Boost logo

Boost :

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2019-08-25 23:02:01

On 22/08/2019 21:37, Michael Caisse via Boost wrote:
> Copying to dev ML.
> On 8/22/19 12:05, Gerald Wiltse via Boost-users wrote:
>> During an annual third-party audit of our source code, boost intrusive
>> was flagged as containing unlicensed code. Specifically, there are
>> several pieces of code in this file which are explicitly attributed to
>> external parties on external websites, which still exist and show no
>> license.
>> Original sources:
>> I don't claim to be a license expert. I've read a lot over the years,
>> but this is the first time that I've actually been between an attorney
>> and a codebase having to figure out practical implications of a scenario
>> like this.
>> I first want to make sure that Boost committee is aware of this situation.
>> Second, I would like to know what the official conclusion would be from
>> the Boost Committee about the license implications in cases like these.
>> Maybe it has come up before and is well established. On the surface, the
>> implications seems ambiguous to me when: DEVELOPER_A takes unlicensed
>> code off the internet, prefixes it with a comment that says "Thanks to
>> DEVELOPER_B ", then prefixes the whole file with a file-level copyright
>> notice that says "COPYRIGHT  DEVELOPER_A", and then says it's
>> distributed under BSL-1.0 license, and then the boost team
>> re-distributes the source code.
>> Internally at my company, there was little discussion about it.  There
>> is no room for ambiguity, so the directive from management was to delete
>> the file from our SCM system completely and ensure it never is included
>> in our products.  VERY fortunately, deleting it doesn't seem to have
>> broken our builds.  In future cases like this, that's really not what we
>> want to be doing with your OSS libraries for obvious reasons.  So, I'd
>> like to know if there's any chance this situation changes in a future
>> version of Boost (I.E., the code be removed/re-written with clean-room
>> approach, etc).


I didn't expect those snippets in the public domain of well-known
methods could be a problem, and I explicitly thanked the authors.

I could just remove that section as compiler-specified methods are
available using clz and friends (that's why your build was not broken).



Boost list run by bdawes at, gregod at, cpdaniel at, john at