How Many Open Source Licenses Do You Need?

jammag writes "Bruce Perens, who wrote the original licensing rules for Open Source software in 1997, notes that there are a sprawling 73 open source licenses currently in existence. But he identifies an essential four — well, actually just two — that developers, companies, and individuals need. In essence, he cuts through the morass and shows developers, in particular, how to protect their work. (And yes, he favors GPL3 over GPL2.) For his own coding work, he's fond of the 'sharing with rules' license, which stays true to the Open Source ethos of shared code yet also enables him to get paid by companies who use it in their commercial products."

Hi again

[Bruce Perens]

Hi Folks,

I happen to be at my desk again today, and can discuss this article, if any of you have questions or, more likely, comments :-)

If I write 30 responses, there will be a break. Slashdot locks me out for four hours after 30 postings from one IP.

Bruce

Replying to A.C.

[khasim]

you mean like this matrix

No. That doesn't show the differences between the licenses. Look at how many of them have the same answers in the same columns ... yet have different restrictions if you read the licenses.

Re:A question of values

[Bruce Perens]

Obviously you need a license that matches your values.

The purpose of my article is to get you to explore those values and select a set of licenses that really match them. Some of the people who select GPL do so not for Richard's given reasons but for business purposes. I would not want to mislead them that their values demand a "gift" style license which is less effective for their particular business purpose. And making Free Software under the BSD license is not incompatible with Richard's philosophy. Remember that Richard is against software being copyrighted, and BSD licensing is pretty close to abandonment of copyright.

Thanks

Bruce

Biased...

[synthespian]

The characterization of BSD, Apache, etc. as "gift" licenses just display Perens' bias.

These are licenses that allow you to work both in proprietary projects and open source projects at the same time.

The word "gift" implies the person does not have a job and is doing it for free when, in reality, the developer might be working for a company that would only use business-friendly licenses.

The real distinctions are: are you going to work for a project else who will demand that you give away your copyright and who will keep their right to fork it into a proprietary project. If the answer is yes, then, please do it. Just don't complain when you see your work being bundled into a proprietary fork while you have to keep convincing everyone that they must use GPL/viral licenses (which is easy to do if you're into the business of selling servers, like IBM, and you want to bundle Linux "for free" - which, simply put, is IBM's strategy against Sun Microsystems, obviously).

The GPL license, due to copyright laws, allows this dual-licensing, which basically means unequal rights for developers (those who hold the copyright and, thus, can fork it into a proprietary license, while demanding that everyone else stick to the GPL version).

If you want developers to have equal rights, i.e., they can do *whatever* I want (i.e., "freedom"), then don't chose the GPL, chose a license such as the BSD license.

Open source code is not a material resource; it is an information resource and cannot be "stolen" (as GPL zealots with faulty logic would have it) but only "copied."

Learn to recognize Linux PR when you see it.

Re:Hi again

[Anonymous Coward]

I'm sure that Bruce doesn't need to get hairballs.

Next thing you know, you're in a high profile meeting, and you start hacking up a big glob of fur. It's just isn't professional. Never mind the being-on-all-fours with an arched back as you hack this glob of hair up.

Unless you're talking about one of those hairless cats.

Re:Still seems to me a little simplified

[Bruce Perens]

One camp basically says "I only want your sources if you distribute the software in binary form", while the other basically says, "I also want them if you run them on your servers." Over-simplified, but you get the idea.

I think it's more a matter of history. There was no SaaS when the GPL was written, or the GPL would have addressed the issue. In the first discussions leading to GPL3, way back in 2004, we were talking about addressing the "ASP problem" in GPL3, not the Affero version. Further GPL revisions stick to the basic principles of the first.

It really breaks down into "sharing is possible" and "sharing is mandiatory", and everything else is an elaboration on that theme.

Thanks

Bruce

Re:GFDL versus CC-BY-SA; noncommercial licenses

[Bruce Perens]

I agree that GFDL is a botch. I used the Open Content License (otherwise mostly unknown today) for my own books. My problem with Creative Content is that it's one name over a broad spectrum of incompatible licenses that have few rights in common other than the right to read the text at all. Can/can't distribute, can/can't do it commercially, can/can't modify, and so on.

Re:Has The GPL Ever Been Proven

[new-black-hand]

That might be right, because Freshmeat is mostly desktop applications and small utilities.

If you look at more recent projects, especially web-related projects (such as web frameworks) there is an increasing trend towards more permissive licenses. Looking at frameworks (from http://en.wikipedia.org/wiki/List_of_web_application_frameworks [wikipedia.org]):

RubyOnRails: MIT
Django: MIT
CakePHP: MIT
Codeigniter: BSD
Zend Framework: BSD
Symfony: MIT
Turbogears: MIT & LGPL

jQuery: MIT & GPL
Dojo: Academic free
Prototype: MIT
Script.aculo.us: MIT
Y! UI: BSD

All the apache javaEE projects: Apache

Out of the top projects on GitHub, I could only count two that were GPL'd: http://github.com/popular/forked [github.com]

So out of all of those frameworks, which together cover the vast majority of web applications and web services being built today, not a single one of them is GPL only.

So web projects are very much trending away from the GPL - and the reason why is what I discussed in this thread previously ie. allowing companies who build on top of these products more flexibility. The developers, by choosing a more permissive license, have elected more flexibility for users, and thus potentially more popularity, over a sharing restriction.

Re:GFDL versus CC-BY-SA; noncommercial licenses

[mlinksva]

The http://en.wikipedia.org/wiki/Open_Content_License [wikipedia.org] is/was a copyleft license, incompatible with both the FDL and CC-BY-SA, hence is a really bad idea for use with new works (but kudos for using it long before alternatives existed). The author has long recommended [opencontent.org] using one of the CC licenses instead.

Creative COMMONS deprecated its two almost never used licenses which did not permit at least global noncommercial verbatim distribution, see http://creativecommons.org/weblog/entry/7520 [creativecommons.org]

Incompatible licenses within the CC suite is of course a valid criticism. For those who get the requirements of the OSD/free software, the solution is to stick to using CC-BY and CC-BY-SA, which CC calls out with approved for free cultural works branding [creativecommons.org].

Disclaimer: I currently work for CC.

Re:Still seems to me a little simplified

[T-Ranger]

Yes there was SaaS when the GPL was written. Significantly before it. Or at least attempts at it.

The Multics project has the very specific purpose of making computing resources a service, just like phones and electricity. CompuServe was one specific example, setup in 1969, to provide time-sharing services to external companies.

Arguably, pre-1975, SaaS was the default, not the exception. Computers were rented, perhaps on your premises, and tended to by vendor techs.

Anyway, this mantra of "we didn't know about it" really makes [GPL supporters] look stupid. I mean really, are you trying to tell me that RMS had never heard of Multics?

Re:Hi again

[Tacvek]

From his wording, it sounds as though this was simply just an out-of-tree kernel driver, which was not highly maintained, (Out of tree kernel drivers require an enormous amount of work to maintain, so they often don't get maintained properly. This is why out of tree kernel drivers are frowned upon. Drivers in the kernel tree automatically have basic maintenance (updates to code when API's change), such that only minor work is needed to maintain the driver.)

This really is not be a license issue, or anything that you could do much to fix (except perhaps pester Digium to get the driver into the kernel tree.) It may be worth reminding companies that working with the community when they use or modify Open Source software can save time and effort in some cases. Kernel drivers are a good example of that, but far from the only one.