Plug-ins and the GPL
Richard Stallman
People have been talking about how the GNU GPL applies to plug-ins;
specifically, plug-ins that are implemented by dynamic linking into a
master program.
The key to answering this is to realize that there is no legal
distinction between dynamic linking and static linking. The plug-in
is therefore an extension to the master program; the two become part
of a larger combined program. On this basis, you can easily figure
out the consequences of the GPL: using GPL-covered code in the larger
combined program is permitted only if the combined program as a whole
is free under the GPL.
I was recently sent a hypothetical scenario which was stated very
clearly; here is how I responded.
Party One produces Program A which can load object code from separate
plugin files. They do not use any GPL code to create Program A. They
distribute Program A as commercial software.
Has Party One violated the GPL?
Party One is not violating the terms of any GPL-covered program, because
they are not using one. So they are not violating the GNU GPL.
After the release of Program A, Party Two produces Plugin B, to be loaded
by Program A. Plugin B uses modified GPL code. Party Two distributes Plugin
B binaries and source code under the terms of the GNU GPL.
Party Two has violated the GNU GPL by converting the GPL-covered code into a
modification for Program A. Since they cannot distribute the whole of
the modified Program A under the GPL, they cannot comply with it.
Therefore they will have to stop distributing this plug-in.
So what are the consequences? If Party Two makes such a plug-in, does
Party One have to release source code for Program A? No; Party One
doesn't have to do anything different, because Program A and Party One
are not responsible for the problem. Only Party Two is responsible.
They will have to stop distributing Plugin B, since they can't do it
in accord with the GPL.
Conversely, if the master program is GPL-covered, then a non-free
plug-in would violate the GNU GPL, just like non-free modifications to
the master program made in other ways.
I should point out that, strictly speaking, the GNU GPL can never
require anyone to release source code for his own modules if he does
not want to. What it requires is *not to combine those modules* with
GPL-covered code in a larger program.
I don't know when there will be a version 3 of the GPL, but I am going
to clarify this in the "development version" now.
Geoffrey KEATING
OK. Let's try to make this completely clear.
Consider a non-free operating system, MacOS. Assume that it's not
possible to distribute the source to it (the source got eaten by a
non-free version control system :-).
In this operating system, most pieces of code are `shared libraries'.
Applications are shared libraries. Plug-ins are almost always shared
libraries. Both applications and plug-ins use operating system
routines by having undefined symbols in the shared libraries (just
like ELF-based shared libraries under linux). Plug-ins may also use
routines of the affected application in the same way, by referencing a
symbol defined in the application. This is not particularly different
from the position under Hurd, Windows, Linux, or Solaris.
1. Now, gzip, a GPL-licensed program, has been ported to MacOS. Is this
allowed by the GPL? Is the result allowed to be distributed in source
form? In binary form (with the source)? Does it matter if the
compiler and header files required to build it are not free? Does it
matter if `porting' in this case just meant recompilation, so no
source-code changes were required?
2. One part of MacOS is called 'Easy Open'; it lets users write
`translators' that take a file which an application cannot read, and
translate it to a file which an application can read, when the
application tries to open the file.
Suppose someone created such a translator, by modifing the source code
to gzip, so that applications could read gziped files (much as emacs
does). Is this allowed? Can the result (binary? source) be
distributed? Does it matter if the source code did not need to be
modified?
3. Now, suppose that some application took its own
application-specific translators, and didn't use Easy Open. Can we
make a version of the 'gzip' translator for this application? Can the
result be distributed? Does it matter if the application could use
Easy Open translators (but not through Easy Open), so the translator
for (3) is the same as for (2)?
In particular, what is the distinction between the three cases above?
I think rms wants to permit (1) and (2), but prohibit (3); but I
believe that at present, the GPL permits all three.
I don't accept RMS's argument that the plugin (3) is the making of 'a
modification' _for the application_. The application is not changed
by the making of a plugin for it. You do not need to distribute the
application or its source code with the plugin under the GPL; the
plugin does not 'contain' the application (see clause 3 of the GPL),
any more than applications 'contain' the operating system. You _do_
need to supply any header files that describe the interface between
the application and the plugin and are used to compile the plugin;
they must not be GPLed.
If you actually _use_ the plugin, then a combined work is formed in
memory. But that work would not be distributed, so that's OK.
PS: I'm aware that there is a non-GPLed zlib. For the purposes of the
discussion, assume that we're not using it; everything is derived from
the GPLed GNU zip.
--
Geoff Keating <Geoff....@anu.edu.au>
Andreas Borchert
On Thu, 14 May 1998 01:23:16 -0600, Richard Stallman <r...@santafe.edu> wrote:
> After the release of Program A, Party Two produces Plugin B, to be loaded
> by Program A. Plugin B uses modified GPL code. Party Two distributes Plugin
> B binaries and source code under the terms of the GNU GPL.
Consider the case that Plugin B cannot only be loaded by Program A but
also by the GPLed Program C. The author of Plugin B could even be not
aware of the existence of Program A.
The key point seems to be whether a plug-in was specifically designed
to work exclusively with a given program or not. If a common interface
for loading is used, however, none of the authoring parties can be held
responsible for the aggregation of GPLed software components with
proprietary software.
On traditional systems we had just one big operating system that was
able to load programs. Today we have in many cases a nested situation
where programs running as user process under a traditional operating
system work like virtual operating systems on the other side (eg web
browsers). Because programs loaded by virtual operating systems are
sometimes called ``plug-ins'' or ``modules'' instead of ``program'' we
should not treat them differently.
> Party Two has violated the GNU GPL by converting the GPL-covered code into a
> modification for Program A.
Who says that modifications are necessary?
I'm not familiar with BeOS but how is it to be considered when no
modifications are necessary for Linux kernel modules to allow them to
be loaded under BeOS? What makes a Linux driver module different from a
binary in /usr/bin in ELF format? ELF is a standard that is in use on
GPLed and proprietary operating systems. Likewise the kernel module
interface of Linux can be seen as standard that may be freely supported
on other proprietary systems as well.
> Conversely, if the master program is GPL-covered, then a non-free
> plug-in would violate the GNU GPL, just like non-free modifications to
> the master program made in other ways.
And who is violating it if modifications of the master program weren't
necessary?
Andreas.
--
Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm, Germany
E-Mail: borc...@mathematik.uni-ulm.de
WWW: http://www.mathematik.uni-ulm.de/sai/borchert/
PGP key available via ``finger borc...@laborix.mathematik.uni-ulm.de''
James Youngman
>>>>> "RMS" == Richard Stallman <r...@santafe.edu> writes:
RMS> Party One is not violating the terms of any GPL-covered
RMS> program, because they are not using one. So they are not
RMS> violating the GNU GPL.
RMS> After the release of Program A, Party Two produces Plugin
RMS> B, to be loaded by Program A. Plugin B uses modified GPL
RMS> code. Party Two distributes Plugin B binaries and source
RMS> code under the terms of the GNU GPL.
RMS> Party Two has violated the GNU GPL by converting the
RMS> GPL-covered code into a modification for Program A. Since they
RMS> cannot distribute the whole of the modified Program A under the
RMS> GPL, they cannot comply with it. Therefore they will have to
RMS> stop distributing this plug-in.
Stipulating that the law does not distinguish between static and
dynamic linking, it will still take account of *where* this linking
process takes place, surely?
Even granting that Program B is a "modification for" A, that
modification takes place in the privacy of the user's own computer and
the result is not distributed. It's not clear to me that program B
alone in isolation constitutes a work derived from program A.
Suppose the plugin interface is that A loads a copy of B into memory
and looks up the address of the symbol "_main" in B. It then calls
it. When this returns, an integer result is recorded. Is B *really*
a work derived from A for the purposes of the GPL? If so, I think
that that is unfortunate.
(I realise that RMS doesn't read Usenet and I have not sent him a copy
by email, and so he won't see this response).
Greg Stark
Geoffrey KEATING <geo...@discus.anu.edu.au> writes:
> OK. Let's try to make this completely clear.
>
> Consider a non-free operating system, MacOS. Assume that it's not
> possible to distribute the source to it (the source got eaten by a
> non-free version control system :-).
The GPL contains a special exemption for operating systems. This isn't
because the FSF thinks it's ok that many operating systems aren't free
software, but rather because they think allowing GPL'd software to be
used on non-free systems will encourage more free software development.
This is similar to the motivation for the LGPL, it's doesn't exist
because the FSF thinks non-free software using free libraries is ok,
but rather because pragmatically it might encourage the development of
the free library. In some cases (glibc for example) it has been very
successful, in others it hasn't.
From the GPL:
> However, as a special exception, the source code distributed need not
> include anything that is normally distributed (in either source or
> binary form) with the major components (compiler, kernel, and so on)
> of the operating system on which the executable runs, unless that
> component itself accompanies the executable.
greg
Milan Zamazal
>>>>> "RMS" == Richard Stallman <r...@santafe.edu> writes:
RMS: Conversely, if the master program is GPL-covered, then a
RMS: non-free plug-in would violate the GNU GPL, just like non-free
RMS: modifications to the master program made in other ways.
Does a non-free program written in Emacs Lisp for Emacs violate GPL?
I think there are such programs. Are they legal or do they have got
special permission from FSF? If the first, what is the difference
between such a program and a plug-in?
Milan Zamazal
jo...@dhh.gt.org
James Youngman writes:
> Suppose the plugin interface is that A loads a copy of B into memory and
> looks up the address of the symbol "_main" in B. It then calls it. When
> this returns, an integer result is recorded. Is B *really* a work
> derived from A for the purposes of the GPL?
Of course not. B does not contain a copy of all or part of A, and therefor
cannot be a derivative of A. In copyright law B is derived from A if and
only if it contains a copy of part or all of A (in excess of the small
amount of copying permitted by 'fair use').
If RMS or anyone else knows of any statutes or case law that contradicts
this, please post the citations.
--
John Hasler This posting is in the public domain.
jo...@dhh.gt.org Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.
Thomas Bushnell, n/BSG
jo...@dhh.gt.org writes:
> Of course not. B does not contain a copy of all or part of A, and therefor
> cannot be a derivative of A. In copyright law B is derived from A if and
> only if it contains a copy of part or all of A (in excess of the small
> amount of copying permitted by 'fair use').
But the derived work is A+B. B is intending to distribute such a
work, by a subterfuge, and is contributing to a net effect of
infringement.
The law looks at intentions and total effects, not just individual
atomic actions. The sum of many independently legal things may be a
very illegal thing.
Thomas
Isaac
In article <u1h90o4...@pusey.MIT.EDU>, Thomas Bushnell, n/BSG wrote:
>
>But the derived work is A+B. B is intending to distribute such a
>work, by a subterfuge, and is contributing to a net effect of
>infringement.
>
Subterfuge seems like a completely inappropriate way of describing
a plug-in. People who write plug ins are not trying to distribute
the original work, but only to distribute additional functionality. Yes
it is true that if you don't already have Photoshop you might want to
purchase it to make use of a plug in, but it would seem to be
a real stretch to say the plug in author was responsible for any legal
or illegal attempts someone might make to get a copy of Photoshop.
In some of the previous discussions this subterfuging of intended
activity seemed to have merit in that the motives of the authors might
be suspect. Here labeling the activity as a subterfuge would seem to
be begging the question.
>The law looks at intentions and total effects, not just individual
>atomic actions. The sum of many independently legal things may be a
>very illegal thing.
>
It's also true that something legal can be accomplished by avoiding
all illegal independent steps. I don't think this line of argument
shows anything.
Isaac
Chris Hanson
Date: Thu, 14 May 1998 01:23:16 -0600
From: r...@santafe.edu (Richard Stallman)
People have been talking about how the GNU GPL applies to plug-ins;
specifically, plug-ins that are implemented by dynamic linking into a
master program.
[...]
I think this is skirting near the edge of a deeper issue.
Namely, how is this situation different from the one in which a GPL'd
program is used on a non-GPL'd operating system?
You are considering the technical details, specifically that a linking
mechanism is being used. So you conclude that this is equivalent to
statically linking the plugin into the non-free program.
But viewing this from a behavioral aspect, it appears that the plugin
developer is building a small program that is designed to run in the
"operating system" that is provided by the browser.
For a closer example, imagine that someone has written a KDE program
that is covered by the GPL. KDE is _not_ free, yet it provides
programming facilities that are very similar to those provided by the
browser to the plugin. Why is there a distinction between the KDE
program and the plugin?
From this point of view, I think one can argue that it is reasonable
to allow GPL'd plugins. (Note that I am not saying that these are
legal under the current GPL.)
Finally -- given your interpretation, it seems to me that it is legal
for a developer to cover such a plugin with the LGPL. Given that, why
is there any issue in the first place? Just use the LGPL for such
programs.
Isaac
In article <1998051407...@wijiji.santafe.edu>, Richard Stallman wrote:
>
[snipped discussion of GPL and plug-ins]
>I don't know when there will be a version 3 of the GPL, but I am going
>to clarify this in the "development version" now.
>
I think clarifying your intentions in a future GPL is a good idea, because
it will certainly result in most people acquiescing to your desires.
If your interpretation of programs and plug-ins being joint works was
tested in court, I believe that what will ultimately be important is
that the restriction is supported by copyright law rather than by any
words in the GPL.
I find the following case more illustrative than the ones Mr. Stallman
addressed. Author A writes a GPL'd plug-in to implement
some graphic transformation and publishes or other wise makes
obvious the interface. Author B likes the plug in so much that he writes
a proprietary program that could use the plug-in, and writes a bunch of
graphic transformation plug-ins of his own. The author doesn't bother
duplicating Author B's plug-in.
Does anyone believe or is there any case law to support the following:
1. Author B cannot distribute his program.
2. Author B must write a his own version of the GPL'd plug-in
before he distributes his program.
3. This case is not relevant because the order of the creation
of program and plug-in makes a difference.
If these kinds of things could be restricted by copyright law, I don't
think we'd see software publishers spending so much time convincing
us we didn't own copies of their software just licenses.
Isaac
Steve Peltz
In article <cph.310...@flenser.ai.mit.edu>,
Chris Hanson <c...@zurich.ai.mit.edu> wrote:
>Finally -- given your interpretation, it seems to me that it is legal
>for a developer to cover such a plugin with the LGPL. Given that, why
>is there any issue in the first place? Just use the LGPL for such
>programs.
Because you can't take GPL code (that someone else has written) and
distribute it under the LGPL without their permission? If all the code
is yours, you can of course release it however you want; that isn't
the issue. The question is, if what you're releasing ALSO contains code
derived from GPL sources, is it allowed to be dynamically linked with
proprietary code (even if the proprietary code was not distributed with
the GPL code)?
RMS seems to say no. So, if you have written a Photoshop replacement that
uses GPL code, apparently you must make sure it can't load a proprietary
Photoshop plug-in, and make sure that GPL-ed plug-ins can't be loaded
by the proprietary Photoshop. Unfortunately (from RMS's viewpoint),
there's then nothing to prevent Adobe from looking at the new interface
you've defined, and make their version accept both the proprietary and
non-proprietary versions, unless RMS is going to start asserting an
interface copyright.
Then, of course, if someone comes along and makes a "Photoshop plug-in
loader", which is itself a plug-in for the GPL-ed version, I'm not sure
what anyone can do about that, either.
Or, if someone comes out with a public-domain stand-alone Photoshop
plug-in loader (containing no GPL code, but not necessarily doing anything
actually useful), then it would seem that all of a sudden it would be
ok to modify the GPL-ed Photoshop replacement to load either type of
plug-in, which seems to me to be a ridiculous outcome.
Leslie Mikesell
In article <1998051407...@wijiji.santafe.edu>,
Richard Stallman <r...@gnu.org> wrote:
>People have been talking about how the GNU GPL applies to plug-ins;
>specifically, plug-ins that are implemented by dynamic linking into a
>master program.
>
>distinction between dynamic linking and static linking. The plug-in
>is therefore an extension to the master program; the two become part
>of a larger combined program.
This doesn't make much sense in the context of programs that
can dynamically load arbitrary extensions at run time. No
one can anticipate the possible combinations. As an extreme
example, consider the apache web server with the mod_perl extension
loaded. Mod_perl, being a complete embedded perl is capable
of dynamically linking additional shared libs with module wrappers
at run time, and in the interest of speed it keeps them loaded
as it serves the next requests. So, given an assortment of GPL'd
and commercial libraries and modules and a random assortment of
programs referencing them you are going to end up with an executable
combining them even though they may never actually reference
each other.
>On this basis, you can easily figure
>out the consequences of the GPL: using GPL-covered code in the larger
>combined program is permitted only if the combined program as a whole
>is free under the GPL.
Do I understand correctly that this dissallows using the GPL on
any shared library that can be wrapped as a perl module on the
basis that it can end up linked to commercial libraries?
>Party Two has violated the GNU GPL by converting the GPL-covered code into a
>modification for Program A. Since they cannot distribute the whole of
>the modified Program A under the GPL, they cannot comply with it.
>Therefore they will have to stop distributing this plug-in.
What if no modification to the GPL'd library is done? A perl
program can use readline without modifying it, and the same
perl may be linked to a commercial database backend library.
The person who wrote and distributed the script may have used
the DBI/DBD interface with the install procedure or the end user
selecting the module that loads the commercial library.
>So what are the consequences? If Party Two makes such a plug-in, does
>Party One have to release source code for Program A? No; Party One
>doesn't have to do anything different, because Program A and Party One
>are not responsible for the problem. Only Party Two is responsible.
>They will have to stop distributing Plugin B, since they can't do it
>in accord with the GPL.
Will this apply to readline in the above case?
>I should point out that, strictly speaking, the GNU GPL can never
>require anyone to release source code for his own modules if he does
>not want to. What it requires is *not to combine those modules* with
>GPL-covered code in a larger program.
Given multiple parties involved and interchangable GPL/non-GPL libraries
how can anyone predict the eventual combinations?
>I don't know when there will be a version 3 of the GPL, but I am going
>to clarify this in the "development version" now.
I don't think it is clear in this posting unless you meant to disallow
the GPL on all shared libraries.
Les Mikesell
l...@mcs.com
Tim Smith
Thomas Bushnell, n/BSG <t...@mit.edu> wrote:
>jo...@dhh.gt.org writes:
>> Of course not. B does not contain a copy of all or part of A, and therefor
>> cannot be a derivative of A. In copyright law B is derived from A if and
>> only if it contains a copy of part or all of A (in excess of the small
>> amount of copying permitted by 'fair use').
>
>work, by a subterfuge, and is contributing to a net effect of
>infringement.
I have been unable to find any copyright cases that mention the concept
of a distribution by subterfuge.
--Tim Smith
Tim Smith
E. Gkioulekas <egki...@u.washington.edu> wrote:
>IANAL and IANARMS :) But let me hazard a guess. If program C exists,
>then Party Two has the right to distribute Plugin B. For as long as
>program C does not exist Party Two can not distribute Plugin B.
Whether or not the plug-in violates the copyright of A cannot be
affected by the existence or non-existence of program C. If the plug-in
does not violate any copyright of A, then the licensing of A is
irrelevant. If the plug-in does violate the copyright of A, then the
existence of C does not change that, and the plug-in must obey A's
license.
--Tim Smith
Thomas Bushnell, n/BSG
Milan Zamazal <p...@informatics.muni.cz> writes:
> Does a non-free program written in Emacs Lisp for Emacs violate GPL?
> I think there are such programs. Are they legal or do they have got
> special permission from FSF? If the first, what is the difference
> between such a program and a plug-in?
Emacs Lisp programs do not have to be distributed under the GPL
because they are not regarded as being the same program as emacs.
The meaning of "same program" is a human concept, not a programming
concept, and the law pays attention to all the facts and details and
attentions to figure out.
The issue is "what are you doing" not "what technical mechanisms are
you using". If what you are doing is prohibited, then it doesn't
matter what technical mechanims are used.
Thomas
Stephen Robert Norris
In article <wksomdx...@generation.net>,
Greg Stark <st...@generation.net> intoned:
Coming at this from a Linux perspective, this seems to rule out GPL'ed
Motif applications, since Linux doesn't ship with Motif (and Motif is
not GPL'ed).
Is that true, or have I misunderstood.
RMS's original post has caused much FUD amongst us Gnome developers - to
the extent that there is a serious move to re-release under a different
license and abandon the GPL'ed version...
Stephen
E. Gkioulekas
fantome/@/usa/./net (le Fantôme) writes:
>On Thu, 14 May 1998 01:23:16 -0600, r...@santafe.edu (Richard Stallman)
>wrote:
>> Party One produces Program A which can load object code from separate
>> plugin files. They do not use any GPL code to create Program A. They
>> distribute Program A as commercial software.
>>
>> Has Party One violated the GPL?
>>
>> After the release of Program A, Party Two produces Plugin B, to be loaded
>> by Program A. Plugin B uses modified GPL code. Party Two distributes Plugin
>> B binaries and source code under the terms of the GNU GPL.
>>
>>Party Two has violated the GNU GPL by converting the GPL-covered code into a
>>modification for Program A. Since they cannot distribute the whole of
>>the modified Program A under the GPL, they cannot comply with it.
>>Therefore they will have to stop distributing this plug-in.
>This still doesn't address the case of:
> Party Three produces a GNU GPLed Program C which can load
> plugins which are loadable by Program A. Does Party Two then
> have the right to distribute Plugin B again?
IANAL and IANARMS :) But let me hazard a guess. If program C exists,
then Party Two has the right to distribute Plugin B. For as long as
program C does not exist Party Two can not distribute Plugin B.
> What about Party Four, who produces a non-free Plugin D for
> Program A, but because Party Three created a program which
> can use those plugins, it works with Program C as well as
> Program A?
So long as Program A exists, Plugin D can be distributed. If only GPLed
programs can load Plugin D, then Plugin D can not be distributed.
To summarize:
1. A GNU plugin can be distributed if a GNU program exists that
can load it. In this case the existence of a corresponding proprietory
program is irrelevant.
2. A proprietory plugin can be distributed unless the only programs that
can load it are licensed incompatibly with the plugin. The existence of
GNU programs is irrelevant if there exist proprietory programs that
can load the plugin.
3. A plugin that predates a loading program can't be derived work
of the program in any way, but I don't know how much fucked the copyright
law is.
That's really confusing. I'm not sure if I got it all straight or not.
>See, you can't merely take a simplistic approach to this problem. If
>you're saying that Plugin B can only be used with Program C and that
>Program C cannot legally use Plugin D (even if the user later
>downloaded Plugin D on their own), this indicates that the GNU GPL is
>not keeping up with the realities of the industry and should either be
>updated to be more useful immediately, or be abandoned very quickly.
Abandoning the GPL is unrealistic and not-practical. I do agree however
that it needs to be updated wrt to this issue, even if only for the
sake of clarification.
>I'd rather see it updated to be useful immediately. While there might
>not be any difference between static linking and dynamic linking in
>the traditional sense, there is a significant difference between those
>two and the "linking" performed by plugins.
>-f
>--
>austin ziegler * fantome*@*vnet*.*net * http://fantome.vnet.net/
>---------------* aziegler*@*vcela*.*com * -------------------------
>Remove the stars to email me * Ni bhionn an rath ach
>my words my opinions my ideas * mar a mbionn an smacht
> -- I Argue Ideas, Not Beliefs: Give Up Your Dogma --
Marcus Sundberg
In article <1998051407...@wijiji.santafe.edu>,
r...@santafe.edu (Richard Stallman) writes:
> People have been talking about how the GNU GPL applies to plug-ins;
> specifically, plug-ins that are implemented by dynamic linking into a
> master program.
>
> clearly; here is how I responded.
>
> plugin files. They do not use any GPL code to create Program A. They
> distribute Program A as commercial software.
>
> Has Party One violated the GPL?
>
> they are not using one. So they are not violating the GNU GPL.
>
> After the release of Program A, Party Two produces Plugin B, to be loaded
> by Program A. Plugin B uses modified GPL code. Party Two distributes Plugin
> B binaries and source code under the terms of the GNU GPL.
>
> Party Two has violated the GNU GPL by converting the GPL-covered code into a
> modification for Program A. Since they cannot distribute the whole of
> the modified Program A under the GPL, they cannot comply with it.
> Therefore they will have to stop distributing this plug-in.
>
> Party One have to release source code for Program A? No; Party One
> doesn't have to do anything different, because Program A and Party One
> are not responsible for the problem. Only Party Two is responsible.
> They will have to stop distributing Plugin B, since they can't do it
> in accord with the GPL.
To think that Party Two in any way is violating the GPL is
absurd!!!
If Microsoft would take the Linux-kernel add a bunch of
proprietary stuff and release it as NT6 (without source
of course), would Linus be violating the GPL and have to
stop distributing Linux?
Of course not!
And neither is Party Two violating the GPL in the above scenario.
He simply writes some GPL'ed code, release it with source and
naturally can't be held responsible for what other people use
that code for.
//Marcus
--
-------------------------------+------------------------------------
Marcus Sundberg | WWW: http://www.e.kth.se/~e94_msu/
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: e94...@e.kth.se
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Just some junk, please ignore!
Isaac
In article <6jg14d$v1l$1...@crux.cs.usyd.edu.au>, Stephen Robert Norris wrote:
>
>Coming at this from a Linux perspective, this seems to rule out GPL'ed
>Motif applications, since Linux doesn't ship with Motif (and Motif is
>not GPL'ed).
>
>Is that true, or have I misunderstood.
>
designated to have the operating system exception. I don't think
there is a problem with GPL'ed Motif applications.
>RMS's original post has caused much FUD amongst us Gnome developers - to
>the extent that there is a serious move to re-release under a different
>license and abandon the GPL'ed version...
>
> Stephen
Isaac
mcg...@indirect.com
In article <wksomdx...@generation.net>,
Greg Stark <st...@generation.net> wrote:
> The GPL contains a special exemption for operating systems. This isn't
> because the FSF thinks it's ok that many operating systems aren't free
> software, but rather because they think allowing GPL'd software to be
> used on non-free systems will encourage more free software development.
>
>
> > However, as a special exception, the source code distributed need not
> > include anything that is normally distributed (in either source or
> > binary form) with the major components (compiler, kernel, and so on)
> > of the operating system on which the executable runs, unless that
> > component itself accompanies the executable.
This exception seems kind of vague to me. Would Internet Explorer be
considered a "major component" of Windows 98 as Microsoft wants to
release it? If so, then can't I create a version of emacs that runs
only as some kind of Internet Explorer-specific plug-in and legally
distribute it under the GPL? This seems to be a perfect example of
what RMS's interpretation is trying to avoid, yet I can't see how it
would be disallowed.
What if non-GPL'd "Program X" is included with almost every Linux
distribution? Is it then a "major component", and therefore
compatible with GPL'd plug-ins?
I can see what the clause is trying to allow, but my point is that
the parenthetical remark "(compiler, kernel, and so on)" doesn't
seem to be enough to give "major component" the desired definition.
I also have one question: say GPL-covered "Program A" and commercial
"Program B" share a common plug-in API. If a GPL'd program is written
using this API, can it be "reasonably considered" an "independent
and separate work" as opposed to a modification to Program A, and
therefore linked with either A or B without problems?
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
John Cavanaugh
Richard Stallman <r...@santafe.edu> wrote:
> People have been talking about how the GNU GPL applies to plug-ins;
> specifically, plug-ins that are implemented by dynamic linking into a
> master program.
Im not a legal expert and Ive always considered myself a proponent of
the free software movement but the following statements really concern
me....
But be aware my comments are more centered around my emotional reaction
(severe disappointment) than legal aspects.
> Party Two has violated the GNU GPL by converting the GPL-covered code into a
> modification for Program A. Since they cannot distribute the whole of
> the modified Program A under the GPL, they cannot comply with it.
> Therefore they will have to stop distributing this plug-in.
This is insane... Its free source, I thought that was the whole purpose.
If the source code is available whats the problem.
In my opinion, if the master program is a viable program that can stand
on its own merit (ie. Not completely crippled if the GNU plug-in is not
there) than this shouldnt be an issue. This way GNU software is only
extending an already viable program and thus protecting GNU software
from being a complete basis for a commercial package.
Ill leave up to the experts to hash out exactly what "viable" means.
> Conversely, if the master program is GPL-covered, then a non-free
> plug-in would violate the GNU GPL, just like non-free modifications to
> the master program made in other ways.
This is also insane... Its also free source...
The standalone viability concept can be applied here as well. If the
master program is a viable program that can stand on its own merit (ie.
Not completely crippled if the proprietary plug-in is not there) than
this shouldnt be an issue either. Why should we care if a commercial
company wants to support a free product? I think its flattering and only
lend more credibility to the whole GNU/Linux free software movement.
Otherwise we may be stunting the growth of emerging market for alternate
OS's.
> I should point out that, strictly speaking, the GNU GPL can never
> require anyone to release source code for his own modules if he does
> not want to. What it requires is *not to combine those modules* with
> GPL-covered code in a larger program.
> I don't know when there will be a version 3 of the GPL, but I am going
> to clarify this in the "development version" now.
Gosh I hope this isnt the direction things are going. I always believed
in GNU & free software but it doesnt have to be all or nothing, does it?
Cant things peacefully coexist in some fashion.
I guess I have spent too much time in Perl land where the Artistic
License is more liberal than the GPL and IMHO more truly represents what
I believe is the spirit of free software.
-----------------------------------------------------------------------
John Cavanaugh Hewlett-Packard Company
Process Engineer 16399 W Bernardo Drive
Office Products Division San Diego CA 92127-1899
Email: cava...@sdd.hp.com Phone: 619-655-7421
619-655-3665 (Fax)
-----------------------------------------------------------------------
Man is not the sum of what he has but the totality of what he does
not yet have, of what he might have.
-- Jean Paul Sartre
-----------------------------------------------------------------------
Osma Ahvenlampi
It might be just me, but it sure seems like RMS is going out of his
way to make it non-viable to use non-GPL and GPL code on the same
system.
Let's take an arbitrary quote I think explains the essence of RMS's
position and extrapolate a little..
RMS: "Using GPL-covered code in the larger combined program is
permitted only if the combined program as a whole is free under the
GPL."
Define: "program": a BeOS application, "code": a GPL add-on module to
the application. Under BeOS, applications do not link against their
add-ons, nor do add-ons have to link against the applications
(although they may; apps may export functionality to an agreed-upon
API, and any program which exports the same symbols can successfully
load the add-on). Code from the add-on is explicitly executed by
searching through its symbol table and calling the function
pointer. As such, I believe the only important distinction between
system("add-on") and load_add_on("addon");
get_image_symbol("symbol",&func); (func)(); is that the latter causes
the code to be executed in the same address space as the program
calling it. By RMS's definition, however, linkage doesn't matter, so
add-ons and the programs using them have to both be under GPL, if
either of them are. What about when the add-on is written to a
specific API that happens to be used by two programs, one of them
GPL'd, and the other not?
And a more contrived example..
Define: "program": Windows, "code": Info-ZIP. Arguably, code loaded
and executed by an operating system is an extension, aka. "plugin" to
the operating system. RMS says linkage method does not matter. This
particular "combined program" would apparently violate GPL. Result: no
GPL code can be used on any non-GPL operating system. It seems like
the ports of the GNU toolset, including Emacs, to proprietary OSes are
in violation of the license. And all you Linux users better delete
your proprietary apps (ApplixWare, StarOffice, x11amp, to provide a
couple of examples).
I used to be a fan of GPL, however this extremism makes me highly
doubtful of it's practical applicability for any purpose.
--
The usefulness of a meeting is inversely proportional to its attendance.
Osma Ahvenlampi <oa at iki fi> (damn spammers)
Osma Ahvenlampi
t...@mit.edu (Thomas Bushnell, n/BSG) writes:
> Emacs Lisp programs do not have to be distributed under the GPL
> because they are not regarded as being the same program as emacs.
> The meaning of "same program" is a human concept, not a programming
> concept, and the law pays attention to all the facts and details and
> attentions to figure out.
This is the main problem with GPL; it says combining GPL and non-GPL
code in the "same program" is illegal, but leaves the defition of
"same program" way too open for interpretation.
--
Polymer physicists are into chains.
dg...@chrysler.com
In article <1998051407...@wijiji.santafe.edu>,
r...@gnu.org wrote:
As much as I respect all that you have done, and of your beliefs and views
with regards to what "Free Software" is and does and should be, I think you're
wrong here, both in the details, and in the spirit of the GPL.
> People have been talking about how the GNU GPL applies to plug-ins;
> specifically, plug-ins that are implemented by dynamic linking into a
> master program.
Isn't that a description of all programs though? Isn't GCC (for example) a
plug-in for (insert non-free operating system here).
> The key to answering this is to realize that there is no legal
> distinction between dynamic linking and static linking. The plug-in
> is therefore an extension to the master program; the two become part
> of a larger combined program.
Well, by the same logic, running _any_ program is just an extension of the OS,
where the OS is the "master program". Conversely, if I only use (say)
Photoshop on my computer, hasn't Photoshop become my OS?
I don't think there's any legal distinction between a "program" and a
"plug-in". They both contain executable code. They are both atomic entities.
(Writing a plug-in does not require access to the "master program"'s source
code, so it is not a modification)
Let's look at your examples:
> Party One produces Program A which can load object code from separate
> plugin files. They do not use any GPL code to create Program A. They
> distribute Program A as commercial software.
>
> Has Party One violated the GPL?
>
> Party One is not violating the terms of any GPL-covered program, because
> they are not using one. So they are not violating the GNU GPL.
No argument. Cut and dried.
> After the release of Program A, Party Two produces Plugin B, to be
> loaded by Program A. Plugin B uses modified GPL code. Party Two
> distributes Plugin B binaries and source code under the terms of the GNU
> GPL.
>
> Party Two has violated the GNU GPL by converting the GPL-covered code into a
> modification for Program A. Since they cannot distribute the whole of
> the modified Program A under the GPL, they cannot comply with it.
> Therefore they will have to stop distributing this plug-in.
And this I completely disagree with. Party B has written code for a program
and released the source in complience with the GPL. They have not modified a
single line of Party A's code, so Program A has not been modified. The fact
that Program A is required to be able to execute Plugin B is irrelevent.
If this doesn't hold, if GPL-ed plugins for non-GPLed programs cannot be
distributed, then no programs can be released under the GPL for non-free
operating systems. Any program written for Windows, MacOS, AmigaDOS, most
UNIXen, etc. cannot be released under the GPL using this argument.
Now there is a potential point of contention as to if a program is or is not a
"plug-in" to the operating system, and another as to if a "master program" can
be treated as an "operating system" for plug-ins. From my point of view, it's
obvious that "they are" and "they can" - but let's ignore that for a second.
Now let's examine the consequences of a world in which Free plugins cannot be
written for Non-Free programs, and vice versa.
There are thousands of plug-ins available for various programs, but they
appear to be most prevelent in the graphics and publishing world, for tools
like PhotoShop, Quark, Lightwave, and so on.
They are so prevelent (and so useful) that a serious graphics program must be
able to use existing plug-ins. It would be impossible for a team maintaining a
"master program" to be able to duplicate all the functionality provided by the
set of available plug-ins. Nor should they want to - there's a lot of very
specialized plug-ins out there that simply aren't required by the majority of
users. A Free replacement for a commercial "master program" should be able to
use non-free plug-ins for this reason.
The flip side is that if someone writes a Free plug-in for a non-Free program,
(we assume that there's no perceived "market" for a commercial version) to
accomplish a certain task, they they should have the ability to distribute
that plug-in under the GPL for the greater good of the community.
> I don't know when there will be a version 3 of the GPL, but I am going
> to clarify this in the "development version" now.
If the current GPL is written so as to deny Free plug-ins/Non-Free Programs
and/or Non-Free plug-ins/Free software, then in my opinion, the GPL needs to
be re-written to specifically allow both cases.
DG
Dima Barsky
r...@santafe.edu (Richard Stallman) writes:
> People have been talking about how the GNU GPL applies to plug-ins;
> specifically, plug-ins that are implemented by dynamic linking into
> a master program.
>
> The key to answering this is to realize that there is no legal
> distinction between dynamic linking and static linking.
OK, forget dynamic linking. Suppose I wrote a program which uses
readline() function and I want to sell the binary. If I compile it
against Rich Salz's "editline" library (which does not impose any
restrictions on me), then it's all right. My program is not
derived from GPL code (does not contain any line of it), so I can use
any license I want. Only if I link it against the GPLed "readline"
library, then I create a derived work. As far as I understand, I still
can use that work myself, but can not distribute it under any license
other than GPL.
Would I violate the GPL if I sell the object modules of my
program (with the Makefile, but without sources), and let the buyer
link it against his own copy of the "readline" library? I think I
would not. Of course, the buyer will not be able to distribute the
resulting binary, but he still will be able to use it.
It looks like GPL does not differ much from LGPL (wrt libraries).
A GPLed library still does not force you to give away the source code
of a program based on that library. It just requires that you
distribute the object modules rather than the executable program,
I don't think it was the original intention of GPL..
--
Dima Barsky <D.Ba...@ee.surrey.ac.uk>
Roland Bergler
r...@santafe.edu (Richard Stallman) writes:
> People have been talking about how the GNU GPL applies to plug-ins;
> specifically, plug-ins that are implemented by dynamic linking into a
> master program.
>
> The key to answering this is to realize that there is no legal
> distinction between dynamic linking and static linking.
So where is the legal distinction between dynamic linking and
invocation via exec? If I wrote a tool designed to be called via
shell escape from a hypotetical non-GPLed emacs-clone useing
shell-command-on-region, wouldnt that mean you could not use any GPLed
code in this tool? The GNU fileutils could not be published unter the
GPL.
Possibly you should require in GPL3, that any GPL-covered program is
explicitly forbidden to have any interface to be callable by any
existing commercial software, because than it could be used as a
plugin to any commercial program.
So I dont think there is a legal distinction between a library, a shared
library and an executable.
> Party Two has violated the GNU GPL by converting the GPL-covered code into a
> modification for Program A. Since they cannot distribute the whole of
> the modified Program A under the GPL, they cannot comply with it.
> Therefore they will have to stop distributing this plug-in.
Put the other way round: If someone wrote a GPL Netscape clone
(GPLscape) with an interface for Netscape plugins, that would allow
anyone to release netscape plugins useing GPL-code, because he always
could state that he just enhanced GPLscape.
--
Roland Bergler
--
Roland Bergler rol...@wossname.m.isar.de
ber...@kratzer-automation.de
Michael Kagalenko
RMS is fanatic. Stay away from GPL.
Isaac
In article <355bd3c1...@news.vnet.net>, le Fantôme wrote:
>
>This is true if and only if the vendor of your copy of Linux has
>included Motif.
>
I believe it is irrelevant as to whether your vendor supports Motif.
It is okay to distribute GPL'd programs which are intended to link
with Motif. You can get Motif through any legal method you choose.
I think your statement comes from attempts to try to establish Motif
as a system component by showing that it's part of one or more
standard distributions. This argument is unnecessary since Motif's
status as a system component (at least for code controlled by FSF)
has already been officially stated.
Isaac
DJ Delorie
John Cavanaugh <cava...@hpsdlei8.sdd.hp.com> writes:
> This is insane... Its free source, I thought that was the whole purpose.
What RMS intended is that the *source* be free from the desires of the
people using it, not the other way around. The *source* has the
freedoms; the *users* are very restricted in what they can do with it.
The purpose of the GPL is to protect the sources, not the people.
Don Bashford
s...@flibble.psrg.cs.usyd.edu.au (Stephen Robert Norris) writes:
> Coming at this from a Linux perspective, this seems to rule out GPL'ed
> Motif applications, since Linux doesn't ship with Motif (and Motif is
> not GPL'ed).
>
> Is that true, or have I misunderstood.
I doubt if it's true, since GNU Emacs itself has a configuration
option to link with Motif.
Thomas Bushnell, n/BSG
Osma Ahvenlampi <oahv...@bounce.mail> writes:
> This is the main problem with GPL; it says combining GPL and non-GPL
> code in the "same program" is illegal, but leaves the defition of
> "same program" way too open for interpretation.
It's not a problem with the GPL, it's a "problem" with copyright law.
If putting the two things together creates a derivative work, then the
GPL applies. If it does not, then it does not.
That's the standard. It's the legal definition of "derivative work"
that is the point.
Now, it is the case that the commercial people who sell shared
library systems make it very clear that programs which link against
those shared libraries are every bit as much derivative works as
programs which link against static equivalents.
The reason is that the result is essentially the same, and the
technical details are officially quite irrelevant.
Now, many commercial vendors of shared library systems grant you very
liberal rights to make such derivative works. But they don't all do
that. And regardless, you have to know exactly what rights they grant
you and don't grant you.
This has nothing really to do with the GPL; the GPL applies to all
derivative works. If people are unhappy with the legal definition of
a derivative work as it applies to computer programs, they can
certainly write their congresscritters and express their disapproval.
Thomas
Thomas Bushnell, n/BSG
James Youngman <JYou...@vggas.com> writes:
> Stipulating that the law does not distinguish between static and
> dynamic linking, it will still take account of *where* this linking
> process takes place, surely?
It cares much more about who does the linking, who encourages the
linking, who is selling a product which is only useful if the linking
happens, and so forth.
Thomas
Kenneth Miller
Hmm. It seems to me that in the case of plugins, there are three
entities involved: The loading program, the loaded module, and the API.
This may or may not be RMS's interpretation, and it isn't really talked
about at all in the GPL, but here goes. The problem I can see people
having with exempting plugins which interact over an API from the
infection clause of the GPL is that companies will pay lip service by
spinning the GPLed code into a plug-in, which is then useless to the
community at large. So, instead of infecting the loading program,
infect the API. APIs cannot be copyrighted (as I understand it) but
they can be published, so the GPL can just require that if code is not
being used directly, the API must be public, and include everything
necessary to create either side of it. Basically, both sides are
derivative works of the API. IMHO, exposing APIs is more useful in many
cases than exposing code.
Mike Greaves
Thomas Bushnell, n/BSG wrote:
>
> Milan Zamazal <p...@informatics.muni.cz> writes:
>
> > Does a non-free program written in Emacs Lisp for Emacs violate GPL?
> Emacs Lisp programs do not have to be distributed under the GPL
> because they are not regarded as being the same program as emacs.
Okay, since you seem to have some confidence of this fact (I had
suspected this but wasn't sure), I'd like to ask some related questions.
Consider cases revolving around source code (for an interpreted
language) compiled to bytecode which is then executed in an
interpreter. The interpreter consists of, and may be embedded in, or
extended with, native machine code. Examples springing immediately to
mind are Guile or Python (maybe with C extensions to the interpreter)
and Java in a JVM. Where are the license violations in the following
examples (please indulge me :-)
1. Programmer A writes an GPLed application in C and embeds a Guile
interpreter in it. Programmer B writes an extension for the application
in Guile, and GPLs it. Programmer C writes a larger framework of
extensions, which calls Prog A's GPLed extension, but keeps his own
source code under lock and key.
My guess is that Prog C has violated Prog B's license, but not Prog A's.
2. Programmer A ports a Python extension, written in C, from Unix to NT
using the GNU-Win32 libraries (GPLed, _not_ LGPLed, if I understand
correctly). So his extension must be GPLed (in any case, let's say it
_is_ GPLed). Programmer B writes a proprietary program in Python which
uses the extended interpreter.
My guess is that Prog A has violated the GPL because the Python
interpreter links with the GPLed extension, and Python can't be under
the GPL. But Prog B hasn't violated the GPL with his proprietary
bytecode. This, if true, is brain-damaged. The free software
components are incompatible with each other, but each is OK with the
proprietary code?
<Wondering Aloud>
With the performance of Java steadily improving, what is the impact to
free software of scenarios like... A nasty, money-grubbing software
house absorbing a ton of GPLed code into a major application. They do
this by writing the application primarily in Java and accessing the
GPLed C code by the JNI (Java Native Interface). Is this a GPL
violation? How is it different from an proprietary Elisp extension -
besides being obviously larger? Hrrrrm.
</Wondering Aloud>
Mike Greaves
mfgr...@shaw.wave.ca
Alan Morgan
In article <6jij4v$i...@lynx02.dac.neu.edu>,
If RMS is a fanatic then you should stay away from RMS.
Judge the GPL on its own merits.
Alan
E. Gkioulekas
Osma Ahvenlampi <oahv...@bounce.mail> writes:
>t...@mit.edu (Thomas Bushnell, n/BSG) writes:
>> Emacs Lisp programs do not have to be distributed under the GPL
>> because they are not regarded as being the same program as emacs.
>> The meaning of "same program" is a human concept, not a programming
>> concept, and the law pays attention to all the facts and details and
>> attentions to figure out.
>This is the main problem with GPL; it says combining GPL and non-GPL
>code in the "same program" is illegal, but leaves the defition of
>"same program" way too open for interpretation.
I believe that what you're noticing is that the copyright law is fucked
and quite inappropriate for software. "Same program" in more general terms
is the "work". The "work" is what copyright rights apply to. In case of
a book, the work is the book. Wouldn't it be weird if a license would
have to explicitly define what the "work" is? Do you see the copyright
notice on a book explain in detail what a book is? ;-)
The GPL was meant to be a legal device that emulates a world without
copyright. You should think of the restriction of not being able to load
a GPL plugin by a proprietory application as a restriction imposed on
you by the proprietory license because _they_ are the ones interfering
with the GPL attempt to emulate the absense of copyright. Equivalently
the case of loading a proprietory plugin by a GPL application.
I think the feeling of anger is warranted, but you're midirecting it
when you say it is a GPL problem. It is primarily a problem with the law
and with proprietory licensing. I am not very certain if a plugin _is_
derived work under the law. It shouldn't be. If it is, then the law sucks.
Elef.
E. Gkioulekas
mkag...@lynx02.dac.neu.edu (Michael Kagalenko) writes:
> RMS is fanatic. Stay away from GPL.
And you're a demagogue. I'd stay away from demagogues _first_ and then
worry about fanatics. Because even a fanatic will not attempt to mislead
you, but a demagogue will.
RMS has opinions that may be rather extreme, but that has more to do with
the fact that he is not near the center of all other opinions. If you were
to define extremism as fanaticism, then Galileo would be a fanatic too.
RMS has shown that he is reasonable in many cases already. For example
he encouraged developers to use the old X license when contributing to XFree86.
He offered to encourage the NPL in exchange for NPL-GPL compatibility.
A true fanatic would hold the line "GPL only, no matter what".
The fine line between being a fanatic and having a certain view is
even finer when that view is more out-of-the-norm than average. Would you say
that Galileo's conviction and insistence that he is right and others are wrong
was also reason to say that he is a fanatic?
At the very least, RMS takes his time to argue in favor of his views.
And Galileo kept telling these assheads to have a look through his
telescope. How about you?
Elef.
Isaac
In article <6jivcp$1i4e$1...@nntp6.u.washington.edu>, E. Gkioulekas wrote:
>I think the feeling of anger is warranted, but you're midirecting it
>when you say it is a GPL problem. It is primarily a problem with the law
>and with proprietory licensing. I am not very certain if a plugin _is_
>derived work under the law. It shouldn't be. If it is, then the law sucks.
>
Such a law would indeed suck. Thankfully there is no evidence that such
law exists. By evidence I don't mean A+B thought experiments, I mean case
law or explicit pointers to unambiguous statements in the copyright law.
At least one person has cited contrary case law concerning video game
cartridges.
I'd say the problem is not GPL or proprietary licensing, but is strictly with
copyright law; if there is a problem. My personal non-lawyerly
understanding of copyright law is that distributing a plug-in for a program
doesn't infringe upon any of the rights that copyright law reserves for the
copyright holder. It's certainly possible to make a plug-in that is derived
from the original program but it's equally possible to generate the plug in
from reading a public specification from a program. It's possible to write
plug-ins for programs that don't even currently exist. I can't see a legal
theory that would outlaw this activity without restricting similar
activities already used to write and execute other GPL'd code.
For example is there really a problem with code or modules designed to
allow running Linux binaries on FreeBSD systems? How about modules
designed to run SCO binaries on Linux? The infringed party would be
who in these cases??
Frankly I don't have any problem with a license that prevents me from
taking someone else's code and using it in ways they don't intend. I do
have a problem with the particular argument. Weren't some of us already
outraged by attempts by software publishers to restrict our ability
to write code that interacted with their programs via Article 2B to the UCC.
Why should I feel differently about writing and distributing code to
interoperate with GPL'd programs (whether we have their source or not).
Isaac
Christopher Eltschka
Richard Stallman wrote:
>
> People have been talking about how the GNU GPL applies to plug-ins;
> specifically, plug-ins that are implemented by dynamic linking into a
> master program.
>
> The key to answering this is to realize that there is no legal
> is therefore an extension to the master program; the two become part
> out the consequences of the GPL: using GPL-covered code in the larger
> combined program is permitted only if the combined program as a whole
> is free under the GPL.
>
> clearly; here is how I responded.
>
> plugin files. They do not use any GPL code to create Program A. They
> distribute Program A as commercial software.
>
> Has Party One violated the GPL?
>
> Party One is not violating the terms of any GPL-covered program, because
> they are not using one. So they are not violating the GNU GPL.
>
> by Program A. Plugin B uses modified GPL code. Party Two distributes Plugin
> B binaries and source code under the terms of the GNU GPL.
>
> modification for Program A. Since they cannot distribute the whole of
> the modified Program A under the GPL, they cannot comply with it.
> Therefore they will have to stop distributing this plug-in.
>
> Party One have to release source code for Program A? No; Party One
> doesn't have to do anything different, because Program A and Party One
> are not responsible for the problem. Only Party Two is responsible.
> They will have to stop distributing Plugin B, since they can't do it
> in accord with the GPL.
>
> plug-in would violate the GNU GPL, just like non-free modifications to
> the master program made in other ways.
>
> require anyone to release source code for his own modules if he does
> not want to. What it requires is *not to combine those modules* with
> GPL-covered code in a larger program.
>
> to clarify this in the "development version" now.
But assume that one writes a plugin for a non-GPLed program, say, for
Netscape. According to what you say, this would not be allowed to be
GPLed.
Now imagine someone else writes a browser, which allows to load
Netscape plugins. Again, if I understand you correctly, this would
not be allowed.
Now imagine at some time they two meet and decide to work together.
Suddenly both components may be released under GPL, by simply
stating that the GPLed browser has an interface to load the GPLed
plugin, and the GPLed plugin is to be loaded by the GPLed browser.
In addition, from this moment on, every other Netscape Plugin can
be released by the respective author under GPL, by simply stating
it as a plugin for the GPLed browser.
Note that the situation changed completely without modifying *one*
bit of code. Also note that individual users are now allowed to load
Netscape plugins into the GPLed browser and GPLed plugins into
Netscape, since they don't distribute the work they produced this
way.
Christopher Eltschka
Roland Bergler wrote:
>
> r...@santafe.edu (Richard Stallman) writes:
>
> > People have been talking about how the GNU GPL applies to plug-ins;
> > specifically, plug-ins that are implemented by dynamic linking into a
> > master program.
> >
> > The key to answering this is to realize that there is no legal
> > distinction between dynamic linking and static linking.
>
> invocation via exec? If I wrote a tool designed to be called via
> shell escape from a hypotetical non-GPLed emacs-clone useing
> shell-command-on-region, wouldnt that mean you could not use any GPLed
> code in this tool? The GNU fileutils could not be published unter the
> GPL.
That raises an interesting question:
What if I took a GPLed library, and made a GPLed program which doesn't
do anything else but provide access to the library? For example, if
the library contained the function int f(int), the program would accept
the command "f(25)" on stdin, parse it, make a call to f with argument
25, and write the result to stdout. Now another program could start
this program, redirect it's input and output to named pipes, and then
instead of calling i=f(25), it would do something like
fprintf(lib_call_pipe, "f(%i)", 25);
fscanf(lib_return_pipe," %i", &i);
Would this make the second program make a derived work?
Leslie Mikesell
In article <355d518f....@news.vnet.net>,
le Fantôme <fantome/@/usa/./net> wrote:
>>> Coming at this from a Linux perspective, this seems to rule out GPL'ed
>>> Motif applications, since Linux doesn't ship with Motif (and Motif is
>>> not GPL'ed).
>>>
>>> Is that true, or have I misunderstood.
>>
>>I doubt if it's true, since GNU Emacs itself has a configuration
>>option to link with Motif.
>
>This option comes from unixes where Motif *is* distributed normally as
>a system library.
Most commercial unix versions included it as a matter of course since
it did not make a large difference in the price they had to charge
for the package. It is a different story for the free unix versions.
But this case makes it clear how arbitrary and silly it is to allow
some commercial products to be considered standard system components
and others not.
Les Mikesell
l...@mcs.com
Leslie Mikesell
In article <6jgsra$4ds$1...@nnrp1.dejanews.com>, <mcg...@indirect.com> wrote:
>In article <wksomdx...@generation.net>,
>> From the GPL:
>> > However, as a special exception, the source code distributed need not
>> > include anything that is normally distributed (in either source or
>> > binary form) with the major components (compiler, kernel, and so on)
>> > of the operating system on which the executable runs, unless that
>> > component itself accompanies the executable.
>
>This exception seems kind of vague to me. Would Internet Explorer be
>considered a "major component" of Windows 98 as Microsoft wants to
>release it? If so, then can't I create a version of emacs that runs
>only as some kind of Internet Explorer-specific plug-in and legally
>distribute it under the GPL? This seems to be a perfect example of
>what RMS's interpretation is trying to avoid, yet I can't see how it
>would be disallowed.
Yes, that would be funny if it turns out that GPL-d IE plugins are
OK since they only work with system components, where GPL-d plugins
for source-available Netscape are disallowed.
Les Mikesell
l...@mcs.com
Tim Smith
Alan Morgan <amo...@Xenon.Stanford.EDU> wrote:
>If RMS is a fanatic then you should stay away from RMS.
>Judge the GPL on its own merits.
That's not always possible, because
1. Many people consider the "spirit" of GPL as important as the legal
menaing, and look to RMS to define what that spirit is, and
2. Many people seem to think that RMS (and the FSF) have some special
status when it comes to legal interpretation of GPL.
What this means is that if you use GPL'ed code in a way that is
perfectly legal, but RMS disagrees with you, the resulting ill-will you
will get from a large number of people may be worth more than whatever
benefit you are getting from using the GPL'ed code.
--Tim Smith
Ben Bullock
Tim Smith wrote:
> 2. Many people seem to think that RMS (and the FSF) have some special
> status when it comes to legal interpretation of GPL.
As far as I can understand the law, if you write a contract
then supposing it isn't clear legally what it means, then
the intention of the people who made the contract would be
one of the important things to consider in a dispute.
I would have thought that RMS and the FSF do have a special status
when it comes to legal interpretation of the GNU GPL.
--
Ben Bullock
Try Cfunctions, a free program for making headers from C files.
Get it from `http://www.hayamasa.demon.co.uk/cfunctions'.
Tim Smith
Ben Bullock <b...@hayamasa.demon.co.uk> wrote:
>> 2. Many people seem to think that RMS (and the FSF) have some special
>> status when it comes to legal interpretation of GPL.
>
>As far as I can understand the law, if you write a contract
>then supposing it isn't clear legally what it means, then
>the intention of the people who made the contract would be
>one of the important things to consider in a dispute.
>
>I would have thought that RMS and the FSF do have a special status
>when it comes to legal interpretation of the GNU GPL.
For GPL'ed code that is not from RMS/FSF, then RMS/FSF has no special
status, because he/they are not one of the parties to the contract.
If RMS/FSF code is involved, then he/they is/are a party to the
contract, and so his/their intent is important, but no more so than that
of the other party.
--Tim Smith
har...@omsi.com
In article <6jnema$4ku$1...@halcyon.com>,
Most (all?) GPL users grant FSF a special right when they use the GPL.
Specifically, they allow the users of their software to, at their option,
adhere to version 2 or "any later version published by the FSF," of
the GPL.
Hence, the FSF's interpretation and stand on the GPL counts a lot
since the FSF may put in the GPLv3 explicitly what it believes to
be a consequence of GPLv2.
Harman.
har...@omsi.com
David Kastrup
mkag...@lynx02.dac.neu.edu (Michael Kagalenko) writes:
> RMS is fanatic. Stay away from GPL.
However, RMS' interpretation of the GPL with regard to plugins is more
than shaky.
Unfortunately, if you don't want to haggle in the courts with him
(even though he is likely to lose), you better not use any software or
library under the GPL and licensed by the FSF (of which there is a lot
around) in order to build a plugin you want to release under the GPL.
Of course, as long as you own the copyright to all of the code in the
plugin you want to release GPLed, it is you who is to decide what to
consider a breach of the license worth sueing.
--
David Kastrup Phone: +49-234-700-5570
Email: d...@neuroinformatik.ruhr-uni-bochum.de Fax: +49-234-709-4209
Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany
Ben Bullock
Tim Smith wrote:
> For GPL'ed code that is not from RMS/FSF, then RMS/FSF has no special
> status, because he/they are not one of the parties to the contract.
>
> If RMS/FSF code is involved, then he/they is/are a party to the
> contract, and so his/their intent is important, but no more so than that
> of the other party.
One reason that what you are saying seems unlikely is that the legal
interpretation of the GNU GPL in a court would affect all software
that is under the GNU GPL. For example, if a court made a decision
about the legal interpretation of it, then any lower court would be
bound by that precedent in any other case which involved the GNU GPL.
For example it would affect software which was copyright owned by the
FSF. So it seems unlikely to me that the intention of the
author of the contract is irrelevant even in third-party cases.
Tim Smith
Ben Bullock <b...@hayamasa.demon.co.uk> wrote:
>> For GPL'ed code that is not from RMS/FSF, then RMS/FSF has no special
>> status, because he/they are not one of the parties to the contract.
>>
>> If RMS/FSF code is involved, then he/they is/are a party to the
>> contract, and so his/their intent is important, but no more so than that
>> of the other party.
>
>One reason that what you are saying seems unlikely is that the legal
>interpretation of the GNU GPL in a court would affect all software
>that is under the GNU GPL.
It would not *legally* affect all software under GPL. A court decision
by a district court would only affect legally the parties involved. If
there is an appeal to a higher court, that would only affect the matters
of law in the case, not the matters of fact. The intent of the parties
is a matter of fact, not a matter of law.
Here's another way to think of this. What determines the contract
between two parties is the intent of the parties at the time the
contract was formed. Unless RMS/FSF has developed remarkable psychic
ability, I don't see how he/they have any special power to say what that
intent was.
--Tim Smith
Isaac
In article <3560744D...@hayamasa.demon.co.uk>, Ben Bullock wrote:
>One reason that what you are saying seems unlikely is that the legal
>interpretation of the GNU GPL in a court would affect all software
>about the legal interpretation of it, then any lower court would be
>bound by that precedent in any other case which involved the GNU GPL.
>
I don't think you can assume that a ruling would be so universal. A ruling
on the GPL could be based on the wording of the license, on copyright law or
even explicit public statements by RMS concerning the GPL's intent if FSF
controlled code was involved. A ruling might also be issued which hinges on
some details concerning the particular software and the intentions of the
plaintif involved. Maybe all GPL'd software would be affected and maybe
not. A broad decision prevent writing any software interoperable with
a given program without permission while a narrow decision might just
outlaw a specific plug-in to gcc.
Isaac
Ben Bullock
Tim Smith wrote:
> It would not *legally* affect all software under GPL.
In the UK certainly it would, for the reason I explained in my message
but which disappeared from your quoted material. If the situation
regarding precedence is different in the US, then I'll stand
corrected, but you (as usual) seem loathe to post evidence for
your assertions.
> Here's another way to think of this. What determines the contract
> between two parties is the intent of the parties at the time the
> contract was formed.
That's of course nonsense.
Isaac
In article <3561D7E4...@hayamasa.demon.co.uk>, Ben Bullock wrote:
>In the UK certainly it would, for the reason I explained in my message
>but which disappeared from your quoted material. If the situation
>regarding precedence is different in the US, then I'll stand
>corrected, but you (as usual) seem loathe to post evidence for
>your assertions.
>
US court system would challenge Tim's statement about precedence in
district courts. Is it really the case in the UK that a ruling in
a lower court becomes binding in every jurisdiction?
>> Here's another way to think of this. What determines the contract
>> between two parties is the intent of the parties at the time the
>> contract was formed.
>
>That's of course nonsense.
>
I think Tim's point is that if you and I complete a contract where we
mutually agree on the interpretation, a third uninterested party's
interpretation is not relevant even if that party used similar (identical)
wording in his own dealings. This seems perfectly logical to me.
You may disagree of course but that does not make Tim's statement nonsense.
Isaac
Steve Peltz
In article <u1hg1ib...@pusey.MIT.EDU>,
Thomas Bushnell, n/BSG <t...@mit.edu> wrote:
>Now, it is the case that the commercial people who sell shared
>library systems make it very clear that programs which link against
>those shared libraries are every bit as much derivative works as
>programs which link against static equivalents.
Not that I've ever seen. They may or may not allow you to ship those
shared libraries with your program, and add restrictions that those
libraries are only licensed to be use with YOUR program, but I've never
seen anyone try to restrict the distribution of the raw program itself,
with the user being required to obtain the library separately.
Examples:
Sending out a program on a DOS diskette, explicitly not putting
system files on it, but leaving space for the user to do so with their
already-licensed copy of DOS. Same thing with MacOS - if you wanted
a bootable diskette, you had to license it (and the end-user license
agreement always stated that you could use the Apple-licensed software
only with your program). However, you could distribute your programs on
a non-bootable diskette with no problems.
Distributing TCP-aware programs with MacTCP included (before TCP was
included as part of the MacOS distribution). You could only do so if you
had a license from Apple; but that didn't prevent you from distributing
your program with the assumption that the end user already had TCP
installed.
Remember the video game cartridge copyright case a while ago, where
the console manufacturer wanted royalties from anyone who made a game
compatible with their console? They tried to do it by checking that
the game cartridge contained something like "Copyright XXXXXXX" in
a specified location in the ROM; and thus any game that worked was a
copyright violation. I believe that failed, and in any case, can't see
that the FSF would think it should work.
Was every program written for the Apple II a derivative work of the ROM
(since essentially every program called ROM routines directly).
I just don't understand the FSF position on this. On the one hand,
they're objecting to increased copyright protection measures (database
protection, millenium digital copyright bill, shrinkwrap provisions);
yet are endorsing a position where if I write a plug-in for Photoshop,
entirely my own code, using only published interface information, not
linked with anything I didn't write, Adobe could demand royalties from
me if I distribute it?
Steve Peltz
In article <xnbtszk...@delorie.com>, DJ Delorie <d...@delorie.com> wrote:
>What RMS intended is that the *source* be free from the desires of the
>people using it, not the other way around. The *source* has the
>freedoms; the *users* are very restricted in what they can do with it.
>
>The purpose of the GPL is to protect the sources, not the people.
Well, RMS also thought that a set of source patches to non-GPLed freely
distributable sources were a violation of the GPL merely because those
patches modified the program (which linked with a non-free library) to
allow it to be built and linked to a GPLed (not LGPLed) library. The
SOURCE as it was normally distributed wasn't even patched, it was a
configuration option when building the program, and in that default
state, the resulting binary wouldn't be a GPL derivative in any sense.
Choosing the non-default configuration option to link with the GPLed
library would result in a binary that couldn't be distributed, but I
always thought the GPL allowed you to USE the code however you wanted,
as long as you didn't distribute anything that was in violation.
And, of course, RMS dropped his objections as soon as a public-domain
hacked together very non-optimal equivalent library was created (for
this specific purpose). That is an addled way of going about things.
My apologies if the public-domain version had more work put into it
than I represent - the point is, I'm not even sure the library would
have had to even work correctly!
Thomas Bushnell, n/BSG
t...@halcyon.com (Tim Smith) writes:
> Here's another way to think of this. What determines the contract
> between two parties is the intent of the parties at the time the
> contract was formed. Unless RMS/FSF has developed remarkable psychic
> ability, I don't see how he/they have any special power to say what that
> intent was.
Be careful, though.
1) By the parol evidence rule, the primary thing determining the
contract is the written words, not the intention. If the words are
clear, but don't match the intention, then the words rule. The
intention only gets into it if the court decides the words are
unclear.
2) A license is not a contract, and not all the same rules will
apply. Because a license (like the GPL) can be a non-negotiated
grant, there may be differences...
Craig Milo Rogers
In article <1998051407...@wijiji.santafe.edu>,
Richard Stallman <r...@gnu.org> wrote:
>People have been talking about how the GNU GPL applies to plug-ins;
>specifically, plug-ins that are implemented by dynamic linking into a
>master program.
>
>The key to answering this is to realize that there is no legal
>distinction between dynamic linking and static linking.
This is an interesting statement. In my experience, one of
the crucial distinctions between static linking and dynamic linking of
software systems is temporal: static linking usually takes place
before distribution to the end user, while dynamic linking usually
takes place after distribution per se.
The GNU GPL uses "distribution" as a key test in determining
whether or not certain clauses, such as those requiring source code
availablilty, apply to a particular modification of GNU GPL'ed code.
Thus, there would appear to be a pertinant legal distinction between
static and dynamic linking.
Thus, the statement appears to be false upon examination.
>The plug-in is therefore an extension to the master program; the two
>become part of a larger combined program. On this basis, you can easily
>figure out the consequences of the GPL: using GPL-covered code in the larger
>combined program is permitted only if the combined program as a whole
>is free under the GPL.
It would be gratifying to state that the rest of the argument
appears to be irrelevant, due to its reliance upon a false premise.
However, that actual failure is that the offered artument fails to
apply proper temporal reasoning, and confuses the "pre-distribution"
and "post-distribution" distinction when it makes claimes about
combined entities.
In particular, the second sentence quoted immediately above is
false in two particulars. First, it uses the verb "to use", which is
quite broad and open to misinterpretation. Generally speaking,
computer programmers consider one portion of code to "use" another
when a temporal relationship is established between the two via a
mechanism such as a subroutine call, as well as when a textual
relationship is created via, say, "#include". However, only the
second interpretation (textual incorporation or the "translation"
thereof) has a clear-cut meaning under Copyright Law, so far as I,
a layman, can determine by perusing the Copyright law resources
that are readily available to me.
Secondly, the GNU GPL version 2 simply doesn't prohibit the
creation or use of so-called non-free combined programs incorporating
GPL-covered code. Instead, it prohibits the *distribution* of such
non-free combined works. Thus, logically, such works may be created
and used, so long as they are not distributed.
>I was recently sent a hypothetical scenario which was stated very
>clearly; here is how I responded.
>
> Party One produces Program A which can load object code from separate
> plugin files. They do not use any GPL code to create Program A. They
> distribute Program A as commercial software.
>
> Has Party One violated the GPL?
>
>Party One is not violating the terms of any GPL-covered program, because
>they are not using one. So they are not violating the GNU GPL.
>
> After the release of Program A, Party Two produces Plugin B, to be loaded
> by Program A. Plugin B uses modified GPL code. Party Two distributes Plugin
> B binaries and source code under the terms of the GNU GPL.
>
>Party Two has violated the GNU GPL by converting the GPL-covered code into a
>modification for Program A. Since they cannot distribute the whole of
>the modified Program A under the GPL, they cannot comply with it.
I do not see any support in the GNU GPL Version 2 for such a
statement. Plugin B is not derived, by textual modification or
translation, from Program A. Therefore, although it may be a
modification *for* Program A, it is not a modification *of* Program A.
Until an act of dynamic linking takes place, it has not modified any
GPL'ed code. Since it is not a modification *of* Program A, there is
no relationship between Program A and Plugin B that is pertinent to
Copyright Law, and thus the GPL.
Again, the crucial distinction to observe is that instances of
the "combined program" are the only entities that incorporate both
GPL'ed and non-free antecedents, and Party Two is not distributing any
instances of the "combined program". Therefore, the terms of the GPL
are not violated by the distribution of Plugin B.
>Therefore they will have to stop distributing this plug-in.
Unsupported by the logic of the case.
It is also worth noting that there is no automatic reason why
Party Two would have to stop distributing Plugin B, even if Plugin B's
distribution did infringe upon GPL-licensed code. If Party One is the
sole copyright holder for Program A, could they not grant Party Two a
separate license to distribute Plugin B if they chose to do so?
It is certainly emotionally satisfying to make statements such
as, "They will have to stop ...", and this is certainly an
often-applied and effective technique in public debate. It can, for
instance, win an election, or force passage of a bill, independent of
any logical basis for the statement. I would hope, however, that the
issues at hand in this forum could be decided on the basis of
rationality, rather than emotional appeal.
>So what are the consequences? If Party Two makes such a plug-in, does
>Party One have to release source code for Program A? No; Party One
>doesn't have to do anything different, because Program A and Party One
>are not responsible for the problem. Only Party Two is responsible.
>They will have to stop distributing Plugin B, since they can't do it
>in accord with the GPL.
False, since it appears that Party Two would actually be complying
with the terms of the GPL as stated in the GNU GPL Version 2.
>Conversely, if the master program is GPL-covered, then a non-free
>plug-in would violate the GNU GPL, just like non-free modifications to
>the master program made in other ways.
Again, a false statement, which ignores the temporal aspects
of the situation. Only distribution of instances of the "combined
program" are prohibited by the GPL. Since the putative non-free
plugin does not modify any GPL'ed code until it is actually linked
against such code, the GPL does not apply to the pre-linkage copies.
>I should point out that, strictly speaking, the GNU GPL can never
>require anyone to release source code for his own modules if he does
>not want to. What it requires is *not to combine those modules* with
>GPL-covered code in a larger program.
This is a false statement on its face, and is easily refuted.
The GNU GPL, as of Version 2, makes no such requirement. What the GNU
GPL Version 2 actually says is that it allows the combination (section
2, first sentence), but prohibits further distribution (section 2b).
Thus, so long as you do not "distribute or publish" (in the exact
words of section 2b) the combined work, your modification is permitted
under the GNU GPL. QED.
It may have been the intent of the author of the GPL to
prevent combination per-se; if so, I believe that the GNU GPL Version
2 is a faulty expression of that intent, and should be revised at the
earliest opportunity.
>I don't know when there will be a version 3 of the GPL, but I am going
>to clarify this in the "development version" now.
I welcome an opportunity and forum to examine and discuss
proposed new versions of the GPL. For instance, I hold Netscape in
high regard for their exemplary behaviour in fostering free and open
discussion of their software license proposals. I would find it
personally gratifying if the authors of the GNU GPL were to meet or
exceed that standard of freedom and openness.
As usual, I append my disclaimer: I am not a lawyer, and this
message does not constitute an offer of legal advice.
Craig Milo Rogers
Isaac
In article <6jt43m$7dl$1...@jaka.ece.uiuc.edu>, Steve Peltz wrote:
>I just don't understand the FSF position on this. On the one hand,
I think the FSF's position is easy to understand even if it's more
difficult to support. If they cannot control the use of GPL'd code
as plug-ins or limit the use of plug-ins with GPL'd programs, then
the protection against making proprietary use of their code without
releasing source disappears. Using Stallman's example, if I can add
a proprietary optimization pass to gcc without releasing the source for
my changes, then the GPL's encouragement to release source has been
circumvented. The FSF has an obligation to everyone who's contributed
code believing it wouldn't be so usurped.
I think there is a fundamental difference between the plug-in described
above for gcc and a plug-in to add a new graphic transformation for Gimp.
The gcc plug-in seems to usurp the copyright holders code while the
gimp plug in seems to simply add new functionality. But I can't see a clear
way to outlaw one without the other. I'm not sure you can really outlaw
either.
>they're objecting to increased copyright protection measures (database
>protection, millenium digital copyright bill, shrinkwrap provisions);
>yet are endorsing a position where if I write a plug-in for Photoshop,
>entirely my own code, using only published interface information, not
>linked with anything I didn't write, Adobe could demand royalties from
>me if I distribute it?
I don't like this implication one bit. I can't imagine that the FSF
likes it either.
Isaac
David Kastrup
t...@halcyon.com (Tim Smith) writes:
> Alan Morgan <amo...@Xenon.Stanford.EDU> wrote:
> >If RMS is a fanatic then you should stay away from RMS.
> >Judge the GPL on its own merits.
>
> That's not always possible, because
>
> 1. Many people consider the "spirit" of GPL as important as the legal
> menaing, and look to RMS to define what that spirit is, and
Not necessarily. A lot of them define the spirit themselves and call
people making money off free software thieves and other nice names,
when the GPL has been explicitly designed to allow those sort of
things.
> 2. Many people seem to think that RMS (and the FSF) have some special
> status when it comes to legal interpretation of GPL.
They have. RMS is chief GNUisance of the FSF, and the FSF holds
enforceable rights to by far the largest corpus of GPLed software
around. You cannot derive GPLed works from this corpus without danger
of getting sued if your interpretation of the GPL is going to conflict
with theirs.
--
David Kastrup Phone: +49-234-700-5570
Email: d...@neuroinformatik.ruhr-uni-bochum.de Fax: +49-234-709-4209
Institut f◯r Neuroinformatik, Universit∽tsstr. 150, 44780 Bochum, Germany
Steve Peltz
In article <6jhgvb$vbu$1...@nnrp1.dejanews.com>, <dg...@chrysler.com> wrote:
>If this doesn't hold, if GPL-ed plugins for non-GPLed programs cannot be
>distributed, then no programs can be released under the GPL for non-free
>operating systems. Any program written for Windows, MacOS, AmigaDOS, most
>UNIXen, etc. cannot be released under the GPL using this argument.
Although I agree with your viewpoint, the GPL does make an exception for
components of an operating system.
Steve Peltz
In article <6jpn0r$g5f$1...@nnrp1.dejanews.com>, <har...@omsi.com> wrote:
>Most (all?) GPL users grant FSF a special right when they use the GPL.
>Specifically, they allow the users of their software to, at their option,
>adhere to version 2 or "any later version published by the FSF," of
>the GPL.
That really only gives the FSF the ability to make additional exceptions
- if they make a later version that restricts additional things, then
naturally anyone who wants to do one of those things will not choose to
use "any later version". If I've made software available under the GPL
because I thought the GPL meant certain things, certainly MY understanding
of it is just as important as the FSF's, with regard to MY code. If I've
modified GPL code, and released my modifications, the intent of everyone
involved becomes an issue.
Peter Mutsaers
>> On 14 May 98 10:01:06 GMT, borc...@turing.mathematik.uni-ulm.de
>> (Andreas Borchert) said:
AB> On Thu, 14 May 1998 01:23:16 -0600, Richard Stallman
AB> <r...@santafe.edu> wrote:
>> After the release of Program A, Party Two produces Plugin B, to
>> be loaded by Program A. Plugin B uses modified GPL code. Party
>> Two distributes Plugin B binaries and source code under the
>> terms of the GNU GPL.
AB> Consider the case that Plugin B cannot only be loaded by
AB> Program A but also by the GPLed Program C. The author of
AB> Plugin B could even be not aware of the existence of Program
AB> A.
AB> The key point seems to be whether a plug-in was specifically
AB> designed to work exclusively with a given program or not. If a
AB> common interface for loading is used, however, none of the
AB> authoring parties can be held responsible for the aggregation
AB> of GPLed software components with proprietary software.
Hmm, then if I were BeOS (their driver gave rise to this statement
from mr. Stallman) then I would create a second (toy) kernel which has
the same linking interface as the real one, release that one under
GPL. Then they use any GPLed code for the 2nd kernel, which happens to
be also usable for the real one.
Things like this to me show the absurdity of the (L)GPL. I do wonder
how it really would stand in court.
Isaac
In article <m2ra1pt...@mailhost.neuroinformatik.ruhr-uni-bochum.de>,
David Kastrup wrote:
>...and the FSF holds
>enforceable rights to by far the largest corpus of GPLed software
>around. You cannot derive GPLed works from this corpus without danger
>of getting sued if your interpretation of the GPL is going to conflict
>with theirs.
>
You're right here of course. I don't think many people object to the
FSF's interpretation of the GPL; it's their interpretation of copyright
law that rankles. If they are right, you better check with Netscape
before you write and distribute any public domain plug-ins because
if the work A+B is derivative, you need permission form A and B to
write a plug-in.
The ability to write code that interoperate other software is an
important one that I don't want to give up. The FSF may disagree
with me on whether that right is more important than protection of
GPL'd code. I'd like to see a way to preserve both, but I haven't
heard one yet.
Isaac
Leslie Mikesell
In article <L53a1.31$5K2.7...@cam-news-reader1.bbnplanet.com>,
Barry Margolin <bar...@bbnplanet.com> wrote:
>In article <6jt58i$iu6$1...@democracy.isi.edu>,
>Craig Milo Rogers <rog...@democracy.isi.edu> wrote:
>>In article <1998051407...@wijiji.santafe.edu>,
>>Richard Stallman <r...@gnu.org> wrote:
>>>The key to answering this is to realize that there is no legal
>>>distinction between dynamic linking and static linking.
>>
>> This is an interesting statement. In my experience, one of
>>the crucial distinctions between static linking and dynamic linking of
>>software systems is temporal: static linking usually takes place
>>before distribution to the end user, while dynamic linking usually
>>takes place after distribution per se.
>
>two types of licensing is a loophole that the copyright law never intended
>to allow, perhaps because it was written before it was possible to
>distribute active elements that would do the deriving on behalf of the
>distributor. Thus, distributing B and scriptC, where scriptC merges A and
>B to produce C, should only be allowed in cases where it would be allowable
>to distribute C. If this is not true, copyright laws regarding derived
>works may be rendered meaningless in the digital world, since they could be
>worked around by distributing only the differences and a script, rather
>than distributing a derived work.
Not at all. Copyright laws aren't made meaningless because the derived
work is created *after* all copyright restrictions have been met regarding
A and B. The copyrights on A and B should have no control over the
separate distribution of scriptC, created and owned by someone else,
and the copyrights on A and B can't control the use of a product, only
subsequent copying.
If I understand the theory of the GPL correctly, it is the license
that allows the code to be copied while the copyright prohibits it
unless you agree to the license. At least in the US you can't be
bound by licenses unless you agree to them so it can't really
restrict your use of a copy after getting it unless agreement was
a condition of obtaining the copy and established beforehand.
However, since copying is restricted, you are only allowed to
redistribute it if you agree to the license terms.
The workaround seems simple enough: if you want to distribute scriptC
just don't ever redistribute any GPL'd code - let someone else
do that. If you don't copy any copyrighted code you don't have
to agree to the license terms. Have I missed something here?
Les Mikesell
l...@mcs.com
Barry Margolin
>Richard Stallman <r...@gnu.org> wrote:
>>The key to answering this is to realize that there is no legal
>>distinction between dynamic linking and static linking.
>
> This is an interesting statement. In my experience, one of
>the crucial distinctions between static linking and dynamic linking of
>software systems is temporal: static linking usually takes place
>before distribution to the end user, while dynamic linking usually
>takes place after distribution per se.
I believe Stallman's reasoning is that the temporal distinction between the
two types of licensing is a loophole that the copyright law never intended
to allow, perhaps because it was written before it was possible to
distribute active elements that would do the deriving on behalf of the
distributor. Thus, distributing B and scriptC, where scriptC merges A and
B to produce C, should only be allowed in cases where it would be allowable
to distribute C. If this is not true, copyright laws regarding derived
works may be rendered meaningless in the digital world, since they could be
worked around by distributing only the differences and a script, rather
than distributing a derived work.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
jo...@dhh.gt.org
Barry Margolin writes:
> Thus, distributing B and scriptC, where scriptC merges A and B to produce
> C, should only be allowed in cases where it would be allowable to
> distribute C. If this is not true, copyright laws regarding derived
> works may be rendered meaningless in the digital world, since they could
> be worked around by distributing only the differences and a script,
> rather than distributing a derived work.
Can you produce some evidence that this is true? I can certainly
distribute pages to paste into your book (or, as I noted earlier, words to
be sung to your music) without your permission. What makes you think I
can't distribute code to be pasted into your program?
Investigate the history of binary patches. I believe that you will find
that they are quite legal.
IMHO, the "digital world" is heading in the direction of making all
copyright law meaningless.
--
John Hasler This posting is in the public domain.
jo...@dhh.gt.org Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.
Andreas Borchert
Indeed. To my understanding of the GPL this would be perfectly OK
but please note that I am not a lawyer and just try to interpret it
technically.
> Things like this to me show the absurdity of the (L)GPL.
Well, LGPL works fine and was not subject of this discussion. In fact,
in case of LGPL you do not need to argue about what constitutes
an operating system, execution environments and general interfaces
because LGPL code may be freely combined with any kind of other code,
provided you keep the freedom to reassemble modified components of
the LGPLed code with non-LGPLed parts (and make sources available etc
as familiar with GPL).
IMHO, we have just a problem with the GPL because the terms used
became more ambigious through the times. At least I had a problem
with it after having read the new comments about plug-ins by RMS.
Therefore I would recommend to prefer the LGPL to the GPL for
new software (be it libraries, plug-ins, drivers or whatever) or
to re-license old software from GPL to LGPL, if possible. This
would remove a lot of open questions in the context of the GPL
(that many people obviously have in this and other threads).
> I do wonder
> how it really would stand in court.
This is always surprising but I think LGPL and for a long time GPL
worked pretty well without considering lawyers and law suits. They
are readable and at least the intentions seem (or seemed in case
of the GPL) to be clear.
Andreas.
--
Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm, Germany
E-Mail: borc...@mathematik.uni-ulm.de
WWW: http://www.mathematik.uni-ulm.de/sai/borchert/
PGP key available via ``finger borc...@laborix.mathematik.uni-ulm.de''
Isaac
In article <L53a1.31$5K2.7...@cam-news-reader1.bbnplanet.com>,
Barry Margolin wrote:
>distributor. Thus, distributing B and scriptC, where scriptC merges A and
>B to produce C, should only be allowed in cases where it would be allowable
>to distribute C. If this is not true, copyright laws regarding derived
>works may be rendered meaningless in the digital world, since they could be
>worked around by distributing only the differences and a script, rather
>than distributing a derived work.
>
Is there really anything particularly digital about this? I see the
claim Stallman makes as analgous to saying that if I write down
some lines of verse and accompany them with "sung to the tune of"
some melody you've written, I need your permission. Similarly I
can't issue an index or concordance to some work you've written
without your permission.
I don't buy the argument that there is anything new about this situation
that only arose because of dynamic linking, plug-in, digital technology.
The problem is somewhat unique to freed code because there is no intent
to restrict the user's (meaning the person running the code) rights,
and because the source code is so available that it's feasible to expect
the user to get it him/herself. Also the compiling and linking operations
we speak of are generally not available to the casual user, but we
expect that the user's of GPL'd code can manage it. No one distributes
Windows code thinking that their audience will have Visual C++ available.
Extending the scriptC argument to the extreme, if it's possible to just
tell someone who to export symbols from a GPL'd work so that a proprietary
piece of code will plug-in to it, I guess the person doing the telling
would be guilty of something or other. I sure wish I knew what though.
Isaac
Craig Milo Rogers
In article <L53a1.31$5K2.7...@cam-news-reader1.bbnplanet.com>,
Barry Margolin <bar...@bbnplanet.com> wrote:
>In article <6jt58i$iu6$1...@democracy.isi.edu>,
>Craig Milo Rogers <rog...@democracy.isi.edu> wrote:
>>Richard Stallman <r...@gnu.org> wrote:
>>>The key to answering this is to realize that there is no legal
>>>distinction between dynamic linking and static linking.
>>
>> This is an interesting statement. In my experience, one of
>>the crucial distinctions between static linking and dynamic linking of
>>software systems is temporal: static linking usually takes place
>>before distribution to the end user, while dynamic linking usually
>>takes place after distribution per se.
>
>two types of licensing is a loophole that the copyright law never intended
>to allow, perhaps because it was written before it was possible to
>distribute active elements that would do the deriving on behalf of the
>B to produce C, should only be allowed in cases where it would be allowable
>to distribute C. If this is not true, copyright laws regarding derived
>works may be rendered meaningless in the digital world, since they could be
>worked around by distributing only the differences and a script, rather
>than distributing a derived work.
[Usual disclaimer: I am not a lawyer, this message is not an
offer of legal advice.]
First, a midly inflammatory, unsubstantiated comment: of all
the innovations we are discussing, surely the GNU GPL itself is the
most extreme example of something that copyright law was not
intentionally written to support.
"Differences" pose a problem. A difference file is textually
derived from two sources (a GPL'ed and an non-GPL-compliant source, in
the situation under discussion). I think a pretty good case can be
made that such a file *is* derived from both its antecedants in the
Copyright sense.
However, this doesn't apply to plug-ins. Idealized plug-ins
have the happy property that the only thing shared between program A
and plug-in B is a public interface. Let us assume, please, that the
public interface is in the public domain, or is otherwise licensed
compatibly with the GPL. ScriptC, which merges A and B, need only
reference A and B by name, which almost certainly deson't infringe on
the copyright of either A or B (trademarks, maybe, but almost
certainly not copyright). So, this is a very different situation than
dealing with a script of differences.
Analogies are misleading. Analogies can lie. Having said
that, I'd like to use an analogy. Suppose there were a grocer,
George, who purchased a large batch of flour, which came with
particular license: "Any bread produced from this flour must be eaten
or given away for free; it may not be sold".
George the Grocer did some experimentation in his kitchen, and
came up with a recipe that produced really outstanding loaves of bread
with the new flour. So, George had bags printed up with the recipe on
them (and the flour's license, too), bagged the flour, and sold the
bagged flour in George's Grocery Store. Everyone who bought the
bagged flour baked and enjoyed delicious loaves of bread in the
privacy of their own homes; not a slice went unconsumed!
Did George the Grocer sell bread? Did he even "distribute"
bread? Did anyone violate the license attached to the flour? I don't
think so. George sold/distributed flour and certain specific
knowledge, a recipe for converting flour into bread. The bread,
itself, was fresh each time a loaf was baked.
If I wanted to extend this analogy, and defend against
anticipated atacks, I could claim that the recipe had the unbelievable
(even with a home bread machine) property that if you followed it
correctly, all the loaves of bread would be identical and
indistinguishable from each other. I won't make that claim, however,
at the present time. ;-)
By analogy, the user-does-the-link strategy (as outlined in
previous messages) fully complies with the provisions of the GNU GPL
Version 2, because each instance of the combined work is a fresh copy,
and is not further published or distributed.
Craig Milo Rogers
Lyno Sullivan
r...@santafe.edu (Richard Stallman) wrote:
>The key to answering this is to realize that there is no legal
>distinction between dynamic linking and static linking. The plug-in
>is therefore an extension to the master program; the two become part
>of a larger combined program. On this basis, you can easily figure
>out the consequences of the GPL: using GPL-covered code in the larger
>combined program is permitted only if the combined program as a whole
>is free under the GPL.
ON THE ONE HAND
With all due respect, I believe their is a legal distinction between
digital objects combined into a transient form (dynamic linking) and
objects combined into a persistent form (static linking). I believe
the transient form is excluded from protection under U.S. copyright
law. My reasoning is as follows:
U.S. Code, Title 17, Section 102(a) says (emphasis is mine):
"Copyright protection subsists, in accordance with this title, in
original works of authorship FIXED in any tangible medium of
expression, now known or later developed, from which they can be
perceived, reproduced, or otherwise communicated, either directly or
with the aid of a machine or device."
< http://lcweb.loc.gov/copyright/title17/1-102.html>
The crux of my reasoning is based on the meaning of the term "fixed".
This was defined in Section 101 which says (emphasis is mine):
"A work is "fixed" in a TANGIBLE MEDIUM of expression when its
embodiment in a copy or phonorecord, by or under the authority of the
author, is sufficiently permanent or stable to permit it to be
perceived, reproduced, or otherwise communicated for a period of more
than TRANSITORY DURATION. A work consisting of sounds, images, or
both, that are being transmitted, is "fixed" for purposes of this
title if a fixation of the work is being made simultaneously with its
transmission."
< http://lcweb.loc.gov/copyright/title17/1-101.html>
Note the phrase "more than transitory duration". I would argue that
the transient form that results from dynamic linking clearly
constitutes the "transitory duration" that is specifically excluded
under U.S. copyright law. Also, it is not clear that the transient,
in-memory, network transmitted or screen displayed output of a program
could be construed as a "tangible medium".
ON THE OTHER HAND
There are various ways I might refute the analysis in the "On the One
Hand" section.
Refutation #1: remember that Section 101 said:
"A work is "fixed" in a tangible medium of expression when its
embodiment in a copy or phonorecord, by or under the authority of the
author, is sufficiently permanent or stable to permit it to be
perceived, reproduced, or otherwise communicated for a period of
more than transitory duration. A work consisting of sounds, images, or
both, that are being transmitted, is "fixed" for purposes of
this title if a FIXATION of the work is being made
simultaneously with its transmission."
I might argue that, when the video and audio results of the Program
appear on the screen and speakers, the work is being transmitted for
fixation at a neuro-chemical level in the brain. This might sound a
little wacky but we must always remember that there are no natural
limitations on the wackiness of a government "Of the Lawyers, By the
Lawyers and For the Lawyers" that won't soon perish from this earth.
Refutation #2: if the user does a screen print or saves a copy of the
image or sound to disk, then they have clearly fixed the work. There
might be a line of logic that builds here around the GPL's
requirements for due notice in GPL Section 2(c):
" you must cause it, when started running for such interactive use
in the most ordinary way, to print or display an announcement
including an appropriate copyright notice"
The issue would play out around the author's culpability and
complicity in having created a system that wantonly promotes GPL
copyright infringement. The author might avoid this by displaying
notice on their copyright screen that any fixing to paper or disk
would constitute infringement.
Refutation #3: U.S. Code, Title 17, Section 102 says that:
"works of authorship include…: (6) motion pictures and other
audiovisual works"
which might be construed to cover the presentation aspects of the
"created" work output of a Program in the sense that GPL, Section 0
says:
" the output from the Program is covered only if its contents
constitute a work based on the Program (independent of having been
made by running the Program). Whether that is true depends on what the
Program does".
Refutation #4: the above line of support is strengthened to the extent
that the output constitutes a work defined in U.S. Code, Title 17,
Section 101 as a "compilation" (in the copyright sense of compilation)
or "derivative work" when Title 17, Section 103(a) says:
" The subject matter of copyright as specified by section 102
includes compilations and derivative works,"
The output of a Program could especially be construed in this manner
if it were pulled from a database or other files that are GPL'd.
Since an algorithm is not protected by copyright, it would be
difficult to claim that the output of an algorithm would be protected.
All this is messy because Title 17, Section 106, "Exclusive rights in
copyrighted works" are always subject to Section 107, " Limitations on
exclusive rights: Fair use" and the Section 110 " Limitations on
exclusive rights: Exemption of certain performances and displays". To
get around these limitations, it could be argued that a consumer pays
an up-front "admission fee" when they buy the non-free Program parts
and cover the distribution costs of the free Program parts.
Thinking about all this gives me a headache. Let me stop making
counter-point arguments and refute those I have created.
REFUTING THE OTHER HAND
The above arguments might be used to construe that dynamic linking is
protected by copyright law. However, the arguments are not relevant
because the GPL, in its own words, specifically excludes them.
GPL, Section 0 says:
"Activities other than copying, distribution and modification are
not covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the Program
(independent of having been made by running the Program). Whether that
is true depends on what the Program does."
My "On The Other Hand" arguments rely on features of copyright law
that are outside the "copying, distribution and modification" coverage
of the GPL. Further, the transient form (dynamic linking) only arises
from "running" the Program which is excluded from the GPL. In my
opinion it would be unusual if one were to claim that the running of
the program creates a new work.
CONCLUSION
Having exhausted all recourse of my "On the Other Hand" arguments, I
find in favor of the arguments put forth in the "On the One Hand"
section. Since I am not trained in legal matters, my interpretations
may have little merit.
--
Copyright (c) 1998 Lyno Sullivan; this digital object is free and
may be copied, modified and distributed under the GNU General
Public License (GPL) at http://www.gnu.org/copyleft/gpl.html and
it comes with absolutely NO WARRANTY; mailto:lyno...@maroon.tc.umn.edu
Fergus Henderson
lyno...@maroon.tc.umn.edu (Lyno Sullivan) writes:
>r...@santafe.edu (Richard Stallman) wrote:
>
>>The key to answering this is to realize that there is no legal
>>distinction between dynamic linking and static linking. The plug-in
>>is therefore an extension to the master program; the two become part
>>of a larger combined program. On this basis, you can easily figure
>>out the consequences of the GPL: using GPL-covered code in the larger
>>combined program is permitted only if the combined program as a whole
>>is free under the GPL.
>
>ON THE ONE HAND
>
>With all due respect, I believe their is a legal distinction between
>digital objects combined into a transient form (dynamic linking) and
>objects combined into a persistent form (static linking). I believe
>the transient form is excluded from protection under U.S. copyright
>law.
Even if you are correct, then I think this is something specific to
U.S. copyright law. The Australian copyright act [1] does not appear
to contain any wording similar to that which you quote from the U.S.
legislation.
[1] <http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/index.html>.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
Barry Margolin
In article <6kt9n1$da6$4...@lazy.cs.unlv.edu>,
Frank T. Lofaro <ftlo...@cs.unlv.edu> wrote:
>You facilitated the tortious (act for which one can be sued) act,
>be giving those instructions.
>
>The act was the linking of the GPL and proprietary code.
>
>Since the person doing the linking didn't copy to redistribute,
>the FSF could use the same logic that many commercial
>products do, that the use of the program constitutes a _copy_
>being made in RAM, hence under copyright jurisdiction.
The GPL very clearly states that it only applies to redistribution, *not*
to other types of copying. No one would consider copying into RAM for use
of the program to be redistribution. Furthermore, in the US, the Copyright
Act was amended some years ago to indicate that copying into RAM in order
to make normal use of a program is considered fair use, not a copyright
infringement.
Note that if the GPL didn't say that its requirements only apply during
redistribution, they could prohibit the linking based on it creating a
derived work. But the GPL specfically says that it only applies during
redistribution.
Isaac
In article <6kt9n1$da6$4...@lazy.cs.unlv.edu>, Frank T. Lofaro wrote:
>
>Possibly the FSF would sue you for contributory copyright infringement.
>
>Here's how.
>
>You facilitated the tortious (act for which one can be sued) act,
>be giving those instructions.
>
>The act was the linking of the GPL and proprietary code.
The problem with this theory is that linking GPL code on your
own system is not a tortious act. It is specifically allowed by
the GPL and might even be fair use were it not specifically allowed.
Of course Stallman's most recent statement is that linking GPL'ed code
with a proprietary library on your own system is illegal. In this case
I'm still not sure that simple instructions versus patches etc are
contributory infringement. For example if I said something like
"If you reverse all the arguments in calls to library foo, your
code will match the interface for the gpled library gfoo which is
much faster and bug free" does this really constitute contributory
infringement? What if the instructions are something any fool could
see on his own?
Isaac
Lyno Sullivan
f...@cs.mu.oz.au (Fergus Henderson) wrote:
>lyno...@maroon.tc.umn.edu (Lyno Sullivan) writes:
>
>>r...@santafe.edu (Richard Stallman) wrote:
>>
>>>The key to answering this is to realize that there is no legal
>>>distinction between dynamic linking and static linking. The plug-in
>>>is therefore an extension to the master program; the two become part
>>>of a larger combined program. On this basis, you can easily figure
>>>out the consequences of the GPL: using GPL-covered code in the larger
>>>combined program is permitted only if the combined program as a whole
>>>is free under the GPL.
>>
>>ON THE ONE HAND
>>
>>With all due respect, I believe their is a legal distinction between
>>digital objects combined into a transient form (dynamic linking) and
>>objects combined into a persistent form (static linking). I believe
>>the transient form is excluded from protection under U.S. copyright
>>law.
>
>Even if you are correct, then I think this is something specific to
>U.S. copyright law. The Australian copyright act [1] does not appear
>to contain any wording similar to that which you quote from the U.S.
>legislation.
>
>[1] <http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/index.html>.
>
------- The Australian Law ----------
COPYRIGHT ACT 1968 - SECT 21 (emphasis added)
Reproduction of works
21. (1) For the purposes of this Act, a LITERARY, dramatic or musical
work shall be deemed to have been reproduced in a MATERIAL FORM if a
sound recording or cinematograph film is made of the work, and any
record embodying such a recording and any copy of such a film shall be
deemed to be a reproduction of the work.
COPYRIGHT ACT 1968 - SECT 10
PART II PART II-INTERPRETATION
Interpretation
10.*3* (1) In this Act, unless the contrary intention appears:
"literary work" includes:
(a) a table, or compilation, expressed in words, figures or
symbols (whether or not in a visible form); and
(b) a computer program or compilation of computer programs;
"material form", in relation to a work or an adaptation of a work,
includes any form (whether visible or not) of storage from which the
work or adaptation, or a substantial part of the work or adaptation,
can be reproduced;
------- My Analysis --------
I concede that, in Australia and every external Territory, the
transitory, invisible form of the copy made in RAM does permit the
work to be reproduced. Please remember, though, that when you GPL
copyleft your work you are permitting me certain rights to copy,
modify and distribute.
GPL, Section 2 says
" These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it."
In Australia I would HAVE to distribute the dynamic parts as separate
works and let the user, at run-time, dynamic link them together. I
still believe this is quite workable for dynamic linked objects like
Java and HTML pages. My brain cannot grapple with the questions that
spring to mind. For example,
1) When you write something in Australia and GPL copyleft it, will
Australia enforce the conditions specified in the GPL? I assume it
would be a tort matter of license violation rather than copyright
infringement. It is weird to me because that would mean that the same
identical user action could be illegal in Australia while being
perfectly legal in the United States. I do not have a clue how such
situations are handled.
2) If you write something in Australia under the GPL and I combine it
with something in the U.S. under another license, whose laws would
prevail? This is additionally confusing because, I believe, the GPL
itself was copyrighted the U.S.
3) Many free software products end up with parts under the laws of
many nations; whose laws would prevail in which situations.
I am not trained in legal matters and I am not sure that I even want
to know the answers to my questions. I must say, in my own defense,
that my whole reason for making such a fuss over this matter is so
that I can be comfortable applying the GPL to my own work. I don't
care about incidental transient (dynamic linking) of my GPL'd objects
with other objects but I darn well don't want anyone deriving my
objects into something outside the GPL nor do I want anyone to take
away the GPL rights when they distribute my objects. I have gone to a
lot of trouble over the years to persuade myself that the GPL is a
usable license and I don't want to revisit the issue of having to find
another license. Please notice that I even apply the GPL to my
writing in the belief that the principles of copyleft ought to be
applied to all forms of creativity.
I must ponder these matters more vigorously so that I can get a clear
picture. Thank you for providing your feedback because it helped me
to gain a better understanding of the issues.
Geoffrey KEATING
lyno...@maroon.tc.umn.edu (Lyno Sullivan) writes:
> f...@cs.mu.oz.au (Fergus Henderson) wrote:
> 1) When you write something in Australia and GPL copyleft it, will
> Australia enforce the conditions specified in the GPL? I assume it
> would be a tort matter of license violation rather than copyright
> infringement. It is weird to me because that would mean that the same
> identical user action could be illegal in Australia while being
> perfectly legal in the United States. I do not have a clue how such
> situations are handled.
In Australia and the US, a copyright action is usually a civil matter.
The owner of the copyright must sue in a country where an infringement
occurred.
> 3) Many free software products end up with parts under the laws of
> many nations; whose laws would prevail in which situations.
Generally speaking, the law of the place where an action takes place
is the law that applies. For instance, in a place with no copyright
law (I'm not sure if there are any of these left), the GPL is
irrelevant; you can copy and distribute software however you like.
One interesting point here is that under Australian law, the copyright
owner can control importation of a work---this was set up in colonial
times to protect the British book companies, and is still there, to
protect the multinational book, recording, and software companies from
the indignity of having to charge similar prices in Australia and the
US... I think the way this interacts with the GPL is that importation
is usually `distribution'.
Oh: I am not a lawyer. This was not legal advice.
--
Geoff Keating <Geoff....@anu.edu.au>
Tim Smith
Frank T. Lofaro <ftlo...@cs.unlv.edu> wrote:
>Possibly the FSF would sue you for contributory copyright infringement.
>
>Here's how.
>
>You facilitated the tortious (act for which one can be sued) act,
>be giving those instructions.
>
>The act was the linking of the GPL and proprietary code.
>
>the FSF could use the same logic that many commercial
>products do, that the use of the program constitutes a _copy_
>being made in RAM, hence under copyright jurisdiction.
There are two problems with trying to apply contributory infringement in
situations like this with GPL'ed software.
1. First, FSF has said that GPL allows you to combine GPL'ed code with
proprietary code for your own use, if you are not distributing the
resulting work. That means that the person doing the linking is not
violating GPL. You cannot have party X liable as a contributory
infringer for an act party Y does, if that act is not a direct
infringement.
2. Second, for someone one does to be a contributory infringement, it
has to have pretty much no substantial use other than helping people
infringe someone's copyright. Proprieatary plug-ins for GPL'ed
programs, and GPL'ed plug-ins for proprietary programs both have a
substantial non-infringing use--people can combine them with GPL'ed code
for their own private use.
--Tim Smith
Tim Smith
Barry Margolin <bar...@bbnplanet.com> wrote:
>of the program to be redistribution. Furthermore, in the US, the Copyright
>Act was amended some years ago to indicate that copying into RAM in order
>to make normal use of a program is considered fair use, not a copyright
>infringement.
Technical correction: that section of the Copyright Act (section 117)
does not make such copying fair use. Rather, it creates a new category
of copying that is allowed.
--Tim Smith
Ray Auchterlounie
>As I related in another post, such an interpretation could doom
>the Mesa/3dfx project.
Mesa is _L_GPL - hence Mesa/3dfx is not under threat.
However, RMSs interpretation presumably means that the existence of
proprietary plugins for Mesa means that you CANNOT _USE_ Mesa in a
GPLed project. This would also apply to OpenGL (or any 3D api) on any
platform for which 3rd party 3d hardware is used (even if the library
does come with the system, eg. on Windoze, it uses 3rd party plug-in
drivers for the hardware).
An interesting question: with XFree86 now the main (only?) free X
implementation, at least on Linux or GNU, would third party
proprietary plug-ins for XFree86 make it illegal to write GPL software
for X on Linux or GNU ?
[ such plug-ins are planned and maybe already a reality, see recent
XFree, and Conix, announcements. ]
>Come to think of it, even commercial linux software would be illegal,
>since the OS is "linking" it into itself at run time.
The Linux kernel contains a copyright statement which explicitly
states that this is not the case.
ray
--
Ray Auchterlounie <r...@kythera.demon.co.uk>