On Thu, Aug 07, 2003 at 11:00:02PM +0100, Andrew Suffield wrote: > > Actually, my goals are the opposite. I see it as intellectually and > > logically dishonest to claim certain requirements for some types of > > non-program data in Debian, other requirements for other data, and do it all > > under the guise that "everything binary is software." > > What requirements, exactly, do you think are being made of some things > and not of others?
I see us requiring RFCs to be mutable, but ignoring the fact that we distribute the GPL, which is not. I see this as also being contradictory with many of the arguments against the FDL. > > There is neither source code nor compiled code for my King James Bible in > > free-form ASCII text. > > This is an example of why they are guidelines, not rules. It is simple > for an intelligent person to interpret this in a sensible manner for > documentation. If by "interpret" you mean "ignore DFSG #2", which seems to be what happens in practice, OK. But is that really the kind of thing you want to do? What would you tell me, as an author, to do to distribute something that can be compiled into machine code out of my plain text prose? This has become a problem in practice. I have witnessed attitudes towards things like the RFC and Emacs manual change within the past few months, despite the fact that our guidelines have not changed, and neither have their licenses materially altered the nature of users' freedoms within that timeframe. Simultaneously, we allow texts like the GPL, which fail if one applies the same rules to them, into the distribution. The DFSG should be dynamic with regards to dealing with new licenses and new software issues. It should not be dynamic regarding applications of existing principles. Nor should it be so dynamic that people attempt to make arguments like you do below for discrimination in favor of things that might otherwise be considered non-free. > We have not, to date, had any difficulty in interpreting the DFSG as > applied to documentation, excluding the lunatic fringe who appear, I think that the persistence and size of this thread provides more than enough evidennce to debunk that claim. > In all the FDL debates, there has not once been a solid argument that My comments are not limited to the FDL debate, but seek to address a more fundamental question: Do software guidelines serve us well for non-software items? My answer is no, but obviously it is being discussed. My mind is open and I remain willing to accept that there may be someone out there that can come up with equitable guidelines. But I perceive a very real inequity in the very prominent example I keep citing in the GPL. > > Why is it OK to include the GPL in our system but not other bits of > > documentation? > > This is virtually a FAQ. > > Firstly, even if that statement was not present, the license would > still be unmodifiable and non-removable; that is the nature of > copyright. The license would be unmodifiable and non-removable *solely as it pertains to the package to which it was affixed*. However, barring protections on the license itself, I could take the text of the GPL, modify it, and apply the modified version to my own software -- or just publish the Goerzen Public License version 2. (Nah, that wouldn't be confusing at all...) The copyright statement on the GPL prevents me from doing this. It seems *very* similar to the RFC problem. > Secondly, there is no convincing reason to believe that this statement > is binding in law, because nobody has presented any evidence that > copyright subsists in a license _at all_. Remember, copyright is not a > natural thing, it was invented in the past few decades in order to > improve the profit margins of corporations. In U.S. law, copyright was actually codified in our *constitution* in section 8, clause 8. That was passed just a we bit more than a few decades ago. However, your argument has a lot of problems. First, that which is the case with U.S. law may not be the case internationally. On this list, we have always erred on the side of caution, assuming that the requirements in a license are legally enforceable. Or are you suggesting that we should special case the GPL? Secondly, there are pending court cases right now in the U.S. alleging copyright violations from legal papers filed in court cases. Thirdly, there is legal precedent for restrictions on the distribution of licenses (which are just a special case of contracts), though usually from a trade secret point of view. > Thirdly, we are distributing software, not licenses. We wouldn't > include them at all if we didn't have to; we only accept them because > forces beyond our control require us to. Are you really saying that we have been violating our own Social Contract for years because we either lack the power to remove the GPL from our distribution or the will to switch to non-GPL software? I find that a rather farfetched notion. I don't see anybody forcing us to ship the GPL on our hard disks. I do see us required to put it there *if we distribute GPL'd software*. But that's the rub, isn't it? We're only required to distribute those invariant sections if we distribute the manual. So we're back to removing the GPL by the same argument that removes FDL documents. -- John Goerzen <[EMAIL PROTECTED]> www.complete.org
