[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