Occupation or a Gift?

Dear young comrades,

Today we saw a short announcement on BilişimSen's account. Its subject was a new venture: OccupySaaS. The slogan is striking: "They laid us off. We're rebuilding their SaaS." It takes its name from Occupy Wall Street, and the language of "the 99%" from the same place. It says that laid-off programmers are writing open-source alternatives, compatible one for one with their former bosses' products (Auth0, Salesforce).

At first glance it is a story that warms you. It warmed us too. Then we asked the three questions we always ask: In whose hands? Under whose control? To whose benefit? The answers were not so cheering.

This piece was not written to impute bad faith to OccupySaaS. The people writing the code may well be workers who were genuinely laid off, trying to turn their anger into production. The piece is about something else: to explain why it is a problem when BilişimSen announces, as "one of us", a venture that has no organisation behind it, does not defend the idea of the commons, and is published under a licence open to capture by capital. And to show why ventures of this kind so often fade, and why the commons matter so much.

---

First, the Summary

1. What is OccupySaaS? An anonymous venture founded in October 2026. It has two early-stage projects: ZeroAuthy (in place of Auth0) and SalesCompel (in place of Salesforce). The code is under the Apache-2.0 licence. It is being written by artificial-intelligence agents, by a "clean room" method, from public API documentation. On GitHub it has 78 stars and 8 forks in all.
2. Who is doing it? Nobody knows. The site has no name, no board, no constitution and no decision-making process. Donations go to a personal "Buy Me a Coffee" page.
3. Why does the licence matter? Apache-2.0 allows the code to be taken, closed, and sold as a rented service. Code written today "against the giants" can sit on those same giants' shelves tomorrow. A licence that protects the commons (AGPL, for example) was not chosen.
4. Why does organisation matter? Open-source projects with no collective structure behind them either fade from volunteer exhaustion or get swallowed by a company. Elastic, Redis, Terraform, xz-utils and OpenSSL are recent examples.
5. What is BilişimSen's mistake? A union announcement gives the announced thing the approval of the class. To give that approval, without asking, to an unorganised, anonymous venture open to capital is to tell the worker that "liberation comes from writing code one by one".
6. Why does the commons matter? A commons is not whatever happens to be open. It is what is owned in common, governed in common and protected in common. Openness is only a door. The commons names the door, the house, and who has a say inside the house, together.
7. What should be done? Ventures of this kind should be met without being belittled, but with criteria: licence, governance, transparency, and a bond with an organisation.

---

What Does OccupySaaS Promise?

Let us give it its due first. The OccupySaaS site is orderly. Its claims are not empty.

• It objects to per-seat pricing. "Infrastructure shouldn't charge rent by the head." That is a sentence that sees correctly the rentier character of the SaaS economy.
• It attacks lock-in. It aims for existing code to keep working unchanged. The real obstacle to a customer leaving Auth0 is not the software. It is the cost of switching. The project takes aim at that obstacle.
• It ties itself to the layoffs. It claims to show that laid-off engineers "can still ship a product".
• It is legally cautious. Leaked code, decompilation, and the former employer's confidential information are forbidden. Every repository has a CLEAN_ROOM.md.

These things are valuable. A small piece of evidence for what we said when we wrote on the future of software engineering is standing here too. The productive forces are no longer as dependent as they once were on a profit-seeking company organisation. A small number of people can rebuild the core of a large product.

But the value of a venture is measured not by its promise, but by the relations of ownership and of governance. That is where we look.

---

Three Questions, Three Answers

In whose hands?

We do not know. There is not a single name on the site. Beyond "Est. October 2026" and a licence file, there is no institutional trace. No constitution, no membership, no elected representative, no minute book. Not even a public member of the GitHub organisation is visible.

Anonymity is not a crime by itself. In countries under repression we too know the value of writing anonymously. But if there is a claim to be a movement, there is also the question of whom the movement answers to. If there is no collective to answer to, what exists is not a movement. It is the project of one person, or of a few. The future of that project depends on those people's goodwill, on how long they stay unemployed, and on whether they find a new job.

Under whose control?

It is not written who decides what code gets merged, what the roadmap is, or where a donation is spent. Donations do not go to a common fund or a cooperative. They go to a personal donation page. Control sits not with the people who contribute, but with the people who have write access to the repository.

In the open-source world this is called the "benevolent dictator" model, and for a long time it was treated as normal. We do not treat it as normal. When the contribution is common and the decision is singular, common labour can in the end be moved somewhere else by a singular decision.

To whose benefit?

Here the licence comes in. It deserves a heading of its own.

---

A Licence Is Not a Technical Detail. It Is a Contract of Ownership

Young comrades, licences look dull. But who a piece of software belongs to is written not in the code, but in the licence.

OccupySaaS has chosen Apache-2.0. This is a "permissive" licence. Roughly, it says: "Take the code, change it, close it, sell it. Just mention our name at the start." It puts no obstacle in the way of turning the code into a closed product, or of selling it in the cloud as a rented service.

Opposite it stand the "copyleft" licences. The GPL, and especially the AGPL, says this: "Take the code, change it, sell it. But you must share the code you changed with the same freedom. Even if you offer it as a service over the network." Copyleft is an anti-enclosure fence, invented by Richard Stallman in the 1980s by turning copyright law back on itself. It protects the commons against whoever wants to fence the commons in.

Now look at OccupySaaS's own aim. Laid-off engineers are writing an identity server to take Auth0's place. Tomorrow, the following can be done with this code published under Apache-2.0:

• A cloud giant can market "managed ZeroAuthy" and price it per seat.
• A startup can fork the code and ship a closed "enterprise edition".
• Okta itself can, if it wishes, fold it into its own product.

Code written "against the giants" is, in law, a gift written for the giants. The question in the title comes from here: occupation, or a gift? Occupation is taking back what was seized. Labour published under Apache-2.0 belongs to whoever wants to take it. The one most ready to take it is capital.

A permissive open-source licence legitimises the taking of labour without permission.

One thing more. A large part of the code is being written by artificial-intelligence agents. In many legal orders (the US Copyright Office's 2025 report points the same way) the copyright protection of output produced without human contribution is uncertain, or absent. The force of a licence built on a work whose copyright is uncertain is itself uncertain. Copyleft itself rests on copyright. This is a new problem that makes it harder still to protect the commons in law. To say "we are writing fast with AI", without thinking it through, is to postpone the question of ownership.

---

Openness Is Not a Commons

Let us repeat here the heading we set while reading Cengizhan Kaptan's piece: A common product is not common without common ownership.

Open source and the commons are often taken to be the same thing. They are not.

Merely open	A commons
The code sits where anyone can see it	The code is the common property of the community that uses and develops it
The licence permits taking, and does not require giving back	The licence requires giving back (copyleft)
The decision sits with whoever has write access to the repository	The decision sits, by written rules, with contributors and users
The money goes to a personal donation, or to an investor	The money goes to a transparent common fund, or to a cooperative
Sustainability depends on a volunteer's energy	Sustainability depends on the organisation's capacity to reproduce itself
Success is measured by the star count	Success is measured by whose life has changed
It ends when a company buys it	It cannot be bought, because there is no single owner to sell it
It has no bond with an organisation, and says it is "apolitical"	It is part of an organisation, or of a class movement

In the work for which she received the Nobel in 2009, Elinor Ostrom showed that the commons are not condemned to "tragedy". But on one condition: when a community with definite boundaries governs the commons by rules it has set itself, and by its own mechanisms of control. If there is no rule, no control and no community, there is no commons. There is a plot whose owner has not yet arrived.

The enclosure movement Marx describes in the chapters on primitive accumulation was exactly this. The English peasant's common pastures were counted as land "that belonged to no one", and fenced. What belongs to no one ends up belonging to the strongest. What is happening in software today is the digital version of that. We discussed it in detail before, in the distillation debate and in the Hugging Face case: everyone's labour is taken because it is "open", and the monopoly's output is protected because it is "property".

---

How Do Ventures Like This Fade? Five Lessons from Recent History

The fate of unorganised openness is not an abstract prediction. The open-source history of the last ten years is full of examples.

First lesson: exhaustion, and the single maintainer

When the Heartbleed bug appeared in 2014, it turned out that OpenSSL, which encrypted half the internet, was being kept alive by a handful of volunteers and a few thousand dollars of donations a year. The xz-utils backdoor of 2024 (CVE-2024-3094) was more striking still. A single exhausted maintainer trusted, for years, a fake identity that was "helping", and the greater part of the world's servers was very nearly taken over. Nadia Eghbal's 2016 report Roads and Bridges had told this years earlier: digital infrastructure stands on free and invisible labour.

For a venture of laid-off engineers, the meaning is plain. Today there is anger, and there is free time. In six months there will be a new job, rent, a family. If there is no organisation, the project stops on the day its maintainer finds work.

Second lesson: the cloud giant's harvest

Elasticsearch was developed for years under Apache-2.0. Amazon took the code and rented it under the name "Amazon Elasticsearch Service". In 2021 Elastic closed the licence, and in 2024 it returned to the AGPL. Redis followed a similar path. When it restricted the licence in 2024, the community forked it as Valkey, and in 2025 Redis moved back to the AGPL. MongoDB told the same trouble in 2018 by moving to the SSPL.

The lesson is this: the largest user of infrastructure code written under a permissive licence is not the community that develops it. It is the cloud monopoly that sells it as a service. These companies learned that, painfully, years later. OccupySaaS is starting with the same licence.

Third lesson: openness can be a phase of marketing

HashiCorp developed Terraform in the open for years, and gathered thousands of outside contributions. In 2023 it changed the licence to the commercially restricted BSL. The community forked OpenTofu under the Linux Foundation. HashiCorp was sold to IBM a short time later.

We are not looking for a "villain" here. This is the ordinary working of capital. If the ownership of a codebase grown by common labour is gathered in a single legal person, that property will one day want to be valued. The community's contribution becomes the line that does not appear on the balance sheet of the company's valuation. If, in an anonymous venture, we do not know who owns it, we also cannot know whether this road is open.

Fourth lesson: the tyranny of structurelessness

Occupy Wall Street swept the world in 2011 and dispersed in two months. The reason was not the police alone. A movement that prided itself on being "leaderless", "structureless" and "demandless" could not build a lasting organisation. Jo Freeman's 1970 essay for the women's movement, The Tyranny of Structurelessness, had said this long before: where there is no formal structure, an informal structure forms. And an informal structure answers to no one.

OccupySaaS takes its name from precisely this movement. Unfortunately, it takes the weakness too.

Fifth lesson: a graveyard of clones

We cannot say that every "alternative to the giants" fades. But the countless "open clones" of Twitter, of Slack, of Google Docs gathered stars and were then forgotten. What the ones that stayed standing have in common is not technical superiority. It is that they were bound either to a foundation (the Linux Foundation, the Apache Foundation, the CNCF), or to a public institution, or to a sustainable community structure. What keeps Mastodon standing is not the code. It is the organised labour of the hundreds of server administrators who run the federation.

In short, code is easy to copy, and an organisation is not. The greater part of the value of SaaS is not in the code either. It is in the operations team on night watch, in the security audit, at the support desk: in living labour. Opening the code does not collectivise this living labour. Self-hosting only loads that labour back onto the user's shoulders.

---

Why Is BilişimSen's Announcement a Problem?

Now to the real subject of the piece. Let us speak in a comradely way, and plainly.

When a union announces something, it does not do so as a news site would. The union's voice is the voice of organised labour. It gives what it announces the approval of the class. BilişimSen's announcement must therefore have a criterion too.

The points we find troubling in the OccupySaaS announcement are these:

1. Presenting the lack of organisation in the language of organisation. To announce as a "movement" a venture that has no constitution, no membership and no decision mechanism behind it is to tell the worker "you can resist without building an organisation". The reason BilişimSen exists is the opposite of that.
2. Not questioning a licence open to capital. BilişimSen ought to know, better than anyone, what the licence question means. To announce without comment a licence open to the uncompensated seizure of labour is to withhold that knowledge from the members.
3. Showing an individual exit as a collective solution. The story "Were you laid off? Write code, beat the giants" makes invisible the struggle, against dismissal, for a collective agreement, for severance, for job security and for workplace organisation. The computing worker's problem is not being unable to write the code. It is being unable to own the code they write.
4. Granting trust without asking for transparency. To give visibility, under the BilişimSen logo, to a venture whose donations go to a personal account and whose managers are unknown is to write the bill for every problem that may later arise onto BilişimSen as well.
5. Leaving one's own agenda in someone else's shop window. Announcing a venture that comes from abroad and aims at foreign SaaS products remains an empty enthusiasm when it is not tied to the concrete problems of the computing worker in Turkey (overtime, surveillance in remote work, the misery of the white collar, the barrier of the branch of industry).

We are not writing this because we think BilişimSen's intention is bad. The opposite. We find it a good thing that interest in such a venture exists among computing workers, and that BilişimSen has seen that interest. But tying the interest to an organisation is BilişimSen's job. Making the announcement with a list of questions would have been much stronger: "Why is this venture not AGPL? Who governs it? Where do the donations go? How can it be bound to our cooperatives?"

---

What, Then, Is the Right Way? Criteria for Being Cautious

Being cautious does not mean being opposed. When we see a new software venture, and especially when it claims to be a "movement", we can ask these questions:

Question	Why it matters
Is the licence copyleft (GPL/AGPL)?	It legally blocks capital from closing the labour in
Does the code belong to a foundation, a cooperative or an association?	It provides an ownership that one person cannot sell or change
Is a copyright assignment (a CLA) demanded from contributors?	Copyright assignment is the door to changing the licence unilaterally later
Are the rules of decision written down?	It gets in the way of informal power
Where does the money go, and who audits it?	It separates a donation economy from personal income
How will the labour of operations and maintenance be paid?	It prevents volunteer exhaustion and unpaid labour
Is there a bond with an organisation, or with a labour movement?	It makes the project's life independent of how long its founder stays unemployed
Is the user given a right to decide?	It turns a customer relation into a community relation

A venture that answers these questions in the affirmative is genuinely a candidate to be a software commons. A venture that does not may be well-intentioned, and it may produce useful code, but it is not a movement. To greet it as a movement is wrong too.

---

Why Do the Commons Matter So Much?

Dear young comrades, under this whole argument lies a single large question: In the digital age, whose will the common wealth be?

Today artificial-intelligence models are trained on code, writing and art made by millions of people. We call this the expropriation of the general intellect. Knowledge produced by common labour is turned into the property of a few companies. The only lasting defence against this expropriation is to organise knowledge as a commons.

A commons requires three things together:

• Common ownership: the code, the data and the model belonging to no single person or company. A copyleft licence, and a collective legal person.
• Common governance: the rules being written and changed by the community that applies them. Ostrom's "design principles".
• Common reproduction: making visible the labour of maintenance, operations and support, and paying for it. Software cooperatives, and public finance.

If one of these is missing, the commons collapses. Code that is open but ownerless gets fenced. Code that is owned but ungoverned is sold one day. Code that is governed but cannot be reproduced fades from exhaustion.

There are examples. The FACTTIC federation in Argentina brings dozens of software cooperatives together. In Brazil the landless workers' movement, the MST, has a technology unit. In Turkey there is the Albatros Computing Cooperative. Debian has worked for years with its own constitution and an elected project leader. None of them shouts "we will beat the giants". All of them quietly do this: they organise labour, they make property common, they share the decision.

As we said in Organising 2.0, a network does not become an organisation by itself. Stars gathered on GitHub do not become solidarity by themselves either.

---

Concrete Tasks

For BilişimSen:

• Use a list of criteria when announcing ventures of this kind (licence, governance, transparency, a bond with an organisation). The table above can be a start.
• Organise a short "Licence and Labour" course for members. Explain the class meaning of the permissive licence, of copyleft, of the CLA and of copyright assignment.
• Turn the anger of laid-off members into support for founding a cooperative. Legal advice, shared hosting, a shared infrastructure for issuing invoices.
• Carry into the agenda the demand for copyleft and a priority for local cooperatives in the software purchases of public institutions.

For the computing worker:

• Look at the licence, the constitution and the CLA of a project you will contribute to. Know to whom you are gifting your labour.
• Use the AGPL or the GPL by default in your own projects.
• Do not stop at giving a star. Join an organisation: a union, a chamber, an association or a cooperative.
• Beyond writing code, put workplace organisation first. Organise before you are laid off, rather than resist after.

For us (Knowledge Commons):

• In the P7 work on public software commons, take up again the idea of a "directly compatible open alternative", on the model of copyleft plus a cooperative.
• Treat this argument as a case in the "From the People's Data to the People's Model" talk at Odak 2026.

---

Dear comrades,

OccupySaaS's slogan is a good one: "They laid us off. We're rebuilding their SaaS." We want to correct that sentence a little:

They laid us off. So we organised. The code we write is no longer anyone's. It is all of ours.

The difference looks like a word or two. But the difference between Occupy Wall Street and a lasting organisation of the class is exactly in those words. Anger is a beginning. Code is a tool. What lasts is the organisation.

The machine is new, and the chain is old. What will break the chain is not a new code repository. It is something old, and something that never grows old: organised labour.

---