Shared Component Licensefirst shot at a short, plain license in the vein of Mongo’s SSPL
Those following the public back-and-forth on MongoDB’s new Service Side Public License will have noticed that I think SSPL is open source, but not well crafted. The choice to patch AGPLv3 made everything hard. I should know. I made the same mistake with my own strong-copyleft license. Starting from BSD was bad enough to induce a rewrite from scratch. AGPLv3 is magnitudes worse, in ways glaring and subtle. Case in point: SSPL’s most important section is buried 4,100 words and 12 sections down.
The licensing project SSPL represents matters. The best criticism comes in-kind. So that’s the kind of criticism SSPL deserves. I’ve been laid up for weeks with an injury, and found myself with the time.
Follows now a first draft of a plain language license inspired by SSPL. This has not been shopped with other lawyers to date, and is not ready for use. I’m looking forward to reviewing, discussing, and refining on GitHub. If you’re interested, watch the repository or drop me a line.
Shared Component License
Developer: {Legal Name}
Homepage: {URL}
Purpose
This license gives you broad permission to work with this software for any purpose, but requires you to contribute source code for changes, additions, and superstructure.
Disclaimer
As far as the law allows, this software comes as is, without any warranty, and the developer will not be liable to anyone for any damages related to this software or this license, for any kind of legal claim.
Acceptance
In order to receive this license, you must agree to its rules. The rules of this license are both obligations under our agreement and conditions to your license. You may not do anything with this software that triggers a rule you cannot or will not follow.
Copyright
The developer licenses you to do everything with this software that would otherwise infringe copyrights in this software they can license.
Patent
The developer licenses you to do everything with this software that would otherwise infringe any patent claims they can license.
Reliability
The developer will not revoke this license.
Notices
You must ensure that everyone who gets a copy of any part of this software from you, in source code or any other form, with or without changes, also gets the text of this license, including its developer and homepage lines.
Contribution
When this license requires you to contribute software:
Publish all source code for that software, in the preferred form for making changes, through a freely accessible distribution system widely used for similar source code, so the developer and others can find and copy it.
License that software under the terms of this license, so the developer and others may work with that software. Alternatively, you may license that software on other terms with substantially the same legal effect as Copyright, Patent, and Reliability. Your other terms may, but need not, include a rule like Notices, a disclaimer like Disclaimer, or both, but no other terms. For example, you may license under the BSD-2-Clause Plus Patent License.
Changes
Contribute changes to files containing this software.
Additions
Contribute additions to this software. You need not contribute additions to other software that only invokes this software’s functionality through the interfaces this software exposes, unless Superstructure requires.
Applications
You need not contribute applications that only invoke this software’s functionality through the interfaces this software exposes, unless Superstructure requires.
Superstructure
Contribute software used to expose this software’s interfaces and functionality to applications. For example, contribute software for managing instances of this software, orchestrating its deployment, logging its activity, monitoring its performance, or backing up its data.
Interfaces
Interfaces exposed by this software include all the interfaces this software provides users or other software to invoke its functionality. For example, command line, graphical, application programming, remote procedure call, and inter-process communication interfaces.
Excuse
You are excused for unknowingly breaking Notices, Changes, Additions, or Superstructure if you do what the rule requires, or stop doing anything requiring this license, within 30 days of learning you broke the rule.
How does this draft compare to SSPL, substantively?
Like SSPL, the draft substantially strengthens copyleft. It follows the line of OSL, AGPLv3, Q, and RPL in that respect.
Like SSPL, the draft applies that strengthened copyleft selectively. In particular, the draft carves out a permissive use case: building applications using the licensed code. I’ve written about that innovation and its political consequences.
Unlike SSPL, the draft uses different rules to draw the boundary between changes and additions that have to be contributed, and applications that don’t. As a baseline, the draft uses an MPL 2.0-style, file-based copyleft. On top of that, the draft sweeps additions to the functionality of the licensed software by drawing a boundary at the interfaces the licensed software exposes.
Like SSPL, the draft follows network-copyleft licenses in triggering copyleft without distribution, and reciprocal licenses in requiring publication, rather than in-band distribution, of source. SSPL has to trigger that way for service superstructure, since service superstructure code isn’t distributed to service users. But SSPL keeps GPL-style copyleft for changes and additions. Using the same distribution requirement for all kinds of code in the scope of copyleft brings the draft closer to RPL. The draft is an actual patches-back license, not a patches-forward license that only incidentally empowers users to send code back.
Unlike SSPL, the draft generalizes from service programs to all programs, by drawing the line using an abstraction: interfaces to functionality. Within the draft, “interfaces” means not just APIs, but CLIs, RPCs, IPCs, or similar mechanisms. The line between code extending the licensed software that must be contributed back—change or addition—and code that need not—application—is whether the other software merely uses the licensed software through the interfaces it exposes.
Unlike SSPL, the draft gives users the option to license the code contributed back under permissive terms. SSPLv2 added some of this flexibility for code within its sweep that the licensee lacks the rights to relicense. Under the draft, permissive is always an option.
Like SSPL, which inherited from AGPL, the draft include an automatic-forgiveness provisions for unknowing violations of license rules. SSPL uses a more formal notice protocol. This draft follows Parity in turning on knowledge, which notice of a violation can induce.
Of course, these are hardly all the similarities and differences. But at less than 550 words, it’s quick enough to read the whole license.
The key issues in my mind, going forward:
- What parts won’t be clear to developers? Any confusing parts?
- Can we improve the boundary between changes and additions, on the one hand, and applications, on the other?
- Can we improve the boundary between applications and superstructure?
- Can we find a better term than “superstructure”?
Open an issue on GitHub or drop me an e-mail anytime.
Your thoughts and feedback are always welcome by e-mail.