Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
On Tue, May 27, 2003 at 03:19:45PM -0400, Brian T. Sniffen wrote:
> Anthony DeRobertis <asd@suespammers.org> 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.
Reply to: