Re: Is inherited class a derivative work?
IANAL, TINLA. on 24/10/01 2:07 pm, Michael Beck at [EMAIL PROTECTED] wrote: > That doesn't matter. The issue is legal, i.e. does the author holds the right > to future releases of the grid, or can anyone develop new versions of the grid > by using inheritance? There is no way that they can do this without distributing the binary of your class or requiring that people buy the binary from you. The former is a simple copyright breach. The issue of legally-deriving the work does not need to be decided, as there are clear precedents for breach of copyright. 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. So let's look at the evidence for this: > In FormGen the court decided for FormGen: > > "Finally, by selling N/I, Micro Star "impinged on [FormGen's ] ability to > market > new versions of the story." Stewart, 495 U.S. at 238; see also Twin Peaks > Productions, Inc. v. Publications Int'l, Ltd., 996 F.2d 1366, 1377 (2d Cir. > 1993). Only FormGen has the right to enter that market; whether it chooses to > do > so is entirely its business. " 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 cannot do the same (refer to the file but not reference the media and not display the media) for a Duke Nukem sequel as I will have nothing to show. - Rob. -- Rob Myers http://www.robmyers.org/ "Smash global capitalism. Spend less money." -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Is inherited class a derivative work?
on 24/10/01 1:44 pm, Michael Beck at [EMAIL PROTECTED] wrote: >I don't know, but if had a super-cool grid class, >I certainly would like the copyright to protect me from anyone >buying my grid, creating a subclass, and then marketing it against >me. Unless they distribute your code without negotiating a deal with you (which is piracy), people will still need to buy your class in order to use the oo-derived class. So this would drive sales of your work and increase your profits rather than reduce them. - Rob. -- Rob Myers http://www.robmyers.org/ "I never made a painting as a work of art. It's all research" - Picasso. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Is inherited class a derivative work?
IANAL, TINLA on 19/10/01 1:53 pm, Chris Gray at [EMAIL PROTECTED] wrote: > If I write a class which extends java.util.Dictionary, then whose > implementation > of java.util.Dictionary am I adapting: No-one's. Is the original work changed? No. Is the original work copied&pasted? No. Is the original work translated to produce the new work? No. Does the new work rely heavily on the original FOR ITS CONTENT? No. The text file just sits there. When it's compiled to object code/bytecodes, it's still just sitting there. It does not contain copied, translated or derived (in the copyright sense) content from the original. Linking is another matter as people have pointed out. The difference between "deriving" a class and "deriving" a work form a copyrighted work is as big as would be expected between a bit of OO jargon and a legally defined term. Please can people stop confusing oo-derivation with (c)-derivation. Programmers may know "derive", "use", "relationship", "adapt", etc., etc., from programming, but their legal usage is quite different and is not flexible. Out of curiosity could function/method names be trademarked to regulate their calling? :-) - Rob. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Is inherited class a derivative work?
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: YAPL is bad (was: Re: Backlog assistance?)
On Monday, September 24, 2001, at 10:08 pm, Matthew C. Weigel wrote: > On Mon, 24 Sep 2001, Ian Lance Taylor wrote: > >> This leads to a GPL-related issue which is not clear to me: can >> redistribution of GPL code be constrained by an employment agreement? > > Well, that brings up the question of whether sharing within a > corporation qualfies as "distribution," a question which I can't recall > being answered (although it could just be my memory failing). This was the source of my misunderstanding: The FAQ makes it clear that "Distribution" means "Public Distribution". This should, however, be made absolutely explicit in the license. FAQs aren't binding, and ambiguities in licenses are bad, m'kay? - Rob. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: YAPL is bad (was: Re: Backlog assistance?)
on 24/9/01 3:26 pm, Rick Moen at [EMAIL PROTECTED] wrote: > But, of course, you were being very speculative, and rather jumping the > gun: My assumption that the OSI Board shares my notion that the right > to privacy should be a part of the definition of open source may be > entirely untrue. Russ for one sounded skeptical at best. I de-jump and apologize for sowing confusion: I share that skepticism but am clearly not best placed to express it. - Rob. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: YAPL is bad (was: Re: Backlog assistance?)
on 24/9/01 2:15 pm, John Cowan at [EMAIL PROTECTED] wrote: > > Rob Myers wrote: > >> I agree that this is an offer rather than a directive. But the effect of >> making the source (ultimately) available to anyone is the same as soon as >> the license is accepted. The GPL has this effect, the APSL makes this effect >> explicit. Any attempt to control this (by requiring that employees or >> clients not distribute the source) is in breach of the license. > > Right enough, but it still may be contained by voluntary action or > by sheer inertia. A disgruntled programmer can stop voluntarily not distributing code. My GPL/APSL comparison does (deliberately) exclude inertia, and I agree that in the real world it is a powerful force, but it is not *certain* to regulate code distribution. This all leaves something to chance which the APSL does not, although the APSL resolves it in a manner which is clearly unsatisfactory to many people. > Just as a practical matter, this may be an impediment to using > modified APSL code in a company that has restrictions about what its > employees may publish. I agree, but I believe that this is a general problem with the *idea* of Open Source rather than Apple's implementation of it. - Rob. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: YAPL is bad (was: Re: Backlog assistance?)
on 24/9/01 7:55 am, Rick Moen at [EMAIL PROTECTED] wrote: > One possible addition to the OSD, to deal with this matter, might be > as follows: > > 10. The Licence Must Not Violate Privacy of Individuals or Organisations > > The licence must not attach any obligations to usage of the covered code > that is entirely internal to the non-public affairs of the individual or > organisation using it. To clarify my opinion (IANAL): If this clause was added it would give organizations one less thing (exposure of information regarding private affairs) to worry about in adopting open source licenses, and so seems very desireable. It does however clash with many existing licenses that assume acceptance of the license by usage of the code and give a general offer of distribution on this basis. It also requires a fair amount of legalese to clarify "public" and "non-public" usage, and very careful auditing. Finally, I believe that it requires licenses to build in a back door for the closing off of open source code, one that unscrupulous organizations will eagerly exploit. - Rob. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: YAPL is bad (was: Re: Backlog assistance?)
on 24/9/01 11:16 am, John Cowan at [EMAIL PROTECTED] wrote: > the GPL > imposes no such obligation to the world at large. If you distribute a > derivative work, you are obliged to distribute the original *to the recipients > of the derivative work*; likewise, if you distribute binaries, you are obliged > to distribute source *to the recipients of the binaries*. It is called the "Public" license... This may be a misunderstanding on my part, and if so I apologize in advance. >From the GPL we have the statement: "You may copy and distribute verbatim copies of the Program's source code as you receive it," I agree that this is an offer rather than a directive. But the effect of making the source (ultimately) available to anyone is the same as soon as the license is accepted. The GPL has this effect, the APSL makes this effect explicit. Any attempt to control this (by requiring that employees or clients not distribute the source) is in breach of the license. This distribution will have copyright dates and file dates in it (and it may be a simple, if annoying, security measure to set the dates to 1970...). It identifies the originator/modifier of the source. The code may have dates, names and other information in comments. People can remember when they received the code. Extra information is given out anyway, but again the APSL makes this an explicit requirement. Explicit requirements are good. IANAL, but from my reading the APSL is specifying the minimum display requirements, not the exact or maximum ones. So if you need to obfuscate the project dates you can take the sources down five years after the project fails and start displaying them six months before it goes live. If it's that important to keep the dates of a project a secret, it probably shouldn't be used under a license with *any* distribution offer/obligation. This is therefore a general FUD concern for Open Source, not a specific problem with the APSL. - Rob. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: YAPL is bad (was: Re: Backlog assistance?)
on 24/9/01 7:55 am, Rick Moen at [EMAIL PROTECTED] wrote: > I note that Russ invited my comment on the APSL publication clause. > I am trying to ignore the gratuitous personal gibes, and will keep > doing so, but, on the other hand will accept his invitation. Can people claiming (or wishing) to represent opensource.org please act like professionals in dealing with issues they regard as annoying. I know it's difficult but I've seen people lose perfectly valid arguments on the basis of over-reaction to personality rather than debate. And you'll get quoted on news sites. > ...it introduces a novel obligation to disclose one's private affairs. >... > The licence must not attach any obligations to usage of the covered code > that is entirely internal to the non-public affairs of the individual or > organisation using it. Well, that's the GPL out for starters. :-) Apple's distribution clause is extroadinary in its legalese not its intent, and IMHO robustness and clarity of licenses is good. - Rob. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: documentation
IANAL On Tuesday, August 28, 2001, at 04:56 pm, [EMAIL PROTECTED] wrote: > someone did mention the QPL license earlier. > I looked at it, but my concern is that it > uses the word "software" everywhere. If the license isn't copyrighted, just search & replace. Or define "the software" to be your document. > There's also the notion of "patches" in QPL, > and that could be widely interpreted when > applied to a Word document. So define "patches" when defined to your document. "Ammendments" is a concept you mention > I've considered writing the document as a perl > program, such that the program dumps the text > to the screen. And then license the program as QPL. > That might be an option, but then I lose any > formating information and images that may have > been in the Word document. You could just write a Perl program to dump the Word document. I'm not sure that either approach provides the protection you're after. > as far as Artistic License goes, it has the same > problems by refering to "software". Plus, isn't it > pretty much agreed that it's a shaky license? > I know they're intending on rewriting it for Perl 6. There's a revised artistic license available that addresses the concerns IIRC. > And all of this just because there's > no license for Word documents, PDF's, etc. There's various open content/documentation licenses. The Open Gaming License is the most complete I know of, but you'd need to remove the word "game/gaming" from it (and it's not OSI approved,of course). > Rather than simply have a documentaion license, > I have to do a bunch of work to make my document > look like software so I can license it with an > OSI approved license. It just seems odd to me. It is. Just define your document as "the software" or do search-and-replace. Or let go of having an OSI approved license. IANAL, as I say. - Rob. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
