« NeoOffice 2.0 Alpha... | Main | links for 2006-04-28 »
20060426 Wednesday April 26, 2006

Open Source Licensing Paper

I've commented before on the three-category model I use for classifying open source licenses for internal use at Sun. We've prepared a white paper [253k PDF] explaining the approach we take and I would welcome constructive feedback. Feel free to pass this on, it is Creative Commons licensed, and let me know if it proves useful. Many thanks to Mary who actually wrote most of it (and had to endure hours of listening to me talk about open source licenses) and to chief squirrel herder Sara who made it happen.

Posted by webmink ( Apr 26 2006, 07:05:13 AM PDT ) Permalink Comments [5]
technorati del.icio.us digg slashdot
Comments:

Each category lists "unrestricted development of derivative works" as a characteristic. This is quite untrue for the example licences given in categories B and C (CDDL, GPL), which are chiefly characterised precisely by the restrictions these licences put on distribution of derivative works.

Further, "FSF-style licences" is a really poor wording of the category C example. What about the LGPL? I think you mean "GPL", not "FSF-style".

Finally, I think using "project" and "file" as distinguishers between category B and C is perhaps ill-conceived - it makes little sense. I think, based on the example licences given (presuming GPL for C), you really mean: whether or not the licence considers usage through linkage (by whatever means) to be a natural limit to the licence as to derived work status, ie "external linkage allowed?" is possibly a more accurate way of putting it.

Posted by Paul Jakma on April 26, 2006 at 10:52 AM PDT #

Thanks for the comments Paul. I do agree the repetition is unnecessary, but I disagree with you about your first point. The principle freedom protected by all open source licenses is the unrestricted development of derivative works. You're right to say that the way those works may be deployed varies but the development is a common factor.

I did struggle for a name for that last category. There are actually three GPL variants, plus many variants created by exceptions, so a category name is needed and just "GPL" didn't seem right. LGPL is actually covered later in the paper - it seems to be a hybrid B/C license that's a lot like B.

I see your point about "linkage" but I was trying to find a memorable way of distinguishing. I did not coin this usage (although I don't recall who did) and I have found it has resonated well with audiences over a long period. Can you think of an equally memorable way to contrast "File-based"?

Posted by Simon Phipps on April 27, 2006 at 05:51 PM PDT #

Hi Simon, Just some feedback (mainly chapter 4 category A) : == Within this context, there is, however, a price to be paid for this high level of developer freedom—and that price is paid by the commons and the community that manages it. Because there is no compulsion for the developer to contribute back to the code commons, the possibility exists that those deriving forks from the code commons will choose not to enrich that commons with bug fixes and other improvements == IANAL to bo honest, but I think the forking thing happens anyway, regardless of the license. Don't know if Category B licenses prohibit forking though (if it is not prohibited, I can see no reason why I cannot eg fork Mozilla) My (practical) experience with the risk of not getting improvements and bug fixes from bsd style licenses is just as big as other licenses. People won't contribute back if they don't want to, independ of the license. I think the BSD style licenses actually promote giving back to the common project, since it is in the best interest of the usrs (mainting your own fork versus at max maintaining a private branch/using the standard package). If the community around the software however doesn't respond well to patches and enhancements, it could indeed have the effect you state.

Posted by Martin van den Bemt on April 28, 2006 at 03:37 AM PDT #

Thanks, Martin. Yes, I have discussed that topic at the greatest possible length with Dalibor Topic and Geir Magnusson (as sample supporters of class C and class A licensing respectively) and many others (most recently with Mr Stallman himself). I have good supporting case studies to suggest that both behaviours can occur.

The ASF view is that nothing is lost by the community when a code consumer fails to participate, and that they are the loser. The FSF view is that only uses that lead to more Free software and reduce the power of proprietary software count as "Freedom".

The topic lays at the heart of the ongoing tension between "Free software" and "Open Source" and there's no way I could do justice to it in a brief position paper!

Posted by Simon Phipps on April 28, 2006 at 07:51 AM PDT #

The first point isn't quibbling about development, the quibble is regarding unrestricted. :) That's clearly not the case for CDDL or GPL - the primary difference between those and BSD-like licences are precisely the restrictions those licences put on derived works. "Copyleft" is an often-used term to describe it, I think, possibly.

As to file/project - no, I can't think of a catchy phrase for it either ;). I don't think though it's an appropriate distinction between CDDL and GPL, e.g. LGPL would be "project" based in this jargon, yet it clearly is more like the CDDL in restricting its scope to only those files (and derivatives of those files).

Afraid though I can't quite be more helpful other than the negative point of "I don't think file vs project is quite right", unfortunately.

Posted by Paul Jakma on May 02, 2006 at 06:51 PM PDT #

Post a Comment:

Comments are closed for this entry.