[License-review] Request for Approval of 'CasperLabs Open Source License (COSL)

[Brian Behlendorf]

I admit to not having the time to digest the license in full, as the 
constant references to the Apache license while adding clearly 
non-Apache-inspired terms gave me substantial cognitive dissonance.

But from what I was able to parse, and Lukas's comments which seem 
sensible, it feels the same as concerns I shared about CAL - these kinds 
of terms belong in the governance agreements between participants on a 
blockchain network, not in the copyright terms on the code itself. They 
may think athey trigger on mere redistribution of the code (or deployment 
on a network) but they substantially hinder re-use and the right to fork 
in ways contrary to the spirit of the OSD.

Speaking as a full-time participant in this space, "Blockchain" doesn't 
change what has always made for the most successful approach to adoption 
of networked technologies: separating standards development, from 
implementation, from network governance. Imagine if ISC's copyright terms 
on BIND had required you to agree to use only a specific root TLD 
hierarchy for DNS resolution, hardwiring users to ICANN; or if Apache web 
server developers had required conformance to specific HTTP standards or 
specific TLS root CAa. Network governance rules, particularly in the 
blockchain space, need to be evolve-able and forkable. ICANN, CA Browser 
Forum, IANA, NANOG, and other groups formal and informal are governance 
organizations that have, imperfectly but improveably, forged an Internet 
infrastructure that's been able to support 30 years of evolution. Even the 
recent .org fiasco proves that overwired governance provisions (in this 
case ICANN's agreement with PIR) can and will be abused, so being able to 
adjust those kinds of terms over time is essential. Ongoing connection to 
a network, and the value embedded there, should be the carrot and stick to 
enforce agreements, not the right to use, modify, and redistribute 
the underlying open source code.

So even if one were to come up with such a license that confirmed to the 
OSD, I'd be disappointed if they were allowed to carry the "Open Source" 
label.

Brian


On Tue, 10 Dec 2019, Lukas Atkinson wrote:
> I don't see this license as a good candidate for approval. The main goal of the license seems to be to cement a particular business model, not to further software freedom. It is also a very unusual and
> complex license, without accompanying rationale for that complexity. Selected objections:
> 
> * By referencing some parts of the Apache 2.0 license, the document is very complex. But beyond importing some definitions and individual fragments, there is no real relation to the Apache license, despite
> what the Preamble section says.
> 
> * The license is specific to one “subject matter code base” per section 2. Indeed, the suggested license-proliferation category is “non-reusable”. But should new licenses in that category be approved? The
> license review process documentation on the OSI website is not entirely clear on that matter.
> 
> * The document imposes onerous obligations on any licensor, such as to designate moderators for a community forum (section 8). While the term “COSLv1.0 Licensor” is not defined, it probably relies on the
> Apache 2.0 term “Licensor”, which includes any Contributor. This feels like a license trap.
> 
> * The license terminates on unrelated activities, e.g. “Interfering with the Economic Operation of the Decentralized Platform”. That in turn is defined very broadly, including running DApps in a manner that
> changes the price of underlying cryptocurrencies. (The relevant sentence in section 7 is grammatically ambiguous, and could possibly also prohibit seeking to develop any DApp).
> 
> * In addition to being specific to a project, the license is also specific to distributed ledger technology. In contrast, the CAL manages to be geared to a similar subject matter, without being specific to
> it.
> 
> * Forking the project is subject to onerous terms, e.g. “Where code in a Fork is to be used to deploy a new independent blockchain with a cryptocurrency, […] that party is to notify the COSLv1.0 Licensor
> with an offer to compensate development efforts of the Community”.
> 
> * Many terms seem to boil down “the Licensor gets to decide”. That's not a license, that is process documentation.
> 
> * Many links in the license are not stable, but point to the master branch of some Git repo.
> 
> * The various requirements of the license are problematic in themselves, but they also clash with the OSD, e.g. arguably OSD #6 No Discrimination Against Fields of Endeavor, OSD #8 License Must Not Be
> Specific to a Product, OSD #10 License Must Be Technology-Neutral. I am not convinced that OSD #3 “The license must allow modifications” is fully fulfilled due to the various restrictions. The license terms
> also present an expansion of copyleft into the field of community governance and economic concerns, which is rather novel.
> 
> Some of these objections could be resolved with a revision of a license, but I'm not sure that a license that is OSI-acceptable would still meet CasperLab's licensing goals.
> 
>