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.
> 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 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.
> 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.
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.
RMS had a local Boston area lawyer help with GPL. I can’t remember the name offhand, but they’re still in practice, albeit not so much in open licensing.
I’d agree that Prosperity is not an open source license, but I still emphatically maintain that Parity is.
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:
> I’d agree that Prosperity is not an open source license, but I still emphatically maintain that Parity is.
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.)
> Amateur is ad hominem, and also simply incorrect.
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 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.
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:
> To be absolutely clear, neither of these "License Zero" licenses are open source or open source compatible in any way whatsoever.
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.
I neither coined “open software”, nor do I think it misleading.
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.
How easy a license is to read and apply is not relevant to whether it's an open source license or not (and personally, as a non-lawyer, I've also found the GPL to be very easy to read).
"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.
Readability goes to whether a license is misleading. The more readable, the less potential to mislead, assuming effect isn't compromised for it.
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.
> Readability goes to whether a license is misleading.
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.
The four freedoms, or What is free software? on fsf.org, are even less precise than the Open Source Definition. None of those is an effective "test" in any technical sense. Frequently, debates about whether licenses "pass" them turn into debates about what the words of the test mean, rather than what the terms of the license mean.
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?
Holy cow, what a rambling mess this blog article is. Perhaps I'm just tired after a long, arduous day negotiating corporate life. Does anyone know what the author is trying to say?
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.
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.
Reading the article gives me the same feeling as trying to understand typical highly overabstracted "enterprisey" code, which seems rather fitting given the title.
This post makes more sense if you know what license zero is.
> 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.
The name "license zero" might be a bit too close to the CC0 license. Maybe a rename might be a good idea? It also doesn't describe the license accurately.
The project’s been going for a while now, and I haven’t heard of anyone confusing License Zero, or one of the public licenses it stewards, for CC0.
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.
I work for a giant global enterprise that buys from your employer, specifically for (a) indemnity and (b) “train the trainer” jumpstart expertise.
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.
I don't think I explained myself very well (edit: and I am typically oversensitive to suggestions that enterprise software isn't a genuinely difficult and important undertaking). My point was that there is a lot of work that needs to be done to make software usable in an enterprise environment that is orthogonal to the license. A lot of that work is simply not a problem for most individuals.
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.
If I implied as much, could you mention where in the post?
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.
Commenting unofficially as an open source fan inside a globally giant enterprise, your post (a) made sense, (b) was circulated to folks much less familiar with these concerns.
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 suppose I might have listed "form a company to commercialize" as one of the approaches, and tagged it as the one with greatest flexibility to add more offerings on top of license rights. I think License Zero, Tidelift, and other "sustainability as a service" offerings exist largely because the overhead of company-based commercialization is so high, and it doesn't scale well down to very small open source projects.
The string of questions under Scope are themselves scoped to a particular subset of what enterprises require from vendors.
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.
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.