Is inherited class a derivative work?

Rod Dixon, J.D., LL.M. rdixon84 at home.com
Thu Oct 18 01:43:17 UTC 2001


The discussion on this topic has been very interesting. I am unsure who posted the comment about the lawyers at FSF, but if that person could obtain clearance to post the complete explanation on why FSF has taken the position that the use of inheritance constitutes the creation of a derivative work, this might be extremely helpful for our discussion.  If this is a reliable legal position, it might discourage use of the GNU GPL. Hence, this is a rather important matter. 

My thoughts on the matter are similar to what seems to be the majority view of the posts on this list, which is the FSF opinion seems oddly incorrect. I say odd because it seems inconsistent, as a matter of open source philosophy, to argue that the GPL permits a copyright holder to grab copyright interest in a modification that oftentimes (if not, almost always) would not be within the scope of the Copyright Act (in the U.S.).


First, I think it is important to be mindful of the fact that inheritance is intended to support the reusability of code, not thwart that effort. If that principle is your starting point, one could argue that there is an implied license to create derived classes that contain objects inherited from another. Consequently, one could not say that all inheritance (if any, for that matter) results in the creation of a derivative work. You still need to look at the source code in each instance to determine whether the copying that occurred constitutes an original work. Frankly, I am doubtful that the creation of a subclass could lead to this result, but the point is, the rule cannot be a per se determination.

In addition, to implied license to access the inheritance feature of some programming languages, I think the Copyright Act's definition of "derivative work" as well as section 117(a) mitigate against a per se rule that the creation of a derived  class results in a derivative work subject to the GPL.  Larry and one other poster has already addressed the derivative work definition in the Copyright Act. As for section 117(a), my understanding is that to the extent that this issue of inheritance can be viewed similarly to the API issue, the resulting "modification" or "adaptation" would be outside the scope of copyright protection entirely since the Copyright act authorizes adaptations that are created as an essential step in the utilization of a computer program. As a practical matter, I suspect that section 117(a) applies to nearly all dynamic calls to API, and, depending upon the circumstances, would apply to some static linking and object inheritance. 

I am still curious about the counter arguments. I look forward to the FSF posting.

Rod Dixon
Visiting Prof.
Rutgers Law-Camden
rod at cyberspaces.org 



 creation of a derived class (subclass)  constitutes a derivative work of the    
    On Tuesday 16 October 2001 03:22 pm, Michael Beck wrote:
    
    > I just got a response from FSF lawyers stating that "inheritance is
    > considered modifying the library" (see below). My question was related to
    > releasing code under LGPL and wanted to make sure that I've interpreted
    > correctly the difference between "work based on a library" and "work using
    > a library", and according to FSF, inheritance falls under "work based on a
    > library" and as such should be released under LGPL.
    
    Now that's a truly scary thought if you think about it. The KDE core 
    libraries are under the LGPL, but there are many KDE applications that are 
    under different licenses and which of subclassed some KDE classes (kwin, 
    kicker, cervisia, etc). Are these programs all now illegal? Will we have 
    another KDE boycott by Debian and Redhat?
    
    I'm going to have to check that nothing in my C++ inheritance chain is LGPL.
    
    -- 
    David Johnson
    ___________________
    http://www.usermode.org
    --
    license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3



More information about the License-discuss mailing list