Open Source Licensing Issues
msuzio writes "Web Techniques has a good editorial column this month on Open Source licensing issues. They focus on the difficulties in resolving both a single license (GPL, BSD, Apache), but also the deeper tangle of how to handle multiple licenses mixed into one project (a piece from GNU, a piece from Apache, etc). I think this issue will continue to dog efforts to bring together multiple open-source components, both in open-source and commercial projects using open-source."
When all else fails, use your common sense.
1) Use the license YOU want to use on your own projects. If you don't like copyleft licenses then don't use them. If you don't like unrestricted licenses then don't use them. Easy, isn't it? But by all means, don't go creating your own new license. There are enough good ones out there that it isn't necessary. There are still some licensing niches to fill in the OSS hierarchy, but I doubt your project fits that bill. The BSD, MIT, GPL, LGPL, MPL, QPL and Artistic licenses are sufficient to meet your needs.
2) Don't get religious over licensing. The well known licenses all have their place. As soon as you say "I will never use the BSD/GPL/QPL/whatever license" you will immediately run across a situation where you will need it. I am personally not fond of copyleft, but if I were to release a commercial open source product that faced competition, you can bet you bippy that I would seriously consider using the GPL. Likewise, don't let license bigotry get in the way of your helping out on other people's projects.
3) Assign your copyrights over to the author. Don't insist on holding on to the copyright for your bug fixes and minor contributions. That's so egotistical as to be stupid. You will get mentioned in the credits, so don't worry about it. You will make the author's life so much easier. If your are the original author or project maintainer, then insist that all copyrights be assigned to the you or the project. If you want your project to be "community based", then seriously consider assigning your copyright to the FSF, creating your own non-profit org, or placing it in the public domain. Do you really want the submitter of a five line bug fix to be in control of all licensing decisions from here on out?
A Government Is a Body of People, Usually Notably Ungoverned
Perhaps some day, people will understand that the GPL does not make code free. Freedom is not something which can be forced, for if it is forced, it is not freedom.
-Nev
As a first approximation, you should think of the software produced under the various licenses as falling into separate equivalence classes. If you discover a "leak" between two equivalence classes that lets you use the code or components from different classes together, well and good -- but don't assume that things will work that way until it has been demonstrated.
To paraphrase another poster, decide in advance which equivalence class you want your code to be in. That tells you which license to use.
Notice that this is not notably different from proprietary software. All of Sun's secret code falls into an equivalence class separate from all of Microsoft's, and there's no a priori reason to expect that you can freely combine the two.
What I don't get is why so many people hear "open source" and think they have an intrinsic right to use the code however they please. If you use code under a license, you are bound by that license just as surely as you are bound by the controls on code coming out of Sun and Microsoft.
Granted, this forces a duplication of effort between equivalence classes. If you are working in Class A and need a widget that is only available in Class B, you have to re-implement it in your own class.
Still, the mere existence of the "open" classes has been a huge boon to code reuse, and as Open Source catches on, the number of members of each class continues to grow phenomenally. Regardless of which "open" class you release your code into, you are participating in a sharability far beyond anything you can participate in with proprietary code.
So pick a class that's large and growing, and that has a license that suits your ideals, and go with it. But don't waste your time whingeing about not being able to steal stuff out of the other classes. A license is a license, and you should take it seriously. No one promised you unrestricted access to anything you might happen to want. You might as well complain about not being able to use Microsoft's source code in your own project.
--
Sheesh, evil *and* a jerk. -- Jade
I used to use the GPL for my software because I liked the idea of having control over my code. But two points came up during the KDE/QPL dispute that made me change my mind.
1) The idea that free software should only be reused in free software is attractive. But the viral nature of the GPL means that a line of code that is copied from one project to another contaminates other code that might be used in a third project. That's the intent of the GPL - to eventually encumber the entire free software pool. To me, it's distasteful that a line or two of code ties the hands of developers who have written a huge project of their own and who may never have seen a line from the original GPL project.
2) And it's not even up to the original author. IIRC, there was no case where an author of GPL code objected to its use in KDE. (RMS's "forgiveness" notwithstanding.) As soon as the words "GPL violation" are used, the Slashdot/Technocrat/FSF lynch mob heads out, apparently in the belief that since they're Members Of The Community, they somehow get to act as the aggrieved party. I'd prefer to keep control of my code, but I'd rather see it wind up in Windows than have it used to ruin a well-intentioned project.
In my estimation there are basically 4 license schemes that would fill just about every niche.
1. BSD - license of choice for authors who beleive that anyone should be able to do whatever they want with free software they create.
2. GPL - license for authors who wish to garantee that all dirivative works based on their code also be relesed under the same free software license.
3. LGPL - license for people who wish to allow diferently licensed software to be linked against their code, otherwise similar to GPL
4. GPL/dual-license (e.g. qt, new mozilla license) - software licensed under GPL, but with declared provision for use not normally allowed by the GPL. This scheme works well for authors who wish to support free software, but also want to add flexibitity in licensing, and even a possible profit stream.
I can't posibly think of reason anyone whould want to use a license such as the artistic license, or a custom license, other than to be perverse, and confusing.
You don't need to find a judge fluent in assembly, you need to find an expert willing to testify that it is likely that the source code was stolen. The judge can rule that source code from both parties be turned over to the court and the court can then make an informed decision about whether source code was stolen or not.
Linux is probably the first real kernel written by volunteers - BSD was written by people working on a government grant, and is derivative of ATT Unix, although later modifications are contributed by volunteers. Why do those volunteers feel good about writing free code? Because abuses are prohibited by the license. Otherwise, they'd be dupes, unpaid employees working for someone else who makes all of the money on a product and puts economic locks on that product using proprietary software, cutting out the free contributor. In that case, the free code would actually be weakening the free software movement by playing into the abuser's hands. That's why more developers choose the GPL. And it's the developers who matter here - no code? Then there's little prospect for users.
The choice is simple here, at least for me. I write BSD-licensed code when someone else is paying me to do so and they insist on the BSD license. I write LGPL or GPL-licensed code the rest of the time, and I feel good about that it's doing for the free software movement.
Thanks
Bruce
Bruce Perens.