recent sweeping layoffs at Mozilla have left several people on my Twitter timeline proclaiming that FOSS is dead. so i wrote a blog post about what happened and what can happen next, with specific reference to License Zero as a project to keep an eye on. figured it might be of interest to the community here, and i’d certainly love to see what y’all think about it.
Thanks for mentioning! I’ve added to my reading list.
So I took a quick read through. I’ll want to read again.
My first reaction is that it’s wonderful to see another person take a second look at free and open source history and practice. Especially when they take the time to write it up and share with the world! We need more people not just consuming approved narratives of free and open, but remixing, rewriting, and even outright rejecting them, too. The facts are the facts. But the ways we see and share those facts ought to be read-write.
My second reaction is that @kat, as ever, shows a wicked eye for the incendiary turn of phrase. “FOSS is dead.” is quite the word bomb. Lots of software people see FOSS as an unalloyed good. Calling it dead will definitely get hackles up. I like the idea that at least some free thinking may follow.
That said, FOSS means so many different things to so many different people that I’m not sure “FOSS is dead” can have much meaning beyond the symbolic, political, and rhetorical.
There are smaller, more modest meanings of “FOSS” to retreat to. I don’t think we’re going to stop seeing software under MIT, BSD, and Apache 2 via GitHub, npm, and crates.io, &c. And I doubt we’ll see the end of foundation-sponsored projects, the Linux kernel process.
Personally, I hope the idea of FOSS as the ideal for all software, and as an inherently noble or charitable act of unqualified Good, is dying. We need to use our words to establish better accountability about the ways our work affects others, both in terms of relationships among programmers, in work and play, and in terms of how our work affects the world as a whole. We need to address financial and ethical problems, not assume that some FOSS orthodoxy or another solves them for us.
the free software people are also yelling at you, because you didn’t do it their way with their license, you did it a different way with a different license, and that goes against amazon’s freedom to screw you over.
was drawn from a blog post about Redis and the Commons Clause. the author’s entire argument was “this is not open source” as though that is in and of itself sufficient to explain why it is bad. and that kind of axiomatic thinking that doesn’t even stop to wonder if it should justify itself is unhealthy for the software discourse in general.
there will certainly always be an FSF and an OSI, and their licenses of choice will always get some use. just like there will always be a Firefox. but the promise, the hope, arguably the myth carried by those entities has turned out to be unfounded. and so they linger on, but their role as symbols of a movement beyond themselves, i think, has died.
@boringcactus enjoyed reading this again. Thanks again for sharing.
I should let you know that License Zero as a brand and a specific manifestation of the project is on its way out. My latest note here on the successor is here: Summary of Planned Changes (L0 -> stricteq) Would love to read your thoughts.
I’m behind on the project, though it’s probably 85% there for initial launch. Mostly because I’ve had to give projects helping some homeless folks here in Oakland priority.
i definitely think the current branding is entirely maintainer-targeted, and to fulfill its current vision that needs to be broader in scope. i think there’s potential to combine the L0 “pay for the ability to use this under a permissive license” approach with the Tidelift “one centralized subscription for enterprises” approach, and at least in theory you might be able to just join forces overtly.
it doesn’t seem like stricteq, at least as planned, addresses the issue that a lack of an overt political agenda creates what Os Keyes refers to as an “implicit neoliberalism”, but that might be out of scope for the goals you have for the project.
definitely exciting to see what’s coming up next. and yeah, doing actual work out in the real world takes priority sometimes, i feel that.
You mentioned an overt political agenda, or the lack of one, in plans for StrictEQ. I don’t yet have a good scaffold of words for that conversation that I’m comfortable standing on. But I’d like to say something, and I’ll try to keep it short.
I want StrictEQ to stand proud for the idea that we should pay to support the colleagues we rely on to get paid, be happy to do it, and acknowledge that all involved are better off that way, overall. But beyond that somewhat insular matter of fairness within the guild of programming, I don’t see StrictEQ as a project focusing on stopping nefarious use cases or encouraging virtuous ones in a broader sense.
I’d like to produce a system and approach that’s compatible with acting for those ends, but StrictEQ as I see it now won’t exist to pave those paths. I’ve outlined what I think that job could look like, and it doesn’t look at all like one person (or lawyer) putting terms on a pedestal. But so far, I haven’t seen any groups acknowledging how the work is hard. I noted at least a whiff of the same skepticism off your post.
It’s tempting to draw a distinction between business morals, or “equity” within the software industry, and end-use morals, or “ethics” in how software affects society more broadly. But I think the crux of “equity” is no more than an application of broader “ethics” to the special case of our programming peers. Hence “StrictEQ”. I want to evoke the “I am he as you are me and we are all together”-ness of it. In a word, “peership”.
My issue is that I feel like the “let’s pay for hammers when we do jobs” message of encouraging peers to support, there isn’t a clear way to charge companies.
I understand the difficulties of spinning up enterprise sales — a function that Tidelift does.
But I feel like directly calling out companies as well would be useful. How do we equip a champion within the company with the materials to get payments made?
I also am still digesting this post.
Mostly I agree with it, and certainly thank you and endorse it for pulling a bunch of threads together in one place.
And for sharing it here and participating @boringcactus!
Outside License Zero as Kyle’s project, I also see a larger movement of looking to licensing as tool.
Profit vs Sustainability is the theme that I see being pivotal. On one side is business models and various corporate structures. On the other side is “I need this project to buy my time so I can maintain it / make it better”. More of course, but starting with single maintainer is likely the right base.
Things like co-ops blur the line between the two, but I think are an interesting direction.
I’m focusing on this area rather than ideological discussions…because I think sustainability has to SUPPORT ideology.
At the risk of rehashing earlier conversations: I don’t worry about whose credit card gets charged, the company’s or the worker’s. That’s for the company and the worker to figure out.
The developer shouldn’t have to step into that ring, as referee or as a fighter. And it’s not on them to comp a customer pending some all-encompassing settlement of expense accounts on their end. The developer’s job is to make good software and get paid.
Consider the American diner. You don’t get to eat, walk out on your tab, or postpone payment indefinitely because you and your buddies can’t figure out how to split the cost. Neither is it the cook’s job to provide a calculator, split large bills, accept exotic currencies, keep track of who owes who from last time, or mediate. It’s their job to cook, serve, and get paid.
Just because individuals might make the payment, and show up on the roster as avatars rather than corporate logos, doesn’t mean we can’t hold companies accountable. We see this work play out all the time. Some of us appreciate companies who publicly hire open developers, theorists, and other Good Folks.
That said, it’s definitely on my list to consider allowing stricteq users to add companies to their projects’ rosters. That way if they do a side deal for a company as a whole, they can reflect that on their project page, and we can continue to use that page as a source of truth about who has a license.
I have and will continue to publish forms, guides, and other resources for doing those kinds of deals. But I’m not interested in trying to “automate” or “standardize” or provide full-service agency services for those kinds of sales. As a rule, companies have procurement processes to make it harder to get their money. Once contracts are signed, they use contract-management tools to streamline the cost of carrying them. But until they’re signed, it’s all gates and speed bumps. Those transaction costs are a big part of why “slap Apache 2.0 on it” is worth so much in the B2B industry.
This doesn’t make it any clearer to me: I don’t really understand the diner point you’re trying to make.
I don’t think maintainers should just be cooks who get paid hours? I thought we were trying to move beyond just hours? Which Tidelift does I think? Sell future hours?
(maybe my mention of hours above muddled this)
My hypothesis is that making a movement to get companies to buy licenses results in more peers. I also don’t care the flow by which payment is made.
I’m trying to “yes and” this — engage peership, AND get companies to have an expectation of owning a license / paying maintainers beyond hours.
Thanks, @boris. I think I understand you better now.
My diner analogy wasn’t about paying devs hourly or by piecework. It was only to hammer on the point that the developer selling the license does not and should not care who picks up the tab. If a license costs $50, the developer gets $50, not later, but now. It might be a charge on the worker’s credit card, on the company’s credit card, on the worker’s godmother’s credit card, or on a half-spent prepaid card they found on the street. $50 is $50.
The company-culture issue is a real one, and a real opportunity. I do care about institutional norms, in addition to individual and professional ones, especially in reaching coders who really just do their jobs, and don’t engage on community issues. And I think we also agree the in addition to is critical. Both-and, not either-or.
Admittedly, I’m acting out some reflexes here that I’ve had to develop elsewhere. I kick every time I read “companies should pay”, and I’m sure it’s no mystery why. When “companies should pay” comes up online, it’s usually an all-too-convenient dodge by employees. Workers get together online, without the bosses around, and agree amongst themselves that someone else should do the paying. That means companies. They have to acknowledge that getting companies to pay, and changing institutional norms more broadly, is far harder than holding individuals to account. But of course workers say that if there’s going to be a hassle, outside developers, or the companies trying to help them, should be the ones to deal with it. Workers say workers should be bothered, at most, to put in good words to their procurement departments, as “internal champions”.
Basically: Nobody wants to pay, and nobody wants to deal with bureaucracy. But that’s short-sighted, self-limiting, and dumb. In many, many cases, people should want to pay. It’s in their best interest to pay. And it’s in their best interest to reduce bureaucracy and friction, not reinforce it. Players across the economy continue to make staggering investments in reducing online payment friction. For stricteq, we’re literally talking less than a minute to pull out a card, pay, and move on.
Companies want workers and suppliers to bear all costs and hassles. Workers want it all on other companies and suppliers. Suppliers want it all on customers. I want those who benefit—companies and workers—to bear the cost, plus any costs of allocating it, as with basically any other day-to-day transaction. And I want the hassle reduced to the absolute minimum, system-wide. Attack transaction costs, or route around them.
Personally, I tend to think effective institutional change on this begins with individual and professional change. I see enlightened self-interest bubbling up from the bottom, rather than flowing down from the top. Especially in institutions that aren’t software companies led by software people. But that’s just my bias.
Perhaps stricteq should allow users to add an optional affiliation to their profile, and then display that affiliation on project pages? Perhaps project pages should group customers by affiliation, and show them together?
oh the Ethical Subcommons post is the sort of thing i wish i had found earlier so i could link it as an example of an implementation of the normative approach, that’s exactly the sort of thing i was thinking of writing next. i think one approach for ensuring StrictEQ can at least enable a normative approach would be to give maintainers intrinsic veto power over the customers who buy licenses from them, like what @kat et al have done with the entropic client license.
a benefit of the tidelift approach is that it’s one subscription on the corporate end, as opposed to the L0-as-it-currently-exists model of one transaction per dependency selling a license. as someone who’s only spent two months of my life in the corporate world, i wouldn’t know for sure, but my intuition is that one all-inclusive subscription is easier to sell corporate accountants on than a new transaction every time a new dependency is considered.
i think the branding issue is that currently, L0 is all about “why as a maintainer should i use one of these licenses” and doesn’t address “as a user, why should i use a Pros/Parity licensed library and (ask my company’s accountants to) pay for a subscription” at all, whereas tidelift has completely disjoint marketing pitches for end users and for maintainers.
I could not agree more.
One of the major goals of stricteq, branding wise, is to present one, unified, consistent story. Of course, that can’t be limited to messaging. One of the major design decisions has been to implement just one kind of account or identity. Everyone with an account is equally able to buy, sell, and be recognized for both.
I haven’t settled on a slogan yet. But the closest I have is something like “the software you depend on depends on you” or “the developers you depend on depend on you”. A key point is that the model itself is a good idea. Those using it to fund their own work must implicitly welcome the chance to fund those they depend on likewise.
None of this is meant as a diss or criticism of Tidelift or other “enterprise adapter pattern” approaches. I’m good friends with Luis Villa, cofounder and legal eagle there, and I strongly support earnest experiments of all kinds in the area. I choose not to put my own energy into enterprise-flavored approaches. But maybe half my day-to-day law practice is helping companies sell that way.
yeah Luis’s work is interesting as well, and i think a likely path forward combines both of your approaches, with a default license being some non-commercial strong copyleft license combining the restrictions of Parity and Prosperity and then making it straightforward for corporations to buy exceptions.
sloganeering remains the hardest part of everything; “support your dependencies, depend on your supporters” or “dependency is a two-way street” or “always give something back” might be paths to explore there as well. maybe even “re-flattening the open source ecosystem”.
Luis dropped a nod to the idea of combining Tidelift with a license-based model in one of their early whitepapers. We joked about offering some kind of prize for whoever signs up for the most sustainability-as-a-services at once. I laughed. Not sure if Luis did.
“smooshing the software industry”
oh god the “we must be backwards compatible all the way to the Stone Age and so all the good names are already taken” stuff is just exhausting.
but yeah, finding some catchy way to express a re-leveling of the playing field is probably the big step towards more broadly useful branding.
A post was split to a new topic: FAFO License v0.2