Is inherited class a derivative work?

[Michael Beck]

> -----Original Message-----
> From: Rob Myers
> Sent: Wednesday, October 24, 2001 10:01

IANAL, TINLA.

> For the latter to be a problem (assuming you don't prohibit it in the
> license or just not export the symbols from the DLL), we
> assume that new
> versions of the grid developed using inheritance in and of
> themselves would be legally-derived works.

Based on the Micro Star v. FormGen case, I would have to disagree. In order to
use MAP files from Micro Star, the end-user had to have the FormGen software on
his PC. The MAP files didn't contained any parts from FormGen, but because the
original parts "assumed a concrete or permanent form" by a simple reference in
those MAP files, they were declared as "derivative work."

By analogy, when you create a derived grid, you are referencing my grid, and all
the functionality that is not changed or added, is coming from the original
grid, and therefore it would constitute a "derivative work." The point is that
your "grid story" is based on my "grid story", and thus you're creating a sequel
to the original grid. The inheritance tree shows exactly the sequel structure.

> This has nothing to do with pure inheritance. If I subclass
> your grid class
> to make a fully functional class that makes no calls to your
> class's code
> and refers to no symbols in it (possibly other than its class
> name. This is
> theoretical, so there are no constructor calls or shared data
> structures)
> and don't distribute it I am still raising the issue of whether I have
> created a legally-derived work or not.

I am not sure, I understand the above example. If you extend the grid class, all
the functionality of the original grid is there. Since my original grid "assumed
a concrete or permanent form" in your derived grid, then based on Micro Star v.
FormGen case, your grid is a "derivative work."

Michael

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