Hi, Chickeners. As I have some code that I would like to contribute back to Chicken, in the form of eggs, I have started to look into the licensing issue. I've asked that on #chicken, and the response was that I should choose my own license.
Sure enough, the eggs page show *a mess*. We have all sorts of licensing, including Public Domain, BSD, MIT, LGPL, GPL-2 and GPL-3. This is the egg breakdown, according to the eggs page: BSD: 168 eggs Artistic: 3 eggs Bremer License: 1 egg Free Use(?): 1 egg GPL-2: 5 eggs GPL-3: 47 eggs LGPL(no version specified): 6 eggs LGPL-1: 2 eggs LGPL-2: 1 egg LGPL-2.1: 9 eggs LGPL-3: 2 eggs MIT: 11 eggs Public domain: 25 eggs SRFI: 5 eggs Unknown(this shouldn't even exist): 4 eggs XEROX: 1 egg Henrietta lists more eggs, but they probably aren't visible. Since eggs are just a chicken-install away, it is non-trivial to determine the legality of a project that uses several of these. And, as a lot of Chicken development nowadays is being done on web servers (and we haven't got a single AGPL egg on that list) we can get away with it for now. This will indubitably generate a flame fest about which license is best, but this is not the intention. Rather, it is to figure out a policy for egg licensing and let authors make informed decisions. Sjamaan suggested that eggs should preferably follow Chicken's license, and I agree with that. Some deviation is unavoidable, specially when eggs bind to external libraries or when they are ported(hence the XEROX license, for instance). Ideally those should be an exception and chicken-install (or even chicken itself) should throw a warning. To reiterate, this is not to say that one should be forced to choose a license. Rather, I see two fronts: 1- Sort out the existing eggs 1.1 - Contact the 'Unknown license' egg authors to agree on a license for the existing code. There are just a few of these, thankfully. 1.2 - See if it is possible to 'Upgrade' the license in some eggs, to reduce version complexity (LGPL guys, I'm looking at you) 1.3 - Figure out which licenses are compatible between each other and post this information in the Wiki. Preferably with comments about suitability for closed-source projects. I have seen some general information, but assistance from FSF might be required. 2- New eggs 2.1 - Write licensing guidelines for new eggs, providing a list of 'recommended' licenses and an explanation for each. The list is of course just a recommendation, but it would allow someone who has yet to decide to make an informed decision. This seems to be a useful starting point: http://www.dina.dk/~abraham/rants/license.html 2.2 - Only publish eggs when the license is provided. It's fine for them to sit in the repository while in progress, of course. I do know if it is currently being done, but the existence of 'unknown license' eggs says it is not. 2.3 - chicken-install and chicken-status should provide licensing information. 2.4 - If they are using a standard license with exceptions, those should be listed explicitely. As an example of how complicated things are, this is from http://www.gnu.org/licenses/license-list.html LGPL 2.1: Compatible with GPL2 and GPL3. LGPL 3: Compatible with GPL3, but not with GPL2. GPL 2: May or may not be compatible with GPL 3, has its own FAQ and gave me a headache. Artistic License is compatible with GPL. What about LGPL? Doesn't say, we have to check. HOWEVER, it is not even free software if the version is 1.0. MIT can be used to refer to the X11 License, but the page states that MIT has used several licenses. We are probably using it to mean the X11 one, but this is the kind of ambiguity lawyers thrive on. SRFI I have no idea. Ditto about the TK egg and the Bremer License, the page didn't load for me here at work. I haven't seen dual-license eggs, but this is also possible. Again, the idea is not to restrict authors. Its their code and they can release it under the Infernal License - 3 that requires virgin sacrifices. It is fine. But, if virgin sacrifices are not actually required, maybe a BSD would suffice, making integration easier. Comments are most welcome. --Stephen Sent from my Emacs _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users