Use Boost Software License

[alt-graph]

With this MR I propose changing our main license for GUL17 to the Boost Software License (BSL) v1.0.

[why]

Read https://www.boost.org/doc/user-guide/bsl.html for a rationale of
why the BSL is a good choice especially for foundational C++ libraries.
In a nutshell, most other licenses require a copyright notice to appear
in the final product even when the library is used in binary form, which
the BSL does not require. This makes the library easier to use in other
software.

[how]

Replace the old license.txt with the LGPL-2.1 text by a LICENSE.md with
the BSL 1.0 text. Move our copyright and license information from the
documentation website into README.md where it is much more accessible.
The website just retains a link to the BSL and to the README.

Finally, replace license information in file headers where necessary.

[soerengrunewald]

Is Boost compatible with MIT and CC0 in regards to sub-licensing? Or in other works do we have to mention MIT/CC0 also in binary form?

OT: I always thought that having some form of acknowledgement to the work was a good thing.

[alt-graph]

Is Boost compatible with MIT and CC0 in regards to sub-licensing? Or in other works do we have to mention MIT/CC0 also in binary form?

I'm not a lawyer, but I'd say it is compatible with CC0 because in CC0 the authors waive their rights to the maximum possible extent. It is probably incompatible with MIT because it grants an additional freedom (to build a program/library that does not contain copyright information in its binary form). That is why the README lists the date.h header as an exception. It is not under the BSL, but under its original MIT license.

In theory – as far as I understood the Boost argument – a DOOCS server that uses the date.h header might have to display the copyright information of that file somewhere or come with a file with the license text:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

At least some lawyers might read it that way... 🤷

OT: I always thought that having some form of acknowledgement to the work was a good thing.

That is not OT at all. :-)

In fact, the LGPL would theoretically give us more acknowledgement across all possible use cases of the library. But that argument is kind of moot if nobody except us uses it – which seems to be the case. The advantage of the BSL is that it makes it easier to reuse the code for anyone out there. Personally I find that more important for this kind of library.

[Finii]

I still struggle to see the 'why'.

Is there any known case where the LGPL hindered adoption of GUL17? Any complained, or even some mild comment by someone from the outside?

I must admit I see no possible outside use for GUL17, especially after we dropped normal packages with the GUL14-to-GUL17 transition and now only build 'doocs compatible/style' packages and have a doocs-centric versioning.

The only consumer of GUL17 (that I can imagine) is Doocs. I also gave up using GUL for non-doocs projects.

For me it makes no sense to have a different license for the doocs clientlib compared to GUL17 (because my feeling is GUL is anyhow just a basic building block for the client library).

So in principle I believe LGPL is perfectly suitable for GUL, and the rationale given by Boost for their license just does not make any sense for GUL. Do we expect that parts of GUL become standard library stuff? ;-)

[alt-graph]

The only consumer of GUL17 (that I can imagine) is Doocs. I also gave up using GUL for non-doocs projects.

For me it makes no sense to have a different license for the doocs clientlib compared to GUL17 (because my feeling is GUL is anyhow just a basic building block for the client library).

So in principle I believe LGPL is perfectly suitable for GUL, and the rationale given by Boost for their license just does not make any sense for GUL. Do we expect that parts of GUL become standard library stuff? ;-)

The LGPL is a bit of a burden. If I want to write a small stand-alone tool that uses SmallVector, I currently have two options:

• Declare an external dependency on GUL17 and publish my tool as I like, with a GUL17 copyright notice tucked away somewhere. We all know external dependencies are a pain in the ***, so I won't do that.
• Copy the SmallVector header into my tool and release it under the GPL. No other license is allowed, even if I would prefer to put the tool under MIT license or whatever.

IMO a more permissive license would make the code more useful – at least for future you and me, if there are no "external" users.

[Finii]

IMO a more permissive license would make the code more useful – at least for future you and me, if there are no "external" users.

For all what WE do I guess mentioning is 100% ok, so MIT is probably ok. But the absolute waiver of BSL - needed specifically for standard library adoption and commercial usecase that do not want to acknowledge... 🤔

[alt-graph]

IMO a more permissive license would make the code more useful – at least for future you and me, if there are no "external" users.

For all what WE do I guess mentioning is 100% ok, so MIT is probably ok. But the absolute waiver of BSL - needed specifically for standard library adoption and commercial usecase that do not want to acknowledge... 🤔

I would be perfectly happy with MIT as well. Boost just came to mind because most of our old backports used it. Should I rewrite this MR to use MIT?

[zykure]

The MIT license feels more suitable to our use-case for me too. I get the point of switching to a more permissive license for an utility library like GUL, but BSL goes beyond what we need and we're surely not operating on the same scale here as Boost does. Also if this does become an issue in the future, we could still adopt another license again.

[Finii]

we could still adopt another license again

I think switching is rather cumbersome, as all developers need agree; even retired ones 😬

But this looks like all 4 participants of this thread would come along to MIT.

I would compile a list of contributors that need to accede, and let them state their consent here.
If all go with the switch the PR can be changed. In this order I would do it.

Lets see

$ git log | grep '^ +[-A-Za-z]+-[-A-Za-z]+: |^Author:' | grep -v 'Date:|Reported-by:' | sed 's/[^:]*: //' | sort | uniq

Translate to Github users...

@Finii @zykure @alt-graph @ohensler @soerengrunewald plus Tim

This means ohensler and Tim missing, yet.

Where Tim just changed the version number once, and Olaf removed one file.
So we are already complete?

Edit: Add image of clicki-bunti solution

[alt-graph]

This means ohensler and Tim missing, yet.

Where Tim just changed the version number once, and Olaf removed one file. So we are already complete?

Tim gave his consent to changing the license at the very beginning of this process (which is where this MR came from), and Olaf just confirmed to me that he has no opinion on the matter. This means we are complete. I'll rewrite this to MIT and take away the "draft" status when I'm done.