10:29 p.m.
Hi,
I guess this has been discussed before but I haven't been listening
carefully. The thing is that today I though I would bite the bullet
and try to merge in some GPLv3 or later code. To get the motivation
for the switch to GPLv3 or later up.
The code I was trying to use, and triggered this, was the go-mode
provided with the golang distribution. It depends on some stuff that
we don't have in XEmacs. From looking at the missing functions and
packages it doesn't seem to be all that hard to support it but...
...the likely place to put the missing functionality is in the
packages, such as xemacs-base. So it will not go into the core, (and
thus I fail in getting the motivation up, which is sad :-(, but except
for that...)
What to do here with the packages and GPLv3 or later code? Do we need
two versions of the packages? GPLv2 or later to go with 21.4 and GPLv3
or later to go with 21.5 and later? Or is it only an issue for
xemacs-base?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:33 p.m.
On Fri, Apr 8, 2011 at 3:29 PM, Mats Lidell <matsl(a)xemacs.org> wrote:
What to do here with the packages and GPLv3 or later code? Do we
need
two versions of the packages? GPLv2 or later to go with 21.4 and GPLv3
or later to go with 21.5 and later? Or is it only an issue for
xemacs-base?
And what do we do about packages that already have GPLv3 or later code in them?
See:
xemacs-packages/ediff/ediff*.el
xemacs-packages/games/sudoku.el
xemacs-packages/prog-modes/verilog-mode.el
xemacs-packages/viper/viper*.el
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:32 a.m.
Jerry James writes:
And what do we do about packages that already have GPLv3 or later
code in them?
We ignore them. Since I don't recall seeing GPLv3 notices go by on
xemacs-patches, The code was presumably added by the authors or their
delegates (ie, package maintainers), and that's tacit permission to
distribute. Even if you know otherwise, we should have a GPLv3
release soon enough to make the issue moot before anybody gets around
to complaining.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:24 a.m.
Mats Lidell writes:
What to do here with the packages and GPLv3 or later code?
My understanding of the law is that packages written to support both
Emacs and XEmacs are separate works, and can't infect XEmacs proper
with GPLv3. However, I don't know what the FSF thinks, and several
3rd party package maintainers refuse to update the XEmacs packages
until we are distributing a GPLv3 core. In many cases this is
unavoidable because they depend on unported features of Emacs 23 or 24.
Do we need two versions of the packages? GPLv2 or later to go with
21.4 and GPLv3 or later to go with 21.5 and later? Or is it only an
issue for xemacs-base?
It's not an issue for any package as far as I can see, once we start
distributing a GPLv3 version of XEmacs. Until then, there's the
question of whether the packages are a separate work from XEmacs core
or not. If they are, then there's no problem. If they aren't, and I
suspect that the party with more lawyers will take that position,
there's a big risk of harassment by the FSF.
Anyway, I've completed translating the ChangeLogs since 21.5.29 into
summaries (modulo a few commits in the last week, none of which will
be hard to add), and probably will finish turning the summaries into
useful text (there's lots of duplication and overlap, and over 600
entries) tomorrow or Monday, so there should be a last GPLv2 release
shortly.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:09 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Mats Lidell writes:
> What to do here with the packages and GPLv3 or later code?
My understanding of the law is that packages written to support both
Emacs and XEmacs are separate works, and can't infect XEmacs proper
with GPLv3.
Please don't use loaded verbiage like "infect".
If packages contain code that is only ever executed on XEmacs, for
example guarded by (if (featurep 'xemacs) ...), that particular code
does not appear separable in a meaningful way from XEmacs, unless one
considers _any_ optional code separate. Which is not the stance of the
FSF AFAICT. If the package runs on either Emacs or XEmacs without
requiring explicit checks, you are likely correct.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:33 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> It's not an issue for any package as far as I can see, once
Stephen> we start distributing a GPLv3 version of XEmacs.
But what about 21.4 and xemacs-base?
Stephen> Until then, there's the question of whether the packages are
Stephen> a separate work from XEmacs core or not. If they are, then
Stephen> there's no problem. If they aren't, and I suspect that the
Stephen> party with more lawyers will take that position, there's a
Stephen> big risk of harassment by the FSF.
So I should be able to upgrade Hyperbole in the packages to the GPLv3
or later version that I distribute from savannah then with out any
problem.
Stephen> [...] so there should be a last GPLv2 release shortly.
That is good news. I guess I can start my merging project after
all.. ;-)
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:35 a.m.
Mats Lidell writes:
But what about 21.4 and xemacs-base?
What about them? xemacs-base is a package, not part of the core.
XEmacs 21.4 is irrelevant at that point because it's historical.
So I should be able to upgrade Hyperbole in the packages to the
GPLv3
or later version that I distribute from savannah then with out any
problem.
As long as it works out of the box with a GPLv3 Emacsen, yes. (There
are some imaginable corner cases, but they're very unlikely.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:02 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> What about them? xemacs-base is a package, not part of the
Stephen> core. XEmacs 21.4 is irrelevant at that point because it's
Stephen> historical.
Well I just thought there would be some problem with merging in GPLv3
or later code in xemacs-base and still distribute 21.4 that really
needs it to be useful ... but I'd be happy if that is just my state of
licensing consequences confusion showing again ;-) And if 21.4 can be
viewed as historical I guess there can't be an issue with it.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:27 p.m.
Mats Lidell writes:
Well I just thought there would be some problem with merging in
GPLv3
or later code in xemacs-base and still distribute 21.4 that really
needs it to be useful
Since xemacs-base is distributed separately, it's up to the users to
download it and use it with 21.4. Nobody has a leg to stand on
complaining about that, as long as we don't fix bugs occasioned by
incompatibility of 21.4 with GPLv3 code. The problem if we don't
distribute a GPLv3 core is that the FSF can argue that the packages
are not a separate product, but rather part of a larger "real" XEmacs
product that actually is core + packages, and we're just distributing
them separately to avoid complying with the GPLv3 on the packages.
We might need to change the name of future sumos so that the name is
different from that documented in 21.4 INSTALL and perhaps any
packages that GPLv3 code in them. It would be something algorithmic
like appending "-to-avoid-fsf-lawuits" (Hi David! but more likely
"-gplv3") to package and/or sumo names, and 21.5 (but not 21.4) would
know to try those names first.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4975
days inactive
4977
days old
8 comments
4 participants
participants (4)
-
David Kastrup -
Jerry James -
Stephen J. Turnbull -
The XEmacs Package Smoketest