RMS On Header Files and Derivative Works

tomhudson writes "In this email from 2003, Richard Stallman says 'I've talked with our lawyer about one specific issue that you raised: that of using simple material from header files. Someone recently made the claim that including a header file always makes a derivative work. That's not the FSF's view. Our view is that just using structure definitions, typedefs, enumeration constants, macros with simple bodies, etc., is NOT enough to make a derivative work. It would take a substantial amount of code (coming from inline functions or macros with substantial bodies) to do that.' This should help end the recent FUD about the Android 'clean headers.'"

Comments

Re:How the fuck do we define a "substantial amount

[Anonymous Coward]

How the fuck do we decide what a "substantial amount of code" actually is? Where exactly is the boundary?

Free Software zealot: "substantial amount of code" == one line

Corporate America: "substantial amount of code" == entire program.

IP Lawyers: "substantial amount of code" == new Porsche.

Re:Copyrights on facts

[OddJobBob]

Express Logic have already been through this when Green Hills released their RTOS using the ThreadX API from Express Logic. In this case the arbitrators ruled in favour of Green Hills even though the header files were copied.

Re:end FUD ?

[tomhudson]

Copyright law already addresses this in the general case. RMS got his opinion from lawyers who know about the specifics of copyright law, that there are plenty of things that are not copyrightable. And yes, in the US this IS settled law, unless you know of a higher court than the Supreme Court of the USofA.

In the more specific case of linux, you might also want to see the COPYING file, which is a modified version of the GPL v2 that explicitly states that using the header files to access kernel services doesn't create a derivative work, which was the whole point of the FUD-packers campaign, to convince handset manufacturers that there was a risk that their Android code was a derivative work and they'd have to share their source.

Hope this clears it up a bit :-

Re:Copyrights on facts

[tomhudson]

First, despite your claim, you are not a lawyer. You have too many basic facts wrong.

Second, facts cannot be copyrighted, any more than the rules of a game can be.

ONLY the presentation or layout of those facts can be copyrighted. And it is ONLY the presentation or layout, not the underlying facts, that are protected.

Unique definitions are also not sufficient of themselves for copyright in software, if that unique definition is either required for interoperability, or is the only way to do something.

For example:

#define ERR_ANY -1
#define ERR_SEEK -2
#define ERR_WRITE -3

is not copyrightable.

url:http://www.ivanhoffman.com/scenes.html

Under the merger doctrine, courts will not protect a copyrighted work from infringement if the idea underlying the work can be expressed only in one way, lest there be a monopoly on the underlying idea. In such an instance, it is said that the work’s idea and expression “merge.” Under the related doctrine of scenes a faire, courts will not protect a copyrighted work from infringement if the expression embodied in the work necessarily flows from a commonplace idea….

The Court went on, in part quoting from the famous litigation between Microsoft and Apple:

Likewise, when similar features of a work are “as a practical matter indispensable, or at least standard, in the treatment of a given idea, they are treated like ideas and are therefore not protected by copyright.”

Re:Copyrights on facts

[binkzz]

#define ERR_ANY -1
#define ERR_SEEK -2
#define ERR_WRITE -3

is not copyrightable.

What about:

#define ERR_PS3 0x46DCEAD317FE45D80923EB97E4956410D4CDB2C2

:-"

Re:Copyrights on facts

[UnknowingFool]

The relevant case law on this is Gates Rubber v Bando.

It established the abstraction-filtration-comparison test in whether copyright code is infringing. Abstraction is the first step and gets the relevant source code. In filtration, any part of the code that cannot be copyrighted must be eliminated for consideration. One thing that must be excluded are facts. For example, many programs that draw circles rely on using Pi. A company cannot copyright PI =3.14159 as this is a fact. Anything in the public domain are excluded. This is where SCO would have had lots of problems because even if the code was legally owned by them (it was owned by Novell), some of what they claimed to be theirs had been put into the public domain by AT&T, USL, BSD, and others over the years. Header files (especially the simple ones that are merely #include statements) can fall under scenes a faire. Standards also fall under this category. Scenes a faire are all the elements that are required for any program of the same type to run. Variable declarations for example. If a program works with files, the owner can't really claim "File file = null" is copyrightable as a variable declaration.

Only after filtering out non-protected elements, can any comparison begin. That was one of the arguments IBM had against SCO: IBM's expert claimed that SCO's expert, SCO VP Gupta, had failed to filter out unprotected elements of code. Two examples of the alleged violating code were the IPC and ELF header files. The IPC header had been put into public domain without copyright since 1989. The ELF header was published as part of the ELF specification whose membership included SCO's predecessor, Santa Cruz. By the way, IBM's expert was Brian Kernighan who worked with Ritchie and Thompson on Unix, wrote the first book on C with Ritchie, and wrote some Unix programs like cron.

Re:end FUD ?

[Belial6]

I agree with RMS on this one. So, now you have it from the highest source.