http://www.perlmonks.org?node_id=223939

Interesting article by Lawrence Rosen (who is The Man by the way) on Linux Journal about Open Source and derivative works.

The article addresses what exactly Mr. Rosen would view a derivative work as. While this is just his opinion and not backed up by any case law in the article, he is a very respected member of the technology law industry. There also definately isn't a "IANAL" at the end of his article ;-).

When should code be considered a "derivative work?" If it's used at all in a program? So would that 100,000 line C program be a derivative of the stdio lib if it only uses one printf statement? There are clearly limits, it's understanding where these limits should lie that is the difficult part.

All the issues discussed in the article could be applied to Perl modules as well. It's an important issue that isn't considered often enough, perhaps due to the non(/anti?)-commercial nature/beliefs of the perl community (there's some good flamebait ;). There may be an impulse to just say "that's for the courts to decide" but in order to effectively oppose any questionable laws on the subject (not that questionable laws are every passed *cough* DMCA *cough*) the technical community needs to have a detailed understanding of the topic.

Enjoy the article :).

Replies are listed 'Best First'.
Re: Derivative Works and Perl Modules
by theorbtwo (Prior) on Jan 03, 2003 at 02:34 UTC

    In general, I think the rule (most people think, anyway) is that dynamic linking does not create a derivitive work, whereas static linking (or textual inclusion of source) does.

    Perl is never staticly linked, in the normal case, so simple "use"ing of a module doesn't do it.

    IANAL, of course.

    Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

[reply]

      Consider this, from the GPL Faq:

      In an object-oriented language such as Java, if I use a class that is GPL'ed without modifying, and subclass it, in what way does the GPL affect the larger program?
      ...
      Subclassing is creating a derivative work. Therefore, the terms of the GPL affect the whole program where you create a subclass of a GPL'ed class.

      It's these types of issues that really add to the confusion. Also see tilly's reply in Using GPL'd Perl Modules in Commercial Software. There is a lot of room here, and I think many companies will making "use" of it shortly.

[reply]
        I'm pretty sure the FSF is stretching a bit there. If you base the source of the child class on the publically documented parent class interface, rather than on the source of the parent class, you're OK. (The resulting binary, if you generate one, is of course still a derived work)

        Claiming otherwise is a bit dodgy. If it works the way they say, making a child class of a GPL class makes your code GPL. If that was true then if someone released a version of, say, the C runtime library that was GPL (rather than LGPL) it would make your entire system and all the code that made it up GPL'd.

        The derived work, generally, is the executable not the source. The source is only a derivative work when it's a modification of someone else's source, which is almost undoubtedly not the case. The wording here is a bit ambiguous.

[reply]
      Perl is never staticly linked, in the normal case, so simple "use"ing of a module doesn't do it.

      According to this:

      First, create a Perl that includes a statically linked DBI by running these commands in the directory where your DBI distribution is located:

      shell> perl Makefile.PL -static -config
      shell> make
      shell> make install
      shell> make perl

      Note that I haven't tried this, I just remembered reading about it once.


      cheers
      davis
      Is this going out live?
      No, Homer, very few cartoons are broadcast live - it's a terrible strain on the animator's wrist
[reply]
        The important distinction there is that, while linking statically makes the resulting executable a derived work, it does not make the original module source a derived work.
[reply]
Re: Derivative Works and Perl Modules
by Anonymous Monk on Jan 03, 2003 at 02:31 UTC
[reply]

Back to Meditations