The exploitation paradox in open source

The exploitation paradox in open source [LWN.net] LWN .net News from the source Content Weekly Edition Archives Search Kernel Security Events calendar Unread comments LWN FAQ Write for us Edition Return to the Front page User: Password: | | Log in / Subscribe / Register The exploitation paradox in open source By Joe Brockmeier March 2, 2026 CfgMgmtCamp The free and open-source software (FOSS) movements have always been about giving freedom and power to individuals and organizations; throughout that history, though, there have also been actors trying to exploit FOSS to their own advantage. At Configuration Management Camp (CfgMgmtCamp) 2026 in Ghent, Belgium, Richard Fontana described the " exploitation paradox " of open source: the recurring pattern of crises when actors exploit loopholes to restrict freedoms or gain the upper hand over others in the community. He also talked about the attempts to close those loopholes as well as the need to look beyond licenses as a means of keeping freedom alive. Fontana is a lawyer who is well-known as an expert on FOSS licenses. He has worked for Red Hat for much of his career, and now works directly for IBM since it absorbed Red Hat's legal department in early 2026. He said that this would be an unusual talk for CfgMgmtCamp, as it was not about configuration management—though he had provided legal support to people working on related projects such as Ansible and Foreman . He would not be speaking for Red Hat or IBM in his talk, however, though he said it did draw on his work experiences over the years. " I'm on vacation, seriously. I wanted to go to Ghent ". Infrastructure and freedoms He said that he might look at open source differently than many in the audience, and that he had been struck by how there were periodic crises and disagreements related to " legal stuff going wrong ". These periodic flashpoints are not totally random, he said, they have underlying features in common; the thing that varies over time is what he called the infrastructure. " I don't mean like 'servers', I mean the current state of play that software is situated in ", from a technical, cultural, and social perspective. Basically, everything that shapes where power concentrates and how freedom can be exercised. Our definitions of freedom are anchored to an earlier technological world, he said. For example, the Free Software Foundation's four essential freedoms : the ability to run, study, modify, and share software all relate to the early days of software development. There is also " the other normative definition that doesn't use the word freedom ", the Open Source Definition (OSD) by the Open Source Initiative (OSI). Those definitions can be thought of as sort of a constitutional foundation for open source. Fontana observed that the " state of play that software is situated in ", everything that is relevant from a technical, social, economic, and business perspective, keeps evolving. Each time that it does, there are new tensions and power dynamics that pop up; but the definitions that underlie our understanding of free software and open source stay the same. They have not been revised to change with the times. This is in part because the gatekeepers for those licenses (" and I've been one of these gatekeepers in the past ") do not want to revise the definitions. In a sense, he said, open source is a conservative domain because it is tied to unchanging definitions even while other conditions do change. When infrastructure changes, there are new opportunities to exploit open source—to exercise power, to create new business models, to make a profit—that did not exist previously. When that happens, people tend to reach for legal fixes to address the exploit, which in turn can create new control points. To illustrate, Fontana said he would walk through some of the history of open source to give examples, beginning with the first flashpoint: the invention of copyleft. Copyright and copyleft Originally, developers were able to share code because it was not obvious that copyright even applied to software. " All software was inherently free. It was a commons. " And then it became clear in the late 1970s that copyright did apply to software after all. That was an infrastructure shift that made it possible to exert control over software by stopping people from making and distributing modifications to software. Copyleft, in the form of the GPL, was a response to that new control point. " It, famously, uses copyright law to create a different type of license that tries to keep software free. " It was a well-intentioned attempt to use a legal tool to improve conditions brought about by legal changes. But despite it being well-intentioned, it was controversial in software-developer communities, Fontana said. Even today there is still a schism between copyleft proponents and those who prefer permissive licenses, such as the BSD, MIT, and Apache licenses. The GPL also opened up a new, unintended, control point in the form of the dual-licensing model. " And this is really interesting, because the GPL is designed to prevent software from being exploited through copyright. " Dual licensing was used to make proprietary licensing effective by giving one party control over copyright, but not others. " You're the one copyright owner of a GPL-licensed code base and you provide a proprietary version for a fee. " That, too, was controversial, but it took time for people to develop the vocabulary to explain why they were concerned about it, he said. Instead of the motivations being to perpetuate the free software commons, you have people using the machinery of copyleft licensing in a certain sense to move code out of the commons. Even though, in a formal sense, it's still there, and there's nothing in the GPL that says this is wrong. Dual-licensing is the first example of " a phenomenon that repeats itself throughout the history of open source. This feature is asymmetry. " Anyone can exercise the freedoms under the GPL, but only one actor has the freedom to use proprietary licensing. To implement this asymmetry, the copyright holder needs to implement a copyright-assignment system or contributor-license agreements (CLAs) that give more power to the maintainer of the project. SaaS loophole The first attempt to use asymmetrical power in open source to make money " in a way that is somehow divorced from the ideals open source is founded on " was dual-licensing, but it was not the last. Businesses continue to use the freedoms granted by open-source licenses to " introduce new forms of scarcity in some way or another ". Fontana said that the audience had probably heard of what he called the Software-as-a-Service (SaaS) loophole, which " kind of breaks open-source licensing ". In particular, it breaks the GPL and copyleft licensing, because the legal foundations of those licenses rest on distribution, which does not happen when the code is used in a SaaS context. " You sort of escape the intended obligation under the GPL even though you're doing things that are sort of similar to what distributors do ". Since there is no binary distributed, the requirements in the GPL are not triggered. In a SaaS context, " the copyleft GPL software becomes equivalent to permissive-license software ". Once again, some people responded to this change with concern about the integrity of open source and an attempt to fix the problem. In particular, it led to the creation of the Affero GPL (AGPL), " sort of an attempt to patch the GPL ", so that deployment of a service becomes a trigger for releasing source code. " I would argue that the AGPL was well-intended, but I don't know if I would say that it was well-designed to combat the problem it was created to deal with. " The AGPL is another example of trying to make a fix to a license when a problem emerges, but licensing does not solve the problem very well. In fact, Fontana said, the AGPL is often used by businesses in a dual-licensing context. Brand identity The value of open source as a brand identity is another sort of infrastructure shift; there is value in labeling something "open source", but it is problematic for the community because there is no way to protect that brand. The Open Source Initiative tried to trademark the term "open source" but failed to do so . That has led to various parties stretching the definition of open source, often toward more restrictions, " really stretching the normative foundations [of open source] or kind of entering into public conflict with them ". Those parties have taken advantage of the ambiguity around what open source is, and turned it into an asset that can be monetized. Open source has become a misused term, without any clear way to combat its misuse. " Open source became this valuable brand, and in some ways it became more valuable than the substance it was supposed to represent ." One form of this that Fontana described is the creation of source-available licenses " mostly used by startups that got built up around a popular open-source project ". The familiar narrative, after a few years, is that the startup does not like the way that people are using the freedoms they were given through the open-source licenses. For example, cloud providers can often operate services based on open-source projects better than the startups can, which leads companies to decide to use licensing against their competitors. The source-available licenses are designed to look like open-source licenses, and the projects are often hosted publicly and allow some of the freedoms that users expect. Those licenses do not comply with the OSD, though, because they discriminate against at least one class of users. " They're ultimately sort of aimed at competitors, without saying, 'if you compete with us, you can't use this software.' They're not honest, in that sense. " Fontana used the example of HashiCorp switching its license from the weak-copyleft Mozilla Public License (MPL) to the Business Source License (BUSL). That license " basically says 'you can use this, but not in production' ", and then converts to an open-source license after several years. The BUSL is not the worst kind of source-available license, he said, and admitted he does not like source-available licenses, in part because they exploit confusion about what "open" means. If a person is not " really clued into this stuff ", then they might be confused and misled into thinking it was open source. Sometimes companies will even continue referring to the project as open source, even while using a restrictive license: There's no question that part of what gives power to these licenses, and the business models enabled by these licenses, is the existing confusion it is exploiting around what 'open' means and what 'open source' means. So source-available licenses just exacerbate some of these problems we've seen historically around asymmetry and so forth. Around the same time source-available licenses became a problem, he said, a " splinter movement in open source " started up as well: the ethical-source movement. He described that movement as believing that normative definitions of open source are flawed because " open source allows you to do all sorts of bad things ". Fontana noted that the ethical-source movement did not fit exactly with the model of exploiting open source for profit, but it " sort of should, in a sense ". The concern that open-source software could be used for " nefarious purposes " has been around for a long time, of course. And it is true, he said, that it is morally neutral because the freedoms are available to everyone. " You can't discriminate against users, or you can't say the GPL is only available as long as you're a good person. " The JSON license from 2002, which is basically the MIT license with a provision added that the software " shall be used for Good, not Evil ", was a forerunner to the ethical-source licenses. There are problems with the ethical-source licenses, too. They do not fit with the accepted definitions of open source, because they discriminate against specific use cases such as " you can't use the software for any use case that violates human-rights law ", or similar. Though Fontana did not say this explicitly, enforcing such licenses would also be difficult, if not impossible. His slide described those licenses as " principled, but misdirected ". (The full set of slides is available on the CfgMgmtCamp site .) Open-source developers realized that bad things are happening with their software and feel they have to do something to stop it. But, how? " You're not empowered to write new laws. You're just a software developer [...] so the only tools you know how to use are licenses " because those are the foundational tools of the whole system. Ethical licenses, he said, are their own infrastructure shift; they are designed to allocate power to certain people and deny it to other people. This time the attempt to create an asymmetry of power is not for profit, but to try to do good. AI The most recent infrastructure shift is AI. Fontana said that that there are " all sorts of asymmetries around what we're calling AI now, and they're more extreme than anything we've seen before ". He said he was tempted to say that AI has nothing to do with open source, but that isn't quite accurate. " AI in the modern sense is built on a foundation of lots of important open-source projects ", which includes authentic open-source projects built up around the use of AI models. But within the world of people creating AI models themselves, " the term 'open' is used extensively, but it's used meaninglessly. And then people using the technology repeat this problem ". The ambiguity around open source just gets worse in the AI era; "open source" in the AI context just basically means that model is public. " It is actually worse than what we have with source available, it's just a signal with no substance ". Misuse of "open" in this context, he said, was openwashing . The models, if thought of as software, do not meet the normative definition of open source. There is no source code, in this case training data, published, and often even information about the training data is not disclosed. " So there's this kind of extreme non-transparency in a context where the term 'open source' is being widely used ", which is unfortunate. So you might say, "why can't we solve all this by creating a new license?" And you know by now my answer is that licenses are not good at solving these problems. Some people are angry about AI and have proposed creating licenses that basically forbid using software to create a new model. Those licenses, Fontana said, would violate the OSD pretty clearly, and it's not even clear that those licenses could solve the problems. Licenses are " very brittle tools " that can't do much. They were effective for the limited purpose they had in the 1980s and 1990s, but the problems of today are too complex for a single type of tool to solve. Licenses aren't the solution Fontana said that when he was discussing the talk with one of the organizers, he was asked to be inspirational: " I'm not used to doing that, I mostly just like to complain about stuff " he deadpanned. He was, however, willing to try. The problem that he identified was that the way open source is conceptualized is rooted in the past, and it does not get updated for new problems. His suggestion is that we should try to reframe open-source freedoms " in a way that is more dynamic or adaptive or mobile ". He displayed a slide (reproduced below) first with the classical freedoms and then with his concepts for new freedoms: reproduce, verify, participate, exit, and stewardship. He ran through the new freedoms quickly. The right to reproduce " is not an original idea in any sense, kind of a generalization of the work done on reproducible builds ". The GPL is designed to allow users to rebuild software from source, but systems are more complex now and " being able to rebuild source code is not enough ". There is a need for a more robust ability to rebuild and verify software. As an example, he said, someone claims to be running a service based on open-source software, but perhaps they've modified it in a substantial way without publishing the modifications. " How can you verify the claims they make about those things? " He mapped the right to modify software to a new concept of a right to participate in development of software. " If you are dependent on a project, there's a sense in which you should have some way of ideally participating in its governance ." Modification is a local freedom, whereas participation is more of a collective freedom. He said it was not a radical proposal for open-source development to become a free-for-all with no standards for contribution, " but it's sort of elevating participation to the level of the original freedoms ." Everybody talks about how the right to fork is a fundamental aspect of open source, but " it turns out in practice, and this has become increasingly true over time, you can't easily fork projects in most cases ". It is actually too costly to practically exercise, so he felt that open source should explicitly state that it is built on " the right to compete " which could make it more practical for participants to exit a community that no longer serves their needs. That, of course, is directly in conflict with the source-available licenses. Finally, stewardship " corresponds to the work you need to do to sustain projects and the community " and should be " elevated to the foundational level for what open source means ". Open source is a human endeavor, Fontana said. The freedoms that he was articulating correspond to real human activities that are important to consider when thinking about the ideals that open source ought to meet. So, the right to reproduce is based on curiosity. The right to verify is based on integrity. The right to participate is related to the notion of solidarity. The right to exit corresponds to the concept of courage. And stewardship, of course, corresponds to care. So these are all human forms of these kinds of reframed definitional freedoms. He was not proposing, he said, to replace the existing freedoms or the notion of what an open-source license is. Those are still a foundational part of open source. But he felt that we need to have a bigger and more expansive sense of what open source means that is not simply rooted in a " static checklist of permissions of 1980s and 1990s kinds of concepts ." Asymmetry is inevitable in open source. It is a feature of infrastructure shifts; there will always be changes in the field of play that create new power relationships and leverage points. What we can do, Fontana said, is make sure that power does not become ossified, " and that's what this notion of mobile freedoms is sort of aimed at ". We cannot eliminate asymmetry, he said, but we can continue to work around it. There was time for one question. An audience member wanted to know if he was referring to the Open Source AI Definition (OSAID) in his talk. Fontana said that he had not mentioned the OSAID in the talk, but had been a critic of the definition. The OSI came up with something that was too complicated and impractical " and also didn't make anyone happy because it has this big compromise built into it ". It tried to address the problem of undisclosed training data, but it does so in a way that has " kind of a hole in it ". It was, " sort of pointless, frankly " and maybe shows that trying to come up with a definition similar to the open-source definition is not the right approach to address the problem. " But I'd have to think about that more. " With that, time elapsed. The new freedoms proposed by Fontana seem interesting, and could do with more detail on how to implement them, but his point that licensing alone is insufficient is certainly valid. It would be useful for people and projects to be thinking beyond licensing to new ways to retain the ideals of open source as the world keeps changing. [Thanks to the Linux Foundation, LWN's travel sponsor, for funding my travel to Ghent to attend CfgMgmtCamp.] Index entries for this article Conference CfgMgmtCamp/2026 to post comments It's good to bring disagreements to surface Posted Mar 2, 2026 20:31 UTC (Mon) by sionescu (subscriber, #59410) [ Link ] (8 responses) I do vehemently object to this: "If you are dependent on a project, there's a sense in which you should have some way of ideally participating in its governance". It comes from a consequentialist moral view, that I don't share (and I don't think I'm alone in this), and in practice it's what is leading many project maintainers to burn out or at least get vary jaded. It's common nowadays to see users opening bugs with a very entitled attitude, that since he (or his company) depends on that library, the maintainers are supposedly obliged to fix ASAP. Or, in larger projects, that the project should be run by a committee where the users have the majority and the developers are in minority (latest example being Rust). And even if you take a more conciliatory view that participation in governance must be balanced with some remuneration to the maintainers, that still doesn't solve the problem that maintainers might have goals completely at odds with the users. Maintainers might not be interested in supporting certain operating systems, in providing SBOMs or other such kind of paperwork, etc... It's good to bring disagreements to surface Posted Mar 3, 2026 4:50 UTC (Tue) by marcH (subscriber, #57642) [ Link ] (3 responses) I think you're reading way too much into this, so it can match your fears. > very entitled attitude [...] since he (or his company) depends on that library, the maintainers are supposedly obliged to fix ASAP. That for instance, looks really far from "ideally participate in its governance" or from any other "ideal". The maintainers who burn out do so because they want their project to reach some desired level of success and recognition - which relies on participation. There are plenty of _other_ open-source projects where maintainers don't care that much, let bugs pile on, pull requests go unreviewed for months, etc. And any shade of grey in the middle. So unless you're literally addicted to social recognition from a few random, entitled persons on the Internet you never heard of, caring too much and burning out is a personal choice. It's "only" one workaholism variant among others. This looks more relevant: > Modification is a local freedom, whereas participation is more of a collective freedom. [...] Open source is a human endeavor, Fontana said. The freedoms that he was articulating correspond to real human activities that are important to consider when thinking about the ideals that open source ought to meet. It's good to bring disagreements to surface Posted Mar 3, 2026 14:12 UTC (Tue) by daenzer (subscriber, #7050) [ Link ] (2 responses) > That for instance, looks really far from "ideally participate in its governance" or from any other "ideal". Just before your quote, the article says "He mapped the right to modify software to a new concept of a right to participate in development of software." The "right to modify" being one of the freedoms granted by FLOSS licences. I.e. in the context we're discussing here, a "freedom" implies entitlement / a right. I agree with the grand-parent poster that deriving a "right to participate" in a project from a mere "dependency" (what does that mean exactly?) on it would be going too far. The members of a project must have the prerogative to reject contributions / participation based on criteria they deem appropriate, or the project can't defend itself against sloppiness, let alone malice. And this isn't just fear about a hypothetical concern, I've witnessed situations where this would have been disastrous for FLOSS projects. It's good to bring disagreements to surface Posted Mar 3, 2026 14:26 UTC (Tue) by jzb (editor, #7867) [ Link ] (1 responses) At the risk of sounding like I'm speaking for Richard, I'd suggest that the first post in this thread is reading some things into the idea that are not present and extrapolating a general idea too far. To me, at least, it seemed clear that this was really aimed at projects that are single-vendor driven or similar. And that it's an idea that needs to be fleshed out when people are forming governance for a project and/or when people consider using/participating in a project. As he did say in the talk, licensing doesn't solve everything -- so I didn't understand this as a mandate that would be built into licensing, but as a community norm that he'd like to see take hold. That, at least to me, means that the consideration around participation would come from all directions -- e.g., if you're outside a project and it's clear that it won't allow you to participate, perhaps re-evaluate whether you're willing to use a project. And there are already communities/foundations that embody this or try to -- e.g., Apache Software Foundation projects are supposed to be level playing fields where anyone can participate / contribute and not be blocked by other corporate interests, etc. That doesn't mean anybody can show up and demand that their patches be accepted, but if a top-level project at the ASF gained a reputation for refusing to allow outside participation except for (say) members of a few companies, then the ASF board might get involved and strongly suggest that the project change its tune. The members of a project must have the prerogative to reject contributions / participation based on criteria they deem appropriate, or the project can't defend itself against sloppiness, let alone malice. Sure. And I don't really think Richard would be suggesting otherwise. Nor do I think this is, for example, aimed at single-maintainer projects or similar. It's good to bring disagreements to surface Posted Mar 3, 2026 14:42 UTC (Tue) by daenzer (subscriber, #7050) [ Link ] > Nor do I think this is, for example, aimed at single-maintainer projects or similar. Neither is my concern. Also, anyone who knows me knows that I'm pretty far from condoning projects which restrict participation to certain companies or groups. Allowing participation by anyone with the required competence (or willingness to learn) and good intentions is very important to me. (Without that I couldn't have started contributing to FLOSS projects myself as a student after all) > As he did say in the talk, licensing doesn't solve everything -- so I didn't understand this as a mandate that would be built into licensing, but as a community norm that he'd like to see take hold. If that is the case, the connection to the "right to modify" granted by FLOSS licences seems misleading. It's good to bring disagreements to surface Posted Mar 3, 2026 17:36 UTC (Tue) by rgmoore ( ✭ supporter ✭ , #75) [ Link ] (2 responses) As others have said, I think you're reading a bit too much into this. There's a big step between participating in governance and calling the shots. Developers really should be listening to their users and, within reason, working to give them what they want. That doesn't mean developers need to be at the beck and call of every individual user- if nothing else, different individual users might have mutually exclusive requests- but when a large subset of the userbase is saying they do or don't want something, smart developers listen. I think this gets to the issue of legal versus ethical obligations. FOSS developers have basically no legal obligations to their users. They can abandon the project, add features nobody asked for, or deprecate features people depend on, all while remaining within their legal rights. But once a project has dedicated users, the developers have an ethical obligation not to mistreat them. That means they should listen to what their users do and don't want and take those desires into account. If they're going to abandon a project, they should let users know and take reasonable steps to pass find a replacement. Respect for the users can make the difference between a mediocre project and a great one. It's good to bring disagreements to surface Posted Mar 3, 2026 17:49 UTC (Tue) by sionescu (subscriber, #59410) [ Link ] (1 responses) > but when a large subset of the userbase is saying they do or don't want something, smart developers listen I don't agree. It might be those developers who want to operate the project as a semi-commercial endeavour might do that, but still, all developers have all the right to say "NO" to requests from the so-called "community": from the Sqlite developers (God bless them), to individual developers that have no interest in turning a project, albeit a popular one, into a broad mission or to the Clojure team who want to keep the language focused and reject features they consider useless to that mission. > But once a project has dedicated users, the developers have an ethical obligation not to mistreat them. Abandoning without advance notice, or without a succession plan is not mistreatment. The developers own the project, and as such they have the right to "abusus" of their property. They're already generous enough to bestow "usus and fructus" on the users. It's good to bring disagreements to surface Posted Mar 4, 2026 10:39 UTC (Wed) by taladar (subscriber, #68407) [ Link ] I would say if there is any moral obligation at all for developers then it is (if able of course, sudden accidents happen) to keep some sort of short notice of their intentions for the project (actively maintained for general consumption, actively maintained but basically only for their own use cases, research/learning project, abandoned,...) somewhere at the top of the README or some similar location. Just to save everyone the hassle of mismatches in expectations. It's good to bring disagreements to surface Posted Mar 9, 2026 22:19 UTC (Mon) by timrichardson (subscriber, #72836) [ Link ] Judging by context, Fontana probably merely meant to extend the concept of local modification, so the participation right is development participation ("open-source development"). FOSS License as Social Contract Posted Mar 2, 2026 23:35 UTC (Mon) by rgmoore ( ✭ supporter ✭ , #75) [ Link ] (2 responses) I think the biggest thing to understand is that FOSS licenses are barely useful as enforceable legal constructs. Suits to enforce the licensing terms are long and painful, and there's no guarantee they'll achieve anything useful even if you win. The license exists more to help define what kind of community the author wants to build around the software. This is an extension of the general truth that any society depends more on social norms than laws to determine how things work. A community where most people cooperate only because they're afraid of legal consequences will fall apart if people lose their fear of the law. A community where most people cooperate because they believe in cooperation will continue to function even if the law stumbles occasionally. FOSS License as Social Contract Posted Mar 3, 2026 4:30 UTC (Tue) by marcH (subscriber, #57642) [ Link ] > A community where most people cooperate only because they're afraid of legal consequences will fall apart if people lose their fear of the law Good thing this is only theoretical. Oh, wait... FOSS License as Social Contract Posted Mar 6, 2026 23:55 UTC (Fri) by ssmith32 (subscriber, #72404) [ Link ] The fact that legal systems are rarely efficient and fair, does not preclude people following the law because they are afraid of it. Sometimes quite the opposite occurs - the very inefficiency and unpredictability of the legal system scares people (and companies) into going through extra lengths to avoid getting dragged into the legal system. Therefore, FOSS licenses are useful as *potentially* enforceable constructs, if not easily enforceable ones. Soo.. if by "useful as enforceable legal constructs" you mean goal is to easily sue people and win, you have a point. But if the meaning of your statement is taken to be that the license is useful if it is followed, you do not, as punishment does not have to easy to exact on someone to make the threat of it encourage the desired behaviour. Open source is the preferred form of software Posted Mar 3, 2026 3:55 UTC (Tue) by ebiederm (subscriber, #35028) [ Link ] I haven't seen anyone put it in a license, but if we talk about communities and social norms I recommend spelling out that open source software be the preferred form of software. I don't always see that around open source software and when it is not things seem to be going sour. Too clever by half Posted Mar 3, 2026 13:10 UTC (Tue) by ptime (subscriber, #168171) [ Link ] I just put my software in the public domain where it belongs. If someone wants to exploit it for profit, more power to them. Social norms vs letter of the license Posted Mar 5, 2026 5:03 UTC (Thu) by tiffnix (subscriber, #171224) [ Link ] (1 responses) I've noticed before, that the strictest sense of open source is very different from what people imagine in practice. A valid open source project can be one where you have to send a check in the mail with a nominal fee to receive a copy of the source code on floppy disk. Some real and widely used projects aren't far off from that model. For example, the Lua programming language doesn't have a public version control repository and does not accept pull requests. It's distributed as a set of source tarballs on the website. SQLite's development is even more closed, as parts of their test suite are kept private. It's a huge contrast compared to the typical open source projects today, that you find on places like GitHub and Codeberg. These projects come with many of the things that were mentioned in the talk, like the ability to participate (bug reports, feature requests, patches), reproducibility (all tests and build scripts included in the repo), etc. So I think it makes a lot of sense to try to define and enshrine these social norms outside the context of a software license. Social norms vs letter of the license Posted Mar 5, 2026 20:47 UTC (Thu) by brunowolff (guest, #71160) [ Link ] I think you need to account for intent as well. If I do something for myself that I think possibly someone else might want to incorporate in something they are doing, I'm going to license it very permissively. But if I were to start working on a project that I wanted to work on collaboratively for an audience of people, I'm going to probably use a copyleft license to make it harder to capture by an outside party. On tools, branding and the nature of the problem Posted Mar 5, 2026 16:30 UTC (Thu) by SLi (subscriber, #53131) [ Link ] Fontana's diagnosis is sharp: the pattern of each legal fix enabling the next exploitation is genuinely useful scaffolding. But I think the talk stops one question short of what it circles around: How much of this is a legal problem and how much something else? There's also an underexplored tension in the "mobile freedoms" proposal. It sounds like two thirds of the talk was about how gatekeepers fail to keep up with infrastructure shifts. The presented solution is, essentially, a new definitional framework. A better one, arguably, but still something someone has to articulate, maintain, and interpret. If the freedoms are truly dynamic and adaptive, you can't anchor them to a fixed definition—and that, in turn, is precisely the kind of ambiguity that enables the exploitation he complains about. If you do anchor them, you are back to the static definition problem. It sounds like he is caught between wanting the clarity of a normative standard and the flexibility to evolve with circumstances, and those desires are in genuine tension. There may be a way to resolve this tension, though: apply Fontana's own proposed freedoms—especially the right to participate—to the governance of the definition itself. If the definition is maintained through a genuinely open, participatory process, the stability comes from the legitimacy of the process rather than the fixity of the content. Of course, that means accepting that "open source" might one day evolve to mean something closer to what we'd currently call "source available." The current guardians of the term would have to live with that. But if you believe in open governance as a principle, you have to accept it even when the outcome isn't the one you'd choose. And if you don't accept it, you're conceding that what you really want is a specific outcome protected by gatekeeping. On the "open source" branding problem: I think it's worth being precise about what claim is actually being made when we say companies are misusing the term. There's a moral/community-norms claim ("you're violating the spirit of what we built"), a definitional-authority claim ("the OSI definition is canonical"), a potential legal claim around misleading representation, and a purely linguistic claim—"open source" in ordinary English just means the source is open, and by that reading source-available licenses aren't even wrong. These are very different arguments with different implications, and FOSS discourse tends to conflate them. The uncomfortable truth is that the movement chose a generic term partly because its intuitive accessibility was a strategic asset for adoption. The genericness was the feature. But genericness and enforceable meaning are in direct tension, and you can't retroactively resolve that by wishing people would defer to the OSD. The trademark avenue failed because "open source" is generic language, and arguably a court recognizing that is the system working as intended—society declining to let a single entity govern the meaning of common words. Entitlement and asymmetry Posted Mar 6, 2026 13:52 UTC (Fri) by paulj (subscriber, #341) [ Link ] (18 responses) > He mapped the right to modify software to a new concept of a right to participate in development of software. ""If you are dependent on a project, there's a sense in which you should have some way of ideally participating in its governance"." This comes across as a very user-entitled POV. Any developer/maintainer of Free Software will know this is a regular problem, where people think you owe them something because they believe they were 'gracious' enough to use the software you provided - leading to a number of undesirable behaviours. I'd also reflect on that in combination with Richard's point that there is asymmetry: > So source-available licenses just exacerbate some of these problems we've seen historically around asymmetry and so forth. I think asymmetry is an issue, but often the problem is the /other way around/ from how Richard perceives it - at least in/around Free Software that is important to infrastructure. The users are often well resourced compared to the maintainer - the user is being paid to work on something, in which this piece of Free Software is playing a part, for a company that is making money (at some level removed) from these activities. Where the maintainer often is not paid specifically for this work, and certainly not being paid by the user's company. I.e., the asymmetry manifests itself in that the /user's/ company will pay that user or other developers to work on whatever problem they have to hand with the software, but never will they pay the maintainer. And the user then expects the maintainer to take on some or all of the immediate integration and testing work, and all of the future support work. I think Richard is missing out on key parts of the problems the modern Free Software ecosystem experiences. Though, being at one of the few big corps that makes a profit from Free Software, it may be they are more insulated from those problems (?). Better way for companies to pay for support/fixes Posted Mar 8, 2026 21:29 UTC (Sun) by DemiMarie (subscriber, #164188) [ Link ] (17 responses) What would a better way for companies to pay for support and/or fixes look like? Better way for companies to pay for support/fixes Posted Mar 11, 2026 3:00 UTC (Wed) by raven667 (subscriber, #5198) [ Link ] (13 responses) I'm just throwing out ideas but it might be more healthy if a commercial organization wants to use some open-source as part of their product, either they pay for a license from the maintainer or they fork and build a consortium around the software controlled by the companies which use it, the original maintainer either gets paid for their time and is a small business, or the original maintainer gets to continue on their merry way tinkering with their hobby project, maybe pulling back changes from the commercial fork, but is unbothered by the needs and responsibilities of customer support. Volunteers shouldn't be used as an accountability sink for the customers of middlemen. Better way for companies to pay for support/fixes Posted Mar 11, 2026 11:16 UTC (Wed) by pizza (subscriber, #46) [ Link ] > Volunteers shouldn't be used as an accountability sink for the customers of middlemen. You overlook the obvious issue that offloading expenses into an external "accountability sink" is, well, much cheaper in the short term. Why pay real money when you don't absolutely have to? Absent some sort of external force (==~ regulations) this isn't going to meaningfully change. Better way for companies to pay for support/fixes Posted Mar 11, 2026 11:57 UTC (Wed) by paulj (subscriber, #341) [ Link ] (11 responses) > they fork and build a consortium around the software controlled by the companies which use it This is actually one of the power asymmetries I had in mind. You're some maintainer of some project say. You spend time (years perhaps) and effort working on some project, improving it, fixing bugs, and eventually getting it good enough that more and more companies start depending on it. These companies then start making more and more demands, without ever contributing resources to the maintainer. Worse, a good number of these demands include variations on: "Take these massively intrusive patches to add RPC-APIs into all various bits of the code, with no test harnesses, no Free Software code using it [unspoken: these allow our proprietary code, which we sell and are never going to contribute back, to use and rely on that Free Software code], and if you don't you are a problem". And when you don't comply, those companies do exactly what you wrote there, and they do their best to kick the original maintainers in the proverbial balls, using the resources and power they have to destroy the project they fork from. Doing something about such asymmetries would be nice. (There is a semi-autobiographical element to this comment). Better way for companies to pay for support/fixes Posted Mar 11, 2026 12:30 UTC (Wed) by pizza (subscriber, #46) [ Link ] (10 responses) Not to disparage your experience, but... > Take these massively intrusive patches to add RPC-APIs into all various bits of the code [...] > and when you don't comply, those companies do exactly what you wrote there [...] > using the resources and power they have to destroy the project they fork from. Another way to read this: We are making heavy use of and want to be a good F/OSS citizen and participate in upstream development. We make changes for our use case and submit them upstream, but the maintainer refuses to accept or even them. Over time this delta grows larger and becomes more and more work to maintain. Meanwhile, numerous other folks are also using our patches and reporting issues/etc with them. So to make everyone happy, we stop bothering the original maintainer and exercise our rights under and perform a soft-fork of with independent revision control (which we were already maintaining internally) and issue trackers and documentation, pooling efforts with the other major users to make it easier to coordinate our work and reduce our collective supply chain risk, and over time we end up massively out-contributing the original maintainer/contributors because we're actively paying multiple people to work on the things we care about -- and the folks using the original code dwindles because ours does everything the original did... and much more. Is this "kicking the maintianer in the balls" or... the entire user-empowering point of F/OSS? > Doing something about such asymmetries would be nice. I have a hard time seeing how "doing something" can mean anything other than "this is no longer F/OSS". Better way for companies to pay for support/fixes Posted Mar 11, 2026 12:45 UTC (Wed) by Wol (subscriber, #4433) [ Link ] (1 responses) > We are making heavy use of and want to be a good F/OSS citizen and participate in upstream development. We make changes for our use case and submit them upstream, but the maintainer refuses to accept or even them. Unfortunately these demands rarely seem to come with any offer of payment. THAT is the problem to a large extent. I take your point but they have a habit of forgetting they get a pay-cheque for their work. Expecting other people to do a lot of work for you without a pay-cheque is unreasonable. Cheers, Wol Better way for companies to pay for support/fixes Posted Mar 11, 2026 13:14 UTC (Wed) by pizza (subscriber, #46) [ Link ] > Unfortunately these demands rarely seem to come with any offer of payment. THAT is the problem to a large extent. I take your point but they have a habit of forgetting they get a pay-cheque for their work. Expecting other people to do a lot of work for you without a pay-cheque is unreasonable. Sure, except that's not what was described! in this context is putting substantial resources into . Where "substantial" far more than is able to put into things. Also, consider that already has a [more than] full time job unrelated to and the amount of work under consideration is at best retainer-style, ie part-time-bursting-to-full-time on demand. Also, if they get formally hired by it will have the effect of making effectively a work-for-hire owned by . These scenarios are really about scale -- There is a wide chasm between "just a hobby" and "capable of completely supporting oneself" F/OSS author/maintainership. Only a scant few reach the latter. (FWIW I'm also speaking semi-autobiographically here) Better way for companies to pay for support/fixes Posted Mar 11, 2026 13:29 UTC (Wed) by paulj (subscriber, #341) [ Link ] (2 responses) > We make changes for our use case and submit them upstream, but the maintainer refuses to accept or even them. Changes that come with no way to test them. No Free Software system that uses them. Changes that are made to insert RPC hooks all over the place, in order to allow proprietary software to exploit Free Software. Better way for companies to pay for support/fixes Posted Mar 11, 2026 13:53 UTC (Wed) by pizza (subscriber, #46) [ Link ] > Changes that come with no way to test them. No Free Software system that uses them. Changes that are made to insert RPC hooks all over the place, in order to allow proprietary software to exploit Free Software. It doesn't matter what the changes are, or why the maintainer rejects them. The right to create (and maintain) your own fork is the *entire point* of F/OSS. Those who do the work get to call the shots, and nobody, original authors included, gets to say "no, you can't do that" [1]. [1] as long as the upstream license is respected Better way for companies to pay for support/fixes Posted Mar 11, 2026 14:31 UTC (Wed) by raven667 (subscriber, #5198) [ Link ] I think the idea here is that when you have differing visions for the software that instead of fighting and burning yourself out, to just part ways and move on. You get to keep and maintain your software the way you see fit, that hopefully continues to bring the value you wanted that lead you to create it in the first place, and the commercial vendor gets to drive their project the way they want that provides value to them, but they don't bother you anymore. Maybe their vendor consortium fork becomes the most popular version because it's integrated with popular commercial software, I'm not sure that's terrible, aside from if you were running the project as a small business and were depending on consulting revenue from the users which might dry up if they switch providers. There is definitely an emotional attachment to things that you've crafted with your own two hands, but as the projects diverge their fork becomes less and less recognizably yours, maybe that attachment can become less and less too until it can be let go, and you can fully own your project and not worry about theirs. Or maybe this is a bad model because it doesn't take in account how human feeling about software actually works, I've not been in this situation so I'm just talking out of my ass here, and I shouldn't be bloviating about how paulj feels about software. Better way for companies to pay for support/fixes Posted Mar 11, 2026 13:58 UTC (Wed) by paulj (subscriber, #341) [ Link ] (4 responses) > Over time this delta grows larger and becomes more and more work to maintain. So... just to make something clear about my semi-autobiographical case, because this was indeed something people said to justify the corporate fork. However, there is something most did not know. And, in case you know the project I'm talking about, and you belief this "truth", I might as well clarify it: - For a number of years maintenance did indeed slow down massively, and many good patches did indeed get ignored (not just the exploitative "let us insert hooks for our proprietary code" stuff). - This occurred under a maintainer who /was/ being paid to do maintenance (or so I thought), by some weird intertwined combination of a US NPO (i.e. one of those 501.3(c), [sic possibly] or whatever - which I have since taken a dim view of) + a for-profit sister (or parent? I never got to the bottom of it) company - the NPO and FPO operated as one basically, which seemed odd to me. - After an absence for other stuff, I came back to maintenance and joined that same NPO - In a couple of months I got through a massive backlog of patches, more than half. - I was then requested by a 'leader' in this NPO+FPO to /stop/ integrating patches, in particular those of 1 corporate contributor... Why? Because they were at that point looking for sponsorship from said corporate contributor.... I left the NPO soon after that. The bizarre thing was the corporates who'd been shaken down by said NPO+FPO, and customers of the FPO, then made this "The project is blocking our patches" argument - when it was *under the stewardship of people from that "NPO"* when that had happened! Anyway, absolutely ridiculous story. Only 1 side was ever told - including by LWN when they reported on that fork. They trotted out the story from the corporates, and never even bothered to contact me about my side. Whole thing has changed my view of Free Software quite a lot though. ;) Better way for companies to pay for support/fixes Posted Mar 11, 2026 16:09 UTC (Wed) by pizza (subscriber, #46) [ Link ] (2 responses) > - I was then requested by a 'leader' in this NPO+FPO to /stop/ integrating patches, in particular those of 1 corporate contributor... > Why? Because they were at that point looking for sponsorship from said corporate contributor.... You've described a very dysfunctional organization, and quite frankly sounds very justified in forking in response to a deliberate shakedown attempt by a supplier/vendor that has repeatedly demonstrated that it should not be relied upon. > Anyway, absolutely ridiculous story. Indeed! Better way for companies to pay for support/fixes Posted Mar 11, 2026 16:28 UTC (Wed) by paulj (subscriber, #341) [ Link ] (1 responses) The entire community was dysfunctional at that time, yes. You've misunderstood something though *remained allied* with shady NPO+FPO, and together forked the project, on the basis the /project/ hadn't merged stuff. Except... that occurred under the guy working for NPO+FPO, who I had eventually suspended (not for the deliberate holding back of patches, but other stuff). So *the fork* had and NPO+FPO, who had a history of shaking down (and I assume other companies) by holding back patches but they blamed the continuing project for not merging stuff, i.e. implicitly blaming me - when it was *THEIR* guy! Now, "They have the right the fork, and you just didn't like XYZ and that's their right, ", as another respondent says. Sure, sure. However, also had some industry clout, and they just happened to have a commercial relationship with another wing of the large corp. that I was working for. And they managed to get some director in the wing they dealt with to talk to a director above me, and I was then required to cease working on , with an implicit threat of consequences (references to my contract, etc.). Oh, the FPO of the NPO+FPO also did consultancy/contract programming work, so they also had conflicts of interests there with the sponsors of the FPO. Absolute shit show of very nasty corporate-industry politics, with highly abusive corporates throwing their weight around and deliberately squashing Free Software maintainers who didn't jump to their tune. Many lessons learned for me. Better way for companies to pay for support/fixes Posted Mar 11, 2026 16:38 UTC (Wed) by paulj (subscriber, #341) [ Link ] Oh, I'll never know exactly why of course, but my best guess is that remained allied with because, even if had extorted them, they had by then paid and 's non-programmer execs were 'compliant' players in that lovely corporate-industry-"open source" game. They play their games now in some "Linux Foundation" umbrella thing. (Which is why I think LWN never bothered to look for my side). I am sad about what happened to that project. I am happy to be well away from people who don't really care about open-source, who came into it late cause they smelled money, and who had learned to play politics at some US big-tech corps that are notorious for cut-throat politics (annual stack-ranking with "cut the bottom X%" firings plus also a "up or out" policy, so even simply doing your current job well isn't sufficient for long). Better way for companies to pay for support/fixes Posted Mar 12, 2026 3:13 UTC (Thu) by jake (editor, #205) [ Link ] > Only 1 side was ever told - including by LWN when they reported on that fork. We certainly make mistakes. We are much more likely to learn from them if the reports come with links. So far, you haven't even named the project, which seems weird as well. jake Better way for companies to pay for support/fixes Posted Mar 11, 2026 10:29 UTC (Wed) by paulj (subscriber, #341) [ Link ] (2 responses) I don't know the answer to that. I think those are probably context specific questions, where the right answer depends on the project, the developer, the community - and they have to figure that out. To go 1 or 2 steps earlier in the problem chain (and pertinence to this story), I'd ask: What can be done in terms of licensing, to make it easier to the developers and maintainers of a project to construct a healthy, self-sustainable ecosystem around a project? An aspect to that likely involves giving those developers some kind of edge in providing commercial services around the project. However, many in Free Software do not like that kind of thing (although, some notable early Free Software projects did indeed sustain themselves by, in whatever way, giving some organisation around the original development team, a commercial edge via licensing). So that's unfortunate, and perhaps we should revisit that and agree on something. To go back another step, would it be morally and/or practically (in terms of the long term good) 'right' for Free Software to seek to give the authors some kind of 'edge' in any commercial exploitation (support, contract development, etc.) of such Free Software, without prejudicing the Free Software nature of the project (i.e., no open core, no shady effectively proprietary modifications via side-contracts, etc.). We should enumerate the 'good' and 'bad' forms of commercial exploitation perhaps, and perhaps see what can be done to give the authors (developers, maintainers) some little advantage in being the ones engaging in the former, and more effectively the latter. Current (widely accepted at least) Free Software licenses are either silent on this, or naïve. That potentially can be fixed. Better way for companies to pay for support/fixes Posted Mar 11, 2026 11:25 UTC (Wed) by Wol (subscriber, #4433) [ Link ] I was certainly thinking a while back that one of the best ways to do something like that, was to provide a (partial) exemption from the requirement to provide source. Allow a maintainer consortium to grant "binary distribution only" licences, but they would only be able to distribute formal consortium builds that the consortium maintained a publicly accessible repository for. So basically the corp is subcontracting the "make source available" requirement. We need some "Open Core" type mechanism, that doesn't subvert the four freedoms ... Cheers, Wol Better way for companies to pay for support/fixes Posted Mar 11, 2026 11:30 UTC (Wed) by paulj (subscriber, #341) [ Link ] > We should enumerate the 'good' and 'bad' forms of commercial exploitation perhaps, and perhaps see what can be done to give the authors (developers, maintainers) some little advantage in being the ones engaging in the former, and more effectively the latter. 'more effectively ^discourage the latter' Copyright © 2026, Eklektix, Inc. This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds