[License-review] [new license] Blue Oak Model License 1.0.0
Lukas Atkinson
opensource at lukasatkinson.de
Wed Nov 8 20:06:50 UTC 2023
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
> 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
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
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.
The overbroad patent grant issue has previously been raised in
https://opensource.stackexchange.com/a/13891
and in the SPDX inclusion thread:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20231108/7aa96601/attachment.html>
More information about the License-review
mailing list