I'm guessing from reading through the 1.32 tarball docs that the this release will still have some libraries that are not under the Boost 1 license. Is this the case? If so, is there a definitive list of these projects? Jared McIntyre
At 05:42 PM 11/7/2004, Jared McIntyre wrote:
I'm guessing from reading through the 1.32 tarball docs that the this release will still have some libraries that are not under the Boost 1 license. Is this the case?
Yes, but John Maddock put in a great deal of effort contacting boost contributors, and so we are in far better shape with this release than the last one.
If so, is there a definitive list of these projects?
See http://www.boost.org/regression-logs/license_report.html It identifies every file with a potential license or copyright problem. That allows you pretty quickly to see what the license status is of any library you are interested in. --Beman
On Nov 7, 2004, at 6:46 PM, Beman Dawes wrote:
At 05:42 PM 11/7/2004, Jared McIntyre wrote:
I'm guessing from reading through the 1.32 tarball docs that the this release will still have some libraries that are not under the Boost 1 license. Is this the case?
Yes, but John Maddock put in a great deal of effort contacting boost contributors, and so we are in far better shape with this release than the last one.
I am _so_ dissed :)
If so, is there a definitive list of these projects?
See http://www.boost.org/regression-logs/license_report.html
It identifies every file with a potential license or copyright problem. That allows you pretty quickly to see what the license status is of any library you are interested in.
--Beman
It's a little bit misleading to look at just the error counts in that list, because that checker also looks for missing Boost license info in documentation, which doesn't really affect users. We would do well to scan that list and make a short list of libraries that still use non-BSL licenses for this release. I offer to do that tomorrow. Doug
I'm guessing from reading through the 1.32 tarball docs that the this release will still have some libraries that are not under the Boost 1 license. Is this the case? If so, is there a definitive list of these projects?
Not as such, remember that lib A may include headers from lib B and so you have to check dependencies as well as specific libraries. You can always use the bcp tool to produce a report of the licences in use for a particular sub-set of Boost. See for example http://freespace.virgin.net/boost.regex/reports/. John.
"John Maddock" <john@johnmaddock.co.uk> writes:
I'm guessing from reading through the 1.32 tarball docs that the this release will still have some libraries that are not under the Boost 1 license. Is this the case? If so, is there a definitive list of these projects?
Not as such, remember that lib A may include headers from lib B and so you have to check dependencies as well as specific libraries. You can always use the bcp tool to produce a report of the licences in use for a particular sub-set of Boost. See for example http://freespace.virgin.net/boost.regex/reports/.
Oh, nasty. If your tests use the Boost.Test library your library shows up as dependent on all of its dependencies. So for example the iterators library is showing up as dependent on all of these, on which it does *not* depend. boost/detail/binary_search.hpp boost/test/detail/fixed_mapping.hpp libs/test/src/unit_test_result.cpp libs/test/src boost/test/detail/basic_cstring/basic_cstring_fwd.hpp boost/test/detail/basic_cstring/basic_cstring.hpp boost/test/detail/unit_test_config.hpp boost/test/execution_monitor.hpp libs/test/src/execution_monitor.cpp -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Oh, nasty. If your tests use the Boost.Test library your library shows up as dependent on all of its dependencies. So for example the iterators library is showing up as dependent on all of these, on which it does *not* depend.
Good point, unfortunately there is no definitive list of which header-files belong to which library, so using the test files to track dependencies is very much second best, and as you say gives misleading results, any better ideas appreciated, John.
"John Maddock" <john@johnmaddock.co.uk> writes:
Oh, nasty. If your tests use the Boost.Test library your library shows up as dependent on all of its dependencies. So for example the iterators library is showing up as dependent on all of these, on which it does *not* depend.
Good point, unfortunately there is no definitive list of which header-files belong to which library, so using the test files to track dependencies is very much second best, and as you say gives misleading results, any better ideas appreciated,
Isn't Boost.Test unique in that way? Maybe just a special case...? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (1)
-
Beman Dawes -
David Abrahams -
Doug Gregor -
Jared McIntyre -
John Maddock