On Tue, May 27, 2003 at 03:19:45PM -0400, Brian T. Sniffen wrote: > Anthony DeRobertis <[EMAIL PROTECTED]> writes: > > On Friday, May 23, 2003, at 03:30 PM, Brian T. Sniffen wrote: > > ... > > In Lotus Development Corp. v. Borland International, Inc.,[0] the > > court held that a menu structure is method of operation. Methods of > > operation are, by statute, not copyrightable. To quote the decision: > > > > We think that "method of operation," as that term is used > > in 102(b), refers to the means by which a person operates > > something, whether it be a car, a food processor, or a > > computer. > > > > We hold that the Lotus menu command hierarchy is an > > uncopyrightable "method of operation." The Lotus menu > > command hierarchy provides the means by which users control > > and operate Lotus 1-2-3. .... Users must use the command > > terms to tell the computer what to do. Without the menu > > command hierarchy, users would not be able to access and > > control, or indeed make use of, Lotus 1-2-3's functional > > capabilities. > > > > The Lotus menu command hierarchy does not merely explain > > and present Lotus 1-2-3's functional capabilities to the > > user; it also serves as the method by which the program > > is operated and controlled. > > <gibber> > > OK. Well, that settles that argument: if this hasn't been reversed, > you're unambiguously correct. Thanks for pointing this out! > > I wonder how this relates to library interfaces... certainly, those > are methods of operation as well. >
IANAL, TINLA As far as I recall that famous case, the case was about the right to re-implement a programmable interface and whether preserving the interface names was a Copyright infringement on the original implementation. This, I believe, is the landmark ruling that it is not illegal for GNU bash to accept the same language and keywords as AT&T sh, for lesstif to be a drop in replacement for Motif etc. The case was not directly about whether someone *using* a proprietary or GPL interface is implicitly deriving from that interface but the ruling may confirm the common theory that gcc for Solaris is not a derivative of the SunOs interface just because it is written to use it. Anyway, I thought the common GPL linking claim was that the runtime in-memory process image includes a copy of the GPL code and is thus a derivative of that copy. Thus at least in the GPL case, the problem is where the borderline is between the last and third-last paragraph of GPL-2 clause 2, with the two extremes being: A: The two pieces of code do not in any way talk to each other but are on the same disk, falling under the explicit mere aggregation provision of clause 2. B: The lines are manually mixed together in the source code of a single medium sized function in a single source file, making the entire function a GPL derivative which must be under the GPL unless otherwise permitted by the author of the old GPL part. If the GPL lines were deleted again, the old GPL parts no longer force GPL-ing of the other lines, but recipients of the combination could continue to act and distribute under the GPL they received it under. So the question is "When does a combination of a GPL piece of code and some independent pieces of code reside so close together at runtime, that the combination forms a single derived work of the GPL piece of code and becomes subject to the GPL as a whole, including each and every part regardless who wrote it?" Borland vs. Lotus as quoted doesn't say much here, since the whole case was about a situation where the Borland and Lotus code where not even on the same (non-networked) computer. Hope this helps even though it doesn't clear up much, sorry. Jakob -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any.
