Any libraries now not under the Boost Software License?
http://boost.org/more/license_info.html says: Currently, some Boost libraries have their own licenses. The hope is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ that eventually all Boost libraries will be covered by the Boost Software License. In the meantime, all libraries comply with the Boost License requirements. Is that still true now that we have Threads under the BSL? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Janek Kozicki wrote:
David Abrahams said: (by the date of Tue, 22 May 2007 17:16:28 -0400)
Is that still true now that we have Threads under the BSL?
yes. I remember a post a while ago that the original author decided to relicense threads to BSL.
I think you just answered with a non-answer ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera said: (by the date of Tue, 22 May 2007 23:41:39 -0500)
Janek Kozicki wrote:
David Abrahams said: (by the date of Tue, 22 May 2007 17:16:28 -0400)
Is that still true now that we have Threads under the BSL?
yes. I remember a post a while ago that the original author decided to relicense threads to BSL.
I think you just answered with a non-answer ;-)
OK, I'm sorry too much haste. I took time to grep my archive, and then google it in webarchive by title: "Permission given to change to Boost.License" http://lists.boost.org/Archives/boost/2006/09/110143.php But I see, the question was "Is that STILL true" ... well I don't know if it's still true. I pay some attention to thread related posts on this list, and since that one post I remember nothing about revoking this permission. -- Janek Kozicki |
----Original Message---- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Janek Kozicki Sent: 23 May 2007 06:44 To: boost@lists.boost.org Subject: Re: [boost] Any libraries now not under the Boost Software License?
Rene Rivera said: (by the date of Tue, 22 May 2007 23:41:39 -0500)
Janek Kozicki wrote:
David Abrahams said: (by the date of Tue, 22 May 2007 17:16:28 -0400)
Is that still true now that we have Threads under the BSL?
yes. I remember a post a while ago that the original author decided to relicense threads to BSL.
I think you just answered with a non-answer ;-)
OK, I'm sorry too much haste. I took time to grep my archive, and then google it in webarchive by title:
"Permission given to change to Boost.License"
http://lists.boost.org/Archives/boost/2006/09/110143.php
But I see, the question was "Is that STILL true" ...
well I don't know if it's still true. I pay some attention to thread related posts on this list, and since that one post I remember nothing about revoking this permission.
You have misunderstood the question completely. It is not: Is Threads under the BSL? (we know the answer to that is "Yes".) The question is: Are there any /other/ libraries that are not under the BSL? If the answer to that question is "No", then the statement: Currently, some Boost libraries have their own licenses. is obviously false, and we can tidy up the licensing page (which will make some corporate lawyers happy). -- Martin Bonner Project Leader PI SHURLOK LTD Telephone: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner@pi-shurlok.com www.pi-shurlok.com
Martin Bonner said: (by the date of Wed, 23 May 2007 09:20:31 +0100)
You have misunderstood the question completely. It is not: Is Threads under the BSL? (we know the answer to that is "Yes".)
The question is: Are there any /other/ libraries that are not under the BSL?
If the answer to that question is "No", then the statement: Currently, some Boost libraries have their own licenses. is obviously false, and we can tidy up the licensing page (which will make some corporate lawyers happy).
Oops, sorry again. So since I started answering to this thread I should finish it with the right answer ;) I did a check in CVS-HEAD. With midnight commander and it's quick-view feature I was able to browse the files pretty quickly. Less than second for each file (of course longer if I didn't spot the license term). So I checked every file, but still - it was a rather quick 'human eyes' search. So I might have not spotted something. But here's what I've found: 1. all the files in /boost/numeric/ublas have following license: // Permission to use, copy, modify, distribute and sell this software // and its documentation for any purpose is hereby granted without fee, // provided that the above copyright notice appear in all copies and // that both that copyright notice and this permission notice appear // in supporting documentation. The authors make no representations // about the suitability of this software for any purpose. // It is provided "as is" without express or implied warranty. So it is not a BSL ! 2. the files /boost/graph/kolmogorov_max_flow.hpp and /boost/graph/write_dimacs.hpp have two licenses, one of which is BSL, in case if that matters. 3. boost/interprocess/detail/atomic.hpp uses Apache license *AND* BSL, weird ! 4. boost/interprocess/detail/config_begin.hpp and config_end.hpp have no license 5. information in boost/interprocess/sync/interprocess_recursive_mutex.hpp about license is obsolete because W.Kempf granted BSL for his code. 6. boost/math/common_factor_rt.hpp nas no BSL license: // (C) Copyright Daryle Walker and Paul Moore 2001-2002. Permission to copy, // use, modify, sell and distribute this software is granted provided this // copyright notice appears in all copies. This software is provided "as is" // without express or implied warranty, and with no claim as to its suitability // for any purpose. 7. boost/multi_array/algorithm.hpp is not clear, but maybe it's correct ? there are also two files with this notice in multi_array_detail. But I guess it's OK 8. boost/program_options/detail/utf8_codecvt_facet.hpp doesn't have BSL: // Copyright Š 2001 Ronald Garcia, Indiana University (garcia@osl.iu.edu) // Andrew Lumsdaine, Indiana University (lums@osl.iu.edu). Permission to copy, // use, modify, sell and distribute this software is granted provided this // copyright notice appears in all copies. This software is provided "as is" // without express or implied warranty, and with no claim as to its suitability // for any purpose. 9. boost/python/detail/python22_fixed.h has boostinspect:nolicense So I guess it's OK with the: Copyright (c) 2001, 2002 Python Software Foundation; All Rights Reserved 10. boost/test/included/unit_test_framework.hpp has no license 11. boost/test/utils/runtime/cla/detail/argument_value_usage.hpp has no BSL: // (C) Copyright Gennadiy Rozental 2005. // Permission to copy, use, modify, sell and distribute this software // is granted provided this copyright notice appears in all copies. // This software is provided "as is" without express or implied warranty, // and with no claim as to its suitability for any purpose. 12. boost/rational.hpp has no license 13. boost/shared_container_iterator.hpp doesn't have BSL: // (C) Copyright Ronald Garcia 2002. Permission to copy, use, modify, sell and // distribute this software is granted provided this copyright notice appears // in all copies. This software is provided "as is" without express or implied // warranty, and with no claim as to its suitability for any purpose. Whew. That's it. Took me one and a half an hour. Hope this helps. Based on above research I could tell that only boost::ublas doesn't have BSL, while all the other files are simply a mistake that can be quickly corrected... best regards -- Janek Kozicki |
Janek Kozicki wrote:
Whew. That's it. Took me one and a half an hour. Hope this helps.
Based on above research I could tell that only boost::ublas doesn't have BSL, while all the other files are simply a mistake that can be quickly corrected...
Thanks for looking into this: I guess it's too late to tell you that the bcp tool can produce a HTML license report in a couple of seconds....! Looks like we still have a bit of chasing up to do on the license front. John.
2007/5/23, John Maddock <john@johnmaddock.co.uk>:
Looks like we still have a bit of chasing up to do on the license front.
The latest (and as long as I've seen them) Boost inspection notification (2007-05-23/RC_1_34_0) *LC* contains: Problem counts: 661 files missing Boost license info or having wrong reference text 398 files missing copyright notice /$
Henrik Sundberg said: (by the date of Wed, 23 May 2007 18:43:52 +0200)
2007/5/23, John Maddock <john@johnmaddock.co.uk>:
Looks like we still have a bit of chasing up to do on the license front.
Problem counts: 661 files missing Boost license info or having wrong reference text 398 files missing copyright notice
yep. that's what I'm talking about. Sometime license information was indeed weirdly wrapped/indented. But it was there. -- Janek Kozicki |
John Maddock said: (by the date of Wed, 23 May 2007 17:16:55 +0100)
Thanks for looking into this: I guess it's too late to tell you that the bcp tool can produce a HTML license report in a couple of seconds....!
Looks like we still have a bit of chasing up to do on the license front.
Oh, I knew that :) But OTOH nothing can really beat a human in some cases. That's why I did this myself. IIRC that tool seemed to generate far too many false warnings. -- Janek Kozicki |
on Wed May 23 2007, Janek Kozicki <janek_listy-AT-wp.pl> wrote:
But here's what I've found:
<snip>
Whew. That's it. Took me one and a half an hour. Hope this helps.
Wow, thanks!
Based on above research I could tell that only boost::ublas doesn't have BSL, while all the other files are simply a mistake that can be quickly corrected...
In that case I vote for ripping ublas out of Boost unless and until the authors fix it. This is crazy; people have had long enough. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Based on above research I could tell that only boost::ublas doesn't have BSL, while all the other files are simply a mistake that can be quickly corrected...
In that case I vote for ripping ublas out of Boost unless and until the authors fix it. This is crazy; people have had long enough.
I'm not sure about that: ublas was voted in under it's existing licence, the authors didn't know at the time that we were about to change things :-) Still we should have another go at contacting them whatever, John.
on Sun May 27 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
David Abrahams wrote:
Based on above research I could tell that only boost::ublas doesn't have BSL, while all the other files are simply a mistake that can be quickly corrected...
In that case I vote for ripping ublas out of Boost unless and until the authors fix it. This is crazy; people have had long enough.
I'm not sure about that: ublas was voted in under it's existing licence, the authors didn't know at the time that we were about to change things :-)
I know it's slightly radical, but at the same time, the ublas authors have made no efforts to integrate with the Boost community and if their library is *still* holding back progress after all this time, IMO it should be dropped. Unlike Boost.Threads, IMO, it can still be maintained as a project outside of Boost... which is sorta what happens anyway IIUC.
Still we should have another go at contacting them whatever,
Please do :) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Wed May 23 2007, Janek Kozicki <janek_listy-AT-wp.pl> wrote:
But here's what I've found:
<snip>
Whew. That's it. Took me one and a half an hour. Hope this helps.
Wow, thanks!
Based on above research I could tell that only boost::ublas doesn't have BSL, while all the other files are simply a mistake that can be quickly corrected...
In that case I vote for ripping ublas out of Boost unless and until the authors fix it. This is crazy; people have had long enough.
Interesting. Reading http://boost.org/more/lib_guide.htm#License I see that BSL is the recommended, but not required license. Above, you propose to rip out a part of Boost because it's not BSL. Can you please point me to - A document that say BSL is an absolute requirement - A mailing list announcement that BSL is now an absolute requirement I've no comment if such change is good or not, but I'm worried about such global decision being made silently. - Volodya
on Sun May 27 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
David Abrahams wrote:
on Wed May 23 2007, Janek Kozicki <janek_listy-AT-wp.pl> wrote:
But here's what I've found:
<snip>
Whew. That's it. Took me one and a half an hour. Hope this helps.
Wow, thanks!
Based on above research I could tell that only boost::ublas doesn't have BSL, while all the other files are simply a mistake that can be quickly corrected...
In that case I vote for ripping ublas out of Boost unless and until the authors fix it. This is crazy; people have had long enough.
Interesting. Reading http://boost.org/more/lib_guide.htm#License I see that BSL is the recommended, but not required license. Above, you propose to rip out a part of Boost because it's not BSL. Can you please point me to
- A document that say BSL is an absolute requirement - A mailing list announcement that BSL is now an absolute requirement
I've no comment if such change is good or not, but I'm worried about such global decision being made silently.
I don't have time to dig these things up right now, and maybe there wasn't even a formal "announcement" per se, but it is common knowledge that the point of the BSL was to get Boost under a single license and there has been a massive, well-publicized, effort to get permissions from library authors so we could do just that. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
- A document that say BSL is an absolute requirement - A mailing list announcement that BSL is now an absolute requirement
I've no comment if such change is good or not, but I'm worried about such global decision being made silently.
I don't have time to dig these things up right now, and maybe there wasn't even a formal "announcement" per se, but it is common knowledge that the point of the BSL was to get Boost under a single license and there has been a massive, well-publicized, effort to get permissions from library authors so we could do just that.
Sorry, but getting as many libraries as possible under BSL (which is indeed well-publicized effort) is not the same as prohibiting libraries not under BSL completely. The latter goal might be obvious to you or to boost moderators, but don't you find a proposal to rip a part of Boost based on policy that's not documented anywhere a little weird? - Volodya
on Sun May 27 2007, Pavol Droba <droba-AT-topmail.sk> wrote:
Rene Rivera wrote:
Hervé Brönnimann wrote:
I would like to know also.
On May 27, 2007, at 2:02 PM, Pavol Droba wrote:
Who is in charge for account creation?
Have you tried contacting all the moderators at <mailto:boost-owner@lists.boost.org> as the instructions mention <http://svn.boost.org/trac/boost/wiki/BoostSubversion> ?
I have understood it as "any" of them and choose Doug Gregor.
In general, please do not email individual moderations with admin requests. Having a bunch of people is part of the way we amortize the work and make sure that those who have time to handle requests are the ones that do it. Also the individual you choose may be out of communication at any time, as happened here. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Sunday 27 May 2007 11:36, Vladimir Prus wrote:
David Abrahams wrote:
on Wed May 23 2007, Janek Kozicki <janek_listy-AT-wp.pl> wrote:
But here's what I've found:
<snip>
Whew. That's it. Took me one and a half an hour. Hope this helps.
Wow, thanks!
Based on above research I could tell that only boost::ublas doesn't have BSL, while all the other files are simply a mistake that can be quickly corrected...
In that case I vote for ripping ublas out of Boost unless and until the authors fix it. This is crazy; people have had long enough.
crazy ;-)
Interesting. Reading http://boost.org/more/lib_guide.htm#License I see that BSL is the recommended, but not required license. Above, you propose to rip out a part of Boost because it's not BSL. Can you please point me to
- A document that say BSL is an absolute requirement - A mailing list announcement that BSL is now an absolute requirement
I've no comment if such change is good or not, but I'm worried about such global decision being made silently.
Indeed. With regard to uBLAS I think there is little chance of a license change. Joerg was contactable up to last year by phone. Email however landed in the bit bucket. He was always very non committal as to a change to a BGL license. I assume a change would require Mathias' agreement. I not sure who Mathias is or if Joerg was still in contact with him. Basically the orignal authors do not seem to be interested in a license change. We would have to accept that if uBLAS's license becomes unacceptable to the Boost community then uBLAS would have to move. The change to BSL has been around for a long time after all and the BSL is a good thing. Maybe there would be a gentler solution then Dave's suggested 'ripping out'. I think a single license for all of Boost is very helpful to users. So the change would have to make the license status very clear. Some kind of 'historical', 'aberrant license' status maybe? Michael
Michael Stevens wrote:
Maybe there would be a gentler solution then Dave's suggested 'ripping out'. I think a single license for all of Boost is very helpful to users. So the change would have to make the license status very clear. Some kind of 'historical', 'aberrant license' status maybe?
Have a look at the way debian/ubuntu organize the distribution: There's afaik a main repository with supported and properly licenced software and a restricted repository with supported software that's non-free in some way. Boost could provide all BSL projects in the main part and move ublas to the restricted area. However, if the BSL is mandatory for new projects, ublas would stay the only restricted project, making this solution disproportionately expensive. A second solution would be a separate Add-On page. These add-on-projects are not part of the current distribution, but should be compatible with it. This would be a place for projects that are already accepted but not integrated in the main distribution, yet, and projects with a non-BSL license (ublas). Malte
on Mon May 28 2007, Michael Stevens <list-boost-AT-michael-stevens.de> wrote:
On Sunday 27 May 2007 11:36, Vladimir Prus wrote:
David Abrahams wrote:
In that case I vote for ripping ublas out of Boost unless and until the authors fix it. This is crazy; people have had long enough.
crazy ;-)
Interesting. Reading http://boost.org/more/lib_guide.htm#License I see that BSL is the recommended, but not required license. Above, you propose to rip out a part of Boost because it's not BSL. Can you please point me to
- A document that say BSL is an absolute requirement - A mailing list announcement that BSL is now an absolute requirement
I've no comment if such change is good or not, but I'm worried about such global decision being made silently.
Indeed.
Well, it's not being made silently; we're discussing it now. Nothing like a radical proposal for getting the issues out into the open, is there? ;-)
With regard to uBLAS I think there is little chance of a license change.
Joerg was contactable up to last year by phone. Email however landed in the bit bucket. He was always very non committal as to a change to a BGL license. I assume a change would require Mathias' agreement. I not sure who Mathias is or if Joerg was still in contact with him. Basically the orignal authors do not seem to be interested in a license change.
We would have to accept that if uBLAS's license becomes unacceptable to the Boost community then uBLAS would have to move. The change to BSL has been around for a long time after all and the BSL is a good thing.
Maybe there would be a gentler solution then Dave's suggested 'ripping out'.
I would love that.
I think a single license for all of Boost is very helpful to users. So the change would have to make the license status very clear. Some kind of 'historical', 'aberrant license' status maybe?
Personally, I don't think it makes sense. It looks like in the very near future this library will be the one and only piece of Boost that is not under BSL. I think having one single special case hurts Boost way more than it helps. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Mon May 28 2007, Michael Stevens <list-boost-AT-michael-stevens.de> wrote:
Personally, I don't think it makes sense. It looks like in the very near future this library will be the one and only piece of Boost that is not under BSL. I think having one single special case hurts Boost way more than it helps.
Agreed. Thomas -- Thomas Witt witt@acm.org
Thomas Witt wrote:
David Abrahams wrote:
on Mon May 28 2007, Michael Stevens <list-boost-AT-michael-stevens.de> wrote:
Personally, I don't think it makes sense. It looks like in the very near future this library will be the one and only piece of Boost that is not under BSL. I think having one single special case hurts Boost way more than it helps.
Agreed.
Thomas
Questions (from the novice/newbie/outsider): 1) Is it a *requirement* for any new libraries that are submitted for review, currently under review, or reviewed/accepted but not yet in the Boost distribution accept the BSL? 2) Are there any other libraries of Boost that are dependent upon uBLAS? If the answers are "Yes" and "No" respectively, then I don't quite understand how a single special case is all that harmful to Boost. (Maybe because I'm not a lawyer.) Certainly having many cases (as in before the BSL push/adoption) was harmful if not impossible. I understand and agree with the need for a single license but when you are down to 1-2 "stand-alone" cases then the harm to boost is fairly minimized is it not? Wouldn't it be sufficient to simply document this special case on the license information page (http://www.boost.org/more/license_info.html) something like: _*Non-BSL Conforming [Legacy] Libraries*_ uBLAS currently remains the only library included with the Boost distribution that has not adopted the BSL (yet). Please see the library for licensing details. *No Boost libraries are dependent upon any non-BSL library in any manner - nor will they ever be. All new libraries added to Boost are required to accept the BSL.* Something like that should allow companies to still accept Boost from a legal standpoint readily enough, no? They could review BSL, find it sufficient and then say to their developers "you can use Boost except for uBLAS" (if the developers don't need uBLAS) or they can spend the extra effort to review uBLAS's license (if/when the developers need it). If that's not enough, how about additionally moving uBLAS to a separate namespace? "boost_non_conformant", "boost_non_BSL", or something along those lines. If other Boost libraries are dependent upon uBLAS then just ignore all this as it becomes a completely different problem (and a nasty one at that). Just my 2.3 cents, -Chris
on Tue May 29 2007, Christopher Woods <cwoods_eol-AT-yahoo.com> wrote:
Questions (from the novice/newbie/outsider):
1) Is it a *requirement* for any new libraries that are submitted for review, currently under review, or reviewed/accepted but not yet in the Boost distribution accept the BSL?
I'm going to go out on a limb and say "yes." An undocumented requirement, but still...
2) Are there any other libraries of Boost that are dependent upon uBLAS?
Not AFAIK.
If the answers are "Yes" and "No" respectively, then I don't quite understand how a single special case is all that harmful to Boost. (Maybe because I'm not a lawyer.)
Or maybe because you don't work in a company where the lawyers can't don't like complication, or because you can't see how having one exception causes pressure to allow more exceptions.
Certainly having many cases (as in before the BSL push/adoption) was harmful if not impossible. I understand and agree with the need for a single license but when you are down to 1-2 "stand-alone" cases then the harm to boost is fairly minimized is it not?
Reduced, but IMO not acceptable.
Wouldn't it be sufficient to simply document this special case on the license information page (http://www.boost.org/more/license_info.html) something like:
_*Non-BSL Conforming [Legacy] Libraries*_
uBLAS currently remains the only library included with the Boost distribution that has not adopted the BSL (yet). Please see the library for licensing details.
*No Boost libraries are dependent upon any non-BSL library in any manner - nor will they ever be. All new libraries added to Boost are required to accept the BSL.*
We may have to do that if we can't get the uBlas authors to change the license and we can't come to a different consensus, but I would not like it. It's a wart, and complicates makes legal analysis of the implications of using Boost.
Something like that should allow companies to still accept Boost from a legal standpoint readily enough, no?
I can't speak for them. My goal is to remove the barriers to adoption, not just keep them moderately low.
They could review BSL, find it sufficient and then say to their developers "you can use Boost except for uBLAS"
In some cases, they don't trust the developers. uBLAS would actually need to be removed from the code to which they have access.
(if the developers don't need uBLAS) or they can spend the extra effort to review uBLAS's license (if/when the developers need it).
If that's not enough, how about additionally moving uBLAS to a separate namespace? "boost_non_conformant", "boost_non_BSL", or something along those lines.
I don't see how that helps. Lawyers don't care about namespaces. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Tue May 29 2007, Christopher Woods <cwoods_eol-AT-yahoo.com> wrote:
Questions (from the novice/newbie/outsider):
1) Is it a *requirement* for any new libraries that are submitted for review, currently under review, or reviewed/accepted but not yet in the Boost distribution accept the BSL?
I'm going to go out on a limb and say "yes." An undocumented requirement, but still...
Good but I think it should be a clearly documented requirement of acceptance to "Boost".
2) Are there any other libraries of Boost that are dependent upon uBLAS?
Not AFAIK.
Good - that means that if you do decide to pull it from Boost you aren't going to end up ripping out lots of other libraries as well.
Or maybe because you don't work in a company where the lawyers can't don't like complication, or because you can't see how having one exception causes pressure to allow more exceptions.
Certainly having many cases (as in before the BSL push/adoption) was harmful if not impossible. I understand and agree with the need for a single license but when you are down to 1-2 "stand-alone" cases then the harm to boost is fairly minimized is it not?
Reduced, but IMO not acceptable.
I understand that a single exception can leave an opening/pressure to allow others. However many things in this world fall under "Grandfather Clauses" because they were around before requirement/restriction/law X was put forth and adopted. If it's understood by all that "that was the way it was then and this is the rule/law/restriction now" then there really isn't any pressure IMHO and hence the basis for how I was suggesting to potentially treat uBLAS. If that's unacceptable that's perfectly fine my me - I was just throwing it out there for consideration.
They could review BSL, find it sufficient and then say to their developers "you can use Boost except for uBLAS"
In some cases, they don't trust the developers. uBLAS would actually need to be removed from the code to which they have access.
Understood. Thanks for your responses, -Chris
on Mon May 28 2007, Michael Stevens <list-boost-AT-michael-stevens.de> wrote:
On Sunday 27 May 2007 11:36, Vladimir Prus wrote:
David Abrahams wrote:
In that case I vote for ripping ublas out of Boost unless and until the authors fix it. This is crazy; people have had long enough.
crazy ;-)
Interesting. Reading http://boost.org/more/lib_guide.htm#License I see that BSL is the recommended, but not required license. Above, you propose to rip out a part of Boost because it's not BSL. Can you please point me to
- A document that say BSL is an absolute requirement - A mailing list announcement that BSL is now an absolute requirement
I've no comment if such change is good or not, but I'm worried about such global decision being made silently.
Indeed.
Well, it's not being made silently; we're discussing it now. Nothing like a radical proposal for getting the issues out into the open, is there? ;-)
With regard to uBLAS I think there is little chance of a license change.
Joerg was contactable up to last year by phone. Email however landed in the bit bucket. He was always very non committal as to a change to a BGL license. I assume a change would require Mathias' agreement. I not sure who Mathias is or if Joerg was still in contact with him. Basically the orignal authors do not seem to be interested in a license change.
We would have to accept that if uBLAS's license becomes unacceptable to the Boost community then uBLAS would have to move. The change to BSL has been around for a long time after all and the BSL is a good thing.
Maybe there would be a gentler solution then Dave's suggested 'ripping out'.
I would love that.
I think a single license for all of Boost is very helpful to users. So the change would have to make the license status very clear. Some kind of 'historical', 'aberrant license' status maybe?
Personally, I don't think it makes much sense. It looks like in the very near future this library will be the one and only piece of Boost that is not under BSL. I think having one single special case hurts Boost way more than it helps. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (11)
-
Christopher Woods -
David Abrahams -
Henrik Sundberg -
Janek Kozicki -
John Maddock -
Malte Clasen -
Martin Bonner -
Michael Stevens -
Rene Rivera -
Thomas Witt -
Vladimir Prus