[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The Great Licensing Discussion
- Subject: The Great Licensing Discussion
- From: Chris Travers <..hidden..>
- Date: Mon, 19 Dec 2011 19:32:59 -0800
It has occurred to me that since we have begun trying to replacing all
SQL-Ledger code, we have not discussed whether we want to stay with
the GPL v2 or later, or whether we want to look at licensing new code
under a different but compatible license. Note that for the
foreseable future (probably next ten years or even forever) the
license for the work as a whole would be unable to change due to
dependencies on translation files, and other things.
The big concern that's been discussed in the past (alas, in private)
is that a number of us on the development team aren't really
comfortable with the GPL v3 but feel that the GPL v2 or higher may
force us in that direction. So I figure I would ask everyone for now
what their thoughts are.
The prevailing interpretation of the GPL among the core team has been
that use of our API does not create a work based on our software and
therefore needs not be covered under specific copyright license
requirements as it is. This places the GPL v2, in our view, somewhere
between the FSF's view of the GPL v2 and the FSF's view of the LGPL (I
assume that actually inheriting our classes would create derivative
works, but merely logically linking would not). Since tables, stored
procedures, and perl functions are all API's this limits the GPL to
cases where our code is used as a basis for other code (either through
literal or non-literal copying), or where our classes are inherited.
So here's the big question: Suppose we start taking all new
contributions under a BSD-style license starting in the very near
future. The work as a whole would still be under the GPL v2 or later
because it isn't practical to just rip out the GPL-bound code and
probably will never be. If the work as a whole ends up having to move
to the GPL v3 or later due to other licensing considerations, but we
have a greater ability to choose a different license at that point if
we need to.
So, suppose we do this. What would it mean for contribution?
If you are a current developer, would you be more or less likely to
contribute in the future if the code was BSD-licensed?
If you are not a current developer, would you be more or less likely
to join development in the future if the code was BSD-licensed?
Two other peripheral comments:
The first is it isn't 100% clear to me what it would mean license-wise
to mix BSD-style licenses and the GPL v3. I have discussed this with
both Eben Moglen and Richard Fontana in the past who have given me
mutually exclusive reasons why the licenses are compatible, and those
reasons are sufficiently incompatible that the only real assurance is
the idea that because these licenses are intended to be compatible,
the GPL v3 will be read as to be compatible with the BSD license
(though I am not 100% sure Moglen agrees with that). The issue is
whether the BSD license can be properly reduced to GPL v3 + additional
permissions with the ability to revoke those permissions without
changing the code (Moglen says yes, Fontana says no. Moglen says this
is a requirement. Fontana says the GPL v3 must be read to be
compatible with the BSD license--- if Moglen is right about the GPL v3
and Fontana is right about the BSD license, they are not compatible,
but the SFLC's work generally sides more with Fontana here, so....).
The larger assurance is that evolving norms in the community see these
licenses as compatible so I doubt these will be read to be
The second is this. I am planning on writing reference
implementations for the stored procedure discovery routines in other
languages, namely PHP and Python. At present I don't see a reason
not to license these pieces of my work under a BSD-style license,
though I am open to comment here.
Anyway what does everyone else think?