* Emacs 23.4 Updated Windows Binaries published
@ 2012-02-05 1:04 Christoph Scholtes
0 siblings, 0 replies; 27+ messages in thread
From: Christoph Scholtes @ 2012-02-05 1:04 UTC (permalink / raw
To: Emacs-Devel devel, help-emacs-windows
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
@ 2012-02-05 16:34 Angelo Graziosi
2012-02-05 16:52 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Angelo Graziosi @ 2012-02-05 16:34 UTC (permalink / raw
To: emacs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
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 19:10 ` Lennart Borgman
0 siblings, 2 replies; 27+ messages in thread
From: Eli Zaretskii @ 2012-02-05 16:52 UTC (permalink / raw
To: Angelo Graziosi; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-05 16:52 ` Eli Zaretskii
@ 2012-02-05 17:12 ` Angelo Graziosi
2012-02-05 17:23 ` Juanma Barranquero
2012-02-05 19:10 ` Lennart Borgman
1 sibling, 1 reply; 27+ messages in thread
From: Angelo Graziosi @ 2012-02-05 17:12 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-05 17:12 ` Angelo Graziosi
@ 2012-02-05 17:23 ` Juanma Barranquero
2012-02-06 5:09 ` Christoph Scholtes
0 siblings, 1 reply; 27+ messages in thread
From: Juanma Barranquero @ 2012-02-05 17:23 UTC (permalink / raw
To: Angelo Graziosi; +Cc: Eli Zaretskii, emacs-devel
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-05 16:52 ` Eli Zaretskii
2012-02-05 17:12 ` Angelo Graziosi
@ 2012-02-05 19:10 ` Lennart Borgman
2012-02-05 20:48 ` Eli Zaretskii
2012-02-06 3:46 ` Stephen J. Turnbull
1 sibling, 2 replies; 27+ messages in thread
From: Lennart Borgman @ 2012-02-05 19:10 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel, Angelo Graziosi
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-05 19:10 ` Lennart Borgman
@ 2012-02-05 20:48 ` Eli Zaretskii
2012-02-05 21:24 ` Lennart Borgman
2012-02-06 3:46 ` Stephen J. Turnbull
1 sibling, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2012-02-05 20:48 UTC (permalink / raw
To: Lennart Borgman; +Cc: emacs-devel, angelo.graziosi
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-05 20:48 ` Eli Zaretskii
@ 2012-02-05 21:24 ` Lennart Borgman
2012-02-06 4:01 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Lennart Borgman @ 2012-02-05 21:24 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel, angelo.graziosi
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-05 19:10 ` Lennart Borgman
2012-02-05 20:48 ` Eli Zaretskii
@ 2012-02-06 3:46 ` Stephen J. Turnbull
2012-02-06 4:15 ` Lennart Borgman
1 sibling, 1 reply; 27+ messages in thread
From: Stephen J. Turnbull @ 2012-02-06 3:46 UTC (permalink / raw
To: Lennart Borgman; +Cc: Eli Zaretskii, Angelo Graziosi, emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-05 21:24 ` Lennart Borgman
@ 2012-02-06 4:01 ` Eli Zaretskii
0 siblings, 0 replies; 27+ messages in thread
From: Eli Zaretskii @ 2012-02-06 4:01 UTC (permalink / raw
To: Lennart Borgman; +Cc: emacs-devel, angelo.graziosi
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-06 3:46 ` Stephen J. Turnbull
@ 2012-02-06 4:15 ` Lennart Borgman
2012-02-06 5:22 ` Stephen J. Turnbull
0 siblings, 1 reply; 27+ messages in thread
From: Lennart Borgman @ 2012-02-06 4:15 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: Eli Zaretskii, Angelo Graziosi, emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-05 17:23 ` Juanma Barranquero
@ 2012-02-06 5:09 ` Christoph Scholtes
0 siblings, 0 replies; 27+ messages in thread
From: Christoph Scholtes @ 2012-02-06 5:09 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Eli Zaretskii, emacs-devel, Angelo Graziosi
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-06 4:15 ` Lennart Borgman
@ 2012-02-06 5:22 ` Stephen J. Turnbull
2012-02-06 5:42 ` Lennart Borgman
0 siblings, 1 reply; 27+ messages in thread
From: Stephen J. Turnbull @ 2012-02-06 5:22 UTC (permalink / raw
To: Lennart Borgman; +Cc: Eli Zaretskii, emacs-devel, Angelo Graziosi
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
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
0 siblings, 2 replies; 27+ messages in thread
From: Lennart Borgman @ 2012-02-06 5:42 UTC (permalink / raw
To: Stephen J. Turnbull, Richard M. Stallman
Cc: Eli Zaretskii, emacs-devel, Angelo Graziosi
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-06 5:42 ` Lennart Borgman
@ 2012-02-06 6:26 ` Paul Eggert
2012-02-06 7:12 ` Stephen J. Turnbull
1 sibling, 0 replies; 27+ messages in thread
From: Paul Eggert @ 2012-02-06 6:26 UTC (permalink / raw
To: Lennart Borgman
Cc: Stephen J. Turnbull, Angelo Graziosi, Eli Zaretskii,
Richard M. Stallman, emacs-devel
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>.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
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:47 ` Lennart Borgman
1 sibling, 2 replies; 27+ messages in thread
From: Stephen J. Turnbull @ 2012-02-06 7:12 UTC (permalink / raw
To: Lennart Borgman
Cc: Eli Zaretskii, Angelo Graziosi, Richard M. Stallman, emacs-devel
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).
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
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 13:47 ` Lennart Borgman
1 sibling, 1 reply; 27+ messages in thread
From: Stephen J. Turnbull @ 2012-02-06 7:46 UTC (permalink / raw
To: Lennart Borgman, Eli Zaretskii, Angelo Graziosi,
Richard M. Stallman, emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-06 7:12 ` Stephen J. Turnbull
2012-02-06 7:46 ` Stephen J. Turnbull
@ 2012-02-06 13:47 ` Lennart Borgman
2012-02-06 15:33 ` Stephen J. Turnbull
2012-02-07 9:53 ` Richard Stallman
1 sibling, 2 replies; 27+ messages in thread
From: Lennart Borgman @ 2012-02-06 13:47 UTC (permalink / raw
To: Stephen J. Turnbull
Cc: Eli Zaretskii, Angelo Graziosi, Richard M. Stallman, emacs-devel
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... ;-)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-06 7:46 ` Stephen J. Turnbull
@ 2012-02-06 13:49 ` Lennart Borgman
2012-02-06 15:46 ` Stephen J. Turnbull
0 siblings, 1 reply; 27+ messages in thread
From: Lennart Borgman @ 2012-02-06 13:49 UTC (permalink / raw
To: Stephen J. Turnbull
Cc: Eli Zaretskii, emacs-devel, Richard M. Stallman, Angelo Graziosi
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?)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-06 13:47 ` Lennart Borgman
@ 2012-02-06 15:33 ` Stephen J. Turnbull
2012-02-06 15:53 ` Lennart Borgman
2012-02-07 9:53 ` Richard Stallman
1 sibling, 1 reply; 27+ messages in thread
From: Stephen J. Turnbull @ 2012-02-06 15:33 UTC (permalink / raw
To: Lennart Borgman
Cc: Eli Zaretskii, emacs-devel, Richard M. Stallman, Angelo Graziosi
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-06 13:49 ` Lennart Borgman
@ 2012-02-06 15:46 ` Stephen J. Turnbull
0 siblings, 0 replies; 27+ messages in thread
From: Stephen J. Turnbull @ 2012-02-06 15:46 UTC (permalink / raw
To: Lennart Borgman
Cc: Eli Zaretskii, Angelo Graziosi, Richard M. Stallman, emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-06 15:33 ` Stephen J. Turnbull
@ 2012-02-06 15:53 ` Lennart Borgman
2012-02-06 17:01 ` Stephen J. Turnbull
0 siblings, 1 reply; 27+ messages in thread
From: Lennart Borgman @ 2012-02-06 15:53 UTC (permalink / raw
To: Stephen J. Turnbull
Cc: Eli Zaretskii, emacs-devel, Richard M. Stallman, Angelo Graziosi
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.)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-06 15:53 ` Lennart Borgman
@ 2012-02-06 17:01 ` Stephen J. Turnbull
2012-02-06 21:40 ` Lennart Borgman
0 siblings, 1 reply; 27+ messages in thread
From: Stephen J. Turnbull @ 2012-02-06 17:01 UTC (permalink / raw
To: Lennart Borgman
Cc: Eli Zaretskii, Angelo Graziosi, Richard M. Stallman, emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-06 17:01 ` Stephen J. Turnbull
@ 2012-02-06 21:40 ` Lennart Borgman
0 siblings, 0 replies; 27+ messages in thread
From: Lennart Borgman @ 2012-02-06 21:40 UTC (permalink / raw
To: Stephen J. Turnbull
Cc: Eli Zaretskii, Angelo Graziosi, Richard M. Stallman, emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-06 13:47 ` Lennart Borgman
2012-02-06 15:33 ` Stephen J. Turnbull
@ 2012-02-07 9:53 ` Richard Stallman
2012-02-07 13:31 ` Lennart Borgman
2012-02-07 15:57 ` Paul Eggert
1 sibling, 2 replies; 27+ messages in thread
From: Richard Stallman @ 2012-02-07 9:53 UTC (permalink / raw
To: Lennart Borgman; +Cc: stephen, angelo.graziosi, eliz, emacs-devel
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/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-07 9:53 ` Richard Stallman
@ 2012-02-07 13:31 ` Lennart Borgman
2012-02-07 15:57 ` Paul Eggert
1 sibling, 0 replies; 27+ messages in thread
From: Lennart Borgman @ 2012-02-07 13:31 UTC (permalink / raw
To: rms; +Cc: stephen, angelo.graziosi, eliz, emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Emacs 23.4 Updated Windows Binaries published
2012-02-07 9:53 ` Richard Stallman
2012-02-07 13:31 ` Lennart Borgman
@ 2012-02-07 15:57 ` Paul Eggert
1 sibling, 0 replies; 27+ messages in thread
From: Paul Eggert @ 2012-02-07 15:57 UTC (permalink / raw
To: rms; +Cc: stephen, emacs-devel, Lennart Borgman, eliz, angelo.graziosi
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
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2012-02-07 15:57 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.