chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] On eggs and their licensing


From: Stephen Eilert
Subject: [Chicken-users] On eggs and their licensing
Date: Wed, 2 Jun 2010 11:43:43 -0300

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]