February 2019 License-Review Summary

In February, the License-Review mailing list discussed:

  • Convertible Free Software License (C-FSL)
  • Twente License
  • Server Side Public License, Version 2 (SSPL v2)
  • Review process, governance, and the OSD

The corresponding License-Discuss summary is online at https://opensource.org/LicenseDiscuss022019 and covers discussions on how to keep the mailing lists civil, and to what degree the business model of a license submitter should be relevant.

License Committee Report

Richard Fontana provides the license committee report. Currently, three licenses are under review:

  • C-FSL 1.4: A decision is due 2019-02-22.
  • SSPL v2: A decision is due 2019-02-18.
  • Twente License: A decision is due 2019-04-05.

Convertible Free Software License

In response to last month's review, Elmar Stellnberger clarifies that the Original Authors have to decide via consensus or set up their own statutes that cover their decision process.

Rob Landley points out that copyright transfers must be written and signed (at least in the US), so that a license like the C-FSL that tries to circumvent this requirement might not hold up in court.

Twente License

Anand Chowdhary submits his Twente License for approval. It is an MIT-style license, except that it also tries to ensure “European values” and privacy: derivatives of the software may only collect and share personal data with the user's prior consent.

Nigel Tzeng points out that this fails OSD #6 “No Discrimination Against Fields of Endeavor”, while Josh Berkus disagrees. Lawrence Rosen criticizes that the license tries to enforce values: “far more ambitious than software can protect with its mere open source licenses.” Eric Schultz suggests other ways than licenses for open source projects to express values, for example by refusing to support unethical use cases.

Bruce Perens adds a bit of historical background to the OSD: it was written to with anti apartheid licenses in mind that ended up hurting innocent people after the apartheid had ended. (Note: e.g. see Computers and the Apartheid Regime in South Africa)

Josh Berkus criticizes that licenses should not mandate values because the interpretation of these values can be quite subjective – thus making it unclear whether the license has been violated. Anand Chowdhary responds that while expressing certain values is the rationale of this license, the text of the license only contains a specific, unambiguous condition.

Carlo Piana [1,2] argues that it is not the job of licenses to ensure compliance with legal obligations: “the entire concept is wrong” and fails to account for changing laws over time.

Lukas Atkinson argues that data protection is not inherent in a software but depends on how the software is used. Therefore, a copyright license doesn't offer a suitable enforcement tool. And while the license seems to emulate the GDPR, it is both more narrow and more restrictive. Atkinson suggests that it might be a better approach to combine the MIT-like attribution requirement with a GDPR-like transparency requirement, but without directly restricting the use of the software. Carlo Piana thinks this is a good idea in principle, but that correctly implementing such a requirement in a license would be rather difficult. In response to this, Anand Chowdhary clarifies their goals and starts drafting a transparency clause.

Server Side Public License, Version 2

Eliot Horowitz (MongoDB) responds to criticism of the SSPL's section 13, and provides some clarifications. Horowitz proposes a rewritten section that explicitly defines “Software as a Service” as “enabling a user to interact with software remotely through a computer network.”

Bruce Perens appreciates this clarification, but notes that this definition was not subject to major objections. Instead, Perens suggest removing the concept of “Service Source Code” in favour of sticking with the AGPL's Corresponding Source concept. Perens summarizes his objections: that the Service Source Code concept attempts to encumber unrelated programs thus running into OSD #9, and that section 13 as written restricts fields of endeavour such as offering the software as a service, thus running into OSD #6.

I don't see how you can change this while keeping the intent of your license […] subsequent alterations to the license text have not substantially addressed [these objections].

Similarly, Brendan Hickey finds that the central objections have not been addressed, though Hickey also points out the SSPL's use of “value” and “primary purpose” as problematic. “What's so special about these claims versus others? Simply, a license that doesn't conform to the OSD must be rejected. As long as these problems are unresolved everything else – like the definition of SAAS – is just window dressing.” In contrast, Kyle Mitchell finds that Horowitz' clarifications address the objections he had.

Review process, governance, and the OSD

In the context of the SSPL review, Kyle Mitchell criticizes the OSI's license review process, in particular the weight given to Peren's voice. “I've lost confidence in this body's ability to make rigorous decisions, or even facilitate focused debate, on any remotely interesting new copyleft license.” Rick Moen quips: “I think Bruce is permitted to be correct and listened to, despite the admitted difficulty of his having credibility on the subject.”

Perens responds to Mitchell that he founds his SSPL criticism solely on the question whether the license can be Open Source: “This is not an issue of my being a honcho, but of clearly stated rules in the OSD that the license intent very obviously came into conflict with.” Perens is also happy to engage with new licensing ideas when they don't purport to be Open Source. In turn, Mitchell disagrees that the OSD would be so clear. “If OSD 6 banned any kind of [discrimination], GPLv2 discriminated against proprietary software makers.” “There should be a new, crips, clear rule on open source copyleft scope. OSD 9 isn't it.” Perens responds to individual points in Mitchell's message. “Free Software and Open Source drew a line in the sand, gave it a brand, and have defended that line. There will always be attempts to push it elsewhere, and they will always be resisted.”

Lawrence Rosen shares some of Mitchell's concerns regarding the scopes of the OSD versus SSPL, but thinks the discussion on these should be separated from the SSPL. In particular:

  • What components or other aspects of server applications are potentially subject to open source copyleft?

  • Is “corresponding source” more than only the Original Work and Derivative Works as defined in copyright law? How much more?

There's also some debate about the “silent majority” who do not participate on the license-review list. Do they approve of everything and would speak up otherwise? Or are they absent because they disagree with the review? Bruce Perens suggests a third option:

Very few people in the world want to be involved with license approval. Not even a majority of OSI directors. That's why what happens on this list is important. They're all trusting us to get it right.

Note: If you'd like to participate on the lists, head over to https://opensource.org/lists for information on how to subscribe.

To promote and protect open source software and communities...

For over 20 years the Open Source Initiative (OSI) has worked to raise awareness and adoption of open source software, and build bridges between open source communities of practice. As a global non-profit, the OSI champions software freedom in society through education, collaboration, and infrastructure, stewarding the Open Source Definition (OSD), and preventing abuse of the ideals and ethos inherent to the open source movement.

Open source software is made by many people and distributed under an OSD-compliant license which grants all the rights to use, study, change, and share the software in modified and unmodified form. Software freedom is essential to enabling community development of open source software.