Emacs 23.4 Updated Windows Binaries published

Emacs 23.4 Updated Windows Binaries published

[Christoph Scholtes]

The updated Emacs 23.4 Windows Binaries have been published in

http://ftp.gnu.org/pub/gnu/emacs/windows/

The originally published build of Emacs 23.4 from 1-30-2012 triggered 
_false_ alarms with some virus scanners (e.g. Avira) and was therefore 
removed from the site. It was determined that this happened only with 
certain versions of mingw-gcc used to build the binaries.

The updated version was built using mingw-gcc 4.4.0 and does not trigger 
the Avira virus scanner. Please report any other instance of a virus 
scanner that may trigger on these binaries to emacs-devel@gnu.org.

The binaries were built using the following libraries:
giflib-4.1.4-1
jpeg-6b-4
libXpm-3.5.8
libpng-1.4.3-1
tiff-3.8.2-1
zlib-1.2.5-2

Please report any bugs that you come across via M-x report-emacs-bugs,
or email bug-gnu-emacs@gnu.org.

For questions, email emacs-devel@gnu.org.

Re: Emacs 23.4 Updated Windows Binaries published

[Angelo Graziosi]

Christoph Scholtes wrote:

> The binaries were built using the following libraries:
> giflib-4.1.4-1
> jpeg-6b-4
> libXpm-3.5.8
> libpng-1.4.3-1
> tiff-3.8.2-1
> zlib-1.2.5-2

Does an user need those libraries at run-time? If "yes", why their 
binaries aren't in the emacs tar-ball? Only libXpm.dll is found... :-(

At least, why not adding a link to those binaries?

Searching in http://gnuwin32.sourceforge.net, for example, one finds 
libpng-1.2.37 but not libpng-1.4.3...

The best solution, in any case, would be to ship all the needed binaries 
from which Emacs binaries depend on... :-)  ...at least as separate 
package (== tar-ball)... :)


Ciao,
Angelo.

Re: Emacs 23.4 Updated Windows Binaries published

[Eli Zaretskii]

> Date: Sun, 05 Feb 2012 17:34:22 +0100
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> 
> Christoph Scholtes wrote:
> 
> > The binaries were built using the following libraries:
> > giflib-4.1.4-1
> > jpeg-6b-4
> > libXpm-3.5.8
> > libpng-1.4.3-1
> > tiff-3.8.2-1
> > zlib-1.2.5-2
> 
> Does an user need those libraries at run-time?

No, Emacs will run even without them.  But some features, like support
for displaying the corresponding image types, will not be available.

> If "yes", why their 
> binaries aren't in the emacs tar-ball? Only libXpm.dll is found... :-(

libxpm is required for displaying the color icons on the tool-bar
buttons, that's why it is stored near the binary distribution.

> At least, why not adding a link to those binaries?

The links are in the README.W32 file.

> The best solution, in any case, would be to ship all the needed binaries 
> from which Emacs binaries depend on... :-)  ...at least as separate 
> package (== tar-ball)... :)

That means unnecessary complications for the volunteers who produce
the binaries, see the recent threads here (about GnuTLS, but not only
about it).  For starters, we need to provide sources as well, and that
might be tricky legal-wise.

Re: Emacs 23.4 Updated Windows Binaries published

[Angelo Graziosi]

Il 05/02/2012 17.52, Eli Zaretskii ha scritto:

> The links are in the README.W32 file.

...hmm... From the README.W32:

  "These libraries are all available as part of GTK
   download for Windows (http://www.gtk.org/download-windows.html), or
   from the GnuWin32 project. "

it looks that the right link is http://www.gtk.org/download/win32.php

Ciao,
Angelo.

Re: Emacs 23.4 Updated Windows Binaries published

[Juanma Barranquero]

On Sun, Feb 5, 2012 at 18:12, Angelo Graziosi <angelo.graziosi@alice.it> wrote:

> it looks that the right link is http://www.gtk.org/download/win32.php

The URL is already fixed in the trunk, but the change wasn't backported to 23.4.

    Juanma

Re: Emacs 23.4 Updated Windows Binaries published

[Lennart Borgman]

On Sun, Feb 5, 2012 at 17:52, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 05 Feb 2012 17:34:22 +0100
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>>
>> Christoph Scholtes wrote:
>>
>> > The binaries were built using the following libraries:
>> > giflib-4.1.4-1
>> > jpeg-6b-4
>> > libXpm-3.5.8
>> > libpng-1.4.3-1
>> > tiff-3.8.2-1
>> > zlib-1.2.5-2
>>
>> Does an user need those libraries at run-time?
>
> No, Emacs will run even without them.  But some features, like support
> for displaying the corresponding image types, will not be available.

So if the question was "any user" than the answer is "yes" ... ;-)

> That means unnecessary complications for the volunteers who produce
> the binaries, see the recent threads here (about GnuTLS, but not only
> about it).  For starters, we need to provide sources as well, and that
> might be tricky legal-wise.

I have not been following this particular thread, but my understanding
is that only a link to the relevant sources is needed now - if we can
guarantee that this works. (This was my understanding of a message
from RMS quite some time ago. I might have misunderstood it, though.)

A real problem is however to keep the libraries updated. There could
be security problems for some of them and that requires an easy way to
remind about security updates and do them.

Re: Emacs 23.4 Updated Windows Binaries published

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Sun, 5 Feb 2012 20:10:50 +0100
> Cc: Angelo Graziosi <angelo.graziosi@alice.it>, emacs-devel@gnu.org
> 
> > That means unnecessary complications for the volunteers who produce
> > the binaries, see the recent threads here (about GnuTLS, but not only
> > about it).  For starters, we need to provide sources as well, and that
> > might be tricky legal-wise.
> 
> I have not been following this particular thread, but my understanding
> is that only a link to the relevant sources is needed now - if we can
> guarantee that this works. (This was my understanding of a message
> from RMS quite some time ago. I might have misunderstood it, though.)

You misunderstood.

Re: Emacs 23.4 Updated Windows Binaries published

[Lennart Borgman]

On Sun, Feb 5, 2012 at 21:48, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Sun, 5 Feb 2012 20:10:50 +0100
>> Cc: Angelo Graziosi <angelo.graziosi@alice.it>, emacs-devel@gnu.org
>>
>> > That means unnecessary complications for the volunteers who produce
>> > the binaries, see the recent threads here (about GnuTLS, but not only
>> > about it).  For starters, we need to provide sources as well, and that
>> > might be tricky legal-wise.
>>
>> I have not been following this particular thread, but my understanding
>> is that only a link to the relevant sources is needed now - if we can
>> guarantee that this works. (This was my understanding of a message
>> from RMS quite some time ago. I might have misunderstood it, though.)
>
> You misunderstood.

If you think so then please explain to me what RMS meant here:

http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00430.html

Re: Emacs 23.4 Updated Windows Binaries published

[Stephen J. Turnbull]

Lennart Borgman writes:

 > I have not been following this particular thread, but my
 > understanding is that only a link to the relevant sources is needed
 > now - if we can guarantee that this works. (This was my
 > understanding of a message from RMS quite some time ago. I might
 > have misunderstood it, though.)

If you mean that Emacs doesn't need to distribute those sources *with
Emacs*, that is true.  If you mean that Emacs docs can point to the
upstream sources, you misunderstand.

 > A real problem is however to keep the libraries updated.

This is the problem.  If you distribute binaries, you must make the
corresponding sources for the exact version of each distributed binary
available according to the GPL.  The message you refer to undoubtedly
was explaining certain corner cases where these sources need not be
delivered in the same packages as the binaries (there are pretty
severe conditions on this, though).

If Emacs makes *zero* changes to the 3rd party sources for its
distribution, then theoretically it would be OK to point to them (but
it doesn't satisfy the GPL!)  However, that case is likely to be
fairly rare (I would guess that in most cases the build scripts would
be modified or not yet published security patches applied, etc), and
so practically the GPL's requirement that you distribute the
corresponding source *yourself* is simple and reasonable.

Re: Emacs 23.4 Updated Windows Binaries published

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Sun, 5 Feb 2012 22:24:17 +0100
> Cc: angelo.graziosi@alice.it, emacs-devel@gnu.org
> 
> >> I have not been following this particular thread, but my understanding
> >> is that only a link to the relevant sources is needed now - if we can
> >> guarantee that this works. (This was my understanding of a message
> >> from RMS quite some time ago. I might have misunderstood it, though.)
> >
> > You misunderstood.
> 
> If you think so then please explain to me what RMS meant here:
> 
> http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00430.html

Having sources near the binaries is the only practical way to satisfy
both clauses mentioned in that thread.

Re: Emacs 23.4 Updated Windows Binaries published

[Lennart Borgman]

On Mon, Feb 6, 2012 at 04:46, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Lennart Borgman writes:
>
>  > I have not been following this particular thread, but my
>  > understanding is that only a link to the relevant sources is needed
>  > now - if we can guarantee that this works. (This was my
>  > understanding of a message from RMS quite some time ago. I might
>  > have misunderstood it, though.)
>
> If you mean that Emacs doesn't need to distribute those sources *with
> Emacs*, that is true.  If you mean that Emacs docs can point to the
> upstream sources, you misunderstand.

Stephen, can you please explain exactly what makes it not permissible
to point to the upstream sources? You say below that it does not
satisfy the GPL. Is that what you mean? What does it break?

>  > A real problem is however to keep the libraries updated.
>
> This is the problem.  If you distribute binaries, you must make the
> corresponding sources for the exact version of each distributed binary
> available according to the GPL.  The message you refer to undoubtedly
> was explaining certain corner cases where these sources need not be
> delivered in the same packages as the binaries (there are pretty
> severe conditions on this, though).
>
> If Emacs makes *zero* changes to the 3rd party sources for its
> distribution, then theoretically it would be OK to point to them (but
> it doesn't satisfy the GPL!)  However, that case is likely to be
> fairly rare (I would guess that in most cases the build scripts would
> be modified or not yet published security patches applied, etc), and
> so practically the GPL's requirement that you distribute the
> corresponding source *yourself* is simple and reasonable.

Re: Emacs 23.4 Updated Windows Binaries published

[Christoph Scholtes]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sun, Feb 5, 2012 at 18:12, Angelo Graziosi <angelo.graziosi@alice.it> wrote:
>
>> it looks that the right link is http://www.gtk.org/download/win32.php
>
> The URL is already fixed in the trunk, but the change wasn't backported to 23.4.

I fixed this in the Emacs 23 branch.

Re: Emacs 23.4 Updated Windows Binaries published

[Stephen J. Turnbull]

Lennart Borgman writes:
 > On Mon, Feb 6, 2012 at 04:46, Stephen J. Turnbull <stephen@xemacs.org> wrote:

 > > If you mean that Emacs doesn't need to distribute those sources
 > > *with Emacs*, that is true.  If you mean that Emacs docs can
 > > point to the upstream sources, you misunderstand.
 > 
 > Stephen, can you please explain exactly what makes it not
 > permissible to point to the upstream sources?

Eli answered this briefly already, but here's some additional detail
and rationale.

 > You say below that it does not satisfy the GPL. Is that what you
 > mean?

Almost.  First, to the extent that the distributed code is under the
GPL but not owned by the FSF, that's exactly right.

Second, even if the additional library code is owned by the FSF, I
consider that the FSF is morally (and perhaps legally by its charter
and the assignment contracts it has entered) bound to provide that
code on terms that allow third parties to easily redistribute Emacs
exactly as they receive it, not to mention with their own
modifications if they desire.  Having to chase down sources on
multiple hosts (some of which may no longer exist at the time you
receive the code) is not my idea of fulfilling that obligation.

I'm willing to go out on a limb and speak for Richard here: he would
also find that unacceptable.

 > What does it break?

It breaks Section 6d of the GNU General Public License, v3 (and the
similar section in GPLv2, which is stricter):

      6. Conveying Non-Source Forms.

      You may convey a covered work in object code form under the terms
    of sections 4 and 5, provided that you also convey the
    machine-readable Corresponding Source under the terms of this License,
    in one of these ways:

        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.

Other parts of section 6 would also be broken in similar ways in case
of "embedded Emacs" or "Emacs-on-a-disk" distribution.

Note that even if Emacs can legally get around this requirement
because the FSF owns all related code, anybody downstream from Emacs
cannot.  They must comply with the GPL in full, which (strictly
speaking) means providing the exact copy of the Corresponding Sources
that produced the binary they're distributing.

Re: Emacs 23.4 Updated Windows Binaries published

[Lennart Borgman]

On Mon, Feb 6, 2012 at 06:22, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Lennart Borgman writes:
>  > On Mon, Feb 6, 2012 at 04:46, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>
>  > > If you mean that Emacs doesn't need to distribute those sources
>  > > *with Emacs*, that is true.  If you mean that Emacs docs can
>  > > point to the upstream sources, you misunderstand.
>  >
>  > Stephen, can you please explain exactly what makes it not
>  > permissible to point to the upstream sources?
>
> Eli answered this briefly already, but here's some additional detail
> and rationale.


Thanks, I am looking for the details.


>  > You say below that it does not satisfy the GPL. Is that what you
>  > mean?
>
> Almost.  First, to the extent that the distributed code is under the
> GPL but not owned by the FSF, that's exactly right.
>
> Second, even if the additional library code is owned by the FSF, I
> consider that the FSF is morally (and perhaps legally by its charter
> and the assignment contracts it has entered) bound to provide that
> code on terms that allow third parties to easily redistribute Emacs
> exactly as they receive it, not to mention with their own
> modifications if they desire.  Having to chase down sources on
> multiple hosts (some of which may no longer exist at the time you
> receive the code) is not my idea of fulfilling that obligation.
>
> I'm willing to go out on a limb and speak for Richard here: he would
> also find that unacceptable.
>
>  > What does it break?
>
> It breaks Section 6d of the GNU General Public License, v3 (and the
> similar section in GPLv2, which is stricter):
>
>      6. Conveying Non-Source Forms.
>
>      You may convey a covered work in object code form under the terms
>    of sections 4 and 5, provided that you also convey the
>    machine-readable Corresponding Source under the terms of this License,
>    in one of these ways:
>
>        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.


I can't see that this in a legal way prevents from pointing to sources
that is not owned by the distributor.

And when it comes to making the code easily accessible would not
something like DOI be useful? (http://www.doi.org/)

(Maybe Richard wants to clarify this. I am adding him.)

> Other parts of section 6 would also be broken in similar ways in case
> of "embedded Emacs" or "Emacs-on-a-disk" distribution.
>
> Note that even if Emacs can legally get around this requirement
> because the FSF owns all related code, anybody downstream from Emacs
> cannot.  They must comply with the GPL in full, which (strictly
> speaking) means providing the exact copy of the Corresponding Sources
> that produced the binary they're distributing.

Re: Emacs 23.4 Updated Windows Binaries published

[Paul Eggert]

On 02/05/2012 09:42 PM, Lennart Borgman wrote:
> I can't see that this in a legal way prevents from pointing to sources
> that is not owned by the distributor.

The GPL is clear that one cannot satisfy its requirements merely by
pointing to sources that someone else happens to distribute.
If one distributes executables, then one also has the responsibility
to distribute sources, even if the sources are identical to someone
else's copy.

This topic came up last week with respect to a Mac port, and Richard
responded there the same way that I expect he'll respond here; please see
the thread starting at <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10656#23>.

Re: Emacs 23.4 Updated Windows Binaries published

[Stephen J. Turnbull]

Lennart Borgman writes:

 > I can't see that this in a legal way prevents from pointing to sources
 > that is not owned by the distributor.

What's unclear about

 > > and offer equivalent access to the Corresponding Source in the
 > > same way through the same place at no further charge.

?

You must place the source at the same place as the object being
offered.

 > And when it comes to making the code easily accessible would not
 > something like DOI be useful? (http://www.doi.org/)

No, you're missing the point here.  Any old source won't do.  The
exact source used to produce the binaries you offer, including any
script etc. required to produce the same binaries, must be provided.

Sure, you *could* use DOI to point to that, but if you fail to update
the DOI pointer when you upgrade the binary, you're in violation of
the GPL.  So this really doesn't save you anything, except a few bytes
of disk space and a few CPU cycles.  The human effort required is the
same.  One Make target can automatically (1) produce the binary, (2)
tar and upload the source, and (3) tar and upload the binary,
automatically satisfying the GPL requirements in this respect.  Thus,
the GPL requirements are *not* burdensome, given modern prices for CPU
and disk, and even bandwidth (you can always offer a "stealth primary"
for both object and source to selected mirrors, and let the general
public download from those mirrors).

Re: Emacs 23.4 Updated Windows Binaries published

[Stephen J. Turnbull]

Stephen J. Turnbull writes:

 >  > And when it comes to making the code easily accessible would not
 >  > something like DOI be useful? (http://www.doi.org/)

 > Sure, you *could* use DOI to point to that, but if you fail to update
 > the DOI pointer when you upgrade the binary, you're in violation of
 > the GPL.

Let me clarify that as Paul and others point out, you are in violation
of the letter of the GPL, which requires actual source, not a pointer,
but that's not what I meant.

What I mean here is that you are also in violation of the spirit,
because your pointer no longer points the to Corresponding Source, but
to something else.

Re: Emacs 23.4 Updated Windows Binaries published

[Lennart Borgman]

On Mon, Feb 6, 2012 at 08:12, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Lennart Borgman writes:
>
>  > I can't see that this in a legal way prevents from pointing to sources
>  > that is not owned by the distributor.
>
> What's unclear about

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.

In fact I think it confirm that sources can be elsewhere.

However it requires a legal arrangement that the sources elsewhere
will be available for the time required. And Richard says that such
arrangements are not made by FSF.

I am not sure that is the best way to handle it, but I am sure Richard
has good reasons for it. Maybe setting up some kind of DOI-like system
would be a better idea long term.

>  > And when it comes to making the code easily accessible would not
>  > something like DOI be useful? (http://www.doi.org/)
>
> No, you're missing the point here.  Any old source won't do.  The
> exact source used to produce the binaries you offer, including any
> script etc. required to produce the same binaries, must be provided.
>
> Sure, you *could* use DOI to point to that, but if you fail to update
> the DOI pointer when you upgrade the binary, you're in violation of
> the GPL.

There could be a DOI-like pointer for exactly those sources used.

> So this really doesn't save you anything, except a few bytes
> of disk space and a few CPU cycles.  The human effort required is the
> same.  One Make target can automatically (1) produce the binary, (2)
> tar and upload the source, and (3) tar and upload the binary,
> automatically satisfying the GPL requirements in this respect.  Thus,
> the GPL requirements are *not* burdensome, given modern prices for CPU
> and disk, and even bandwidth (you can always offer a "stealth primary"
> for both object and source to selected mirrors, and let the general
> public download from those mirrors).

An easier way is perhaps to clone the sources to a new place in the
repository (or another repository).

In a way that actually is something like a DOI-system since the cloned
sources gets a new identifier.

Thanks for the thoughts. I think it is all clear to me now. (If I did
not misunderstood... ;-)

Re: Emacs 23.4 Updated Windows Binaries published

[Lennart Borgman]

On Mon, Feb 6, 2012 at 08:46, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Stephen J. Turnbull writes:
>
>  >  > And when it comes to making the code easily accessible would not
>  >  > something like DOI be useful? (http://www.doi.org/)
>
>  > Sure, you *could* use DOI to point to that, but if you fail to update
>  > the DOI pointer when you upgrade the binary, you're in violation of
>  > the GPL.
>
> Let me clarify that as Paul and others point out, you are in violation
> of the letter of the GPL, which requires actual source, not a pointer,
> but that's not what I meant.

I do not understand what that would mean. Is not all you can give just
a pointer? (Whether it is in the form of a http URL or a DOI URI does
not really matter, or?)

Re: Emacs 23.4 Updated Windows Binaries published

[Stephen J. Turnbull]

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.

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

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).  Probably
nobody will sue you, just ask you to fix it, but you will definitely
get a rep as one who disrespects licenses.

 > 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.  In practice, the FSF might not go after somebody who did
that, as clearly the "preferred form of source for development" is a
clone of the DVCS repo.  On the other hand, they might very well ask
you to provide the tarball, too.  And if the VCS were BitKeeper or
Visual Source Safe, they probably *would* go after you.

Re: Emacs 23.4 Updated Windows Binaries published

[Stephen J. Turnbull]

Lennart Borgman writes:

 > > Let me clarify that as Paul and others point out, you are in violation
 > > of the letter of the GPL, which requires actual source, not a pointer,
 > > but that's not what I meant.
 > 
 > I do not understand what that would mean. Is not all you can give just
 > a pointer? (Whether it is in the form of a http URL or a DOI URI does
 > not really matter, or?)

If you're providing an archive, of course you can include the source
in that archive.

If you don't include source in the archive with the binary, I
interpret clause 6(d) to mean that if the GnuTLS binary is available
at

    http://www.gnu.org/projects/emacs/w32/contrib/gnutls-999.zip

the GnuTLS source can be at

    http://www.gnu.org/projects/emacs/w32/contrib/gnutls-999-src.zip

or similar.  No explicit URI needed. :-)

Or you can provide a README-GnuTLS-source.txt or similar at

    http://www.gnu.org/projects/emacs/w32/contrib/README-GnuTLS-source.txt

that gives an arbitrary URL.  See my other post for why clauses 6(a),
6(b), 6(c), and 6(e) don't apply here.

Re: Emacs 23.4 Updated Windows Binaries published

[Lennart Borgman]

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

Re: Emacs 23.4 Updated Windows Binaries published

[Stephen J. Turnbull]

Lennart Borgman writes:

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

You may be right.  At least, by "same place" I mean "via relative
URI", and I've always read 6(d) that way, but that's clearly my
mistake since it does refer to textual instructions.

The question about a third party's sources, though, I think there's
some ambiguity there.  "You" are required to provide and ensure
availability of the sources; I've always interpreted that as meaning
you need to have access to the server where the archive is hosted, and
the phrase about "operated by a third party" is intended to avoid the
excessive burden (for most folks) of maintaining a host.  Rather, you
can use Savannah or SourceForge, as long as you do the work of
maintaining the copy.

If the intent is in fact to allow a third party's copy to be used, ok,
you're technically right.  But I would consider the necessary legal
arrangements to be prohibitively expensive, compared to a rental
server or a project on Savannah or SourceForge.

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

Yes.  But this isn't that hard; you would use some kind of universal
ID, like the bzr revid (not revno).

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

Sure, that would certainly satisfy the "equivalent copying" requirement.

Re: Emacs 23.4 Updated Windows Binaries published

[Lennart Borgman]

On Mon, Feb 6, 2012 at 18:01, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Lennart Borgman writes:
>
>  > 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.
>
> You may be right.  At least, by "same place" I mean "via relative
> URI", and I've always read 6(d) that way, but that's clearly my
> mistake since it does refer to textual instructions.

Ok.

>  > 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.
>
> Yes.  But this isn't that hard; you would use some kind of universal
> ID, like the bzr revid (not revno).

Yes, that was what I had in mind.

>  > 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.
>
> Sure, that would certainly satisfy the "equivalent copying" requirement.

Then I think we agree.

Re: Emacs 23.4 Updated Windows Binaries published

[Richard Stallman]

What is DOI?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Emacs 23.4 Updated Windows Binaries published

[Lennart Borgman]

On Tue, Feb 7, 2012 at 10:53, Richard Stallman <rms@gnu.org> wrote:
> What is DOI?

See http://www.doi.org/ :

    The Digital Object Identifier (DOI®) System is for identifying
    content objects in the digital environment. DOI® names
    are assigned to any entity for use on digital networks. They
    are used to provide current information, including where
    they (or information about them) can be found on the Internet.
    Information about a digital object may change over time,
    including where to find it, but its DOI name will not change.

    The DOI System provides a framework for persistent
    identification, managing intellectual content, managing
    metadata, linking customers with content suppliers,
    facilitating electronic commerce, and enabling automated
    management of media. DOI names can be used for any
    form of management of any data, whether commercial
    or non-commercial.

    The DOI System is an ISO International Standard.

But when I mentioned DOI it was the idea I was thinking of.

Re: Emacs 23.4 Updated Windows Binaries published

[Paul Eggert]

On 02/07/2012 01:53 AM, Richard Stallman wrote:
> What is DOI?

It's an alternative to URLs, which is supposed to be more
stable than URLs.  For example, a DOI to a paper published in 2002
is still supposed to work, even if the paper's publisher
has moved or has changed their website.  In practice, I've
found that DOIs are more stable than ordinary URLs, but they
still don't always work; my guess is that publishers occasionally
go bankrupt or stop paying the DOI clearinghouse or whatever.

Here's a DOI:

10.1007/978-3-642-24418-6_13

You can convert it to a URL like this:

http://dx.doi.org/10.1007/978-3-642-24418-6_13

This points to the following paper:

Bergquist M, Ljungberg L, Rolandsson B.
A Historical Account of the Value of Free and Open Source Software: From Software Commune to Commercial Commons.
IFIP Advances in Information and Communication Technology 365/2011, 196-207