Slashdot Mirror

← Back to Stories (view on slashdot.org)

Derivative Works And Open Source

Posted by timothy on from the deriving-force dept.

marvin826 writes " Larry Rosen has a nice article in the current issue of the Linux Journal about the legal interpretation of derivative works. Seems there are two camps in the world in terms of using open-source libraries, such as GPL licensed libraries, in proprietary software. Read this article and see which camp you are in! Having people working full-time on proprietary software, using open-source libraries, can only help the open-source software get better? "

4 of 357 comments (clear)

  1. Quoth the attorney by qwijibrumm · · Score: 5, Interesting
    2) The meaning of derivative work will not be broadened to include software created by linking to library programs that were designed and intended to be used as library programs. When a company releases a scientific subroutine library, or a library of objects, for example, people who merely use the library, unmodified, perhaps without even looking at the source code, are not thereby creating derivative works of the library.
    Ok, cool. But doesn't the GPL also prohibit linking to proprietary programs under most (all?) circumstances? If I want some big company to use my libraries, I'll release them under LGPL which doesn't have this provision. Musicmatch Jukebox links to Lame, an LGPL library. I don't know that anyone ever implied that linking did create a derivative work. But it's still illegal if I link a proprietary program to a GPL library.
    --
    I wish there was some there was some way that I could be outside playing basketball, in the rain, and not get wet.
  2. Impressed, but reserved... by ajs · · Score: 5, Interesting

    A good overview of the issues.

    However, I think that the classic issue that has stumped the traditional wisdom is not coverdd. That is the case of "interface definitions" that must be loaded and merged with your source code at compile time. These include C or C++ "header files", or the "modules" of Perl. In interpreted languages the issue gets really sticky because you can modify those external libraries at run-time.

    For example, is this Perl module a derivative work?

    package CGIOverride;
    use CGI;
    sub import {}
    package CGI;
    sub params { die }
    sub new { die }
    sub start_html { die }
    1;
    __END__

    Here I basically edit the CGI module, but I do it at compile-time. If the law has to start getting into compile-time vs. pre-compile-time distinctions, I think we're going to be in for a bumpy ride!

    Even worse... one way to resolve the above is to say that I'm not editing CGI, I'm editing the CGI namespace. At that point, we have to decide if a namespace is something that is protected under copyright law! Are namepsaces just a loosely maintained analog of the domain name system? Is a Perl module or a C++ header analogous to a programmer's Web site? *shudder*

  3. Re:Noone really understands the GPL... by Fnkmaster · · Score: 5, Interesting
    The problem is that many of us who are very active in the Open Source/Free Software communities and are bright people and experienced coders, and some of us who are ALSO experienced businessmen AND have dealt with many lawyers in the past and written and signed many legal contracts STILL don't understand the GPL.


    That's right. I consider myself to fall into the above. I mean, I think I understand the GPL, I understand the concepts behind the contract, but it is fucking vague. Concepts like linking - what does linking mean when you are referring to a Java program? If two classes are in the same jar, are they linked? Is it a derivative work? Are they part of a single "work"? If an interface is BSD-licensed or just public domain, but an implementation is GPLed, can I use runtime class binding to invoke it from a piece of commercial software? What about if I use RMI or some godawful XML/HTTP/SOAP mechanism to invoke it?


    Now the usual Slashdot response when somebody submits an Ask Slashdot on these topics is "Don't ask us, call your lawyer"! The problem is that while lawyers are experienced and generally skilled at reading contracts, you know a fuck of a lot more about software construction, components and the like than your lawyer does. And though IANAL, I have many friends who are, and you'd be shocked at how much jurisprudence out there is based on concepts like "would a reasonable person expect that..." and so on. If a reasonable person doesn't know what the word "link" means or doesn't understand what a "derivative work" is, even a reasonable person who IS a practitioner of the art in question, then the contract is, IMHO, on shaky grounds when it comes to enforcement in a court of law.


    But that's just my opinion. Feel free to prove me wrong.

  4. What do we *want* the answer to be? by Dunark · · Score: 4, Interesting

    I'd like to suggest a pragmatic approach: What definition does more to advance the cause of promoting the use of open-source systems? If we say that linking to system libraries makes an application subject to GPL, we can expect the makers of proprietary software to avoid open-source platforms in droves. This would help M$ to maintain the "applications barrier to entry" that has so far discouraged many people from switching to Linux.

    In my opinion, we should say that calling library routines does not make the calling program subject to GPL.