[License-review] For Approval: The BOS Public License v1.0
Carlo Piana
carlo at piana.eu
Fri Jul 24 07:26:54 UTC 2026
----- Messaggio originale -----
> Da: "Josh Berkus" <josh at berkus.org>
> A: "License submissions for OSI review" <license-review at lists.opensource.org>, "Harz Tronics"
> <harztronicsgmbh at gmail.com>
> Inviato: Giovedì, 23 luglio 2026 21:41:16
> Oggetto: Re: [License-review] For Approval: The BOS Public License v1.0
> On 7/22/26 2:44 PM, Harz Tronics wrote:
>> You can review the full license text and documentation here:
>> https://github.com/Luis-Harz/The-BOS-License <https://github.com/Luis-
>> Harz/The-BOS-License>
>> Thank you very much for your time and for reviewing this submission. I
>> look forward to hearing your feedback.
>
> Please attach a copy of the text to your submission. While we
> appreciate making it available via Github, we need a version that isn't
> subject to dynamic changes to evaluate.
[...]
>
> Overall, this license falls into the common trap of thinking of OSS as
> having an "original source" which was somehow created from scratch
> without using any other OSS components, and all downstream derivatives
> are copying most of its code, and directly from it. While direct
> forking certainly happens, so does minor code copying, downstream
> redistribution, project merging, aggregation into collections, etc. A
> new license should take the realities of modern OSS software
> distribution into account.
>
> --
> Josh Berkus
>
While we can't really discuss the legal text, since the link is broken and the submission is still lacking the required information, or the text of the license for that matter, I could not agree more with Josh. Judging from the description alone, the idea that there is one original source, or that the original copyright holder has special rights over downstream contributors of a project, is deeply flawed.
I am not even sure what shortcoming this license intends to cure compared to the hundreds of already existing non copyleft MIT-style licenses. While I cannot judge the actual condition, the idea to create a new type of condition (e.g. forks must put a backlink to the "original project") creates additional friction in the compliance process -- which is already a nightmare for a medium-sized embedded software project. Therefore I urge license submitter to introduce one only where there is a strong rationale. As a rule of the thumb, if in more than 25 years nobody thought of it, most likely it is not a perceived problem, unless something new has come around (see the SaaS model, or extensive AI model usage, etc.). This does not seem to be the case here.
Cheers
Carlo
More information about the License-review
mailing list