[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs 23.4 Updated Windows Binaries published

From: Lennart Borgman
Subject: Re: Emacs 23.4 Updated Windows Binaries published
Date: Mon, 6 Feb 2012 16:53:52 +0100

On Mon, Feb 6, 2012 at 16:33, Stephen J. Turnbull <address@hidden> 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

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.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]