Re: Inconsistencies in our approach
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 <jgoerzen@complete.org> www.complete.org
Reply to: