Re: Derivative Works and Perl Modules

[theorbtwo]

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

[Anonymous Monk]

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.

[Elian]

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.

[davis]

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

[Elian]

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.