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

On 04/30/2010 03:17 AM, Lars Ivar Igesund wrote:
> Hi folks,
[snip]

Thanks. I sat down and carefully read through your long message, but failed to extract a crucial piece of information from it: what steps do we need to take to make progress in the matter?

Andrei