Bruce Perens and the OSI board
Posted Mar 24, 2008 18:30 UTC (Mon) by
BrucePerens (subscriber, #2510)
Parent article:
Bruce Perens and the OSI board
Jake, you should point out that the famous license proliferation committee that refused to seat me finally was not able to take any action regarding license proliferation.
Also, I'm disappointed that you did not publish much of the interview we had, it was a lot of work for me. Here are parts of two emails some will find relevant:
I really was afraid that they could vote in a Microsoft representative, next year if not this. After all, Matt has Microsoft giving the keynote speech at his "Open Source In Business" conference, and OSI is being so close-mouthed about this election that nobody knows who the other candidates are, or even the date of the election. But Mike Tiemann assures me they aren't considering MS, and Matt says he's the only one who actually did consider Microsoft (interesting the way he admits it while denying its possibility).
Jake Edge wrote:
You have mentioned the four licenses that would take care of all open
source license requirements, what is the status of those? Have you
specified them somewhere so that folks can look them over, etc?
I've been giving my Open Source Governance consulting customers this for some time, minus the political discussion because it doesn't apply to them, but I haven't published it.
First, the goals:
Meet most business (and non-business) purposes of Open Source. I go into the purposes in explaining the licenses.
The licenses must be compatible with each other, so that all of your projects and their derivatives can be mixed with all of your other projects and their derivatives.
Protect yourself. The most pressing need to protect yourself, and Open Source in general, is regarding software patents. The need to protect yourself is illustrated best by the JMRI (Java Model Railroad Interface) case. The JMRI developer was using an Artistic license. A manufacturer of model railroad throttles incorporated the JMRI code into his product, and then sued the JMRI author for patent infringement, seeking to prevent that developer from distributing the Open Source to anyone who wasn't using that manufacturer's product. The case hasn't gone entirely well for the JMRI developer because the Artistic license was legally weak. So, if you don't want to be taken advantage of by unsavory characters like that, you'd better have solid patent language in your license.
Essentially, you need these licenses:
Gift: This license has essentially no strings other than protecting the developer from patent suits by his own users regarding his own software. You use it when you want people to use their software in both proprietary and Open Source code, and you don't want them to worry about the license. For example, if you are trying to push a standard API layer for some task, you might distribute the example code to handle that API under this license so that everybody can use it in both proprietary and Open Source software.
Sharing with Rules: This license acts to keep all implementations of the software free by using a strong "reciprocal" provision. If you make a derivative work, you have to give everybody the source code, and the rights to modify, redistribute, use, etc. This is a very important license for businesses that want to make money through dual-licensing, like MySQL. They have the GPL, and then a commercial license that they sell to anyone who doesn't want to have to GPL their derivative work (I'm ignoring issues of MySQL's server-client nature and how the GPL applies to that for the purposes of this example). It keeps your competition from running away with your product, by binding them to be your partner in development. In the volunteer developer community, a strong reciprocal license is often preferred by developers whose motivation is to build up Free Software rather than to assist proprietary software.
In-Between: Something between gift and sharing with rules, to require a derivative work of a module to have reciprocal provisions while allowing that work to be bound into a greater product that is proprietary. LGPL is the most-used example of this. It motivates public cooperation from proprietary developers,
Software-as-a-Service: The Affero GPL is an example of this, so is the Socialtext license. They are kludges to get around the "ASP problem", the problem of works that are derivative of a reciprocal license but are performed rather than being distributed. They help some vendors maintain a dual-licensing paradigm while producing a software-as-a-service product.
You can achieve most purposes in Open Source with this list.
The political part is which licenses you pick, not that you pick licenses to do these things. To illustrate, suppose you pick this set:
Gift: BSD
In-Between: GPL with exception.
Sharing-with-rules: GPL
Software-as-a-service: Affero GPL.
This gives you a working set of licenses, pretty compatible with each other, and the text of three of them are very similar so there are really only two licenses to understand, and they have the advantage that they are in very broad use. But some of the community are kicking and screaming because they resent and oppose the GPL and the Free Software Foundation, or something similar. And there are also the problems that BSD doesn't have explicit patent protection language, and the GPL has been criticized for legal ambiguity.
So, to resolve the legal ambiguity you go to LGPL3, GPL3, and Affero GPL3. These have been scrutinized by a committee of lawyers from many major corporations and other entities during their development, which is much more than we can say for most other Open Source licenses. So they have more legal solidity. But some component of the community is kicking and screaming even worse because they distrust the GPL3 effort.
So, you may have to use licenses that duplicate the effect of LGPL, GPL, and Affero GPL without coming from FSF, to calm down the violent opposition. You craft these licenses carefully to be compatible with the FSF ones. But now you may have had to create more licenses, and you have a new part of the community kicking and screaming because they'd rather you used the FSF ones.
And somewhere in there you have to find a version of the BSD license with better patent protection, which may get the BSD folks upset, even though you are doing this for their own protection.
So, that's the political problem. The assignment is to navigate your way through this, satisfying a lot of people but NOT getting a complete consensus. Then evangelize the result and try to gently influence people to use your minimal combination rather than all 70 licenses out there at the moment. I think it could work pretty well. Never perfectly.
Bruce Perens
(
Log in to post comments)