> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 17, 2001 21:43 > > 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.
It was me, and I will try to get a clearance. > If this > is a reliable legal position, it might discourage use of the > GNU GPL. Hence, this is a rather important matter. I assume, you meant GNU LGPL, correct? > 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 often times (if not, almost > always) would not be within the scope of the Copyright Act > (in the U.S.). Can you be more specific on your position? Are there any cases suggesting just this? If we agree that "class" is a design blueprint for an object, why should it be any different that "architectural design" or "chip design"? Both are 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. As long as there is no infringement of the copyright. Otherwise one could conclude that CD-ROM burners are here to make copies of copyrighted CD and sell them. > 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. Inheritance mechanism is given to you by compiler vendors, not by the class author, therefore such a conclusion would be very questionable. Otherwise, people could argue that by releasing a software on CD-ROM, the vendor gives you the right to make a copies of it, since you have a CD-burner on your PC. > Consequently, one could not say that all inheritance > (if any, for that matter) results in the creation of a > derivative work. Agreed. Exception would be an "abstract class", or overriding abstract methods in a regular class, since the author leaves it explicitly to the user to create implementation for the abstract methods. > 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 surprised why people bring all the time the API linking as their argument. Class is a design blueprint for an object, and IMHO should be treated as such, i.e. as a "design entity", similarly to "architectural design" or "chip design". When you derive a class, you are creating a copy of the original class. When you make changes to the new class, you are creating a "derivative work", the same way as you would do it by making changes to a copy of book, copy of a picture, copy of a house design, or a copy of a chip design. You don't change the original, but you still are creating a derivative work. How the mechanism works to create a derived class should be really irrelevant to the discussion, because Copyright Law states explicitly that it doesn't care about it in its definition of copies: ""by any method now known or later developed". When you derive a class (before making any modifications to it), you have created a "material object", "from which the work can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device". In our case, a compiler is the helping device. Michael -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
