The core concept hasn't changed. We have a lot more data about what works and what doesn't. Back in 2002 funding for development tool companies and open source companies was non-existent. Git or github didn't exist. Things changed.
easy for software to commoditize hardware... hard for hardware to
commoditize software. (Spolsky 2002)
Linus effectively killed the golden goose of writing OSs, a
super-difficult task that deservedly propelled Gates and Allen to the
stars.
All it takes is a college kid and a laptop to ship software. I
wouldn't know where to start building and shipping chips and circuit
boards. And that's why Azure, not Office, is where Microsoft's placing
its bets.
RoboVM tried to close the source but they made a release of a version that still had the GPL license attached to it. They didn't commit those sources to the public git.
They had to release those sources after the fact because they didn't change the license in the general release.
That's interesting, though if you're the copyright holder and didn't complicate things with contributions from outsiders, dual licensing is fairly easy. That is, you're free to have both GPL and proprietary code mixed if you control all the contributed code.
The article makes it sound as thought their own license forced them to release their own code. This could have only happened if the project had outside GPL'd code integrated into it, but then they wouldn't be able to legally change the license without removing that GPL'd code.
1) RoboVM had to use the GPL license because they used other people's GPL code - which they presumably pulled out / rewrote themselves in their new closed-source version
or
2) the author mistakenly believes that RoboVM is bound to the terms of the GPL license, or forced to offer new GPL licenses, on code they own 100%, just because they have offered GPL licenses to other people in the past
3) They released a binary and included the GPL license as part of the binary release licenses thus committing to the GPL in that release while not making the code available.
If they owned 100% of the copyright, then it still wouldn't matter. The GPL gives additional permissions, along with some restrictions / obligations, to Licensees. As copyright holder you are not a Licensee.
You do not need to grant yourself a license to distribute your own works. You always had that right.
Besides, who would sue you? The only person who has standing is the copyright holder. You're gonna sue yourself because you failed to honor the terms of a license, which was granted from yourself to yourself?
I know plenty of people who do open source consulting professionally, (in an ethical fashion). I myself did it briefly (not really my thing)
Yes predatory people and scammers exist. But lets not dismiss an entire field because some people are assholes.
Also, i have no idea what the bait and switch the author is talking about is. Did anyone really think that google open sourcing android meant that it was open sourcing the entire android ecosystem? There has to be an intention to mislead for it to be a bait and switch. Someone doing something you dont like is not a bait and switch unless they try and trick you.
Selling consulting is hard... You need a whole sales org and if not, a salesperson personality. This often clashes with the hacker mentality and requires different disciplines. I would say this doesn't sell "easily" like a SaaS would.
Of course its "hard", if it was trivial nobody would pay you to do it. And you are right, the skillset is different from pure dev. However, you don't need a "sales org" to do it. Plenty of people do it by themselves or in a small company of a couple devs and an administrative assistant.
here is a preview for you -- for three or four years after being a thirty year old hot-shot on some current in-demand tech, yes.. great life consulting.. fast forward ten years.. "people over 35 should consider retiring" and no consulting.. at the same time, massive, huge outsourcing to the lowest wages, for newer tech stacks, and maintenance mode for lots of things that were current.
Don't chase fads if you want stability (for that matter, chasing fads is bad if you want to be a rockstar too - its like going to the goldrush after everyone has already flocked).
Anyways, as a php dev, i can assure you im not working on whatever the popular trend is right now.
Chasing the fad of COBOL undertaken right now, I think, could help one bring home some bacon for years and years.
Certain tech stops being a fad but stays entrenched and in a certain, while not overwhelming, demand. Hiring for PHP and C++ jobs will continue for a loooong time.
Oh, i guess that makes sense. Its weird how they tie GPL into it, because unless they accepted third party contributions the story would be exactly the same with a bsd license.
Been saying this privately for a long time. Agree on "GPL is the best choice," as well. My personal experience with devs who don't want to GPL their code or contribute to GPL projects is that they're under the impression that having a permissive license on their own project will get $corp to use it and, somehow, they'll profit from $corp using it. Haven't personally seen it yet, but I have seen a bunch of permissive licensed stuff get pulled into bigger projects and changes never contributed back.
GPL is still a questionable choice for anything that can be turned into a SAAS app. Remember if you dont distribute the binary, you dont have to distribute sources.
This is a good point and I'd like to suggest (without being certain) that the AGPL is a good solution.
> The GNU Affero General Public License is designed specifically to ensure that ... the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.
Imho if you're ok with the GPL v3, the AGPL v3 is almost always the better choice. The spirit of the GPL is "if you change it for anything other than internal use, you have to distribute the changes", and the AGPL just logically extends the enforcement of this to services provided over the internet.
The AGPL v3 and GPL v3 also contain provisions to make them compatible with each other (resulting in AGPL terms for the combined work, but the GPL parts remain GPL).
FWIW, i dont like the ambiguity of what is "configuration" and what is "code". I feel its a bit unclear.
I also think its a bit problematic taken in the absolute, sometimes you have security patches you want to deploy and test out for a week before making the issue public, or perhaps emergency patches for sudden (downtime causing) issues.
I don't think the nitty gritty details of the AGPLv3 matter much in practice. Those details matter most to the sort of organizations that fear lawsuits and consult with lawyers, and such organizations will likely not use AGPLv3 licensed code at all.
AGPLv3 is thus a de facto 'hobbyists only' license, and hobbyists by in large don't go around suing each other; generally they just make good faith efforts to respect each others licenses and maybe use social ostracism when somebody steps over the line. Since hobbyists don't take their community disputes to court, the technical legal minutia of the license doesn't matter to most of them.
I still think details matter because it helps determine what is good faith following the license. Ambiguity also helps spread fud, which makes it harder for big companies to contribute and reuse such software.
As a corporation, I might not want to use it in conjunction with my code, but that's the point. You are free to do what you want, but you in turn must share your code.
Or you engage with the owner to make a financial arrangement for a separate license.
that's not right. in my understanding the intention of the AGPL is to share code with users of a program, even if the users didn't get a copy of the program.
therefore the AGPL shouldn't force you to share code if the program runs on a server. but it should force you to share code if the program can be accessed by a user.
this may even apply to running something like a kiosk device where users interact with a program on a device they don't own.
Right but which freedom does that restrict that's not in the spirit of the gpl?
I.e. the gpl prohibits you not sharing code if you distribute the binary. What is the philosophical underpinning of "sharing binary" not being a restriction but "ethernet" being a restriction.
The evil thing is not similar because you are discriminating against a field of endevour (similar to licenses that say educational use only, non-commercial only or non-military only). It seems to be a very different type of restriction.
>> As a corporation, I might not want to use it in conjunction with my code, but that's the point.
I've worked for several large corporations and were in the throes of a major project. Using an Open Source tool would've cut a lot of our dev times by many hours. Three out of three times, all three team leads and managers said "no" to using open source. We had to build several large components from scratch, which did lead to extended development timelines, a ton of working late at night and several "crunch" weekends.
Their rationale? They didn't want to have to maintain a piece of software that was open source. The resounding opinion was it was "dangerous" and not safe - because someone could check in a malicious piece of code and that could end up in our very large, enterprise application when we needed to update it. Nobody wanted to be on the hook if that ever happened.
In the end, it seemed like it was more about upper management types playing CYA instead of trying to put out a solid product.
Am I mistaken in believing the only additional requirement of the AGPL is, in layman's terms, that if you operate the software as a paid service you must also release the source code of any changes that you apply to it?
If that is the case, I don't see how the AGPL qualitatively infringes on any "freedoms" that the GPL doesn't already restrict: you must keep derivatives free. Of course one may argue that the GPL is nonfree when compared to BSD/MIT style licences, in which case fair enough.
The justification usually given for AGPL is to prevent other companies from running paid SaaS without sharing their modifications. The actual terms is that any user who interacts with the software over the network must be able to download the sources. It doesn't say anything about whether the service is paid or free.
I think the argument of FOSS people who don't like it would be something like, as a user, just running the software on my machine can potentially create a legal obligation to set up source distribution, if, like, I forgot to block a port.
Ah, I was unaware that it applied regardless of it being a paid service or not. I imagine that would be somewhat analogous to distributing binaries of modified GPL software for free without providing the sources.
In any case, does the AGPL requirement to provide sources apply even if you are running an unmodified version? In other words, would merely pointing to the original repository not be enough?
Regarding the risk of accidental legal obligations, I suppose it depends on the details and technical wording of the licence.
If the requirement broadly covers any use of the software on the machine (e.g. some backend service that happens to help your public webserver to stay online) I can see the discomfort, especially if one must explicitly provide or link to unmodified sources too.
On the other hand though, if the requirement is limited to actual provision of the software's functionality to 3rd parties, I would argue that if someone accidentally provides it due to forgetting to block a port then they have much bigger problems than the AGPL.
if you get notified of a security breach caused by your own incopetence, you secure it. which would effectively be the highest harm apgl can inflict on you already: stop hosting the service. which was your point all along.
i think pointing to an upstream repo is probably enough in most cases provided you can link to the right version. but what do you do if the upstream repo disappears?
for a popular program that's not very likely, but lost source code is the bane of software development, so hacing your own version available would be better, at least as a backup
> just running the software on my machine can potentially create a legal obligation
Not true: only if you made local modifications.
> I forgot to block a port
Also not true. You have plenty of time to close that port.
"""your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice."""
If you expose services on the Internet by mistake you are going to have 1000x bigger problems than the risk of being sued successfully for a honest mistake.
Personally, I am much more wary of the definition of "interaction" than of unwillingly distribute the software. The later one is a fault of the person accessing my computer against my will, not mine. But I have no idea how far "interaction" can be stretched-up, is using your software equivalent to signing some NDA? Hell if I know.
That said, FOSS authors normally aren't the kind of people that pushes to those crazy maximalist interpretations of documents. So if any risk exists, it's not large.
I would say GPL constrains some freedoms of the code users to provide some freedoms to the end users.
It's not entirely clear what counts as derivative work with regards to GPL. There is a lot of corner cases and workarounds in the real world. It becomes even less clear when you widen the definition of distribution.
Do you mean you believe it doesn't comply with the Free Software Definition and/or Open Source Definition, or that you believe it does but that it's nonfree anyway (or in other words, that you disagree with those definitions)?
> Many people find the AGPL to be a nonfree license, myself included.
I don't understand this stance.
From the point of view of the user, the AGPL offers the same freedoms as the regular GPL. If you use the program, you have the right to see and edit its source code, regardless if the program runs on your own computer or on another computer.
How can anybody call this feature "nonfree" is beyond me.
Not really, the vast majority of users of these kinds of software run it unmodified, the valuable stuff is around it. (If that weren't the case, MongoDB hadn't come up with their own "give us everything!" license because AGPL was too "weak")
One of the important definitions of Free (capital F) software is the freedom to modify it without restrictions.
If you're just talking about the freedom to run things unmodified, basically every software you can download online without paying is "free", and obviously AGPL fits that bill for the uncapitalized "free" software. But that's not what we're talking about here, right?
If the freedoms is your angle: And a large point of the GPL family of licenses is to make you publish your changes so your users can run and further modify it, and AGPL is a logical extension to that for a world in which users rely on software they don't personally run. So that their important freedom of being able to run and modify software they rely on is preserved. If you get to keep your changes, your users are deprived.
The situation is funny that AGPL is widely derided as both being to weak and being to strong.
As an open source project 'owner' my personal experience is similar i.e. nearly nobody of the companies contributes back. Often times you are not even allowed to talk about their usage.
But still, I think the permissive license we picked was the better choice. Especially after our company was formed and we want to use the project for ourself too the (A)GPL would make the community working together with this harder (CLA, dual licensing?)
IMO a permissive license is better and easier for the developer and the GPL is better for the end user.
But even the GPL does not grant you anything without a lawyer :) E.g. I tried to get the GPL source code from Waze (tried it multiple times!) and got a reply:
"I've looked into your concern and determined that it needs some extra attention from our end."
See also https://2jk.org/english/2014/03/27/israeli-waze-hit-with-gpl...
> Especially after our company was formed and we want to use the project for ourself too the (A)GPL would make the community working together with this harder (CLA, dual licensing?)
In this scenario, your company is the thing GPL is trying to protect your community devs from (i.e. the gpl is trying to stop a company from taking contributions donated on the condition they would be open-source, and selling them privately without compensation). You are basically saying the GPL makes it harder to do the thing the GPL was trying to stop.
The GP wants to donate some software to the community, on the condition that he gets to use any derivative community work on his product. Anybody contributing to the code is clearly informed of that, and decides to do it out willfully.
It's a perfectly reasonable arrangement that adds value to both the community and the GP, and that the GPL "protects against". So, yes, the GP's point stands in that there are uses for licenses other than the GPL. All of the complaints about they only being good for people creating proprietary software are true, they just completely miss the point.
To clarify, i dont think that GP is morally wrong or anything (as long as they are upfront about what they are doing, although it can get morally questionable fast if they aren't careful). I guess the point i was trying to make is its weird to describe that as a flaw of the GPL when its basically the primary use case .
The morally questionable situation is where you publish code under GPL, allow community contributions on the code on the condition that the community contributors sign a document transfering copyright to you (without payment or anything like that) and then also use those community contributions in a closed source product you sell.
> The GP wants to donate some software to the community, on the condition that he gets to use any derivative community work on his product.
wat
That's exactly backwards. Releasing your donation under a permissive license doesn't give you that. A permissive license gives others express permission to make derivative works that the original author company might not be able to use themselves—because there's no obligation for others to keep it open...
> IMO a permissive license is better and easier for the developer and the GPL is better for the end user.
A permissive license is only better and easier for developers of proprietary software. The GPL is better for developers of free software and for end users.
I agree, though I think there's an irony in the mutual incompatibility of many FOSS licenses. For instance, try making a GPL project that depends on a data file licensed under Creative Commons. One's best bet in such a situation is to ask the rights holder to release to you under a compatible license, but people (and institutions) are generally reluctant to do so.
Two permissive licenses, one headache for the FOSS dev.
> But still, I think the permissive license we picked was the better choice. Especially after our company was formed and we want to use the project for ourself too the (A)GPL would make the community working together with this harder (CLA, dual licensing?)
Regardless of license, most software projects are either community projects, or corporate projects, but not both. Corporations rarely see fit to invest in the development of a project they're using because some other chump is giving it away for free. And volunteer programmers rarely want to deal with submitting commits to a project with corporate managers who are focused on the needs of the organization and see volunteer programmers as out-of-the-loop nuisances.
Whether you're a corporation open sourcing something to get free community labor, or a volunteer open sourcing something to get corporations to contribute, you'll probably be disappointed.
> IMO a permissive license is better and easier for the developer and the GPL is better for the end user.
users don't care, they aint taking the code for changing.
Arguably it also doesn't matter till you are corporation closing the code for profit. If all you do is OSS and are used by people that also release OSS, extra protection GPL gives are not useful. But of course real world is not that idealistic.
And for that of course BSD/MIT is better. No facility for anyone to get anything out of you so you can take and take without ever giving back aside from occasional bug report and outrage over someone having a bug they didn't fix in project they are not paid to develop in the first place
GPL gives one guarantee - that the code you give will not be closed down for money and used to save some corporation some dev-hours. Some devs don't like it because it is making their life difficult (and I'd also argue anything higher than LGPL for stuff like libraries is kinda pointless), but that's kinda the point.
GPL explicitly allows commercial usage. E.g. I take take your GPL code and create a SaaS around it and make a lot of money or I can create a consultancy service around your GPL code.
My single biggest incentive when I'm writing open source code is that I want to NEVER have to solve the same problem again, for the rest of my career, no matter who I am working for in the future.
That's why I chose the license that seems least likely to prevent me from being able to use the code I've written (currently Apache 2).
I think the parent is alluding to a situation where their employer has copyright for the code written on the job. If you take your own previously-written code and just "submit" it to the codebase, you've created a legal snafu for yourself if you ever want to use that same code again elsewhere.
Of course you can take your code and license it to said employer in whatever way you both agree on. But this is going to be much easier if the code is already publicly available to everyone, with a known license: the employer doesn't need to even care really who the author is, just the license.
for the same reason in one job i was able to change my employment contract to include a guarantee that all code i write on that job will be released under the GPL
i thought that way i would always be able to use the code in my own FOSS projects but i would also not be able to sell out and make my work proprietary (since it would contain GPL code owned by my employer)
this may seem less beneficial than an apache license but it was aligned with the company goals as far as my work was concerned, so i essentially had them put a verbal promise into writing, and i thought it was a neat way to commit myself to FOSS
Makes sense. There are two broad classes of code, actual standalone projects, and handy code you don't want to rewrite at each job. The latter really fits BSD or Apache - you're trying to break down as many barriers to use as possible and you aren't concerned about receiving contributions.
I don't think that's necessary, though. As the original creator, you're the "owner", not a licensee.
As the owner you reserve the right to re-license it to anybody you'd like, under any license you'd like, as long as you don't give that right away.
At a job, or on a contract, the employment agreement or the contract will almost always says you're giving that right to them in exchange for compensation.
> My single biggest incentive when I'm writing open source code is that I want to NEVER have to solve the same problem again, for the rest of my career, no matter who I am working for in the future.
You can tell your company to either buy a proprietary license from yourself or reimplement the whole thing.
> My personal experience with devs who don't want to GPL their code or contribute to GPL projects is that they're under the impression that having a permissive license on their own project will get $corp to use it and, somehow, they'll profit from $corp using it.
I don't think i've ever heard someone saying this. Does anyone really believe this? Some concrete examples would be illuminating.
For me the logic roughly worked out like this. I managed to get successive employers to "sponsor" (i.e. pay me my normal salary but let me use my work time to work on my open source project) my open source project, because we were using that project at work and it was missing features my employer was interested in.
Some of those employers had policies outright prohibiting GPL use...
I choose BSD over GPL because I want myself and others to have the maximum utility of my work. demanding downstream users coordinate that work with me doesn't really support that goal for either of us.
The case of Linux vs *BSD is probably the largest-scale test of efficiency of GPL vs permissive licenses on stuff contributed back. It also looks pretty decisive, too.
I think it is dangerous to look at this too much, there are other reasons that Linux got off to a better start not directly related to the license. Such as some rather serious lawsuits against FreeBSD in the past, that hurt adoption in the time Linux was getting up and going.
But yeah it is true that Linux is much more efficient at getting stuff upstreamed, I think Sony has sent more patches to Linux than FreeBSD and the PlayStation runs on it.
The only problem I have with GPL is that I don't want to use "or later version" (as I don't trust all future FSF leaders), but it's illegal to link GPL V2 and V3 code, and I would expect the same problem will arise with a future V4.
There's also the path that--even if you have a permissively licensed project--$corp will see your thing, like it, and decide to just copy it, to overall avoid having to deal with dependencies they do not own. In other words, a lot of places are unwilling to play in anyone else's backyard. They "support" open-source, but only when it's on their terms.
They might even call you, under the pretext of a job interview, and of course they want to discuss in detail the most significant project you've worked on! But you find out there are all kinds of awkward conditions on the job offer, like a cross-country move, or much lower pay than you were expecting, or no actual commitment that you'd be working on your project but just a vague, verbal statement that you could continue "during 10% time". You'll have to interview three more times with 15 more teammates. Everything gets dragged out for months and then you see them announce their own project in opposition to yours.
That is, if anyone pays attention to your project. Most open-source developers are categorically averse to anything resembling advertising. Try building a thing and then posting about it on a topic-appropriate sub-Reddit. So many of them will delete your post or ban your account from the sub for "spam".
The vast majority of the market--including other open-source developers--want open-source developers to write code, shut up, and go away. The minute you start talking about maybe wanting some remuneration for your efforts, you're suddenly "ungrateful" or "shilling" or "spamming" or "selling-out". (EDIT: It's happening in this very thread, further down the page)
> My personal experience with devs who don't want to GPL their code or contribute to GPL projects is that they're under the impression that having a permissive license on their own project will get $corp to use it and, somehow, they'll profit from $corp using it.
A lot of big corporations will not allow GPL dependencies to be used in their codebases, and not having a GPL license will definitely make software more usable by those corporations.
How the developer expects to profit by giving something away for free is definitely a mystery, but there is also some truth to the idea that a GPL license does scare companies away.
The GPL solves very few problems nowadays, because most software isn't distributed anymore. The AGPL solves a specific issue: a company is running an undistributed, modified version of the code, which is accessed by end-users, that gives them a business advantage.
Elasticsearch is a good example of a problem that isn't solved by a different license. Amazon is running essentially unmodified versions of elasticsearch, which competes against the business model of the company building elasticsearch. Even with an AGPL license, elasticsearch (the company) is not going to be making any money.
If a company isn't interested in upstreaming changes, it probably won't help that they're using an AGPL license. If the code isn't user-facing, the license won't force them to make their changes available. Even if it is, often changes a company doesn't want to upstream are very specific to them and aren't useful to others. Even if it's business valuable, and the company makes the changes available, they won't be making it easy to integrate.
The AGPL, more than anything, places a burden on users and developers, and reduces the community size. Most companies don't allow the use of AGPL software, and in the cases they do, they often only allow its use in an unmodified way, or only allow modifications if it isn't user-facing.
That was our main reason for scrutinizing AGPL libraries at $previous_job. IIRC our biggest concern was over iText (Java PDF library) and other libraries that depended on iText. In our case, we ended up not having to modify anything and were fine, but if we did have to modify, it'd have been to include trade secret features, which are a non-starter for distribution!
It's a nasty, complicated situation with bad actors on both sides.
You're probably thinking of SaaS, but, still, what?
I'd argue we distribute software much more than say 20 years ago. Almost every web site you view is distributing non-trivial software (javascript, from maybe a dozen npm packages). App stores are making software distribution much easier for the average user. Programmers are increasingly using dependency managers to download libraries. Even every SaaS service is getting their software from somewhere, and the tech stack is increasingly complex these days, which means even more software being distributed and used.
Perhaps what you mean is "software isn't sold anymore", so the money is all in the services. Which is probably true, and this is probably where GPL is becoming irrelevant.
But then, it can be argued that the services model was in part the industry's response to the prevalence of GPL, which pushed businesses to find workarounds. People need to make money, and if software sales isn't generating enough dollars because GPL software pushes down the prices people are willing to pay, then they'd just invent reasons for users to buy services instead. -- which, if true, could be interpreted as a success story for the GPL.
You have to truly hate people to license a library using anything but a permissive license, especially in the javascript ecosystem. Nothing ruins your day quicker than finding a transitive dependency with a copyleft license.
Maybe I should have been clearer. Most actual products based on OSS aren't distributed anymore. They're SaaS. The majority of the most popular app store apps are clients to a SaaS product.
The bit about how GPL "forced" a company to release its own source code is obviously false. If you release your own software under the GPL, you can't be forced to do anything, this only applies if you integrate third party GPL code. For your own code, you retain full copyright, and by definition the license you yourself applied cannot force you to do something you don't want.
This is a fundamental misunderstanding about how copyright works, the author could have closed the source completely without changing the license, because the license only applies to third parties trying to use that licensed code, not the authors.
Can we please not start having all our blogs use creepy DALL-E garbage as the cover art. This is going to be really shitty if all the blogs have distracting uncanny-valley bio-morphic junk splashed across their titles.
A lot of blog templates, as well as tools that syndicate blog content, require some sort of image. They'll take the first image they encounter, no matter what it is. If you want to avoid it being some sort of sidebar glyph, or the page looking wonky, you have to supply an image. What image would possible have fit this article? And so we end up with AI-generated filler.
That doesn't make it desirable, but I hope it helps to explain it.
Are you saying you would prefer all blog posts to be header by the same undifferentiated photo of a blue sky? I'm not quite getting what you're saying here.
I mean, if a person is only ever going to write a single blog post, then yes, absolutely, post a personal photo of something beautiful. Why not? But if a person might post more than one blog post, then presumably there's some motivation to tying each (required) photo to the post in question in some way, even if tangential, right?
perhaps you're being a bit pedantic here? You are well aware that one can iterate on the "take a picture of anything, every time you make a blog post!" theme, you don't need to compel me to spend my time telling you that. There's surely more productive ways to spend one's time.
> "take a picture of anything, every time you make a blog post!"
If you're saying one can actually find things relevant to my blog posts by doing that, I'd love to hear more. Because it doesn't seem plausible to me.
Using AI images isn't really as easy as one may think. It takes a couple minutes to generate a large image, and sometimes the AI messes up. A couple iterations later, you've already used 20 minutes. If I could generate better images with a camera pointing at random things around me, please enlighten me on that.
PS: I don't think anyone is compelling you to reply -- you chose to do so.
> Big corporations aren’t benevolent - the advocacy I see around OSS projects from FAANG (MAANG) companies is problematic. They don’t support OSS. They use and leverage it.
How is this problematic? For most of my career, I also haven't supported OSS -- I too use and leverage it.
Open source is relatively simple: it does what it says on the tin. If you make something freely available under a non restrictive license, you no longer own that thing. Sure, you may retain some copyright, but you've given it away. Why are people always surprised when those free things are leveraged? Is everyone truly this naive?
GPL, AGPL, BSL... they all solve different problems. There's no right answer. If you're building something and want to make money, then it behoves you to choose a license that strengthens your position to make money, rather than introduce a vulnerability.
> GPL, AGPL, BSL... they all solve different problems. There's no right answer.
While there are legitimate arguments in favor of different open source licenses, the BSL is a proprietary license and is always the wrong answer. I'd agree with this if it used a real open source license like Apache or MIT as its third example instead.
And well the other BSL (Business Source License) may be appropriate for proprietary software that you want to be released under a open license at a later time.
Although I am also not really aligned with the idea on a ideologically plane.
> FOSS goes beyond throwing some code on a forge and slapping a license on it!
It literally does not. Please refer me to any definition of Free and Open Source Software that refers to anything beyond the text contained in the license. Please stop spreading such woefully sore interpretations. This is exactly how you burn out authors and maintainers.
> A lot of companies do astroturfing by creating a false impression of community, cooperation, openness and decentralized development.
I've said it elsewhere, but these elements do not inherently have anything to do with Open Source. It's beyond foolish to presume them.
> Later on they add CLAs, switch to open-core or use other tricks to strictly control development and use.
If this bothers you (which it shouldn't) then perhaps consider an alternative licenses which restrict the ability to monetize without releasing source, such as AGPL.
Licenses are being wielded as per their lettering. This is a good thing, generally. We all benefit from Open Source regardless of CLAs or open-core.
CLAs are primarily there for legal protection. An alternative is a DSO, but legal teams tend to be a bit hesitant to allow them. Everyone dislikes CLAs, including companies that use them, because they make it more difficult to accept changes.
Open source, historically speaking, is an implied social contract:
I as the developer do something nice for the world. I therefore hope that you, as the user, will pay it forward.
When this ethos is subverted by people who don't pay it forward, who just see "Free!" and unthinkingly take and take without ever thinking to give anything back, it rubs people the wrong way.
"Open Source", historically speaking, was the right (and obligation) to have the ability to modify the source code of software you use. There was nothing about 'paying it forward', but rather giving users the freedom to control the software they run.
The parent comment to your's has been my understanding (using FLOSS since last year's of last millennium), why do you find it not to be true that there was an implied social/moral contract with free-libre software?
Because there was never an implied social/moral contract. If you want something, put it in the license. Don't shame people for adhering to the letter of the license.
Do you have any written evidence that this was a commonly accepted "social contract"? Because I've been using FLOSS since last year's of last millennium as well and I've never heard of such attitudes until recent years. (Even today, I rarely see OSS project leaders actually saying they expected all users to give back something -- it's mostly other users who somehow assume everyone else needs to do so. And if I may say, making presumptions on the intentions of OSS developers is a bit... presumptuous to say the least, even if well intentioned.)
One of the few "giving back" contracts I'm aware of is the GPL. Which explicitly states in the license that you need to open source your modifications if you distribute the binary. Vim nags you a bit to donate to Uganda children, but that's explicit as well.
You demand evidence, implicitly, but give none ... calling something revisionist (suggesting purposeful misleading, ie lying) without any backup is, um, a bit unfriendly. Maybe it was just that people in projects I came across followed that pattern of share-and-share-alike?
>Even today, I rarely see OSS project leaders actually saying they expected all users to give back something //
I've never seen it _demanded_ of anyone. Also, I think it largely went away in the early 2000s, as more, varied licenses came online bringing OSS a much broader base.
Pay-it-forward seemed to be a growing movement across society (well before Oprah latched on to it) but particularly on the 'net/burgeoning web. I used Slackware as my primary and got a lot of code from Sourceforge as well as using Debian and RedHat packages later.
Perhaps it was our approach [my, and other people with this impression]. That the first [and only] FOSS license I heard of was GPL, that the movement rallied (to my recollection) around that banner and so the idea of giving back was embedded -- I'm not a programmer. My self-apportioned part early on was to share Linux, help people with compilations and installs; act as a helper and advocate I suppose. It wasn't an explicit obligation, maybe it comes from transactional thinking having grown up in a Western Capitalist society under right wing governments?
[I'll have a dig around for some sources if I get chance.]
> I as the developer do something nice for the world. I therefore hope that you, as the user, will pay it forward.
Why do you believe this to be the case? While I applaud the notion, it is sadly divorced from reality. The notion of "nice for the world" or hoping users "pay it forward" is not, historically speaking, part of the social contract.
The social contract has been roughly either "you, the end user, are granted free access to the source code of these programs, in perpetuity, to use, modify or distribute as you see fit, while either preserving or discarding these properties (depending on the license)", or "this body of work is unencumbered by copyright or liability, enjoy".
> people who don't pay it forward, who just see "Free!" and unthinkingly take and take without ever thinking to give anything back, it rubs people the wrong way.
No? It doesn't. If I write some code and slap the BSD or MIT license on it, it's gone. I've gifted it to the universe. That's the point.
I grow tired of this rhetoric that open source is somehow coupled to community contributions and donation based funding. It's not! Sure, that may happen for some projects, and it's wonderful that it does, but it is decidedly not a characteristic of Open Source.
SQLite is Open Source, yet your contributions are not welcome. Linux is Open Source, haven't you bought Linus a coffee?
Wouldn't the AGPL with no CLA have made everyone happy? Elastic wouldn't have had to worry about Amazon adding secret sauce to a fork and then selling it as a service, and the rest of us wouldn't have had to worry about Elastic going proprietary.
It reminds me of Joel Spolsky's "Strategy Letter V" talking about how open source is often used to commoditize the complement of your product[1]. It's been very sad to see the open source community being taken over as the OP points out by corporations, but there is hope. There is still a thriving community of people who do open source for fun, but as the OP points out, a lot of these communities do use GPL. I'm thinking about sr.ht in particular.
FOSS was never about open source, it was about freedom and liberty.
It is supposed to advocate a lack of restrictions upon what users can do to the software to balance against what software can do to the users, or more importantly, forbid the users from doing at all. (or permit doing with varying levels of convenience/inconvenience).
but then, with a debate that software is better made in an open source development/collaboration style, and a political and economical state-society built around exclusivity and deceitful exploitation, there's no discourse around freedom left near the open-closed source debate.
also, the earlier FOSS advocates (GNU crowd) thought they could 'hack' the system and use one of its own tools, specifically copyright laws, in order to 'trick' (hacker mindset) the law system into guaranteeing that the software was not going to be locked down and turned to work against the users. It's become clear now (in retrospect) it did not work.
There is a place where open source platforms and software should be the norm, and that's in government and education. There's no reason to use proprietary software and platforms as the governmental norm (for example, all software related in any way to collecting and tallying votes should be open source). Nor is there any reason to push Apple or Microsoft on students, or for that matter, proprietary and overpriced textbooks.
As far as making money, governmental and educational programs should hire technical professionals who keep their open source systems secure and updated, and who also contribute updates and improvements to open source code.
Yes, this cuts the investment capitalists and monopolistic tech corporations out of the taxpayer-financed public sector, while also improving the quality of governmental and educational programs, and likely saving on expenditures as well. Sounds like a win-win.
I completely agree with you. I hope this way of doing things prevails, although I am worried that the "megacorp sales org wines-and-dines key politician and secures juicy $$$$$ government contract" way of doing things may still be prevalent and rather hard to dislodge in some places.
> Some developers use problematic open source licenses which they can then leverage for sales. But then they get vilified as “not open source enough”. There’s no winning there.
There aren't different degrees of open source. Either your license meets the OSD or it doesn't. What companies get vilified for is choosing licenses that are unambiguously not open source, but then trying to capitalize on the trust and goodwill associated with open source anyway.
Thanks to open source we have an operating system that doesn’t demand my privacy or attention. Yeah occasionally an organisation runs with it, maybe fails, but in the long run it’s contributed and build upon allowing non commercial benefits
I called it "Selfish OSS", how FAANG uses open source communities... I was an open source advocate there for a while, but became disillusioned with it pretty quickly. Some of the engineers care about contributing to the communities, sure, but the companies absolutely do not give a shit about that. It's all about enforcing dominance / crushing competition, and making recruiting easier. What the users want is only supported if it's also what the company wants. If your feature request isn't also desirable to the company, it's not happening, even if you submit the code. I'm now more likely to advocate for closed-source.
> People have various answers for open source business models. E.g. "consulting" or the vague “support”. I always wonder if such people ever tried selling consulting? Or maybe “support”. People don’t buy these things. Especially in a downturn economy.
I'm conflicted with this statement. In 2008 I was consulting and I had a longer, than usual, backlog of work at the time. I would drive to my clients and remember the dichotomy of what was coming from the radio and my situation. It seems as though some organizations view consulting as a cheaper way to get things done in tighter financial times - I'm curious how the next few years play out, but I would gather that open source solutions, and the consulting around them, goes up as organizations look to cut op and capex.
I don't believe this is the case for most OSS. Many of these companies (e.g. Sun) had the greatest intentions, however at some point the purpose of a company is to make money.
Some (like Automattic) are lucky enough to do this through hosting and/or a marketplace, but for most it will be some form of open/closed model or lock-in.
Whenever I see a company whose product is OSS take on investor money, to me that is a red flag for the longevity of that OSS software.
Agreed on everything except the assertion that people don't buy support or consulting. Sure they do, just maybe not at the scales the author would like? Depends how much you're happy with.
But the bait and switch, and the retail "loss leader" practices? Hundred percent. He gave some good examples, but some others you might not have thought about are Google and Chrome, and Microsoft and VSCode.
We're already approaching Chrome being your only choice, and what do you think Google will do on that day?
Much more difficult to get to is VSCode being the only game in town, but I can imagine it being the only one that matters at some point.
I think VS Code's popularity has very little with it being open source. Indeed, many of the components that makes up the distribution of VS Code people use are closed source.
Would it be better if VS Code was completely closed source?
From the perspective of the Open Source community, you mean? I'd say yes. At least then people would know upfront what the game is, and maybe it wouldn't attract certain users.
Same with his Android example. It's _technically_ open source, but not for most practical cases (similarly with VSCode, there's a version you can download right now that's fully open source, it's just not very practical).
I know this might be an unpopular opinion, but my opinion on how to make money off open source is mostly, “you don’t”
Companies release and contribute to open source because the open sourced code isn’t their primary business and there is more value in having outsiders contribute than the competitive advantage of forcing competitors to create their own version of whatever the open source code does. This works fine without making money.
Individuals work on open source because they want to participate in the community and might want improvements. This works fine without making money.
Yes, we would lose companies that are created solely to develop and release open source software, but I am kind of ok with that.
Open source advocates love to point to Red Hat as a shining example of how software development around open source can lead to a successful business model. Unfortunately, it is an outlier instead of proof it works for the majority (or even a significant minority). If simply releasing your source to the public lead to monetary success (or even sustainability) then there would be hundreds or thousands of other 'Red Hat examples' out there.
Simply hiding your source does not lead to success either. Anybody can hide their source, but only some people succeed in starting software businesses.
I don't think anybody claimed "simply releasing your source to the public [will] lead to monetary success"
I have a software project that I am considering open sourcing. I have people tell me all the time 'just open source it!' as if money just magically appears in your bank account after doing so. Making good software is hard. Making it profitable is also hard and open source is not some magic bullet. Most advocates for it are also realistic, but there are enough out there who seem convinced that it somehow is.
From a pure business perspective, I feel like there are more data points out there that have won (as in, "survived") by shipping proprietary software.
Don't want to make moral judgements here about proprietary-vs-FLOSS but within my hacker bubbles, one biases themselves to be partial to FLOSS very easily. If I were to ship "some things" (it really depends what the thing is) as proprietary, this community may not take too kindly to that move (and neither may I).
On the other hand, I don't think that the world at large really cares. Sometimes it feels that one can either be a) financially well off or b) more beloved by the hacker community. These things are not mutually exclusive like that but the union of these is rather rare. Hard choices!
Speaking of license options, even if you decide to release all your code as open source, there are so many options to choose from. I counted 116 different open source licenses that are currently 'blessed' by OSI: https://opensource.org/licenses/alphabetical
How do you pick the 'right one' for your project that you won't regret later on?
Look at what other similar projects have been doing, and if it's been working out well enough for them. And if you are the sole copyright owner, you're not locked into your choice. You can either refuse community contributions or make them sign over the copyright to you. Then you're free to distribute your software under another license going further.
Proprietary software doesn't save you from having to make decisions like this. Proprietary software can be licenced under many different terms. Are you going to sell perpetual per-seat licenses? Subscriptions? Selling updates? Support contracts? Avoiding future regret is always going to be a speculative affair.
Red Hat didn't create a new thing from whole cloth, open source it, and prosper.
They spotted an opportunity to sell a version of an open source thing to commercial customers. This, in turn, made product development out of what looks on the surface like open source contribution.
That worked really well for Red Hat, but the wrong lesson to take away is that there is big money in open sourcing software.
> But AWS was forking and not really helping their bottom line. So Elastic changed their license to block AWS. AWS started their own fork. Some people vilify Elastic in this story
The negative reaction to Elastic was not because they changed their license, but because they made their own proprietary license, rather than an understood OSI-approved license, like AGPL.
Complaining about not getting paid always sounds like the equivalent donating to a charity or volunteering in a soup kitchen and then complain you didn’t get your money back or paid for your time in the soup kitchen. If you’re writing OSS, considerate a donation of your time.
Why is payment required? If payment is a major motive then don’t use an OSS license. If you’re doing it because, in general, you support OSS as an ideology then be realistic and understand that compensation for your time equivalent to a corporate swe job isn’t likely, and you’re almost definitely never going to be compensated commensurate with the popularity of work that hits mainstream. If you find yourself complaining about how much time it takes to maintain and how demanding users can be, walk away in the satisfaction you’ve created something worthwhile and other people will continue the work if enough feel the same way.
> volunteering in a soup kitchen and then complain you didn’t get your money back or paid for your time in the soup kitchen
No, its not like that at all.
It would be like if you volunteered in a soup kitchen, where every single day, half of the patrons were individuals that couldn't afford the soup, and the other half were businesses that were taking the free soup, putting their name on it, and selling it. The first group of people I am fine with. Thats why soup kitchens exist, and pro bono exists. But once someone gets the ability to pay, they should pay. Thats why I support non-commerical licenses:
I generally agree, noncommercial licenses are the way to go. Otherwise it is very much like setting up a soup kitchen where businesses can take the soup & sell it.
Although under this metaphor the soup, once a single can is made, has an infinite supply at zero cost save the nominal costs a business has to transport cans from the kitchen's infinite pantry... or they can take a single can and build their own infinite pantry... well, all metaphors break down if you try to map their attributes 1-to-1 onto the target domain. In this case though I intend the metaphor to extend only to the labor aspect of running a soup kitchen because that is a significant & necessary aspect of keeping it going, as with OSS projects. OSS projects have an advantage over soup kitchens in that non-labor resources are proportionately very small.
> once a single can is made, has an infinite supply at zero cost
The point is, the businesses are abusing the social contract. The unspoken agreement is, that the item is for people who cant afford it. The businesses can afford it. They just see that its free, so they are taking advantage of that fact.
Yes, some licenses explicitly allow the business to do that. However I don't think some developers take the time to actually think about what their license means, and they end up giving up more rights than they would if they had a better understanding. If you told an open source developer that even AGPL allows commercial use, some might be surprised by that fact.
Thank you for engaging in such a thoughtful discussion here. I really appreciate opportunities that force me to consider my value judgements in an explicit fashion rather than as a general feeling, and I hope you similarly see my replies as good-faith engagement in that discussion. As such I would really like to see what you think of my reply to your last comment, if it stands up to the scrutiny of someone making thoughtful commentary that runs counter to its (my) own reasoning. Given that:
I think I see the social contract differently, that it has evolved over the decades as OSS has permeated software culture. At this point in OSS history I do think developers generally understand what their license means. It seems like a developer would have to ignore most industry news to avoid having at least a general understanding that different licenses have commercial implications.
As such, I don't see it as abusing the social contract when a business-- even a massive FAANG-- uses software with licenses that permit commercial use. I would certainly prefer that they give something back to those projects either in dev time by their own paid swe's working on the project or financial support. The later simply isn't possible though if the project has not set itself up in some way as a formal organization. GAAP doesn't really have a way for businesses to account for financial support to non-employee individuals when it isn't either a contractor relationship or formal non-profit status.
If a developer does not understand the broad distinctions between licenses (such as the AGPL) then I have some sympathy for them if they make choices early on that don't align with their financial goals or social values. They should change their license in, if possible, a non-disruptive fashion. However I also regard such a situation as an easily avoidable mistake.
In general I think it is fruitless to look at the status quo & rail against businesses that violate whatever you may perceive to be unspoken agreements or social contracts. It is highly unlikely to change businesses' behaviors. It would be much better for OSS developers to change their behavior so that it requires businesses to use their work in the way they intend.
I view the four freedoms of FOSS as personal freedoms. Rights granted to individuals. And, US Supreme Court rulings notwithstanding, don not regard businesses as having attributes of personhood. It seems like the arguments for support/compensation models for developers of OSS imply similar values, and so proponents of those arguments should spend their time advocating for developers to choose corresponding licenses rather than advocating for businesses to change their practices.
Most people don't complain about working a few hours of unpaid volunteer time on a worthwhile cause; whether that is donating to a soup kitchen on a Saturday or fixing a bug in an OSS project during a couple evenings. The problem is that serious OSS projects (just like running a major charity organization) often require a lot more than a few evenings or a weekend here and there.
Expecting people to donate thousands of hours of unpaid labor toward anything seems a bit extreme. If it is considered whining to expect some compensation for what amounts to another full-time job, then we should not expect anyone to stick with it for very long.
>If it is considered whining to expect some compensation for what amounts to another full-time job, then we should not expect anyone to stick with it for very long.
It's whining to expect compensation when a person knew what they were getting into or decides to stick with it even after it becomes more than they thought they were getting into & complains about compensation.
Not sticking with it for long is exactly what I think people should do when it grows beyond their desire to devote so much time to it. If I created a charity and it grew to the point where I didn't have enough time to run it, and couldn't get enough donations to cover my financial needs if I stopped my normal job, I wouldn't write blog posts about how "The model for running charities is broken because volunteers can't get paid enough to keep them running!" If no one else was interested in running it I'd scale things back or gently, perhaps regretfully, wind things down.
An OSS project is essentially a charity organization. And, while developers may not like it, charitable organizations that reach even modest sizes have to spend a significant amount of time soliciting donations & volunteer time. St. Jude's couldn't function and wouldn't be such a highly successful charity without having built up such a newtwork and put in that effort.
OSS doesn't need a compensation model because one already exists-- that of other charities. For projects that get large enough to start experiencing problems like this I'd encourage them to incorporate as a charity, a 501(c)(3) in the US. That gives them an excellent pathway towards covering labor or other costs and provides an excellent pathway for corporate users to contribute financial resources in formal & tax deductible fashion than when someone puts up a paypal donate button or similar.
Any particular reason he points to Zig as a template for supporting/monetizing OSS? Was that just an example? There is the Rust Foundation and many others, no? Just curious if Zig was a pioneer in this or if this was just one example of many he could have given.
The Zig Software Foundation is a 501(c)(3) non-profit foundation entirely sustained by donations (and now a couple support contracts). We pay 3 developers to work full-time and also offer a pool of hours that other core contributors can bill the foundation when they do Zig work.
As far as I'm aware, not all foundations pay their core contributors, including the Rust Foundation.
On top of that, we don't have any big tech company in our board of directors and never will, this is another difference with the Rust Foundation (and many others).
There's millions of companies out there creating software all the time. Of those, tens of thousands don't need that software to be closed-source, due to their business model. But open sourcing software is a huge hurdle: cleaning up code, finding a brand that doesn't violate a trademark, making sure the software doesn't violate any software patents, choosing the right license, finding a way to interact with a community (if at all), etc. It's expensive and time-consuming and dangerous.
We need to make it dead simple for companies to open source their code. And we need to popularize the hires that happened because of a company's open source, or their outreach in the FOSS community. An organization dedicated to this work could have a huge impact.
256 comments
[ 3.2 ms ] story [ 304 ms ] threadeasy for software to commoditize hardware... hard for hardware to commoditize software. (Spolsky 2002)
Linus effectively killed the golden goose of writing OSs, a super-difficult task that deservedly propelled Gates and Allen to the stars.
All it takes is a college kid and a laptop to ship software. I wouldn't know where to start building and shipping chips and circuit boards. And that's why Azure, not Office, is where Microsoft's placing its bets.
They had to release those sources after the fact because they didn't change the license in the general release.
and other 3rd party GPL dependencies.
1) RoboVM had to use the GPL license because they used other people's GPL code - which they presumably pulled out / rewrote themselves in their new closed-source version
or
2) the author mistakenly believes that RoboVM is bound to the terms of the GPL license, or forced to offer new GPL licenses, on code they own 100%, just because they have offered GPL licenses to other people in the past
You do not need to grant yourself a license to distribute your own works. You always had that right.
Besides, who would sue you? The only person who has standing is the copyright holder. You're gonna sue yourself because you failed to honor the terms of a license, which was granted from yourself to yourself?
If they didn't own 100%, then see 1).
I know plenty of people who do open source consulting professionally, (in an ethical fashion). I myself did it briefly (not really my thing)
Yes predatory people and scammers exist. But lets not dismiss an entire field because some people are assholes.
Also, i have no idea what the bait and switch the author is talking about is. Did anyone really think that google open sourcing android meant that it was open sourcing the entire android ecosystem? There has to be an intention to mislead for it to be a bait and switch. Someone doing something you dont like is not a bait and switch unless they try and trick you.
Anyways, as a php dev, i can assure you im not working on whatever the popular trend is right now.
Certain tech stops being a fad but stays entrenched and in a certain, while not overwhelming, demand. Hiring for PHP and C++ jobs will continue for a loooong time.
My impression is that it's relicensing a product from a FOSS license to a proprietary one after it's gotten a bunch of users.
> The GNU Affero General Public License is designed specifically to ensure that ... the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.
The AGPL v3 and GPL v3 also contain provisions to make them compatible with each other (resulting in AGPL terms for the combined work, but the GPL parts remain GPL).
The FSF goes a bit more into detail on this: https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-t...
I also think its a bit problematic taken in the absolute, sometimes you have security patches you want to deploy and test out for a week before making the issue public, or perhaps emergency patches for sudden (downtime causing) issues.
AGPLv3 is thus a de facto 'hobbyists only' license, and hobbyists by in large don't go around suing each other; generally they just make good faith efforts to respect each others licenses and maybe use social ostracism when somebody steps over the line. Since hobbyists don't take their community disputes to court, the technical legal minutia of the license doesn't matter to most of them.
As a corporation, I might not want to use it in conjunction with my code, but that's the point. You are free to do what you want, but you in turn must share your code.
Or you engage with the owner to make a financial arrangement for a separate license.
This is like nonfree usage restrictions on otherwise free software, like the famous (if unenforceable) “can not be used for evil” license clause.
therefore the AGPL shouldn't force you to share code if the program runs on a server. but it should force you to share code if the program can be accessed by a user.
this may even apply to running something like a kiosk device where users interact with a program on a device they don't own.
I.e. the gpl prohibits you not sharing code if you distribute the binary. What is the philosophical underpinning of "sharing binary" not being a restriction but "ethernet" being a restriction.
The evil thing is not similar because you are discriminating against a field of endevour (similar to licenses that say educational use only, non-commercial only or non-military only). It seems to be a very different type of restriction.
That's not even remotely near what it is.
I've worked for several large corporations and were in the throes of a major project. Using an Open Source tool would've cut a lot of our dev times by many hours. Three out of three times, all three team leads and managers said "no" to using open source. We had to build several large components from scratch, which did lead to extended development timelines, a ton of working late at night and several "crunch" weekends.
Their rationale? They didn't want to have to maintain a piece of software that was open source. The resounding opinion was it was "dangerous" and not safe - because someone could check in a malicious piece of code and that could end up in our very large, enterprise application when we needed to update it. Nobody wanted to be on the hook if that ever happened.
In the end, it seemed like it was more about upper management types playing CYA instead of trying to put out a solid product.
If that is the case, I don't see how the AGPL qualitatively infringes on any "freedoms" that the GPL doesn't already restrict: you must keep derivatives free. Of course one may argue that the GPL is nonfree when compared to BSD/MIT style licences, in which case fair enough.
I think the argument of FOSS people who don't like it would be something like, as a user, just running the software on my machine can potentially create a legal obligation to set up source distribution, if, like, I forgot to block a port.
In any case, does the AGPL requirement to provide sources apply even if you are running an unmodified version? In other words, would merely pointing to the original repository not be enough?
Regarding the risk of accidental legal obligations, I suppose it depends on the details and technical wording of the licence.
If the requirement broadly covers any use of the software on the machine (e.g. some backend service that happens to help your public webserver to stay online) I can see the discomfort, especially if one must explicitly provide or link to unmodified sources too.
On the other hand though, if the requirement is limited to actual provision of the software's functionality to 3rd parties, I would argue that if someone accidentally provides it due to forgetting to block a port then they have much bigger problems than the AGPL.
https://www.gnu.org/licenses/agpl-3.0.en.html
It just says interact remotely through a network. Interpreting what this means precisely is left as an exercise for the reader / the reader's lawyer.
I'm not against AGPL myself so don't take that as like, the strongest argument against it. It was meant a bit tongue-in-cheek.if you get notified of a security breach caused by your own incopetence, you secure it. which would effectively be the highest harm apgl can inflict on you already: stop hosting the service. which was your point all along.
for a popular program that's not very likely, but lost source code is the bane of software development, so hacing your own version available would be better, at least as a backup
distributions keep archives. Just use a distribution and you're fine.
Not true: only if you made local modifications.
> I forgot to block a port
Also not true. You have plenty of time to close that port.
"""your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice."""
If you expose services on the Internet by mistake you are going to have 1000x bigger problems than the risk of being sued successfully for a honest mistake.
That said, FOSS authors normally aren't the kind of people that pushes to those crazy maximalist interpretations of documents. So if any risk exists, it's not large.
It's not entirely clear what counts as derivative work with regards to GPL. There is a lot of corner cases and workarounds in the real world. It becomes even less clear when you widen the definition of distribution.
I don't understand this stance.
From the point of view of the user, the AGPL offers the same freedoms as the regular GPL. If you use the program, you have the right to see and edit its source code, regardless if the program runs on your own computer or on another computer.
How can anybody call this feature "nonfree" is beyond me.
Granted, the license only asks you to publicize your modifications, but in software that's basically your "first-born".
If you're just talking about the freedom to run things unmodified, basically every software you can download online without paying is "free", and obviously AGPL fits that bill for the uncapitalized "free" software. But that's not what we're talking about here, right?
The situation is funny that AGPL is widely derided as both being to weak and being to strong.
Do you have evidence?
But still, I think the permissive license we picked was the better choice. Especially after our company was formed and we want to use the project for ourself too the (A)GPL would make the community working together with this harder (CLA, dual licensing?)
IMO a permissive license is better and easier for the developer and the GPL is better for the end user.
But even the GPL does not grant you anything without a lawyer :) E.g. I tried to get the GPL source code from Waze (tried it multiple times!) and got a reply: "I've looked into your concern and determined that it needs some extra attention from our end." See also https://2jk.org/english/2014/03/27/israeli-waze-hit-with-gpl...
(btw: you can get the inofficial code from here https://github.com/maximuska/Freemap-waze)
No, as developers we use tons of software. We are users before being developers. As such, GPL protects developers as well.
In this scenario, your company is the thing GPL is trying to protect your community devs from (i.e. the gpl is trying to stop a company from taking contributions donated on the condition they would be open-source, and selling them privately without compensation). You are basically saying the GPL makes it harder to do the thing the GPL was trying to stop.
It's a perfectly reasonable arrangement that adds value to both the community and the GP, and that the GPL "protects against". So, yes, the GP's point stands in that there are uses for licenses other than the GPL. All of the complaints about they only being good for people creating proprietary software are true, they just completely miss the point.
But if you take too long to reach it and forget the context, it does indeed sound like a weirdo complaining that the GPL is copyleft.
The morally questionable situation is where you publish code under GPL, allow community contributions on the code on the condition that the community contributors sign a document transfering copyright to you (without payment or anything like that) and then also use those community contributions in a closed source product you sell.
wat
That's exactly backwards. Releasing your donation under a permissive license doesn't give you that. A permissive license gives others express permission to make derivative works that the original author company might not be able to use themselves—because there's no obligation for others to keep it open...
A permissive license is only better and easier for developers of proprietary software. The GPL is better for developers of free software and for end users.
Two permissive licenses, one headache for the FOSS dev.
Regardless of license, most software projects are either community projects, or corporate projects, but not both. Corporations rarely see fit to invest in the development of a project they're using because some other chump is giving it away for free. And volunteer programmers rarely want to deal with submitting commits to a project with corporate managers who are focused on the needs of the organization and see volunteer programmers as out-of-the-loop nuisances.
Whether you're a corporation open sourcing something to get free community labor, or a volunteer open sourcing something to get corporations to contribute, you'll probably be disappointed.
users don't care, they aint taking the code for changing.
Arguably it also doesn't matter till you are corporation closing the code for profit. If all you do is OSS and are used by people that also release OSS, extra protection GPL gives are not useful. But of course real world is not that idealistic.
And for that of course BSD/MIT is better. No facility for anyone to get anything out of you so you can take and take without ever giving back aside from occasional bug report and outrage over someone having a bug they didn't fix in project they are not paid to develop in the first place
GPL gives one guarantee - that the code you give will not be closed down for money and used to save some corporation some dev-hours. Some devs don't like it because it is making their life difficult (and I'd also argue anything higher than LGPL for stuff like libraries is kinda pointless), but that's kinda the point.
GPL explicitly allows commercial usage. E.g. I take take your GPL code and create a SaaS around it and make a lot of money or I can create a consultancy service around your GPL code.
That's why I chose the license that seems least likely to prevent me from being able to use the code I've written (currently Apache 2).
That's incorrect. As the upstream author you have every right to use your own code any way you want.
Well, that depends on if the project accepts pull requests, and whether they have something like a contributor licensing agreement in place.
Of course you can take your code and license it to said employer in whatever way you both agree on. But this is going to be much easier if the code is already publicly available to everyone, with a known license: the employer doesn't need to even care really who the author is, just the license.
Not at all. The code you are going to submit already has a license file attached. Just update it with an accepted FOSS license before the submission.
You don't have to provide any special license or make it public.
> Of course you can take your code and license it to said employer in whatever way you both agree on.
but that's likely to be a manual step with a lot of raised eyebrows, frowns, and questions involved.
i thought that way i would always be able to use the code in my own FOSS projects but i would also not be able to sell out and make my work proprietary (since it would contain GPL code owned by my employer)
this may seem less beneficial than an apache license but it was aligned with the company goals as far as my work was concerned, so i essentially had them put a verbal promise into writing, and i thought it was a neat way to commit myself to FOSS
As the owner you reserve the right to re-license it to anybody you'd like, under any license you'd like, as long as you don't give that right away.
At a job, or on a contract, the employment agreement or the contract will almost always says you're giving that right to them in exchange for compensation.
You can tell your company to either buy a proprietary license from yourself or reimplement the whole thing.
You won't be able to use it if the future project is under a GPLv2 (or GPLv2+) requirement, since Apache 2.0 and GPLv2 are not compatible.
I don't think i've ever heard someone saying this. Does anyone really believe this? Some concrete examples would be illuminating.
Some of those employers had policies outright prohibiting GPL use...
And linux (GPL) does have paid developers, and so does webkit (LGPL).
Your data is rather meaningless… but I'm happy your statistic that excludes all the data points you dislike proves your theory :)
But yeah it is true that Linux is much more efficient at getting stuff upstreamed, I think Sony has sent more patches to Linux than FreeBSD and the PlayStation runs on it.
There's also the path that--even if you have a permissively licensed project--$corp will see your thing, like it, and decide to just copy it, to overall avoid having to deal with dependencies they do not own. In other words, a lot of places are unwilling to play in anyone else's backyard. They "support" open-source, but only when it's on their terms.
They might even call you, under the pretext of a job interview, and of course they want to discuss in detail the most significant project you've worked on! But you find out there are all kinds of awkward conditions on the job offer, like a cross-country move, or much lower pay than you were expecting, or no actual commitment that you'd be working on your project but just a vague, verbal statement that you could continue "during 10% time". You'll have to interview three more times with 15 more teammates. Everything gets dragged out for months and then you see them announce their own project in opposition to yours.
That is, if anyone pays attention to your project. Most open-source developers are categorically averse to anything resembling advertising. Try building a thing and then posting about it on a topic-appropriate sub-Reddit. So many of them will delete your post or ban your account from the sub for "spam".
The vast majority of the market--including other open-source developers--want open-source developers to write code, shut up, and go away. The minute you start talking about maybe wanting some remuneration for your efforts, you're suddenly "ungrateful" or "shilling" or "spamming" or "selling-out". (EDIT: It's happening in this very thread, further down the page)
A lot of big corporations will not allow GPL dependencies to be used in their codebases, and not having a GPL license will definitely make software more usable by those corporations.
How the developer expects to profit by giving something away for free is definitely a mystery, but there is also some truth to the idea that a GPL license does scare companies away.
Elasticsearch is a good example of a problem that isn't solved by a different license. Amazon is running essentially unmodified versions of elasticsearch, which competes against the business model of the company building elasticsearch. Even with an AGPL license, elasticsearch (the company) is not going to be making any money.
If a company isn't interested in upstreaming changes, it probably won't help that they're using an AGPL license. If the code isn't user-facing, the license won't force them to make their changes available. Even if it is, often changes a company doesn't want to upstream are very specific to them and aren't useful to others. Even if it's business valuable, and the company makes the changes available, they won't be making it easy to integrate.
The AGPL, more than anything, places a burden on users and developers, and reduces the community size. Most companies don't allow the use of AGPL software, and in the cases they do, they often only allow its use in an unmodified way, or only allow modifications if it isn't user-facing.
It's a nasty, complicated situation with bad actors on both sides.
You're probably thinking of SaaS, but, still, what?
I'd argue we distribute software much more than say 20 years ago. Almost every web site you view is distributing non-trivial software (javascript, from maybe a dozen npm packages). App stores are making software distribution much easier for the average user. Programmers are increasingly using dependency managers to download libraries. Even every SaaS service is getting their software from somewhere, and the tech stack is increasingly complex these days, which means even more software being distributed and used.
Perhaps what you mean is "software isn't sold anymore", so the money is all in the services. Which is probably true, and this is probably where GPL is becoming irrelevant.
But then, it can be argued that the services model was in part the industry's response to the prevalence of GPL, which pushed businesses to find workarounds. People need to make money, and if software sales isn't generating enough dollars because GPL software pushes down the prices people are willing to pay, then they'd just invent reasons for users to buy services instead. -- which, if true, could be interpreted as a success story for the GPL.
Maybe I should have been clearer. Most actual products based on OSS aren't distributed anymore. They're SaaS. The majority of the most popular app store apps are clients to a SaaS product.
This is a fundamental misunderstanding about how copyright works, the author could have closed the source completely without changing the license, because the license only applies to third parties trying to use that licensed code, not the authors.
That doesn't make it desirable, but I hope it helps to explain it.
1. Go outside
2. Look up!
3. Take a picture !
Now you have a hi res photo of the very beautiful sky of Planet Earth . For free !
I mean, if a person is only ever going to write a single blog post, then yes, absolutely, post a personal photo of something beautiful. Why not? But if a person might post more than one blog post, then presumably there's some motivation to tying each (required) photo to the post in question in some way, even if tangential, right?
> "take a picture of anything, every time you make a blog post!"
If you're saying one can actually find things relevant to my blog posts by doing that, I'd love to hear more. Because it doesn't seem plausible to me.
Using AI images isn't really as easy as one may think. It takes a couple minutes to generate a large image, and sometimes the AI messes up. A couple iterations later, you've already used 20 minutes. If I could generate better images with a camera pointing at random things around me, please enlighten me on that.
PS: I don't think anyone is compelling you to reply -- you chose to do so.
How is this problematic? For most of my career, I also haven't supported OSS -- I too use and leverage it.
Open source is relatively simple: it does what it says on the tin. If you make something freely available under a non restrictive license, you no longer own that thing. Sure, you may retain some copyright, but you've given it away. Why are people always surprised when those free things are leveraged? Is everyone truly this naive?
GPL, AGPL, BSL... they all solve different problems. There's no right answer. If you're building something and want to make money, then it behoves you to choose a license that strengthens your position to make money, rather than introduce a vulnerability.
While there are legitimate arguments in favor of different open source licenses, the BSL is a proprietary license and is always the wrong answer. I'd agree with this if it used a real open source license like Apache or MIT as its third example instead.
And well the other BSL (Business Source License) may be appropriate for proprietary software that you want to be released under a open license at a later time.
Although I am also not really aligned with the idea on a ideologically plane.
A lot of companies do astroturfing by creating a false impression of community, cooperation, openness and decentralized development.
Later on they add CLAs, switch to open-core or use other tricks to strictly control development and use.
It literally does not. Please refer me to any definition of Free and Open Source Software that refers to anything beyond the text contained in the license. Please stop spreading such woefully sore interpretations. This is exactly how you burn out authors and maintainers.
> A lot of companies do astroturfing by creating a false impression of community, cooperation, openness and decentralized development.
I've said it elsewhere, but these elements do not inherently have anything to do with Open Source. It's beyond foolish to presume them.
> Later on they add CLAs, switch to open-core or use other tricks to strictly control development and use.
If this bothers you (which it shouldn't) then perhaps consider an alternative licenses which restrict the ability to monetize without releasing source, such as AGPL.
Licenses are being wielded as per their lettering. This is a good thing, generally. We all benefit from Open Source regardless of CLAs or open-core.
I as the developer do something nice for the world. I therefore hope that you, as the user, will pay it forward.
When this ethos is subverted by people who don't pay it forward, who just see "Free!" and unthinkingly take and take without ever thinking to give anything back, it rubs people the wrong way.
"Open Source", historically speaking, was the right (and obligation) to have the ability to modify the source code of software you use. There was nothing about 'paying it forward', but rather giving users the freedom to control the software they run.
Do you have any written evidence that this was a commonly accepted "social contract"? Because I've been using FLOSS since last year's of last millennium as well and I've never heard of such attitudes until recent years. (Even today, I rarely see OSS project leaders actually saying they expected all users to give back something -- it's mostly other users who somehow assume everyone else needs to do so. And if I may say, making presumptions on the intentions of OSS developers is a bit... presumptuous to say the least, even if well intentioned.)
One of the few "giving back" contracts I'm aware of is the GPL. Which explicitly states in the license that you need to open source your modifications if you distribute the binary. Vim nags you a bit to donate to Uganda children, but that's explicit as well.
>Even today, I rarely see OSS project leaders actually saying they expected all users to give back something //
I've never seen it _demanded_ of anyone. Also, I think it largely went away in the early 2000s, as more, varied licenses came online bringing OSS a much broader base.
Pay-it-forward seemed to be a growing movement across society (well before Oprah latched on to it) but particularly on the 'net/burgeoning web. I used Slackware as my primary and got a lot of code from Sourceforge as well as using Debian and RedHat packages later.
Perhaps it was our approach [my, and other people with this impression]. That the first [and only] FOSS license I heard of was GPL, that the movement rallied (to my recollection) around that banner and so the idea of giving back was embedded -- I'm not a programmer. My self-apportioned part early on was to share Linux, help people with compilations and installs; act as a helper and advocate I suppose. It wasn't an explicit obligation, maybe it comes from transactional thinking having grown up in a Western Capitalist society under right wing governments?
[I'll have a dig around for some sources if I get chance.]
Why do you believe this to be the case? While I applaud the notion, it is sadly divorced from reality. The notion of "nice for the world" or hoping users "pay it forward" is not, historically speaking, part of the social contract.
The social contract has been roughly either "you, the end user, are granted free access to the source code of these programs, in perpetuity, to use, modify or distribute as you see fit, while either preserving or discarding these properties (depending on the license)", or "this body of work is unencumbered by copyright or liability, enjoy".
> people who don't pay it forward, who just see "Free!" and unthinkingly take and take without ever thinking to give anything back, it rubs people the wrong way.
No? It doesn't. If I write some code and slap the BSD or MIT license on it, it's gone. I've gifted it to the universe. That's the point.
I grow tired of this rhetoric that open source is somehow coupled to community contributions and donation based funding. It's not! Sure, that may happen for some projects, and it's wonderful that it does, but it is decidedly not a characteristic of Open Source.
SQLite is Open Source, yet your contributions are not welcome. Linux is Open Source, haven't you bought Linus a coffee?
1: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
It is supposed to advocate a lack of restrictions upon what users can do to the software to balance against what software can do to the users, or more importantly, forbid the users from doing at all. (or permit doing with varying levels of convenience/inconvenience).
but then, with a debate that software is better made in an open source development/collaboration style, and a political and economical state-society built around exclusivity and deceitful exploitation, there's no discourse around freedom left near the open-closed source debate.
also, the earlier FOSS advocates (GNU crowd) thought they could 'hack' the system and use one of its own tools, specifically copyright laws, in order to 'trick' (hacker mindset) the law system into guaranteeing that the software was not going to be locked down and turned to work against the users. It's become clear now (in retrospect) it did not work.
As far as making money, governmental and educational programs should hire technical professionals who keep their open source systems secure and updated, and who also contribute updates and improvements to open source code.
Yes, this cuts the investment capitalists and monopolistic tech corporations out of the taxpayer-financed public sector, while also improving the quality of governmental and educational programs, and likely saving on expenditures as well. Sounds like a win-win.
There aren't different degrees of open source. Either your license meets the OSD or it doesn't. What companies get vilified for is choosing licenses that are unambiguously not open source, but then trying to capitalize on the trust and goodwill associated with open source anyway.
The source code for Windows is public and available.
No its not.
I'm conflicted with this statement. In 2008 I was consulting and I had a longer, than usual, backlog of work at the time. I would drive to my clients and remember the dichotomy of what was coming from the radio and my situation. It seems as though some organizations view consulting as a cheaper way to get things done in tighter financial times - I'm curious how the next few years play out, but I would gather that open source solutions, and the consulting around them, goes up as organizations look to cut op and capex.
I don't believe this is the case for most OSS. Many of these companies (e.g. Sun) had the greatest intentions, however at some point the purpose of a company is to make money.
Some (like Automattic) are lucky enough to do this through hosting and/or a marketplace, but for most it will be some form of open/closed model or lock-in.
Whenever I see a company whose product is OSS take on investor money, to me that is a red flag for the longevity of that OSS software.
But the bait and switch, and the retail "loss leader" practices? Hundred percent. He gave some good examples, but some others you might not have thought about are Google and Chrome, and Microsoft and VSCode.
We're already approaching Chrome being your only choice, and what do you think Google will do on that day?
Much more difficult to get to is VSCode being the only game in town, but I can imagine it being the only one that matters at some point.
Would it be better if VS Code was completely closed source?
Same with his Android example. It's _technically_ open source, but not for most practical cases (similarly with VSCode, there's a version you can download right now that's fully open source, it's just not very practical).
Companies release and contribute to open source because the open sourced code isn’t their primary business and there is more value in having outsiders contribute than the competitive advantage of forcing competitors to create their own version of whatever the open source code does. This works fine without making money.
Individuals work on open source because they want to participate in the community and might want improvements. This works fine without making money.
Yes, we would lose companies that are created solely to develop and release open source software, but I am kind of ok with that.
We wouldn't even lose them. If open source were incompatible with software development companies, then Red Hat wouldn't be in business.
I don't think anybody claimed "simply releasing your source to the public [will] lead to monetary success"
From a pure business perspective, I feel like there are more data points out there that have won (as in, "survived") by shipping proprietary software.
Don't want to make moral judgements here about proprietary-vs-FLOSS but within my hacker bubbles, one biases themselves to be partial to FLOSS very easily. If I were to ship "some things" (it really depends what the thing is) as proprietary, this community may not take too kindly to that move (and neither may I).
On the other hand, I don't think that the world at large really cares. Sometimes it feels that one can either be a) financially well off or b) more beloved by the hacker community. These things are not mutually exclusive like that but the union of these is rather rare. Hard choices!
Proprietary software doesn't save you from having to make decisions like this. Proprietary software can be licenced under many different terms. Are you going to sell perpetual per-seat licenses? Subscriptions? Selling updates? Support contracts? Avoiding future regret is always going to be a speculative affair.
They spotted an opportunity to sell a version of an open source thing to commercial customers. This, in turn, made product development out of what looks on the surface like open source contribution.
That worked really well for Red Hat, but the wrong lesson to take away is that there is big money in open sourcing software.
The negative reaction to Elastic was not because they changed their license, but because they made their own proprietary license, rather than an understood OSI-approved license, like AGPL.
Why is payment required? If payment is a major motive then don’t use an OSS license. If you’re doing it because, in general, you support OSS as an ideology then be realistic and understand that compensation for your time equivalent to a corporate swe job isn’t likely, and you’re almost definitely never going to be compensated commensurate with the popularity of work that hits mainstream. If you find yourself complaining about how much time it takes to maintain and how demanding users can be, walk away in the satisfaction you’ve created something worthwhile and other people will continue the work if enough feel the same way.
No, its not like that at all.
It would be like if you volunteered in a soup kitchen, where every single day, half of the patrons were individuals that couldn't afford the soup, and the other half were businesses that were taking the free soup, putting their name on it, and selling it. The first group of people I am fine with. Thats why soup kitchens exist, and pro bono exists. But once someone gets the ability to pay, they should pay. Thats why I support non-commerical licenses:
https://polyformproject.org/licenses/noncommercial/1.0.0
Although under this metaphor the soup, once a single can is made, has an infinite supply at zero cost save the nominal costs a business has to transport cans from the kitchen's infinite pantry... or they can take a single can and build their own infinite pantry... well, all metaphors break down if you try to map their attributes 1-to-1 onto the target domain. In this case though I intend the metaphor to extend only to the labor aspect of running a soup kitchen because that is a significant & necessary aspect of keeping it going, as with OSS projects. OSS projects have an advantage over soup kitchens in that non-labor resources are proportionately very small.
The point is, the businesses are abusing the social contract. The unspoken agreement is, that the item is for people who cant afford it. The businesses can afford it. They just see that its free, so they are taking advantage of that fact.
Yes, some licenses explicitly allow the business to do that. However I don't think some developers take the time to actually think about what their license means, and they end up giving up more rights than they would if they had a better understanding. If you told an open source developer that even AGPL allows commercial use, some might be surprised by that fact.
I think I see the social contract differently, that it has evolved over the decades as OSS has permeated software culture. At this point in OSS history I do think developers generally understand what their license means. It seems like a developer would have to ignore most industry news to avoid having at least a general understanding that different licenses have commercial implications.
As such, I don't see it as abusing the social contract when a business-- even a massive FAANG-- uses software with licenses that permit commercial use. I would certainly prefer that they give something back to those projects either in dev time by their own paid swe's working on the project or financial support. The later simply isn't possible though if the project has not set itself up in some way as a formal organization. GAAP doesn't really have a way for businesses to account for financial support to non-employee individuals when it isn't either a contractor relationship or formal non-profit status.
If a developer does not understand the broad distinctions between licenses (such as the AGPL) then I have some sympathy for them if they make choices early on that don't align with their financial goals or social values. They should change their license in, if possible, a non-disruptive fashion. However I also regard such a situation as an easily avoidable mistake.
In general I think it is fruitless to look at the status quo & rail against businesses that violate whatever you may perceive to be unspoken agreements or social contracts. It is highly unlikely to change businesses' behaviors. It would be much better for OSS developers to change their behavior so that it requires businesses to use their work in the way they intend.
I view the four freedoms of FOSS as personal freedoms. Rights granted to individuals. And, US Supreme Court rulings notwithstanding, don not regard businesses as having attributes of personhood. It seems like the arguments for support/compensation models for developers of OSS imply similar values, and so proponents of those arguments should spend their time advocating for developers to choose corresponding licenses rather than advocating for businesses to change their practices.
Expecting people to donate thousands of hours of unpaid labor toward anything seems a bit extreme. If it is considered whining to expect some compensation for what amounts to another full-time job, then we should not expect anyone to stick with it for very long.
It's whining to expect compensation when a person knew what they were getting into or decides to stick with it even after it becomes more than they thought they were getting into & complains about compensation.
Not sticking with it for long is exactly what I think people should do when it grows beyond their desire to devote so much time to it. If I created a charity and it grew to the point where I didn't have enough time to run it, and couldn't get enough donations to cover my financial needs if I stopped my normal job, I wouldn't write blog posts about how "The model for running charities is broken because volunteers can't get paid enough to keep them running!" If no one else was interested in running it I'd scale things back or gently, perhaps regretfully, wind things down.
An OSS project is essentially a charity organization. And, while developers may not like it, charitable organizations that reach even modest sizes have to spend a significant amount of time soliciting donations & volunteer time. St. Jude's couldn't function and wouldn't be such a highly successful charity without having built up such a newtwork and put in that effort.
OSS doesn't need a compensation model because one already exists-- that of other charities. For projects that get large enough to start experiencing problems like this I'd encourage them to incorporate as a charity, a 501(c)(3) in the US. That gives them an excellent pathway towards covering labor or other costs and provides an excellent pathway for corporate users to contribute financial resources in formal & tax deductible fashion than when someone puts up a paypal donate button or similar.
As far as I'm aware, not all foundations pay their core contributors, including the Rust Foundation.
On top of that, we don't have any big tech company in our board of directors and never will, this is another difference with the Rust Foundation (and many others).
We need to make it dead simple for companies to open source their code. And we need to popularize the hires that happened because of a company's open source, or their outreach in the FOSS community. An organization dedicated to this work could have a huge impact.
licenses and "for profit" mindset has to disappear asap, just like with patents, bottleneck of humankind
let the knowledge be shared and known by everyone, let people unlock what's yet to be discovered