If i released a block or module i have created, will have to release it under gpl to comply with moodle being gpl? or can i release it under another licence?
Yes.
(Such a module or block will inevitably code copied from Moodle core, of from the new module/block template. Therefore it is a derivative work of a GPL covered work, therefore you have to release it as GPL.)
(Such a module or block will inevitably code copied from Moodle core, of from the new module/block template. Therefore it is a derivative work of a GPL covered work, therefore you have to release it as GPL.)
What if you didn't copy code from Moodle core, but developed it from scratch based on the published API and documentation? You don't have to use newmodule.zip...
I know with the state of documentation this would be quite some effort, but you could do it (possibly cleanroom-style; get one person to analyze existing code, then pass on the information rather than any actual code to the developer).
Not that I particularly want anyone to create Moodle modules under other licenses (all the Open University's publicly-released Moodle code is GPL). Just causing trouble.
--sam
I know with the state of documentation this would be quite some effort, but you could do it (possibly cleanroom-style; get one person to analyze existing code, then pass on the information rather than any actual code to the developer).
Not that I particularly want anyone to create Moodle modules under other licenses (all the Open University's publicly-released Moodle code is GPL). Just causing trouble.
--sam
At least for blocks, you need to subclass block_base, so no matter what, you will still be linking with Moodle code. Even with modules, you are probably going to use parts of the Moodle API (dmllib, gradebook, etc).
I agree you'll be unable to avoid calling Moodle functions. PHP is an interpreted language, so technically nothing ever gets 'linked' at all... but I googled a bit and it does seem that if plugins are strongly linked to the API, they are likely to be covered.
Seems like a pretty unpleasant aspect of copyright law, to me - for example if a random commercial program can have plugins, I wouldn't like the company to be able to place restrictions on how I could distribute a plugin I wrote. However there are lots of laws I don't like...
--sam
Seems like a pretty unpleasant aspect of copyright law, to me - for example if a random commercial program can have plugins, I wouldn't like the company to be able to place restrictions on how I could distribute a plugin I wrote. However there are lots of laws I don't like...
--sam
Yeah "linked" is probably the wrong word, since PHP is interpreted. Being a subclass, though, a block would probably be considered a derivative work of block_base at least.
I think the bottom line is, I say that any module should be released under a GPL-compatible license, as that is the most direct way of interpreting the license. If you* want to get around it in any way, using clean-room techniques,etc (aside from the purely theoretical discussions on this forum), you should consult a lawyer (and probably be prepared that this be brought to court, as I'm sure that there are people who would want to fight your interpretation).
* "you" being a general "you", and not referring in any way to Sam in particular.
I think the bottom line is, I say that any module should be released under a GPL-compatible license, as that is the most direct way of interpreting the license. If you* want to get around it in any way, using clean-room techniques,etc (aside from the purely theoretical discussions on this forum), you should consult a lawyer (and probably be prepared that this be brought to court, as I'm sure that there are people who would want to fight your interpretation).
* "you" being a general "you", and not referring in any way to Sam in particular.
Well, for better or for worse, that's what the creators of Moodle chose. Otherwise, there's the LGPL which doesn't require the same level of freedom with derivative works.
No. Since you are using GPLed code, your license must be compatible with the GPL (that is, the combined work must be distributable under the terms of the GPL), but as long as that requirement is met, you may use any other license for your own work, such as BSD/MIT, LGPL, public domain, etc. In general, the license for your work would have to be at least as permissive as the GPL, and must allow your work to be sublicensed under the GPL.
Also, note that Moodle is moving to GPLv3, and so your license should be compatible with GPLv3. (e.g. licensing your work under "GPL version 2 only" is not good; licensing your work under "GPL version 2 or later" is OK.)
Of course, licensing your work under a different license would primarily affect only people who might use your code outside of Moodle (e.g. someone who wants to port your block to some other software), since anyone who works within Moodle would be working within the bounds of the GPL anyways.
Also, note that Moodle is moving to GPLv3, and so your license should be compatible with GPLv3. (e.g. licensing your work under "GPL version 2 only" is not good; licensing your work under "GPL version 2 or later" is OK.)
Of course, licensing your work under a different license would primarily affect only people who might use your code outside of Moodle (e.g. someone who wants to port your block to some other software), since anyone who works within Moodle would be working within the bounds of the GPL anyways.
There are two different issues here:
(e.g. using the YUI libraries to do some JavaScript magic inside Moodle).
The external code here doesn't include/use/link with any of the Moodle functionality. It's Moodle that's using this completely independent code.
In this case, Hubert is right, the external code needs to be compatible with the GPLv3. See this list from the Free Software Foundation.
(e.g. creating a block, activity module, etc.).
In this case, your code uses Moodle code and interacts with Moodle directly. As Tim said, it's therefore considered a "derived product" and therefore must be licensed under the same terms as Moodle itself (GPLv3 or later).
Francois
1- Integrating external code into Moodle
(e.g. using the YUI libraries to do some JavaScript magic inside Moodle).
The external code here doesn't include/use/link with any of the Moodle functionality. It's Moodle that's using this completely independent code.
In this case, Hubert is right, the external code needs to be compatible with the GPLv3. See this list from the Free Software Foundation.
2- Extending Moodle with your own code
(e.g. creating a block, activity module, etc.).
In this case, your code uses Moodle code and interacts with Moodle directly. As Tim said, it's therefore considered a "derived product" and therefore must be licensed under the same terms as Moodle itself (GPLv3 or later).
Francois
Actually, they aren't really all that different. What "GPL-compatible" means is that the licenses are loose enough that they can be effectively re-licensed under the GPL 3+ license.
note that Moodle is moving to GPLv3
Is it? I never heard about it, it'd be interesting to learn more about that.
The GPLv3 is a good license, but it is not a true upgrade from GPLv2.
There were 2 changes proposed to GPLv3 that significantly change how the license works: the Affero clauses and the anti-tivolization clauses. Web developers were loud in their opposition, so the Affero clauses were skipped. The anti-tivolization clauses saw significant resistance but rms went through with them.
In my reading, it does have some "issues" -- not in itself, but it adds conditions that are new and unexpected if you are used to GPLv2. It is a different license. I am chasing some lawyer friends who work on FOSS licensing to have a sit down and careful reading of the changes.
(As they say, IANAL; but I have studied copyright & software licensing at law school.)
In case anyone is interested, this discussion touches on the issue.
John Gilmore - of Sun, Cignus, GDB fame - posts here his concerns about Tivoisation http://lists.laptop.org/pipermail/devel/2008-December/021841.html
And my reply is here:
http://lists.laptop.org/pipermail/devel/2008-December/021843.html
In short, depending on the reading, GPL v3 may prevent "Moodle Embedded Servers" that are locked down to prevent tinkering by the end users, regardless of whether they are the legal owners.
Right now the XO has a sophisticated security scheme to discourage laptop theft. The XS doesn't have that right now, so no potential issues w GPLv3. But I want to discourage theft of the XS as well, so it is reasonably likely that we'll see a similar antitheft scheme at least on some XSs.
I frankly suspect John Gilmore is reading too much into it, and that the terms of the license don't support his reading; but I am not certain.
An anti-tivoisation clause that protects the rights of the _owner_ of the hw+sw "product" is very valuable in a FOSS license (*). In any case, the bit that is worrying me is that the GPLv3 confusingly talks about protecting the "user", not the "owner".
* - But in terms of the GPL, it's a _significant change_ in the social contract
and many projects are jumping on the v3 bandwagon without understanding fully what it means. Yes, there are better patent protections (yay!) but some uses you may see as legitimate are now blocked (oops?!).
John Gilmore - of Sun, Cignus, GDB fame - posts here his concerns about Tivoisation http://lists.laptop.org/pipermail/devel/2008-December/021841.html
And my reply is here:
http://lists.laptop.org/pipermail/devel/2008-December/021843.html
In short, depending on the reading, GPL v3 may prevent "Moodle Embedded Servers" that are locked down to prevent tinkering by the end users, regardless of whether they are the legal owners.
Right now the XO has a sophisticated security scheme to discourage laptop theft. The XS doesn't have that right now, so no potential issues w GPLv3. But I want to discourage theft of the XS as well, so it is reasonably likely that we'll see a similar antitheft scheme at least on some XSs.
I frankly suspect John Gilmore is reading too much into it, and that the terms of the license don't support his reading; but I am not certain.
An anti-tivoisation clause that protects the rights of the _owner_ of the hw+sw "product" is very valuable in a FOSS license (*). In any case, the bit that is worrying me is that the GPLv3 confusingly talks about protecting the "user", not the "owner".
* - But in terms of the GPL, it's a _significant change_ in the social contract
A lot of historical anti-GPLv3 comments are based on early drafts and relate to issues which have been resolved before the final license was published.
In terms of the School Server for example, the anti-DRM clause doesn't apply because a school server is not a consumer product.
See the definitions of "User Product" and "Installation Information" from Section 6 of the GPL.
Loosely-speaking, anti-theft devices are fine under GPLv3 as long as the owner of the device has the keys.
Francois
In terms of the School Server for example, the anti-DRM clause doesn't apply because a school server is not a consumer product.
See the definitions of "User Product" and "Installation Information" from Section 6 of the GPL.
Loosely-speaking, anti-theft devices are fine under GPLv3 as long as the owner of the device has the keys.
Francois
My concerns over the Moodle and OLPC are a bit about the XS, and a bit about being able to use bits of Moodle on the XO itself. The fact that a DRM'd XO can boot a different OS image and act as XS means that the line is very blurry.
If it can't be used on the XO, I will be in trouble sooner than you expect.
And reading section 6 doesn't appease me much, and that is the key problem.
Read the definition of "user product". It is very vague language. See:
"If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized)".
One of the readings here is that ownership does not matter -- give the laptop to someone for an extended period of time, and you have 'conveyed' (this is gplv3 parlance for 'distributed'), so they better be able to replace the code on the device.
This reading goes clearly contrary to the GPLv2. Imagine you are working at a large corp, and every employee has a locked down Linux laptop for the duration of their employ.
- Is the device "designed for incorporation into a dwelling"? Yes it is.
- Do the employees have the "right of posession and use", for a "fixed term"? Oh yes they do.
So the definition has been met. In case I made you doubt, "doubtful cases shall be resolved in favor of coverage". Oops, even if we are close, it means we're in!
(This is actually shameful in such an influential license. GPLv2 is crisp-clear, and if you ever heard Moglen speak, you know where the crispness comes from. This hazy "doubtful" definitions look like trouble to me, and don't sound like Moglen at all.)
So, how about the machine being locked down, ie: you have an OLPC-inspired BIOS/firmware that does not let you replace the OS at all unless it comes from company HQ. Looks like progress in security. Also looks like you can't with GPLv3.
In the Moodle case, a govt controlled "Moodle appliance" gets installed in the school. It may be owned and controlled by the Ministry of Education. But if it is a generic device that can be defined as "designed for incorporation into a dwelling" then the Ministry can no longer lock it down.
Section 6 hinges in no small part on whether an 'embedded moodle server' looks like a mac-mini or like a dell blade server.
Now. Please. I don't say this lightly, and I don't mean to FUD. I am researching this but, so far, GPLv3 is a different beast from v2. It changes the social contract. It restricts things that GPLv2 allows.
In other words: it is not the same license. Make sure GPLv3 is what you want.
In practice, it means that for OLPC I may have to revert to the last pure GPLv2 version I can get from out of GIT. Not fun at all.
Personally, I am OK with Moodle going v3 if that's what MD wants and there is reasonable agreement on the topic. I am happy to contribute my code dual-licensed v2/v3.
It changes the social contract. It restricts things that GPLv2 allows.
It seems to me that on a technical level, that would be obvious. If it wasn't different, there would be no point in having a version 3. By the same token, the GPLv2 was different from the GPLv1. However, IMHO, these things that you mention all violate the original purpose of the GPL. DRM in the name of security still violates the user's freedom (as the GPL defines them).
The GPL never cared about the user in that sense.
It has allowed the Linux to be used on multiuser servers for centuries. And on those servers, you get no privileges from the GPL unless you were the root user.
I am a google user. Do I get some privileges from the GPL software they use? During the Affero-for-GPLv3 discussions it was claimed that the 'network' aspects were 'new', but SMTP and friends have been with us for decades.
The GNU userland has been in use on Solaris and other unixen from before Linux existed. Those unixen were prediminantly used as multiuser environments. That is where it was written. RMS stated "I must write GNU" in that era, and his image of the GNU OS didn't give the end users one iota of freedom unless 'root' allowed it.
The recipient of the GPLd software gets some rights. That recipient is usually the owner of hardware on which to run it. More likely, the sysadmin.
Of course, users do benefit. The sources are usually published for all to see, so anybody can get them, and the software enhancements benefit everyone.
But the GPLv2 was not written for the freedom of end users. It is written for the fellow hacker, for the fellow sysadmin.
Is it? I never heard about it
Yup. There was a thread about this somewhere, but I don't know where to find it. The coding style documentation dictates the use of the GPL 3. Many, if not all, of the files under lib, have already been modified to specify "GPL v3 or greater".
Yes, Martin D. mentioned it in this thread: http://moodle.org/mod/forum/discuss.php?d=124359 (see "ISSUE 2: GPL versions")note that Moodle is moving to GPLv3
Is it? I never heard about it, it'd be interesting to learn more about that.
The answer to both your questions is yes. You can release it under whatever license you jolly well please, but if you do, it must also be available under the GPL 3+. This is what they call multi-licensing. Firefox, for example, can be licensed under the GPL, LGPL, or MPL.
Careful here, this thread is gathering a lot of untrue statements.
If you are writing a Moodle block/plugin, it is a derivative of Moodle and therefore the GPL requires that all derivatives also be under the terms GPL.
Dual-licensing is not the GPL.
For example, a piece of code under the BSD license cannot link with or include code from Moodle. So no, you can't license your plugin under both BSD and GPL.
If you want the authoritative source for everything GPL, look here: http://www.fsf.org/licensing/licenses/gpl-faq.html
The only other option you've got, other than GPLv3, is AGPLv3 because the GPLv3 states that it is explicitly compatible with AGPLv3.
Francois
If you are writing a Moodle block/plugin, it is a derivative of Moodle and therefore the GPL requires that all derivatives also be under the terms GPL.
Dual-licensing is not the GPL.
For example, a piece of code under the BSD license cannot link with or include code from Moodle. So no, you can't license your plugin under both BSD and GPL.
If you want the authoritative source for everything GPL, look here: http://www.fsf.org/licensing/licenses/gpl-faq.html
The only other option you've got, other than GPLv3, is AGPLv3 because the GPLv3 states that it is explicitly compatible with AGPLv3.
Francois
Hi all,
i have this debate in serval arena at the moment. The main reason for asking about licensing is i'm looking a revenue stream to support a project.
Most of the issue regarding licensing has been down to semantics.
As if i write a class that extends a parent class is not a derivative work as i have not altered the code in the parent class.
If all the lines of are unique and not copied from gpl code then i can issue in under any licence as im the copyright holder.
Function names and calls to moodle functions fall into the category of linking.
I wouldn't be able to distribute my pluign with moodle if it wasn't gpl.
i have this debate in serval arena at the moment. The main reason for asking about licensing is i'm looking a revenue stream to support a project.
Most of the issue regarding licensing has been down to semantics.
As if i write a class that extends a parent class is not a derivative work as i have not altered the code in the parent class.
If all the lines of are unique and not copied from gpl code then i can issue in under any licence as im the copyright holder.
Function names and calls to moodle functions fall into the category of linking.
I wouldn't be able to distribute my pluign with moodle if it wasn't gpl.
We may call it semantics. Lawyers call it 'laws' and 'license clauses'
In short: your code will use Moodle's core libraries from the moment you include config.php. To work, your code needs the core Moodle libs, and that is covered in GPL (v2 and v3) as "linking".
And if you are linking, you are making a derivative. This is the core point: your code is not standalone; remove the moodle libs and it won't run.
You can use your derivative ("vanilla Moodle + Ian's modules, blocks, themes and patches") as you wish, but if you distribute it (give it to someone else outside of your company, to run in their computer) then you are bound by the GPL.
If Moodle was covered by the LGPL, then you'd be able to link against it, and yet retain the ability to license your part in other terms.
If you really have magic foo that you want to protect, you can build it in 2 components:
write the Moodle module/block/theme so that it only provides the UI and glue with moodle libs, and talks via a network or socket protocol (XMLRPC? SOAP?) to a backend. This 'frontend' will be covered by the GPL.
Write your backend to do whatever secret magic foo, communicating via XMLRPC with the frontend. License it as a separate program in any way you like.
This is only useful if your code is actually doing something that is really novel and mysterious.
Easier and saner, you can do like most devs do: work on custom modules/blocks as a work for hire
I find this interesting.
Can anyone tell me how Joomla (www.joomla.org) get's around this?
Joomla is released under the GPL however allows addon's to be sold by 3rd parties?
Is it just a matter of the owner of the code saying that their code is gpl but they don't mind people selling addons?
Can anyone tell me how Joomla (www.joomla.org) get's around this?
Joomla is released under the GPL however allows addon's to be sold by 3rd parties?
Is it just a matter of the owner of the code saying that their code is gpl but they don't mind people selling addons?
Yes. It is largely up to the owner's point-of-view on the issue whether the GPL is enforced on third-party addons.
Just out of interest then, has anyone at Moodle taken an official stance on this.
(for instance in this discussion Martin Dougiamas seems to hint that he doesn't mind people developing and selling addons, though I could have misread it)
It would seem to me based on comments that I've seen around these forums that there are a number of people wanting to develop for Moodle but in a commercial sense. Would it not expand what is available to Moodle users to allow them to do as such (without taking away from what we already have for free).
To give Joomla as an example again. They allow commercial addons however that does not seem to have hindered the wealth of free and actively developed addon's also available.
(for instance in this discussion Martin Dougiamas seems to hint that he doesn't mind people developing and selling addons, though I could have misread it)
It would seem to me based on comments that I've seen around these forums that there are a number of people wanting to develop for Moodle but in a commercial sense. Would it not expand what is available to Moodle users to allow them to do as such (without taking away from what we already have for free).
To give Joomla as an example again. They allow commercial addons however that does not seem to have hindered the wealth of free and actively developed addon's also available.
The fact that you sell software is completely unrelated to the license that the buyer is under.
In this case, if you sell GPL software, then the person who bought it is perfectly entitled to distribute the source code for free to anyone else they like. So I have no problem with anyone selling addons for Moodle or even Moodle itself (be it on your head when the buyer later discovers they could have downloaded it for free!)
My stance on licensing is that the cleanroom conditions required to legally NOT license new Moodle code under an open source license are so ridiculous that they are practically impossible, and so in the real world all new code should be under the GPL or a looser compatible license, as discussed by others here.
It's just a better model all round to think of selling your precious time rather than trying to impose the industrial-age concept of selling access to electrons that were basically free to produce.
In this case, if you sell GPL software, then the person who bought it is perfectly entitled to distribute the source code for free to anyone else they like. So I have no problem with anyone selling addons for Moodle or even Moodle itself (be it on your head when the buyer later discovers they could have downloaded it for free!)
My stance on licensing is that the cleanroom conditions required to legally NOT license new Moodle code under an open source license are so ridiculous that they are practically impossible, and so in the real world all new code should be under the GPL or a looser compatible license, as discussed by others here.
It's just a better model all round to think of selling your precious time rather than trying to impose the industrial-age concept of selling access to electrons that were basically free to produce.
Great conversation everyone!
I was trying to find a legal (politics stink) justification for GPL'ing our new modular Blackboard to Moodle converter and came up with the following justifications.
1: The work is a derivative of the SFSU converter. While it does not contain any SFSU code, it is a modernized, modularized translation of the preexisting tool.
2: The work generates output in the Moodle course format, which makes our tool a derivative work of Moodle, and thus covered under the GPL.
Even though we included no explicitly GPL'd code, we have created a derivative work of two explicitly GPL'd products.
Look for a release this week in contrib.
I was trying to find a legal (politics stink) justification for GPL'ing our new modular Blackboard to Moodle converter and came up with the following justifications.
1: The work is a derivative of the SFSU converter. While it does not contain any SFSU code, it is a modernized, modularized translation of the preexisting tool.
2: The work generates output in the Moodle course format, which makes our tool a derivative work of Moodle, and thus covered under the GPL.
Even though we included no explicitly GPL'd code, we have created a derivative work of two explicitly GPL'd products.
Look for a release this week in contrib.
Sounds interesting... Can't wait to see it / try it out!
mike
mike
Well, a simple and transparent revenue stream is to ask to be paid for doing custom development to a particular users' requirements, but then release the code as GPL so that everyone benefits. (Of course, it is up to the client whether you release the code to the world by putting it in contrib, or just give one copy to the client.)
Actually, my statement was true, but depending on how you took it, it may have been misleading.
Let's say I write the Foo block. I can put it under the MIT & GPL license if I want. Now, if you use Foo and Moodle together, Foo has to be under the GPL. If the block can only be used with Moodle, the the cross-licensing is effectively pointless, the MIT license could never actually be used.
However, let's say some of my code wasn't moodle specific at all. Cross-licensing would allow someone else to take that section of the code out and integrate it with their own non-GPL project.
All this said, I would usually against cross-licensing since it seems to confuse people (not to mention the GPL is a great license).
Edit: Remember that using the "GPL 2 or greater" license is actually cross-licensing.
Let's say I write the Foo block. I can put it under the MIT & GPL license if I want. Now, if you use Foo and Moodle together, Foo has to be under the GPL. If the block can only be used with Moodle, the the cross-licensing is effectively pointless, the MIT license could never actually be used.
However, let's say some of my code wasn't moodle specific at all. Cross-licensing would allow someone else to take that section of the code out and integrate it with their own non-GPL project.
All this said, I would usually against cross-licensing since it seems to confuse people (not to mention the GPL is a great license).
Edit: Remember that using the "GPL 2 or greater" license is actually cross-licensing.
If you look at http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLModuleLicense it covers this exact question, and says, among other things: "You can, if you wish, release your program under a license which is more lax than the GPL but compatible with the GPL." (emphasis mine) So the 3-clause BSD license is OK, because it is compatible with the GPL. (The original 4-clause license is not OK.)
Dual licensing (with GPL as an option) is GPL compatible, so long as anyone can choose to license the work under the GPL only.
Dual licensing (with GPL as an option) is GPL compatible, so long as anyone can choose to license the work under the GPL only.
You're right, I was wrong.
You can dual-license your Moodle plugin on it's own. However the combined product stays under the GPL and the same GPL-compatible requirements apply to anybody linking with your BSD code.
You can dual-license your Moodle plugin on it's own. However the combined product stays under the GPL and the same GPL-compatible requirements apply to anybody linking with your BSD code.
Yes, that's a good explanation.