Any libraries now not under the Boost Software License?

[David Abrahams]

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thomas Witt-2]

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@...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christopher Woods]

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Abrahams]

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christopher Woods]

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost