Ignore freedom 2 for a minute, and consider freedom 3: Free Software (and Open Source Software) requires the ability to distribute modified versions. That freedom can't meaningfully exist without also allowing the ability to distribute unmodified versions (since you could just make a trivial modification and redistribute). So, freedom 3 necessarily implies freedom 2, and you can't have FOSS without freedom 3.
What you've suggested amounts to the "shared source" model of "look but don't touch".
You also entirely ignored my point that the GPL still makes it possible for companies like id to easily profit from sales of their engines, without having to add further restrictions.
Also, the JRE became Free Software under the GPL several years ago. :)
>Also, the JRE became Free Software under the GPL several years ago. :)
No it didn't. The official JRE and JDK are both still proprietary software. That's the whole point of OpenJDK.
People can distribute modified and unmodified versions within a pool of licensees under my suggested license. That's the primary difference: instead of allowing wide and clear redistribution by any recipient to anyone else, you may only redistribute to persons with licenses.
Dual-licensing under the GPL is not really relevant here. There are good reasons not to dual-license. While it may work for id's case, it doesn't work in every case, and it's not the same thing: under my proposal no one would be entitled to a copy of the software until they satisfied conditions sufficient to obtain a license from the vendor. Under the dual-license scheme anyone content with GPL can use GPL without obtaining a specific license from the vendor.
As for the rest: you keep re-explaining what you want, but thankfully that won't make it happen. You can try to build a community around such restricted code, but FOSS has progressed more than far enough that restrictions of the form you suggest simply can't gain enough traction to take hold; you'd have to build a community from scratch, in the face of an openly hostile immune reaction from the FOSS community. More importantly, by adding such restrictions you remove several of the mechanisms the FOSS community has to protect itself from various critical failure modes, which makes such a scheme inherently doomed to fail in the first place. In a way, the reaction you'd get from the FOSS community comes from that community knowing that such a scheme can't work, and wanting it to fail quickly before it causes more of a distraction.
Among many other reasons, FOSS can't succeed when tied to a single privileged upstream vendor. Development of good ideas requires a community that can make changes the upstream vendor never thought of and doesn't immediately approve of, and any scheme that requires a license from the upstream vendor can't support a community like that. Such a scheme would also create a fragile community that the vendor could destroy at any time. Ironically, the possibility of forking a project and running with it in a different direction helps avoid fragmentation and prevent a variety of standard failure modes for a development community.
The FOSS community has numerous examples of successful forks, where the project just moved entirely to the fork and ignored the now-irrelevant original, and would otherwise have just died or stagnated indefinitely. A very short list of examples: Jenkins (forked from Hudson by the people actually working on it), LibreOffice (forked from OpenOffice.org by the people actually working on it), Xorg (forked from XFree86 by the people actually working on it), cdrkit (forked from the last FOSS version of cdrecord before the maintainer became even more visibly insane than previously demonstrated), EGCS (forked from GCC at a time when GCC had utterly stagnated due to excessive centralized control, and became the new GCC because all the development moved there; we could use a repeat of that right about now).
Take a look at https://lwn.net/Articles/282261/ , https://lwn.net/Articles/246381/ , and the various things Linus has written about "commit access" as a broken model. You can't have independent development when everone needs a license from one vendor, and you can't have FOSS without independent development. You certainly couldn't have a world where numerous companies, even competitors, can all cooperate in the same community and produce something useful.
I keep rephrasing myself because you seem not to understand. I am not suggesting that this model should replace the GPL or more permissive licenses entirely. I am not suggesting it will crush or destroy all free software and all extant models of free software licensing or development. I am merely suggesting a middle ground that would get source in the hands of licensed users instead of leaving them with nothing and promoting the idea that distributing source is the same as ruining your investment.
I understand that this would be more restrictive because it wouldn't allow you to share with certain people. The details, of course, are dependent on the final language of this hypothetical license, but as I said I would like most of the burden of compliance to rest on the individual consumer and not the publisher, i.e., "Do not use this if you do not have a valid license". This is not any different than what we have now -- commercial vendors put out closed-source software that says "You promise not to use this unless you are supposed to" in the EULA and this is blatantly violated by those who choose to pirate the software. I don't see how or why releasing the source would make this any worse, and I think it stands to improve profitability from specific games significantly.
You seem to believe that under this license forks would be impossible. I don't understand why you think that. Forks are by definition derivative works ("modified code") and as long as you comply with the license restrictions on distribution you can continue to release and host forks on GitHub et al.
Don't assume that people who disagree with you simply don't understand you.
I don't mean "fork" in the sense of "hit the fork button on github to do a 'git clone'". I mean "fork" in the sense of "I've taken over maintenance of this project due to lack of maintenance or fundamental disagreements with the existing maintainers". You can't usefully fork software in that sense when the original authors maintain effective veto power over the entire community. The ability to fork software in that way, though rarely actually invoked, prevents a large number of problems simply by always remaining an available option.
Apart from that, you've just attempted to reinvent a new way of profiting from proprietary software, except that numerous vendors have already tried it in numerous forms and failed. Heed the warning. Or, alternatively, don't: http://www.despair.com/mis24x30prin.html
If you want to write proprietary software, do so. If you want to foster a development community around your source code, do so. Don't try to mix the two; you'll annoy both sides, and that won't end well.
>Don't assume that people who disagree with you simply don't understand you.
It's not that you disagree, it's that you imply that forks would be impossible or that the suggestion amounts to "look but don't touch". These suppositions are clearly NOT what I am saying, so I am replying to correct and/or clarify my position.
I don't really have anything new to contribute to your arguments other than I consider a license grant irrevocable based on purchasing the game or whatever. Just as you can't go take back someone's copy of Windows because you don't like their political views, you shouldn't be able to go and take away someone's license for new_game because you disagree or think they should have paid more or whatever. It is true that under this proposition the original author would have to be paid if you wanted to use a fork and had never paid for the original copy of the software.
And if the original author disappears, or stops selling licenses at all, or changes their license to "we will not sell you a copy if you use $OTHER_FORK"? As I said, the original author can easily kill the entire community or any individual part of it at any time.
Consider what would have happened if Oracle had that kind of power over the communities that formed LibreOffice or Jenkins; those projects wouldn't have survived in such an environment.
On top of all of that, what makes the original author so special here? The community adds a huge pile of value, often more than the original author, and yet only the original author gets to demand payment? Or should this become like the NetBSD license's ever-accumulating attribution clauses, with a hundred different authors to pay license fees to?
It looks like you are having a relatively in-depth discussion and your earlier exchange reminded me of a recurring question I have. I've posted the question but no one seemed to have interacted with it. Would you be so kind as to take a look? Here it is:
Take a look at this entry in the GPL FAQ: https://www.gnu.org/licenses/gpl-faq.html#ReleaseNotOriginal
What you've suggested amounts to the "shared source" model of "look but don't touch".
You also entirely ignored my point that the GPL still makes it possible for companies like id to easily profit from sales of their engines, without having to add further restrictions.
Also, the JRE became Free Software under the GPL several years ago. :)