Follow Slashdot blog updates by subscribing to our blog RSS feed

 



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

RMS On Header Files and Derivative Works 247

Posted by timothy
from the but-I-said-'a'-first dept.
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 @10: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.

    • by kestasjk (933987) * on Sunday March 20, 2011 @10:51AM (#35550810) Homepage
      This copy of Photoshop CS I've got installed is also a statement of fact, by the way. I love lawyers!
      • by Dogtanian (588974) on Sunday March 20, 2011 @11:28AM (#35551154) Homepage

        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) on Sunday March 20, 2011 @11:44AM (#35551264) Homepage

          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 the project going than it splitting legal hairs and turning people off from the project, that pretty much has been done by tame junk journalists at the behest of closed source proprietary software houses looking to make open source software look bad.

          • by Dogtanian (588974) on Sunday March 20, 2011 @12:06PM (#35551426) Homepage
            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) on Sunday March 20, 2011 @12:10PM (#35551454)

            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.

            • by NemosomeN (670035) on Sunday March 20, 2011 @12:47PM (#35551772) Journal
              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 :-)

              • by the phantom (107624) on Sunday March 20, 2011 @02:00PM (#35552226) Homepage

                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 arithmetic mean (the average that you provide an example of), the geometric mean (calculated similarly, but with some extra powers of 2 and a square root), higher order means, or a variety of other measures of center.

                Additionally, even if the original poster meant the arithmetic mean, his statement was probably not that far off the mark. 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. Hence about half of the population will be above the arithmetic mean, and about half will be below. Since a metric which quantifies the quality of a lawyer is likely to consist of many variables, each with their own distributions, the central limit theorem implies that the overall distribution of quality will be normal (of course, this is under the assumption that a large enough proportion of those variables are independent, which may or may not be a dubious assumption). Basically, the quality of lawyers is probably a (more or less) normally distributed random variable, and about half of lawyers are less than average (i.e. of a quality lower than the mean).

                In short, you (a) are being a math nazi, which strikes me as hypocritical, given your stance on grammar nazis; and (b) are only correct in a technical sense, and not in a colloquial (or even general mathematical) sense.

                • by smellotron (1039250) on Sunday March 20, 2011 @05:57PM (#35554140)

                  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 care about the distribution. It also lends itself well towards quartile/percentile information, which is quite interesting for some topics (i.e. wealth distribution).

                  Since a metric which quantifies the quality of a lawyer is likely to consist of many variables, each with their own distributions, the central limit theorem implies that the overall distribution of quality will be normal (of course, this is under the assumption that a large enough proportion of those variables are independent, which may or may not be a dubious assumption).

                  Variable independence aside, I believe you're making assumptions that the central limit theorem doesn't allow. It's possible that while there are thousands of observable attributes of lawyers, the only one that matters is "mojo". If one has mojo, he(she) wins cases and finds legal loopholes; and if one doesn't, one suck balls. Therefore, your assertion that overall lawyer quality must be something near a Gaussian is incorrect in a mojo-driven universe.

                  FWIW, I am typically a grammar nazi, too :)

    • by OddJobBob (1965628) on Sunday March 20, 2011 @10: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 @12: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.

      • by Crispy Critters (226798) on Sunday March 20, 2011 @02:25PM (#35552418)
        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.
      • 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-protected elements include: elements made for efficiency (i.e. elements with a limited number of ways it can be expressed and thus incidental to the idea) elements dictated by external factors (i.e. standard techniques) design elements taken from the public domain Any of these non-protected elements are thrown out and the remaining elements are compared with the allegedly infringing program's elements to determine substantial similarity. So header files would be thrown out because of standard techniques and design elements taken from the public domain. The kernel header files mainly express the POSIX standards of communication between the system and programs. That is not to say ALL header files are not copyrightable. A header file used in an application may be copyrightable if it expresses something outside of the three excluded elements above in sufficient quantities. But in this instance the portions of the kernel header files that Google copied into a new file and distributed fall into one of the three exclusions from above. I am not a lawyer. This is not legal advice. Read the legal findings yourself or consult a real lawyer if you are concerned.
    • by martin-boundary (547041) on Sunday March 20, 2011 @04:47PM (#35553680)
      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 to the given compiler, and there's no way anyone could claim that it's not creative or copyrightable.

      • by smellotron (1039250) on Sunday March 20, 2011 @06:04PM (#35554188)

        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 phonebook argument - the phone numbers, names, and addresses are facts and thus may not be copyrighted, but the presentation is creative and thus may be copyrighted.

        • by martin-boundary (547041) on Sunday March 20, 2011 @07:17PM (#35554678)
          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 convenience of the compiler developers.

          See below for what it looks like (and even this isn't complete enough to be compilable). That's a lot of creative input for one standard C definition, and completely "fake": there are no guarantees whatsoever that the contents shown will exist in a previous or a future version of the C compiler I'm using, and if I change C compiler vendors, then there's no guarantee that even some kind of structure will be called an _IO_FILE.

          No programmer should ever use _IO_FILE directly (or even include libio.h in his programs) The only purpose of _IO_FILE is internal for the compiler developers.

          struct _IO_FILE {
          int _flags; /* High-order word is _IO_MAGIC; rest is flags. */
          #define _IO_file_flags _flags

          /* The following pointers correspond to the C++ streambuf protocol. */
          /* Note: Tk uses the _IO_read_ptr and _IO_read_end fields directly. */
          char* _IO_read_ptr; /* Current read pointer */
          char* _IO_read_end; /* End of get area. */
          char* _IO_read_base; /* Start of putback+get area. */
          char* _IO_write_base; /* Start of put area. */
          char* _IO_write_ptr; /* Current put pointer. */
          char* _IO_write_end; /* End of put area. */
          char* _IO_buf_base; /* Start of reserve area. */
          char* _IO_buf_end; /* End of reserve area. */
          /* The following fields are used to support backing up and undo. */
          char *_IO_save_base; /* Pointer to start of non-current get area. */
          char *_IO_backup_base; /* Pointer to first valid character of backup area */
          char *_IO_save_end; /* Pointer to end of non-current get area. */

          struct _IO_marker *_markers;

          struct _IO_FILE *_chain;

          int _fileno;
          #if 0
          int _blksize;
          #else
          int _flags2;
          #endif
          _IO_off_t _old_offset; /* This used to be _offset but it's too small. */

          #define __HAVE_COLUMN /* temporary */
          /* 1+column number of pbase(); 0 is unknown. */
          unsigned short _cur_column;
          signed char _vtable_offset;
          char _shortbuf[1];

          /* char* _save_gptr; char* _save_egptr; */

          _IO_lock_t *_lock;
          #ifdef _IO_USE_OLD_IO_FILE
          };

      • by Unequivocal (155957) on Monday March 21, 2011 @08:44AM (#35558416)

        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.

  • by MickyTheIdiot (1032226) on Sunday March 20, 2011 @10:59AM (#35550904) Homepage Journal

    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?

    • by Hobart (32767) on Sunday March 20, 2011 @01:41PM (#35552102) Homepage Journal

      Linus isn't the only copyright holder on the kernel. It's shared amongst several dozen (hundreds/thousands) of contributors - all of whom obtained the right to it via the license terms, and have shared their contributions under those same license terms.

      You -might- respond to J-Random-Kernel-Contributor's action against you by combing through the code and removing only that individual's copyrighted contributions, but you'd be open to all the others at that point.

  • by redelm (54142) on Sunday March 20, 2011 @11:03AM (#35550946) Homepage

    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.

    • by Latent Heat (558884) on Sunday March 20, 2011 @11:13AM (#35551028)
      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) on Sunday March 20, 2011 @11:27AM (#35551146)

        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.

        • by Darinbob (1142669) on Sunday March 20, 2011 @04:17PM (#35553442)

          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 assume memory is cheap and caches are large, and when they're not you just get a bigger computer next year. It's no longer a matter of just linking to third party libraries, you now have to recompile from scratch to use the libraries.

          It's one thing to not worry about optimizing code early on, but it's a bizarre world when you just ignore optimization altogether.

          • by sribe (304414) on Sunday March 20, 2011 @07:56PM (#35554908)

            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 can be. For a suitably C++ish definition of high-level ;-)

      • 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 method is only practical for smaller application projects, certainly not libraries, and I'm damn grateful that I don't have to compile the entire GNU / Linux stack (or even just X + QT/GTK/OpenGL) into each C or C++ program I write...

        Java allows you to compile against the byte code because the .class files contain the interface definitions. C / C++ .o & .so files do not contain the interface definitions; After compilation / linking of the executable the API interfaces & linking symbols are not needed (unless for debugging or public API purposes).

        However, even with your single translation unit approach I can strip out all of the implementation code from your .h files, leaving only the interface. I can then compile code that provides or uses the interface that your compiled code offers. The stripped down .h files will contain only the facts of how the API is accessed (what function names take which parameters and return what values), and will not contain the details of how the results are achieved.

        If you have an amazing program called DeepThought.h that has a function such as:

        int UltimateAnswerToLifeTheUniverseAndEverything( void ) {
        int answer;
        ... complex calculation here ...
        return answer;
        }

        I can create my own DeepThought.h that looks like this:

        int UltimateAnswerToLifeTheUniverseAndEverything( void );

        And implement the function in my own DeepThought.cpp file. Code that used your DeepThought.h can now use my DeepThought.h, and our implementation details can be totally different, and IMHO, uninfringing.

        int UltimateAnswerToLifeTheUniverseAndEverything( void ) {
        // cache answer to avoid re-calculation.
        static int results( 0 );
        if ( results == 0 ) results = ( (5 << 2) | 1 ) << 1 ;
        return results;
        }

        It is a fact that your DeepThought.h provides a function called "UltimateAnswerToLifeTheUniverseAndEverything" that takes no parameters and returns an integer. The fact that my DeepThought API provides a similar interface that is compatible with your API has nothing to do with how each of our products achieve their results. Your function may return different results than mine, but the way people ask either library to produce results is the same.

        Vehicles have a common interface: steering wheel and accelerate / decelerate pedals. How the body / engine is designed and built can vary widely between manufacturers; Patents / trademarks, etc keep them from duplicating each other's exact designs and implementations. However, the manufacturers can all provide a similar common interface. Every time you buy a new car you don't have to learn a different set of controls (Joystick + hat switches?).

        TL;DR: Even if you put all the code in the .h It can still be reduced to just the interface facts, and re-implemented without infringing.

        • 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 the .h file. I can reduce that to just the interface facts: [network-theory.co.uk]

            mylib.h
            template <T> int someFunc( T * aVar );

            Here is the .cpp implementation that has been split out (still LGPL) -- A derivative of the original combined template interface / impl.
            mylib.cpp
            #include mylib.h
            template <T> bool someFunc( T * aVar) {
            if ( aVar != NULL ) return true;
            return false;
            }

            // Add Explicit template instantiations commonly needed -- prevents multiple instantiations of these:
            template <int> bool someFunc ( int * aVar );
            template <float> bool someFunc ( float * aVar );
            // etc..

            I can then compile a mylib.so that falls under the LGPL. I can then link NON LGPL programs to it via the sanitized .h file.

            In order to use the template with types other than float or int I must have access to the mylib.h & mylib.cpp and include both. Or, I can use just the .H and recreate my own .CPP implementation to provide a compatible yet non-derivative, non-infringing library that I can license however I choose.

            Once I have created (& possibly extended ) my own non-infringing lib, I am free to distribute the stripped down mylib.h file along with the mylib.so binary and other programs that only use the explicitly instantiated float, int and MyNewClass variants will not need to include the mylib.cpp code.

            In the case of Boost, you'll end up re-creating much of the template implementation, but this does not mean that one can not separate the template implementations and interfaces, and subsequently create a compatible, non-infringing library that is compatible with Boost.

            Or, you can separate the boost interface from its implementation, explicitly instantiate the template forms you will be using in a derivative .so binary (same license as Boost), then create your non-derivative application that simply uses the instantiated template forms and distribute it under a different license.

            TL;DR: You are wrong. My point stands that I can reduce any .h files to their implementation facts then create non infringing .cpp file to link my own non-infringing / separately licensed code against.

            • 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, char, etc.

          In this case it is better to explicitly instantiate these commonly used template forms in the implementation, and allow programs to link against the shared library binary only using the header file. If you do not separate the implementation from the interface, then this is impossible to achieve and each individual executable will re-instantiate all the commonly used template forms for no good reason (wastes space). For templates that have trivial implementations this is not as big of an issue.

          Search for: "separate template definition declaration", and "explicit template instantiation". These are areas that "noobie" template users fail to take notice of.

          Even if whole program optimization is your goal, it is better to create a .cpp file that includes all the other .h & .cpp files and compile it as a final step in production, than to have to re-compile all the implementations each time one line of code changes.

  • by trifish (826353) on Sunday March 20, 2011 @11:44AM (#35551270)

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

    • by msauve (701917) on Sunday March 20, 2011 @01:32PM (#35552048)
      "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) on Sunday March 20, 2011 @06:30PM (#35554368)

        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 probably not go down too well with the people who used my license.

        In fact, there is (in some sense) a way to license your code in such a way that you defer to the FSF's future clarifications: use the "or any later version" clause. If you use that clause, you are stating that you trust any future clarifications made by the FSF to apply to your work. Linus specifically did not use this clause because he doesn't trust the philosophy of the FSF, only the specific wording of the GPLv2.

        Just pointing that out. I do agree with the FSF here.

  • ... a derivative work?

  • by shutdown -p now (807394) on Sunday March 20, 2011 @12:34PM (#35551662) Journal

    ... 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).

  • by ljhiller (40044) on Sunday March 20, 2011 @12:48PM (#35551774)
    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) on Sunday March 20, 2011 @01:08PM (#35551914)

      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) on Sunday March 20, 2011 @02:34PM (#35552524)
        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 no different than the one where your code depends on static or dynamic linking of a GPL'd library, say GNU readline. Your code, in order to operate, must be combined with the GPL'd code, forming a new combined work, which under GPL section 2(b) must be distributed under the terms of the GPL and only the GPL. If the author of the other code had chosen to release his JAR under the Lesser GPL, your contribution to the combined work could be released under any license of your choosing, but by releasing under GPL he or she chose to invoke the principle of "share and share alike."

        They claim this, even if your code contains no text from GPL'd code, contains only unprotected API text from GPL'd header files, or is distributed only as a non-compilable package that requires end-user assembly with GPL sources obtained separately.

        • by pem (1013437) on Sunday March 20, 2011 @04:02PM (#35553346)
          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.

          • by pem (1013437) on Sunday March 20, 2011 @04:18PM (#35553450)
            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) on Sunday March 20, 2011 @05:37PM (#35554016) Homepage

      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.

  • by exa (27197) on Sunday March 20, 2011 @06:35PM (#35554406) Homepage Journal

    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 anything in "header files", in general. I think you
    would have to ask him about the opinion of the FSF on header files,
    and interface definitions in general in any language. Note that he did
    not mention "function declarations". Read what he says carefully:

    > 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.

    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. That is simply not permitted by the license.

    I think there are trolls from some companies here that are trying to make it seem as
    if you can use GPL'd libraries in any proprietary program. I am beginning to
    suspect they already do that in other ways.

    Best,

    • by ledow (319597) on Monday March 21, 2011 @07:12AM (#35557798) Homepage

      "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 user account consists of alphabetical username and password and a numerical ID), and it has definitions (Pi is 3.141592). It does not and should never contain any substantial amount of code (or, really, lots of macro tricks). Everyone routinely distributes header files to closed-source DLL's, libraries etc. because it's not copyrightable and allows people to use those libraries (it is, in fact, necessary). But the header file is likely NOT covered by copyright at all (even if it says it is) because the information therein is not expressive (i.e. there are tools that can extract a "header" file you can use from a binary, it's just not as useful).

      What he's saying is that:

      long print_squared(int x);

      is not copyrightable. And almost every court in the land (including the SCO debacle) confirms that. It's not copyrightable because it's not expressive - it's merely fact and convention and interface. In the same way, a quadratic formula is not copyrightable but a book "Solving quadratics" or even a short except might well be copyrightable (and most probably is).

      The interface, as specified in a header file, is uncopyrightable on its own (though that doesn't stop people putting notices on it, it just doesn't mean they are "true"). The *body* - in programming terms - of a function (or the programmer's expression of his particular way of performing a certain procedure) is copyrightable, the *definition* or *prototype* is not.

      Otherwise every piece of software in the world is either a) infringing or b) GPL by extension (e.g. I use the SDL header in a closed-source program to know what functions to call and what parameters they expect - it doesn't mean that the SDL code is included except in a self-contained "closed" DLL or that the SDL licence applies to my entire program).

      And Google specifically said - they took a header file (which is 99.9% uncopyrightable - see SCO vs IBM etc.) and extracted JUST the function prototypes (so no question of macros, stray function bodies, etc. playing a part) and used that list of uncopyrightable "X does Y" to enable interfacing to a piece of code that was ENTIRELY under another licence. You can take ALL of the function prototypes in that way if you want. But you can't take a SINGLE LINE of function body without risking using copyrightable (and therefore copyright) material.

      Header files have one purpose - to provide the facts necessary to describe the *interface* to a set of code without needing the code present. Because they are facts, non-expressive and necessary for interoperability, they are uncopyrightable. If the GPL covered them, an awful lot of commercial games are in for a shock because they almost certainly used or include the SDL header, or the Allegro header, or any one of a million and one headers (including "windows.h"!) and thus become subject to the licensing terms on it. The SDL header even re-states the LGPL licence, for instance.

      Attempting to sue over header files and/or data derived from header files will end in humiliation. That said, certain parts of certain header files that contain macro code could easily be copyrightable. But that's no relevant - Google stripped out anything that wasn't a function prototype, from what they said.

Everybody likes a kidder, but nobody lends him money. -- Arthur Miller

Working...