FLOSS License Proliferation: Still a problem
License proliferation in free-libre / open source software (FLOSS) licenses is less than it used to be, but it’s still a serious problem. There are, thankfully, some interesting rumblings to try to make things better.
Russ Nelson at the Open Source Initiative (OSI) wants to restart a FLOSS license anti-proliferation committee to address the problem that there are too many FLOSS licenses. He wants to set up a process to establish two tiers, “recommended” and “compliant”. There’s no telling if the work will be successful, but the basic concept sounds very reasonable to me.
Matt Asay counters that “Someone needs to tell the Open Source Initiative, Google, and others who fret about license proliferation that the market has already cut down the number of actively used licenses to just a small handful: L/GPL, BSD/Apache, MPL, and a few others (EPL, CPL)… It’s a worthy cause, but one that has already been effectively fought and settled by the free market. I would hazard a guess that upwards of 95 percent of all open-source projects are licensed under less than 5 percent of open-source licenses. (The last time I checked, 88 percent of Sourceforge projects were L/GPL or BSD. It’s been a non-issue for many years.) There is no open-source proliferation problem. Do we have a lot of open-source licenses? Yes, just as we have a lot of proprietary licenses (in fact, we have many more of those). But we don’t have a license proliferation problem, because very few open-source licenses actually get used on a regular basis. This is a phantom. It seems scary, but it’s not real.
Asay is right that “the market” has mostly settled the issue, but I think Asay is quite wrong that there is no problem. I quite agree with Asay that there is a very short list of standard FLOSS licenses… but there’s still a lot of people who, even in 2008, keep creating new incompatible FLOSS (or intended to be FLOSS) licenses for their newly-released programs. And although it’s true that “very few actually get used on a regular basis”, it’s also true that a large number of people are still creating new, one-off FLOSS licenses that are incompatible with many widely-used licenses. Why? I think the problem is that there are still a lot of lawyers and developers who “didn’t get the memo” from users and potential co-developers that new FLOSS licenses are decidedly unwelcome. As a result, new programs are still being released under new non-standard licenses.
I can even speculate why there are so many people still creating incompatible licenses, even though users and distributors don’t want them. A lot of new programs are developed by people who know a lot about their technical specialty, but very little about copyright law, and also very little about FLOSS norms (both in licensing and community development processes). So they go to lawyers of their organizations. As far as I can tell, many lawyers think it’s fun to create new licenses and have absolutely no clue that using a nonstandard FLOSS-like license will relegate the program to oblivion. (The primary thing that matters to a lawyer is if they or their organization can be sued; if the license causes the program to be useless, well, too bad, the lawyer still gets paid.) Indeed, many lawyers still don’t even know what the requirements for FLOSS licenses are - never mind that there are license vetting procedures, or that using non-standard FLOSS licenses is widely considered harmful. So we have developers, who know they want to collaborate but don’t realize that they need to follow community standards to make that work, and we have lawyers, who often don’t realize that there are community standards for the licenses (and their non-selection will affect their clients).
Let me give some specific examples from recent work I’m doing, to show that this is still a problem. Right now I’m trying to get some software packaged to more rigorously prove that software does (or doesn’t) do something important. I tried to get CVC3 packaged; it has “almost a BSD license”, and I believe the developer intended for it to be FLOSS. Problem is, somebody thought it’d be fun to add some new nonstandard clauses. The worst clause - and I’m highly paraphrasing here - could be interpreted as, “If we developers did lots of illegal activities in creating the software, you’re required to pay for our legal expenses to defend our illegal activities, even if the only thing that you did is provide copies of this software to other people, or used it incidentally.” Certainly that’s how I interpret it, though I’m no lawyer. When I brought this license text to Fedora legal, let’s just say that they were less than enthused about endorsing this license or including the program in the distribution. Indeed, CVC3’s license may make it too dangerous for anyone to use. After all, how could I possibly determine the risk that you (the developer) did something illegal? CVC3 also has another annoying incompatible license addition (compared to the BSD-new license), a “must change name if you change the code” type clause. Of course, it won’t compile as-is; the only way to compile it is to change the code :-). Here’s hoping that they fix this by switching to a standard license. CVC3 is not the only offender, either, there are legions of them. I examined Alt-Ergo, a somewhat similar program. It uses a FLOSS license, but it uses the remarkably weird and non-standard CeCILL-C license (this is even less well known than its cousin the CeCILL; according to Fedora it’s FLOSS but GPL-incompatible, and a GPL-incompatible FLOSS license is a remarkably bad choice). Third example - over this weekend I had a private email conversation with a developer who’s about to release their software with a license; the developer intended to create (as a non-lawyer!) yet another license with incompatible non-FLOSS terms. Which would have been a big mistake.
Frankly, I think Asay is being excessively generous in his list of acceptable licenses. The standard FLOSS licenses are, I believe, simply MIT, revised BSD (BSD-new), LGPL (versions 2.1 and 3), and GPL (versions 2 and 3), and possibly the Apache 2.0 license. All of these licenses have a very large set of projects that use them, are widely understood, have been deeply analyzed by legal experts, and yet are comprehensible to both developers and users. An especially important property of this set, as you can see from my FLOSS license slide, is that they are generally compatible (with the problem that Apache 2.0 and GPLv2 aren’t compatible). Compatibility is critical; if you want to use FLOSS to build serious applications, you often need to combine them in novel ways, and license incompatibilities often prevent that. As I note in Make Your Open Source Software GPL-Compatible. Or Else, the GPL is by far the most popular FLOSS license; most FLOSS software is under the GPL. So choosing a GPL-incompatible license is, in most cases, foolish. Which is a key reason I don’t include the MPL in that set; not only do these licenses have vanishingly small market share compared to the set above, but their incompatibilities make their use foolish. Even Mozilla, the original creator of the MPL, essentially no longer uses the MPL (they tri-license with the GPL/LGPL/MPL, because GPL-incompatibility was a bad idea).
Having a short “OSI recommended” or “FSF recommended” list of licenses is unlikely to completely solve the problem of license proliferation. But having a semi-formal, more obviously endorsed, and easy-to-reference site that identified the short list of recommended licenses, and explained why license proliferation is bad, would help. While those well-versed in FLOSS understand things, the problem is those others who are just starting out to develop a FLOSS project. After all, the license is chosen at the very beginning of a project, when the lead developer may have the least experience with FLOSS. Anyone beginning a new project is likely to make mistakes, but there’s a difference; just about any other mistake in starting a FLOSS project can be fixed fairly easily. Don’t like the CM system? Switch! Don’t like your hosting environment? Move! But a bad license is often extremely difficult to change; it may require agreement by a vast army of people, or those (e.g., organizational lawyers) who have no incentive to cooperate later. Yes, projects like vim and Python have done it, but only with tremendous effort.
The license mistakes of one project can even hurt other projects. Squeak is still trying to transition from early licensing mistakes, and it’s still not done even though it’s been working on it for years. These has impeded the packaging and wider use of nice programs like Scratch, which depend on Squeak. The Java Trap discusses some of the challenges when FLOSS requires proprietary software to run; when the FLOSS licenses are incompatible, many of the same problems apply. In short, when FLOSS licenses are incompatible, they cause problems for everyone. And when there are more than a few FLOSS licenses, it also becomes very hard to understand, keep track of, and comply with them.
Asay and Nelson have no trouble understanding the license proliferation issues; they’ve been analyzing FLOSS for years. But they are not the ones who need this information, anyway. It’s the newcomers - the innovators coming up with the new software ideas, but who don’t fully understand collaborative development and how FLOSS licensing enables it - who need this information. I don’t really mean to pick on Asay in this article; it’s just in this case, I think Asay knows too much, and has forgotten how many people don’t yet understand FLOSS.
Documenting a short list of the “recommended licenses” would be a great boon, because it would help those innovative newcomers to FLOSS approaches avoid one of the costliest mistakes of all: Using a nonstandard license.
path: /oss | Current Weblog | permanent link to this entry