Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Android GNU is Not Unix Google Software Linux Technology Your Rights Online

RMS On Header Files and Derivative Works 247

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.'"
This discussion has been archived. No new comments can be posted.

RMS On Header Files and Derivative Works

Comments Filter:
  • Copyrights on facts (Score:5, Informative)

    by nickovs ( 115935 ) on Sunday March 20, 2011 @11:44AM (#35550732)

    I've hear it suggested by a number of lawyers that the _specification_ a binary interface of a library is a statement of fact, rather than a creative work. Since copyright does not apply to statements of fact this would suggest that structure definitions and the like would not be subject to copyright, and by extension the is no issue regarding derivative works. Of course you could probably as the same lawyers on a different day (or with a different person paying the bills) and get a different answer, but the concept seems to make sense.

    • This copy of Photoshop CS I've got installed is also a statement of fact, by the way. I love lawyers!
      • This copy of Photoshop CS I've got installed is also a statement of fact, by the way.

        Simply asserting that doesn't mean a court would agree with you. Given that the current discussion about "statement of fact" was specifically about *header files* only, what basis do you have for this statement?

        • by rtb61 ( 674572 )

          The reality is a lawyer will agree with any opinion the client has to make as long as there is a pay check in it. Of course that agreement will be in politispeak that can be interpreted six ways from Sunday afterwards.

          When it comes to Open Source software it most often will be only subject to community discussion, with only blatant egregious examples of copyright infringement being subject to legal review.

          The community surrounding any open source project is going to be far more interested in keeping th

          • What you say is true- however, the OP's original statement related to the uber-closed-source Photoshop CS which had nothing to do with open source. I suspect that the OP's original assertion was simply a lame, half-baked, no-thought-put-into-it, misguided attempt at reductio ad absurdum- which was wrong, because the discussion only related to header files, not to complete closed-source software programs.
          • by abulafia ( 7826 )

            The reality is a lawyer will agree with any opinion the client has to make as long as there is a pay check in it. Of course that agreement will be in politispeak that can be interpreted six ways from Sunday afterwards.

            Only if you have a shitty lawyer. Good ones actually add value, help strategize and avoid risk. It helps to remember that of any cohort, half are below average.

            • Half are below average? 1, 1, 1, 1, 1, 1, 1, 1, 1, 11 What is the average of these numbers? What percentage of them is below that average? (Answers: 2, and 90%)
              • Half are below average? 1, 1, 1, 1, 1, 1, 1, 1, 1, 11 What is the average of these numbers? What percentage of them is below that average? (Answers: 2, and 90%)

                On average, people have less than 2 feet :-)

              • I find it odd that you have a signature proclaiming your hate of grammar nazis, then you post something like the above. Grammar nazis are people who are overly pedantic about the structure and syntax of language, while you are being overly pedantic about the use of a fairly common word, which happens to have many related meanings in colloquial usage. In colloquial English, an "average" is any measure of central tendency. Even in mathematics, "average" is a somewhat ambiguous term, and can refer to the ar

                • Yes, the arithmetic mean is not a resistant measure of center, and can be influenced dramatically by outliers. On the other hand, in a normally distributed set of data, the arithmetic mean and the median will be equal. In many populations, many of the statistics that you could measure will be (approximately) normally distributed.

                  That's a fair point. However, the argument that mean ~ median puts the cart in front of the horse. Why not just calculate a median in the first place? Then at least you don't

    • by OddJobBob ( 1965628 ) on Sunday March 20, 2011 @11:55AM (#35550874)

      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.

    • by UnknowingFool ( 672806 ) on Sunday March 20, 2011 @01:03PM (#35551404)
      The relevant case law on this is Gates Rubber v Bando [groklaw.net].

      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 [groklaw.net]. 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.

      • Remember that the abstraction-filtration-comparison test is applicable to cases in the 10th Circuit. Other circuits have different tests. Until the Supreme Court weighs in, copyright law will in effect be different in different parts of the US.
        • by DrJimbo ( 594231 )
          According to the Wikipedia [wikipedia.org]:

          The AFC test was developed by the United States Court of Appeals for the Second Circuit in 1992 in its opinion for Computer Associates Int. Inc. v. Altai Inc. It has been widely adopted by United States courts and recognized by courts outside the United States as well.

      • Computer Associates International, Inc. v. Altai, Inc. http://scholar.google.com/scholar_case?case=6976925648486076739&q=Computer+A [google.com] ssociates+International,+Inc.+v.+Altai,+Inc.&hl=en&as_sdt=2,23&as_vi s=1 This is where the abstraction-filtration-comparison process was used in a copyright and trade secret case. The process the court must first determine the allegedly infringed program's constituent structural parts. Then, the parts are filtered to extract any non-protected elements. Non-p
    • Have you ever looked inside the standard header files for your C compiler? The C function prototypes are only a small part of the text that the typical header file contains. There's also lots of comments and extra definitions that do not form part of the C standard, and lots of conditional branching and (nonstandard) include paths for machine specific include files etc.

      I'd guesstimate that the actual prototype definitions are at most 20% of the total line count on average. The rest is pretty much unique

      • I'd guesstimate that the actual prototype definitions are at most 20% of the total line count on average. The rest is pretty much unique to the given compiler, and there's no way anyone could claim that it's not creative or copyrightable.

        I think a reasonable argument is that the function/enum/union/struct definitions are themselves fact (and therefore not subject to copyright), whereas the mechanism used to express them on a given platform (compiler+os+extra) is another issue entirely. Similar to the pho

        • To extend your analogy, imagine that the phone company, for purely internal reasons, introduces many extra fake names with fake addresses. More than there are real names and real addresses. This is what actually happens. On my system, the stdio.h header defines the name FILE as follows:

          typedef struct _IO_FILE FILE;

          This says that the (published C standard mandated) FILE is an (unpublished, nonstandard) _IO_FILE defined in some (nonstandard) header file called libio.h. Now _IO_FILE is just there for the c

      • Yes but. My reading of Google's process for the Linux headers is that they specifically strip out all the comments and complex macros such as what you describe. Their readme even describes how they optimize some macros to make them simple (by short circuiting or otherwise). Presumably they do this to optimize but also to make them trivial and therefore free to distribute in a non-gpl header.

  • Can someone explain something to me... how does anyone but Linus Torvalds have the standing to file an action or even complain about this? He owns the copyright, shouldn't he be the one that decides that something is in violation.

    I know that FSF has brought actions in some rare cases, but isn't that on behalf of the real owner of the copyright?

    Anyway.. it does seem like if FSF and Linus don't have a problem with what was done there is nothing to talk about. Am I oversimplifying this?

    • Comment removed based on user account deletion
  • People think RMS is unreasonable and as grasping as some of the commercialists he decries. Not in my experience.

    I've had the same sort of [slow] email chat with him, and he is far more technical (and reasonable). I wouldn't want to speak for him, but the closest I got was that if source produced executable binary, then it was derivative. If the included source only affected the production of executable generated by other source, it was not derivative.

    • I guess people are talking C? I program C++ with the classes in the .h files, using the .cpp files only to determine which root classes get created. Criticize me for not following good practices, but I do this to simplify translation of programs between C++ and Java, where everything is done in terms of classes and there is only the one .java type source file.

      So at least in C++, the header files could just specify interfaces or they could specify the entire program source code.

      • by sribe ( 304414 )

        I guess people are talking C? I program C++ with the classes in the .h files, using the .cpp files only to determine which root classes get created. Criticize me for not following good practices, but I do this to simplify translation of programs between C++ and Java, where everything is done in terms of classes and there is only the one .java type source file.
        So at least in C++, the header files could just specify interfaces or they could specify the entire program source code.

        Right, consider templates... The "header files are often not copyrightable" refers to the kinds of header files that include only simple declarations, not implementations. It's not really "header files" that are not copyrightable, it's the kind of API description & definitions that are often (but not always) the sole content of header files.

        • This is my big gripe with C++ especially with templates. It just feels absurd to shove everything into a glorified macro, especially when compilers are no where good enough to collapse essentially identical instantiations to avoid bloat. And yet this is being promoted as the proper way to do things. I mean if you have both an STL list of integers and of unsigned integers almost every linker will leave two duplicates of the code in the executable. That's why this style only exists on PCs where the users

          • by sribe ( 304414 )

            Have you *really* looked at what is output? Your examples should actually result in almost no functions at all, because a great deal of the code is simple enough to always inline--assuming you have a decent compiler and you're looking at optimized builds. You can indeed generate a huge amount of bloat with naive use of templates, and sophisticated use of templates is a black art. But one of the neat things about templates & C++ is how amazingly efficient the code generated by "high-level" abstractions c

      • I guess people are talking C? I program C++ with the classes in the .h files, using the .cpp files only to determine which root classes get created. Criticize me for not following good practices, but I do this to simplify translation of programs between C++ and Java, where everything is done in terms of classes and there is only the one .java type source file.

        So at least in C++, the header files could just specify interfaces or they could specify the entire program source code.

        Your project must then compile as only one object, and a change to just one line of code triggers a complete re-compile of the object. This prevents you from reusing your unmodified static or shared libraries in a new compilation -- No boundaries exist such as threading library, network library, etc... If so, when the executable binary application is built it must compile all that other code too (single translation unit), each time, even if the none of the classes change. Your everything in the .h metho

        • You can't put method bodies in a separate .cpp file if you use templates. When your library is mostly templates (like Boost), then all its code must necessarily be in the header files.

          This does not mean that the code in the headers can "still be reduced to just the interface facts".

          • You can't put method bodies in a separate .cpp file if you use templates. When your library is mostly templates (like Boost), then all its code must necessarily be in the header files.

            This does not mean that the code in the headers can "still be reduced to just the interface facts".

            You are misinfromed. Yes you can, see this example [parashift.com]. You can separate the template interface and implementation; However, in order to instantiate a template you must have access to the implementation. Libraries can provide just the template interface and a .so with commonly used instantiations to link against, and as long as you only use the explicit instantiated template forms you will not need the template implementations.

            Lets say you have some LGPL function template that has its implementation in th

            • Okay, so theoretically this can work. Pragmatically, especially with something like Boost lambda or Spirit libraries, where there are dozens of implicitly instantiated templates, this would be very complicated to implement. You'd probably have to compile with original headers first, and then read symbols from object files and parse them to figure out what got instantiated.

              Of course, Boost is not LGPL anyway (thankfully; I wouldn't want to debate this in court!), so this all is purely hypothetical.

      • Actually, sometimes putting the entire definition in a header file is the right thing to do. Template classes, for example.
        • Actually, sometimes putting the entire definition in a header file is the right thing to do. Template classes, for example.

          It is never the right thing to do. You should always separate the template implementation from the template interface. This allows you to create a pre-compiled shared library that includes commonly used template instantiations.

          Lets say you have a template class that has a non-trivial amount of implementation code. If all the implementation is in the header files then every program that uses the template must instantiate each template form, even for commonly used forms such as int, float, long, double, c

  • The FSF is NOT the copyright holder of the Linux _kernel_ (or most of it).

    • by msauve ( 701917 )
      "The FSF is NOT the copyright holder of the Linux _kernel_ "

      No, but they wrote the license under which the kernel is distributed. Seems to me that their opinion on how that license is meant to apply is pretty authoritative.
      • by mgiuca ( 1040724 )

        Not really. That's why we have a license. When I choose to apply GPL to my code, I am not licensing my code under "anything the FSF ever says on the matter in the future", I am applying the license as it is worded. Otherwise, I could write a license which says "You may not use this work commercially," get a bunch of people to apply that license to their works, and then a few years later clarify "Oh, when I said commercially, I meant selling it for over $1000. Anything under that is fine." Which would probab

  • ... for providing a reference. This is a pretty conclusive statement, and definitely clears things up for me. I apologize if my comments in the previous discussion on the use of kernel headers by Android mislead someone (IANAL and all that).

  • When he says 'substantial' I hear 'non-empty'. You can't link to a single function in a dynamic library without creating a derivative work. So be sure you strip out all inline functions and macros from GPL header files and just use the structures, typedefs, and enums. Just to be safe. And goodbye C++ templates.
    • by pem ( 1013437 )

      You can't link to a single function in a dynamic library without creating a derivative work.

      When it runs, the entire program is arguably a derivative work. When your software alone is just sitting there, no, it's not.

      Otherwise, you might as well argue that a single GPLed plugin will force Microsoft to opensource IE.

      • by ljhiller ( 40044 )
        Then I should have been more specific. I'm not talking about optional components, but libraries always linked in at runtime when the program launches. Stallman, Moglen, and FSF have long taken the stance that dynamic linking to GPL'd libraries (GPL 2 or 3, not LGPL or GPL + linking exception) requires adherence to the GPL license. Here's a quote:

        Eben:
        The language or programming paradigm in use doesn't determine the rules of compliance, nor does whether the GPL'd code has been modified. The situation is

        • but it's not necessarily true they'd prevail in court on this.

          Note that they've never sued anybody about this. It's just posturing.

          The claim that the GPL has now been tested in court, while true, doesn't address this issue, and IMHO probably never will.

          • BTW, I addressed the exact same Eben Moglen quote (from a slashdot interview in February 03 [slashdot.org]) on a discussion thread on the Python mailing list in November of that same year [google.com]. About the only thing that has changed in the intervening 7 years is that there are now enough important non-GPLed opensource projects that it is much harder for Stallman and his acolytes to cow all the FOSS developers into believing that he's always right on everything.
    • by Xtifr ( 1323 )

      So be sure you strip out all inline functions and macros from GPL header files and just use the structures, typedefs, and enums.

      Inline functions and macros that are trivial or which constitute scènes à faire are not going to be protectable either. Thus "substantial" is the correct term (although it may not take a whole lot to reach something approaching substantial).

  • Thing is, Stallman is saying that just including a header file. eg. #include "stdio.h" does not make the program a derivative of stdio.h.

    It doesn't however mean you can get stdio.h, remove all the comments and copyrights then pass that off as your own file, which is what Google have allegedly done.

  • He kindly told me that he thought about it, and this is not a case of violation.
    However, he did not tell me anything about header files, so I suppose
    we must assume he still thinks the same on this since 2003.

    From what I gather in his 2003 e-mail, I believe their lawyer must have
    thought of the "fair use" exceptions in copyright law, and indeed
    simply quoting a few typedefs would fall under fair use (since it is not a
    substantial portion). On the other hand, I have a hard time believing
    that this goes for anythi

    • by ledow ( 319597 )

      "He explicitly says that for there to be a derivative work, it would take a substantial amount of code. So, you can't just take a substantial portion of a GPL'd program's (either an application of a library) *interface* and release it under an arbitrary license."

      No, he says it would take a substantial amount of CODE. Meaning actual bodies of functions (he says so in the same line).

      A header file, by convention, contains no code. It has interface definitions (X expects an integer), it has data structures (A

It is easier to write an incorrect program than understand a correct one.

Working...