Chris Allen posted with a reference to the OS license discussion that was started by Grant Skinner. The original post was more of a summary of the licenses but its got a few people talking in the comments. Anyways, Chris was thinking about the licenses we currently use on our open source projects here at Infrared5. In particular, he brought up Jedai which is an open source framework that consists of client/server api for building collaborative applications.
I thought about it briefly and came up with two reasons why one would pick a restrictive license over a less restrictive license. I still think that LGPL is a good choice for frameworks. Here’s where I draw the line. I think that if your building a coloring api and its a small black box of code that does something and does it well, then a less restrictive license would be beneficial to the developers since they may want to change the implementation. However, when it comes to an open source framework, a license is the only way to prevent the core api from forking. What’s so important about forking? Well in terms of a LGPL, developers can always extend the framework to create new and interesting distributions. LGPL only says that if any of the core code changes that it must get contributed back to the project. Does this mean that you can’t change the core code? Of course you can. It just means that the project has the option to incorporate that code into the core codebase. The project always has the option to defer adding your code. One thing that I look for in a framework is consistency in terms of it’s core api. Could you imagine if there were 10 different versions of Cairngorm? One forked version totally threw away the concept of the ModelLocator. One threw away the portion of code that dispatched events from the FrontController. I think those types of forks would lead to slower adoption and a smaller pool of Cairngorm developers who can come into my shop and hit the road running on a project that uses Cairngorm. Part of the attractiveness to using a framework is that the coding experience is consistent.
So, I’ll conclude:
A library could fall under a less restrictive license
A framework may want to prevent forking by using a more restrictive license
Again, it’s always up to the team who built the code. You can’t force anyone to choose a license, but y0u can explain the benefits of one over the other in regards to a project.
So again, I wonder if anyone else has any opinions.
Tags: Uncategorized // Add Comment »
