[boost] About the new License

From: Jaap Suter (j.suter_at_[hidden])
Date: 2003-11-01 19:13:52

Hi,

first of all, is there any estimate on when the next Boost release will
occur? I have a few questions regarding the license changes that will occur
then.

How much of an active pressure is there towards trying to convert existing
Boost libraries to use the new license?

Are there any known libraries that, for their own reasons, definitely won't
adopt the new license?

Looking at the latest status of the CVS, there seem to be a lot of libraries
still that haven't adopted the new license. Is this simply a matter of
people not having time to do the changes? Will we just hope that eventually
all libraries will make the transition, even if it takes several Boost
releases?

Is it possible for the Boost website to provide a seperate distribution with
only those libraries that have the Boost license? Perhaps we can update John
Maddocks BCP tool to search for all the libraries with this license.

This brings up another question; what happens if a library with the Boost
license depends on a library that doesn't adopt the license yet. I
understand that the license only applies to the source in the library
itself, but such a dependency on another library pretty much defeats the
purpose of having a unified license in the first place.

Perhaps unapropriate, but would it be possible for the Boost website to
provide a list of companies that are willing to state they use Boost in
production code. I understand that we'll probably never know about many uses
of Boost, and I'm not really sure if the lawyers of company A care that
company B uses Boost, but I do feel that if we can get a few high-profile
companies to announce that they use (a subset of) Boost, that might help
other companies evaluating Boost and its legal issues.

And finally a bit couple of open questions:

I just read that Metrowerks apparently ships MW9 with a threading library
that uses the Boost.Thread interface. Are there any other known uses of
Boost interface or implementations like this? With other Boost libraries
(partially) defining standard interfaces (type-traits, smart pointers,
etc.), what effect will this have on the legal issues (most importantly
IP-infringement related) surrounding Boost libraries. Especially considering
the low-level nature of some of the libraries, the interface almost defines
the implementation. For example, anybody implementing the scoped_ptr
interface will pretty much end up with code the same as in the Boost
library, perhaps minus the portability workarounds. What does this mean for
the copyright of the original Boost scoped_ptr, especially considering that
anybody implementing its own scoped_ptr will probably have heard of Boost
and possibly even have looked at it.

Sorry if any of these questions have been answered in the past. I have
searched the Active State archives, but didn't get very much. I understand
everybody would much rather discuss development rather than legal issues, so
feel free to ignore this email.

Regards,

Jaap Suter