Re: Packages, release notes, etc

Re: Packages, release notes, etc

[Tassilo Horn]

Michael Welle <mwe012008@gmx.net> writes:

Hi Michael,

> I have noticed that a lot of packages (at the least of the packages I
> have installed) come without release notes, the explicit copyright
> notice and all the other 'meta data'. Is there some kind of consensus
> on how that should be handled or is it just the way it is?

The documentation in (info "(elisp)Library Headers") suggests that each
elisp file should have the following header:

,----
|      ;;; foo.el --- Support for the Foo programming language
| 
|      ;; Copyright (C) 2010-2015 Your Name
| 
|      ;; Author: Your Name <yourname@example.com>
|      ;; Maintainer: Someone Else <someone@example.com>
|      ;; Created: 14 Jul 2010
|      ;; Keywords: languages
|      ;; Homepage: http://example.com/foo
| 
|      ;; This file is not part of GNU Emacs.
| 
|      ;; This file is free software…
|      …
|      ;; along with this file.  If not, see <http://www.gnu.org/licenses/>.
`----

So in general, metadata such as copyright notice, author, maintainer,
and homepage should always be available no matter how a package is
distributed, e.g., just from SCM, via tarballs, or via the emacs package
manager.

With respect to license, I think it is not even possible for an emacs
package to have a license different than GPL version 3 or later.  Each
package is a combined work of emacs + X so the emacs license extends to
the package.  That's probably the reason why there's no special License
field in the standard headers.

Things like a ChangeLog or release notes are optional and up to the
package maintainer.  Some packages have them either in separate files,
in their info documentation, or included as comment in the package's
main file.

I think that the above conventions are strictly enforced at least for
all packages from the official GNU ELPA package archive but there might
be packages from MELPA or Marmalade which are lacking this metadata.
I'd report a lack of the standard headers as a bug to the bugtracker of
the respective package.

Bye,
Tassilo

Re: Packages, release notes, etc

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Sep 10, 2015 at 12:11:03PM +0200, Michael Welle wrote:
> Hello,
> 
> Tassilo Horn <tsdh@gnu.org> writes:

[...]

> > With respect to license, I think it is not even possible for an emacs
> > package to have a license different than GPL version 3 or later.  Each
> > package is a combined work of emacs + X so the emacs license extends to
> > the package.  That's probably the reason why there's no special License
> > field in the standard headers.
> Hm, so it isn't possible to distribute a package that is in the public
> domain or maybe one that is Artistic ver. 2.0 licensed via ELPA or one of
> the other repositories? I doubt that.

This looks strange to me too. Tassilo: are you sure you didn't mean
"...to have a license incompatible than GPLV3 [or later]"?

Of course, the "or later" is the hard part here. How do we know that
Apache V2 is compatible with yet-to-know GPLV4?

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlXxXBcACgkQBcgs9XrR2kYQAwCfUA848q3U8f94cRkbTVmdLRUB
T4gAn3tikeeglwYdNBvfsUjmwfhWkKAy
=6pnd
-----END PGP SIGNATURE-----

Re: Packages, release notes, etc

[Tassilo Horn]

[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]

<tomas@tuxteam.de> writes:

>> > With respect to license, I think it is not even possible for an
>> > emacs package to have a license different than GPL version 3 or
>> > later.  Each package is a combined work of emacs + X so the emacs
>> > license extends to the package.  That's probably the reason why
>> > there's no special License field in the standard headers.
>> Hm, so it isn't possible to distribute a package that is in the
>> public domain or maybe one that is Artistic ver. 2.0 licensed via
>> ELPA or one of the other repositories? I doubt that.
>
> This looks strange to me too. Tassilo: are you sure you didn't mean
> "...to have a license incompatible than GPLV3 [or later]"?

No, I've meant what I said.  You can write a GPL program and thereby use
other libraries with GPL-compatible licenses.  But as soon as you use a
GPL library in your program, that program must also be GPL.  That's why
the GPL is called a copyleft license.

Well, I'm actually not absolutely certain that it must be exactly GPL
but at least its license must ensure the very same freedoms the GPL
ensures.  So "must be GPL" should be correct at least for practical
terms.

> Of course, the "or later" is the hard part here.  How do we know that
> Apache V2 is compatible with yet-to-know GPLV4?

Even if I'm right which I think I am, that's indeed a good question.
I'd say my elisp package X must be licensed at least under the GPL
version which covers the minimum version of emacs which is required to
use the package.  So if my package only requires emacs 21, then I can
probably release it as GPLv2 (an no later).  Of course that would be a
bad decision as it would preclude others from building another package
on top of mine and other packages or recent versions of emacs.

Well, but here I'm just guessing.

Bye,
Tassilo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 212 bytes --]

Re: Packages, release notes, etc

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Sep 10, 2015 at 01:00:04PM +0200, Tassilo Horn wrote:
> <tomas@tuxteam.de> writes:
> 
> >> > With respect to license, I think it is not even possible for an
> >> > emacs package to have a license different than GPL version 3 or
> >> > later.  Each package is a combined work of emacs + X so the emacs
> >> > license extends to the package.  That's probably the reason why
> >> > there's no special License field in the standard headers.
> >> Hm, so it isn't possible to distribute a package that is in the
> >> public domain or maybe one that is Artistic ver. 2.0 licensed via
> >> ELPA or one of the other repositories? I doubt that.
> >
> > This looks strange to me too. Tassilo: are you sure you didn't mean
> > "...to have a license incompatible than GPLV3 [or later]"?
> 
> No, I've meant what I said.  You can write a GPL program and thereby use
> other libraries with GPL-compatible licenses.  But as soon as you use a
> GPL library in your program, that program must also be GPL.  That's why
> the GPL is called a copyleft license.

The question is of academic value anyway, since an Emacs extension
only makes sense together with Emacs or XEmacs, and both are GPL.

It's clear that the extension must be *at least* GPL compatible to
be of any value for the user. And then, distributing it in the context
of Emacs makes it *effectively* GPL. Perhaps it must be GPL, as you
say.

Not making it GPL (if at all legally possible) has only the value of
confusing the user, which I think we agree is not a positive value :-)

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlXxa5gACgkQBcgs9XrR2kYICACfTD+bijTHnsf36nXsHY3sUOVt
miEAnjjDbk1QfWTmWr8IgdxfOKQ5LhlV
=kVSD
-----END PGP SIGNATURE-----

Re: Packages, release notes, etc

[Alexis]

Tassilo Horn <tsdh@gnu.org> writes:

> Things like a ChangeLog or release notes are optional and up to the
> package maintainer.  Some packages have them either in separate files,
> in their info documentation, or included as comment in the package's
> main file.

Yes, in my packages i include a “;;; Commentary:” section at the start
of the main package file, containing Markdown within comments, that
`el2markdown`:

    https://github.com/Lindydancer/el2markdown

uses to generate the README.md file containing the package
documentation.


Alexis.

Re: Packages, release notes, etc

[Stefan Monnier]

> With respect to license, I think it is not even possible for an Emacs
> package to have a license different than GPL version 3 or later.

Not exactly: the license can be different from GPLv3+, but it should be
compatible with GPLv3+, indeed.


        Stefan

Re: Packages, release notes, etc

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> With respect to license, I think it is not even possible for an Emacs
>> package to have a license different than GPL version 3 or later.
>
> Not exactly: the license can be different from GPLv3+, but it should
> be compatible with GPLv3+, indeed.

But what's the purpose of the copyleft when I can release a derived work
basing on GPL code under a GPL-compatible license which has no copyleft
anymore, e.g., Apache License, Version 2.0?

Bye,
Tassilo

Re: Packages, release notes, etc

[Stefan Monnier]

>>> With respect to license, I think it is not even possible for an Emacs
>>> package to have a license different than GPL version 3 or later.
>> Not exactly: the license can be different from GPLv3+, but it should
>> be compatible with GPLv3+, indeed.
> But what's the purpose of the copyleft when I can release a derived work
> basing on GPL code under a GPL-compatible license which has no copyleft
> anymore, e.g., Apache License, Version 2.0?

You can't take existing GPL code and distribute it with an MIT
license, indeed.  But you can distribute the code *you* write with
an MIT license.

You have to use a license that's compatible with the GPL not because
it's a mere derivative of GPL'd code, but because that code can only
work by linking with GPL'd code.  IIUC this is a theory that hasn't been
tested in court.


        Stefan

Re: Packages, release notes, etc

[Joost Kremers]

Tassilo Horn wrote:
> But what's the purpose of the copyleft when I can release a derived work
> basing on GPL code under a GPL-compatible license which has no copyleft
> anymore, e.g., Apache License, Version 2.0?

But what's a derived work? IANAL but according to Wikipedia a derivative
wokr includes (a significant portion of) the original work. In that
view, Emacs plugins, are not derivative works.

IIUC the FSF argues that using a library in your program makes your
program a derivative work of that library. (It's why there's also an
LGPL.) In that view, something could be said for the argument that
plugins are derivative works, even though Emacs is strictly speaking
not a library.

If you say that Emacs is essentially a virtual machine, then plugins
written by third parties are not derivative works, I think. I mean,
Oracles JVM is GPL, but I doubt that means that every program running on
it must also be GPL. OTOH most Emacs plugins aren't just programs that
happen to run on the Emacs VM, they're extensions modifying or extending
the functionality of Emacs itself. (There are a few packages that I
would consider actual programs running on top of Emacs, such as Gnus,
mu4e, magit, etc. To me, those are intuitively different from a package
such as e.g., markdown-mode or hydra, but the line is difficult to draw.
I'm myself not sure on what side of the line I'd put org-mode, for
example.)

Anyway, what I'm trying to say is that it's not at all clear what the
legal status of Emacs packages is, and I'm pretty sure that if someone
were to publish a proprietary Emacs extension and the FSF would sue,
it'd be far from an open and shut case...


-- 
Joost Kremers                                   joostkremers@fastmail.fm
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: Packages, release notes, etc

[Pascal J. Bourguignon]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> With respect to license, I think it is not even possible for an Emacs
>>>> package to have a license different than GPL version 3 or later.
>>> Not exactly: the license can be different from GPLv3+, but it should
>>> be compatible with GPLv3+, indeed.
>> But what's the purpose of the copyleft when I can release a derived work
>> basing on GPL code under a GPL-compatible license which has no copyleft
>> anymore, e.g., Apache License, Version 2.0?
>
> You can't take existing GPL code and distribute it with an MIT
> license, indeed.  But you can distribute the code *you* write with
> an MIT license.
>
> You have to use a license that's compatible with the GPL not because
> it's a mere derivative of GPL'd code, but because that code can only
> work by linking with GPL'd code.  IIUC this is a theory that hasn't been
> tested in court.

Notice that what has been tested in court, is that a _translation_ is a
derived work, and subject to the copyright of the original copyright
holder.

And this is something that I would love to see tested in court, if
somebody took a GPL library written in, say lisp, translated it into
say C, and tried to distribute it under a different licence.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: Packages, release notes, etc

[Pascal J. Bourguignon]

Joost Kremers <joost.m.kremers@gmail.com> writes:

> Tassilo Horn wrote:
>> But what's the purpose of the copyleft when I can release a derived work
>> basing on GPL code under a GPL-compatible license which has no copyleft
>> anymore, e.g., Apache License, Version 2.0?
>
> But what's a derived work? IANAL but according to Wikipedia a derivative
> wokr includes (a significant portion of) the original work. In that
> view, Emacs plugins, are not derivative works.
>
> IIUC the FSF argues that using a library in your program makes your
> program a derivative work of that library. (It's why there's also an
> LGPL.) In that view, something could be said for the argument that
> plugins are derivative works, even though Emacs is strictly speaking
> not a library.
>
> If you say that Emacs is essentially a virtual machine, then plugins
> written by third parties are not derivative works, I think. I mean,
> Oracles JVM is GPL, but I doubt that means that every program running on
> it must also be GPL. OTOH most Emacs plugins aren't just programs that
> happen to run on the Emacs VM, they're extensions modifying or extending
> the functionality of Emacs itself. (There are a few packages that I
> would consider actual programs running on top of Emacs, such as Gnus,
> mu4e, magit, etc. To me, those are intuitively different from a package
> such as e.g., markdown-mode or hydra, but the line is difficult to draw.
> I'm myself not sure on what side of the line I'd put org-mode, for
> example.)
>
> Anyway, what I'm trying to say is that it's not at all clear what the
> legal status of Emacs packages is, and I'm pretty sure that if someone
> were to publish a proprietary Emacs extension and the FSF would sue,
> it'd be far from an open and shut case...

Indeed, and given that the legal analysis of the existing cases,
demonstrate that it all reduces to whether the judge considers to be in
presence of a derived work or not (nonwithstanding any technicalities
like linking, as I mentionned previously, a mere translation (in
literature) is considered derived work, I'm sure you could make the case
for source code too).

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: Packages, release notes, etc

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Sep 10, 2015 at 10:09:07PM +0200, Tassilo Horn wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >> With respect to license, I think it is not even possible for an Emacs
> >> package to have a license different than GPL version 3 or later.
> >
> > Not exactly: the license can be different from GPLv3+, but it should
> > be compatible with GPLv3+, indeed.
> 
> But what's the purpose of the copyleft when I can release a derived work
> basing on GPL code under a GPL-compatible license which has no copyleft
> anymore, e.g., Apache License, Version 2.0?

Now I get it: you say that writing Emacs Lisp code is automatically a
"derived work" of Emacs. Hm. I don't know what the general position
on that is. Is a program written in Perl a derived work of Perl?

Most certainly a grey area, that's why some packages (e.g. GCC and its
runtime companion library) go to some lengths to clarify those points
(in the case of GCC, a C program is explicitly not considered derived
work, although it includes headers and caters to interfaces). But if
you think of the recent spat between Oracle and Google wrt copyright
violation by using some Java interfaces... it seems that the lawyers
themselves don't know a priori how the judges are going to decide on
that.

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlXyZh4ACgkQBcgs9XrR2kbpawCfb5YGvqcp5JIRjLUQy7M/NGao
o6QAniLDAvAY7EYHQBdOjAO2q40CMPca
=1sE3
-----END PGP SIGNATURE-----

Re: Packages, release notes, etc

[Alan Schmitt]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

On 2015-09-11 04:12, "Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Notice that what has been tested in court, is that a _translation_ is a
> derived work, and subject to the copyright of the original copyright
> holder.
>
> And this is something that I would love to see tested in court, if
> somebody took a GPL library written in, say lisp, translated it into
> say C, and tried to distribute it under a different licence.

This is coming frighteningly close to licenses covering algorithms.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Last week athmospheric CO₂ average (Updated September 9, 2015, Mauna Loa Obs.):
377.86 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]