DR–0004-Boost-license

⦿ decision-record

1  Status

  • ACTIVE

  • REPLACE DR–0003-LGPL-license

2  Context

In Dok, libraries can be managed like templates, i.e. specialized and then injected inside the code of the combined-work.
If these libraries are under a “viral license” like GPL and LGPL then also the derived work will be affected because the code of these libraries is not anymore distinct from the derived work, but it became part of it.

3  Decision

The permissive license Boost Software License v1.0 (BSL) will be used, because:
  • the library code can be injected inside derived work code without affecting its license

  • it is the license of C++ STL Boost libraries, that are used in a lot of projects with different licenses, using a compilation process similar to Dok

  • the derived works binary distributions are not obliged to credit the used libraries, so it is less stringent than MIT and BSD licenses

  • it is an OSI approved license

  • it is short and simple to read

Despite being released under BSL, Dok can (re)use the source code of other libraries released under many different licenses. So Dok MUST include a licensing management tool for analyzing the libraries usend in each distinct project and inferring:
  • the final license of the derived work

  • if the derived work MUST be relinkable with newer versions of used LGPL libraries

  • the credits to give to used libraries in source-code and in binary distribution

  • other licensing aspects

DokMelody documentation that is not part of the source code will be released under CC-BY–4.0. It is a well known license, good for documentation material, used from many big projects like Wikipedia.

3.1  Boost Software License 1.0 text

Boost Software License - Version 1.0 - August 17th, 2003
Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the “Software”) to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following:
The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

3.2  How to apply the license

Every (also minor) source code file must start with an header comment like

SPDX-License-Identifier: BSL–1.0
Copyright (C) 2019 Author Name <author-email@example.net>
Authors and contributors must add them self to the list of copyright holders, when they change a file.
Contributors of minor bug-fixes and minor patches can also not add them self to the list of copyright owners of the file. In this case the project repository history will give them credit.
Some source files can contain source-code under different licenses. They will use the proper SPDX identifier.
Ownership of source files is distributed between all contributors.

3.3  Problems with LGPLv3+

LGPLv3+ license was previously considered but discarded.
LGPLv3+ enforces a very nice and fair “right to repair”, i.e. the user of a product X using a LGPL library L MUST be able to create a new version of X using a different/improved/patched version of library L.
But LGPLv3+ can not be called from GPLv2 code bases, and there are many interesting projects using GPLv2 instead of GPLv2+. So there is some fragmentation problem for (L)GPL-like licenses.
Worse using LGPLv3+ in DokMelody IDE tools, there can be annoying complications because DokMelody IDE will transform the source code injecting some LGPLv3+ source code, then:
  • or the original version of the source code MUST be maintained, for allowing a transformation with a new version of the LGPLv3+ library, despite the injected code is usually very trivial

  • or the source code must be released under GPLv3+ license

GPL and LGPL with a static linking exception and other similar exceptions can be right in Dok/DokMelody but they make more difficult reusing code from other plain GPL and LGPL projects because they are not compatible together.
So despite LGPLv3+ philosophy is very fair and reasonable, its usage in practice can introduce annoying problems.