I think we need to be much more willing to consider software that's released with source available, but under a license that doesn't comply with the DFSG. (And yes, such software should be called something other than "open source".) Those guidelines aren't sacred, and neither is Stallman's definition of free software.
Ever since I read _Hackers_ by Steven Levy a few years ago, I've been much less sympathetic toward Stallman, and the MIT AI Lab hackers in general. If you've read _Hackers_, recall that Stallman also strenuously opposed passwords. Well, it's absolutely clear now that restricting access to computers with passwords (or something equivalent) is absolutely necessary to defend against bad actors. So we should be open to the possibility that, while widespread sharing of source code is good, some kind of restriction on the usage of that code is necessary to protect the developers from freeloaders. I'm sure we haven't arrived at the best way to do this yet, but we won't get there if we immediately reject all attempts because they don't meet a definition of freedom that's perhaps too absolute for the real world.
> I think we need to be much more willing to consider software that's released with source available, but under a license that doesn't comply with the DFSG.
Once that line is relaxed, even slightly, more licenses like this will start showing up and running battering rams against all the other parts of that line that prove inconvenient compared to proprietary licenses.
This license is proprietary. I don't care if there's source or not, it's still proprietary. It does not serve the interests of Open Source to compromise on its nature to obtain somewhat more quantity of a far lesser thing.
The unusual foibles and preferences of specific people who are firmly in the history of FOSS are not relevant factors here. The relevant factor is drawing and maintaining a strict definitional line, because if we let that line become even slightly porous, it won't hold up to the resulting assault that would invite.
> some kind of restriction on the usage of that code is necessary to protect the developers from freeloaders
Absolutely. For instance, requirements that others share changes they make under the same license.
There's been a massive push in recent decades towards permissive licenses, driven in large part by a combination of companies who find permissive licensing convenient and individual developers who project a certain counter-counterculture "do whatever you want, I don't want to think about licenses". We're now seeing the net result of that: many large companies actually using those permissive licenses as written, and not necessarily the ethos behind them.
MongoDB was licensed under AGPL – not a permissive license – when AWS started free loading on them. Copyleft licenses have shown themselves to be no panacea when it comes to exploitation from the multi-billion-dollar companies. If Free Software can't feed its developers, they will look for food elsewhere.
Copyleft licenses are an improvement. They do not universally force payment in every case where a proprietary license could, but on the other hand, would MongoDB have become as popular in the first place if it wasn't FOSS?
(And I object to the concept that hosting FOSS as a service is "freeloading". FOSS has always and only ever asked for giving back code, not money. Freeloading would be refusing to give back code, and companies regularly do fail on that front as well.)
> If Free Software can't feed its developers, they will look for food elsewhere.
FOSS can feed developers quite well. Some developers are deciding they'd prefer to sell proprietary software because they resent other companies benefiting from their work, and they're welcome to do that. What's not welcome is trying to claim the popularity benefits of FOSS without actually being FOSS; it is a good thing on balance that such efforts have met with chilly receptions.
There are many, many conversations going on about additional ways to fund FOSS development. The ones that have a hope of succeeding aren't the ones that start by abandoning FOSS.
https://www.gnu.org/gnu/thegnuproject - "Computer users should be free to modify programs to fit their needs, and free to share software, because helping other people is the basis of society."
] You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist. If you do publish your changes, you should not be required to notify anyone in particular, or in any particular way.
I agree entirely, and I do think it's important to only be required to give source to those you give binaries to. I just didn't want to nitpick that particular distinction here.
> FOSS has always and only ever asked for giving back code, not money.
Which is one of the reasons of disillusionment from them. On one hand, FOSS licenses only benefits developers who can fix the software to their liking – a non-developer user would likely just pay for it to make sure that they can get reliable, professional support. On the other hand, it assumes that the labour of developers is worthless (or at the very least, it's value is completely dissociated from its real-world impact).
> There are many, many conversations going on about additional ways to fund FOSS development.
Are any of them non-reliant on either the altruism of their users (donations, patronage, etc.), or selling value-added services that can easily be undercut by a party with deeper pockets (e.g., MongoDB vs AWS)?
Does that happen though? log4j developers were working overtime to fix the security bug [1], while corporation expected them to release the fix ASAP for free. Who was paying?
As far as I am aware, AWS never used any of MongoDBs source code. They implemented the MongoDB API. The license is thus irrelevant. AWS could have implemented the Mongo API no matter what sort of license it was under- it could have been entirely closed source.
Its no different than Google using the Java APIs in Android. The Supreme Court of the USA clearly ruled in Google's favor. It did not matter that the APIs were closed source software.
Further, I would disagree with using the term "freeloading" for some one who uses an Open Source program under the terms of the license in which it is offered. (Again, not even the case for AWS as pertaining to MongoDB).
Yes, they did, when MongoDB was licensed under AGPL. After MongoDB relicensed under SSPL, they release the API-compatible DocumentDB which is proprietary itself.
Sorry, I did some duck searching, maybe I am misremembering, but I can't find any evidence that AWS ever used MongoDB or offered it as a service directly?
> There's been a massive push in recent decades towards permissive licenses, driven in large part by a combination of companies who find permissive licensing convenient and individual developers who project a certain counter-counterculture "do whatever you want, I don't want to think about licenses".
I'm not sure permissive Open Source licensing is counter-cultural. It's just a way for developers to take from and contribute to the software commons as part of their commercial day jobs. It doesn't challenge the status quo any more than the journals in which other disciplines might share and grow expertise on new techniques which are not considered trade secrets.
More restrictive Free Software licenses can be counter-cultural since the virality of those licenses can prevent software being 'exploited' by commercial entities. But that counter-cultural label only really applies to communal Free Software. Open-core business models while valid aren't really of the same spirit.
The balance between permissive and restrictive Open Source and Free Software licenses in the software commons of an area ultimately ends up reflecting the developer time that each model provides. And whether a particular license is permissive or restrictive will depend on the company. GPL JavaScript libraries are pretty restrictive as using them would likely require you to share your commercial application code under a permissive license. GPL Linux is effectively permissive unless your business model involves selling operating systems.
I think we're mostly in agreement here. I was suggesting that FOSS itself was a counterculture (compared to proprietary software), and I was loosely describing the resentful "I don't want to think about licenses" (or moreso mocking people who care about licenses) as a conter-counterculture to that. I think that plays directly into the promotion of permissive licensing.
If I understand the synopsis of that article correctly, I don't think that concept applies here. Unless I've got my history wrong, our dominant standard for what's considered free software or open source, the Debian Free Software Guidelines (later repackaged as the Open Source Definition, wasn't the result of some kind of broad consensus among developers, users, and/or distributors. As badsectoracula pointed out [1] [2], source-available licenses with restrictions used to be more common. But Debian was always strongly aligned with the FSF's ideology; if I'm not mistaken, it was originally funded by the FSF, and of course, the full name of the main Debian distro is Debian GNU/Linux.
> The unusual foibles and preferences of specific people who are firmly in the history of FOSS are not relevant factors here. The relevant factor is drawing and maintaining a strict definitional line
My point is that this strict definition reflects nothing more than the MIT AI Lab hackers' elevation of their freedom (even at the expense of others, as in chapter 5 of _Hackers_) to an ethical absolute. Of course, most of those hackers outgrew that, but Stallman didn't, and he successfully spread the idea that all generally useful technical information, including software, should be freely available. And, if I'm not mistaken, that's where the DFSG came from. Since I didn't spell out part of my logic in my original comment, I will here: given that his nearly-forgotten campaign against passwords was obviously hopelessly naive, we should be open to the possibility that the same holds for the idea that software should be free for everyone to use.
> 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. But then, it's possible that by choosing a permissive license, I'm further poisoning the well, because I'm making more software available to freeloaders who would otherwise be obligated to pay someone (not necessarily me). FWIW, I'm thinking about developing an AccessKit-based module that has more of a niche use case (a screen reader for platforms or embedded devices that don't already have accessibility support), and for that, I might go with a dual copyleft/commercial licensing scheme.
> Unless I've got my history wrong, our dominant standard for what's considered free software or open source, the Debian Free Software Guidelines (later repackaged as the Open Source Definition, wasn't the result of some kind of broad consensus among developers, users, and/or distributors. As badsectoracula pointed out [1] [2], source-available licenses with restrictions used to be more common. But Debian was always strongly aligned with the FSF's ideology; if I'm not mistaken, it was originally funded by the FSF, and of course, the full name of the main Debian distro is Debian GNU/Linux.
The OSI (and indeed the whole open source movement) was formed explicitly as a counter to the FSF from people with a different ideological position. They were by no means temperamentally inclined to follow Debian; they adopted a virtually identical definition of open-source because it's the only one that works.
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 think we need to be much more willing to consider software that's released with source available"
I agree. The label 'source only' is considered a dirty word among some open source advocates. But if you are building a B2B (Business-to-Business) software product, 'source only' is a perfectly viable option to succesfully make a living from your product - one that isn't completely closed source (but one that clearly isn't open source). The source code of the product cannot be shared, but it can be modified by the customer to suit their needs.
The idea of 'source only' is not new at all. Back in the late 90s when Delphi was popular, many developers created and sold components to other developers (e.g. UI widgets). These components came with full source code of the components but they were not open source.
Fast forward to today, what are examples of 'source only' products doing well? Two examples: 'Kirby CMS' and 'Craft CMS' (Content Management Systems). Both are popular and profitable. Their source code is even published publicly on GitHub. The product creators trust customers will pay for the product (presumably some do not, but enough customers do pay so it doesn't matter).
Other developers are happy to contribute to the eco-system of plugins. So, yes, it's perfectly possible to build a community of enthusiastic followers for a 'source only' product that isn't open source.
WordPress is another example. Although WordPress is open source, the plugin market is full of 'source only' plugins for sale that are successful and profitable.
Source-only / source-available is great way to make a living. It also makes whoever purchases your software life easier.
But pretending to be open-source and accepting contributions from people who mistaken your project as open-source is problematic. Or, in another word, changing your license from open-source to something else because open-source made it popular in the first place is problematic too.
In most cases - source available is _de facto_ open-source.
You have two limitations on a product:
- "actual physical limitations": the fact that you have the source, and that it's not a brutally-difficult life/career-consuming endeavor to edit it.
- "artificial legal limitations": what the license says you can do
Typically the capabilities afforded by the latter are a strict subset of the former (legal freedom to modify is useless without the practical freedom afforded by the actual source — I could release something with the full rights afforded by an open-source license, but if I fail to actually upload my code, even if you're legally free to edit the binary, it's a mostly useless freedom). At the same time, it's very common for the legal limitations to be utterly irrelevant, whether it's a case of you simply breaking a law that's not relevant to you (perhaps from another economic sphere of the world, or maybe you're just poor — or something is abandonware and there's nobody to even pay, not even a publisher). In all of these cases only the physical limitation dictates what you're able to do.
--
If someone makes a freeware game, and it's abandonware — but it's source available, people can patch it so it keeps running on modern computers. They can translate it to other languages People can even fix egregious bugs. They can analyze it, and tease out internal mechanics and secrets, and document them on a wiki. If it's source-unavailable, then they're basically screwed.
Far from being hypothetical, what I'm describing is more or less how the entire rom-hacking community works — thousands of games have undergone this, where they've received unofficial translations, balance and bug fixes, etc. (I have at least a couple of personal favorites, where I had an RPG with certain abilities that infamously did nothing in the release copy, even though they supposedly applied buffs to your heroes. In a modded version, that bug was fixed and they fully worked as intended.) All of this is possible in the modding scene because this stuff existed in a state where something "awfully close to" the platform's source code was available in a non-obfuscated, direct form.
It's all illegal. All of it. That entire scene can't exist, legally, and survives on this wonderful, cockroach-like survivorship mentality of simply not caring that it's illegal, dodging lawsuits, and trading copies of things in defiance of takedown requests — which in turn happen so incredibly rarely that it may as well, practically, be legal.
--
Unix, for another great example, basically exists because "actual physical limitations" didn't restrict it — the devs made the source available, tons of people copied it in what was probably a rather illegal/gray-area way, and sure, some people kicked up all sorts of legal fuss about it (c.f. some famous lawsuits involving SCO group), but in practice the only thing that matters was the fact that it had illegally achieved ubiquity. At that point the genie could no longer be put back in the bottle.
I disagree. I consider practical limitations and legal limitations to be not be a subset of the other. They are separate, and the respective freedoms are both important.
And I dispute your claim that in the rom hacking community something "awfully close" to source code was often available. Plenty of times, mods are done using disassembly from the binaries. Disassembly is nothing like source code. Yet software patches based only on disassembly are possible, maybe even common. Source availability of course makes things easier. Documentation makes things easier still. Public version control of source code makes things eaven easier.
As a user of software, what are the benefits of something that is "source available" but not open source? Why would this be important to you?
I guess I can think of a few reasons. To help you learn how to use the software better than just from vendor-provided documentation? To help you find bugs, instead of relying on the vendor to do that? (when you're paying for software, these are kind of things one hopes one is paying for the vendor to do for you so you don't have to do it yourself, but we all know that hope is not always bourne out...)
What are the actual reasons people are interested in this, over ordinary "source not available" software distribution/licensing? These above, other?
Source available doesn't mean that you can't do anything with the code, it usually means that there are limitations (e.g. sharing it) with what you can do with it.
There are a lot of cases where "source available" expects you to modify the code and even share patches with others. A popular example nowadays would be Unreal Engine 4, but it isn't anything new - Borland's OWL was distributed as source code and you need a license to use it (it is part of C++ compilers so any of their compilers would provide a license), but over the decades there have been improvements made by its users in the form of OWLNext that is meant to be installed "on top" of OWL (ie. wont work by itself).
OK, so the reason you are interested in this is for the ability to write, share and use patches that can be used by those who pay for a license to the code, to be able to add features without having to rely/wait for the vendor to do so?
Yes, while it is certainly worse than full Free Software from a community perspective, it is still much better than closed source commercial software since you are at least in control - even if the developer shuts down or abandons the project, you are still able to fix bugs and improve the program (you or anyone else who decides to distribute patches - assuming the license doesn't explicitly forbid that, but it'd be pointless to do that IMO, not that some didn't try it). And if you ever decide to move somewhere else, you can still get your data out of the program (modify it to dump to another format or just use the code to make your own converter) so you're not locked in either.
"Source available" was also common in earlier Unix systems, e.g. an once popular image viewer called "xv" was basically a shareware program distributed as source code. People even wrote patches for it.
The problem with absolutism: it ignores how trivial it is to copy and deploy a lot of modern programs. Condemning licenses which protect against juggernauts like Amazon leaves no middle ground between free software and proprietary software.
Purely for practical reasons, I tend strongly toward using FOSS in all companies I've worked for. Ideology aside, if the authors go out of business or drop support, I can still support it myself (or pay someone too). From that position, I don't see a lot of middle ground between FOSS and proprietary: either it's FOSS or it's not. I don't mean that harshly, and it's not as though I flat-out wouldn't use proprietary software. I certainly wouldn't judge others who do. It's just that I see non-FOSS software as a significant risk that has to be mitigated, perhaps by limiting its use to cases where it'd be inconvenient if it went away, as opposed to a company-ending event.
I don't think that absolutism, which for me carries a connotation of purity or dogma. For me, it's a pragmatic choice. For me, software using this license doesn't have an advantage over other proprietary licenses. I view it as regular, commercial software with an trial discount. Which is OK! That doesn't make it bad!
> Ideology aside, if the authors go out of business or drop support, I can still support it myself (or pay someone too).
If I'm not mistaken, the intention with newer licenses such as this is that developers still release the source; they're just not allowing unrestricted free use. So if they go out of business or drop support for that code, user can still continue maintaining it, at least privately. Meanwhile, the fact that the authors are getting directly compensated for the software makes it less likely that they'll go out of business or drop support.
The availability of source makes a big difference, doesn't it?
> The availability of source makes a big difference, doesn't it?
It helps a lot, but it's not sufficient by itself. Am I still allowed to use the software if the company goes away? Can I distribute it to my customers? Can I deploy it on servers it's not already deployed to? With FOSS, the answers are clear. Some commercial software also has clauses like "if we cease to exist, your license reverts to the terms of the MIT license" or such.
Yeah, having the code become permissively licensed if the original developer goes out of business seems like a good compromise.
That said, we can't make policy decisions based solely on what leaves one group (in this case, the users of abandoned software) better off in the hypothetical worst case. We need to balance that with what's fair for everyone (particularly upstream authors in this case), ideally avoiding that worst case if possible.
I get it. I do. It's just that, for me personally, this isn't any better than say a Microsoft license. Years ago, I would've described it as shareware. In fact, I still might.
Steven Levy is writing what I would consider historical fiction, but let's pretend his story is true. Context matters.
Whether passwords are necessary depends on context. Many family computers don't have accounts or passwords, and it works fine for the same reasons most houses don't have bedroom doors which lock. People are trusted to not be bad actors.
The early AI Lab was super-open, and it worked fine. Everyone knew each other, and there weren't (m)any bad actors. Part of the reason MIT CSAIL doesn't work as well is that it closed itself off.
That's very different from a 2022-era computer facing the public internet with billions of potential attackers.
That post is a word salad of unsubstantiated vague name-calling.
> In the most intuitive case, the fact that the maker of a product, service, or program needs to recoup costs or earn fair compensation becomes irrelevant, if not overtly despised.
The classic "Open source will never be popular, because people have to get paid" argument.
> Software people, and their progress, über alles. ... Utopian communalism on the supply side, among programmers
So free software developers are literally Commie-Nazis? Got it.
> Often these strike a borderline millenialist, free-in-the-promised-land tone.
Oh, and religious extremists too, I see.
> The usual rules about permission, compensation, respect, and so on don’t apply, insofar as they’d apply to those making software.
Also, people who use free software are all thieves and pirates, apparently.
Many of the most useful open source projects are corporate driven. The only thing holding those companies to the usual set of licenses and provisions rather than something that would be much less open is the Schelling fence of the “open source” definition. Throw the door open to a thousand different idiosyncratic licenses and they too will abandon Apache, BSD, and MIT.
The reasons corporations lead open source projects is to undercut their (potential) competitors by commoditising their complements. OSI licenses are used in such projects because they allow the businesses to achieve the above.
Open-source has started to become a weapons in the arsenal of Goliath against the David who may want one-day challenge it. If your only agenda is being free to fix your printer'a drivers [1], that may not be a deal-breaker; but many others are looking at something that provides justice alongside freedom. [2]
Seems like a strange attack against (eg) GPL. Stallman is completely odd, but GPL's aim has nothing to do with developers and everything to do with users: Let users know and control the software they're running on their computers. This is a real world issue, even if you don't think you need it.
This does have varied ramifications for developers, but all designed to prevent a downstream removing rights for a user to access the code running. And that's great, irrespective of your or my views on the chap who instigated it all.
The way I see it, Stallman is an end user freedom maximalist with end user roughly meaning person sitting in front of a computer using software. Thinking like this, any obstacle blocking a user from complete control of the computation on the computer is evil.
This of course completely disregards the notion of computers having owners.
Unfortunately, we are currently way way in the other direction, with owners being deprived of control over owned devices by manufacturers and vendors.
Are you claiming those lawyers are pulling problems out of their [..], or do you accept that there might be very real reasons for embargoing GPL, especially with many lawyers from many companies doing that?
I'm saying there's already a very obvious, decades-old established solution to the problem the parent commenter is raising. It's just an unpopular solution with devs on this board, because they actually want to be able to keep ~~freeloading~~ er, re-using community contributions at their well-paid jobs.
Ever since I read _Hackers_ by Steven Levy a few years ago, I've been much less sympathetic toward Stallman, and the MIT AI Lab hackers in general. If you've read _Hackers_, recall that Stallman also strenuously opposed passwords. Well, it's absolutely clear now that restricting access to computers with passwords (or something equivalent) is absolutely necessary to defend against bad actors. So we should be open to the possibility that, while widespread sharing of source code is good, some kind of restriction on the usage of that code is necessary to protect the developers from freeloaders. I'm sure we haven't arrived at the best way to do this yet, but we won't get there if we immediately reject all attempts because they don't meet a definition of freedom that's perhaps too absolute for the real world.