From: Roland [mailto:roland.schwarz@chello.at]
It is fine to hear, that there are serious attempts now to move forward with the threads library.
However it would be too bad if we needed a _complete_ rewrite of the threading library. Could anyone please drop me some lines why this should be necessary at all? Is the new license thus incompatible to the old one?
This is entirely about licensing. The thread library needs to be under the boost license and it is not. All attempts to date to contact the copyright holder (William Kempf) have failed, without his permission we are in the position of needing to rewrite it into compliance. Glen Knowles Centor Software Corporation
Glen Knowles wrote:
From: Roland [mailto:roland.schwarz@chello.at]
It is fine to hear, that there are serious attempts now to move forward with the threads library.
However it would be too bad if we needed a _complete_ rewrite of the threading library. Could anyone please drop me some lines why this should be necessary at all? Is the new license thus incompatible to the old one?
This is entirely about licensing. The thread library needs to be under the boost license and it is not. All attempts to date to contact the copyright holder (William Kempf) have failed, without his permission we are in the position of needing to rewrite it into compliance.
I'm probably missing something, but why? Is current Boost.Thread license violates some of Boost license guidelines? Wasn't the point of BSL to simplify the task of evaluating Boost license for the user? Is so, why can't we have all of Boost under BSL and Boost.Threads under current license? After all, two licenses to evaluate should not be too much. - Volodya
Vladimir Prus <ghost@cs.msu.su> writes:
Glen Knowles wrote:
From: Roland [mailto:roland.schwarz@chello.at]
It is fine to hear, that there are serious attempts now to move forward with the threads library.
However it would be too bad if we needed a _complete_ rewrite of the threading library. Could anyone please drop me some lines why this should be necessary at all? Is the new license thus incompatible to the old one?
This is entirely about licensing. The thread library needs to be under the boost license and it is not. All attempts to date to contact the copyright holder (William Kempf) have failed, without his permission we are in the position of needing to rewrite it into compliance.
I'm probably missing something, but why? Is current Boost.Thread license violates some of Boost license guidelines? Wasn't the point of BSL to simplify the task of evaluating Boost license for the user? Is so, why can't we have all of Boost under BSL and Boost.Threads under current license? After all, two licenses to evaluate should not be too much.
There are two issues: 1. Having just one consistent license would put to rest many questions (like "Boost.Threads uses a different license; why can't I use a different license for my library?" and "How can I be sure that there aren't other licenses lurking in the Boost sources?") and would be a great deal simpler than having two. I would really like to see us use *one* consistent license, and given the extensive work that seems to be planned for the threads library it would be a real shame to have the new work make it *harder* to make the transition to a single one. 2. It's not our practice to summarily change the maintainership of a library without the permission of the original maintainer. If we start with a fresh codebase that problem mostly disappears. Neither one of these problems is insurmountable, but *if* it's not too much work it would be preferable to either get a positive response from Bill or start over from scratch. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
2. It's not our practice to summarily change the maintainership of a library without the permission of the original maintainer. If we start with a fresh codebase that problem mostly disappears. Boost code is on sourceforge. If I remember correctly, at the time of registering new project I gave permission to SF to change maintainership under some circumstances. Project developers registered on SF might had given it as well. Should someone check it? -- Alexander Nasonov
participants (3)
-
alnsn＠yandex.ru -
David Abrahams -
Glen Knowles -
Vladimir Prus