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 |

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 |

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 /$

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 |

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.

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

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

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

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

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