On Thu, 25 Mar 2021 at 06:23, Jens Maurer via Lib-Ext <
lib-ext_at_[hidden]> wrote:

> On 25/03/2021 04.43, Steve Downey via Lib-Ext wrote:
> > In the pre-meeting chatter for SG16 there was some conversation about
> proposed libraries and how ready they might be for adoption into
> implementation stdlibs. Some of the conversation was around "ugly style"
> and namespaces.
> > However, it's my understanding that license is a much more serious issue
> as to whether an implementation of a proposal can be pulled in to an
> implementation. I suspect that almost no non-trivial libraries have been
> imported directly, that is ones that aren't essentially fully defined by
> their synopsis.
>

[std::experimental::simd entered the chat]

The Intel PSTL probably counts too. And GCC's "STL" subset of the std::lib
was imported from the SGI STL (which was based on the HP STL code). It's
fairly small, but GCC's std::shared_ptr was forked from Boost's. Both MS
STL and GCC use the Ryu library for std::to_chars, although that's as an
implementation detail for one API, and it's not actually a "reference
implementation" of the standard API.


> The question is if implementers can examine the source,


There are no free software or open source licences that say you can't look
at the source code. Neither the code nor the licence can propagate to your
eyeballs. If you **copy** the code, you must respect the terms of the
licence (though maybe only if you distribute the copied code outside your
own home/company). Looking at code does not give you cooties.

Some large tech companies' lawyers might say their staff can't look at code
with certain licences, but that's a (stupid, FUD-spreading) company policy
not a condition of the licence.

Email me off-list for an extended version of this rant.



> if the library source is not encompassed in the standardisation proposal.
> I have heard that there are concerns that the Boost license addresses. I am
> not sure what those are, specifically. In particular with respect to a
> reference implementation of a proposal.
>

Consider the "solely in the form of machine-executable object code
generated by a source language processor" wording in the Boost licence.
Some licences are not suitable for template-heavy or header-only libraries
because the object code in your program is (arguably) a "derived work" of
the code in the headers, and so subject to the terms of the licence.


> > Can we address this, somehow, in the proposals without changing the
> licensing of the reference implementation? I am assuming that ISO rules
> already prevent patent traps and such.
>

No. A reference implementation that contains patented designs is covered by
that reference implementation's licence, not anything ISO says. Reference
implementations are not ISO documents and are not part of the standard that
WG21 publishes (via SC22, JTC1 and ISO/IEC).



>
> This seems thoroughly off-topic for this forum.
> It's each implementer's choice whether they care about any
> reference implementation supplied by the proposal submitter,
> at all.
>
> The job of WG21 is to make sure the specification is airtight
> enough such that independent implementations are possible
> and can be used to write portable programs. To that end,
> it's actually a disservice to WG21 if everybody re-uses
> the reference implementation instead of re-implementing
> from scratch, because we usually find bugs in the
> specification the moment we have independent implementations.
>
>
Absolutely agreed. While it's a lot more work (and I do not like having to
do any work, let alone more) the quality of the spec is always improved by
somebody trying to completely re-implement it **from the spec alone**. For
example, the std::filesystem spec is vastly better for having independent
re-implementations rather than just taking Boost.Filesystem. There are
always gaps between the reference implementation and the spec, and
sometimes contradictions.