From: David Kastrup <dak@gnu.org>
Cc: xemacs-beta@xemacs.org, emacs-devel@gnu.org, bob@rattlesnake.com,
stephen@xemacs.org, andy@xemacs.org, Ben Wing <ben@666.com>
Subject: Re: Permission to use portions of the recent GNU Emacs Manual
Date: Mon, 20 Dec 2004 09:07:42 +0100 [thread overview]
Message-ID: <x5r7llqto1.fsf@lola.goethe.zz> (raw)
In-Reply-To: <200412200147.05475.pogonyshev@gmx.net> (Paul Pogonyshev's message of "Mon, 20 Dec 2004 01:48:55 +0200")
Paul Pogonyshev <pogonyshev@gmx.net> writes:
> David Kastrup wrote:
>> Paul Pogonyshev <pogonyshev@gmx.net> writes:
>> > David Kastrup wrote:
>> >> b) why it would be technically impossible for you to change the XEmacs
>> >> manual licence to the GFDL: it does not seem like you have handed out
>> >> any written assurances that the licence is never going to change.
>> >
>> > I think because contributing a piece of work implicitly means that you
>> > agree to distribute it under the _current_ license.
>>
>> Whose theory is that? I don't see any of it in copyright law, and I
>> don't see any of it in the GPL.
>
> Mine, I guess. Just to note, I'm not particularly familiar with all
> this stuff, so take it lightly, please. I'm just on that ``common
> sense'' ground.
>
>> This sounds suspiciously like the
>> "viral licence" theories where a contact with GPLed software magically
>> makes all of your software free for the taking.
>
> I fail to see much similarity, but feel free to elaborate.
It is the same "it comes into contact with GPL software, so it
magically gets licenced as GPLed software" theory.
>> This is simply not true. To have software GPLed, you need to
>> explicitly licence it that way, regardless of whether it has come
>> in contact with other GPLed software or not. Only if it has, you
>> must not redistribute a combined product under a different licence.
>> But there is no automatic remedy involved: you always have
>> _several_ choices to come into compliance: licence the whole under
>> GPL, or replace the GPLed parts by something different, or stop
>> distributing it.
>>
>> > So, to relicense a piece of contributed work, you need an agreement
>> > from the author, either got in advance (like FSF copyright
>> > assignment includes) or got right before the license change.
>>
>> To "reli[ce]nce" something it must have been licensed in the first
>> place.
>
> I cannot understand what exactly you think about contributions
> without signed papers. Let's try to filter it out (again, I'm
> basing on my common sense and little knowledge of copyright law, so,
> please, be kind to my mistakes.)
>
> So, let's assume John contributes a large patch (500 lines of code)
> to XEmacs. Since we are talking of XEmacs here, he is not asked for
> any copyright assignments or other legal papers.
>
> Now, what is the legal status of XEmacs + John's patch now? (We
> assume XEmacs is legally distributed under GNU GPL before the patch
> is added.) I'm listing all possibilities I can think of.
>
> Possibility 1. John's patch is automagically licensed under GNU GPL
> and ``license control'' is miraculously transferred to some mistical
> ``XEmacs spirit,'' that can change the license at whim, like FSF
> could if it wasn't bound by our assignment papers.
>
> This doesn't sound real.
>
> Possibility 2. John's patch is automagically licensed under GNU
> GPL, but to relicense it, you need his blessing. This is what I
> guessed in the previous message based on XEmacs as a whole being
> distributed under GNU GPL.
>
> However, you wrote that John's code couldn't be licensed implicitly:
> ``To have software GPLed, you need to explicitly licence it that
> way, regardless of whether it has come in contact with other GPLed
> software or not.'' What does ``explicitly'' means, BTW?
If you are not assigning copyright, then a written and signed
statement is explicit enough for the law.
> I'm distributing a program I wrote, with each file saying it comes
> under GPL and the GPL text in `COPYING'. Is this explicit enough?
The last time I looked, typical contributors were not distributing
complete versions of XEmacs. Even if they were, if they change their
mind afterwards about their contribution, all you can demand is then
that they stop distributing XEmacs with their patch in it.
> Should John distribute his patch and GPL text along with it to make
> it explicit?
The GPL text is a text. It's connection to the material must be
established. It is not established by the files sitting in the same
directory. If you have an exchange of consideration, like if you are
paying somebody, _then_ the material is licenced to you and, absent
any other written communication, it may be assumed that the
accompanying licence file is considered valid if it has been attached
by the selling party. But if you, say, pay somebody for working on
XEmacs code and you don't put the GPL requirement in the contract, and
you pay him for code (not for work hours), then you may run into legal
trouble if he later claims he did not intend his work to be made
available to third parties.
> Or is signing legal papers the only option? What is the difference
> between licensing done by the project original author and its
> contributors in terms of licensing?
Nothing. If the original author changes his mind, explains that the
GPL licence file landed up in that directory by accident and he did
not have permission from management, anyway, and stops handing out
copies, and you have not given him anything in return, you can't drag
him to court for damages.
> Possibility 3. John's patch is not licensed at all, because he
> didn't explictly license it.
>
> However, to the best of my knowledge of copyright law, you cannot
> even _use_ non-licensed work, not to mention modify or distribute
> it. This means that XEmacs people cannot legally merge John's patch
> in. In other words, XEmacs + John's patch combination is illegal to
> use, modify or distribute...
There you are. If you need to go to court with a contributor that has
changed its mind, this is what you will get stuck with. Lots of
business gets done every day without anything written down (life would
get complicated otherwise). But if somebody changes his mind
afterwards, then the situation better be a standard situation that a
court can resolve without making it a major case.
> Possibility 5. XEmacs does require some sort of explicit licensing
> of contributions.
>
> Again, that would solve all problems, but from what I've heard here,
> this is simply not the case.
It would solve the problem of legality. It would not solve the
problem of having a single major copyright holder able to enforce
copyright in case of licence breaches (which is why the FSF demands
assignments instead of licences).
> Either
>
> XEmacs is distributed under GNU GPL, because each contributor
> implicitly (and some of them explicitly, by assigning
> copyright to FSF) licensed it under that license.
>
> Or
>
> XEmacs is used, distributed and modified illegally, because
> some parts of it are not licensed by copyright holders in any
> way. This means that people working on XEmacs, as well as
> distributors and even common users can be sued for copyright
> infringement (or how do they call it.)
Or
XEmacs is used, distributed and modified under the assumption
that all of the various copyright holders (which might not
even be tracked) have given their consent to do so and will
never withdraw it. Nobody can be sued for copyright
infringement until it can be shown that this was done on
purpose. Merely distributors and users can be ordered to stop
using copies of XEmacs with the respective code in it. This
will open the suitor for a counterclaim _if_ he can be shown
to have distributed XEmacs himself. In addition, if some
party distributed binary-only versions of XEmacs, and the
XEmacs team would try to sue him, he can have the case thrown
out of court if he can show that XEmacs itself uses code from
him without explicit permission.
> I personally don't feel easy about the second option. I'd like to be
> convinced that either the first or a third (missed here) option is
> true.
When in doubt, ask a lawyer. The above is not legal advice, it is
just one possible view. The more possible views exist, the more
expensive court cases become, and the less predictable the outcome.
The FSF is a small organization that does not have the resources to go
to court with some company like SCO, and XEmacs is even smaller.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
next prev parent reply other threads:[~2004-12-20 8:07 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-09 22:28 Permission to use portions of the recent GNU Emacs Manual Ben Wing
2004-12-10 23:14 ` Richard Stallman
2004-12-11 0:59 ` Ben Wing
2004-12-11 1:06 ` Miles Bader
2004-12-11 10:27 ` Alan Mackenzie
2004-12-11 18:19 ` Eli Zaretskii
2004-12-11 20:43 ` David Kastrup
2004-12-11 19:02 ` Stefan Monnier
2004-12-12 0:26 ` Karl Fogel
2004-12-12 8:57 ` David Kastrup
2004-12-12 16:56 ` Brian Palmer
2004-12-12 13:31 ` Matthew Mundell
2004-12-12 13:40 ` David Kastrup
2004-12-12 2:03 ` Robert J. Chassell
2004-12-12 4:59 ` Karl Fogel
[not found] ` <m1CdWGG-0004R2C@rattlesnake.com>
2004-12-12 17:43 ` David Kastrup
2004-12-12 18:39 ` Florian Weimer
2004-12-12 19:24 ` David Kastrup
2004-12-12 19:49 ` Florian Weimer
2004-12-12 19:43 ` Robert J. Chassell
2004-12-12 19:59 ` David Kastrup
2004-12-12 20:46 ` Robert J. Chassell
2004-12-12 21:00 ` Andy Piper
2004-12-13 1:59 ` Robert J. Chassell
2004-12-13 2:23 ` David Kastrup
2004-12-13 12:34 ` Thien-Thi Nguyen
2004-12-13 16:53 ` Robert J. Chassell
2004-12-15 14:23 ` Stephen J. Turnbull
2004-12-15 19:14 ` Robert J. Chassell
2004-12-15 20:19 ` David Kastrup
2004-12-15 23:32 ` Robert J. Chassell
2004-12-17 5:36 ` Stephen J. Turnbull
2004-12-15 23:20 ` Richard Stallman
2004-12-16 10:58 ` David Kastrup
2004-12-16 12:18 ` Eli Zaretskii
2004-12-16 12:29 ` Kim F. Storm
2004-12-17 0:53 ` Richard Stallman
2004-12-18 10:20 ` Ben Wing
2004-12-18 23:32 ` Miles Bader
2004-12-19 6:31 ` Ben Wing
2004-12-19 6:32 ` Ben Wing
2004-12-19 13:54 ` Robert J. Chassell
2004-12-19 15:40 ` David Kastrup
2004-12-19 16:10 ` Paul Pogonyshev
2004-12-19 21:32 ` David Kastrup
2004-12-19 23:48 ` Paul Pogonyshev
2004-12-20 8:07 ` David Kastrup [this message]
2004-12-20 14:05 ` Robert J. Chassell
2004-12-20 0:19 ` Ben Wing
2004-12-20 7:20 ` David Kastrup
2004-12-20 10:58 ` Stephen J. Turnbull
2004-12-20 10:56 ` Richard Stallman
2004-12-20 12:47 ` David Kastrup
2004-12-17 1:32 ` Stephen J. Turnbull
2004-12-12 4:39 ` Richard Stallman
2004-12-12 6:16 ` Stefan Monnier
2004-12-12 21:28 ` Eli Zaretskii
2004-12-12 21:43 ` David Kastrup
2004-12-13 2:22 ` Robert J. Chassell
2004-12-13 6:48 ` Brian Palmer
2004-12-13 10:05 ` David Kastrup
2004-12-13 17:44 ` Bruce Stephens
2004-12-14 13:09 ` Stephen J. Turnbull
2004-12-14 2:56 ` Karl Fogel
2004-12-14 14:16 ` Robert J. Chassell
2004-12-13 4:23 ` Dhruva
2004-12-13 19:51 ` Richard Stallman
2004-12-13 20:03 ` David Kastrup
2004-12-14 10:03 ` Per Abrahamsen
2004-12-14 10:14 ` David Kastrup
2004-12-14 14:09 ` Robert J. Chassell
2004-12-14 14:25 ` David Kastrup
2004-12-14 20:19 ` Robert J. Chassell
2004-12-14 22:09 ` David Kastrup
2004-12-15 0:12 ` Robert J. Chassell
2004-12-15 8:03 ` Per Abrahamsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x5r7llqto1.fsf@lola.goethe.zz \
--to=dak@gnu.org \
--cc=andy@xemacs.org \
--cc=ben@666.com \
--cc=bob@rattlesnake.com \
--cc=emacs-devel@gnu.org \
--cc=stephen@xemacs.org \
--cc=xemacs-beta@xemacs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).