Free Newsletters :

Bruce Perens: How Many Open Source Licenses Do You Need?: Page 2

Posted February 16, 2009
By

Bruce Perens


(Page 2 of 3)

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.

Next Page: A Fourth Open Source License to Consider


Page 2 of 3

Previous Page
1 2 3
Next Page



Tags: open source, Linux, software, GPL, policy


0 Comments (click to add your comment)
Comment and Contribute

 


(Maximum characters: 1200). You have characters left.