[License-review] Request for License Review - BarrerSoftware License (BSL)v1.0

[Lukas Atkinson]

Aside from the glaring OSD#6 issues already discussed, this license seems
to be non-approvable for various other reasons.

Concerns that the license does not meet the bar for OSI approval:

* 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.

* The license is not reusable. The License-Review process (
https://opensource.org/licenses/review-process) 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 “special provisions” section). Overall, there are 30
separate occurrences of the company name.

* The “educational use” and “government use” sections seem to restate
permissions that have already been given, but could also be interpreted as
limiting permissions in these fields of use.

* The license says that “you may charge for services, not software”, but
doesn't clearly define “service”. 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?

Concerns that the license is unclear:

* 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 “appendix: legal
formalities” 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 “rationale”
section in the middle of the license, and a “philosophy” 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.

* The compatibility list is unclear. For example, it mentions the “GNU GPL
v3.0 (with non-commercial addendum)”. This conflicts with Section 7 of the
GPL-3.0, which governs “additional terms”. A “non-commercial addendum”
would surely qualify as an “additional restriction” 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.

* The license compatibility list also claims that Apache-2.0 and
BSD-family licenses are not compatible because those “allow
commercialization”. This is clear evidence of an intent to violate OSD#6,
regardless of what has been stated in the submission email.

* 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 “version history” section suggesting an intent to evolve the
license. On the other hand, the license defines “compatible license” as
“any license that  includes substantially similar restrictions on
commercial exploitation and requirements for perpetual free availability”,
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.

* The license uses “BSL” 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.

Historical context to consider:

* The SSPL has already been mentioned. During its review process there was
intense debate about where to draw the line to prohibit the “wrong” 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.

* 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.

* 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 –
rendering the prohibition against direct sales effectively irrelevant. In
contrast, this submission explicitly prohibits any monetization or bundling.

I'd therefore ask the OSI board to reject this license submission.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251230/282e1ed2/attachment.htm>