Created
March 10, 2019 03:36
-
-
Save kemitchell/70f87df932c563d259c3dcae9a4591f5 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| <?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.6.2">Jekyll</generator><link href="https://writing.kemitchell.com/atom.xml" rel="self" type="application/atom+xml" /><link href="https://writing.kemitchell.com/" rel="alternate" type="text/html" /><updated>2019-03-09T19:32:14-08:00</updated><id>https://writing.kemitchell.com/</id><title type="html">/dev/lawyer</title><subtitle>law, technology, and the space between</subtitle><author><name>Kyle E. Mitchell</name></author><entry><title type="html">Deprecation Notice: MIT and BSD</title><link href="https://writing.kemitchell.com/2019/03/09/Deprecation-Notice.html" rel="alternate" type="text/html" title="Deprecation Notice: MIT and BSD" /><published>2019-03-09T00:00:00-08:00</published><updated>2019-03-09T00:00:00-08:00</updated><id>https://writing.kemitchell.com/2019/03/09/Deprecation-Notice</id><content type="html" xml:base="https://writing.kemitchell.com/2019/03/09/Deprecation-Notice.html"><p>MIT and BSD open source licenses are well known, popular, and legally deprecated. They served long and well, but they’re older than many open source software developers, and haven’t been maintained.</p> | |
| <p>With licenses like <a href="https://blueoakcouncil.org/license/1.0.0">Blue Oak</a> available, it’s time open source upgraded from academic forms of the ’80s. There are good social, practical, and especially legal reasons to do so.</p> | |
| <h2 id="mit-and-bsd-dont-handle-patents">MIT and BSD don’t handle patents.</h2> | |
| <p>Both copyrights and patents apply to software, but the word “patent” does not appear in MIT or BSD terms. <a href="http://stlr.org/2018/10/15/the-truth-about-oss-frand-by-all-indications-compatible-models-in-standards-settings/">MIT and Cal’s tech transfer offices say they never intended to license any patents.</a> There is <a href="https://opensource.com/article/18/3/patent-grant-mit-license">some argument</a> that other words, like “use”, imply permission under patents, anyway. And there is <a href="http://stlr.org/2019/03/04/oss-and-frand-complementary-models-for-innovation-and-development/">some law</a> that may or may not imply patent permission, when giving someone a copy of software. But a license can avoid all that uncertainty by spelling out plainly that it covers all relevant intellectual property. MIT and BSD don’t.</p> | |
| <p>Licenses like <a href="https://spdx.org/licenses/Apache-2.0.html">Apache 2.0</a> show how lawyers do this in legal terms for private deals every day. <a href="https://blueoakcouncil.org/license/1.0.0#patent">Blue Oak</a> shows the same job done in everyday English, without long lists, run-on sentences, or complex scope rules.</p> | |
| <p>Patents are a problem that MIT and BSD do not solve. Open source developers have better options, at no real cost, with significant additional benefits. Even developers and companies that despise software patents, and will never seek them, benefit by choosing modern terms. It’s one thing to know that <em>you</em> won’t seek or enforce any patents. It’s quite another to have legal assurance from <em>others</em> that they, or their successors, won’t lay a patent trap.</p> | |
| <h2 id="mit-and-bsd-are-hard-to-read">MIT and BSD are hard to read.</h2> | |
| <p>When you tell a lawyer to keep it short, their first draft will cheat by drawing heavily on background law and legal vocabulary. They’ll <em>invoke</em> complex concepts, rather than identifying or explaining them, often with cues non-lawyers won’t catch. It’s an extra, laborious, intellectually grueling step to translate the whole legal message into everyday words and phrases. <a href="https://blueoakcouncil.org/2019/03/06/model.html#language-simplified">Blue Oak made that extra investment</a>. MIT and Cal did not.</p> | |
| <p>As a result, the shortness of MIT and BSD are reassuring only until you actually try to understand them, and find you need a decoder ring. The terms are actually <em>dangerous</em> if you read them without knowing you need that decoder ring, believing you see the whole picture, which often turns out to be just the picture you wanted to see.</p> | |
| <p>My most popular piece of writing to date is <a href="https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html">thousands of words only partly explaining the 171 words of The MIT License</a>. Having commentary to guide you through a dense license is better than not having it. But it’s a distant second-best to having a license that’s readable and actionable on its own, like <a href="https://blueoakcouncil.org/license/1.0.0">Blue Oak</a>.</p> | |
| <p>Blue Oak <a href="https://blueoakcouncil.org/license/1.0.0#purpose">starts with a summary of its purpose</a>, a built-in TL;DR. You should read the whole license, because it’s easy and it matters. Blue Oak <em>wants</em> to be understood.</p> | |
| <h2 id="its-not-clear-what-mit-and-bsd-are-legally">It’s not clear what MIT and BSD are, legally.</h2> | |
| <p>We call terms for open source software “licenses”. But there’s a long-running debate in open source theory about whether they’re just licenses, licenses and contracts, both, or potentially both. I call the question theoretical, because pragmatically, dealing with that kind of uncertainty is always a distant second-best to avoiding it entirely. For open source, the keys are permission given and the rules that come along with it. Legal characterization is an implementation detail, and implementation details shouldn’t constrain high-level goals.</p> | |
| <p>Licenses like <a href="https://spdx.org/licenses/AFL-3.0.html">AFL</a> make clear that they <em>can</em> be contracts. Other forms, and now <a href="https://blueoakcouncil.org/license/1.0.0">Blue Oak</a>, make clear their terms <em>have</em> to be agreed, and not just received. License or contract? The answer is <em>both</em>. And that is a very good thing. Eliminating that question clarifies many other issues.</p> | |
| <p>Another long-running debate in open source licensing theory concerns revocation. When someone releases code under an open source license for nothing, can they take it back? Other popular licenses dating back decades, like <a href="https://spdx.org/licenses/GPL-2.0-only.html">GPLv2</a> and <a href="https://spdx.org/licenses/GPL-3.0-only.html">v3</a>, say specifically that developers <em>cannot</em> revoke their licenses, but also insist that they are just licenses, and not contracts. That’s still a head-scratcher—<a href="https://www.synopsys.com/blogs/software-security/breach-gpl-license-breach-contract/">fortunately not a particularly threatening one</a>—because the legal rules about revocation and relying on others’ words come from contract law, which covers agreements, not intellectual property law, which covers licenses. Blue Oak <a href="https://blueoakcouncil.org/license/1.0.0#acceptance">says it’s both a license and an agreement</a>, and also that <a href="https://blueoakcouncil.org/license/1.0.0#reliability">contributors can’t take their licenses back</a>. The title of that section, <em>Reliability</em>, is just the point.</p> | |
| <p>We can say much the same about warranty disclaimers and damages exclusions, the parts of licenses, often needlessly set in illegible <code class="highlighter-rouge">ALL CAPS</code>, that protect open source contributors from legal liability. How do those disclaimers and exclusions work? Under contract law, we have a pretty good idea. Under intellectual property law alone, we don’t really know. The specific terms about warranties that we see in nearly all open source licenses—“as is”, “implied warranties”—actually <a href="https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?sectionNum=2316.&amp;lawCode=COM">come from statutes about contracts</a>.</p> | |
| <h2 id="mit-and-bsd-attribution-is-a-land-mine">MIT and BSD attribution is a land mine.</h2> | |
| <p>With very rare exception, even permissively licensed open source software under terms like MIT and BSD comes with rules to follow. By far the most common rule is <em>attribution</em>, which requires those who make copies of the software, in source or compiled form, to include copies of terms, copyright notices, and other information about who licenses the software, and how.</p> | |
| <p>A byproduct of those notices is credit. Open source developers who want credit should get it. Traditional attribution rules, like those in MIT and BSD terms, arguably don’t go far enough, <a href="https://writing.kemitchell.com/2018/07/12/Posterity.html">especially in the software-as-a-service era</a>. But many companies don’t even do what the old licenses say they have to do, especially for <a href="https://www.npmjs.com/package/browserify-licenses">client-side JavaScript libraries</a>.</p> | |
| <p>The contract-or-license question muddies the waters here again. But most lawyers I’ve heard from believe that violating the attribution rule of an open source license <em>kills your license</em>. In other words, if you use someone’s software under MIT or BSD and share a copy without including their copyright notices and license terms, they can sue you for infringement, since the open source license no longer applies to you.</p> | |
| <p>The same risk applies to copyleft rules under licenses like GPLv2. That makes it possible for money-minded developers, or those who acquire their rights, to <a href="https://opensource.com/article/17/8/patrick-mchardy-and-copyright-profiteering">sue unknowning violators for money</a>, even when the point was originally to get patches back, not cash. That has led to coordinated efforts like <a href="https://www.fsf.org/licensing/enforcement-principles">Principles for Community-Oriented Enforcement</a> and the <a href="https://gplcc.github.io/gplcc/">GPL Cooperation Commitment</a>. The latter essentially backports a fix from GPLv3 to GPLv2: Pave a path to forgiveness in the license, to ensure companies who break the rule have a chance to make good, and opportunistic plaintiffs can’t use it to spring a trap.</p> | |
| <p>Blue Oak <a href="https://blueoakcouncil.org/license/1.0.0#excuse">applies the same fix to its attribution rule</a>. If someone fails to provide a copy of the license with a copy of the software, you can call them out in writing. If they do what they should have done in thirty days’ time, they’re back on track. If they refuse, then poof goes their license.</p> | |
| <h2 id="mit-and-bsd-breed-confusion">MIT and BSD breed confusion.</h2> | |
| <p>Nobody knows how many variants of <a href="https://fedoraproject.org/wiki/Licensing:MIT?rd=Licensing/MIT">MIT</a> and <a href="https://fedoraproject.org/wiki/Licensing:BSD">BSD</a> terms there are. I see a new one twice a year or so. In that sense, MIT and BSD <em>have</em> evolved over the years, but not in any useful way. Boundless variation just makes identification and compliance harder.</p> | |
| <p>Neither, apparently, do we really know how to fill out the standardized <a href="https://spdx.org/licenses/MIT.html">MIT</a> and <a href="https://spdx.org/licenses/BSD-2-Clause.html">BSD</a> templates we have. Some projects continue for years, attracting scores of meaningful contributors, with only the long-departed, initial contributor’s name in the license. Some projects replace the name with “project contributors”, rendering the line meaningless. Some projects institute chores for adding names to the copyright line and bumping the year each January. We treat projects doing all of those things the same. Apparently, none of that is essential.</p> | |
| <p><a href="https://blueoakcouncil.org/license/1.0.0">Blue Oak</a> follows modern licenses like the GPLs, Apache 2.0, Mozilla Public License, and Eclipse Public License in offering a fixed form. All you have to do is copy the terms into your project and reference it in any header comments, metadata, or documentation about licensing. There’s no copyright line or other template field to fill out or update. There’s no temptation to munge the terms, intentionally or accidentally.</p> | |
| <p>Authorship information for open source software is nearly always available online. Notice rules designed for projects from single institutions, distributed on magnetic tape by mail, back in the ’80s, don’t make sense in 2019. <a href="https://blueoakcouncil.org/license/1.0.0#notices">Hyperlinks to terms should count.</a> Under Blue Oak, they do.</p> | |
| <h2 id="mit-and-bsd-dont-expect-more-contributors">MIT and BSD don’t expect more contributors.</h2> | |
| <p>MIT and BSD terms include a space for a single copyright notice, because they were written for releases from academic institutions that own all the copyrights in their employees’ work. What about other contributors to the project? They hold copyright in their contributions.</p> | |
| <p>Modern permissive licenses, like <a href="https://spdx.org/licenses/Apache-2.0.html">Apache 2.0</a>, expect contributions from others, and express rules and expectations about how they’ll be licensed. Those rules are some of the most complex in the Apache license. In part to be double sure, in part because it’s not clear if or how the contribution-licensing conditions of Apache 2.0 work, the Apache Foundation also publishes and uses <a href="https://www.apache.org/licenses/#clas">standardized contributor license agreements</a>.</p> | |
| <p><a href="https://blueoakcouncil.org/license/1.0.0">Blue Oak</a> takes the next logical step. The license speaks from all contributors to the project, not just the first. It clearly expresses the expectation that all contributors will make their work available on the same terms. It’s still worth getting a record of contributors’ intent to license on Blue Oak terms. But Blue Oak takes the correct approach, <a href="https://writing.kemitchell.com/2017/02/16/Against-Legislating-the-Nonobvious.html">documenting that expectation to build a case that it goes without saying, rather than trying to write it into rules folks may not read</a>.</p> | |
| <p>Blue Oak <em>expects</em> more contributors. MIT and BSD expect everyone to work for one university.</p> | |
| <h2 id="use-blue-oak-for-new-work">Use Blue Oak for new work.</h2> | |
| <p>I had a hand in drafting the <a href="https://blueoakcouncil.org/license/1.0.0">Blue Oak license</a>, and I’m executive director of Blue Oak Council, the license steward. But I was not alone. Several lawyers came together, in GitHub private repos, to do what we couldn’t have done apart.</p> | |
| <p>Blue Oak is the best permissive open source software license we know how to write. We didn’t originally set out to write a license, but <a href="https://blueoakcouncil.org/2019/03/06/model.html">no existing form offered all the features we were looking for</a>.</p> | |
| <p>A whole lot of great software is out there under MIT and BSD terms. Those licenses will always be with us. As licensing lawyers, we know from firsthand experience how difficult relicensing multi-contributor projects can be.</p> | |
| <p>But for new work, there’s a clear choice. <a href="https://blueoakcouncil.org/license/1.0.0">Blue Oak</a> is a good permissive license in 2019. Old, unpatched MIT- and BSD-style terms are not.</p></content><author><name>Kyle E. Mitchell</name></author><category term="Open Source" /><category term="Licensing" /><category term="Intellectual Property" /><summary type="html">MIT and BSD open source licenses are well known, popular, and legally deprecated. They served long and well, but they’re older than many open source software developers, and haven’t been maintained. With licenses like Blue Oak available, it’s time open source upgraded from academic forms of the ’80s. There are good social, practical, and especially legal reasons to do so. MIT and BSD don’t handle patents. Both copyrights and patents apply to software, but the word “patent” does not appear in MIT or BSD terms. MIT and Cal’s tech transfer offices say they never intended to license any patents. There is some argument that other words, like “use”, imply permission under patents, anyway. And there is some law that may or may not imply patent permission, when giving someone a copy of software. But a license can avoid all that uncertainty by spelling out plainly that it covers all relevant intellectual property. MIT and BSD don’t. Licenses like Apache 2.0 show how lawyers do this in legal terms for private deals every day. Blue Oak shows the same job done in everyday English, without long lists, run-on sentences, or complex scope rules. Patents are a problem that MIT and BSD do not solve. Open source developers have better options, at no real cost, with significant additional benefits. Even developers and companies that despise software patents, and will never seek them, benefit by choosing modern terms. It’s one thing to know that you won’t seek or enforce any patents. It’s quite another to have legal assurance from others that they, or their successors, won’t lay a patent trap. MIT and BSD are hard to read. When you tell a lawyer to keep it short, their first draft will cheat by drawing heavily on background law and legal vocabulary. They’ll invoke complex concepts, rather than identifying or explaining them, often with cues non-lawyers won’t catch. It’s an extra, laborious, intellectually grueling step to translate the whole legal message into everyday words and phrases. Blue Oak made that extra investment. MIT and Cal did not. As a result, the shortness of MIT and BSD are reassuring only until you actually try to understand them, and find you need a decoder ring. The terms are actually dangerous if you read them without knowing you need that decoder ring, believing you see the whole picture, which often turns out to be just the picture you wanted to see. My most popular piece of writing to date is thousands of words only partly explaining the 171 words of The MIT License. Having commentary to guide you through a dense license is better than not having it. But it’s a distant second-best to having a license that’s readable and actionable on its own, like Blue Oak. Blue Oak starts with a summary of its purpose, a built-in TL;DR. You should read the whole license, because it’s easy and it matters. Blue Oak wants to be understood. It’s not clear what MIT and BSD are, legally. We call terms for open source software “licenses”. But there’s a long-running debate in open source theory about whether they’re just licenses, licenses and contracts, both, or potentially both. I call the question theoretical, because pragmatically, dealing with that kind of uncertainty is always a distant second-best to avoiding it entirely. For open source, the keys are permission given and the rules that come along with it. Legal characterization is an implementation detail, and implementation details shouldn’t constrain high-level goals. Licenses like AFL make clear that they can be contracts. Other forms, and now Blue Oak, make clear their terms have to be agreed, and not just received. License or contract? The answer is both. And that is a very good thing. Eliminating that question clarifies many other issues. Another long-running debate in open source licensing theory concerns revocation. When someone releases code under an open source license for nothing, can they take it back? Other popular licenses dating back decades, like GPLv2 and v3, say specifically that developers cannot revoke their licenses, but also insist that they are just licenses, and not contracts. That’s still a head-scratcher—fortunately not a particularly threatening one—because the legal rules about revocation and relying on others’ words come from contract law, which covers agreements, not intellectual property law, which covers licenses. Blue Oak says it’s both a license and an agreement, and also that contributors can’t take their licenses back. The title of that section, Reliability, is just the point. We can say much the same about warranty disclaimers and damages exclusions, the parts of licenses, often needlessly set in illegible ALL CAPS, that protect open source contributors from legal liability. How do those disclaimers and exclusions work? Under contract law, we have a pretty good idea. Under intellectual property law alone, we don’t really know. The specific terms about warranties that we see in nearly all open source licenses—“as is”, “implied warranties”—actually come from statutes about contracts. MIT and BSD attribution is a land mine. With very rare exception, even permissively licensed open source software under terms like MIT and BSD comes with rules to follow. By far the most common rule is attribution, which requires those who make copies of the software, in source or compiled form, to include copies of terms, copyright notices, and other information about who licenses the software, and how. A byproduct of those notices is credit. Open source developers who want credit should get it. Traditional attribution rules, like those in MIT and BSD terms, arguably don’t go far enough, especially in the software-as-a-service era. But many companies don’t even do what the old licenses say they have to do, especially for client-side JavaScript libraries. The contract-or-license question muddies the waters here again. But most lawyers I’ve heard from believe that violating the attribution rule of an open source license kills your license. In other words, if you use someone’s software under MIT or BSD and share a copy without including their copyright notices and license terms, they can sue you for infringement, since the open source license no longer applies to you. The same risk applies to copyleft rules under licenses like GPLv2. That makes it possible for money-minded developers, or those who acquire their rights, to sue unknowning violators for money, even when the point was originally to get patches back, not cash. That has led to coordinated efforts like Principles for Community-Oriented Enforcement and the GPL Cooperation Commitment. The latter essentially backports a fix from GPLv3 to GPLv2: Pave a path to forgiveness in the license, to ensure companies who break the rule have a chance to make good, and opportunistic plaintiffs can’t use it to spring a trap. Blue Oak applies the same fix to its attribution rule. If someone fails to provide a copy of the license with a copy of the software, you can call them out in writing. If they do what they should have done in thirty days’ time, they’re back on track. If they refuse, then poof goes their license. MIT and BSD breed confusion. Nobody knows how many variants of MIT and BSD terms there are. I see a new one twice a year or so. In that sense, MIT and BSD have evolved over the years, but not in any useful way. Boundless variation just makes identification and compliance harder. Neither, apparently, do we really know how to fill out the standardized MIT and BSD templates we have. Some projects continue for years, attracting scores of meaningful contributors, with only the long-departed, initial contributor’s name in the license. Some projects replace the name with “project contributors”, rendering the line meaningless. Some projects institute chores for adding names to the copyright line and bumping the year each January. We treat projects doing all of those things the same. Apparently, none of that is essential. Blue Oak follows modern licenses like the GPLs, Apache 2.0, Mozilla Public License, and Eclipse Public License in offering a fixed form. All you have to do is copy the terms into your project and reference it in any header comments, metadata, or documentation about licensing. There’s no copyright line or other template field to fill out or update. There’s no temptation to munge the terms, intentionally or accidentally. Authorship information for open source software is nearly always available online. Notice rules designed for projects from single institutions, distributed on magnetic tape by mail, back in the ’80s, don’t make sense in 2019. Hyperlinks to terms should count. Under Blue Oak, they do. MIT and BSD don’t expect more contributors. MIT and BSD terms include a space for a single copyright notice, because they were written for releases from academic institutions that own all the copyrights in their employees’ work. What about other contributors to the project? They hold copyright in their contributions. Modern permissive licenses, like Apache 2.0, expect contributions from others, and express rules and expectations about how they’ll be licensed. Those rules are some of the most complex in the Apache license. In part to be double sure, in part because it’s not clear if or how the contribution-licensing conditions of Apache 2.0 work, the Apache Foundation also publishes and uses standardized contributor license agreements. Blue Oak takes the next logical step. The license speaks from all contributors to the project, not just the first. It clearly expresses the expectation that all contributors will make their work available on the same terms. It’s still worth getting a record of contributors’ intent to license on Blue Oak terms. But Blue Oak takes the correct approach, documenting that expectation to build a case that it goes without saying, rather than trying to write it into rules folks may not read. Blue Oak expects more contributors. MIT and BSD expect everyone to work for one university. Use Blue Oak for new work. I had a hand in drafting the Blue Oak license, and I’m executive director of Blue Oak Council, the license steward. But I was not alone. Several lawyers came together, in GitHub private repos, to do what we couldn’t have done apart. Blue Oak is the best permissive open source software license we know how to write. We didn’t originally set out to write a license, but no existing form offered all the features we were looking for. A whole lot of great software is out there under MIT and BSD terms. Those licenses will always be with us. As licensing lawyers, we know from firsthand experience how difficult relicensing multi-contributor projects can be. But for new work, there’s a clear choice. Blue Oak is a good permissive license in 2019. Old, unpatched MIT- and BSD-style terms are not.</summary></entry><entry><title type="html">Blue Oak Council</title><link href="https://writing.kemitchell.com/2019/03/07/Blue-Oak-Council.html" rel="alternate" type="text/html" title="Blue Oak Council" /><published>2019-03-07T00:00:00-08:00</published><updated>2019-03-07T00:00:00-08:00</updated><id>https://writing.kemitchell.com/2019/03/07/Blue-Oak-Council</id><content type="html" xml:base="https://writing.kemitchell.com/2019/03/07/Blue-Oak-Council.html"><p>I’m very happy to announce of Blue Oak Council, a new organization for which I’m inaugural executive director. The Council’s website, <a href="https://blueoakcouncil.org">blueoakcouncil.org</a>, spells out its mission:</p> | |
| <blockquote> | |
| <p>Blue Oak Council opens the software commons up to those who can’t find or afford specialized legal help by bringing experienced lawyer-technologists together to publish free, practical materials about software licenses.</p> | |
| </blockquote> | |
| <p>The website already hosts a number of projects: a <a href="https://blueoakcouncil.org/list">list of permissive public software licenses</a>, a <a href="https://blueoakcouncil.org/license/1.0.0">model permissive license</a>, and <a href="https://blueoakcouncil.org/examples">examples of how to use those resources in contracts, grants, and policies</a>. We’re looking forward to facilitating new, useful projects with more attorneys in the near future.</p> | |
| <p>Last week, I found myself sitting in a coffee shop with a fellow board member, mulling the state of the specialty, the profession, and materials to learn it. On a lark, we tried to count the number of attorney specialists in public software licensing currently in private practice, and therefore available to new clients. We agreed it’s probably single digits, maybe even worldwide.</p> | |
| <p>What’s more, the cost of those specialists’ time, including mine, cuts the count down to zero for nearly all individuals and shoestring operations, especially in the nonprofit sector. There’s a sea of software out there to help them, but they can’t navigate it safely or confidently on their own.</p> | |
| <p>I don’t know if Blue Oak Council can change all that, but we’re damn well going to try.</p> | |
| <p>If you’re a fellow or student licensing lawyer looking to collaborate on real, practical resources for the underserved, <a href="mailto:kyle@kemitchell.com">drop me a line</a>. Blue Oak Council wants to be an ally, a resource, and a help in your service.</p></content><author><name>Kyle E. Mitchell</name></author><category term="Nonprofits" /><category term="Intellectual Property" /><category term="Licensing" /><summary type="html">I’m very happy to announce of Blue Oak Council, a new organization for which I’m inaugural executive director. The Council’s website, blueoakcouncil.org, spells out its mission: Blue Oak Council opens the software commons up to those who can’t find or afford specialized legal help by bringing experienced lawyer-technologists together to publish free, practical materials about software licenses. The website already hosts a number of projects: a list of permissive public software licenses, a model permissive license, and examples of how to use those resources in contracts, grants, and policies. We’re looking forward to facilitating new, useful projects with more attorneys in the near future. Last week, I found myself sitting in a coffee shop with a fellow board member, mulling the state of the specialty, the profession, and materials to learn it. On a lark, we tried to count the number of attorney specialists in public software licensing currently in private practice, and therefore available to new clients. We agreed it’s probably single digits, maybe even worldwide. What’s more, the cost of those specialists’ time, including mine, cuts the count down to zero for nearly all individuals and shoestring operations, especially in the nonprofit sector. There’s a sea of software out there to help them, but they can’t navigate it safely or confidently on their own. I don’t know if Blue Oak Council can change all that, but we’re damn well going to try. If you’re a fellow or student licensing lawyer looking to collaborate on real, practical resources for the underserved, drop me a line. Blue Oak Council wants to be an ally, a resource, and a help in your service.</summary></entry><entry><title type="html">Back to IP</title><link href="https://writing.kemitchell.com/2019/03/04/Back-to-IP.html" rel="alternate" type="text/html" title="Back to IP" /><published>2019-03-04T00:00:00-08:00</published><updated>2019-03-04T00:00:00-08:00</updated><id>https://writing.kemitchell.com/2019/03/04/Back-to-IP</id><content type="html" xml:base="https://writing.kemitchell.com/2019/03/04/Back-to-IP.html"><blockquote> | |
| <p>The Congress shall have Power … To promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries.</p> | |
| <p>— United States Constitution, Article 1, Section 8</p> | |
| </blockquote> | |
| <p>How should society support creation and maintenance of public knowledge goods in the private sector? The obvious answer: intellectual property law. The public policy behind modern IP law gives creators of valuable ideas and expressions rights to make others pay for licenses, so they can recoup costs and keep up the good work.</p> | |
| <p>In the case of open source software specifically, the obvious way to fund developers is to pay them for copyright licenses. The government is so sure of this general solution to the sustainability problem—<a href="https://en.wikipedia.org/wiki/Excludability">making nonexcludable ideas excludable</a>—that it applies to qualifying software by default, like it or not. Open source software developers make software open-source by <a href="https://oss.kemitchell.com">reversing those copyright and other IP rules</a>, knocking out the supports the law provides.</p> | |
| <p>Of course there’s an open source sustainability problem. Open source declines society’s official solution to the sustainability problem. Opting <em>out</em> of the solution is opting back <em>in</em> to the problem.</p> | |
| <p>None of this is to say that the present policy justification and practical, political history of intellectual property laws have always aligned. They haven’t. Nor does the current policy entirely jibe with reality. Intellectual property rights allotted to individual creators by default often end up belonging to employers and clients instead. The exception of corporate ownership swallows the rule of individual creator empowerment for commercially viable work. Overzealous strengthening of IP rights goes too far, upsetting the balance of social and private benefit.</p> | |
| <p>Many open source activists reject the idea of treating code, and especially patentable ideas implementable in code, as property. It’s easy to find evidence of the shallow, property-as-panacea thinking they criticize. But it’s also wrong to criticize IP for making ideas into property, and stop there. The law makes ideas into property for a reason. In open source terms, that reason is sustainability. Properly understood and applied, intellectual property is a means to sustainability, not an end in itself. By all means criticize IP rules when they fail to achieve their ends. Or offer a superior alternative.</p> | |
| <p>Making ideas into property isn’t the only way to fund or encourage work. Some projects, and some creators, don’t need money or encouragement, anyway. Others, especially businesses, have different compelling reasons for creating or funding open source, like <a href="https://www.cncf.io/">inducing strategically beneficial market distortions</a> or <a href="https://reactjs.org/">enhancing their names and esteem</a>. In exceptional cases, support based on enlightened self-interest, like donations, can suffice, at least for a while. But enlightened self-interest remains in short supply.</p> | |
| <p>There are many reasons to believe in open source, to see it as a novel and exciting exception to rules once seen as firm. Many folks contribute to, and identify with, open source as an alternative to, or rejection of, markets, business firms, industrial production methods, and the modern IP “asset” mentality. These folks marvel at Linux’ ability to challenge, and eventually outcompete, server operating systems from established, traditionalist, hidebound software companies.</p> | |
| <p>When I speak to these open source contributors about sustainability, I often find them in a double bind.</p> | |
| <p>On one side, their view drastically constrains the field of viable alternative solutions to the sustainability problem. <a href="https://indieopensource.com/public-private">Public-private licensing</a> is out. <a href="https://indieopensource.com/open-core">Open core</a> is out. Delayed open source release is out. All of these merely mix some element of IP-based exclusivity in with partial or eventual open source release.</p> | |
| <p>On the other side, they have to confront the fact that industry has learned from, and arguably coopted, a selective sampling of open source tools and techniques. Open source has “won” by demonstrating good service to the kind of large and growing business firms some hoped it would supersede. In many areas open source <em>is</em> the dominant development culture of software business, and not because business capitulated, but because open source assimilated. It’s the <a href="https://en.wikipedia.org/wiki/Volkswagen_New_Beetle">New Beetle</a> era, not the <a href="https://en.wikipedia.org/wiki/Volkswagen_Beetle">Old Beetle</a> heyday.</p> | |
| <p>Escape from that double-bind has almost always meant encouraging developers to engage in a kind of business, adjacent to their open source work, that for whatever reason falls outside the scope of open source expectations. That’s a hack. Those approaches conflict, at a higher level, with open ideology. Provide hosting. Offer the software as a service. Sell paid support. Set up a trademark licensing or certification program.</p> | |
| <p>Often, these opportunities stand just as available to those who don’t contribute to open source as to those who do. That subjects those who rightly deserve support to competition from free riders, again. Where opportunities do favor contributors, their advantage often boils down either to an exclusive right of some other kind, like a trademark, a certification, or established market position, or to an unaccounted deduction from open source. It’s far easier to sell integration, support, and training, for example, by keeping publicly available documentation for an open source project weak, outdated, or nonexistent. It’s far easier to sell hosting or implementation when hosting and implementation remain hard.</p> | |
| <p>The challenge to property exceptionalists remains: What alternative to exclusivity can they offer, to achieve the same purpose as intellectual property laws? Or do they merely accept that open source will accumulate remainders and contributions from neophytes, the obsessed, and the well-off? That those in need of support shouldn’t expect any, but instead write proprietary code for cash, and pray for a rare fluke of charity?</p> | |
| <p>An unsustainable challenge to incumbent business is no real challenge at all. Is open source a viable, self-sufficient alternative to those models of software creation and distribution, or merely a reaction—and increasingly an accessory—to business as usual?</p></content><author><name>Kyle E. Mitchell</name></author><category term="Open Source" /><category term="Intellectual Property" /><category term="Sustainability" /><summary type="html">The Congress shall have Power … To promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries. — United States Constitution, Article 1, Section 8 How should society support creation and maintenance of public knowledge goods in the private sector? The obvious answer: intellectual property law. The public policy behind modern IP law gives creators of valuable ideas and expressions rights to make others pay for licenses, so they can recoup costs and keep up the good work. In the case of open source software specifically, the obvious way to fund developers is to pay them for copyright licenses. The government is so sure of this general solution to the sustainability problem—making nonexcludable ideas excludable—that it applies to qualifying software by default, like it or not. Open source software developers make software open-source by reversing those copyright and other IP rules, knocking out the supports the law provides. Of course there’s an open source sustainability problem. Open source declines society’s official solution to the sustainability problem. Opting out of the solution is opting back in to the problem. None of this is to say that the present policy justification and practical, political history of intellectual property laws have always aligned. They haven’t. Nor does the current policy entirely jibe with reality. Intellectual property rights allotted to individual creators by default often end up belonging to employers and clients instead. The exception of corporate ownership swallows the rule of individual creator empowerment for commercially viable work. Overzealous strengthening of IP rights goes too far, upsetting the balance of social and private benefit. Many open source activists reject the idea of treating code, and especially patentable ideas implementable in code, as property. It’s easy to find evidence of the shallow, property-as-panacea thinking they criticize. But it’s also wrong to criticize IP for making ideas into property, and stop there. The law makes ideas into property for a reason. In open source terms, that reason is sustainability. Properly understood and applied, intellectual property is a means to sustainability, not an end in itself. By all means criticize IP rules when they fail to achieve their ends. Or offer a superior alternative. Making ideas into property isn’t the only way to fund or encourage work. Some projects, and some creators, don’t need money or encouragement, anyway. Others, especially businesses, have different compelling reasons for creating or funding open source, like inducing strategically beneficial market distortions or enhancing their names and esteem. In exceptional cases, support based on enlightened self-interest, like donations, can suffice, at least for a while. But enlightened self-interest remains in short supply. There are many reasons to believe in open source, to see it as a novel and exciting exception to rules once seen as firm. Many folks contribute to, and identify with, open source as an alternative to, or rejection of, markets, business firms, industrial production methods, and the modern IP “asset” mentality. These folks marvel at Linux’ ability to challenge, and eventually outcompete, server operating systems from established, traditionalist, hidebound software companies. When I speak to these open source contributors about sustainability, I often find them in a double bind. On one side, their view drastically constrains the field of viable alternative solutions to the sustainability problem. Public-private licensing is out. Open core is out. Delayed open source release is out. All of these merely mix some element of IP-based exclusivity in with partial or eventual open source release. On the other side, they have to confront the fact that industry has learned from, and arguably coopted, a selective sampling of open source tools and techniques. Open source has “won” by demonstrating good service to the kind of large and growing business firms some hoped it would supersede. In many areas open source is the dominant development culture of software business, and not because business capitulated, but because open source assimilated. It’s the New Beetle era, not the Old Beetle heyday. Escape from that double-bind has almost always meant encouraging developers to engage in a kind of business, adjacent to their open source work, that for whatever reason falls outside the scope of open source expectations. That’s a hack. Those approaches conflict, at a higher level, with open ideology. Provide hosting. Offer the software as a service. Sell paid support. Set up a trademark licensing or certification program. Often, these opportunities stand just as available to those who don’t contribute to open source as to those who do. That subjects those who rightly deserve support to competition from free riders, again. Where opportunities do favor contributors, their advantage often boils down either to an exclusive right of some other kind, like a trademark, a certification, or established market position, or to an unaccounted deduction from open source. It’s far easier to sell integration, support, and training, for example, by keeping publicly available documentation for an open source project weak, outdated, or nonexistent. It’s far easier to sell hosting or implementation when hosting and implementation remain hard. The challenge to property exceptionalists remains: What alternative to exclusivity can they offer, to achieve the same purpose as intellectual property laws? Or do they merely accept that open source will accumulate remainders and contributions from neophytes, the obsessed, and the well-off? That those in need of support shouldn’t expect any, but instead write proprietary code for cash, and pray for a rare fluke of charity? An unsustainable challenge to incumbent business is no real challenge at all. Is open source a viable, self-sufficient alternative to those models of software creation and distribution, or merely a reaction—and increasingly an accessory—to business as usual?</summary></entry><entry><title type="html">Indie Open Source</title><link href="https://writing.kemitchell.com/2019/02/25/Indie-Open-Source.html" rel="alternate" type="text/html" title="Indie Open Source" /><published>2019-02-25T00:00:00-08:00</published><updated>2019-02-25T00:00:00-08:00</updated><id>https://writing.kemitchell.com/2019/02/25/Indie-Open-Source</id><content type="html" xml:base="https://writing.kemitchell.com/2019/02/25/Indie-Open-Source.html"><p>Over the past few years, I’ve had an incredible number of deep conversations about open source business models with solo hackers and small firms off the VC-funded track. Nearly all of those calls ended the same way:</p> | |
| <blockquote> | |
| <p>We should really get together and do something about how hard it is for indies to find out about business models that work for them.</p> | |
| </blockquote> | |
| <p>At some point, I started adding these folks to an empty GitHub organization, <a href="https://github.com/indieopensource">indieopensource</a>. Today, I’m pleased to announce that the org is no longer empty. We’ve begun fleshing out <a href="https://indieopensource.com">indieopensource.com</a> as the resource we all wish we’d had ourselves, much earlier.</p> | |
| <p>Within scope:</p> | |
| <ul> | |
| <li> | |
| <p><a href="https://indieopensource.com/for-indies#business-model-guides">guides to business models</a> that work well for solo and small-firm developers, like <a href="https://indieopensource.com/paid-support/indies">paid support</a> and <a href="https://indieopensource.com/public-private/indies">public-private licensing</a></p> | |
| </li> | |
| <li> | |
| <p>explainers for <a href="https://indieopensource.com/for-users">users</a> and <a href="https://indieopensource.com/for-contributors">outside contributors</a> of projects running those models</p> | |
| </li> | |
| <li> | |
| <p>a <a href="https://indieopensource.com/indies">showcase of companies</a> running those models, like <a href="https://metafizzy.co">Metafizzy</a> and <a href="https://sidekiq.org">Sidekiq</a></p> | |
| </li> | |
| <li> | |
| <p>a collection of <a href="https://indieopensource.com/forms">legal forms</a> useful for those models, including a <a href="https://github.com/indieopensource/paid-license">paid license</a>, a <a href="https://github.com/indieopensource/support-contract">support contract</a>, and a <a href="https://github.com/indieopensource/tiny-cla">tiny contributor license agreement</a></p> | |
| </li> | |
| <li> | |
| <p>a directory of <a href="https://indieopensource.com/services">service providers</a> helping to make business models cheaper and easier to run</p> | |
| </li> | |
| </ul> | |
| <p>We’re <a href="https://indieopensource.com/scope">not stressing what it means to be an “indie”</a>. Rather, we’re sending out a signal to collect new writing, data, and tools for mutual aid. We’re trying to become a shared and codeveloped resource.</p> | |
| <p>As for contribution, the project is very young, and has all the needs: design, writing, links, data about companies and service providers. The action is <a href="https://github.com/indieopensource">all under the GitHub organization</a>, especially the <a href="https://github.com/indieopensource/indieopensource.github.io">repository for indieopensource.com</a>.</p></content><author><name>Kyle E. Mitchell</name></author><category term="Open Source" /><category term="Business Models" /><category term="Forms" /><category term="Licenses" /><summary type="html">Over the past few years, I’ve had an incredible number of deep conversations about open source business models with solo hackers and small firms off the VC-funded track. Nearly all of those calls ended the same way: We should really get together and do something about how hard it is for indies to find out about business models that work for them. At some point, I started adding these folks to an empty GitHub organization, indieopensource. Today, I’m pleased to announce that the org is no longer empty. We’ve begun fleshing out indieopensource.com as the resource we all wish we’d had ourselves, much earlier. Within scope: guides to business models that work well for solo and small-firm developers, like paid support and public-private licensing explainers for users and outside contributors of projects running those models a showcase of companies running those models, like Metafizzy and Sidekiq a collection of legal forms useful for those models, including a paid license, a support contract, and a tiny contributor license agreement a directory of service providers helping to make business models cheaper and easier to run We’re not stressing what it means to be an “indie”. Rather, we’re sending out a signal to collect new writing, data, and tools for mutual aid. We’re trying to become a shared and codeveloped resource. As for contribution, the project is very young, and has all the needs: design, writing, links, data about companies and service providers. The action is all under the GitHub organization, especially the repository for indieopensource.com.</summary></entry><entry><title type="html">Open Source Software License Reading List</title><link href="https://writing.kemitchell.com/2019/02/24/License-Reading-List.html" rel="alternate" type="text/html" title="Open Source Software License Reading List" /><published>2019-02-24T00:00:00-08:00</published><updated>2019-02-24T00:00:00-08:00</updated><id>https://writing.kemitchell.com/2019/02/24/License-Reading-List</id><content type="html" xml:base="https://writing.kemitchell.com/2019/02/24/License-Reading-List.html"><p>I’ve just published <a href="/license-reading-list.html">an open source software license reading list</a> for those looking to get into open source software licensing.</p> | |
| <p>This will be my go-to guide for those asking about how to study up on open source licensing.</p></content><author><name>Kyle E. Mitchell</name></author><category term="Open Source" /><category term="Licensing" /><category term="Reading" /><category term="Teaching" /><summary type="html">I’ve just published an open source software license reading list for those looking to get into open source software licensing. This will be my go-to guide for those asking about how to study up on open source licensing.</summary></entry><entry><title type="html">First Thoughts on the Redis Source Available License Agreement</title><link href="https://writing.kemitchell.com/2019/02/22/Quick-Thoughts-on-Redise-Source-Available-License.html" rel="alternate" type="text/html" title="First Thoughts on the Redis Source Available License Agreement" /><published>2019-02-22T00:00:00-08:00</published><updated>2019-02-22T00:00:00-08:00</updated><id>https://writing.kemitchell.com/2019/02/22/Quick-Thoughts-on-Redise-Source-Available-License</id><content type="html" xml:base="https://writing.kemitchell.com/2019/02/22/Quick-Thoughts-on-Redise-Source-Available-License.html"><p>Redis Labs <a href="https://redislabs.com/blog/redis-labs-modules-license-changes/">recently announced another change to their modules license terms</a>, taking them away from the <a href="https://commonsclause.com">Commons Clause</a>, a messaging clusterfuck for which they briefly served as poster child.</p> | |
| <p>A few quick thoughts on Version 1, dated February 21, 2019:</p> | |
| <blockquote> | |
| <p>This Agreement sets forth the terms on which the Licensor makes available the Software. BY INSTALLING, DOWNLOADING, ACCESSING, USING OR DISTRIBUTING ANY OF THE SOFTWARE, YOU AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO SUCH TERMS AND CONDITIONS, YOU MUST NOT USE THE SOFTWARE.</p> | |
| </blockquote> | |
| <p>There’s lingering confusion over whether public software licenses are just licenses, contracts, or at least licenses and possibly also contracts. That <a href="http://www.gnu.org/philosophy/enforcing-gpl.html">distinction</a> has proved <a href="https://www.synopsys.com/blogs/software-security/breach-gpl-license-breach-contract/">more intellectual than practical</a>. Increasingly, lawyers drafting public license terms are choosing to eliminate the uncertainty, by requiring their terms to be accepted as agreements.</p> | |
| <blockquote> | |
| <p><strong>Database Product</strong>: any of the following products or services:</p> | |
| <p>(a) database;</p> | |
| <p>(b) caching engine;</p> | |
| <p>(c) stream processing engine;</p> | |
| <p>(d) search engine;</p> | |
| <p>(e) indexing engine;</p> | |
| <p>(f) machine learning or deep learning or artificial intelligence serving engine;</p> | |
| <p>…</p> | |
| </blockquote> | |
| <p>This is <em>not</em> the standardizable form everybody’s been waiting for. These points are very specific to Redis Labs, and the kinds of competing projects that concern Redis Labs. However…</p> | |
| <blockquote> | |
| <p>(g) a product or service exposing the Redis API;</p> | |
| <p>(h) a product or service exposing the Redis Modules API; or</p> | |
| <p>(i) a product or service exposing the Software API.</p> | |
| </blockquote> | |
| <p><em>These</em> points are all highly reminiscent of the more general approach taken in my <a href="https://github.com/kemitchell/api-copyleft-license">API Copyleft License</a>, previously called the Shared Component License, which I <a href="/2019/01/30/API-Copyleft.html">blogged here last month</a>. The key is the API. There is hunger for license terms that protect against, or require open source release of, “wrapper” code that still exposes the API of the originally licensed software. Various drafters, from various points of view, are converging on that dividing line for rules about free-of-charge and closed-source use.</p> | |
| <blockquote> | |
| <p><strong>Your Application</strong>: an application developed by or for You, where such application is not a Database Product.</p> | |
| </blockquote> | |
| <p>Again, Redis Labs takes fundamentally the same tack as my <a href="https://github.com/kemitchell/api-copyleft-license">API Copyleft License</a>. We want a “safe zone” of permission for applications that <em>don’t</em> modify or expose the licensed software’s API, but only use it. The boundary is between “applications” of the licensed software and its API, and “wrappers” that expose or enhance that API for other applications.</p> | |
| <p>Restricted, source-available licenses giving selective permission, based on API. Open licenses selectively applying copyleft, based on API.</p> | |
| <p>We’re onto something…</p></content><author><name>Kyle E. Mitchell</name></author><category term="licensing" /><category term="open source" /><category term="copyleft" /><category term="open core" /><summary type="html">Redis Labs recently announced another change to their modules license terms, taking them away from the Commons Clause, a messaging clusterfuck for which they briefly served as poster child. A few quick thoughts on Version 1, dated February 21, 2019: This Agreement sets forth the terms on which the Licensor makes available the Software. BY INSTALLING, DOWNLOADING, ACCESSING, USING OR DISTRIBUTING ANY OF THE SOFTWARE, YOU AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO SUCH TERMS AND CONDITIONS, YOU MUST NOT USE THE SOFTWARE. There’s lingering confusion over whether public software licenses are just licenses, contracts, or at least licenses and possibly also contracts. That distinction has proved more intellectual than practical. Increasingly, lawyers drafting public license terms are choosing to eliminate the uncertainty, by requiring their terms to be accepted as agreements. Database Product: any of the following products or services: (a) database; (b) caching engine; (c) stream processing engine; (d) search engine; (e) indexing engine; (f) machine learning or deep learning or artificial intelligence serving engine; … This is not the standardizable form everybody’s been waiting for. These points are very specific to Redis Labs, and the kinds of competing projects that concern Redis Labs. However… (g) a product or service exposing the Redis API; (h) a product or service exposing the Redis Modules API; or (i) a product or service exposing the Software API. These points are all highly reminiscent of the more general approach taken in my API Copyleft License, previously called the Shared Component License, which I blogged here last month. The key is the API. There is hunger for license terms that protect against, or require open source release of, “wrapper” code that still exposes the API of the originally licensed software. Various drafters, from various points of view, are converging on that dividing line for rules about free-of-charge and closed-source use. Your Application: an application developed by or for You, where such application is not a Database Product. Again, Redis Labs takes fundamentally the same tack as my API Copyleft License. We want a “safe zone” of permission for applications that don’t modify or expose the licensed software’s API, but only use it. The boundary is between “applications” of the licensed software and its API, and “wrappers” that expose or enhance that API for other applications. Restricted, source-available licenses giving selective permission, based on API. Open licenses selectively applying copyleft, based on API. We’re onto something…</summary></entry><entry><title type="html">API Copyleft License 1.0.0</title><link href="https://writing.kemitchell.com/2019/02/22/API-Copyleft-1.0.0.html" rel="alternate" type="text/html" title="API Copyleft License 1.0.0" /><published>2019-02-22T00:00:00-08:00</published><updated>2019-02-22T00:00:00-08:00</updated><id>https://writing.kemitchell.com/2019/02/22/API-Copyleft-1.0.0</id><content type="html" xml:base="https://writing.kemitchell.com/2019/02/22/API-Copyleft-1.0.0.html"><p>I’m happy to announce <a href="https://github.com/kemitchell/api-copyleft-license/releases/tag/v1.0.0">the 1.0.0 release of the recently rechristened API Copyleft License</a>.</p> | |
| <p>This was only possible with wonderful feedback from several people:</p> | |
| <ul> | |
| <li>Theo Belaire</li> | |
| <li>Josh Berkus</li> | |
| <li>Ben Hilburn</li> | |
| <li>Adam Jacob</li> | |
| <li>Alexis Richardson</li> | |
| <li>Luis Villa</li> | |
| </ul> | |
| <p>Looking forward to more proposals and discussions <a href="https://github.com/kemitchell/api-copyleft-license">on GitHub</a>. Version 1.0.0 is a good license. But like all the license I work on, I expect that it will continue to evolve.</p> | |
| <p>The text of version 1.0.0 follows:</p> | |
| <blockquote> | |
| <h1 id="api-copyleft-license">API Copyleft License</h1> | |
| <p>Version 1.0.0</p> | |
| <p>Developer: {Legal Name}</p> | |
| <p>Homepage: {URL}</p> | |
| <h2 id="purpose">Purpose</h2> | |
| <p>This license gives you permission to use, share, and build with this software for free, but requires you to contribute source code for changes, additions, and software that you build with it, other than applications.</p> | |
| <h2 id="disclaimer">Disclaimer</h2> | |
| <p><strong><em>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.</em></strong></p> | |
| <h2 id="acceptance">Acceptance</h2> | |
| <p>In order to receive this license, you must agree to its rules. Those rules 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.</p> | |
| <h2 id="copyright">Copyright</h2> | |
| <p>The developer licenses you to do everything with this software that would otherwise infringe copyrights in this software they can license.</p> | |
| <h2 id="patent">Patent</h2> | |
| <p>The developer licenses you to do everything with this software that would otherwise infringe any patent claims they can license.</p> | |
| <h2 id="reliability">Reliability</h2> | |
| <p>The developer will not revoke this license.</p> | |
| <h2 id="notices">Notices</h2> | |
| <p>You must ensure that everyone who gets a copy of any part of this software from you, in source code or any other form, also gets the text of this license, including its developer and homepage lines.</p> | |
| <h2 id="copyleft">Copyleft</h2> | |
| <p>With two exceptions, <a href="#prototypes">Prototypes</a> and <a href="#applications">Applications</a>, you must contribute all software that invokes this software’s functionality, as well as changes and additions to this software, according to <a href="#contributing">Contributing</a>.</p> | |
| <h2 id="prototypes">Prototypes</h2> | |
| <p>You need not contribute prototype changes, extensions, or applications that you do not end up using for more than fourteen calendar days, share with anyone else, or use to provide a service to anyone else.</p> | |
| <h2 id="applications">Applications</h2> | |
| <p>You need not contribute software that only invokes this software’s functionality through the interfaces this software exposes, without exposing this software’s interfaces and functionality to other software.</p> | |
| <p>Interfaces exposed by this software include all the interfaces this software provides users or other software to invoke its functionality, such as command line, graphical, application programming, remote procedure call, and inter-process communication interfaces.</p> | |
| <h2 id="contributing">Contributing</h2> | |
| <p>When this license requires you to contribute software:</p> | |
| <p>First, 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.</p> | |
| <p>Second, ensure that each part of that source code is licensed to the public under one of these:</p> | |
| <ol> | |
| <li> | |
| <p><a href="https://spdx.org/licenses/BSD-2-Clause-Patent.html">The BSD-2-Clause Plus Patent License</a></p> | |
| </li> | |
| <li> | |
| <p>terms with substantially the same legal effect as <a href="#copyright">Copyright</a>, <a href="#patent">Patent</a>, and <a href="#reliability">Reliability</a>, and optionally a rule like <a href="#notices">Notices</a>, a disclaimer like <a href="#disclaimer">Disclaimer</a>, or both, but no other terms</p> | |
| </li> | |
| <li> | |
| <p>this license</p> | |
| </li> | |
| </ol> | |
| <p>Take these steps within thirty calendar days of creating or using the software for the first time.</p> | |
| <h2 id="excuse">Excuse</h2> | |
| <p>You are excused for unknowingly breaking <a href="#notices">Notices</a> or <a href="#copyleft">Copyleft</a> if you do what the rule requires, or stop doing anything requiring this license, within thirty days of learning you broke the rule.</p> | |
| </blockquote></content><author><name>Kyle E. Mitchell</name></author><category term="Copyleft" /><category term="Licensing" /><category term="Open Source" /><summary type="html">I’m happy to announce the 1.0.0 release of the recently rechristened API Copyleft License. This was only possible with wonderful feedback from several people: Theo Belaire Josh Berkus Ben Hilburn Adam Jacob Alexis Richardson Luis Villa Looking forward to more proposals and discussions on GitHub. Version 1.0.0 is a good license. But like all the license I work on, I expect that it will continue to evolve. The text of version 1.0.0 follows: API Copyleft License Version 1.0.0 Developer: {Legal Name} Homepage: {URL} Purpose This license gives you permission to use, share, and build with this software for free, but requires you to contribute source code for changes, additions, and software that you build with it, other than applications. 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. Those rules 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, also gets the text of this license, including its developer and homepage lines. Copyleft With two exceptions, Prototypes and Applications, you must contribute all software that invokes this software’s functionality, as well as changes and additions to this software, according to Contributing. Prototypes You need not contribute prototype changes, extensions, or applications that you do not end up using for more than fourteen calendar days, share with anyone else, or use to provide a service to anyone else. Applications You need not contribute software that only invokes this software’s functionality through the interfaces this software exposes, without exposing this software’s interfaces and functionality to other software. Interfaces exposed by this software include all the interfaces this software provides users or other software to invoke its functionality, such as command line, graphical, application programming, remote procedure call, and inter-process communication interfaces. Contributing When this license requires you to contribute software: First, 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. Second, ensure that each part of that source code is licensed to the public under one of these: The BSD-2-Clause Plus Patent License terms with substantially the same legal effect as Copyright, Patent, and Reliability, and optionally a rule like Notices, a disclaimer like Disclaimer, or both, but no other terms this license Take these steps within thirty calendar days of creating or using the software for the first time. Excuse You are excused for unknowingly breaking Notices or Copyleft if you do what the rule requires, or stop doing anything requiring this license, within thirty days of learning you broke the rule.</summary></entry><entry><title type="html">API Copyleft</title><link href="https://writing.kemitchell.com/2019/01/30/API-Copyleft.html" rel="alternate" type="text/html" title="API Copyleft" /><published>2019-01-30T00:00:00-08:00</published><updated>2019-01-30T00:00:00-08:00</updated><id>https://writing.kemitchell.com/2019/01/30/API-Copyleft</id><content type="html" xml:base="https://writing.kemitchell.com/2019/01/30/API-Copyleft.html"><p>I’ve been part of a group writing <a href="https://github.com/kemitchell/shared-component-license/blob/master/license.md">a new open source license that’s copyleft for patches, additions, and wrappers, but permissive for applications that just use through the API</a>. A kind of plain-language <a href="https://www.mongodb.com/licensing/server-side-public-license">Server Side Public License</a>. The inimitable <a href="https://lu.is/">Luis Villa</a> really got me thinking with <a href="https://twitter.com/luis_in_brief/status/1088250694010695680">this tweet</a>:</p> | |
| <blockquote> | |
| <p>Scoping to the API for service consumers is a pretty good 2019 equivalent for the original MPL “scope for plug-ins” intention.</p> | |
| </blockquote> | |
| <p>By “MPL”, Luis is referring to <a href="https://www.mozilla.org/en-US/MPL/2.0/">The Mozilla Public License, version 2.0</a>, which he had a big part in writing. MPL 2.0 epitomizes “file-based copyleft”, which sets rules about what licensees have to contribute back by focusing on the computer files where source code lives:</p> | |
| <blockquote> | |
| <h2 id="110--modifications">1.10. “Modifications”</h2> | |
| <p>means any of the following:</p> | |
| <ol> | |
| <li> | |
| <p>any file in Source Code Form that results from an addition to, deletion from, or modification of the contents of Covered Software; or</p> | |
| </li> | |
| <li> | |
| <p>any new file in Source Code Form that contains any Covered Software.</p> | |
| </li> | |
| </ol> | |
| <p>[…]</p> | |
| <h2 id="31--distribution-of-source-form">3.1. Distribution of Source Form</h2> | |
| <p>All distribution of Covered Software in Source Code Form, including any Modifications that You create or to which You contribute, must be under the terms of this License. […]</p> | |
| </blockquote> | |
| <p>By contrast, the license I’ve been working on focuses on whether new software goes beyond invoking the licensed software through its existing interfaces:</p> | |
| <blockquote> | |
| <h2 id="copyleft">Copyleft</h2> | |
| <p>With two exceptions, <em>Prototypes</em> and <a href="#applications"><em>Applications</em></a>, you must contribute all software that invokes this software’s functionality, as well as patches and additions to this software, according to <em>Contributing</em>.</p> | |
| <p>[…]</p> | |
| <h2 id="applications">Applications</h2> | |
| <p>You need not contribute software that only invokes this software’s functionality through the interfaces this software exposes, without exposing this software’s interfaces and functionality to other software.</p> | |
| <p>Interfaces exposed by this software include all the interfaces this software provides users or other software to invoke its functionality, such as command line, graphical, application programming, remote procedure call, and inter-process communication interfaces.</p> | |
| </blockquote> | |
| <p>The basic drafting challenge for this kind of license boils down to a line-drawing problem. We could put software that builds on other software on a spectrum:</p> | |
| <div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>patches extensions applications wrappers | |
| </code></pre></div></div> | |
| <p>The goal of the license is to scope copyleft selectively, to miss applications, but cover everything else:</p> | |
| <div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>patches extensions applications wrappers | |
| copyleft copyleft PERMISSIVE copyleft | |
| </code></pre></div></div> | |
| <p>With that in mind, the license needs to draw two lines, one between extensions and applications, the other between applications and wrappers:</p> | |
| <div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code> 1 2 | |
| patches extensions | applications | wrappers | |
| copyleft copyleft | PERMISSIVE | copyleft | |
| </code></pre></div></div> | |
| <p>Earlier versions of the license drew each of these lines in separate language, using different words and concepts. But the current draft draws both lines with the same words and concepts: functionality and interfaces of the licensed software.</p> | |
| <p>How do we distinguish applications from extensions? Extensions go beyond accessing the licensed software through the interfaces it already exposes. How do we distinguish applications from wrappers? Wrappers make the licensed software’s interfaces or functionality available to still other applications.</p> | |
| <p>The interface-functionality concept is a kind of pun. It just so happens that we can draw both extension-application and application-wrapper lines with it. Coincidentally, that seems to achieve the goals of the license very nicely.</p> | |
| <p>The inimitable <a href="https://blog.codinghorror.com/">Jeff Atwood</a> caught onto this pretty much immediately, and responded to my pleas for help renaming the form, in <a href="https://twitter.com/codinghorror/status/1090126535590170624">these</a> <a href="https://twitter.com/codinghorror/status/1090129373733171200">tweets</a>:</p> | |
| <blockquote> | |
| <p>The tell is that you keep using the word API to describe it. That needs to be in the name.</p> | |
| </blockquote> | |
| <blockquote> | |
| <p>I still think you’re going to be in a world of hurt unless you go with API License. You can explain the other exceptions more easily than “interface boundary”</p> | |
| </blockquote> | |
| <p>I quibble, because API is just one kind of interface, and the license covers many kinds. I’m right, but I think Jeff is, too. It’s a little strange to name a specific license after the licensing <em>paradigm</em> it represents. <a href="https://github.com/kemitchell/shared-component-license/issues/18">But why not just “API Copyleft License”?</a></p></content><author><name>Kyle E. Mitchell</name></author><category term="Copyleft" /><category term="Licensing" /><category term="Open Source" /><category term="SSPL" /><summary type="html">I’ve been part of a group writing a new open source license that’s copyleft for patches, additions, and wrappers, but permissive for applications that just use through the API. A kind of plain-language Server Side Public License. The inimitable Luis Villa really got me thinking with this tweet: Scoping to the API for service consumers is a pretty good 2019 equivalent for the original MPL “scope for plug-ins” intention. By “MPL”, Luis is referring to The Mozilla Public License, version 2.0, which he had a big part in writing. MPL 2.0 epitomizes “file-based copyleft”, which sets rules about what licensees have to contribute back by focusing on the computer files where source code lives: 1.10. “Modifications” means any of the following: any file in Source Code Form that results from an addition to, deletion from, or modification of the contents of Covered Software; or any new file in Source Code Form that contains any Covered Software. […] 3.1. Distribution of Source Form All distribution of Covered Software in Source Code Form, including any Modifications that You create or to which You contribute, must be under the terms of this License. […] By contrast, the license I’ve been working on focuses on whether new software goes beyond invoking the licensed software through its existing interfaces: Copyleft With two exceptions, Prototypes and Applications, you must contribute all software that invokes this software’s functionality, as well as patches and additions to this software, according to Contributing. […] Applications You need not contribute software that only invokes this software’s functionality through the interfaces this software exposes, without exposing this software’s interfaces and functionality to other software. Interfaces exposed by this software include all the interfaces this software provides users or other software to invoke its functionality, such as command line, graphical, application programming, remote procedure call, and inter-process communication interfaces. The basic drafting challenge for this kind of license boils down to a line-drawing problem. We could put software that builds on other software on a spectrum: patches extensions applications wrappers The goal of the license is to scope copyleft selectively, to miss applications, but cover everything else: patches extensions applications wrappers copyleft copyleft PERMISSIVE copyleft With that in mind, the license needs to draw two lines, one between extensions and applications, the other between applications and wrappers: 1 2 patches extensions | applications | wrappers copyleft copyleft | PERMISSIVE | copyleft Earlier versions of the license drew each of these lines in separate language, using different words and concepts. But the current draft draws both lines with the same words and concepts: functionality and interfaces of the licensed software. How do we distinguish applications from extensions? Extensions go beyond accessing the licensed software through the interfaces it already exposes. How do we distinguish applications from wrappers? Wrappers make the licensed software’s interfaces or functionality available to still other applications. The interface-functionality concept is a kind of pun. It just so happens that we can draw both extension-application and application-wrapper lines with it. Coincidentally, that seems to achieve the goals of the license very nicely. The inimitable Jeff Atwood caught onto this pretty much immediately, and responded to my pleas for help renaming the form, in these tweets: The tell is that you keep using the word API to describe it. That needs to be in the name. I still think you’re going to be in a world of hurt unless you go with API License. You can explain the other exceptions more easily than “interface boundary” I quibble, because API is just one kind of interface, and the license covers many kinds. I’m right, but I think Jeff is, too. It’s a little strange to name a specific license after the licensing paradigm it represents. But why not just “API Copyleft License”?</summary></entry><entry><title type="html">Critique This License</title><link href="https://writing.kemitchell.com/2019/01/27/Criticize-This-License.html" rel="alternate" type="text/html" title="Critique This License" /><published>2019-01-27T00:00:00-08:00</published><updated>2019-01-27T00:00:00-08:00</updated><id>https://writing.kemitchell.com/2019/01/27/Criticize-This-License</id><content type="html" xml:base="https://writing.kemitchell.com/2019/01/27/Criticize-This-License.html"><p><em>Update: Thanks to some great feedback, this license form has evolved considerably. See <a href="https://commonform.org/kemitchell/proprietary-software-license/latest">the latest draft on commonform.org</a> for the most recent text.</em></p> | |
| <p>I’m working on a short, minimal, but adaptable paid software license. I’d be grateful for feedback from colleagues and <em>especially</em> non-lawyer programmers and business people.</p> | |
| <p>You can <a href="https://docs.google.com/document/d/1rgmbrS92_mGmMg8kuL9uWThtLtH99k13qkqPOaDx6jc/edit?usp=sharing">make comments on this Google Doc</a>.</p> | |
| <p>The terms work with an “Order Form” that sets out essential details and key terms, like who is buying from who, what software they’re buying, what versions are covered, and whether the vendor is agreeing to an extended patent warranty. Vendor and customer sign the order form, which references the legal terms.</p></content><author><name>Kyle E. Mitchell</name></author><category term="Contracts" /><category term="Forms" /><category term="Software" /><summary type="html">Update: Thanks to some great feedback, this license form has evolved considerably. See the latest draft on commonform.org for the most recent text. I’m working on a short, minimal, but adaptable paid software license. I’d be grateful for feedback from colleagues and especially non-lawyer programmers and business people. You can make comments on this Google Doc. The terms work with an “Order Form” that sets out essential details and key terms, like who is buying from who, what software they’re buying, what versions are covered, and whether the vendor is agreeing to an extended patent warranty. Vendor and customer sign the order form, which references the legal terms.</summary></entry><entry><title type="html">Shared Component License</title><link href="https://writing.kemitchell.com/2019/01/12/Shared-Component-License.html" rel="alternate" type="text/html" title="Shared Component License" /><published>2019-01-12T00:00:00-08:00</published><updated>2019-01-12T00:00:00-08:00</updated><id>https://writing.kemitchell.com/2019/01/12/Shared-Component-License</id><content type="html" xml:base="https://writing.kemitchell.com/2019/01/12/Shared-Component-License.html"><p>Those following the public back-and-forth on MongoDB’s new <a href="https://www.mongodb.com/licensing/server-side-public-license">Service Side Public License</a> will have noticed that I think SSPL is open source, but not well crafted. The choice to <a href="https://webassets.mongodb.com/_com_assets/legal/SSPL-compared-to-AGPL.pdf">patch AGPLv3</a> made everything hard. I should know. I made the same mistake with <a href="https://licensezero.com/licenses/parity">my own strong-copyleft license</a>. 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.</p> | |
| <p>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.</p> | |
| <p>Follows now a first draft of a plain language license inspired by SSPL. This has <em>not</em> been shopped with other lawyers to date, and is not ready for use. I’m looking forward to reviewing, discussing, and refining <a href="https://github.com/kemitchell/shared-component-license">on GitHub</a>. If you’re interested, watch the repository or <a href="mailto:kyle@kemitchell.com">drop me a line</a>.</p> | |
| <blockquote> | |
| <h1 id="shared-component-license">Shared Component License</h1> | |
| <p>Developer: {Legal Name}</p> | |
| <p>Homepage: {URL}</p> | |
| <h2 id="purpose">Purpose</h2> | |
| <p>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.</p> | |
| <h2 id="disclaimer">Disclaimer</h2> | |
| <p><strong><em>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.</em></strong></p> | |
| <h2 id="acceptance">Acceptance</h2> | |
| <p>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.</p> | |
| <h2 id="copyright">Copyright</h2> | |
| <p>The developer licenses you to do everything with this software that would otherwise infringe copyrights in this software they can license.</p> | |
| <h2 id="patent">Patent</h2> | |
| <p>The developer licenses you to do everything with this software that would otherwise infringe any patent claims they can license.</p> | |
| <h2 id="reliability">Reliability</h2> | |
| <p>The developer will not revoke this license.</p> | |
| <h2 id="notices">Notices</h2> | |
| <p>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.</p> | |
| <h2 id="contribution">Contribution</h2> | |
| <p>When this license requires you to contribute software:</p> | |
| <ol> | |
| <li> | |
| <p>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.</p> | |
| </li> | |
| <li> | |
| <p>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 <a href="#copyright">Copyright</a>, <a href="#patent">Patent</a>, and <a href="#reliability">Reliability</a>. Your other terms may, but need not, include a rule like <a href="#notices">Notices</a>, a disclaimer like <a href="#disclaimer">Disclaimer</a>, or both, but no other terms. For example, you may license under the <a href="https://spdx.org/licenses/BSD-2-Clause-Patent.html">BSD-2-Clause Plus Patent License</a>.</p> | |
| </li> | |
| </ol> | |
| <h2 id="changes">Changes</h2> | |
| <p>Contribute changes to files containing this software.</p> | |
| <h2 id="additions">Additions</h2> | |
| <p>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 <a href="#superstructure">Superstructure</a> requires.</p> | |
| <h2 id="applications">Applications</h2> | |
| <p>You need not contribute applications that only invoke this software’s functionality through the interfaces this software exposes, unless <a href="#superstructure">Superstructure</a> requires.</p> | |
| <h2 id="superstructure">Superstructure</h2> | |
| <p>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.</p> | |
| <h2 id="interfaces">Interfaces</h2> | |
| <p>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.</p> | |
| <h2 id="excuse">Excuse</h2> | |
| <p>You are excused for unknowingly breaking <a href="#notices">Notices</a>, <a href="#changes">Changes</a>, <a href="#additions">Additions</a>, or <a href="#superstructure">Superstructure</a> if you do what the rule requires, or stop doing anything requiring this license, within 30 days of learning you broke the rule.</p> | |
| </blockquote> | |
| <p>How does this draft compare to SSPL, substantively?</p> | |
| <p>Like SSPL, the draft substantially strengthens copyleft. It follows the line of <a href="https://opensource.org/licenses/OSL-3.0">OSL</a>, <a href="https://www.gnu.org/licenses/agpl-3.0.en.html">AGPLv3</a>, <a href="https://opensource.org/licenses/QPL-1.0">Q</a>, and <a href="https://opensource.org/licenses/RPL-1.5">RPL</a> in that respect.</p> | |
| <p>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 <a href="https://writing.kemitchell.com/2018/11/04/Copyleft-Bust-Up.html#commercial">written about that innovation and its political consequences</a>.</p> | |
| <p>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 <a href="https://www.mozilla.org/en-US/MPL/2.0/">MPL 2.0</a>-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.</p> | |
| <p>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 <a href="https://opensource.org/licenses/RPL-1.5">RPL</a>. The draft is <a href="https://writing.kemitchell.com/2018/08/28/Unhappy-Coincidences.html#software-freedom-doesnt-mean-patches-back">an actual patches-back license</a>, not a patches-forward license that only incidentally empowers users to send code back.</p> | |
| <p>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.</p> | |
| <p>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.</p> | |
| <p>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.</p> | |
| <p>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.</p> | |
| <p>The key issues in my mind, going forward:</p> | |
| <ol> | |
| <li>What parts won’t be clear to developers? Any confusing parts?</li> | |
| <li>Can we improve the boundary between changes and additions, on the one hand, and applications, on the other?</li> | |
| <li>Can we improve the boundary between applications and superstructure?</li> | |
| <li>Can we find a better term than “superstructure”?</li> | |
| </ol> | |
| <p><a href="https://github.com/kemitchell/shared-component-license/issues/new">Open an issue on GitHub</a> or <a href="mailto:kyle@kemitchell.com">drop me an e-mail</a> anytime.</p></content><author><name>Kyle E. Mitchell</name></author><category term="Copyleft" /><category term="Licensing" /><category term="Open Source" /><category term="SSPL" /><summary type="html">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.</summary></entry></feed> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment