They mention it in one of the lines of this blog, but apparently this individual (perhaps with the help of others, it wasn't clear) has come up with two of their own software licenses, with a website and everything.
> The Prosperity Public License (Prosperity) works a bit like a Creative Commons NonCommercial license, but for software. Prosperity gives everyone broad permission to use your software, but limits commercial use to a short trial period of 32 days. When a commercial user’s trial runs out, they need to buy a private license or stop using your software.
> The Parity Public License (Parity) works a bit like AGPL, but requires users to release more of their own code, in more situations. Parity requires users who change, build on, or use your work to create software to release that software as open source, too. If users can’t or won’t release their work, they need to buy a private license that allows use without sharing back.
I'm one of those folks that usually defaults to AGPL for their open source work for practical reasons - it's much easier to go from a copyleft license to a permissive one due to circumstance than the other way around. However, I always found it a bit strange that there were dozens of variants of the MIT and BSD license out there, but aside from the GPL and MPL no other popular license really took up the mantle of copyleft, aside from perhaps the old Sleepycat license.
This looks like a very appealing license on its face, but the fact that it's specifically _not_ written in legalese is a little weird, though the fact that the author is a lawyer is some reassurance.
I am in fact the prime mover behind License Zero (https://licensezero.com), but I am by no means alone in it. Parity and Prosperity would not be what they are without enormous amounts of feedback and suggestions from users and interested hackers. Some of those folks agreed to be listed here: https://licensezero.com/thanks
That being said, you're absolutely right that we've seen more permissive licenses than copyleft license, by simple count. Compare: https://blueoakcouncil.org/list
> limits commercial use to a short trial period of 32 days. When a commercial user’s trial runs out, they need to buy a private license or stop using your software.
So it's clearly not Free Software because it doesn't respect freedom 0. Hardly a surprise that Bradley Kuhn and the FSF object to it being classified as such.
This is hardly a failure of "free software", just the author wants to try to subvert the definition which the FSF has long established. Maybe the author should try calling it something completely different (I suggest "trialware") and then the FSF wouldn't be bothered.
The GPL has always been criticized for its definition of distribution, which allows companies to host SaaS offerings of GPL software without having to make their modifications available.
Hosting a GPL-licensed server and receiving network activity does not constitute distribution, which is why the AGPL exists.
> However, I always found it a bit strange that there were dozens of variants of the MIT and BSD license out there, but aside from the GPL and MPL no other popular license really took up the mantle of copyleft, aside from perhaps the old Sleepycat license.
Fundamentally, copyleft can only be instantiated once. No two distinct copyleft licenses as we know them can be compatible with each other without jumping through carefully-placed hoops[1] because the combination necessarily imposes stricter distribution conditions (there would be no point otherwise), which is expressly what each copyleft license seeks to prohibit per se.
I think it's only a slight exaggeration to say that the perceived problem of license proliferation, and the ecosystem of license gatekeeping that sprung up around it, owes itself wholly to the design of the GPL in this respect.
It didn't last. The GPLv2/3 split haunts us to this day.
> Fundamentally, copyleft can only be instantiated once.
That's true of GPL-style copyleft, because it was designed quite intentionally to be a network-effect-leaden singleton. We say "GPL-compatible", but it's more accurate to say "GPL-submissive". The difference was felt very directly by the Eclipse folks in the run up to EPLv2.
But there's nothing about share-alike terms that require that stricture. The Parity license that I mention in the blog post takes a different tack. Have a look at its rule about how to contribute back: https://paritylicense.com/versions/7.0.0.html#contribute
A developer building on Parity code could choose to license their work on weaker copyleft terms.
It is always useful to fall back to basic when ever people try to redefine copyleft or GPL. A copyright license is a list of complex permissions. Nothing more, nothing less.
If you have a two set of permissions, compatibility is the logical conclusions of finding intersection and see which actions are permitted in both set. Set theory do not have submissive and dominant sets. The intersection is always the elements which are in both A and B.
The parity license says "Make sure every part of the source code is available under this license or another license that allows everything this license does". It practically spells out that permissions in the intersection that lies between parity and an other license is acceptable to use when combining parity with an other license. It is true. It also true for any other copyright license, including GPL.
You’re technically correct, and I think set theory is a very productive metaphor for the analysis. But that analysis with GPL hasn’t worked out so cleanly, however, due to its complexity. Even GPLv2 is a relatively long license. It attempts to spell out copyleft in relatively low-level terms, legally speaking. Add on additional cleverness, like anti-TiVo and liberty-or-death, and it becomes very hard to say where the boundaries are, or to compare them to less idiosyncratic licenses.
It is fair to say that a complex description of permissions is harder to define and compare than a simple description. GPLv3 attempts to be international interpreted across different copyright laws and to a degree different languages, which makes the job even harder.
But it also fair to point out that the basic permissions are fairly simple. Give the recipient source code of the whole work, put it under the same license, don't do something which a judge would deem as circumventing the authors intention of giving you those permissions.
The above simplified version of copyleft would likely work fine, although I suspect every lawyer on the globe would hate it.
Set theory doesn’t, but this isn’t pure set theory, it’s a social process (perhaps it’s game theory, though I don’t think you have to really use math to get the point ). The GPL came first, so it effectively forces others to submit or to go it alone.
Copyright is the entity that came first. A copyright license is the object you can use to claim you have permission to do something which copyright declares illegal by law.
We can put gpl first when trying to determine the intersection of all the set of permissions when dealing with multiple licenses, but in the end the fundamental question to be answered is: Do you have a set of permissions to do something which copyright makes illegal. Yes/No. In the case of multiple copyrighted work you need permission for all that which copyright limits in those cases.
If we want to look at it from a game theory perspective it we would ask who the agents are, their goals, the environment and the resources. Here a narrow intersection can be a cost, or it can be irrelevant depending on context. The biggest permission is always to write it yourself which make the limitation of copyright a non-issue for the author. Naturally that is not the only factor, nor the only agent, so it all depend.
> But there's nothing about share-alike terms that require that stricture. The Parity license that I mention in the blog post takes a different tack.
But they do. "or another license that allows everything this license does" sounds less restrictive at a glance, in that on the surface it permits additions to be separately licensed, but its effect is the same: no license with more stipulations is acceptable, and by symmetry any less restrictive share-alike license with similar wording cannot accept combination with this one.
Additions to code under your license may be published under weaker terms. But they cannot be weaker copyleft terms. I can think of a few edge cases involving use of independent portions of the new work under only the weaker license, but it doesn't achieve a likely goal of someone choosing a copyleft license: to eliminate confusion about whether it's permissible to merge downstream improvements.
Why not? What about, say, the API Copyleft License, which reads very much like Parity, but permits building closed applications? https://apicopyleft.com/
That license allows everything Parity does, plus one more: creating closed applications.
Taken on its own merits, I would indeed consider MPL 2.0 inadequate as a general-purpose copyleft license. Formally, you could argue that it's even weaker than the API Copyleft terms. As such, it's hard to recommend MPL for a project standing alone.
It understands, however, its position as a compromise which makes the underlying goal of its approach to copyleft untenable. Despite that, tries to preserve the ability to incorporate downstream changes through one degree of separation. The difference in expectations is palpable. The implied flow for publishing derivatives of MPL work is to distribute also under MPL, with the option of separately licensing non-Covered Software presented as a concession to tightly define the scope of the license. The implied flow for publishing derivatives of API Copyright Licensed work seems to involve carefully considering how much you can get away with under the listed exceptions, with the option to not share alike presented front and center.
The distinction is essentially irrelevant to anyone approaching licensing from a legalistic perspective, bet defaults matter for everyone else.
The use case for MPL and SSPL was broadly the same: selectively apply permissivity for the primary build-on use case (browser plugins, applications) to stoke adoption and copyleft to other use cases (forks, hosted offerings) as a bulwark against competitors (Microsoft, AWS). In drafting and presentation, I thought SSPL failed to communicate that heritage. So I wrote what became the API Copyleft License.
While this article's tone is somewhat angry and personal, it makes some quite interesting points and takes a perspective that I've never heard before.
Before reading the article I was tentatively in favor of more expansive copyleft licenses such as Mongo's SSPL, for various reasons. But I hadn't considered something implied by that position, which this article says directly: The FSF and what one might call "mainstream copyleft" are aggressively defending corporate interests by attacking such licenses. Perhaps they (the FSF et al) don't do it intentionally, but that's nevertheless their effect...
The FSF is not 'attacking' such licenses, they're just arguing that they aren't free libre software licenses. It's the SSPL people and others, by trying to co-opt the free and Libre software movement by claim their licenses are something they are not, which are mounting the assault. And let's be clear it is a pernicious, aggressive and deliberate attack threatening, and in some cases knowingly intended to fundamentally undermine free software principles. This is an existential threat to the FSF.
If they just went away and propagated and argued for their licenses on their own terms, the FSF wouldn't have anything in particular to say about it.
And the FSF has even come up with their own license for network services, namely the AGPL - that is a full free-software license, since compared to the GPL it only clarifies requirements around public performance of the covered work (which unlike mere "use" of the software, is something that copyright law expressly grants as an exclusive right of the copyright holder!)
Most people never get that far, because they write the license off as an attack on principles. The debate about the substance didn’t really get to happen.
As for public performance, I’m not aware of any case law to suggest that the public performance right applies to software as you suggest. And I’ve never seen FSF or independent legal counsel argue that GPLv3 and AGPLv3 are functionally equivalent due to background law.
The FSF theorists I’ve read describe AGPL as “synthesizing” a public performance right for software that doesn’t otherwise exist under current copyright law. They do so out of two existing exclusive rights: the right to prepare derivative works (making changes or building larger programs) and the right to reproduce in copies (incidental to use).
Well, I'm not aware of any case law to suggest that the right would not apply. Until the question is decided either way, it makes sense to assume that it would be applicable.
From where I sit it appears the FSF has come up with a particular definiton of "free" and opposes anyone using the term "free software" if their meaning of free differs from what the FSF desires. Maybe the term "FSF free" should be used when that is the intent rather than trying to corral the term "free software" itself.
The FSF came up with a particular definition of "free", the community broadly accepted it, the community and developers releasing software under that definition built up a particular public association with that term, and then a bunch of companies decided they wanted the all the goodwill of that term without paying attention to any of the fundamental rules the community had established years ago.
Literally this entire conflict could go away if critics of the FSF just used the term "Source Available". What would be wrong with that?
Why does our community need to be the one to give up our terms and muddy years of existing language, documentation, and cultural association? What exactly is the problem with just using the words "Source Available"? If someone develops a new license, why is it suddenly my responsibility to redefine the terminology I used for everything I've ever built?
Before now there was no conflict for the the term free software. When it accomplished the same goal for everyone many people just didn't care about a precise meaning. It was "free enough" for all views to fit in the same tent.
Large corporations are now stepping the unwritten meaning held by one portion who were previously satisfied with the overall outcome. Before, these people didn't care who owned the term as long as the goal was achieved. Now that the situation has changed these people want the phrase to mean what they always believed it meant. Even though you might not have been aware this difference even existed.
The meanings of words change with the progress of humanity. Nobody gets to hold on to a word like free just because they're comfortable with its current usage.
That argument assumes a conclusion I reject -- I disagree that the culturally understood definition of FOSS has already changed outside of specific set of businesses. And in the same way that nobody gets to hold onto a word indefinitely just because they dislike change, it is also true that nobody gets to redefine a word just because it helps their marketing.
The current evolution of language like "free" is a political movement pushed by political actors; it's not based on an observation of how culture has evolved, but on a belief about how culture should evolve -- specifically how culture should evolve to benefit specific business interests.
In other words, Mongo didn't wake up one morning and discover that FOSS had changed, Mongo made a decision to try and change FOSS.
Of course, businesses and critics have the right to argue about FOSS definitions, and traditional FOSS advocates have a right to tell them to buzz off and stop stealing the positive associations that exist in no small part because we were dogmatic about definitions.
My position is that there are scenarios where dogmatism about words is genuinely important, and that sometimes, changing definitions should be resisted. The muddying of FOSS is no different from the muddying of words like "organic" or "humane" as labels for food products. Without a strong governing organization like FSF to prevent the dilution of these terms, the terms will quickly become meaningless and useless for end-users and consumers. FOSS may not be a purely prescriptive term, but that doesn't mean that every database product on the market should be able to manipulate it whenever they feel like they aren't making enough money.
While I can't help you with your opinions and beliefs I do understand what you're saying. MongoDB may have done this purely to for marketing. They may also genuinely believe the change still leaves their code being free software. I don't know anyone there.
The change, if there is one, won't be because of you or me. It will happen over a few years time or it won't happen. It will be driven by what people accept and what they don't. A few extremely loud voices may turn the tide in either direction so maybe there's good reason for each side digging in their heels and making noises. Either way, each individual's idea of free software will exist under the names that evolve out of this skirmish. Both businesses and coders will adapt.
The "aggressive, deliberate, threatening attacks" I have seen in discussions like this almost always seem to come from the FSF crowd. (not necessarily official sources, but supporters in public discussion channels)
If the source available people weren’t trying to appropriate the term Free Software (with capitals) this argument wouldn’t exist. Free Software has a long standing, broadly accepted definition which many of these companies accepted and see to their advantage for many years. Now they want to change their licenses, but keep using the term.
They are trying to take other people’s stuff. They can’t just walk away with all the good Will and social capital Free Software has built up over the years because it’s beneficial to their shareholders. That’s the attack, it’s a smash and grab, and that’s why FOSS is fighting for its life in this.
I've thought this for years: the aggressive defense of super liberal OSS licenses with no sort of "SaaS clause" or other limits turns FOSS into free labor for SaaS companies.
SaaS is more closed than closed: you control nothing, not even your data, and can trivially be spied on and monetized in other questionable ways. The fact that some of the pieces of a SaaS site are open source is meaningless and changes nothing.
If all code must be free "as in beer" for all uses then this kind of SaaS (paid or "free" and paid for via surveillance capitalism) is literally the only possible business model. Well that and traditional 100% closed. The Googles and Facebooks of the world are fine with that.
Just as a side note, "free labor" is common and not necessarily a bad thing. Whenever you give someone a gift, whatever work you did on it is effectively free labor. You could also think of donations to charity that way when you fund them out of your salary, not to mention volunteering.
It's true that often people don't want to do that, though, and this is certainly understandable.
I'd add only that services not only can be more closed than software, it's normal and in some sense acceptable that they are. Whether it's freedom rhetoric or business advice, there's a strange disconnect between received wisdom for software and received wisdom for services.
2) why should companies be able to keep proprietary version from being distributed?
The second one I can see being possible by having employees agree not to exercise their GPL redistribution rights as a condition of employment. Still it seems like a large group of companies could all agree to that kind of thing to effectively take a GPLed work private.
The initial drafts of the GPLv3 did contain the Afferro provisions, but there was a lot of backlash over it during the public drafting process (some argued it wasn't enforceable, many argued that it overstepped their views on what the GPL should be, and so on). So it was split off into a separate license to hopefully increase the probability that people would switch to GPLv3.
Given all of the other FUD around GPLv3 from Linus et al, it seems like they wouldn't have lost much if they'd kept it in (or maybe they should've gone with the LGPL model, where the main license has the restrictions but they have a separate license which reduces the restrictions). But hey, hindsight is 20-20.
This is not entirely accurate. (Well, there's a possibility that the FSF had early private drafts of GPLv3 that adapted the terms of AGPLv1 in some sort of straightforward sense.) (Source: I was more or less at the center of these developments at the time.)
The early public drafts of GPLv3 had already rejected the idea of incorporating an Affero provision in a strong sense. Instead, they explicitly classified AGPLv1-like Affero conditions as GPLv3-compatible -- but note that no otherwise GPLv3-compatible licenses with Affero conditions existed at the time, and it wasn't especially likely that they would spring into existence. Note that inclusion of some sort of Affero-like provision was already a publicly controversial issue in the run-up to the release of the first public draft of GPLv3, which you can see in some of the news coverage from the period (late 2005).
There was resistance or objection to the sort of compromise around network services the early drafts took, but this basically took the following forms: (1) some individuals (who I would say were mainly associated with the Debian Project or the FSF staff itself) argued that GPLv3 should have directly adopted an Affero provision, though one without the perceived flaws in the AGPLv1 version, which were sort of carried over into the wording of the draft compatibility provision; and (2) some companies (representing financial services interests who had come to be dependent on Linux for data center operations) raised concerns about the compatibility clause leading to an Affero-specific license proliferation problem. Outside of those two viewpoints there wasn't much interest in the issue, once the public drafts of GPLv3 were released.
The eventual solution, responsive to those two points of criticism, was to get rid of the compatibility solution in favor of a single, separate, FSF-authorized, GPLv3-compatible Affero license, with the Affero provision worded in a way that avoided the perceived flaws of the AGPLv1 approach.
employees agree not to exercise their GPL redistribution rights
If you prepare a derivative of a GPL app as a work for hire, what GPL rights would you have? You don't own the copyright on the modifications, the employer does.
> You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.
> Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.
So based on my reading, your employer can convey the software to you without complying with the normal copyleft terms.
Your employer is an entity (a person, an LLC, or a corporation), you work for that entity. The entity is allowed to distribute it among themselves but the entity prevents itself from distributing to others (by following the license constraints). You, the employee, do not gain the right to the software because the employer did not give you, personally, any permission to the software.
Only once the software has been distributed by the employer to a third party do you, the employee, get rights to that GPL software. You can replace GPL with other licenses, the premise remains the same: an employee is part of the employer and not a separate entity.
Hmm GPL states any distributed modifications must be shared. So the employee does not violate any licenses by snagging a copy of the code that was distributed. I’m sure there may be other violations that may cause an involuntary termination event, but per the license the world now has the right (and the company is violating the GPL by not offering the code)
I will add if the company fixes their GPL violation then the employee is now violating the new license (since the GpL licensed code wasn’t valid in the first place). So it is best to not pirate any code even if you think it should be open (until the employer has confirmed in some way)
License is between two parties, world doesn't have any rights. I can see how two companies can use GPL to share the code they both use internally, and nobody else has the right to use it unless one of the companies "conveys" it to them.
If I loan you my laptop brimming with free software, and you use it for a day, have I redistributed the software to you? No. You had use of a computer you didn't own executing the software, no copy was made. It's no different from the well-known SaaS loophole the AGPL attempts to close.
I think the GPL grants rights of redistributing GPL-licensed software to "anyone with the software", not "anyone who makes a derivative work and owns it".
I don't know the actual reason, but these are my opinions. First, I seem to remember at the time the GPLv3 was being worked on there was some push to include the language from the AGPL. I believe (though I could be mistaken -- it was a long time ago) that the wording in AGPL was considered to be a bit ambiguous. There was some worry that the definitions of "convey" and/or "propogate" (I think) were not on solid footing. Eventually all that got sorted out and without looking at the original text of the AGPL I can't recall off hand, but I think they changed the text for AGPLv3.
I think there was also some concern that perhaps AGPL was not the way to go. As you no doubt know, the intent of the GPL is to allow people to run software for any purpose. You can even modify the software and keep it to yourself. The need to include source code only ticks in when you distribute the binary -- so that the recipient has the same abilities you do (minus the ability to change the license). There definitely was some discussion at the time whether or not the AGPL's further restriction impinged on Freedom 0. I admit that I mostly ignored this conversation, so hopefully someone else will give you a better answer.
For myself, I've mostly moved over to the AGPL, but I still find some of the wording to be not as good as I would like (I won't bore you with the details). I feel that the GPL is a more secure and conservative license that has been tested quite thoroughly in the court. It was a difficult choice for me to decide which one I wanted to go with since I agree with the aims of the AGPL license, but don't quite trust it as a legal document to the extent that I do the GPL. I presume others feel the same way I do.
> 2) why should companies be able to keep proprietary version from being distributed?
Possibly my reasoning will appeal to you because it is bereft of moral qualifiers ;-) A license is a license. In most cases licenses give the recipient more freedoms than they would enjoy without the license (otherwise they wouldn't need a license -- in some complicated licenses you give up something in consideration for something else, but I won't get into that). The question is how much freedom should you give the recipient of your program?
I value software freedom. The software world is vastly better in my opinion since the concept of software freedom came into existence. I want to promote this kind of software and hope that it dominates for most software that I will come into contact with. Because of this I write free software and think hard about how to make pure free software businesses work (currently writing a game of all things...)
The most important part of free software from my personal perspective is the idea that there is an even playing field. To be honest, I don't even like the idea that the upstream author can change the license on you if they control the copyright. As a user, I want some continuity. I don't want to have a split where suddenly my local contributions have less value because I have to compete against software that I can no longer contribute to. This is not a moral choice in my personal view. It's purely selfish. I choose to use free software particularly because it stops a lot of shenanigans from the upstream producer.
On the other hand, as an author I also have needs. I choose to write free software. My downstream users do not necessarily have the same point of view that I do. I am not going to change the license (and encourage multiple copyright holders in my projects specifically to make it difficult to change the license). I don't want to compete against a downstream that has more options than I do. It's purely pragmatic.
Now, the question you will undoubtedly ask is, if I'm OK with this restriction, why am I not OK with the restrictions in these SaaS licences. Surely I understand that they are trying avoid competition with a downstream that has no obligation to contribute and can supply the same service with a higher efficiency (and therefore lower cost).
In truth, have a considerable amount of sympathy, but there are really two key issues. First, I do not want to use software with those restrictions. It's not like I wish fire and death to them, but I'm decidedly blaze about their existence. I'd rather collaborate with groups that treat me how I want to be treated, rather than groups that are not as bad as the other guys.
From an author's perspective, I understand their plight, but I actually don't think SaaS is a good way to sell services. It's rent seeking. As much as I appreciate the idea of a near O(1) (per user) complexity for cost structure, I think it results in services that... don't have much service if you get my idea. It devolves into the Googles of the world and I'm not actually that keen on it. I think there are better business models waiting to be discovered (but I'm busy with my crazy free software gaming business model and there is only so much crazy that even I can keep track of, so don't ask me to do it).
But, if they want to do it, I'm not picketing their offices. Neither am I picketing Microsoft, Adobe, or even Oracle. I don't like it, but I'm not king of the world. If you ask me to cheer them on? No thanks. If you ask me to say, "Surely this is better than not having it?" No thanks. It definitely isn't for me.
> I actually don't think SaaS is a good way to sell services. It's rent seeking.
Big yikes. That is a really intriguing idea.
Rent-seeking to me means that the seeker has exclusive control over some asset that they did not themselves create, and uses that to extract rent from people who want access to it.
Amazon selling free software SaaS doesn't seem like rent-seeking, because Amazon don't have exclusive control over anything. They just offer better value than their competitors, for various reasons.
MongoDB selling SSPL'd SaaS doesn't seem like rent-seeking, because they invested in creating the software, and they aren't stopping anyone else from selling it as SaaS either, just requiring them to do so on a sort of level playing field.
Even Oracle selling proprietary SaaS doesn't seem like rent-seeking, because they invested in creating the software.
For me the best example of "rent seeking" is actual rent ;-) You build a building and you rent out rooms in it. It's the initial outlay of capital that you turn into a steady income stream without having to put any more work into it. This is in contrast with selling a service where you charge for your labour. My objection to rent seeking with regards to SaaS is similar to what happens with rental properties without regulation: there is a great incentive not to address problems since all labour past the initial capital cost is a cost centre, not a profit centre. Similar to some situations with rental properties, it is also relatively easy for vendors to lock in customers by not providing facilities to move their data somewhere else. As a user of services, I think SaaS is a poor way to offer a service. It's can clearly be a desirable situation for the vendor ;-) Probably that wasn't clear in my previous message.
With actual rent, most of what you're charging for is the location, not the building. That's why rents for flats in London or San Fransisco are astronomical, but those for much larger and nicer houses in Chelmsford or Fresno are a fraction as much. The rentier did nothing to create the value of the location, they just bought a slice of it.
It's not immediately clear that there is an analogue of location for SaaS.
Which is why ytur point about lock-in is interesting. It's not so much that lock-in is part of rent-seeking, so much as that lock-in creates the analogue of "location" needed for rent-seeking (maybe?). Once people are stuck in AWS, Amazon can charge higher prices for shittier services, because people have a reason to be there over and above value for money.
I recently developed a new vegan dish that addresses some of the practical problems with veganism as a whole by using bugs as a substitute protein source. Very promising, but these critics keep on attacking me, claiming I can't call my product vegan because "technically" it uses animal by-products.
And I think this shows why the vegan community organizers and primary advocates are actually anti-innovation. If the vegan movement wants to actually achieve its ideals, we need to reject the old guard that ideologically insists that no vegan dishes can contain meat.
Your dish isn't vegan though. It may be an improvement over eating meat, but it still creates suffering for living creatures. I don't know why you need so strongly to apply the "vegan" label to whatever your dish is, especially when it seems to involve literally eating "meat" from insects. Just call it "sustainable omnivorism" or something.
Now take the same reaction you just had, and apply it in the context of Kyle's post.
> When I wrote a strong copyleft license for dev tools, the FSF faithful objected. Why wouldn’t a movement best known for dev tools and software freedom want a copyleft license that requires devs using dev tools to make their work free?
Because it's not Free software. It may be an improvement over proprietary software, but it's still restricting user freedom. Just call it "Source Available" or something.
I don't know why, but this argument seems to be perennial when it comes to FOSS. It's not just from the copyleft side; the recent Commons Clause debacle read something like "to keep our software free, we're going to sell proprietary access to it a little bit".
I understand the central complaints that it's hard to keep the lights on writing FOSS, and that when FOSS isn't winning, ideological purity can marginalize it where compromises might do more good overall. But those discussions aren't helped by a baffled "why don't you just accept this?" framing. Disputes like the one between FSF and OSI are explicit about acknowledging and analyzing the tradeoffs between approaches. Nonspecific "FOSS isn't winning!" arguments instead rely on the dodge of "we need to do something and this is something", without stopping to justify what's being changed or why.
Why aren't SSPL, API Copyleft, Parity, CAL, and Icepick free software licenses?
GPL restricts my freedom to build and share closed applications with free libraries, in order to prevent the creation of closed software that restricts others' freedom.
AGPL restrict my freedom to build and share network applications as closed software with free code, in order to prevent the creation of closed software that restricts others' freedom.
Why can't a license restrict my freedom to build closed applications with free dev tools, in order to prevent the creation of closed software that likewise restrict others' freedom?
The licenses you mention are not Free Software licenses because restricting what people do with their software (and not just how they share it) violates rule 0.
> Why can't a license restrict my freedom to build closed applications with free dev tools, in order to prevent the creation of closed software that likewise restrict others' freedom?
It can.
If just won't be a FOSS license by the traditionally understood definition of FOSS. For better or worse, the Free Software definition guarantees more freedom around end-user usage than it does around how you distribute software.
And maybe you think that's an arbitrary distinction. That's fine. You can build anything you want. You could build your own "Software Equality" or "Extended Copyleft" movement, or whatever you wanted to call it. Maybe it'll be even better than FOSS. The only thing you can't do is confuse people by calling your licenses something that they're not.
Nobody is upset that SSPL, API Copyleft, Parity, CAL, and Icepick exist. They're all fairly interesting licenses. I'm glad that they exist. Just stop trying to co-opt a movement and blur lines that have been clearly understood for years.
> It just won't be a FOSS license by the traditionally understood definition of FOSS. For better or worse, the Free Software definition guarantees more freedom around end-user usage than it does around how you distribute software.
I appreciate your frank admission of the distinction, but I have yet to hear a good defense of it that both rests on something other than "that's the way we said it is" and doesn't trap GPL or AGPL.
The understanding you describe exists, but I can't agree that it's broadly shared or accepted. If there's a tradition, it belongs to a very narrow tribe. That tribe isn't growing particularly fast precisely because its tenets are so esoteric and don't stand up to typical hacker interrogation by those not thoroughly marinated in the political history. That's the "byzantine, insular ideology of copyleft" I mentioned in the blog post.
> The only thing you can't do is purposefully confuse people by calling your licenses something that they're not.
I can call it open, and I do. Folks may hear both your view and mine, but the result isn't confusion. It's a choice.
There is no proprietary right in the terms "free software" or "open source". And there is no good reason for those presently ill served to pretend those ill serving them enjoy such a right. When a better mousetrap comes along, the designer of the last model doesn't get to pull the words "mouse trap" out of the newcomer's mouth. As in software, so in licenses: lead, follow, get out of the way, or get run over. When I follow my people to a license problem, I try my best to lead with solutions.
> Nobody is upset that SSPL, API Copyleft, Parity, CAL, and Icepick exist.
I'm glad to hear you say so, but I've received lots of feedback from people who are upset. And not just because "license proliferation". Have a look at the OSI license-review archives ... though I don't generally recommend that.
> The licenses you mention are not Free Software licenses because restricting what people do with their software, and not just how they share it, violates rule 0.
Making changes and building applications are things that people do with software, ways that people use software, in common parlance. The only folks I know who want to split that hair aim to defend FSF's free software definition. That definition was largely a post hoc rationalization designed to alleviate the cognitive dissonance between the increasingly libertarian, permissive bent taking over open source ideology via OSI/ESR and the overt prescriptivism of GPL. OSI revels in permissionlessness and an idealized, rules-free environment. GPL is full of rules.
It was politically expedient to draw a line around GPL and say "no rules, except these rules, because we need these people as allies". Not rigorous. Not otherwise coherent.
> Just stop trying to co-opt a movement and blur lines that have been clearly understood for years.
That movement hasn't moved in some time. The initiative is out of initiative. There is no widespread understanding of the details we're discussing. We are both rarefied wonks.
The movement you seem to think I'm coopting was itself coopted. Open source "won" by giving software freedom to developers who don't pass along to end-users in turn. I don't apologize for writing copyleft licenses that eschew the compromises of the earlier forms. Especially in light of their performance to date.
> That definition was largely a post hoc rationalization designed to alleviate the cognitive dissonance between the increasingly libertarian, permissive bent taking over open source ideology via OSI/ESR and the overt prescriptivism of GPL.
This is... a view of that debate, and to be fair it's not necessarily unfounded. But let's assume it's 100% accurate.
Would you say that debate was a good thing for the FOSS movement as a whole, or was it a painful years-long argument that fractured the community and forced otherwise productive developers to waste hundreds of hours arguing with each other?
I don't understand the point-of-view of someone who looks at the GPL, says, "that exception was an arbitrary compromise" and then concludes, "let's add more arbitrary compromises."
> I don't apologize for writing copyleft licenses that eschew the compromises of the earlier forms.
I'm not asking you to. I just don't see why that has to involve attacking a tribe that is resistant to fundamental changes of this sort, and that is perfectly happy with its current growth and direction. I don't see what any of that has to do with your ability to build or promote new licenses, and I don't see why the narrow nature of the FOSS tribe means that suddenly we shouldn't be free to create our own terms that accurately and narrowly describe what we stand for. Say what you want, brand dilution is a real thing, and you are causing it.
And what possible benefit could there be to having this argument? Call your licenses Copyleft++, or Shared Source, or Liberty Licenses, or Social Good Licenses, or Share Alike. You say that you're not trying to co-opt a movement, but I don't understand what benefit you could ever gain from going to war with the existing FOSS community other than to seize on the existing expectations of users who feel like they already understand and can trust what FOSS software is and how it acts in the real world.
> When a better mousetrap comes along, the designer of the last model doesn't get to pull the words "mouse trap" out of the newcomer's mouth.
No, of course not. But if you build a bear trap and start advertising it as a mouse trap, I'm going to call you out on that. You can say the distinctions that we have are arbitrary, you can say that the community is small, you can say that we're dumb for holding on to them, you can say that most people want a new movement that's more receptive to their specific goals, you can say we're ineffective. Fine. But the distinctions still exist, and they allow us as a community to precisely describe ourselves, and we have used them for years, and you don't have the right to arbitrarily take them away.
If you think you can build a better movement, and you obviously think you can, then go build a better movement. I have no objection at all to different communities approaching user freedom from different angles and philosophies. I welcome that, the more the merrier. I would genuinely, sincerely love to see more alternatives to the FOSS movement spring up, because I admit that the FOSS movement can't address everyone's needs on its own.
It's especially fantastic to see lawyers getting involved, because there's a huge, real need for more variety of pre-built licenses that devs can safely adopt, and there are a very small number of people who are both advocating for user freedom and equipped to build those licenses. It's really, really good. Just stop saying that it's FOSS.
> I don't understand the point-of-view of someone who looks at the GPL, says, "that exception was an arbitrary compromise" and then concludes, "let's add more arbitrary compromises."
I don't think we should carve more ugly exceptions into a bad rule. I think we should have a better rule that better serves the underlying purpose. Specifically: license conditions that require developers using open source to build software to contribute their own work alike ought to be welcomed, no which kind of "use" as we slice and dice that term triggers the obligation. In FSF-speak: copyleft can regulate exercise of freedom 0 and freedom 1 as well as freedom 2 and freedom 3, to the same end, adaptable for both activist and pragmatic business use.
> I just don't see why that has to involve attacking a tribe that is resistant to fundamental changes of this sort, and that is perfectly happy with its current growth and direction.
Because that resistance to change creates and perpetuates restraints that prevent developers from addressing pressing, practical problems. Embedded library developers have recognized license choices at hand to keep their work free, or to dual license. Service library developers do not. Distributed-application developers have established license choices to keep their work free or to dual license. Developer toolmakers do not. And so on.
Intentionally or unintentionally, consciously or unconsciously, the old-guard posture picks winners and losers. No picking losers, then claiming to represent them.
> going to war with the existing FOSS community
I'm not at war. But there is no singular FOSS community to go to war with. And again, doctrinal specifics---like being able to rattle off the four freedoms from memory---aren't characteristic of any broad set. They're common knowledge only among a particular cohort of developers who came into open practice in particular ways at particular times. I suspect that includes both of us, but not nearly everyone. It took me way too long to internalize that.
For example, I published a noncommercial software license a while back and took great care not to present it as "open source". Many of its early adopters did anyway. When I reached out to them to warn of the feedback I thought they should expect, the answer was often "nobody I code with cares about any of that". I'd send them the Open Source Definition or links to fsf.org. No awe. Lots of good questions I couldn't answer.
That was my experience with the maximal-copyleft license and OSI, too. After a number of weeks, I had to report back that approval didn't seem likely, but that I didn't feel I could make a strong case why in any but political terms. The developers I thought I was serving by taking the debate for the team responded, almost unanimously: "We don't care. I know open source, and it's open source. Why are you wasting your time on that process in the first place?"
> But the distinctions still exist, and they allow us as a community to precisely describe ourselves, and we have used them for years, and you don't have the right to arbitrarily take them away.
Sure I do, but not arbitrarily.
I believed as you do, that FSF and OSI definitions represent rigorous, legal-flavored standards. Having actually dove into them now, the only precision to take away is false precision. Without linking you to a bunch of long blog posts: The OSD is a fork of DFSG, which OSI holds out as a technical standard, but Debian never did. When the text actually met many eyeballs under OSI, the org ended up making a bunch of hasty changes and commentaries to stem the tide of hackers reading it to exclude GPL. Twenty years later, I still saw comments on OSI's mailing list to the effect that the nondiscrimination criteria prohibit copyleft---more confounding than helpful. In the intervening time, OSI approved a number of controversial and just plain bad licenses. They approved stronger-than-GPL copyleft terms like OSL and RPL.
If the organizations' work in today's climate is to preserve a winners' history of open licensing circa 2000-2010, they should build that monument. Monuments don't move. Movements have to.
If "the movement" was just a tribe, you're right. It belongs to its time and place ... long past. But if "the movement" was really more than that, a set of goals beyond mere market penetration and a very niche kind of fame, the mantle belongs to those advancing those goals. Developers unhappy with where software freedom has run aground don't deserve to be marker for scorn or shorn of their "open source" identity. If that happens, they won't bend over backwards to honor open source as predecessor. They'll turn on it. New tribe.
All of the licenses this person defends have serious defects which are being ignored here. FSF saw and understood there were many weaknesses in gplv2 which is why they worked so hard on gplv3, which is the standard bearer for copy left in my opinion, including it's derivatives like a/l(gpl).
The main criticism that is valid is the "gunshy enforcement" by FSF, but if you listen to people like Eben Moglen they are very open about the fact that they have been working on the long game of getting into a position where enforcement would be effective instead of weaken the copyleft movement via a failed enforcement action, and that they have known it would take many years and even decades before the law side would catch up and be ready. I do think they need to step it up, but these are things that FSF et al already acknowledge and are working to address.
I have to admit a certain amount of conflicting views here, as I am at the same time sympathetic to entities afraid of doing work that others might then use and profit off of without contributing back (such as MangoDB claims), but I am also sensitive to claims that the licenses they are pursing could also be used as a cudgel to get more people towards paying them instead of using FOSS versions, and also to the fear of corps that SSPL could be a dangerous license if misconstrued. Which is why Mongo was dropped by RedHat, Fedora and Debian...
In general I think that (a/l)gplv3 did most of the work actually needed to solve these issues, and that attempts like SSPL, however laudable, are likely to fracture and weaken FOSS as a whole and, being incompatible with gpl, I cannot support them. There are ideas there that are important and should be discussed however.
I have put my actions where my mouth is on this issue. I have worked very hard to make the majority of my daily desktop and server stacks gpl or gpl compatible. (which means I steer far clear of mit/bsd licensed things if I can) The few exceptions are things I always keep an eye out for alternatives on.
I believe I mentioned enforcement only in closing. As far as licenses go, my criticism was sharper: FSF licenses as intended allow substantial bodies of activist work to benefit venture capital-backed, closed-software companies. Those intentional drafting decisions are incongruous with a post-hoc politics of VC scapegoating.
You mentioned Moglen's public writing on enforcement, and I think you summarize it fairly. But it is precisely that posture that I criticize as gunshy. The Principles of Community-Oriented GPL Enforcement lay it shorter and plainer.
The idea that the law isn't ready for GPL enforcement is laid bare by other organizations' success enforcing GPLs. This has some folks within the FSF camp worried: https://www.youtube.com/watch?v=P1mGG4JYurE They are losing the power to construct and enforce their own social truth about the licenses they published.
Well, I have to admit, you make some convincing points. I feel like I have a lot of reading to do. Are there any books or even blogs that really delve into the meat of the subject you can recommend? I think there is a lot of internal criticism in FSF that doesn't get leaked due to fear of it portraying a weakness, but that needs to be talked about regardless, and you are doing that. Thanks for a balanced response.
Unfortunately, there's no single tome directly on point of these debates that I'm aware of. Some of these debates are very old, but some are also basically current events. I'd also be suspicious of any one point of view, including my own.
I think I remember correctly that Bradley and Van were generally against SSPL, while Heather and I were for it. But you should ask them, rather than take my word for it!
> GPLv2 and v3 gave hobbyists, students, and anti-corporate hackers a means to feel as though their work resists the evil empire of the software industry, while in fact serving it up with unpaid work product. From the VC point of view, the GPLs break the dam on that pool of labor, flooding venture prospects with freebie technology.
That seems concerning and deeply cynical. Mostly because I worry that it may be accurate.
I think it's silly: the idea that free software is primarily done unpaid is just a myth, as can be seen from the attendees of any major free software conference, or the commit history of the major codebases. The killer feature of copyleft is as a way for standards to propagate within industries so that duplicate work can be avoided. Any benefits that end users get are a happy coincidence.
This is certainly true for the big headline projects. For every one of those, there's a hundred small but widely used libraries or tools whose sole maintainers (or tiny groups of maintainers) struggle under the workload of keeping it going, as they do so in addition to whatever pays their bills - with no obvious route to recompense for that unpaid labour. Worse, large users of the tool or library get to make modifications without sharing them with the original author and rest of the world.
the idea that free software is primarily done unpaid is just a myth, as can be seen from the attendees of any major free software conference
I'll point out that just because you mostly see delegates from big businesses to FOSS conferences, that doesn't mean this is a representative sample. It can just as well mean that the long tail of contributors isn't able to attend.
Of course, had the maintainers of the small-but-popular tool/library chosen a license under which the big corporate users were forced to contribute any local modifications back, this may in itself have prevented the popularity of the tool or library in the first place. Because for many developers and companies, using an AGPL (or even GPL or LGPL) licensed tool or library is absolute anathema.
(GPL in whatever form of course does not help with financially compensating independent developers, so it wouldn't fully solve the problem.)
> GPLv2 and v3 gave hobbyists, students, and anti-corporate hackers a means to feel as though their work resists the evil empire of the software industry, while in fact serving it up with unpaid work product.
I got linux and the GNU userland for free. I used it to learn and it got me a job.
Of course I contribute to GPL projects.
It's not unpaid work, it's paid in code.
It's funny that he chose mongodb as an example. They require a contributor to sign the CLA and give all ownership of the code to mongodb. This is effectively unpaid work, more than the GPL.
These new unfree licenses are the most restrictive the VC friendly lawyers can think of to maintain an usurped "open source" moniker while trying to push clients to buy commercial licenses.
Yes lot of corporations get free software for free. And that should be celebrated: free (as in freedom to tinker) software is getting everywhere. People can read it, adapt it to their needs and release it again.
Despite all the points the author tries to make, he forgets to mention the most important one: license proliferation is not a positive thing for people who care about software freedom. He's responsible for proliferating, and I hope it stops. Lack of innovation in licensing isn't the problem. Corporate greed is.
The licenses I’ve contributed to don’t rehash old licenses. They represent new choices. Some patch holes in old forms. Some break new ground.
If “license proliferation” means something even stricter, like “no new licenses, even if they do new things”, there’s no good argument for it as a policy, other than protecting those currently “winning” who fear change. Database proliferation is not killing software. Nor is framework proliferation or markup language proliferation or programming language proliferation.
Just my opinion, but the author sounds like a corporate shill (I realize he is a VC): “ The old, creaky pillars of the free software movement need convenient scapegoats, because the facts on the ground raise serious doubt about the effectiveness of their leadership and the byzantine, insular ideology of copyleft they impose.”
The state of software development and benefits to society from FSF licenses are, I believe, manifest.
I also support other open source licenses, I am not criticizing them, I am merely defending FSF licenses.
I guess that my personal bullshit meter gets tripped up when something is an attack rather than a balanced discussion.
The header said “Venture Capital Shill”, so I thought I was using a term he self identified with. Maybe I was wrong about that and it is just the title of the article.
You literally quoted part of the section that describes that the author considers that label an unfair attack made to allow people to ignore his arguments. And then used said label to attack him and ignore his arguments.
The article is worth reading more carefully, even if you don't agree with him.
I read the article as carefully as I could given its style and I think the author is injecting the negative sentiment by self abasement to give himself license to anger, etc.
The GPL was written by an institutional employee that was upset by VC backed plans to co-opt internal software and turn it into a profit vehicle. In that context the compatibility of everyone's interests but VC interests make perfect sense.
The claim that copy left is failing and byzantine are haberdash. That many people don't understand GPL and that it is succeeding in its direction and not the one they assumed is an argument that could be made and should at a minimum be significant to VCs.
So if I want to write an OSS library that can't be used for monetary gain, what license do I release it under? AGPLv3?
EDIT: Actually, I misspoke, since monetary gain isn't the problem. I should have said "used against user freedom", but that's much less well-defined. I want a license that is as "open" as possible, for whatever definition of "open".
The current version of Prosperity uses Creative Commons' approach to prohibiting commercial use. Polyform uses a new, and in my opinion, much improved approach with practical "safe harbors" of clarity for predominantly noncommercial organizations, as well as common personal uses. Prosperity also includes a built-in free trial period for commercial users, while Creative Commons does not.
The forthcoming version 3 of Prosperity will be written as a fork of Polyform Noncommercial, leveraging its improved approach, still with a built-in free trial. If you're interested in those terms, I'd greatly appreciate feedback: https://github.com/licensezero/prosperity-public-license/blo...
If something in the terms isn't clear, that's the terms' fault, not yours. I'd appreciate an issue or an e-mail, so we can make it clear.
(IANAL, but) Yes, you'd use the AGPL because it basically maximizes user freedom. It doesn't stop people from running services for a living with the licensed code _and_ it protects the original authors and service users from exploitation.
It's just the GPL with an extra clause and that's a good thing.
I'd say as strongly copy left as possible, although that will inevitably bring with it some restrictions for users. Parity ( https://paritylicense.com/ ) is my favourite at the moment (created by the blog posts author).
It's interesting in that it doesn't try to prescribe the license downstream projects use as long as it's free (in contrast to for example GPL) but is, at the same time, very strict in regards to when it applies (basically every time Parity-licensed code 'touches' non-free software), which means there is no Saas loophole for example.
That's an interesting license, thanks! I would have liked some examples about what exactly it does, because reading the text doesn't make all the ramifications clear, but it looks promising.
If some of the text is unclear, you can submit an issue on the license' GitHub repository. Kyle (the creator of the license) considers this an issue with the license, and is very open to improve the text to eliminate any such issues readers have.
I will, thanks. It's not unclear in a legal way, just in a human "what can my users/forkers/etc do with this license" way (which may still be a valid issue to open).
Isn't Parity License a source-available share-alike freeware license? It seems very different from GPL and even the ideas by which copyleft was originated.
Would you care to elaborate? To me, it seems very much in the 'spirit' of what GPL set out to do back when, updated to eliminate issues that weren't/couldn't have been forseen. Parity is not perfect (yet), but to me it's the most viable attempt at a modern copyleft license to date.
Technically, one can argue Parity is not 'open source', if one acknowledges that only OSI approved licenses should be called 'open source'. I don't, and quite a few other folk don't either. Lots of people do, though.
To me it seems very unclear what this license means in practical terms. It mentions that contributions are needed unless it's prototype but definitions on what it means isn't there. Can you operate gmail-type of service, call it beta and not release the code for many years because it's "used for for non-production user testing"?
Not to nitpick but OP mentioned "OSS" not "FOSS." Open does not mean free. You can allow others to access to your IP without the freedom to use it however they want, since nothing is black and white.
You can't. It wouldn't be OSS if I couln't take your library and resell it. You could look at CC-BY-NC-SA, but it's not Open Source and not appropriate for software.
I think it's mostly because of the kind of legalese used in the license text, as they are designed for art.
From their FAQ:
> Can I apply a Creative Commons license to software?
> We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available. (...)
> Unlike software-specific licenses, CC licenses do not contain specific terms about the distribution of source code, which is often important to ensuring the free reuse and modifiability of software. (...)
> their work resists the evil empire of the software industry
Not sure that the creators of BSD really cared about the things this article is talking about when created BSD license. Many of the opensource projects that I use are either created or maintained by the "evil empire of the software industry".
The author makes interesting points well illustrated by the abuses, by multinational corporations and internet fatcats, of the licenses we depend upon.
But he neglects to mention the fundamental point that the community is not well served by a proliferation of licenses.
So, what is the alternative? What am i supposed to do if I think there is no license that deals satisfactory with the problems I have, and I'm can't create a new one, because, well, it makes things a bit less straightforward for my users?
To me, it's not really proliferation if the license addresses issues no other license addresses. Just because it adds one or more licenses to the number of existing licenses, doesn't mean those licenses should not exist.
Also, as a developer I think choice is good. If users have to do a bit more work to figure out whether they can or want to use code because of its license then that is unfortunate, but not too much to ask.
Why exactly do you think writing such a new license is doing more harm than good?
I guess that's where we disagree. I think the existence of such a license might be -- in some cases -- the one thing that motivates the author to create a project in the first place (its for me, anyway). And I don't think open-source has any obligation to come with 'no cost' for its users.
Reading (and respecting) its license is the least one can do when using somebody elses code. If that takes time, then one just has to factor that in when deciding whether to re-use someone elses code or not.
https://guide.licensezero.com/
> The Prosperity Public License (Prosperity) works a bit like a Creative Commons NonCommercial license, but for software. Prosperity gives everyone broad permission to use your software, but limits commercial use to a short trial period of 32 days. When a commercial user’s trial runs out, they need to buy a private license or stop using your software.
> The Parity Public License (Parity) works a bit like AGPL, but requires users to release more of their own code, in more situations. Parity requires users who change, build on, or use your work to create software to release that software as open source, too. If users can’t or won’t release their work, they need to buy a private license that allows use without sharing back.
I'm one of those folks that usually defaults to AGPL for their open source work for practical reasons - it's much easier to go from a copyleft license to a permissive one due to circumstance than the other way around. However, I always found it a bit strange that there were dozens of variants of the MIT and BSD license out there, but aside from the GPL and MPL no other popular license really took up the mantle of copyleft, aside from perhaps the old Sleepycat license.
This looks like a very appealing license on its face, but the fact that it's specifically _not_ written in legalese is a little weird, though the fact that the author is a lawyer is some reassurance.