Hello,
Is it against Moodle license to create a plugin or module and not to release it under GPL, but use a propietary (closed source) license for this new plugin or module ?
I am not a lawyer, but my understanding is that yes it's legal, as long as:
- You don't use any GPL code in the closed source module
- You don't distribute the closed source module with any GPL code (for instance, a package containing Moodle and your plugin).
Hello,
Yes, I willl release all contributed modules under GPL, except for a tiny one involved in integration with other propietary software, wich is a requisite for my customer.
I asked this because I read somewhere in the past that if you write code that *must* run under a GPL'd software (i.e, some piece that makes no sense tu be runned alone) then you are forced to license it as GPL, too.
thanks for your answer
This is incredibly common if you are involved in commercial development for Moodle. The simple answer, in my interpretation, is as follows...
* Your Moodle addition almost certainly has to be GPL
* You don't HAVE to distribute it to anybody except your customer
(of course, the GPL gives your customer the freedom to redistribute so price/act accordingly).
* Your Moodle addition almost certainly has to be GPL
* You don't HAVE to distribute it to anybody except your customer
(of course, the GPL gives your customer the freedom to redistribute so price/act accordingly).
In reply to Howard Miller
Re: Non-free plugins and Moodle license question
Really Howard is, IMO, 100% correct:
- Your plugin must endorse GPL, because Moodle is GPL and your solution is using it (any doubt? is it able to run without Moodle?). That's the difference between GPL and LGPL (that Moodle is not at all).
- The GPL license doesn't force you to redistribute the code worldwide nor anything like that, you decide how you spread your solution. Point. It simply grants to ppl receiving it, the same rights you have over it (look, modify, redistribute...) while keeps another to you, basically authorship. So, once you've distributed it to your customer, then both you and your customer have rights to redistribute the plugin freely, but in any case, it's your (any of you) decision to do that or no.
Cristal clear IMO
- Your plugin must endorse GPL, because Moodle is GPL and your solution is using it (any doubt? is it able to run without Moodle?). That's the difference between GPL and LGPL (that Moodle is not at all).
- The GPL license doesn't force you to redistribute the code worldwide nor anything like that, you decide how you spread your solution. Point. It simply grants to ppl receiving it, the same rights you have over it (look, modify, redistribute...) while keeps another to you, basically authorship. So, once you've distributed it to your customer, then both you and your customer have rights to redistribute the plugin freely, but in any case, it's your (any of you) decision to do that or no.
Cristal clear IMO
Hi, Howard and Tim
Currently I am using Moodle to teach kids at my private tuition centres and online.
As I have not been able to have many of the features and user interfaces I would like to have for my students with Moodle. I have been heavily customising the front end/interface of the system (beyond themes) in order to meet the specific requirements and demands of my courses and students.
In your discussion, you say that, under GPL, "You don't HAVE to distribute it to anybody". I do not sell or distribute the customised system as a code to anyone but sells my contents as a teaching/learning service, which are created on and therefore must run on my customised moodle system and quiz engine.
My question is whether I have to disclose and share all the custom codes (and even contents?) to anybody if it is requested under the GPL? I believe that this is not the case, and selling contents on the customised system on the internet (on VPS) does not mean "distributing" the customised system, correct?
It may sound like a silly question, but I would like to make sure that I understand.
Your help is highly appreciated.
Kind regards,
Noby
Noby, you have not asked a silly question. The clauses of the GPL only come into play if you distribute the program. Allowing someone to access it via a web interface does not come into it. There is a separate GNU license for this consideration called the Affero GPL.
To nit pick Howards comment from 2009
* Your Moodle addition almost certainly has to be GPL
I'm not sure this is true. If you don't distribute your program then there is no obligation to
do anything to "apply the GPL" as the GPL only has meaning if you distribute the program. So you could include a license notice saying "This is my code, its not GPL and you cannot make copies of it". You could then sit and admire your cleverness and show it to people who you did not distribute the code to. But as soon as you were to distribute the code, that additional "license" would be in breach of the GPL.
* You don't HAVE to distribute it to anybody except your customer
That is entirely true, and if you do distribute it to your customer they get the same GPL rights you had when you received the code that the plugin is now part of.
If you think of a Word processor that was released under the GPL, you would not expect that it would limit the license of documents created using it. In the same way you can create courses that are hosted by Moodle and there is no restriction on the license under which you sell those courses.
Hi, Marcus and Tim
Thank you very much for your explanation. Now it is very clear to me, and I can continue customising the codes where necessary and enrich the contents.
Kind regards,
Noby
I just meant (I think) that IF there is a need for a license then it's going to be GPL as a derivative work of Moodle.
However, in this case, as the code is going no place then it is irrelevant (as you point out).
I care about this because I *do* develop Moodle plugins for clients where I do distribute the code. I am perfectly happy for them to be GPL with all that entails. What annoys me is when other developers attempt to apply more restrictive license conditions. So, I'm keen that the message and obligations are clear.
I missed my vocation as a nitpicking lawyer
"What annoys me is when other developers attempt to apply more restrictive license conditions. So, I'm keen that the message and obligations are clear. "
Me too
You are correct.
Content you add to Moodle is not affected by Moodle's licence, in the same way that a document in write in Microsoft Word is not affected by Microsoft's licence.
For Moodle code, the GPL only specifies what should happen if you give (or sell) the software to someone.
It is almost inevitable that any Moodle plugin will count as a derivative work of Moodle, thus, you must obey the GPL.
GPL places very little restriction on what you do until you try to give your code to someone else - the you have to give the the same freedoms over the whole work that the GPL gave you over Moodle.
This has been discussed at length before. Try finding the previous thread(s).
GPL places very little restriction on what you do until you try to give your code to someone else - the you have to give the the same freedoms over the whole work that the GPL gave you over Moodle.
This has been discussed at length before. Try finding the previous thread(s).
Yes, that is what I thought. Thank you for yout POV
I agree with Mark that we should encourage everyone to contribute openly to Moodle in the spirit of community.
But one should emphasize that whether something is a derivative work depends on how one approaches writing it. If you start your module or theme from scratch and only use API calls and theme selectors, for example, that is not a derivative work (at least to my understanding -- I am not a lawyer, but we must all obey the law).
The reason that this is often misunderstood is that people read the GPL license and think that the word "link" means connected to in any possible way. But the license uses the word "link" in the way that a compiler does it -- connecting up code that you don't own with your own work, often in a way that can't be disconnected.
For example, you are free to make a plugin for Microsoft Word and they have nothing to say about how you license it. But, if you compile it with one of their libraries or if you ship it with a copy of Word, then you are subject to their copyright restrictions.
Now, if someone wants to suggest that merely using the documented API calls or theme selectors is sufficient to make something a derivative work, then that would be a good discussion. But otherwise, whether a plugin must by its nature be free and open-source really depends on how one went about creating it and how one distributes it. But I am happy to stand corrected if this is wrong.
But one should emphasize that whether something is a derivative work depends on how one approaches writing it. If you start your module or theme from scratch and only use API calls and theme selectors, for example, that is not a derivative work (at least to my understanding -- I am not a lawyer, but we must all obey the law).
The reason that this is often misunderstood is that people read the GPL license and think that the word "link" means connected to in any possible way. But the license uses the word "link" in the way that a compiler does it -- connecting up code that you don't own with your own work, often in a way that can't be disconnected.
For example, you are free to make a plugin for Microsoft Word and they have nothing to say about how you license it. But, if you compile it with one of their libraries or if you ship it with a copy of Word, then you are subject to their copyright restrictions.
Now, if someone wants to suggest that merely using the documented API calls or theme selectors is sufficient to make something a derivative work, then that would be a good discussion. But otherwise, whether a plugin must by its nature be free and open-source really depends on how one went about creating it and how one distributes it. But I am happy to stand corrected if this is wrong.
The concept of "link" is not as clear as it could be, I agree.
I've never thought it as Martin Langhoff describes it below, but his description sounds plausible to me.
Even if we ignore that angle for a moment, my perspective has always been that it's simply not possible to develop code "100% from scratch" in the real world. Developers always copy existing code, and thus the new code needs to follow the same license.
As others have said, I think the best way to work with non-GPL code is to write a GPL module that communicates with a separate standalone system (non-GPL).
I've never thought it as Martin Langhoff describes it below, but his description sounds plausible to me.
Even if we ignore that angle for a moment, my perspective has always been that it's simply not possible to develop code "100% from scratch" in the real world. Developers always copy existing code, and thus the new code needs to follow the same license.
As others have said, I think the best way to work with non-GPL code is to write a GPL module that communicates with a separate standalone system (non-GPL).
+1 with Tim and Howard. Listen to these guys, they know what they're talking about -- Your plugin code will be compiled/interpreted/executed as part of Moodle, so it is effectively "linked" together in terms of the GPL.
Recommended reading http://moodle.org/mod/forum/discuss.php?d=135139
However -- if you do have code that does something very special and does not in any way depend on Moodle itself, you can write it and run it separately.
Here is how it can work:
- Write your own program, under your own license, encapsulating your magic thing. Make it respond to RPC calls, or just make it a separate executable program.
- Write a moodle plugin or module that talks to it via RPC, or that executes your program. This code will mostly be boilerplate Moodle plugin, and UI interactions, and will be subject to the GPL. But it doesn't matter to you -- because your "magic" is elsewhere.
This assumes you have some strong magic worth preserving and selling separately.
There is no disagreement that one is under the GPL if they include Moodle or any other GPL code (or parts of it) in their product. But a plugin or theme written from scratch and distributed by itself does not contain any code written by anybody else, so, just like you don't have to ask Microsoft permission to write a Macro that runs under Excel, you don't need to give a GPL license to your code written from scratch for an open source project.
I have no horse in this race as I don't sell my work.
I have no horse in this race as I don't sell my work.
Even if you wrote it yourself, it will be calling the Moodle API all the time So it is not self-standing code. It doesn't run without Moodle, so it is a "derivative work".
If it is self-standing code that runs anyway without Moodle, it is easy to make it a separate program (in the way that I've described, and the GPL doesn't affect it.
Examples:
- Moodle connects to Oracle (as its main DB, or as an external DB for auth or enrolment) via an RPC mechanism. GPL doesn't affect Oracle.
- Moodle sends email via SMTP, potentially via a proprietary email server like MS Exchange, again GPL doesn't do anything.
- Moodle uses external programs like /usr/bin/zip -- the GPL doesn't affect it. (It uses a custom license).
- Moodle can control external programs -- I use it to control ejabberd -- by executing commandline calls. Ejabberd is a program on its own right, so it could use any license. (It is GPLd
"Even if you wrote it yourself, it will be calling the Moodle API all the time 
So it is not self-standing code. It doesn't run without Moodle, so it is a "derivative work"."
This has been hashed over many times, but the distinction is pretty arbitrary between using an API in an environment like PHP (where tiny little programs execute over and over) and decoupling bits via an external program or php process. For instance, to get the desired functionality and avoid any GPL conflicts they could write a wrapper/controller for the appropriate moodle API bits, this adapter writes data to an output stream (file, db, pipe whatever); so this adapter is GPL, as it's part of moodle. This output data is then consumed by a proprietary bit of software which then writes the data back to the stream, where it is consumed by the GPLed API adapter again and ingested back into moodle. Unnecessarily complex technically, but I think this approach allows GPL/proprietary functionality to coexist. (you probably don't even need an adapter as web apps, and I think especially moodle, aren't very stateful, almost everything is read in/out of the db, so a proprietary bit of code in a separate process modifying the db directly would likely suffice)
Cheers,
Kyle
So it is not self-standing code. It doesn't run without Moodle, so it is a "derivative work"."This has been hashed over many times, but the distinction is pretty arbitrary between using an API in an environment like PHP (where tiny little programs execute over and over) and decoupling bits via an external program or php process. For instance, to get the desired functionality and avoid any GPL conflicts they could write a wrapper/controller for the appropriate moodle API bits, this adapter writes data to an output stream (file, db, pipe whatever); so this adapter is GPL, as it's part of moodle. This output data is then consumed by a proprietary bit of software which then writes the data back to the stream, where it is consumed by the GPLed API adapter again and ingested back into moodle. Unnecessarily complex technically, but I think this approach allows GPL/proprietary functionality to coexist. (you probably don't even need an adapter as web apps, and I think especially moodle, aren't very stateful, almost everything is read in/out of the db, so a proprietary bit of code in a separate process modifying the db directly would likely suffice)
Cheers,
Kyle
I agree that this is often discussed and many people assume that an original piece of code becomes a derivative work if it is designed to work only with one other program because it uses its API, etc. But that is not what the license says. And a license is unable to restrict others from making original work even if it wanted to.
What a license can do is set conditions on distributing its software with your code. So compiling and linking with a GPL library for an executable, and distributing that combined work would fall under the GPL. As would giving someone else a modified copy of Moodle. But if they install the plugin themselves, the developer is not the one distributing the GPL code, only his own. And as such, it would seem from my reading, he can assign whatever license he chooses.
Of course, one could argue that names get_record and update_record, or the names of CSS tags, etc. are themselves copyrighted, but then that would seem to make any extension for a commercial product subject to the copyright of that product, and I don't think anybody makes that claim. And there is no separate copyright law for free and open source programs.
Now, if the above is correct, would commercially pluggins, distributed outside of the open-source channel, hurt an open-source project? I don't think so. And, they would have to compete against free software. The other consequence if the above is correct is that one should not assume that all their pluggins have a GPL license, especially if it obtained from a source that only distributes code under the GPL.
What a license can do is set conditions on distributing its software with your code. So compiling and linking with a GPL library for an executable, and distributing that combined work would fall under the GPL. As would giving someone else a modified copy of Moodle. But if they install the plugin themselves, the developer is not the one distributing the GPL code, only his own. And as such, it would seem from my reading, he can assign whatever license he chooses.
Of course, one could argue that names get_record and update_record, or the names of CSS tags, etc. are themselves copyrighted, but then that would seem to make any extension for a commercial product subject to the copyright of that product, and I don't think anybody makes that claim. And there is no separate copyright law for free and open source programs.
Now, if the above is correct, would commercially pluggins, distributed outside of the open-source channel, hurt an open-source project? I don't think so. And, they would have to compete against free software. The other consequence if the above is correct is that one should not assume that all their pluggins have a GPL license, especially if it obtained from a source that only distributes code under the GPL.
If you want to be strictly correct... what the license says (in section 2) is:
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
..."reasonably considered independent and separate works"... is the key. In practice, this has led lawyers and courts to look at 2 'threshold issues':
- Is your code able to run independently... usefully?
- do your code and the GPL code end up executing in the same address space, as one program? In other words, are they linked - in the technical sense of what a linker does? Some references at http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works
With interpreted languages, you do end up executing in the same address space.
The above is to the best of my knowledge. I am not a lawyer - however, I have done 2 master levels courses in software licensing with the excellent Bob Dugan. And I've done quite a bit of work with copyright lawyers on sw licensing. As always, consult your lawyer, and stay away from the courts!
If your code does not run without Moodle, then it is covered under the GPL.
If your code does run independently of Moodle and outputs to something moodle specific, like the Moodle 1.9 file format, then it is covered under the GPL.
If your code runs independently of Moodle, does not borrow anything from Moodle, and does not depend on Moodle for its usefulness, then you can do what you want with it.
IANAL, but the above was always pretty obvious to me.
If your code does run independently of Moodle and outputs to something moodle specific, like the Moodle 1.9 file format, then it is covered under the GPL.
If your code runs independently of Moodle, does not borrow anything from Moodle, and does not depend on Moodle for its usefulness, then you can do what you want with it.
IANAL, but the above was always pretty obvious to me.
The problem with dialogs like this is that everyone is well meaning and trying to get a better understanding of the situation, but we really don't get any closer to resolving the issue.
I stand by my position that making plugins that interface with a product does not require or imply that you are giving a special license to users. You may, however, be restricted from distributing your product with the program being interfaced to.
But I also acknowledge that the much more popular perspective that is frequently repeated is that if you create code that is designed to interface exclusivly with a GPL license product, you must give that creation a GPL license even if you don't distribute it with the original GPL licensed code.
The link below is the GPL license used by Moodle for one to read and reach their own conclusion.
http://docs.moodle.org/en/License
I also encourage everyone to freely share their code to open-source projects, not because it is a requirement in all cases, but because of the benefits it gives to all involved.
I stand by my position that making plugins that interface with a product does not require or imply that you are giving a special license to users. You may, however, be restricted from distributing your product with the program being interfaced to.
But I also acknowledge that the much more popular perspective that is frequently repeated is that if you create code that is designed to interface exclusivly with a GPL license product, you must give that creation a GPL license even if you don't distribute it with the original GPL licensed code.
The link below is the GPL license used by Moodle for one to read and reach their own conclusion.
http://docs.moodle.org/en/License
I also encourage everyone to freely share their code to open-source projects, not because it is a requirement in all cases, but because of the benefits it gives to all involved.
I believe the license states what is allowed but does not state that this must be enforced. I think we should stop debating over the license for a bit and consider what may be most beneficial a model for the Moodle community.
eg. Joomla is a CMS that is released under the GPL yet has many commercial addons that tie in in a similar way that Moodle addons do. The creators could theoretically ban this but they have decided to allow and foster it. Overall I think it has been a very beneficial approach for them. The main product (Joomla) is still completely free and get's a lot of development support. There are many free addons. And there are many paid for addons. Overall the choices and quality are very high and everything coexists nicely.
I can really see Moodle existing and thriving under a similar model. Especially given the increasing interest there seems to be in people wanting to develop commercial addon's for Moodle. It won't take anything away from what is currently available for free and yet will create increasing value for those willing to spend a little money.
Now there is the model of paying developers to develop the addons, then releasing it for free, and in an ideal world this sounds great, but in reality it doesn't quite work that well. If I'm an organisation and desire a certain feature X. Under this model I either have to foot the bill for development entirely myself, I then have to wait for it to be developed etc. Or I can try and find others that also desire feature X and get them to share the cost (but this is a lot of effort and not guaranteed), then fight with them over how it should be implemented etc.
Or I can purchase a commercial product and implement it now with a lot less effort and hassle. And because they want me to buy it they have an interest in making it as good as possible. So I get a better product in terms of quality and cost (both effort on my behalf and money). I'm not saying all addons should be commercial and I don't believe they would be. The balance would remain, as it has done nicely and naturally within Joomla and others that have adopted this model.
Anyways, this is ultimately the decision of the creators and I will respect any such decision they make.
eg. Joomla is a CMS that is released under the GPL yet has many commercial addons that tie in in a similar way that Moodle addons do. The creators could theoretically ban this but they have decided to allow and foster it. Overall I think it has been a very beneficial approach for them. The main product (Joomla) is still completely free and get's a lot of development support. There are many free addons. And there are many paid for addons. Overall the choices and quality are very high and everything coexists nicely.
I can really see Moodle existing and thriving under a similar model. Especially given the increasing interest there seems to be in people wanting to develop commercial addon's for Moodle. It won't take anything away from what is currently available for free and yet will create increasing value for those willing to spend a little money.
Now there is the model of paying developers to develop the addons, then releasing it for free, and in an ideal world this sounds great, but in reality it doesn't quite work that well. If I'm an organisation and desire a certain feature X. Under this model I either have to foot the bill for development entirely myself, I then have to wait for it to be developed etc. Or I can try and find others that also desire feature X and get them to share the cost (but this is a lot of effort and not guaranteed), then fight with them over how it should be implemented etc.
Or I can purchase a commercial product and implement it now with a lot less effort and hassle. And because they want me to buy it they have an interest in making it as good as possible. So I get a better product in terms of quality and cost (both effort on my behalf and money). I'm not saying all addons should be commercial and I don't believe they would be. The balance would remain, as it has done nicely and naturally within Joomla and others that have adopted this model.
Anyways, this is ultimately the decision of the creators and I will respect any such decision they make.
You can see lots of examples of how to do this in the Moodle community. Elluminate, Wimba, Respondus, Turnitin, Google, even Microsoft, have all built or had built for them integrations between Moodle and their commercial or otherwise licensed products. The Moodle side module/block/auth plug-in/enrollment plug-in is covered under the GPL, but not WindowsLive, GoogleApps, WimbaVoice, etc. Folks who are interested in making commercial plug-ins can look at these plug-ins to see examples.
I've designed/PM'd a few commercial-app<->Moodle integrations, and basically if you think of the diagram below, everything in orange is GPL. If you make an CommercialApp Moodle module, and let anyone have it, they can re-release it willy-nilly. However, they can't connect to your CommercialApp unless you let them, and they can't make any claims on any of the code in your commercial App (all the stuff in blue) - unless you copy (or type) some Moodle code into it - don't do that
.
The stuff in green is just data, marked up somehow to make it translatable (many use XML, more still just use CSV).
I've designed/PM'd a few commercial-app<->Moodle integrations, and basically if you think of the diagram below, everything in orange is GPL. If you make an CommercialApp Moodle module, and let anyone have it, they can re-release it willy-nilly. However, they can't connect to your CommercialApp unless you let them, and they can't make any claims on any of the code in your commercial App (all the stuff in blue) - unless you copy (or type) some Moodle code into it - don't do that
. The stuff in green is just data, marked up somehow to make it translatable (many use XML, more still just use CSV).
moodle-thing_2.png
I think we said pretty much the same thing. Do you know of any examples where a 'differently licensed' app modified the moodle DB directly?
I think we said pretty much the same thing. - but I LIKE using Balsamiq.'
Do you know of any examples where a 'differently licensed' app modified the moodle DB directly?
If your app contains Moodle table names in it's code, it would break GPL - but if the apps. db calls are non-specific - e.g. end user configured, it's ok - for example there are various MySQL management apps that can be used to modify Moodle tables.
Also look at ExternalDB - the concepts there can be extended
.
Do you know of any examples where a 'differently licensed' app modified the moodle DB directly?
If your app contains Moodle table names in it's code, it would break GPL - but if the apps. db calls are non-specific - e.g. end user configured, it's ok - for example there are various MySQL management apps that can be used to modify Moodle tables.
Also look at ExternalDB - the concepts there can be extended
The issue is not what we, or anyone here think is GPL, the place to start is with the copyright holders interpretation.
The Free Software Foundation, the Software Freedom Law Center - they have their interpretation and its for the most part based on 'value' - the technical form of the integration matters a lot less to them. "If your App depends 100% on the GPL work - its a derived work" - that's their view, from their classes on GPL compliancy
But they don't own the software and they don't get to decide on how Moodle interprets the GPL. Just as the Linux Kernel team has their own interpretation of derived works, they don't see proprietary applications running on the kernel (userspace) as derived works under the license. Smart move as Linux would be no where if it couldn't run Proprietary applications.
So, the question is, and the only source we can really abide by, is the Moodle team, the copyright holder. So I am searching in here for any previous policy statements by them, not all of us forum members. If they don't have any policy statement on this - then we can I guess look at their actions, which seem to be unconcerned at all with proprietary applications hooking in using standard interfaces or in some custom fashion.
Which is fine and all, I've no quarrel with them wanting to foster such, others might see this as making a profit from the free contribution of all the contributors. Though it would be good if contributor agreements let people know how others might benifit from thier free software. Really not my concern.
I would love, just from an intelelctual point of view, to find the thinking for using GPL and not LGPL as a way to set aside any concerns of integration. LGPL would for the most part remove these concerns about derived works - and copyleft effects from integration.
Anyone knowing any thread to read, appreciated, other wise I will continue using search.
[quote]
..."reasonably considered independent and separate works"... is the key. In practice, this has led lawyers and courts to look at 2 'threshold issues':
- Is your code able to run independently... usefully?
- do your code and the GPL code end up executing in the same address space, as one program? In other words, are they linked - in the technical sense of what a linker does? Some references at http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_deriv
[/quote]
To be fair the courts have never addressed the viewpoint of the SFLC/FSF. The intentions of the GPL founders push copyright law in regards to derived works to extremes that have no caselaw as guidance.
Nor is it really correct to say the courts have decided on these 'tests' as a way to define derived works. Of 11 Federal courts, as I remember my research 4 used a similar test, 2 used completely different test ans some courts had no ready test to go by. There is hardly a consensus opinion in these courts.
Though again, even if there was it wouldn't cover the FSF viewpoint, which has only partially to do with the technical forms of integration. It looks t the semantics of the integration(their words not mine).
Again, all of this is mute of Moodle doesn't care, its their ownership, their right to pursue as they see fit.
There is not single copyright holder for Moodle. The Moodle project does not ask contributors to assign copyright, so all contributions are copyright their original authors.
I am a core developer, and I worked for moodle.com for a year to August 2009. Currently I work for the Open University, UK as a developer. Personally, I am a strong believer in free software. I cannot speak for the Moodle project.
Moodle does care about about freedom. For example, some months ago we had a crack-down on non-GPL themes.
On the other hand, we are not completely against commercial software. An example of the right way to do it is the Elluminate integration. Elluminate is stand-alone online meeting software that is commonly used in Education. It is closed source, and works fine without Moodle. Typically you would have Elluminate running on one server, and Moodle running on another.
The Moodle-Elluminate integration easily lets teachers add elluminate sessions to their courses, giving students a single link to click to get into their Elluminate session. This is implemented as a Moodle plugin that is released as GPL. http://cvs.moodle.org/contrib/plugins/mod/elluminatelive/?pathrev=MOODLE_19_STABLE
That complies with the GPL, and in the absence of an open-source competitor to Elluminate (I wish there was one), it is the best thing we can offer teachers.
I am a core developer, and I worked for moodle.com for a year to August 2009. Currently I work for the Open University, UK as a developer. Personally, I am a strong believer in free software. I cannot speak for the Moodle project.
Moodle does care about about freedom. For example, some months ago we had a crack-down on non-GPL themes.
On the other hand, we are not completely against commercial software. An example of the right way to do it is the Elluminate integration. Elluminate is stand-alone online meeting software that is commonly used in Education. It is closed source, and works fine without Moodle. Typically you would have Elluminate running on one server, and Moodle running on another.
The Moodle-Elluminate integration easily lets teachers add elluminate sessions to their courses, giving students a single link to click to get into their Elluminate session. This is implemented as a Moodle plugin that is released as GPL. http://cvs.moodle.org/contrib/plugins/mod/elluminatelive/?pathrev=MOODLE_19_STABLE
That complies with the GPL, and in the absence of an open-source competitor to Elluminate (I wish there was one), it is the best thing we can offer teachers.
The licensing of Moodle plug-ins is quite clear.
Moodle is GPL, Moodle plug-ins make function calls to Moodle and share data structures. Therefore, all Moodle plug-ins which run within Moodle are GPL.
Read the GPL FAQ here for conformation - http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF
"If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed."