<div dir="ltr"><div>(Comments by an irrelevant stranger).</div><div><br></div>I am rather surprised by this conversation.<div><br></div><div>This reminds me of the controversy related to Ethical Source software and the concept of "open source". This is relevant here, given the discussion revolves around the DFSG (Debian uses the two phrases synonymously, and the OSD is almost a verbatim copy).</div><div><br></div><div>The reason the ESM got lashback from many, myself included, has nothing to do with whether the kind of licensing they are promoting is good or bad, but rather with the fact that they described them as licenses "for open source", while this was not nearly the case.</div><div><br></div><div>"Free software" and "open source" are phrases relied upon by the community, by several documents, and even by governments to have a stable and clear meaning. The two movements are different and separate, but the class of software is quite well defined and nearly the same, with disagreements only on its very boundary.</div><div><br></div><div>It seems to me that something quite similar is happening here.</div><div>One question is whether a license which prevents running software to make proprietary software is acceptable.</div><div>A very different question is whether it qualifies as a Free Software license.</div><div><br></div><div>Of course, a free software activist will answer in the same way to both questions (since the free software movement believes only free software licenses are acceptable), but they are not the same question.</div><div><br></div><div>While the first question is inherently subjective, I think the second can be answered quite clearly with a resounding "no".</div><div>Freedom zero has always been understood to include participating in quite morally tainted activities. In fact, agreeing on morality is not necessary to know whether a piece of software meets this criterion.</div><div><br></div><div>DFSG guidelines 5 and 6 essentially codifies the same as freedom zero and, from all that I've seen, they are also commonly understood to include any kind of activity regardless of morality. This also makes the DFSG (or, more commonly, the OSD) a reliable standard that can be agreed upon.</div><div><br></div><div>Even if we were to erase guidelines 5 and 6 altogether, I'd argue that the meaning of the DFSG would essentially remain unchanged. The reason is that the way in which a software license would discriminate against fields of endeavour is by not providing those working in such fields the freedoms required by the other guidelines.</div><div><br></div><div>I feel that if someone wants to create a movement, or simply to define a set of licenses, which restrict the freedom to run the software when it is run for the purpose of making proprietary software, or for any other purpose that they disagree with, they should feel very welcome in doing so.</div><div><br></div><div>But the newly defined software licenses would not be free software licenses. That is a standard that ought to remain reliable and which people, communities and governments need to be able to continue reliably using, or rejecting.</div><div><br></div><div>> Would it be a restriction on freedom to run, since downstream could no longer</div>> run the program for *any* purpose, they could only run it for the purpose of<br>> compiling GPL'd software?  If not, why not?<br><div><br></div><div>The fact that free software *might* be copyleft is literally part of the Free Software Definition. And the DFSG should be read with historical context in mind: Debian clearly allows copyleft software and considers it to be free software.</div><div><br></div><div>If you make a derivative of a copyleft program, you are affected by the copyleft restriction. It really does not matter in the slightest which program you are running to build such a derivative.</div><div><br></div><div>If you have a copyleft compiler, and if the output of such a compiler is a derivative thereof, then copyleft does affect you when you distribute the output of the compiler, just as much as when you build a derivative of the compiler in any other way.</div><div><br></div><div>You are still, however, completely free and welcome to use the compiler for the purpose of making proprietary software, in a company that exclusively releases proprietary software as long as, of course, what you are distributing isn't directly the output of the compiler.</div><div><br></div><div>In addition, if you are able to alter the output of the compiler such that it no longer includes significant portions of it, then the copyleft clause no longer affects you.</div><div><br></div><div><br></div><div>Copyleft is the strongest, and most controversial, restriction which can exist in a free software license. I think trying to extend the meaning of "free software" by watering it down with other, newer, restrictions (ones that, by the way, can't even rely on the same legal hooks as the others) would be a really dangerous move.</div><div><br></div><div>I find it also questionable whether such a clause (which, interestingly, exists in some proprietary software, such as Visual Studio Community) even works well in practice.</div><div>One can build some software components, which they need in their own software, under a public-domain equivalent license, then use them in whatever proprietary software they are building. Of course, this can be mitigated with other newer stronger restrictions, thus getting even further from software freedom.</div><div>I'd also like to hear what the plan is for allowing free distribution of a piece of software, yet making sure any recipient signs contractual clauses.</div><div><br></div><div><br></div></div>