[phobos] Licensing in Tango and elsewhere
Lars Ivar Igesund
larsivar at igesund.net
Fri Apr 30 01:17:34 PDT 2010
Hi folks,
I wish to clear the air somewhat regarding this topic.
I mostly feel like saying "Aaaarghh, you all got it wrong!", but I'll rather
try to explain my (and thus to some degree Tango's) stance.
Lets first start by defining incompatible licenses. This is entirely a user
issue, and ocassionally applies if the user uses two libraries with licenses
that conflict. This almost only ever happen if one of those licenses is the
GPL. It certainly does not happen between BSD and Boost.
So what is the issue here? It is truly impractical to have different
licenses littering a code base, so every library writer wish to avoid that.
And thus to include code from a different library with a different license,
a release of rights/relicensing may be necessary (at least in the case
moving from a stricter to a less strict license).
Then there is the case of dual licenses, such that Tango has. This tends to
make all types of interaction, such as outlined in the above paragraphs,
even more complex. I like to think that we had good reasons for making Tango
dual licensed back in the days, but in the end it has caused little more
than grief. Thus, prior to Don's Boost ticket, we started to discuss the
possiblity of a license change.
Since the BSD to some (me included) appears to be less than ideal due to the
binary attribution clause, we initially sought for an entirely new
alternative. We generally really like the Apache 2.0 license, and as
probably most other licenses, it is the result of thourough legal
counseling. The Apache Foundation is no small actor in the "open source
market". I think Boost is a nice license too, but as I will get back to, it
is a tad less restrictive than the BSD. The AFL we just dismissed, as it
just isn't well enough known (it is however a good license, written by a
lawyer specialized in software licensing issues).
To change the license of a library such as Tango is a major process, not the
least because it over the times have got over 50 contributors to the code,
some that today are really difficult to get to (we have failed when trying
to get in touch with a couple of them). So when looking to change the
license, we actually had to look into the likely case of "what can we do in
the case where we lack an acceptance from some of the contributors?". We
certainly can't move to a less restrictive license, but the AFL is
considered equal enough to the Apache 2.0, such that a relicense wasn't
totally infeasible.
At about this point in time, Don created his license ticket. In retrospect,
me changing the description of it, was probably a bad idea. The alternative,
given the restrictions outlined above, would have been just to close it
though. In any case, I am sorry if this has aggravated you Don, I certainly
didn't intend to.
In the end, we also decided against the Apache 2.0 move, the AFL<->Apache
link was just not clear enough, and we wished to avoid any potential issues
there. Looking at the options now, we ended up with the BSD, which Tango
already is licensed under.
Binary attribution clause:
This is the only actual difference between Boost and BSD, Boost otherwise
appear to be fully derived from the BSD license. Now, what does it mean?
Well, it typically mean that you don't get away from the copyright
obligations in the license, just because you have compiled the code. How you
comply with this, is up to yourself. For a product, the most obvious
solution would probably be to put a note in the documentation. OSX has taken
a different route if I understand correctly, by noting it in the boot
messages. This is of course entirely possible with Tango too, however we
think it will be good service to our users to make it possible to include
the text as a string in the binary, since that is also in compliance.
I will note further that there is an abundance of BSD licensed software out
there, which to my knowledge never really caused any harm, neither to the
libraries themselves, or to commercial businesses. (Whether this is because
all ignore the binary attribution clause, and noone tries to enforce it, I
do not know). In fact, BSD is a really popular license among copmanies such
as Google. For Tango, we believe this to be a good thing, as we ocassionally
also wish to use external code, and the best (ignoring stuff licensed as
L/GPL for now) almost always turns out to be BSD.
So in the end, Tango is in terms of licensing, really bound to decisions
made about 6 years ago, when Mango was started (as the very first project on
dsource), and those decisions were made such that the library should have a
license compatible with Phobos, seen from the user. That was true then, and
it is true today.
As for what prompted this discussion in the first place, tango.time, it is
not about being asinine or anything else. In my opinion, claiming a clean
room implementation of an API in D is difficult, if for no other reason that
it is (due to imperfect doc generation etc) somewhat difficult to properly
study a D API without at the same time reading the source (or glimpsing at
it). Even if you have good intentions, as I'm sure Shoo had, it is important
to know this, there may be less forgiving actors out there. I also think it
is civil to inform the originators if you go into such a process, and note
in the docs where the inspiration comes from, even if not required for an
API per se. Now I wasn't one of the contributors to the modules in question
(tango.time is a package fwiw, not just one module), but I can say that the
question stated by Walter (making license concessions wrt this package) will
in any case apparently take a few days to get an answer to from all relevant
parties.
--
Lars Ivar Igesund
More information about the phobos
mailing list