[License-review] [new license] Blue Oak Model License 1.0.0

[Carlo Piana]

> Da: "Lukas Atkinson" <opensource at lukasatkinson.de>
> A: "License submissions for OSI review" <license-review at lists.opensource.org>
> Inviato: Mercoledì, 8 novembre 2023 21:06:50
> Oggetto: Re: [License-review] [new license] Blue Oak Model License 1.0.0

> The license is evidently OSD-compliant and should probably be approved.

> Similarly, Richard Fontana's one-line review for the Fedora allowed-licenses
> list 9 months ago:
> [
> https://gitlab.com/fedora/legal/fedora-license-data/-/issues/148#note_1254904069
> |
> https://gitlab.com/fedora/legal/fedora-license-data/-/issues/148#note_1254904069
> ]

> > This license clearly meets Fedora's standards for allowed licenses.

> But in my very amateur opinion, it is not yet the best license that it could be:

> 1. While attempting to be maximally permissive in as few words as possible, the
> copyright license does not consider potentially non-licenseable aspects of
> copyright such as moral rights. Unusually, the license does not even expect the
> preservation of copyright notices. This might be dismissed by pointing out that
> the license won't override applicable laws, so some attribution might still be
> required. But especially in an international context, being silent on this
> aspect could cause confusion about which exact rights were licensed and which
> compliance obligations exist. The CC0 mechanism (promise not to exercise or
> assert any remaining rights) seems much clearer.

> Insufficient international consideration and the problem of moral rights has
> been noted by license co-author Kyle Mitchell in [
> https://news.ycombinator.com/item?id=19350503 |
> https://news.ycombinator.com/item?id=19350503 ]

> These issues have also been raised previously by Thorsten Glaser on the
> license-discuss list: [
> https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-July/020901.html
> |
> https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-July/020901.html
> ]

Thanks, indeed this is not my favorite license by far and I would personally not recommend it because I think it goes too far on using layman's terms in an effort to clarity, which ends up detracting from legal certainty. But this is my -- probably biased -- personal opinion. 

For the rest, I also do not spot any reasons why it should not be approved. I am open to read contrarian opinions. 

On the moral rights, mind that these are not licensable, so anything the license says one way or the other, nothing changes. I take the opinion that moral rights are probably not relevant in software as they are in creative, but arguing this would be too long. Probably only the authorship right has some bearing. 

On the other hand, people conflate attribution (as in CC-BY) with protection of moral rights. They only overlap, but are not the same thing. You can comply with CC-BY and not giving proper attribution under moral rights. Attribution of authorship is a right to not being denied claims of authorship. How this pans out depends on many circumstances and it basically resolves in not intentionally obfuscating or denying or unduly limiting or belittling the attribution as it was made by the author, if they have claimed. And it must be personal to the author(s) as individuals, not to a group, not to a company, not to a government etc. 

In a nutshell, coming from a moral right jurisdiction, the fact that moral rights are not dealt with does not concern me much, as it is largely orthogonal to the text of the license and little you could do. 

> 2. The "strong patent grant" looks so broad that it would be completely unsafe
> for anyone who might come into contact with patents to contribute to Blue Oak
> covered software. Companies should have policies against contributing to Blue
> Oak covered software. The Apache-2 mechanism (limiting the patent grant to
> those aspects that would be "necessarily infringed by their Contribution")
> seems much more reasonable.

Well, GPLv3 has a very strong patent license. Surely the most important thing is that those holding a patent portfolio and not wishing to dilute it in a non-copyleft license understand the consequences of using such license. Once this is clear, I expect the lawyers involved in the process to be sophisticated enough. 

> The overbroad patent grant issue has previously been raised in [
> https://opensource.stackexchange.com/a/13891 |
> https://opensource.stackexchange.com/a/13891 ]
> and in the SPDX inclusion thread: [
> https://github.com/spdx/license-list-XML/issues/800#issuecomment-471449910 |
> https://github.com/spdx/license-list-XML/issues/800#issuecomment-471449910 ]

> I don't think these aspects are fatal though: downstream distributors can avoid
> issue 1 by voluntarily giving attribution beyond the Notice explicitly required
> by the license, and issue 2 can be avoided by licensing downstream
> modifications under a different license like Apache-2. Thus, the license
> doesn't encumber downstream Software Freedom.

> Still, issue 2 is giving me pause. It is a surprising and unusual term. If this
> license were OSI-approved, some people might incorrectly think that they can
> safely contribute to projects under this license.

Please note that we at OSI are trying to have a taxonomy that goes beyond "approved/not approved" in giving information to those chosing licenses. But if a license is sufficiently marking all checkboxes in OSD, it has been submitted according to the policy, it is not up to OSI to question the merit of the license, IMHO or to raise "recommendations". I have my own (I am public with that), everyone is entitled to their. 

Cheers, 

Carlo 
(personal opinions only here). 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20231109/6d91dc91/attachment.html>