4 ms·

>Short answer: no, FOSS couldn't possibly work without the ability to modify and redistribute, and licenses that attempt to suggest otherwise get rightfully rej

>Short answer: no, FOSS couldn't possibly work without the ability to modify and redistribute, and licenses that attempt to suggest otherwise get rightfully rejected before they can proliferate. The ability to modify and redistribute continues to exist; the limitation should be equivalent to something like, "You are not allowed to use this unless you have a license", similar to the "You are not allowed to use this unless you agree to the licensing agreement" that many Linux distributions use to preface installation of the Oracle JRE. You are free to disagree but I do not see any necessity for the provisions of the GPL that allow unlimited redistribution as long as source is included. It's not that I don't want people to use the GPL or that I don't find it worthwhile or noble to release software as GPL, it's just that I don't feel freedom 2, "the freedom to help your neighbor [whether they have contributed or paid anything or not]", is an essential component for all software. I do believe that source should be included with all software, so I think there is a good middle ground somewhere out there and I want someone to seize it. I want the image to be perpetuated that giving your users source code isn't the same thing as bankrupting your company and/or resigning yourself to profit only on supplementary "support services". I don't like the image that has been perpetuated by things like the GPL that a source release == complete unsellability.

JoshTriplett 15y ago
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. Take a look at this entry in the GPL FAQ: https://www.gnu.org/licenses/gpl-faq.html#ReleaseNotOriginal 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. :)
- cookiecaper 15y 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.
  - JoshTriplett 15y ago
    OpenJDK has become the official JDK/JRE at this point (see http://blogs.oracle.com/henrik/entry/moving_to_openjdk_as_the http://blogs.oracle.com/henrik/entry/moving_to_openjdk_as_th... for an official statement to that effect from an Oracle developer). The proprietary JDK/JRE represents legacy software. 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/282261/ , https://lwn.net/Articles/246381/ 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.

JoshTriplett 15y ago

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. Take a look at this entry in the GPL FAQ: https://www.gnu.org/licenses/gpl-faq.html#ReleaseNotOriginal 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. :)

cookiecaper 15y 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.
- JoshTriplett 15y ago
  OpenJDK has become the official JDK/JRE at this point (see http://blogs.oracle.com/henrik/entry/moving_to_openjdk_as_the http://blogs.oracle.com/henrik/entry/moving_to_openjdk_as_th... for an official statement to that effect from an Oracle developer). The proprietary JDK/JRE represents legacy software. 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/282261/ , https://lwn.net/Articles/246381/ 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.