Scapegoating free software’s failures
writing.kemitchell.com
writing.kemitchell.com
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.
There may be more copyleft licenses than you think. Blue Oak Council, in which I'm also involved, recently published this resource: https://blueoakcouncil.org/copyleft#copyleft-families
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
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.
1: e.g. https://www.mozilla.org/en-US/MPL/2.0/FAQ/#mpl-and-lgpl
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.
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.
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.
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.
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 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.
I’m familiar with several who do not!
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.
Hosting a GPL-licensed server and receiving network activity does not constitute distribution, which is why the AGPL exists.
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...
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.
Nice turn of phrase.
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.
Approximately all then open source software I work with on a daily basis is SaaS companies pooling efforts on the problems they have in common, yes.
It's true that often people don't want to do that, though, and this is certainly understandable.
Spot on, and those companies managed to subvert and violate the spirit of FLOSS in many ways.
1) why wasn't AGPL used for GPLv3?
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.
But yeah why have AGPL as a separate thing?
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.
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.
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.
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)
> 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.
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.
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.
What am i missing?
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.
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.
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.
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.
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).
Van Lindberg has done a lot of work on public performance recently. You might like to read his blog.
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.
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?
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.
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.
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.
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.
> 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.
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?
> 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.
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.
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.
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.
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.
An interesting SO on the SSPL: https://opensource.stackexchange.com/questions/7522/sspl-and...
In essence, I mark it as a sign of honest discussion when someone admits the weaknesses to their arguments. There is none of that here, ergo...
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.
As for blogs, I'd strongly recommend all the folks mentioned in the post, all of whom I link from my blogroll (https://writing.kemitchell.com/blogroll.html).
Bradley Kuhn: http://www.ebb.org/bkuhn/blog/, but see also https://copyleft.org, to which he's contributed extensively
Heather Meeker: https://heathermeeker.com/
Van Lindbergh: https://processmechanics.com/
My own: https://writing.kemitchell.com
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!
For a more general reading list, see this one from Blue Oak Council: https://blueoakcouncil.org/lawyer-reading-list
[1]: https://karlitschek.de/2019/08/open-source-if-more-than-lice...
That seems concerning and deeply cynical. Mostly because I worry that it may be accurate.
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.)
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.
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.
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.
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.
[citation needed]
Your comment seems more to prove his point than refute it.
The article is worth reading more carefully, even if you don't agree with him.
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.
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 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.
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. (...)
https://creativecommons.org/faq/#can-i-apply-a-creative-comm...
Free software passes on the freedom to the USER of the software, preserving access to the source code, the ability to change it, etc.
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.
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.
It's just the GPL with an extra clause and that's a good thing.
For a company, this directly leads to increased profit.
This is one of the reasons why FLOSS licenses cannot go further than AGPL in limiting scope and use.
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".
But he neglects to mention the fundamental point that the community is not well served by a proliferation of licenses.
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?
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.