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