In defense of a third way in open software licensing
blog.licensezero.com
blog.licensezero.com
* "Parity Public License" is a poorly drafted and extremely aggressive alternative to the AGPL, requiring users to "Contribute all source code for software you develop, deploy, monitor, or run with this software".
* "Prosperity Public License" is a proprietary shareware license with a 32-day free trial.
This license is trying to square the circle of having source code open to individuals who want to tinker with it and at most cover their costs, and those who want to build multi billion dollar empires out of it.
Facebook, Google and Amazon wouldn't be the monopolies they are today if the software cost of spinning up 1 server wasn't the same as the cost of spinning up 1,000,000.
This is a very hard problem where intention matters far more than anything concrete. I can run 50 copies of some IoT code and still have it be non-commerial, I can run one copy of linux and have it as the core of a multi million dollar business.
Today we have the problem of centralized servers far more than of secret source code. The GPL can't deal with this at all, and the AGPL is one small step in the right direction. Spreading the gains of the internet giants is one way of dealing with the problem of monopoly, one that is much less violent than splitting each company into several smaller ones that should compete against each other, as nearly happened to Microsoft.
> This license is trying to square the circle of having source
> code open to individuals who want to tinker with it and at
> most cover their costs, and those who want to build multi
> billion dollar empires out of it.
Open-source software can't be restricted to non-commercial use because that would violate the Open Source Definition (https://opensource.org/osd).
> Today we have the problem of centralized servers far more
> than of secret source code. The GPL can't deal with this at
> all, and the AGPL is one small step in the right direction.
Here's the relevant part:
<quote> In the end, license experiments are a threat, but not a threat to open source as defined. They’re a threat to what open source sought, as a movement: recognition and collaboration with business concerns producing proprietary software. Patches to existing licenses and license ideas don’t change how effective unpatched terms remain for other work. Rather, innovation threatens the symbiosis of open source orthodoxy and enterprise-procurement-bound proprietary consumption. Holding permission back reduces what the shepherds of open source can lead back to large company-consumers. Offering a compelling middle way that better balances concerns for smaller players reduces the number of projects that end up under pushover licenses, for lack of better-fitting options, ready for selective assimilation by big-company incumbents. Incumbents that prefer outlast and out-compete to contribute and compensate, when it comes to projects not invented here. </quote>
>Your software would then be proprietary software, not open-source, even if the entire source repository was public.
This view reminds me of the bad old debate about the fact that GPL was not an open source license. "How can it be open if it forces me to do thing I don't like? The only open license is the MIT license.". A more or less verbatim quote from the 00s on why Linux was doomed and should be classed as proprietary software.
What is your definition of open source?
If you go by the definition provided by the Open Source Initiative the following section means the GPL isn't an open license because it requires all software linked to it to be provided under the GPL too:
<quote> 9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software. </quote>
> If you go by the definition provided by the Open Source
> Initiative the following section means the GPL isn't an
> open license because it requires all software linked to
> it to be provided under the GPL too:
I don't know why you think the GPL isn't an open-source license, when it's listed prominently on https://opensource.org/licenses as OSI-approved.
I don't claim that any noncommercial license meets the OSD. I have and do argue my strong-copyleft license meets that definition, and acknowledge that's controversial.
Nobody, and crucially no legal right, makes it anybody's job to argue to the OSD. That is purely elective.
> There are nice diagrams showing "source available"
> separate from "open source".
First way: Highly permissive licenses such as ISC, BSD, and Apache.
Second way: Copyleft licenses such as GPL and AGPL.
Third way: ?
For reasons I point out in the post, I consider that implication harmful.
The third way referred to in the post is source-available software. Others may or may not include software under stronger-than-strong copyleft or reciprocal licenses, like my Parity or OSI-approved RPL, in that category.
The goal is never to restrict which people use the software. The goal is to create incentives for individuals to actually make that software, make a living on that software, spend a few decades doing it. Which today requires certain protections from powerful organizations and overall from predatory capitalist incentives. Maybe a license forcing so much opening up, that makes businesses never consider allowing it if they are competing on software in any way, because too much openness makes competing on software automatically unviable, allowing competition to freely enter the market. Parity license seems a bit better at this than AGPL, but still doesn't feel like it's attacking the right issues.
> The goal is never to restrict which people use the software.
To qualify as an open-source license, the answer must be "yes". Otherwise the license is restricting who can use your software.
The Prosperity Public License restricts commercial use, therefore it is not an open-source license. You can't wordsmith your way out of this.
It started as a way to sell Linux to companies that didn't like Stallman. That you're trying to define away that history to people, such as myself, who were there when it happened and are still deeply ambivalent about the choices made is extremely disingenuous.
Parity is a radical copyleft license. If "not perfectly clear in every case" means "poorly drafted" to you, welcome to the wonderful world of legal drafting. You might like to review:
https://heathermeeker.com/open-source-faq/what-are-the-most-...
https://mjg59.dreamwidth.org/49370.html
https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...
Who bears the cost of the uncertainty in rules 1-3 of the Parity license? Does that help or hurt the goals of the license? For more on Parity, and the thought that went into it, see:
https://blog.licensezero.com/2018/09/14/free-to-take-freedom...
As for "shareware", the definition isn't rigorous. But almost all the shareware I've used was distributed binary- or bytecode-only, and often feature-incomplete, or limited by license-key-based software controls. Which is the point again. Developers can publish source without giving open source licenses.
> Traditional proprietary software is not publicly available
> in source form.
> make source available, and develop it in the open,
> without giving a permissive public license that defeats
> your other immediate needs.
> Parity is a radical copyleft license.
> As for "shareware", the definition isn't rigorous. But
> almost all the shareware I've used was distributed
> binary- or bytecode-only, and often feature-incomplete,
> or limited by license-key-based software controls.
Practically speaking, code developed in the open, by a diverse set of contributors, under a noncommercial license permitting redistribution, is far more comparable to open source than to Windows. That distinction is very clearly worth making. Doing otherwise risks forcing developers onto open source licenses when they're suboptimal, and nursing a misconception that the benefits of available source code accrue only to available source code that is also licensed under OSI- or FSF-approved terms.
Your conclusion on the enforceability of copyright use restrictions is incorrect. Look at Vernor v. Autodesk and the MAI Trio. Look the CC-NC litigation.
I have written far more proprietary than open source licenses, professionally. But practicing this area of law doesn't make my arguments correct. They have to stand on their own, without ad hominem support.
> You're defining proprietary to include source-available.
> That is part of what I mean by "the two-party system" of
> thinking, forcing options into one camp or the other.
> Practically speaking, code developed in the open, by a
> diverse set of contributors, under a noncommercial
> license permitting redistribution, is far more
> comparable to open source than to Windows.
> Doing otherwise risks forcing developers onto open source
> licenses when they're suboptimal, and nursing a
> misconception that the benefits of available source code
> accrue only to available source code that is also licensed
> under OSI- or FSF-approved terms.
> Your conclusion on the enforceability of copyright use
> restrictions is incorrect. Look at Vernor v. Autodesk
> and the MAI Trio. Look the CC-NC litigation.
You might like to argue that your binary distinction is best. That's fine. But you're going to have to argue.
> The benefits of being open-source ought to accrue only to software that is open-source.
I would say that benefits ought to accrue to software according the benefit it brings. There is a lot of value in publishing source, even without an OSI- or FSF-approved license. That value ought to be recognized, not lumped in with software without public source. As I wrote in the post: "Publishing code alone brings many of the benefits currently imputed exclusively to open source under licenses like MIT and BSD."
> None of those cases are relevant to this discussion.
Vernor was decided _after_ enactment of 17 USC 117, addresses it directly, and cites the MAI Trio extensively. If you don't want to read the opinion, here's the EFF writeup:
https://www.eff.org/cases/vernor-v-autodesk
They quote the holding, where the court uses the exact phrase "use restrictions".
If you want to argue that public licenses can't enforce use restrictions because they aren't written directly to the 17 USC 106 rights, and that incidental, inevitable exercise of at least the exclusive reproduction right doesn't count under 17 USC 117, you have to deal with the "owner" language there, and the clear deviation from the CONTU Report. And Vernor.
As for the CC-NC licenses, the parties in Great Minds didn't dispute that the use was noncommercial. IIRC, they clashed on another part of the license, namely whether the noncommercial user could have a third party exercise its license on its behalf.
Here's English coverage of a German court enforcing a CC-NC license in a pretty far reaching way:
https://www.techdirt.com/articles/20140326/11405526695/germa...
Find a new term and establish it instead of trying to capitalize on an existing one that means something else.
"Source available" is a fine term (if there's a more specific one for a specific license, present that), and gets the entire meaning debate out of the way, so one can discuss the merits of the license as it is, not purely in comparison to something it somewhat pretends to be.
(this specific blog post is better at this than other messaging, but this at least partially explains why the climate is so unfriendly)
Without meaning to overshadow that positivity, I'd offer two tiny quibbles:
The OSD is pretty clear ... if you ask easy questions. I tried and failed to find the strongest copyleft license that OSI would approve. The main upshot of that laborious process was that OSI wouldn't likely approve such a license, even if it met the OSD.
As for creating confusion with an established "brand", I tried to address this in the post, by analogy to vote splitting. That may have got buried too deep, in the final edit. My point there is basically one I've made here on HN before:
It's deeply disingenuous for this blog post to use the word "bullying" to describe the community's rejection of software distributed under undesirable or ill-considered terms. You can ship your code under whatever terms you want, but don't act like users and contributors have an obligation to support you when you make choices that don't serve their interests.
As for "bullying", that very adequately describes behavior on GitHub, Twitter, mailing lists, and news sites toward those behind React, Commons Clause projects, and Lerna. "Failure to support" is a straw man.
That really doesn't matter. All they know about open source is based on this definition. There millions of articles about open source on the internet that use it. You are trying to invalidate all of them for no good reason. As a consequence every opinion about open source they ever read prior to your efforts would be outdated. Most people understand danger of these actions which leads to behavior you described as "bullying".
The Open Source Definition says nothing about source control, patch submission, bug tracking, releases, versioning, dependencies, package repositories, continuous integration, test coverage, style guides, codes of conduct, and so on. There are also articles on the Internet that talk about a "post-Open Source" GitHub generation, and articles that affirmatively reject definitions of open source in terms of license conditions, rather than community. OSI has been controversial since inception, and there's plenty about that, too.
If the OSD were merely a descriptive framework, that would be one thing. "Here is a class of licenses we can describe, and here are benefits we can correlate with them." But OSD gets used far beyond that. It's used prescriptively. It's used to sanction. Those are social functions of a movement, and the crux of a movement is participation, not definition. It matters that people making open source haven't heard of OSD, because they neither participated in its adoption nor consented to its authority. It has no sway over them. The idea that a mailing list could define their community rankles.
I don't consider debate about OSD, DFSG, or "What is free software?" bullying. I do consider peer pressure on maintainers to adopt terms that don't advance their goals, against their stated interests, bullying. I consider unfounded legal FUD to the same effect bullying. Have a look at the Lerna GitHub issues, or Twitter conversation about Commons Clause.
There is nothing in your list that is different for open-source and proprietary software development. You could as well add countless articles about OOP and functional programming because they mention some open-source tools.
OSD is about answering three simple questions. Should I use some program or library? Should I contribute to its development? Should I release my new program or lib as open-source? OSD makes process of choosing the answer fairly simple and helps developer avoiding all weird legal stuff. He doesn't need to know OSD and read full texts of licenses as long as he uses most adopted like MTI, BSD, GPL. Descriptions of pros and cons of every one of them in layman terms are available on the internet. It's hard to say the same for the ill-conceived licenses you mentioned.
I can't sell some project based on Lerna to [list of companies] ? OK. How am I supposed to check that the company didn't change name? What if I am selling my work to subcontractor? I would probably have to include this list in every contract. What if every open-source project started banning some arbitrary list of companies? Am I supposed to review the last commit to license every time to make sure that my company wasn't included? All that looks, sounds and smells like a lot of headache and any reasonable person would drop the project with first sign of it.
Commons Clause was even worse. It was advertised as "MTI+CC", but nobody would be able to figure out what "CC" part meant for them without a lawyer. And any lawyer would advise to find something else.
That's not right, even assuming full "Innersource".
My point was that OSD is a set of criteria for licenses, plus a source-availability requirement. Those criteria don't predetermine all the practices that make up open source development right now. Those practices have changed! The OSD largely hasn't.
> OSD makes process of choosing the answer fairly simple and helps developer avoiding all weird legal stuff.
If you've managed to avoid all weird legal stuff so far, I'm glad for you. A good portion of my legal career is addressing weird legal stuff, which crops up even with MIT, BSD, and GPL, to use your list. The GPLs and other copyleft licenses are chock full of weird legal stuff.
> Descriptions of pros and cons of every one of them in layman terms are available on the internet. It's hard to say the same for the ill-conceived licenses you mentioned.
I wrote one of the more popular guides to MIT in layman's terms:
https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...
I've also summarized the License Zero public licenses:
https://guide.licensezero.com/#public-licenses
The License Zero licenses are far easier to read, besides. That was part of the point of writing them from scratch.
> What if every open-source project started banning some arbitrary list of companies?
Highly unlikely. And that is not the approach of the License Zero licenses, React, Commons Clause, or most others that I mention.
If somehow this did become popular---again, very hypothetical---I'd go into npm and RubyGems and other package managers, and propose a package metadata field for excluded entities, and perhaps standardized categorical exclusions. This still sounds inconvenient, and I agree that it would be. But to give you a sense of near current practice, some large companies prohibit use of open source from specific competitors, even under permissive licenses, especially when the patent terms of the license are weak or nonexistent. That would include MIT, BSD, and GPLv2.
> And any lawyer would advise to find something else.
Or do a deal with Redis Labs. Which was the point, I think.
https://i.imgur.com/bSdusjH.png
It's not about "two-party system", it's about the "natural" distribution of software distribution models.
Stuff written in BASIC naturally came with its own sources, but even then people would often obfuscate it to avoid derivative works being made. People wanted reputation, not money, and they didn't want their work ripped off, or for others to profit off their labours.
In the RISC OS community I was a part of, releasing source as a matter of course only became common with the influence of Linux. Before that, binary-only PD with homebrew or completely absent licensing was the norm.
Might you be able to mention any particularly important or memorable programs distributed that way? I'd be really interesting to go back and try to find contemporaneous writing about the motivations you mentioned.
As for the contemporaneous writing, I'd start with the comp.sys.acorn.* newsgroup archive on Google Groups, because it's searchable (and I definitely remember this stuff being discussed in the late 90s, mainly as a reaction against the rise of Free Software.
Incidentally, the decline of the RISC OS market really brought home to me the value of having sources available (and being allowed to use them). We had two significant breaking architectural changes (StrongARM architecture in 96 and the move from ARM's 26-bit to 32-bit addressing mode in the 00s) which cost us a lot of good software because the authors had moved on and nobody could fix the code.
Interesting!
> comp.sys.acorn.* newsgroup archive
Thanks!
> Incidentally, the decline of the RISC OS market really brought home to me the value of having sources available (and being allowed to use them).
I have a few of these stories, but now I have one more.
The developer wants to get paid to develop the source code.
The administrator wants to be able to modify and deploy the source code and be paid for running the resulting program.
The user wants to be able to review the source code and administration logs.
Open source as currently defined covers 100% of the interests of the administrators and none of the interests of the other groups.
The AGPL kind of covers some of the interests of the users.
Closed source protects the interests of the developer.
Being a member of all three groups I would be very interested in a license that manages the trade offs so the admins, in the guise of google and amazon, don't suck up all the money from developers and turn users into a commodity.
https://www.microsoft.com/en-us/sharedsource/
I'm not sure if many webapps like gmail that have a big chunk of the UI in javascript count as "all rights reserved" "source-available". The code is minimized, obfuscated, and perhaps is the result of the transpilation of the real source, and it must talk to the servers that has not public source code.
The reason there isn't much in the public-domain, closed-source quadrant is that permission without code is completely useless. For example:
I hereby grant you, m1el, an MIT license for the short novelty program I have just fixed in the tangible medium of expression know as my hard drive, project name Caveman. Enjoy!
Compare code without permission, which still has some limited value for others, especially educational and inspection value, as well as for the developers, in the form of access to free services.
I'd also put a number of public-patent-grant programs in that family. That's potentially much more interesting.
If MongoDB is AGPL, why does everyone else throw a shit fit? Despite its faults, MongoDB is still massively popular, so I assume it's used at many enterprises.
Also, side note: can anyone point a blog post (preferably from a lawyer) that explains why AGPL is so problematic?
The AGPL attempts to restrict behavior that does _not_ require copyright permission. If I have MongoDB running on my server and it serves as a datastore to my website, then no part of MongoDB is copied off my machine. Copyright doesn't apply. So the only way the AGPL can exist is if it's _not_ a copyright license.
But if the AGPL isn't a copyright license, what _is_ it? Is it a contract with no consideration? Is it a copyright license _combined with_ a contract? Is it like a EULA, and if so, how does it apply when the apparent end-user (the person visiting my site) hasn't accepted the terms?
Lawyers don't like these sort of pseudo-contract legal constructs, they're the law equivalent of a flaky hour-long integration test.
The consideration is the software itself. In exchange, you are granted a license. The license requires (in part) that you offer the source code to any user that uses the software. As the service provider, it is copyright infringement to make available the AGPL licensed software unless you agree to the license.
The problem with MongoDB is that they are using the AGPL in a way in which it wasn't intended to be used. This confuses the issue about what you are and are not allowed to do.
> As far as I understand, the AGPL kicks in on "propagation"
> -- which in the important case means "making available to
> the public".
- To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
- To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
They make the distinction in the AGPL (which I think they don't in the GPL) for exactly the reason you state.
It's exactly the same with any proprietary server software. You can have a copy of the software, but without a license to allow others to run it, then you can't make it available on a network. These days most server software explicitly allows unlimited use in their license, but in the old days it was always per seat licencing.
If the AGPL is invalid, then so are all extant proprietary server licenses.
> If the AGPL is invalid, then so are all extant proprietary server licenses.
The GPLv3 does distinguish propagation and conveyance. This allows the license to put fewer restrictions on certain types of copying that are relevant to large organizations.
If I'm a server software producer and I sell you a copy of a piece of software, you can't actually use it unless I also give you a license to use it. This is unlike any other kind of machine that I might make and sell to you. If I sell you my fancy coffee roaster, I literally can not force you to use it in a specific way. This is actually why printer manufacturers put software in the ink cartridges -- so that they can force you to agree to a usage license.
The reasoning behind being able to extend copyright to running programs (which I think is BS, personally, but I don't make up the laws) is that the computer that runs the software must load, and therefore copy, the software. You only have permission to do that if the copyright holder gives you permission to do that.
This is where the license comes in. I give you a license to load the software into running memory (and hence run it), on the provision that you follow the rules I state. You don't have to agree to the license, but if you don't agree, then you don't have a license, and you are forbidden by copyright law from running the software.
With the AGPL, the license is given provided that you agree to give the users a compatible license to the software. Again, the contract consideration is: ability to run the software in exchange for agreeing to the terms.
You are right that the GPLv3 does reference propagation. I should have looked. It mentions it specifically to state that the GPL does not come into effect on propagation, only conveyance (which is the main difference between it and the AGPL).
Edit: spelling
https://blog.licensezero.com/2018/09/14/free-to-take-freedom...
Especially this section:
https://blog.licensezero.com/2018/09/14/free-to-take-freedom...
I know some lawyers who would prefer and argue for your reading of copyright law's limitations, as a matter of policy. But that is not the reading that I see in court decisions or professionally drafted copyright licenses, which impose blanket use and purpose restrictions all the time.
To your point, copyright law is "default deny". (See also: https://oss.kemitchell.com/#defaults-and-overrides) Take as given that the uncertainty you describe is as serious as you present it. Who does that uncertainty benefit, in context? Consider: https://opensource.google.com/docs/using/agpl-policy/
> But that is not the reading that I see in court decisions
> or professionally drafted copyright licenses, which impose
> blanket use and purpose restrictions all the time.
I won't be providing you any further comments. If you have need of specific guidance in this legal area, please seek your own legal counsel.
The root of it is that the copyleft licensing scheme was from the beginning merely a clever hack. Ideally (from a free software perspective) copyright law would not protect functional software, and we would have another law that requires all published software to be free software.
The GPL was a speculative attempt to bend problematic copyright laws to the purposes of free software. Over time the GPL has proven to work, sort of. But it was not clear at the beginning that it would. Years, decades, have gone by and we now see that there are ways for companies to restrict user freedoms with software that technically complies with the GPL. The GPL was pretty successful for the 1990s concerns, why not make an updated license that addresses 21st Century business models. It is still not clear whether the AGPL will work as well vs SaaS as GPL did against the "selling copies" model.
There are really 2 issues you need to keep in mind: 1) there is a difference of opinion about whether linking to an unmodified, GPL or AGPL licensed library is considered to be a "modification" of that library; 2) GPL and AGPL are different in terms of software that is only accessed via a network (i.e., the user does not receive a copy of the executable code).
In the first point, the FSF (who maintains these licenses) believes that linking to a GPL or AGPL license creates a "combined work" that requires a license that is compatible with the GPL or AGPL. In other words, you can't "convey" (distribute) the combined program unless the overall license has compatible terms. Other people disagree. To my knowledge, this point has not been tested in court. While the GPL itself is well tested in court now, that is for applications that are clearly based on a GPL licensed piece of code. Whether or not a library that is providing a utility function has that same legal protection is still untested (as far as I know).
However, there are a couple of things that I think are important about this. First, the intent of the licenses is clear. It's a completely jerk move to use a GPL or AGPL licensed library without considering the intent of the authors that chose that license. You might get away with it legally, but why be a jerk just to save a few bucks? (Not that it stops people...) Secondly, the intent of the license is clear, if you want people to use the software in a different way, please pick a different license! There are many appropriate licenses (and probably the LGPL is what a project like MongoDB should be licensed as). I'll talk a bit about that at the end.
With the second point, it's important to understand the difference in use cases for the GPL and AGPL. The GPL is intended for applications that are meant to be "conveyed" (distributed) to the user. The user then runs the program themselves. With a GPL or similar license, they enjoy the 4 freedoms of being able to run the software for any purpose, inspect the source code, modify the source code, and to distribute their modifications if they wish (as long as they grant the 4 freedoms to their users).
The AGPL is designed to give similar freedoms to people who do not receive an executable -- their only interact with the software is through the network. The only reason for choosing the AGPL is to ensure that users can receive the source code to: run the code for any purpose (rather than just the purpose the service provider allows), inspect the source code, modify the source code, and distribute their changes.
I don't know the history of MongoDB, so I don't know why they chose the AGPL. It is frankly a bizarre choice, IMHO. My only guess is that they intended that users of an online service be given access to the MongoDB source code. Why they thought that was important, I really don't know. The MongoDB developers are pretty adamant that the license does not restrict people from building services that are not AGPL.
In practical terms, for the moment anyway, it's not a big deal. Even if the AGPL applies to the combined software (and FWIW, I believe that it does), the only people who have standing to sue are the copyright holders of MongoDB. They have clearly said that they are happy with people not offering the 4 freedoms when making services using MongoDB. In other words, you can be relatively sure they aren't going to sue you -- and nobody else has standing to do so.
On the other hand, it's still a legal liability. If MongoDB changes hands some day and the new copyright holder has a different opinion, will you end up getting sued? Although I think it is incredibly unlikely, it could definitely happen. Crazier things have happened.
To sum up, AGPL is not problematic at all, if you are using it as intended (as an aside, I actually don't like some of the wording, which I think is a bit hand-wavy at times, but it's the best license that I know of for the niche that it occupies). The only problem is that MongoDB developers are using it in a way that differs from its intended purpose and are thereby muddying the waters in terms of communicating what they want. I suspect they simply made a mistake originally and now it's just too difficult to make the license change.
But, at the end of the day, there is no excuse - we cannot sacrifice our ideals/values just because Open Source can be rough.
True Open Source is worth making the sacrifice for, but there are a lot of new/old licenses trying to evangelize themselves as "Open Source" but are secretly masked proprietary/cripple-ware. This needs to be stopped.
We had a good discussion about this on Twitter the other day: https://twitter.com/marknadal/status/1032763711008559104
There's no question that useful software that costs for commercial use produces less economy-wide benefit than useful software that's always free of charge. But the question isn't how much potential benefit open source can pump out, but rather how much benefit open source can pump out for the cost, and how that cost gets allocated.
I've never held Prosperity, or its predecessor, out as open source licenses in the traditional sense. Others have called them so, even after I pointed out my own opinion.
I have and do hold Parity out as an open source license. If copyleft licenses don't meet your definition of open source, or only copyleft licenses with known, practical software-freedom vulnerabilities, I can certainly square that with your view of open source's purpose. But I can't square it with open source's history, or with most stacks we call "open source".
I think it would work better to argue, open source is about leaving aside the ethical considerations (which are highly charged topics) to focus on how effective is code sharing as a development methodology, and within that, what licensing regime under current law works best from a business perspective. And the question is different for an academic talking about larger society, vs. an individual business or developer who is choosing his/her/its own license. Obviously your duty as an attorney is to grapple with the latter question.
Thus, while I personally am more or less with RMS on the ethical inquiry, I see no reason why your L0 ideas should not be discussed within the context of open source. I personally would not choose to use your license, but that is irrelevant.
One point of errata in your essay: free software (I hope) does not depend on copyright protection. Far from it. Free software viewpoint is that copyright protection should not extend to software. Rather, the law should require published software to be free software.
However, given that the law is not going to change anytime soon, the GPL was written as a clever hack to use copyright to promote the values of software freedom. This has been successful to some degree, so it is a perfectly fair question to ask what we would do for software freedom if copyright protection as we know it today did not extend to functional software. But this is probably not a question that would be asked within the context of "open source" I guess...
https://blog.licensezero.com/2018/09/14/free-to-take-freedom...
I can speak about APGL. They limit commercial freedom, specifically the right to commercialize software incorporating AGPL code, and either distribute it or provide it as a network service without source or a similar license. In other words: the freedom to make and market software in the usual commercial way. A limitation on Freedom 3 (to share changes)? The FSF says so. A limitation on Freedom 0 (to run the software)? They don't say, but I think so.
I also think you're right that software freedom doesn't depend on copyright. Copyright is merely a means to it, via copyleft. But if the law required freeing of software, that would restrict commercial freedom publicly in the same way AGPL does by private ordering. Unfortunately, that law would also have to require disclosure or publication of source code, and conformance on all the other fronts where AGPL fights: patent law and DRM, for example.
That's a far more expansive legislative program than abolishing copyright. Abolish copyright, and I can keep my code secret. And lock others' code down with patents. And so on. Many laws affect software freedom!
> I see no reason why your L0 ideas should not be discussed within the context of open source.
I agree.
In terms of open development as a production system, my point is largely here: https://blog.licensezero.com/2018/09/16/two-party.html#swing...
If making software in the open made sense to more people, we'd get more of it. Many of those projects might start as source-available, and end up copyleft or permissive open source. But instead of paving that path, we shame it as proprietary, and lump it in with Windows.
Open source orthodoxy is right about transaction costs and efficiency on the consumer side, but totally abdicates the supply side of software production. I've read on their mailing list that if you have to ask how you're going to make money making open source, you're the wrong person to be making open source, and that OSI doesn't owe any cycles on any business model.
> And the question is different for an academic talking about larger society, vs. an individual business or developer who is choosing his/her/its own license. Obviously your duty as an attorney is to grapple with the latter question.
I can't tell you how much it means to read that. Thank you for acknowledging. It gets lost.
* Heather Meeker (Fair Source, Commons Clause) * Tidelift (Luis Villa)
I wonder what happens when these peolle are given financial security?
As an investment in the future, the returns could be amazing! Many, if not all, authors really care and it shows.
Would making sure they are free to care, live well, maybe create more be such a bad thing?
Secondly, with that on the table, I wonder about the quality, and drive to create like that. We may see amazing tools.
Re: Open Source
Being able to see the source is high value. Being able to build on others work is high value.
Arguably, high enough value to trigger this kind of mess.
Pay them. Seriously.
Is the problem one of ego? AwesomeSauce.com wants to be recognized and get value from their work. Is recognizing CantLiveWithout DB or Language, Toolkit, etc... taking away from all that somehow?
Is it one of confusion?
AwesomeSauce.com paid, only to see AlsoAwesomeSauce.com not pay?
Does that matter, if bazillions are being made?
Seems to me this all can be litigated to our mutual detriment, or it can be handled as a family struggle, or worse.
Have to say, I do not blsme people looking hard at billion dollar enterprises, and their many big fix, support requests with a jaded eye, maybe a hungry one.
Fixing that scenario may well be ultra cheap compared to the mess and opportunity costs to come.
I put this here to stimulate some discussion, not as judgement, or anything aimed at anyone.
Really open licenses are a good thing. Really, really good thing. Many of us know the story. Pick up some code, any computer we can find and just build.
Breaking that seems extreme. Maybe it just does not need to be that way.
Maybe it should not.
What is worth what here?
Perhaps those conversations go far easier than the current ones will, and it is not like tech as a whole can't afford a solution.
Again, not a negative, or statement against anyone. Just thinking out loud here.
Still, opportunity costs on this are likely huge relative to settling financials on a merit basis.
I would never put such a license in the same category as the MIT or Apache licence.