Dual-licensing is a popular Open Source business model, especially using the (very restrictive) Gnu General Public License (GPL). Popular opinion, as reflected (for example) in the comments on this blog posting, says that it’s either forbidden or highly questionable to do things like linking non-GPL things with GPL things, so enterprises will have to buy a dual-licensed version (instead of using the free GPL version of the software) to take advantage of closed-source enterprise components.
The case of MariaDB
I wonder if popular opinion might be wrong.
Consider the GPL software package mentioned in the blog posting linked above: MariaDB, a fork of the Open Source MySQL database manager. Because the maintainers of MariaDB don’t own most of the copyrights on the code, they cannot dual-license it; as a result, some people believe that the GPL forbids using closed-source MySQL storage engines such as ScaleDB with MariaDB.
Distribution, not use
Unlike closed-source licenses, however, the GPL exists primarily to control how people distribute software packages, not how people use them. Section 0 of the GPL makes this fairly clear:
Section 0: “Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted…”
The non-normative FAQ for this version of the GPL goes even further, allowing private modification of a package outside the scope of the GPL as well:
A company is running a modified version of a GPL’ed program on a web site. Does the GPL say they must release their modified sources?
The GPL permits anyone to make a modified version and use it without ever distributing it to others. What this company is doing is a special case of that. Therefore, the company does not have to release the modified sources…
Non-GPL plugins and personal use
So, with that in mind, let’s start with the personal-use case. I have an unmodified GPL-licensed copy of MariaDB and a properly-licensed copy of ScaleDB. I do not need to modify anything in the MariaDB distribution to use ScaleDB — I just have to drop ScaleDB into the appropriate directory and edit my personal config files to tell MariaDB to use it. Since I’m just running MariaDB, not modifying it, am I even bound to accept the terms of the GPL? It doesn’t look like I am.
Non-GPL plugins and aggregation
Now, let’s take this a step further. What if distribute a DVD-ROM that happens to have both MariaDB and ScaleDB on it? I comply with the GPL for MariaDB (e.g. include a copy of the GPL and the MariaDB source code), and have permission from the copyright holder to include ScaleDB. There are no modifications to MariaDB at all, even in the configuation files: just two separate packages that happen to be stored in different directories on the same DVD-ROM. Am I in violation of the GPL now?
And what if I decide to add a script to automate configuring MariaDB to use ScaleDB as a third, independent software package? The script is an entirely separate piece of software, and includes no GPL code at all. I still don’t modify MariaDB or bundle ScaleDB with it in the same package, but I provide a tool that someone can use to do so (they could also use the tool if they obtained both packages from other sources). Now is there a GPL violation?
So I end up with a redistributable DVD-ROM that allows a user to install a GPL program with a closed-source, plug-in storage engine for private use, and I don’t think I’ve violated the GPL or even wandered into any grey areas. What does everyone else think?
I too believe that what the user does with two separate pieces of code is their own business under GPL2. I believe that GPL3 goes a bit further, but MySQL is under GPL2. So I believe that the two can work together without an OEM license. However, your idea of a script to combine the two gets a bit more gray. Compare this to the litigation against Napster, versus VCRs. The VCR enabled copying copyrighted materials, but was OK because it had other legitimate purposes (same with photocopy machines). Napster, since it had very little practical usage for anything other than distributing copyrighted music (which is illegal) was sued to death. So can you hand a user a script for combining GPL and non-GPL, whose sole purpose is to circumvent GPL? I’m not sure, no good case law on that one that I’m aware of, but I would avoid it. I believe that there are layers here. If you use dynamic linking versus static linking, that creates a degree of separation. If the storage engine supports other databases, that provides more separation regarding the two acting as a single product. There are things like this that help to create legal separation. Our understanding is that it IS doable.
Interestingly, Michael Kay wrote something similar in his blog a week ago. Here’s the link:
Fortunately I’m not in a position where I need to worry about the GPL right now, but I’ll be interested to see whether some kind of consensus arises out of these musings.
Mike: I agree that an installation script would be an obvious target for something looking to sue, but I doubt they’d succeed: unlike Napster, such a script would simply automate something that a private user is allowed to do anyway, and it itself would contain no GPL code.
Paul: Thanks for the link. I don’t follow Michael’s blog, but I should, especially since we’re old war buddies from the early XML days, and Saxon actually started from SAX. It’s interesting that Michael, coming from the supplier side, also sees the cracks in the GPL dual-licensing model. Perhaps the whole thing rests on a GPL FUD campaign that could collapse out from under the dual-licensers at any time.
Another consideration is that the language of the GPL was intended to prevent people from distributing a GPL application that required a closed-source library to run, since that would just be a Trojan horse for vendor lock-in. An optional closed-source plugin is different: it might add extra functionality, but you can easily use the FOSS application without it. Of course, I’m sure that Richard Stallman would love to block that, too!
I do think that the script is on the red zone and not mere aggregation, at least if you’re on GPLv2. Once you package everything in a neat installer (and modify the code appropriately to automate the interaction) then the plugin is not a plugin anymore, it’ a new package. As long as the client sees the package as one complete package, then it’s one package. The more you amend the code to practically interface easier with the closed-source app, the more it would be in violation of the GPL.
I’d say that if you want to combine the two, one installer is not the right option. You can either relicense the ScaleDB to comply with GPL or maybe consider providing it as a SaaS and charge for the use (which is allowed by GPL).
[Decent Disclosure: I’m a copyright attorney and I represented the plaintiff in Jinchess v. IChessU, the first Israeli GPL enforcement suit, the case was quite similar, but there were some amendments in the original code, that made the distribution seem like one package (one windows installer, f.e)]
Jonathan: Thanks for the case reference. Unfortunately, the 2006 Slashdot article you linked to didn’t say how the case turned out. Is the final decision online? You mentioned that the case also involved code changes to Jin Chess (presumably to support the closed-source software).
I wonder if it would make a difference if the install script were the primary installation mechanism or not — e.g. the DVD-ROM simply installed MariaDB by default, but there was a separate script (or screen) that allowed you to add in the closed-source ScaleDB.
As a second option, what if the DVD-ROM didn’t distribute the GPL software at all, but configured the Windows installer to download it automatically, with an explicit prompt (e.g. “Would you like to download and install MariaDB”) followed by a window where the user had to click “OK” to accept the GPL?. In that case, no GPL software touched the DVD-ROM, so in my non-legal opinion, it looks like the distributor is not bound by the GPL.
The general view is that you can’t create a combined work containing both GPLed and closed-source components and distribute it, because that violates the GPL requirement that any derivative work of a GPLed work be itself a GPLed work. Some people deny that such a combination counts as creating a derivative work. If we set that view aside, though, then distributing (by whatever method) the work in two pieces, the GPL piece and the closed-source piece, with the clear expectation that those who receive it will combine them, is constructive distribution of the combined work. By analogy, if it were forbidden to sell salt, dissolving your salt in water and then claiming that you only sold sodium ions and chloride ions (even if you separated them into two bottles) would not save you from the frown of the judge.
I am not a lawyer; this is not legal advice, but it is not the unauthorized practice of law, either.
The case was settled out of court and both parties were pleased, you can see The press release here (there were also a few articles, but they went on and analysed the settlement, which is something I’m prohibited on doing as a counsel).
I (personally) think that if it were a windows installer (or bash script) downloading the package as a “dependency” (same as a .deb package) and integrate them, this would be a problem. If we’re talking about two separate installers that are meant to install the software as a whole, I think that the aim is not mere aggregation, but a single distribution.
I’d highly recommend to avoid it, though I’m not 100% certain it is in violation of the GPL.
Here is how it works for us:
You download MySQL code, it has a storage engine interface. Then you download an open source interface that enables MySQL to leverage the services provided by ScaleDB and other storage engines. You compile these together.
ScaleDB is a separate application (sold in binary form) that is accessed by the now compiled MySQL application using dynamic linking. We consider ScaleDB to be like a database storage service called by MySQL, much like a file system or network file system.
There is a precedent whereby MySQL acepted the BSD license for such a connector provided by IBM that leverages the services of IBM’s DB2. See details and MySQL counsel’s approval here: http://bugs.mysql.com/bug.php?id=44172
Based upon the facts that:
1. MySQL and ScaleDB are compiled seperately;
2. They utilize dynamic linking a la an operating system call;
3. The connector code is open sourced;
4. MySQL leverages these services independently, meaning it can also leverage other storage engines using this same approach;
5. ScaleDB will provide similar services to other databases (possibly upon first customer ship);
6. There is a precedent of IBM doing this with DB2 (using a BSD-style license) and Sun legal blessing it.
We believe that it should be clear that they are two separate and independent applications. Thoughts?
I think that you should go into further details as for the dynamic linking. Actually an OS call might make it ok, but I’m not certain.
The two applications (the mySQL and the engine) are ok, as they are both open-source and GPLed (actually, doing it without installation is putting it on the OK zone anyway) the problem is with the binary: If it’s sold separately, and installed separately, then it’s most likely ok. As long as it’s not distributed together as one application and contains all the copyright notices, I think that it isn’t in violation of the GPL.
You should also differentiate between BSD and GPL.
Now the question is whether anyone is distributing an installer that automates this process after the purchase of ScaleDB, which might incur liability on him (but not you).
And another thing,
Sun mentioned that they don’t have any problem with IBM’s BSD license on DB2 as it allows them to distribute DB2 under the GPL license (and not vice-versa), not because DB2 was proprietary.
Pingback: Warum Piratenpartei? Hierzu Lawrence Lessing | Linux Datenschutz Politik
Pingback: Warum Piratenpartei? Hierzu Lawrence Lessing: | Linux Datenschutz Politik