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.
>>
>> https://github.com/boostorg/intrusive/blob/develop/include/boost/intrusive/detail/math.hpp#L156-L158
>>
>> https://github.com/boostorg/intrusive/blob/develop/include/boost/intrusive/detail/math.hpp#L207-L208
>>
>>
>> Original sources:
>> http://stackoverflow.com/questions/11376288/fast-computing-of-log2-for-64-bit-integers
>> http://www.flipcode.com/archives/Fast_log_Function.shtml
>>
>> 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).
Hi,
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).
Best,
Ion