Commercial version questions regarding the GPL

I'm not the author, but this is a common misunderstanding that often comes up in open-source projects: provided this is an original copyrighted work (i.e. 100% of the code is by the author, not building on GPL code written by anyone else), the author can do as he pleases. The GPL can't supersede the author's ownership and right to relicense his own code under a different license (as an example of dual licensing, take a look at, for instance, MySQL).

Of course, if the author of this project is "borrowing" anyone else's code, then that makes his software a derivative work and he might have a problem.

Also, it's not exactly true that GPL software can't be sold for profit; there's just not much point in it (since the code has to be publicly made available). In Stallman's own words, from http://www.gnu.org/philosophy/selling.html:

"Except for one special situation, the GNU General Public License (GNU GPL) has no requirements about how much you can charge for distributing a copy of free software. You can charge nothing, a penny, a dollar, or a billion dollars. It's up to you, and the marketplace, so don't complain to us if nobody wants to pay a billion dollars for a copy."

Seems the author already wrote something about this on the forums: http://drupal.org/node/25412

Khalid's "extended" version would actually still be covered under the GPL, actually, since it is in effect a derivate work of node vote. But, he is free to a) sell it and b) distribute it. Being GPL, the people he distributes the code to must receive a) the source code (automatic with PHP unless you obfuscate it) and b) the right to make changes/redistribute under the GPL.

However, they are unlikely to get any assistance from Khalid if they do this.

In any case, this is certainly a tricky/interesting area of open source. Khalid has done nothing wrong, and I applaud his initiative in going this route.

Note: I've changed the title because it is incorrect and somewhat inflammatory. Let's just use this space for discussion and/or move it to the forums where Khalid explains his two modules.

Groklaw has a fine collection of articles on the GPL. The ones under the heading, "Groklaw articles on the GPL" on the following page are particularly good:

http://www.groklaw.net/staticpages/index.php?page=20050131065655645

Jeremy:

The point you raise about modules using the Drupal APIs is very good; this is indeed something of a slightly fuzzy area, arising from the fact that GPL was originally designed with compiled languages (such as C/C++) in mind, where there are libraries and binaries etc., and everything is in general a bit different than with dynamic scripting languages such as PHP.

The FSF tackles the issue, sort of, in their GPL FAQ:

What is the difference between "mere aggregation" and "combining two modules into one program"?

Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.

Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL--if you can't, or won't, do that, you may not combine them.

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

Again, it is clearly evident that the explanation given there is not quite suitable for PHP (what exactly is a "program", in PHP ?) But I think the issue can really be resolved through these two points:

1) How "deep" is the API and thus the resulting linkage? In Drupal's case, the API is high-level, nice and clean; we are in essence talking of certain, pre-defined function names which the module developer can implement in his code, as well as other functions that he can call to access the DB interface and so on. Now consider: if somebody were to start entirely from scratch and write a commercial PHP-based CMS that would implement 100% the same API as Drupal, but would be a fully original work not based on any open source code, many existing Drupal modules could work with it as is, no code changes required. Conversely, say somebody wrote a GPL module for this new commercial CMS; that still wouldn't make the base CMS system GPL. I think this certainly would argue in favor of the legal theory that Drupal's API (and PHP APIs in general) are loosely-coupled enough that the FSF's definition of a linked "program" doesn't come into play.

2) Industry standard practice: lots of other GPL projects (and CMS scripts in particular) written in PHP (or Perl, Python or Ruby) have faced this same question. Most of the discussions I've seen have reached the conclusion outlined in my previous point. For instance, I remember it being discussed at some length in the Mambo forums. Though Mambo has somewhat less of a strictly (= cleanly) defined "API" than Drupal does, there exist a quite large number of third-party commercial add-ons for Mambo that utilize this API and thus potentially "link" with Mambo; in the end, just so everyone could be 100% clear on the issue, I think the core developers gave their explicit blessing to commercial add-ons using the Mambo API, which quite effectively ended the debate (as again, the copyright holders always have ultimate authority over their own code). Perhaps a similar gesture might be useful for Drupal as well?

Boris wrote:

Khalid's "extended" version would actually still be covered under the GPL, actually, since it is in effect a derivate work of node vote. But, he is free to a) sell it and b) distribute it. Being GPL, the people he distributes the code to must receive a) the source code (automatic with PHP unless you obfuscate it) and b) the right to make changes/redistribute under the GPL.

This is incorrect. The extended version is a derivative work of the basic version, but it doesn't necessarily have to be GPL-licensed, provided (as I stated before) that Khalid owns the copyright to the entire work. I reiterate that the GPL does not bind the copyright holder, who is certainly free to relicense his own code in any way he pleases.

To clarify this, say that I write YANVS (Yet Another Node Vote Script), which is 100% my own work (not borrowing code from anyone else), and I release version 1.0 under the GPL. Now, I continue development on YANVS, but for some reason my mental health deteriorates, and I decide not to release version 2.0 under the GPL, but instead make it a fully commercial product. That is fine; as the author and copyright holder, I'm entirely entitled to do this, and the code for version 2.0 is thus never released publicly, even though it certainly is a derivative work building on the original 1.0 codebase. However, my change of heart does not, of course, affect the already-released version 1.0, which is still covered under the GPL and free for anyone to use, modify and improve (there is no way to revoke the rights I've given others to use it under the GPL).

However, let's say that there is then another developer who (not owning any other rights to the original 1.0 codebase other than those granted him as a licensee of the GPL) decides to roll his own, improved 2.0 version, which (following my example) he makes commercial as well, not releasing any of his changes back to the community. Not only is he in breach of the GPL, but I have a very clear case of copyright infringement to prosecute against him.

Short version: GPL affects licensees, not copyright holders.

Prometheus That's right :-) Misunderstandings regarding this are very common.

Actually, one could quite easily make the case that a Drupal module is always derived work based on Drupal itself and thus has to be released under the GPL as well. A Drupal module can usually only be used together with Drupal, so it makes some sense. But IANAL.

Hello everyone.

I am somewhat disappointed by Jaza making a tempest in a teapot, rather than asking first for a clarification on the perceived violation.

I also like to thank those who stood up for a fellow Drupaller, and linked to my other post too.

To give the short answer, this is a special case of dual licensing. Think about MySQL database and many other free software projects.

The commerical version of these modules existed before a GPL version was created. My other post linked to above detailed how that came to be, and rather than making it all a closed version for one customer, the community gains a version, but the customer gains a competitive edge.

As for whether Drupal modules should by default by GPL'd, this is a variant of the infamous Linux Driver debate, where many (including Linus) have asserted that they are GPL no matter what. Others hold the opinion that this should not be the case, citing this as an example of fanaticism, and promoting the stereotype that the GPL is a bad virus that infects any software it comes in contact with, and spreading FUD on GPL being restrictive rather than promoting freedom.

I recommend that modules be declared as LGPL, thus allowing commerical companies to have their closed versions for their own use, yet the core stays GPL as it is now. If a developer wants to GPL their module, then they are still free to do so.

I think that core developers (Dries) contact Eben Moglen on this (lawyer and co-author of the GPL), and declare a position that is more conducive to innovation and not perceived as restrictive.

(I was wondering if we will get a patch for that issue, so we can close it. Also, should we branch it to 4.5 ? [Just some lighthearted jokeing around])

Thanks to others for correcting me -- you are absolutely right, the licensing affects licensees (silly me!).

The all-modules-must-be-GPL issue did come up at DrupalCon in Belgium. The majority of people pretty much agreed that whether or not it was "officially" stated, modules did NOT have to be GPL (killes: if I write code for scratch that mimics the Drupal hook structure, the modules would still work).

I too would like to see a clear statement around modules. LGPL may be the way to go.

Boris, I actually think there was agreement that modules should be GPL. At least the one time when it was discussed when I was around. Some people said that themes (at least their stylesheets) would not need to be GPl since they would be more generally applicable.

As a Drupal consultant, I always sell my time and not my code. The code generated is done as "work for hire" and thus copyrighted by the client and licensed under the GPL. That does not mean it is neccessarily published.

Don't get me wrong, I think that dual licencing is ok. But a Drupal module is by no means comparable to MySQL because it is not a standalone application.

Regarding the issue of contrib modules and whether they are GPL by definition or not.

I did not attend the meeting, so I cannot say what was all discussed.

However, I vividly remember that after that it was briefly mentioned that the agreed upon thing was that "all contributed modules in the repository should be GPL", specifically excluding any other license (e.g. BSD, ...etc.) to avoid confusion on what license modules that are downloaded from Drupal.org would be under.

So, by implication, if something never hit the repository, it is not by default GPL.

In other words, if a module was never in the contribs on Drupal.org, but is installed on a server running Drupal, it does not follow that this module is now "tainted" and should become GPL by default.

As I said above, a similar controversial issue rears its head up every now and then in the Linux kernel, specifically drivers. Well meaning but uncompromising Open Source vigilante claim that everything should be GPL, including kernel drivers. This has the effect that it turns off hardware drivers who fear that their edge is now lost. The end result is less vendors willing to contribute binary drivers for much needed hardware, and in turn less adoption of open source software.

So, I recommend the following:

- Anyone committing modules to the contrib repository on Drupal agrees that the module is GPL.

- Anyone can license his/her module under LGPL, provided it is not in contrib repository.

- Drupal allows LGPL modules to be run under it.

This way, we don't preclude commerical use of Drupal, yet preserve the freedom for the contrib repository.

The modules I've contributed are GPL, fine...but if it ever comes to it. version 1.0 is GPL, and derived from an unlicensed 0.9 codebase, from which I will also (rhetorically) derive any commercial version.

That's why I personally don't see a reason LGPL modules shouldn't be accepted...it would eliminate a potential song-and-dance routine.

Setting status to fixed, since this is not a bug per se.