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.
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"