Make Tango fully licensed under Apache 2.0

Well as author you can release all your code under several licenses.

Personally I don't think that adding yet another license to tango is the way to go, because having multiple licenses makes the actual licensing even less clear.

In my opinion if the license should be changed, it should be changed to a single license, and in that case I see apache 2.0 as a much better alternative.

It is used more widely and has clearer guidelines toward how to handle other licenses (which in my opinion is very important), also it tries to ensure that a single license is presented to the end user, and the apache license is mantained (for exmaple ensuring that contributions fall under that license.

I had opened the discussion about that here: http://www.dsource.org/projects/tango/forums/topic/786

We wish to make Tango fully licensed/distributed under the Apache 2.0 license, and for this the consent from current contributors is needed.

Please chime in.

(1) The Apache license does look much better than the existing Tango license, and a big improvement over the AFL; but... (2) The primary reason I wanted the Boost license was to close the gap between Tango and Phobos -- possibly the largest problem facing D. Does this still achieve that?

(Note that the goal could also be achieved with by allowing a reciprocal Boost license for Phobos ONLY. But we have to do SOMETHING).

I have some problems understanding the issue. In general code in Tango isn't a candidate for inclusion in Phobos, and the same holds true for the other direction. If some lesser pieces are such candidates (say the math package), the author is of course free to license as he wish. If someone wish to make compatibility layers between the two, that isn't an issue either as the API itself cannot be licensed.

When that is said, Apache 2.0 and Boost aren't actually conflicting licenses, so using Phobos and Tango code together isn't an issue, and that seems to me to be the, by far, most likely scenario.

Further, having an additional license just for Phobos doesn't make sense, since an open source license is transitive towards all users in any case.

Tango has very many contributors, some that are difficult to get hold of. If we're not able to do it, that will be OK (if not preferrable) with Apache 2.0 since it will still be possible to distribute Tango under it with a NOTICE about the original licenses.

This option does not exist for Boost however, since both BSD and AFL will require explicit consent for the code to be distributed under it, Boost being a looser license. This, in addition to the other arguments for Apache 2.0, make us feel that it is not worth an investment towards Boost.

Replying to larsivi:

We wish to make Tango fully licensed/distributed under the Apache 2.0 license, and for this the consent from current contributors is needed.

Not that I ever committed much here, but any of my contributions to tango or dsource.org/projects/tango may be relicenced under any FSF-free licence.

Good luck if you do need explicit consent from all authors :(

With time, it has become evident that is near to impossible to get explicit consent from all authors. There is some evidence that this isn't really really needed, but we'd rather be on the safe side.

"history" has shown us that two licenses is very confusing for the users, especially when one of them isn't very well known, and the difference isn't _that_ big.

Thus we feel there is only one alternative left - drop one of the current licenses and stick with the other. The winner then is BSD.

In the past we have felt that the BSD is somewhat impractical for the user due to the binary attribution clause, but we intend to solve that by providing it to the users by putting the license text in a static string in a central module. Thus we end up with an open, relatively short, well known, easy to comply with, GPL compatible license. It is also a license that makes a lot of high quality libraries directly compatible - for example for potential inclusion/bundling with Tango.

We intend to implement this change prior to Tango 1.0