[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GPL traitor !

From: Alan Mackenzie
Subject: Re: GPL traitor !
Date: Mon, 11 May 2009 17:41:32 +0000 (UTC)
User-agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (FreeBSD/4.11-RELEASE (i386))

In gnu.misc.discuss Hyman Rosen <> wrote:
> Alan Mackenzie wrote:
>> The notion of "inclusion" doesn't make sense when talking about computer
>> programs.  Tell me, is an intricate C Macro "included in" or "referred to
>> by" the extension?  What about a data structure it uses?

> Referenced by. Macros are directions to the compiler on how to translate
> code to which they are applied.

Then exising C functions are also referenced by the new code.  The syntax
for the two is almost, but not quite, the same.  (Believe me, I know a
lot about the syntax of C.)

> Similarly, data structures are ideas and inventions, not text.

Data structures are text.  Of course they are.  They're typically written
in ASCII text.  If they're not written, they're not data structures -
they're just ideas, of some degree of vagueness, of what might one day
become a data structure.  No, you can't copyright the vague notion.  Yes,
you can copyright the embodied, written data structure.

There's no fundamental difference between "functions" and "data
structures".  Functions are also just "ideas and inventions".  Either can
be formally expressed as the other.  "Code" in an interpreted language IS
just data, a structured string of characters or a linked list, later
processed by an interpreter.  John McCarthy knew that back in the late
1950s.  Given that, say, a Python program is "merely" data, would you
maintain that copyright doesn't apply to it?

Yes, there are some computer languages that enforce an artificial
distinction between "data" and "code", often for good reasons (you're
an Ada hacker, aren't you?), but even that breaks down in languages
like C++ (where (class) data elements are often functions) and Java (in
which all functions are class data elements, or something like that).

> You can patent them, but you cannot copyright them, and using data
> structures does not subject a program to the copyrights of the support
> library.

What support library?  We're not talking about "support libraries", at 
least I'm not.  We are talking about the detailed internal expression of
the core of a conceptually coherent program.  A "support library" might
well be distinct, for copyright purposes, from what uses it.  Normally it
would be liberally licensed anyhow, so who cares?

If you can't copyright a data structure, you can't copyright a function.
They're the same thing.  Please tell me you're just winding me up.

> There might be a case made for things like C++ template libraries
> subjecting compiled programs to their copyright when those libraries
> come with large amounts of code that appear translated into the output
> with minor parameter substitutions.

C++ template libraries are copyright.  Their external interfaces are
(I think) usually in the public domain.  Their internals are copyright.
Their license is "use how you like in code produced by my compiler".

> Perhaps sufficiently large C macros might qualify as well.

C macros often straightforwardly generate bits of functions, in fact
often are just sequences of statements with a #define at the top and
backslashes at each EOL.

>> In that case, the extension is derived from the source code of the data
>> structures, and thus isn't a "separate" new work.

> You are again using the word "derived" in it English sense, which is not
> relevant. Copyright recognizes the concept of a "derivative work" (not a
> "derived" work, which has no meaning in copyright law).

You're being unnecessarily pedantic and very parochial here.  There will
be hundreds, if not thousands, of different words used in copyright law
for this concept.  "Derived work" is just as good as "derivative work" in
this newsgroup.

> A derivative work is a work that is a significant auctorial
> transformation of an existing work, and the concept of derivative work
> exists in order to handle the issues of copyrights belonging to both
> the original author and to the transforming author.

I was using the word "derived" in that sense.  Writing a code generator
to transform data in one highly complicated data structure (the
compiler's intermediate form) into another highly complicated data
structure (the target OS's object format) is a significant auctorial
transformation of these data structures, not a trivial one.

> Copyright does apply to characters created by an author. You might try
> to apply the novel and amusing argument that the data structures of a
> program are equivalent to the characters of a novel, and so their use
> in another program violates the original author's copyright.

It's a reasonable, if imperfect, analogy.  Please explain why you don't
think that a novel's (human and animal) characters aren't just "ideas
and invention" the way you say data structures are.

You can't copyright the idea of a male space ship commander, but you can
copyright Captain James T. Kirk.  You can't copyright the idea of a
compiler's intermediate data format being a linked list in memory, but
you can copyright the particular instance of it which is part of GCC.

> You would lose, though.  Courts like interoperability and frown on
> using copyright to prevent it.

Just where do you get that notion from?  It's the first I've heard of it.

> > Interoperability has nothing to do with what's been discussed so far.

> It does - using the data structures of another program in order to interact
> with it is exactly interoperability.

Only if there are two programs involved (otherwise we'd have "intra", not
"inter").  In the scenario I've been describing, there's only a single
program involved.

Interoperability is a strong practical argument in favour of the GPL and
other licenses which enforce the ability of hackers to create
interoperable programs.

It's kind of surprising that the courts don't enforce the disclosure
of programs' internal data structures to facilitate interoperability,
isn't it?

> If the copyright holder of a GPLed program is attempting to deprive
> the author of a program which interoperates with it (such as a plug-in)
> ,....

Oh, come on, Hyman!  I have not been talking about "plug-in"s, i.e. the
software equivalent of a device with a standard three-pin plug that you
plug into a standard three-hole socket.  Such a beast is what the GPL
means when it talks about "a reasonably independent work".

> .... of his copyright rights, that is exactly trying to prevent
> interoperability using copyright.

Rubbish!  The GPL copyright holder wishes to maximise interoperability.
A non-free extension of a program is less i11e than a GPL'd extension.
For example, when the internal data structures of the program get
amended, the non-free extension becomes non-i11e, whilst the free
extension will get amended alongside the rest of the program.  This is
why Linux far prefers free drivers to proprietary ones.

Anyhow, your talk of i14y tacitly assumes two existing pieces of code
which could be combined, but for copyright restrictions.  What I am
talking about is an extension of an existing program specifically
intended for it.  The i14y is entirely in the hands of the extension's
author, who will know about the program's licensing terms before he even
starts writing his extension.

>> One of the central aims of the GPL is to promote interoperability, as
>> you're well aware.

> I'm not aware of any such thing. The aims of the GPL are that users of
> computer programs should have the right to run, read, modify, and share
> those programs. Where does interoperability enter the picture?

Being able to read and modify programs enables you modify them to be
i11e with other programs, or to modify the other programs for the same
purpose.  For example, if the SMTP protocol gets extended, it's easier
to amend a GPL'd mail transport agent than a proprietary one.

Alan Mackenzie (Nuremberg, Germany).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]