Recently, I got more interested in the subtleties of different open source licenses. Luis Ibáñez pointed be to some books about that.
One is “Open Source Licensing, Software Freedom and Intellectual Property Law” by L. Rosen. This book is written in the context of US law, but lot of it should be applicable in international contexts. Beyond the basis, I discovered some pretty interesting stuffs. Some are summarized here, but referring to the original book would be good idea.
The first one was the difference between copyright law and contract law. Basically, copyright prevent anybody from making copies of your program, the open source license is the thing that will allow other people to do so. The copyright law is enforceable only by the owner of the copyright. That mean that somebody creating a derivative work won’t be able to enforce the license (as he doesn’t own the copyright). To be able to do so, it must be done under contract law. Thus, a contract must be presented, considered and accepted by the user: click-wrap method (accept button on a website, at the installation, etc) are acceptable.
Few of the most popular licenses (BSD, GPL for example) explicitly mentioned that. Even, the GPL is intended to be applied only as license not a contract.
The possibility of dual licensing is also well explained. I was familiar with the example of Mysql where companies are ready to pay to avoid the obligation of the GPL. But the example of Ghostscript was more unusual: they use the concept of scheduled licensing, where companies pay to have the product one year before the open source version.
Another interesting part of the book is about the open source license with a commercial origin (CPL, OSL and AFL) and particularly their patent defense strategy. The idea is to say “you get a license to use, copy, etc this software, but if you sue us for any patent infringement, this license is revoked”. That work for big corporations with a significant patent portfolio, much less for small open source projects. That’s amazing to see how these big corporation are building an arsenal of patents mostly as a deterrent.
Related to the patent in softwares, the FSF came out with a short movie illustrating the issue: Patent Absurdity. In this movie, one analogy is particularly striking: what would have happened if the patent had been available for music in the 1800s ? As the end of this movie, they illustrate the concept with a Beethoven symphony:
(Note: I sure hope this use of the video come under fair use, as I don’t think it can come under the CC-non derivation as I extracted only part of it. Let’s see if it gets me into trouble with the FSF…)
To come back to the license issue, one question is “what license to use?” Obviously, compatibility with the other softwares you’re planning to work with is an important consideration. The question of compatibility comes both ways: can you use this particular software and can you be used by this software? Of course, I’m not really being precise here: the issue is not really when using the software but redistributing it (but that the whole point of an open source license as they all guaranty that you can use the software with complete freedom anyway).
In most cases, the choice ends up being between an academic license (such as BSD) and a reciprocal license (GPL is one). If the philosophy of the GPL is laudable (every software would end up being shared), it is also very controversial with some even using the misleading term of viral (note: a virus is rarely something you can choose not to get, for a license, you can). On one hand, I wouldn’t want to have my own bugs served me back in a closed source software preventing me to fix them. Also, if somebody uses my work to make a good, fun, useful program, I’d hate not to be able to have a look in the inside to understand how they did it. But on the other hand, the controversy and misunderstanding around the GPL could slow down the progress of an open source project. This point was illustrated by Paul Ramsey on this post: On the road to Damascus… GPL to BSD. The license is not all what matter in an open source project. The community around it is a very important asset and will more efficiently compel people to give back their improvements to avoid the hassle of keeping these improvements in synchronization while the project progress.
Patents and licenses are only part of the issue as the recent problem in ITK with the sparse linear solver highlighted recently. In this particular case, the problem was that some code relied on algorithms copyrighted to the ACM (that’s what happen when you publish a paper in ACM). The ACM copyright precludes uses for commercial purposes. As such, the ACM copyright is incompatible with any open source license (as they all guaranty No Discrimination Against Fields of Endeavor) at least without an explicit permission from the ACM. Apparently, request from ITK to the ACM for the inclusion of these particular algorithms were not successful. At the end, another algorithm was included requiring a translation from Fortran to C++. That’s quite an unfortunate and (from a technical point of view) unnecessary duplication of efforts, wasting resources (i.e. developer time) that could have been better employed (ITK objective is to provide image analysis tools in the medical domain).