From: Lennart Borgman <lennart.borgman@gmail.com>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: Eli Zaretskii <eliz@gnu.org>,
emacs-devel@gnu.org, "Richard M. Stallman" <rms@gnu.org>,
Angelo Graziosi <angelo.graziosi@alice.it>
Subject: Re: Emacs 23.4 Updated Windows Binaries published
Date: Mon, 6 Feb 2012 16:53:52 +0100 [thread overview]
Message-ID: <CANbX365845TtQKA-LvdFX-T_fzK4_A+GNfE_3ggxYnpoOMnEXQ@mail.gmail.com> (raw)
In-Reply-To: <8762fkyo2b.fsf@uwakimon.sk.tsukuba.ac.jp>
On Mon, Feb 6, 2012 at 16:33, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Lennart Borgman writes:
>
> > Just what I said above. But the answer from Richard that Paul just
> > pointed to (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10656#23) is
> > very clear.
>
> Clear as mud. What you are missing is that Richard responded to a
> fragment of Paul's post which was arguably misleading. Paul wrote
> "ship executables", but Richard's reply does *not* apply to "shipping"
> via the Internet. See below.
>
> > In fact I think it confirm that sources can be elsewhere.
>
> That's wishful thinking, at best.
I am perhaps an optimist ;-)
> No, in this case, where we are talking about distributing via an
> Internet server, the sources have to be in the same place as the
> object. The GPL, section 6(d), is crystal clear on that point.
Are we reading the same version of GPL 6(d)? Maybe I do not understand
the English well then. 6(d) says:
d) Convey the object code by offering access from a designated
place (gratis or for
a charge), and offer equivalent access to the Corresponding Source
in the same
way through the same place at no further charge. You need not
require recipients
to copy the Corresponding Source along with the object code. If
the place to copy
the object code is a network server, the Corresponding Source may be on a
different server (operated by you or a third party) that supports
equivalent copying
facilities, provided you maintain clear directions next to the
object code saying
where to find the Corresponding Source. Regardless of what server hosts the
Corresponding Source, you remain obligated to ensure that it is
available for as
long as needed to satisfy these requirements.
It says "through the same place", not "at the same place". And it also
tells what to do if the source is not on the same server as the object
code.
I really do not understand. I would be glad if you explained further.
> There
> are three exceptions: 6(b), 6(c), and 6(e). None applies to the
> situation we are discussing. 6(b) requires that you *provide physical
> media* (eg, a CD-ROM) plus a *written guarantee* that the sources
> exist in a particular place; Emacs is clearly not going to restrict
> itself to that. Section 6(c) does not apply to mass distribution; it
> specifically says "only occasionally" (eg, making a copy of Emacs as a
> birthday present for your sister). Further, to invoke 6(c) you must
> have received your copy under 6(b), which certainly is not the case
> for Emacs and GnuTLS. 6(e) requires use of a peer-to-peer protocol,
> which is obviously unsuitable as the primary source of a mass
> distribution of Emacs.
>
> > There could be a DOI-like pointer for exactly those sources used.
>
> C'mon, Lennart, I wasn't born yesterday. Of course I figured that out
> already. That's so obvious even a U.S. Patent Office examiner would
> refuse to pass it.
;-)
Yes, I know you are aware of that.
> You are *still* missing the point. Did you miss Eli's recent post
> asking somebody to remove version numbers of 3rd party libraries used
> by the Windows binary distribution? Updating that DOI is a PITA and
> mistake-prone, and it's a nasty mistake to make because *any small
> mistake at all* because it puts you in technical violation of your
> license (but only if you distribute binaries only; if you distribute
> the source too, typos in the README are merely typos).
Updating the DOI-like URI would indeed be problematic since it could
still be used for old distributed object. I guess you have to create
new numbers for every ojbect distribution.
> > An easier way is perhaps to clone the sources to a new place in the
> > repository (or another repository).
>
> Technically easier, yes; GPL-compliant, arguably not. Clause 6(d)
> requires "equivalent copying services"; if the object is in a tarball,
> one could argue that requiring tarball users to install Bazaar is not
> equivalent.
Ok, I never understood it that way, but you may be right. However even
Launchpad seems to get an easy way to download a zip file instead of
using Bazaar soon. (There is a long standing request for that and the
comments suggests that it is implemented now but I do not know if it
is in production yet.)
next prev parent reply other threads:[~2012-02-06 15:53 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-05 16:34 Emacs 23.4 Updated Windows Binaries published Angelo Graziosi
2012-02-05 16:52 ` Eli Zaretskii
2012-02-05 17:12 ` Angelo Graziosi
2012-02-05 17:23 ` Juanma Barranquero
2012-02-06 5:09 ` Christoph Scholtes
2012-02-05 19:10 ` Lennart Borgman
2012-02-05 20:48 ` Eli Zaretskii
2012-02-05 21:24 ` Lennart Borgman
2012-02-06 4:01 ` Eli Zaretskii
2012-02-06 3:46 ` Stephen J. Turnbull
2012-02-06 4:15 ` Lennart Borgman
2012-02-06 5:22 ` Stephen J. Turnbull
2012-02-06 5:42 ` Lennart Borgman
2012-02-06 6:26 ` Paul Eggert
2012-02-06 7:12 ` Stephen J. Turnbull
2012-02-06 7:46 ` Stephen J. Turnbull
2012-02-06 13:49 ` Lennart Borgman
2012-02-06 15:46 ` Stephen J. Turnbull
2012-02-06 13:47 ` Lennart Borgman
2012-02-06 15:33 ` Stephen J. Turnbull
2012-02-06 15:53 ` Lennart Borgman [this message]
2012-02-06 17:01 ` Stephen J. Turnbull
2012-02-06 21:40 ` Lennart Borgman
2012-02-07 9:53 ` Richard Stallman
2012-02-07 13:31 ` Lennart Borgman
2012-02-07 15:57 ` Paul Eggert
-- strict thread matches above, loose matches on Subject: below --
2012-02-05 1:04 Christoph Scholtes
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=CANbX365845TtQKA-LvdFX-T_fzK4_A+GNfE_3ggxYnpoOMnEXQ@mail.gmail.com \
--to=lennart.borgman@gmail.com \
--cc=angelo.graziosi@alice.it \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
--cc=stephen@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).