On Sun, 18 Aug 2019, 18:55 Paul A Bristow via Boost,
Prompted by some recent discussion of Boost license and copyright info by the Debian package team,
[...]
Now that the 1.71 release is out bar a little shouting, I wonder if we should focus on improving compliance for the next release?
I’d like to propose
1 A boost/tools/inspect/develop branch to refine the inspect program a little and improve the documentation (I have done something on this already for my education and use).
2 Discussion of the bad results (zip attached) to try to find why there are so many reports and to decide what to do.
3 Encourage all authors to run inspect on their library locally and try to remedy the items missing.
4 I suspect that many libraries will have items missing but the authors are also missing. So someone from the community maintenance team will need to take over and make some decisions on what to do. Often just providing a copyright claim from the obvious author and Boost license will suffice?
5 Try to improve the compliance with other guidelines. For example. there are many libraries that are failing to prevent with min and max macros for what of a couple of brackets. Usually (std::numeric_limits<>::max)(). All these will trip up Windows users in a puzzling way. Please can we just fix these?
+1 Boost Inspection Report
Inspect version no 3.1.15 Run Date: 08:44:19 UTC, Saturday 17 August 2019 Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) Copyright Boost 2019
boost-no-inspect Inspection from path "libs" including subfolders. Totals: 52355 files scanned 4351 directories scanned (including root) 3472 problems reported
Problem counts: 1790 files missing Boost license info or having wrong reference text 1682 files missing copyright notice
Worst Offenders: outcome 940 metaparse 556 polygon 228 python 194 beast 192
Summary: algorithm (4) array (2)
FYI, I made an attempt a while ago to fix the array: https://github.com/boostorg/array/pull/9 -- Mateusz Loskot, mateusz@loskot.net (Sent from mobile, may suffer from top-posting)