|
Boost : |
From: Michael Caisse (mcaisse-lists_at_[hidden])
Date: 2019-08-22 19:37:42
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%c2
>
> https://github.com/boostorg/intrusive/blob/develop/include/boost/intrusive/detail/math.hpp#L207-L208%c2%a0%c2
> Â
>
> Original sources:Â
> http://stackoverflow.com/questions/11376288/fast-computing-of-log2-for-64-bit-integers%c2
> 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). Â
>
> Regards,
> Jerry
>
> Gerald R. Wiltse
> jerrywiltse_at_[hidden] <mailto:jerrywiltse_at_[hidden]>
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk