> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 26, 2001 09:28
> if inheritance was legally ruled to be a derived work, > most open source licenses would get rewritten > to grant, unconditionally, the right to inherit. I don't think that there would be that many. It seems to me that there would be no impact on licenses that: - let you do unconditional modifications (e.g. BSD, MIT), - spell out "derivative work" (e.g. IBM or Python Public license), unless it wasn't their intent to qualify inheritance as "derivative work" - require to publish inherited classes (e.g. LGPL) My guess is that some licenses, depending on their original intent, would have to change the wording to be more precise, e.g. by using the term "derivative work", or by spelling out "inheritance". > I know I'd do it with my perl code on CPAN. > > even if you could get legal backing to your assertion, > most people in the open source community wouldn't use it. I agree with you. Although there might be few changes. For example, authors who currently use MPL but feel that inherited classes should be published back to the community, might switch to LGPL or a similar license. > That should be a flag that something is amiss in your approach. My aim is to correctly interpret the law. If my assertion is legally correct, then it gives the authors the chance to make a "conscious" decision whether inherited classes should be published or not. For authors who already published their code under BSD or similar license, it doesn't matter, because they don't care about any modifications being published, anyway. So there is no disadvantage to them. But it would provide clarification to those authors who want to make sure that all derivative work (incl. inherited classes) get published back to the community and who were not aware that currently some licenses don't include inheritance in their definition of "modifications". Michael -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3