Something can be a Schelling point or a game-theoretic focal point even if it wasn't originally developed through widely collaborated-on consensus. The DFSG and the Open Source Definition are a Schelling point now, because there is now much more consensus on maintaining that specific line than there is on any particular approach to bending it; if we lose that focal point, we will have a hard time establishing a new one, especially if we haven't already established a specific standard or amendment beforehand.
I am not, for the record, arguing that the DSFG or OSD is perfect. Far from it. There's reasonably widespread agreement that the continued existence of DFSG/OSD clause 4 is a mistake and should be revoked, for instance. And it's not obvious that a strict reading of the DFSG or OSD would allow the AGPL, if it hadn't been taken as nearly a given that it must. I also don't necessarily think all aspects of the SSPL are wildly worse than the AGPL (I think it fails DFSG/OSD as written, but not necessarily in a way that the AGPL doesn't), and I personally wouldn't be opposed to seeing a more blanket "it's OK to have copyleft requirements that trigger through arbitrarily strict conditions, as long as those copyleft requirements may always be satisfied by distributing full sources including all dependencies".
There are careful evolutions that may make sense to our definitions, to better serve the goals of FOSS; I don't believe that it should be an un-amendable definition. But I don't believe the principle that anyone can use the software for any purpose is a point we should compromise on. Even if you don't believe in that principle for its own sake (which I personally do), that point in particular is an incredibly valuable Schelling point; the most probable alternatives to it (which have been attempted) would run the gamut of random "cannot use for X" restrictions. It's far easier to agree on allowing all possible uses, insofar as people who dislike any particular use can nonetheless come to a consensus on allowing all uses.
> should be freely available
> software should be free for everyone to use
While I don't think you're necessarily intending to use these terms in an ambiguous manner, I think it's important in light of the point of this discussion that "available at no cost" was never the goal; "anyone should be able to get the source and modify" was the goal. Some people argue that "available at no cost" follows as a necessary consequence from that, but I don't think that's the case.
In terms of failures of vision at the time, I think it's notable that that goal didn't take into account how many people actually have the practical ability to take advantage of Open Source (taking into account both people with software development skill and people with the ability to pay others for software development skill). Those principles were absolutely developed by people primarily concerned with the practical rights of fellow FOSS developers, which to a first approximation they idealistically treated as "everyone".
> > There's been a massive push in recent decades towards permissive licenses
> Fair point. And I admit that this has made me stop and think about my choice of license for my own primary open-source project, AccessKit [3]. I was quick to permissively license that project from the beginning, before I considered funding. As it turned out, most of my development on that project so far has been funded by Google, which also specifically requested the Apache license (I went with the Apache/MIT dual license common in the Rust world). But in any case, I think a permissive license is actually the best choice for my goal with this project, which is to encourage and help developers to make as many GUI applications as possible accessible to disabled users. So yes, I want frictionless adoption above all else, but I think it's for a good reason. If a massive company used my project without paying me, I think I would consider it a net positive, because at least more applications would be accessible.
I absolutely agree with this. I believe there are extremely good reasons to use permissive licenses sometimes. Promoting standards (e.g. PNG, zlib, zstd); getting the rapid popularity to displace a prominent proprietary product; promoting important principles that are more important than the specific software itself (e.g. accessibility); any time you value adoption of something far more than any value directly accrued back to you.
If a substantial number of projects all use copyleft licensing, that carries much more weight than when fewer projects do so; it creates an ecosystem that people buy into and then gain much from. One library in isolation doesn't create a tipping point. It's not obvious if we can escape the equilibrium and attendant social pressures of mostly permissive licenses to the equilibrium of mostly copyleft licenses.
But in general, I do think that many projects just automatically use a permissive license, or automatically listen when a large company says they'd prefer a permissive license. Any time a company tells you that they'd prefer that you use a more permissive license, they're placing value on the licensing of your software, and that's value they may be willing to pay for. How much they'd be willing to pay is another question, but if you want to be able to sell alternative licenses you have to start from the baseline of a license that a company does not prefer and is not as comfortable with.
(As a Rust developer, I am sad that the norms of the Rust community strongly and pervasively push for permissive licensing.)
I am not, for the record, arguing that the DSFG or OSD is perfect. Far from it. There's reasonably widespread agreement that the continued existence of DFSG/OSD clause 4 is a mistake and should be revoked, for instance. And it's not obvious that a strict reading of the DFSG or OSD would allow the AGPL, if it hadn't been taken as nearly a given that it must. I also don't necessarily think all aspects of the SSPL are wildly worse than the AGPL (I think it fails DFSG/OSD as written, but not necessarily in a way that the AGPL doesn't), and I personally wouldn't be opposed to seeing a more blanket "it's OK to have copyleft requirements that trigger through arbitrarily strict conditions, as long as those copyleft requirements may always be satisfied by distributing full sources including all dependencies".
There are careful evolutions that may make sense to our definitions, to better serve the goals of FOSS; I don't believe that it should be an un-amendable definition. But I don't believe the principle that anyone can use the software for any purpose is a point we should compromise on. Even if you don't believe in that principle for its own sake (which I personally do), that point in particular is an incredibly valuable Schelling point; the most probable alternatives to it (which have been attempted) would run the gamut of random "cannot use for X" restrictions. It's far easier to agree on allowing all possible uses, insofar as people who dislike any particular use can nonetheless come to a consensus on allowing all uses.
> should be freely available
> software should be free for everyone to use
While I don't think you're necessarily intending to use these terms in an ambiguous manner, I think it's important in light of the point of this discussion that "available at no cost" was never the goal; "anyone should be able to get the source and modify" was the goal. Some people argue that "available at no cost" follows as a necessary consequence from that, but I don't think that's the case.
In terms of failures of vision at the time, I think it's notable that that goal didn't take into account how many people actually have the practical ability to take advantage of Open Source (taking into account both people with software development skill and people with the ability to pay others for software development skill). Those principles were absolutely developed by people primarily concerned with the practical rights of fellow FOSS developers, which to a first approximation they idealistically treated as "everyone".
> > There's been a massive push in recent decades towards permissive licenses
> Fair point. And I admit that this has made me stop and think about my choice of license for my own primary open-source project, AccessKit [3]. I was quick to permissively license that project from the beginning, before I considered funding. As it turned out, most of my development on that project so far has been funded by Google, which also specifically requested the Apache license (I went with the Apache/MIT dual license common in the Rust world). But in any case, I think a permissive license is actually the best choice for my goal with this project, which is to encourage and help developers to make as many GUI applications as possible accessible to disabled users. So yes, I want frictionless adoption above all else, but I think it's for a good reason. If a massive company used my project without paying me, I think I would consider it a net positive, because at least more applications would be accessible.
I absolutely agree with this. I believe there are extremely good reasons to use permissive licenses sometimes. Promoting standards (e.g. PNG, zlib, zstd); getting the rapid popularity to displace a prominent proprietary product; promoting important principles that are more important than the specific software itself (e.g. accessibility); any time you value adoption of something far more than any value directly accrued back to you.
If a substantial number of projects all use copyleft licensing, that carries much more weight than when fewer projects do so; it creates an ecosystem that people buy into and then gain much from. One library in isolation doesn't create a tipping point. It's not obvious if we can escape the equilibrium and attendant social pressures of mostly permissive licenses to the equilibrium of mostly copyleft licenses.
But in general, I do think that many projects just automatically use a permissive license, or automatically listen when a large company says they'd prefer a permissive license. Any time a company tells you that they'd prefer that you use a more permissive license, they're placing value on the licensing of your software, and that's value they may be willing to pay for. How much they'd be willing to pay is another question, but if you want to be able to sell alternative licenses you have to start from the baseline of a license that a company does not prefer and is not as comfortable with.
(As a Rust developer, I am sad that the norms of the Rust community strongly and pervasively push for permissive licensing.)