RE: Is inherited class a derivative work?

[Michael Beck]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 16, 2001 23:34

> 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?

IANAL, but assuming that the FSF statement about LGPL and inheritance is
correct, this would only indicate that the classes derived from KDE should be
published under LGPL. The programs using them could continue to be released
under their current licenses.

Michael


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

Re: Is inherited class a derivative work?

[Forrest J. Cavalier III]

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

I think this fits with RMS and FSF previously published
ideas (which were not from lawyers.)

For years RMS and the FSF have the stance that if there is only one
implementation of a library/API, and you write something which
links to it, your work is a derivative work of that library.
I expect the RMS/FSF reasoning is consistent in the case of
inherited class.

The library/API aspect is a topic discussed on license-discuss
in the past (in a number of threads regarding the GPL and
loopholes, if I recall.)

This is the first I have heard that FSF lawyers had a hand in
crafting a position on this particular topic.  Since the FSF
argument always seemed a little weak to me, I would like to read
the "lawyer-strengthened" position also.

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

Re: Is inherited class a derivative work?

[Rod Dixon, J.D., LL.M.]

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
[EMAIL PROTECTED] 



 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

did others on this email list recently receive this spam

[Simon, David]

On Monday, I received the following email that purported to be internal and
was actually from an external source.  Our analysis shows that this email
came this license discussion email list.  

So, 
1. did others on this list receive this email (but not from the
[EMAIL PROTECTED] address which is not an intel address)
2. is there something we can do to block this in the future?

Thank-you


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 15, 2001 10:35 AM
Subject: FINANCIAL SERVICES STOCK - UNDERVALUED?

Regarding AMSE:

A "Buy Recommendation" was issued on 7/9/01 by Los
Angeles based Stratos Research. The 12 month target is $2.25. The stock is
currently trading under 25 cents. Undervalued? 
You have to do the research on this one. 
Recent press can be reviewed at
 
10K and 10Q reports are at


Calendar Year: 1997 1998 1999 2000 2001*
Mortgage Sales ($$) 50M 125M 175M 225M 300M
Top Line Fees ($$) 500K 2.0M 4.5M 6.5M 8.50M
Earnings ($$) 50K (2.0M) (6.0M) (2.0M) +500K
*projected results for 2001 M=Millions K=Thousands

For a quote go to

If you have received this message in error or don't
want anymore mailings from us, please excuse this message and send an e-mail
(with "remove" in the subject box) to [EMAIL PROTECTED]
 

This is not an offer to sell you stock. This message
conveys information taken from public filings and independent research
reports that are freely available in the public domain. This message and
some of the referenced materials may contain forward looking statements
including without limitation statements relating to the company's plans,
expectations, intentions, and adequate resources. These statements are made
pursuant to the "safe harbor" provisions of the Private Securities
Litigation Reform Act of 1995. Please refer to the company's 10K and 10q
filings for more disclosure about AMSE and the risks that could be
associated with an investment in the company's common stock. 
-- 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

RE: Is inherited class a derivative work?

[Michael Beck]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 16, 2001 19:05

> I've been watching the exchange on this topic with interest.

Great, finally a lawyer here!

> While the FSF *may* be correct, I would expect a more
> thorough analysis
> of the situation from them before I accept their conclusion.

Hopefully, they will provide one.

> In
> particular, how does inheritance differ in a substantive and legally
> significant way from traditional subroutine linkage which, as
> many of us
> believe, does *not* create a derivative work at least the context of
> dynamic linking?

I let FSF speak for themselves, but for me the flaw in this kind of comparison
is that you compare individual "traditional subroutines" to a class, which is an
entity "containing" such subroutines.

A correct comparison would be between a traditional library of subroutines and a
class.

Let's assume, I create a "Library X2", with an exact interface as "Library X"
(i.e. containing exact definition of all subroutines from "Library X"), copy the
implementation of each of them to "Library X2", provide new implementation for
two of those subroutines, and add two new subroutines.

What is then the "Library X2"? Is this a "derivative work", or is it a totally
new independent work? Can I claim copyright to the "Library X2" as my
independent work, or is this new "Library X2" a "derivative work" of "Library
X"?

IMHO, "Library X2" is nothing else than adaptation of "Library X", and as such,
a derivative work. If this is true, than a subclass is also a derivative work.

Just because OOP technology (via inheritance) made "copy & paste" of source code
of class methods irrelevant, it doesn't mean, IMHO, that you can ignore the fact
that by creating an inherited class your "intent" was to change/modify the base
class, and not using it "as is".

Michael

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

derivative work

[Angelo Schneider]

Hm, 

I tend to write lenghty maisl, sorry.

In short: bring the question if a piece is derived work or not down to
the source code.

You are deriving work if you take original source code and modify it.

You are making a derived work if you incorporate source code in any way,
compiling, loading and interpreting, linking, dynamic linking,
translating in a different language (if tehre is no paradigm change)
into one single piece of final work.

Becaus your final work 'containes' the original work.

Being in any way dependened on an original work
.   calling subroutines of that library
.   reffereing to classes in that library
.   deriving from classes in that library
legaly that all is *NOT* making a derived work.

This is not my stand point and I know most people somewhat working with
the GPL also have not that "stand point".

But that does simply not matter. Its aquestion of law and not of stand
points, making a derived work means you copy (hence the term copyright)
parts or whole of some one else into your work.

So: look at the cases above, and then link with that library, this
constitutes a derived work. Reason: the source code of that library is
incorporated (after compiling and archiving in a library) into your
finla product(work).

Sidenote: dynamic linbking constitutes a copy of the work in main
memory, it copies also the libraries into main memory. They are linked
in main memory(that has no meaning, linking just means here and above:
put together) so they are a drived work in memory, due to the copying
and putting together.

Yes I know, RMS himslef does dynamic linking not consider being a
derived work, well, law sees it different.

Sidenode 2: You can use process boundaries, e.g. CORBA or similar
constructions (RPC) to overcome those restrictions. Calling a library
which is in its own proces from a different process does not construct a
derived work, as they are not "put together". Why is that? Well,
"derived work" means all parts are put together into one thing. The new
one thing is then a derived work of the parts.


Hope that helps,

Angelo

--
Angelo Schneider OOAD/UML [EMAIL PROTECTED]
Putlitzstr. 24   Patterns/FrameWorks  Fon: +49 721 9812465
76137 Karlsruhe   C++/JAVAFax: +49 721 9812467
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: Is inherited class a derivative work?

[Rob Myers]

on 17/10/01 2:34 pm, Angelo Schneider at [EMAIL PROTECTED] wrote:

> In Germany dynamic linking is: "derived work".
> Its up to your lisence if you allow it.
> 
> Inheritance is NOT, NOWHERE, NEVER a "derived work".
>
> However incorporating the derived class plus the base class into a piece
> of software makes that software a derived work, not the derived class.
> (Because the base class is included)

If dynamic or static linking create a derived work but subclassing per se
doesn't, I can't see many cases where being able to use a subclass wouldn't
create a derived work given your definition.

It sounds like inheritance is OK but use of inherited code isn't. A bit like
the UK's laws on owning cannabis seed. :-)

- Rob

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

Re: Is inherited class a derivative work?

[Angelo Schneider]

Hi all!

The FSF is incorrect.
However your extract and the talk with the FSF might have been
missleading, see below.

Ken Arromdee wrote:
> 
> >
> On Tue, 16 Oct 2001, Lawrence E. Rosen wrote:
> > While the FSF *may* be correct, I would expect a more thorough analysis
> > of the situation from them before I accept their conclusion.  In
> > particular, how does inheritance differ in a substantive and legally
> > significant way from traditional subroutine linkage which, as many of us
> > believe, does *not* create a derivative work at least the context of
> > dynamic linking?
> 
> Well, the FSF believes that that does too, so I presume they don't see a
> difference...
> 

As I said in my previous post:
"derived work" is a legal term, its defined in law what "deriveed work"
means.

In Germany dynamic linking is: "derived work".
Its up to your lisence if you allow it.

Inheritance is NOT, NOWHERE, NEVER a "derived work".
However incorporating the derived class plus the base class into a piece
of software makes that software a derived work, not the derived class.
(Because the base class is included)

Simple example:
a1 b2 c3 d4 <-- That is my work.

Its protected under copyright (well its to primitive to be realy
protected, just lets asume it was).

You write:
e5

That stands alone! No derivation.

You write:
A1 B2 C3 D4 <-- that is a derived work (translation)
a1 b2 XX d4 <-- that is a derived work
a1 b2 c3 d4 e5 <-- that is a derived work
b2 c3 d4 e5 a1 <-- that is a derived work

Its always a "derived work" for one simple reason: it containes literaly
the original work. Thats the definition of "derived work". Thre are
further ways for derived work as one pointed put here: e.g. translation
into a different lanuage(or programming language), writing a sequel to a
nove also can be considered a "derived work".

A class inheriting does not contain -- in the code written by the coder
creating the inherited class -- any portion of the base class, so it is
by definition of the law not a "derived work".

Programs using a GPLed library are derived from that library because
they LINK with it. Not becasue the call routines from it. (In germany no
one would distinguish between dynamic and static linking, because the
result is a set of copies of copyrighted pieces in main memory of the
executed process, so all copied parts fall under copyright, because you
copy them into main memory)

Changing  a file of an library is a derived work of that file and hence
of the library itself. (Well, here are complicated exceptions thinkable
and only the file is derived work and not the changed library)

Adding a file to the library can be considered a drived work(same
complicated exception apply), so you would just make two libraries,
thats not a derived work as the original one is untouched.

Now you link both libraries to an executeable -> derived work, of the
original library: because it is in the executeable, not because there
might be ANY relation of your library code to the original library code.

Finaly: calling routines in a library is NOT "derived work".
Period. It is not important wat you THINK, its important what the law
says.
Linking with that library is the only process creating a derived work!

So if you use a GPL library, make it a dynamic one, distribute it under
GPL as you are forced to do so by the license, and distribute your
program with an installation script that fetches the library from the
internet anywhere. Your program is then during the time it is
distributed NOT a derived work, but during run time it is :-)

Regards,
   Angelo

P.S. no, I'm not a lwawer, but I work in that area for years. (Basicly:
I can not get why you all write code, write/read licenses, sell code,
gpl code and and and, and no one seems interested to look into the legal
framework his work is placed in. Its not even important if that legal
framework is everywhere the same, most do not understand the
international copyright treaties only have one goal: is your work
copyrighted under US law, "in germany" your right is honoured. Is my
work under german copyright law copyrighted, my rights are honoured in
the US. Even because both rights differ substantial. Just get a book
with copyright law, the german one has 143 Paragraphs, most of them are
3 or 4 lines. In total it might have 80 pages, where 20 are important
for you. I would think the US one is smaler.)

--
Angelo Schneider OOAD/UML [EMAIL PROTECTED]
Putlitzstr. 24   Patterns/FrameWorks  Fon: +49 721 9812465
76137 Karlsruhe   C++/JAVAFax: +49 721 9812467
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Re: Is inherited class a derivative work?

[Bjorn Reese]

[ Apologies if multiple copies were sent -- mail server problems ]

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
[...]
> > -David "Novalis" Turner,
> > Licensing Question Volunteer,
> > Free Software Foundation

David Turner may have received his reply from a lawyer, but that
is not clear from his reply. Please note that David Turner himself
is not a lawyer, but a programmer, so I would not recommend taking
his reply as legal advice.

http://web.novalis.org/resume.html
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3