<div dir="ltr"><div dir="ltr"><div>Aside from the glaring OSD#6 issues already discussed, this license seems to be non-approvable for various other reasons.</div><div><br></div><div>Concerns that the license does not meet the bar for OSI approval:</div><div><br></div><div>* The license reads like it was drafted by AI tools. This alone should be grounds to stop reading the license, but for the sake of the argument let's continue.</div><div><br></div><div>* The license is not reusable. The License-Review process (<a href="https://opensource.org/licenses/review-process">https://opensource.org/licenses/review-process</a>) clearly requires that new licenses are reusable. However, the entire license is specific to the submitter's company, even mentioning various products in the middle of the text (e.g. see the \u201cspecial provisions\u201d section). Overall, there are 30 separate occurrences of the company name.</div><div><div><br></div><div>* The \u201ceducational use\u201d and \u201cgovernment use\u201d sections
seem to restate permissions that have already been given, but could also
be interpreted as limiting permissions in these fields of use.</div><div><br></div><div>* The license says that \u201cyou may
charge for services, not software\u201d, but doesn't clearly define
\u201cservice\u201d. I remember a discussion about this term during the SSPL
reviews, but the two licenses seem to use the term very differently.
Concretely: is paid Software-as-a-Service allowed? Would it be possible
to charge for hosting services?</div><div><br></div><div>Concerns that the license is unclear:</div></div><div><br></div><div>* The license has an inherently unclear structure. It consists of a brief summary with bullet points (legally binding), followed by what seems to be the main license (also legally binding), followed by an \u201cappendix: legal formalities\u201d that's supposed to define the formal license, but with the above sections having precedence. Many sections in the main(?) license do not contain license terms and are merely informative. E.g. they instruct recipients how to report license violations. They provide statements of intent for dealing with license violations. There's a lengthy \u201crationale\u201d section in the middle of the license, and a \u201cphilosophy\u201d section a bit later. This is not just confusing for people who are used to reading Open Source licenses, but probably also entirely confusing for folks who are not. Unless I go through the effort of creating a consolidated version that combines the three parts, I have no idea what the actual rights and conditions are.</div><div><br></div><div>* The compatibility list is unclear. For example, it mentions the \u201cGNU GPL v3.0 (with non-commercial addendum)\u201d. This conflicts with Section 7 of the GPL-3.0, which governs \u201cadditional terms\u201d. A \u201cnon-commercial addendum\u201d would surely qualify as an \u201cadditional restriction\u201d as far as the GPL is concerned and would be ineffective. While the intent here is clear, the actual effect is not, and approval of unclear licenses should be avoided.</div><div><br></div><div>* The license compatibility list also claims that Apache-2.0 and BSD-family licenses are not compatible because those \u201callow commercialization\u201d. This is clear evidence of an intent to violate OSD#6, regardless of what has been stated in the submission email.</div><div><br></div><div>* The license compatibility mechanism may or may not allow for license version upgrades. There is no explicit provision for later versions, though there is a \u201cversion history\u201d section suggesting an intent to evolve the license. On the other hand, the license defines \u201ccompatible license\u201d as \u201cany license that includes substantially similar restrictions on commercial exploitation and requirements for perpetual free availability\u201d, which could be viewed as an unusually broad upgrade clause. Having an upgrade mechanism has never been a precondition for OSI approval, but this point is illustrative of this license's general vagueness.</div><div><br></div><div>* The license uses \u201cBSL\u201d as an abbreviation. Per SPDX this abbreviation refers to the (OSI-approved) Boost Software License, though it's also commonly used for the (non-Open) Business Source License. A different abbreviation might avoid confusion.</div><div><br></div><div>Historical context to consider:</div><div><br></div><div>* The SSPL has already been mentioned. During its review process there was intense debate about where to draw the line to prohibit the \u201cwrong\u201d kind of commercial exploitation. There is now clear consensus that the SSPL does not comply with the OSD. Similarly, this suggests that the present submission is far away from what can be considered OSD-compliant.</div><div><br></div><div>* The Cryptographic Autonomy License was a successful (though controversial) example of pushing the boundaries of what can be considered OSD-compliant. However, its submission had a clear argument that its data migration provisions are *necessary* to ensure full Software Freedom. In contrast, the current submission lacks such a clear argument.</div><div><br></div><div>* The SIL Open Font License is a fascinating specimen that forbids sale of the licensed software itself. On the face of it, this is an OSD#6 violation. However, this is a relatively old license, and new submissions should be held to a higher standard. The SIL-OFL also doesn't prohibit all commercialization, and allows sales when bundled with other software \u2013 rendering the prohibition against direct sales effectively irrelevant. In contrast, this submission explicitly prohibits any monetization or bundling.</div><div><br></div><div>I'd therefore ask the OSI board to reject this license submission.</div></div></div>