Enterpriseification
blog.licensezero.com
blog.licensezero.com
Both explicitly violate the first principle of the Open Source Definition (https://opensource.org/osd-annotated), free redistribution.
We have the open source licenses we do for a reason. They've been vetted. They work. They meet established criteria. It's okay to consider new ones, but the process for that isn't just to make something up and hope it works.
Amateurs have no more business playing lawyer and writing general-purpose software licenses than they do playing doctor and handing out surgical advice. It's not thought-provoking, it's dangerous and harmful to people who don't understand why licenses like this could cause them huge unmitigated legal headaches down the road.
It’s worth noting that the creator of License Zero is in fact an actual lawyer. And he has been working on open source license issues (and blogging about it excellently) for many years.
Which may be why the author coins the misleading, sound-alike marketing term “open software”.
Though I’m not really sure what, if anything, the point of that long, meandering, piece was. It occasionally seemed like it might be circling in on making a clear point, butnthent drifted off in another direction.
Quite the contrary. Until the recent release of the Blue Oak Model license, with which I was also involved, I don’t think there had been a legally rigorous license as easy for non-lawyers to read and apply than Parity.
"Open software" is not a term of art in the free software community (only "free software" and "open source" are), which makes its similarity to "open source" seem quite suspect. And maybe you didn't come up with it, but that doesn't mean it's not a misleading term.
If you found GPL easy to read, v2 or v3, you join a list that as far as I know includes no active open licensing lawyers. Of all the major, painful, routine questions about open license compliance, those from GPLs outnumber all the rest.
Getting through the text is one thing. But that alone is not what I mean by a license being readable. In substance, rather than form, it has to be a functional set of rules.
If by term of art you mean defined with precision, neither open source nor free software meet that standard, unless you count definitions that say "whatever such-and-such organization says" or "whatever such-and-such organization's founder says".
The OSD may be readable for you, but only in the way GPL was. There's no legal or otherwise technical precision beneath those pleasant terms answering old, important questions.
More on that: https://writing.kemitchell.com/2019/04/23/OSD-wontfix.html
Nobody said the license text was misleading. The point is that the use of the term "open software" is misleading because it leads the reader to think it's similar to "open source" which in fact isn't.
On the topic of precise definitions, you might argue that "open source" is imprecise because it has other meanings and was in common use before OSI. But "free software" was a brand-new term and has a specific definition (the four freedoms). The DFSG are guidelines and tests to verify if the definition is followed.
To give a sense, FSF says "four freedoms", but they actually require at least five. The fifth (number 4) is the right to make and share nonfree work based on free work within organizations, known as "private changes". FSF writing doesn't explain the boundary between running and changing, or why free software licenses can set conditions on changing, but not running, or why AGPL gets to break that rule. They don't explain how anti-Tivo or anti-DRM satisfy the freedoms.
Readable licenses are important because they cut the welds on the hood of software licensing. Devs can read Parity or Prosperity or Charity or Blue Oak and decide for themselves whether it's open or free or public or simply allows them to do what they want to do. They don't have to trust intermediaries, who it turns out apply unexpressed, private views on what the definitions mean as or more often than expertise on what the licenses mean.
As for Parity and strong copyleft generally, consider:
> I make my code available for use in free software, and not for use in proprietary software, in order to encourage other people who write software to make it free as well. I figure that since proprietary software developers use copyright to stop us from sharing, we cooperators can use copyright to give other cooperators an advantage of their own: they can use our code.
Copyright has given authors broader and stronger control of their work in the last three decades. Why haven't FSF copyleft licenses gotten correspondingly stronger?
Moreover, the arguments against them I’ve heard haven’t been based in lack of free distribution or OSD 1. Anyone is free to redistribute Prosperity- and Parity-licensed code.
Amateur is ad hominem, and also simply incorrect. I won’t pretend my views are consensus, but I have spent a lot of time with OSD, and the result has been disappointment, not reverence. See:
https://writing.kemitchell.com/2018/11/05/OSD-Copyleft-Regul...
It's very clearly not.
> Moreover, the arguments against them I’ve heard haven’t been based in lack of free distribution or OSD 1.
While I see arguments on OSD 1, I’d agree that's not the clearest problem. Clause 3 of Parity runs directly contrary to OSD 9. (Oddly enough, Parity might just be the odd license that manages to be a Free Software license without being an Open Source license, though, as the Free Software Definition doesn't have anything equivalent to OSD 9, even though the two definitions usually either both fit or both don't fit licenses.)
You're not the only one who's said it's not, and I'm not the only one who's said it clearly is.
> Clause 3 of Parity runs directly contrary to OSD 9.
There is nothing clear about OSD 9, or at least nothing to do with the reach of copyleft:
https://writing.kemitchell.com/2018/11/05/OSD-Copyleft-Regul...
You're right. I do owe you an apology for that. Sorry.
I still find the circumstances _around_ license discussions like this to be filled with a frustrating amount of amateur lawyering that can be misleading and dangerous. As an open source developer and content creator, I can't tell you how many times I've come across something in GitHub with a "clever" license and thought "great, now not only can I not use any of this, but I see a whole contributor community who clearly believe they are contributing to an open source license when they very much are not."
I could not agree more. Except that I'd blame the lawyers, not the amateurs. There will be amateur discussion, because there are far more needs of the kind than affordable and available lawyers to serve them. If the level of amateur discussion bothers lawyers, the lawyers should raise the level of amateur discussion.
Gregg Toland famously told Orson Welles there wasn't anything about the camera he couldn't learn in half a day. That's true of law, too. With a baseline liberal education, if you put in enough days, you've got it. From there, you develop by immersion and participation. Simple as that.
I do what I can. With plain language. With public writing and participation in public projects:
https://fieldguide.kemitchell.com/
https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...
No, that opinion is fear mongering and damaging to a functioning democracy. Legal contracts are a foundational tool of modern democratic society. To say laymen should never write contracts means to say we should also give up valuable tools to make our lives better. Who do you think wrote the original GPL? According to Wikipedia Stalllman wrote it [1]. I bet many legal experts of the time wouldn’t have recommended the idea of copyleft or perhaps even condoned writing it. Having laymen initiate the contract writing process also helps put pressure to keep contracts in "plain language" as some advocate for [2].
To be clear, one _really_ should have a lawyer familiar with relevant legal jurisdictions to review anything written by a layman (especially oneself). However, it’s important for people to take active roles in the legal process lest it become the sole domain of lawyers. One example I’d construe is as a layman "writing (part of) a contract" would be a new employee requesting a change in an employment contract to change an overly broad IP assignment (say excluding after hour open source work in areas outside the businesses domain). It’s common for companies to just use whatever boilerplate employment contracts their contracted lawyers copied out of some off the shelf contract regardless of how it fits the business or employees.
1: https://en.m.wikipedia.org/wiki/GNU_General_Public_License#H... 2: https://hbr.org/2018/01/the-case-for-plain-language-contract...
Given the amount of effort it took to just barely understand what he's selling, I'd say he has some work to do if he wants people to buy into his idea.
I also don't find speaking about organizational questions in overly software engineering terms any good. "It's rather coupling than an adapter." No, just say that the sponsor would try to influence your OSS organization according to their interests. Damn.
> License Zero is a new way to support open software developers.
Contributors can choose from two new licenses, Parity and Prosperity, that make their work free for not-for-profit or open-source users, then sell private licenses to other devs who want to use for profit or in closed source. Everything happens through a simple, dev-friendly interface.
I called the project “License Zero” to reference its impossible goal: reduce the marginal cost of dual licensing, over simply receiving a public license, to zero.
The characterisation that license indemnity is the bulk of our value added is, putting it mildly, an incomplete one.
The table under scope specifically addresses differences in licensing expectations, rather than related services like maintenance, support, training, and integration. The string of questions under Scope mention the call for a broader, vendor relationship behind the code. I mention that Tidelift layers on maintenance assurances, aside from the license.
This post is inside baseball, and I’m surprised to see it on the front page of HN. But I’d like to make it clearer if I can.
Compliance and legal assurance are part of the value. But they are not the whole of what enterprise vendors do. Big companies have needs that no casual OSS contributor would need to scratch.
The table was particularly helpful, and at least this global enterprise is well aware of all the other nonsense it didn’t cover. I would have found adding those to the table to lessen your focused point about license openness and pitfalls vs. need of the ecosystem to be sustainable.
I would argue that to qualified engineering teams at a regulated buyer, license indemnity is the bulk of value of interest. Someone wants to use OOS, they have to go find a “liability sink”. The trick becomes finding one offering a purer upstream, and w/o vendor lock-in such as custom tooling devs have to learn to manage the system.
Given the qualifiers in that comment, many customers, including some within this firm, will find your broader ‘enterprise’ offerings of interest as well.
It's demonstrable that these features are orthogonal to license, because they were expected before OSS became a norm.
LDAP/SAML/OAuth/OIDC/whatever integrations, online backups, auditing, accounting and usage, multi-tenancy, credential management, file integrity, mandatory access control, etc etc. There are thousands -- literally thousands -- of things that enterprises collectively want that individuals and small teams don't even think about.
A lot of OSS efforts acquire these capabilities because an enterprise vendor sponsored their development. Hence my point that "a single throat to choke" is only a slice of the value we and our competitors add.