<div dir="ltr"><div dir="ltr"><div>The license is evidently OSD-compliant and should probably be approved.</div><div><br></div><div>Similarly, Richard Fontana's one-line review for the Fedora allowed-licenses list 9 months ago:</div><div><a href="https://gitlab.com/fedora/legal/fedora-license-data/-/issues/148#note_1254904069">https://gitlab.com/fedora/legal/fedora-license-data/-/issues/148#note_1254904069</a></div><div><br></div><div>> This license clearly meets Fedora's standards for allowed licenses.</div><div><br></div><div>But in my very amateur opinion, it is not yet the best license that it could be:</div><div><br></div><div>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.</div><div><br></div><div>Insufficient international consideration and the problem of moral rights has been noted by license co-author Kyle Mitchell in <a href="https://news.ycombinator.com/item?id=19350503">https://news.ycombinator.com/item?id=19350503</a></div><div><br></div><div>These issues have also been raised previously by Thorsten Glaser on the license-discuss list: <a href="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</a></div><div><br></div><div>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.</div><div><br></div><div>The overbroad patent grant issue has previously been raised in <a href="https://opensource.stackexchange.com/a/13891">https://opensource.stackexchange.com/a/13891</a></div><div>and in the SPDX inclusion thread: <a href="https://github.com/spdx/license-list-XML/issues/800#issuecomment-471449910">https://github.com/spdx/license-list-XML/issues/800#issuecomment-471449910</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div>