From: Christopher Woods (cwoods_eol_at_[hidden])
Date: 2007-05-29 15:19:06
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.
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)
_*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
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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk