The Open Source initiative has, to date, approved 73 licenses. How many do you really need? If you're a company or individual producing Open Source software, no more than 4. And you can get along with just 2 of them.
But the fact that there are 73 licenses is a problem. Many of those licenses are incompatible with each other. To understand the legal implications of mixing software under two of those licenses together in the same program, you'd have to learn 5256 different combinations!
And the worst thing about this is, it's my fault! Well, partially. When I wrote the rules for Open Source licensing in 1997, as a policy document of the Debian project, not many people took what we then called Free Software seriously, and it was unthinkable that 73 different licenses that complied with my Open Source Definition would ever be written.
Understanding licenses isn't really an Open Source issue. Most software is copyrighted and under some sort of license, and the licenses on proprietary software are much more pernicious than those on Open Source.
But most companies, even large ones, aren't yet completely able to cope with the implications of software licensing. At your next departmental meeting, ask how many people have clicked Yes on a license of a web site or software application while at work. Then, ask how many of those folks are authorized to enter into a contract on behalf of the company.
See the problem?
To understand how many Open Source licenses you really need, it's important to set some goals. First, the licenses must all be compatible with each other. There's no point in licensing your own company's Open Source so that its not compatible with other Open Source from your company. And second, the licenses should fulfill the various different business purposes for Open Source.
Open Source has business purposes? If you're a business. The two main ones are:
To get everyone possible to use your software to do things the same way:
For example, if you're creating a standard that you'd like everyone to use regardless of whether their own software is Open Source or proprietary. Some years ago, a manufacturer of circuit design software created a standard file format for circuit designs, and distributed Open Source software that circuit chip foundries could use to read that format under the BSD license, which has no significant restrictions.
Because the company's competitors could also use the same format with their software, the foundries had an incentive to implement the format and simplify their operations. Thus, the circuit design software manufacturer was assured that their software's output would be usable with essentially all chip foundries.
To create a partnership for software development, where everybody shares in the work:
About 14 years ago, I created the Busybox embedded systems toolkit for Linux. I put in a month's worth of evenings on the project, which was to build a command-line environment that would fit on a single floppy disk, for the Debian GNU/Linux distribution's installer. I released the product under the GPL license.
Subsequently, embedded systems companies adopted Busybox because doing so gave them some time-to-market advantage in putting their product offerings together: they wouldn't have to re-do my work. Because I'd used the GPL, their extensions to my software had to be under a GPL-compatible license too, and had to be made available in source-code form.
The various embedded Linux companies shared that work with each other and the entire Open Source community. At least 5 person-years of work have been added to that program, and all of that work is available for anyone to use. Had I used a license without the share-and-share-alike provisions of the GPL, those embedded companies would have kept their additions to themselves as proprietary software. And that wouldn't have done them much good, because Busybox wasn't business-differentiating for those companies.
So, companies that want to share, but don't want their competitor to run away with their work without themselves sharing, are well advised to use a license like the GPL.
So, from those two business purposes, we can arrive at the sorts of licenses we need:
1. A gift license:
This is as unrestrictive as possible, which allows the licensee to combine the work with either Open Source or proprietary software.
2. A sharing with rules license:
This says be my partner even to companies you might not always trust, for example your worst competitors in the market, because if they improve the product, they have to share.
3. An in-between license:
This is for making software libraries under the sharing with rules paradigm, but which are usable in proprietary software.
With these three sorts of licenses, we can fulfill most of the different business purposes that there might be for an Open Source development.
Individuals and Open Source Projects
The motivations for individuals, rather than companies, are somewhat different. They're important because the largest company working on the Linux kernel, in a recent survey, was No Affiliation. Individuals play key roles in many important Open Source projects.
Some individuals are content to give all the Open Source software they create away as a gift. Not me. I use gift licenses when I'm paid to do so, and sharing with rules licenses otherwise.
This is mostly because I don't want to be the unpaid employee of some company that uses my work and gives nothing back to the Open Source community. I want the people who extend my software to give their extensions to the world to share, the same way I gave them my original program. So, my payback for writing Open Source is that my software drives a further increase in the amount of available Open Source software, beyond my individual contribution.
There's another motivation for use of a sharing with rules license in the software I'm currently building: dual licensing.
Companies that want to combine my new software with their own proprietary product, without having to comply with my sharing with rules license, pay me for a commercial license. That license doesn't require any sharing, and allows my work to be combined with their commercial product. But they can get the same work for free, as can everyone, if they can comply with the sharing with rules license.
Thus, I am paid to make Open Source, and can give it away at the same time. Had I used the gift license, companies would have no motivation to pay for my commercial license.
Dual licensing is a bit more complicated than the usual Open Source development, because the company that offers dual-licensing needs to own the entire copyright to the program, or the right to re-license all contributions to the program. It's necessary to give contributors some sort of incentive, or they generally aren't very willing to sign over their copyrights or the right to re-license their contributions.
So, we have our three sorts of licenses. Let's start to map those to real licenses. My preferred three are:
1. Gift license: The Apache License 2.0
This is similar to the MIT and BSD licenses, but provides a little more protection from software patent lawsuits to the Open Source developer.
2. Sharing-with-rules license: GPL 3
Descended from the GPL, the most popular Open Source license, this license is updated to deal with the vastly larger amount of copyright and case law that exists today.
3. In-between license: LGPL 3
This is very similar to the text of GPL 3, so that you don't need to learn another license.
All three are compatible with each other, according to FSF and other authorities.
At this point, some contingent of the audience has just thrown up their hands and shouted EEEEEwwww! Why's he using GPL3?????
GPL3, unfortunately, gained a bad reputation in some camps because it is ambitious, and because Linus Torvalds was uncomfortable with it. Linus' discomfort stems from a personal issue, so I tend to discount him in this case.
One of the most ambitious things about GPL3 is that it attempts to prohibit DRM. Hmmm, did you notice that announcement that iTunes isn't going to use DRM any longer? Between the debut of GPL3 and today it seems that more people have realized that DRM isn't such a great idea.
The other ambitious thing that GPL3 does is that it insists that the software in an embedded device be modifiable in situ. This is so that Open Source operating systems are still possible in the future.
You see, we need computers to run them on. Today, we can get cheap motherboards for desktops, upon which we can install Linux and other Free Software. In the future, people won't use desktops as much as they use embedded devices like cell phones and web slates. So, we want to make sure that we can run new Free Software on embedded devices that already come with Free Software out of the box.
So, those two big ambitions of GPL3 are worthy of praise. But the biggest advantage of GPL3 is its legal solidity. During the creation of GPL3, literally dozens of attorneys, from the world's largest companies, reviewed every word of the license. No license anywhere has had 1/10 of the legal review that went into GPL3.
So, you can be reasonably sure that it will perform in court the way it's intended to work. Managing dozens of attorneys is difficult, but Richard Stallman was equal to the task, keeping the result in line with the ethos of Free Software.
A lot of companies like the MPL license, from the Mozilla project, better. But MPL actually only fits in the place of the in-between license; its terms aren't strong enough to provide the sharing-with-rules environment that is necessary to protect some products.
My main problem with MPL is not the license itself, but the very many licenses that have been derived from it, each with its own little differences, making the combinatorial problem of Open Source licenses significantly worse. FSF was smart to copyright their license text and maintain that there would be FSF-approved derivatives only.
It's easily possible to put together another list of three licenses that satisfies the requirements above. But this is the one that I think that most companies, and Open Source projects, should use.
I'll catch a lot of flack from people who are partisan to the BSD license, who are sticking with GPL2, who like one of the other 70, etc. But those licenses do similar things to the ones above, while being less up to date regarding how they cope with today's environment of patent and copyright infringement and all of the case law that has built up around it. When GPL 2 was written, there wasn't an Internet as we know it today, there weren't MP3 players, and the most complicated input device in most people's homes was a touch-tone phone.
If we all build our own sets of three licenses, we'll still have that combinatorial problem when we go to mix our Open Source with that of other people. We'll still have 70 different licenses, many of them in wide use. You can help to solve the problem.
Will you join me?
I said you needed 4 licenses at most, and have only discussed 3. The 4th you might consider is Affero GPL3.
This license is specifically engineered to keep Google from running away with your product without sharing their improvements to it. Well, actually, it deals with the software as a service problem. The GPL class of licenses does not require that anyone share source code until they actually distribute the software. But Google doesn't distribute software, it performs it on its own site.
So, a license had to be written to cope with the SaaS phenomenon. If you want to keep the license count down to 3, you can use Affero GPL3 in place of GPL3. The text of Affero GPL3 is very similar to that of the plain GPL3, so again, you don't really have to learn an entire new license.
So, my set includes two base licenses: Apache 2.0 and GPL3, and two derivatives of GPL3: LGPL3 and Affero GPL3. To use them, you'll have to learn two licenses, and two sets of variations on one of those licenses. All of them are compatible with each other. Suddenly, Open Source isn't as complicated as those 5,256 combinations of two of the approved 73 licenses!