There's this idea that open source should be totally free, but then how does the developer writing the software wind up eating and paying their rent? There's the linux kernel and mozilla and other massive open source projects which have large companies and foundations and budgets behind them, but that is the 0.01% of open source projects.
When OSS maintainers setup companies and go the "loss leader" or "bait and switch" or "freemium" models so that they release open source code, but the Enterprise-level offerings are locked behind proprietary licenses then this is looked at as being a betrayal.
The OSS community almost seems to require OSS maintainers to be in poverty, while allowing large corporations to freely consume all of their work. That just isn't sustainable.
So companies will generally keep away from my stuff, but people doing open source will happily use it.
I've had several people complain about this and ask me to use MIT. I put in my code of conduct that asking that is forbidden :D
By using aggressive open source licenses like AGPLv3 you have to do more work to keep the door open for yourself to profit later if you so choose, it’s a bad personal economic choice, and while some view it as the ultimate in altruism to prevent this, it’s also an act of denial, everyone who could have used it inside companies or projects that can’t change their license to be compatible are denied the ability to use the code.
Also hot damn, the AFPL license is super aggressive, makes AGPLv3 look downright business friendly: https://en.m.wikipedia.org/wiki/Aladdin_Free_Public_License
Too bad that rewriting something doesn't transfer copyright :D
Ideas aren't copyrightable. IANAL
That's it. I have no plans for using anything more liberal than lgpl ever.
> Things might get complicated if you have other contributors though.
Not really… they distribute under whatever license they got it from.
[0]: https://vadosware.io/post/the-future-of-free-and-open-source...
It's a weird sort of exploitation, because OSS maintainers who don't think they're being adequately compensated are free not to participate by volunteering their time.
- Is well-compensated while working for a for-profit company where the codebase is proprietary.
- Works in open source but is poorly paid or not paid at all.
[1] That they might prefer to work on open source is their problem, and not one for the economy, I think; I say this as an open source developer who gets paid to work on open source and prefers this over working on proprietary software.
I think it's a problem for the economy, not because of individuals' preferences, but because I think there is an overall economic benefit to work being open source.
First of all, it's been sustainable for a long time -- what changed?
Secondly, a lot of major open source projects are being worked on by developers who are employed full-time by large corporations to do it. And I don't just mean Red Hat or the Linux kernel. Those devs get paid by their employers to work on open source projects that benefit their employers and also the wider community -- it seems like a really successful, scalable, sustainable model.
The people who are having a hard time are the indie devs, but let's be honest, being an indie dev who gives away software for free has always been, and always will be, a bad business model. It's not a good idea to do that for a living. It never will be.
Big failures like OpenSSL fiasco happened - where sure, company was sustainable but due to skewed priorities coz of funding (companies that founded it founded features that from perspective of any other company were bloat, and not enough work went into modernizing the code) the code was shit and full of traps.
And it's still a fact that vast majority of developers of stuff used everywhere wouldn't be able to do it as full or even part time job for financial reasons.
All while the corporate is pushing same "BSD/MIT good, GPL bad" agenda, coz they don't need to contribute anything back to stuff they take
Yeah and people eat it up.
"oh it won't have as many users"
well who cares? It's less hassle. Not like you get anything back from having 100x more downloads.
It isn't just the Indie devs it is the smaller businesses as well. Those are the ones pulling license changes, doing "freemium" models and other things that the OSS community is objecting to and the author is throwing shade at. Those models are NOT working well or we wouldn't be having these discussions.
The models that "work" for the coder are just tossing your code into public and not caring because it is a side project or something that you're doing to learn to code and you'll abandon it in a few years. Or else working for an existing Fortune 500 company getting hired to work on open source, or one of the few large open source foundations (sponsored heavily by massive corporations and/or academia).
And I worked for the past 10 years in open source at a startup-to-small-business getting paid by my employer for open source. That model is not very good, which is why we're seeing so many issues with "bait and switch" at those kinds of smaller corporations.
And that's it, no "enterprise editions", the only extra code you're paying for is backported critical patches, and deterministic builds of software (and all its dependencies) from source. RH puts a huge amount of effort into those builds, it's incredibly painful as an RH dev sometimes, but it seems to be a huge factor in building trust.
But, I can see why it doesn't really work for other companies, step 1 is "Be Red Hat, and have Red Hat's reputation."
I've been involved in Kafka a bit, and it's been very sad seeing Confluent devs having to deprioritise work on FOSS Kafka to focus work on stuff that, well, they can sell for money, but I totally get why.
The maintainers chose OSS. It's like taking out a loan then complaining about having to pay it back - either don't go OSS, or step down as maintainer.
This is the "bait & switch". It is planned right from the beginning, the tricky part is that you need to make the "it's completely free" phase as long as possible (using borrowed cash, investor money, whatever) to have as large a userbase as possible. And THEN switch.
It's literally the definition of "bait & switch"
They are changing license of the new stuff.
You are free to keep using whatever you were using forever. It's the same as a maintainer just abandoning a project and you having to take over.
At least that's their hope. And 90% of customers probably do, if they have reached a critical mass by that time.
* Bait = get as many people to use your software as possible * Switch = THEN change the license (for new additions) so that as few people as possible jump ship. Bonus points if you do it shortly before adding a cool new feature that lots of people are waiting for
Sometimes it works. Sometimes, Amazon is quicker and offers a product based on your version. The trick is to get the timing right...
it doesn't. It's a completely different argument.
You want support buy support.
If the FOSS license was such that it didn't restrict use, but only redistribution, then only the existing redistributors are licensees. The existing users have no rights.
If the new license says that unlicensed use is not allowed, then the users are now infringing. They didn't agree to any license in order to use the program when it was free and therefore they are not in any agreement that can be grandfathered.
Even if a license says that it's irrevocable (or some doctrine applies which makes it so, regardless) it can only be irrevocable to those users who have entered into the license. Those users may enjoy the continued right to redistribute the program. However, new users receiving the program do not benefit from the irrevocability; they have no existing license contract that can be grandfathered.
If a program has gone from FOSS to "cannot redistribute or use", the situation is like that existing licensees are allowed to give away copies, but the new users receiving them aren't allowed to do anything with those copies.
Software whose copyright holder has expressed revocation of a FOSS license should be regarded by all parties as a piece of radioactive or biohazardous waste.
Don't even think about maintaining a fork or anything of the sort.
No, that's not how it works. If libfoo 2.0 was released under an open source license, it remains so into the future.
If a company was the owner of that source code and decides the libfoo 2.1 is now suddenly proprietary and no longer open source they can certainly do that. But libfoo 2.0 remains open source and can be forked by the community or whoever wants.
There are many examples of this, for example Open Solaris. When Oracle bought Sun they quickly reverted Solaris back to closed source. But not even the (arguably) most lawyered-up tech company in the world can change history and change the license on the the previous Open Solaris releases.
That's how Solaris forked into the proprietary Solaris which Oracle still keeps alive and the open source descendants of Open Solaris (Illumos, etc.)
I would trust that only if the copyright holder makes it clear that they are not revoking the license for libfoo 2.0, but that libfoo 2.0.1 will be under a different license.
If they indicate that they wish to revoke the license for previously released libfoo 2.0, it seems they have the right to do that; I don't want to be the one testing it in court.
I don't know about the details of the Solaris/Oracle situation, but I doubt it hinged around it simply not being possible to revert a license, as such.
A company as aggressively litigious as Oracle would love nothing more than to kill off all Open Solaris forks. But Sun released Open Solaris with an open source license so it's not something they can change.
Consult a lawyer whenever you need to use an open source project, their opinion carries weight that mine does not.
At best they could take back the 100% Oracle-owned parts. The community would have to build to fill in the gaps.
They couldn't revoke any files that have, say, a BSD license, even if Oracle (or Sun, before them) had modified them and added their own copyright notice, simply because they would need to contact the original authors and act in concert with them; those authors would likely refuse.
I'm mainly talking about situations when the revoking party is actually 100% copyright holder to the majority of the files implementing the payload functionality, without which there is no software. I don't see how you the copyright holder would not have the right to revoke a FOSS license over it.
Based on what? None of the existing licensees have a signed contract of any kind, nor has any exchange of value taken place; allowing free redistribution and use was an uncompensated, unilateral action.
Even if there were a doctrine that existing redistributors were grandfathered forever, so they could continue making copies and giving it away, the license would not actually be available to the recipients, who are not existing licensees.
The U.S. Copyright Act indeed has the concept of termination:
https://cdas.com/copyright-termination-prime/
There are limitations to it for various obvious reasons, like that you can't terminate the copyright assignment implicit in a work for hire. (Because, doh, you were paid.)
No, that's not the case. By buying Sun, Oracle owns all the Open Solaris code.
Sun of course could not have open sourced code they didn't own the rights to open source in the first place. It was a long effort within Sun to scrub all the code to make sure. (This is why open sourcing proprietary code is a lot of work and most companies don't bother. Thankfully Sun did.) Some parts had to be distributed as binary blobs because Sun didn't have the ownership (over time there were separate efforts to rewrite these to reduce dependency on binary blobs).
> I don't see how you the copyright holder would not have the right to revoke a FOSS license over it.
Can you provide any examples where this has happened?
According to Section 203 (grants made after 1978), it looks like you have to wait 35 years, and then in a five year window after that, you can terminate.
So there is a way, but the copyright grantees have over three decades' worth of protection.
This law is for specific grantees; like Bob assigns the copyright to Alice (other than as a work for hire done for Alice). Alice is now the copyright holder. 35 years later, Bob has the right to say Alice is no longer the copyright holder.
Bob has five years to do it. Bob must write Alice some kind of letter. The termination date must be no sooner than 2 years, and no later than 10 years, from that letter.
A free software license isn't a copyright grant so the termination business, and its limitations, may be inapplicable. The users of software aren't copyright grantees, and those who are currently non-users aren't anything at all.
Now about the Open Solaris code; while some of it has copyright notices mentioning only AT&T and/or Sun Microsystems, there is a boatload of hits for "Regents of the University of California".
> Even if there were a doctrine that existing redistributors were grandfathered forever, so they could continue making copies and giving it away, the license would not actually be available to the recipients, who are not existing licensees.
Well, that doctrine is there: if you grant someone a copyright license and they take you up on it, they have 35 years before you can revoke it, in the United States.
It's not clear that third parties continue to have the same privilege after you indicate that the license is no longer available to new licensees.
I doubt such a case exists, but if it does I'd love to learn its story.
> If the FOSS license was such that it didn't restrict use, but only redistribution
That's not a FOSS license to begin with.
> If a program has gone from FOSS to "cannot redistribute or use", the situation is like that existing licensees are allowed to give away copies, but the new users receiving them aren't allowed to do anything with those copies.
Users still get the copy with the old license. The company can't go on your disk and edit the license after you obtained the software and the license.
> Don't even think about maintaining a fork or anything of the sort.
Amazon does it… I'm sure their legal department was consulted.
What legal precedent are you talking about?
In general, bare licenses (where the licensee does not give anything valuable to the licensor) can be revoked with sufficient notice. This is law in most jurisdictions I'm aware of. And this is taught to law students in their textbooks (heck if you just look up "bare licenses" in legal dictionaries you'll probably find something to that effect).
Do you have any standing to claim that OSS goes against this general rule?
The practical reason this doesn't happen is that revoking the OSS license of published code is pretty much un-enforceable and pointless exercise. There's no practical advantage that can be conceivably gained from such a stunt (unless you want the infamy for being the first person to attempt this), especially considering the PR fallout.
But I'll assure you that, if you actually try, and send emails to legal departments of sufficiently large companies notifying them that you revoked an OSS license of a project that you own, most of those companies will avoid using your projects and will try to transition away. I can't imagine any half-decent corporate lawyer advising the company that they definitely won't get into trouble because the precedent says OSS copyright owners can't do this.
FWIW I think some of them might actually tell you that you can't do this (which is mostly a bluff), but that's not going to be what they'll advise their clients/employers.
Disclaimer: IANAL but have a law degree.
If the software disappears from mainstream distros and its upstream repo is shut down, with notices that the free license has been revoked and forking isn't permitted, it's only a matter of time before it fizzles away.
If it's something of great interest to individual hobbyists, it might persist for years, but enterprises and institutions will not knowingly want to touch it. (If they really need it, they may seek licensing of the continuing proprietary version, if it exists).
If a security vulnerability is found in the code, it may need expert attention; but the experts will be required to perpetrate copyright infringement in order to fix it; it will have to be done anonymously. Then you need some place to host that and so on.
The proprietary version will have all the fixes and improvements, so that the old once-free version will just recede into the past as a broken old illegal version of a proprietary program, essentially no different from an ancient source code leak.
Your understanding is deficient. Some of the most popular free licenses like GPL and BSD don't restrict use. Users don't have to enter into the licensing agreement at all, only those who redistribute.
By using the software, you implicitly agree to the liability disclaimers, and that's about it.
All of the conditions in the license have to do with redistributing.
Licenses that restrict use in any way (e.g. "free for non-commercial use") are not free licenses.
> The company can't go on your disk and edit the license after you obtained the software and the license.
That's just a practical matter. If a license is revoked, the software will continue to be redistributed or used by people who don't even know about it. That doesn't mean it's legal.
The same thing could happen to software that was improperly licensed to begin with. E.g. a rogue employee took some code without company authorization and put it out with a free license. They can't go into people's disks and erase the bits, but the software is not legally free.
If you write a program and freely license it, such that Debian or Fedora pick it up, and then you write them a letter saying that the program isn't actually freely licensed, that it was a mistake, they will drop the thing like a hot potato.
The GNU project requires signed copyright assignments from contributors who make more than a trivial change. That protects (or hopefully protects) the projects from backpedaling problems.
And then the CEO of megacorp sends employees to come everyday and empty your foodbank and serve the food at the company canteen, because this saves the company catering money, and thus profit.
Yes, technically everyone's welcome at your food bank, but ... it won't be long before you'd stop doing it, right?
The implied nature of a food bank is providing food to those in need - I've yet to see a software where the implication is that the wealthy can't use it.
The point being made is that people getting upset when they are made to feel like their altruism is taken advantage of, let alone abused to ends that are against the spirit of the original work, and getting disillusioned and abandoning projects of love, is quite a natural and altogether human reaction.
OP said they didn't get why anyone would/should be particularly upset by megacorps using their open source software in perhaps not the manner originally envisaged. I was simply trying to come up with a more relatable example to relate why. The induplicability of food is completely irrelevant here.
> The induplicability of food is completely irrelevant here.
Then in what sense is the metaphor valuable? It was merely meant to depict an emotion that the humans on this forum will already be well aware of?
Open source was originally about the freedom to use software in new and creative ways, and NOT about giving away free stuff.
There is almost a point where, like all language, the original meaning becomes obsolete and a new one takes over.
Really, from the outside it looks silly - "I gave my code away, and now I'm not profiting from it!". Then at the same time all of the biggest, richest companies in the world are software companies because they chose not to do that.
To be honest I have no answers to the problem, and personally find most of the answers that do get thrown around dont pass the most basic of logic tests. So like you the only option I see is for developers to make the change, stop the freedom and the free ride.
What you're probably thinking of is "Public Domain." That's where a creator disclaims most (though not all) rights to the creation.
There is an idea pervasive within the developer culture that--through sweat and grit--one can build a project (regardless of FOSS or not) and eventually be recognized for the effort. And not just recognized, but recognized in a specific way. For some developers, that is notoriety. For others, it's money. But the idea is basically "my code in -> my definition of validation out".
And I think it's pretty clear that, for most projects out there, that's just not true. Or, more specifically, there is a huge chunk of the story that is missing. Because it's not hard to find dozens of projects in almost any niche, across thousands of niches. For the vast majority of them, they toil in obscurity. Some of them might be underdeveloped, but I see that more as a result of the failure to receive said validation leading to quitting the project. There is clearly some other factor involved in between creating a project and finding success with that project.
A lot of that missing element is selling. Even FOSS projects that are delivered free of charge to users need to "sell" themselves. Linux wouldn't be anywhere if Linus Torvalds hadn't recruited users. You have to convince people to try your thing and that convincing can take many forms. "Selling" is putting a name to "the act of convincing".
It's not quality code. It's not documentation. It's not a pretty website. Lots of failed projects have those things. Lots of successful ones don't. You have to market your project, and that's work.
Work that isn't coding. And that's why more developers don't do it.
Celebrity developers have people hanging on their every word on Twitter already. They have already done the work of advertising--advertising themselves--and now they cash in on the reputation and can make a successful project just by announcing it. Large corporations have money to pour into actual advertising and marketing for new projects. But independent developers don't have the cache or the money to be able to pull that off, and don't have the visibility into the background work on those other projects to know how their efforts are different from the projects they look up to.
But FOSS advocates keep pointing to the work of celebrity developers, of "open-source aligned" corporations, and saying "see, open-source can work". There's a lot of pressure from other developers to open your work. Most of the loudest voices keep saying, "this path works", leaving out the key element, making it sound like a dream.
I call this the "Field of Dreams Paradox". We have the phrase "if you build it, they will come" stuck in our cultural memory, but have forgotten that the movie is about a literal miracle.
Like, how is even say a single developer of mildly popular lib doing one thing gonna setup financing ? Or get people to pay ? Anything from patreon to tips was tried to mild results at best
If you give something away for free, you should not expect money for it. If you license it for anyone to use, you should not be surprised if some of the users end up being big companies. By choosing to give it away, you have chosen to give up control of what happens.
If you want to sell software for money, then do that. If you want control over how it is used, choose a license that gives you that control. But don't just give things away for free and then complain about what users do with the freedom you willingly gave to them.