Bug#750643: antlr: missing licence for PyANTLR

Fri Jul 11 10:20:32 UTC 2014

Hi Debian, hi Thorsten,

(first of all, you are correct, let's continue in English).

>Grundsätzlich möchte ich jedoch die fehlende Lizenz ergänzen ohne viel
> >Aufwand zu erzeugen. Eine neue Antlr 2.x Version wird es wohl nicht geben,
> >bin nicht sicher ob ich das überhaupt könnte (technisch ja, rechtlich??).
> Hm. Im konkreten Fall würde ich trotzdem dazu raten, da der Rest von
> Antlr ja unter weniger restriktiven Bedingungen verfügbar ist.

Discussed this with the original author of Antlr. The lights are on red for
a new 2.7 release and I'm currently not willing to create a fork.

which is why the “LICENSE.txt” of Antlr itself does not
> work for you. (Side fact: it’s misnamed because PD means absence of
> the need for a licence.)

What file name does Debian then propose?

I urge you to choose a licence
> like the MIT or BSD one for it, to stay compatible to other libs
> that may be integrated into the same Java project.

Both are fine with me, so I would like to get going with BSD.

I think that, for Debian, all we need is a statement from you
> which licence(s) you choose for which parts.

>  • For Debian, please just state which licence(s) you choose for
>   1) antlr/actions/python/
>   2) lib/python/

My "statement" is then:

 o All source code packed with (1) is released in terms of the BSD software
license.

 p All source code packed with (2) is released in terms of the GPL software
license.

So, can you help me reformulate them so that they look proper and can be
used in an "official" statement?

Second, how shall I transmit this statement to Debian? There is a
"half-backed" website [1] - maintained by me -  where I could put those
license details.

[1] http://workbench.haefelinger.it/pyantlr

// Wolfgang

On Thu, Jul 10, 2014 at 4:04 PM, Thorsten Glaser <tg at mirbsd.de> wrote:

> Hi!
>
> More in the private reply to the private message…
> and a tl;dr at the end.
>
> wolfgang haefelinger dixit:
>
> >*That being said, I do not know why the antlr *.jar file includes the
> >Python code, as it does not need to.
>
> I have not understood this either, but in the current released
> version of Antlr 2.x it’s there.
>
> >If the antlr upstream distributes the
> >binary *.jar file with it, thiswill not be a problem.*
>
> Please define “this will not be a problem”…
>
> >This sentence is still confusing. It is a fact that antlr2-*.jar does not
> >contain *any* Python code. However, it contains the Java part of the
> >pyAntlr code generator plugin (path: antlr/actions/python/**). This code
> is
> >written by me, however, nowhere are the words "copyright" or "license"
> >mentioned.
>
> By Berne Convention, and thus also national law, this means it’s
> proprietary material of yours.
>
> >Therefore I conclude, that this code
> >is fully covered by LICENSE.txt listed in the root of antlr-*.tar.gz (or
> >other distributions listed at http://www.antlr2.org/download.html).
>
> The funny thing there is that “Public Domain” does not work for you.
> A German citizen is, by law, not permitted to wilfully relinquish
> copyright, which is why the “LICENSE.txt” of Antlr itself does not
> work for you. (Side fact: it’s misnamed because PD means absence of
> the need for a licence.)
>
> It would really be easier for everyone if Antlr itself would say,
> for example:
>
> “In countries where the Public Domain status of the work may not be
> valid, the authors grant a copyright licence to the general public to
> deal in the work without restriction and permission to sublicence
> derivates under the terms of any (OSI approved) Open Source licence.”
>
> Then you could just choose one or several Open Source licences for
> your parts.
>
> (GPL, while perfectly fine in itself and as your choice, will not
> work for the majority of the Java™ ecosystem: GPLv2 is not compatible
> with Apache v2; GPLv3 is but isn’t compatible with LGPLv2.x, and no
> GPL is complatible with CPL/EPL or *shudder* CDDL. Thus, most people
> dealing with Java™ will have to remove PyAntlr from it anyway.)
>
> For the binary JAR, only antlr/actions/python/ seems to be relevant.
> Due to the aforementioned reasons, I urge you to choose a licence
> like the MIT or BSD one for it, to stay compatible to other libs
> that may be integrated into the same Java project.
>
> >Thus there is a remaining Python part in "lib/python", part of the source
> >code distribution (http://www.antlr2.org/download/antlr-2.7.7.tar.gz).
> >Indeed, the license details are there in a bad shape.
>
> Right. This seems to be entirely separate, and not relevant for
> the JAR, so GPL is probably fine here, from a compatibility PoV.
>
> >My proposal to get rid of the problem is:
> >
> >(a) pyANTLR-*.jar   => The pyANTLR code generator plugin for Python
> written
> >in Java, depending on antlr-*.jar. Technically, this would be the
> >"antlr/actions/python/**"
> >part found in the antlr*.jar file
>
> This could be separate or stay in the normal Antlr JAR file.
> Both is fine either way, for Debian, it “just” needs a licence.
> If the licence is “liberal” enough (like BSD/MIT, or even
> “LGPLv2.1 or later” but I don’t know if this may not bite people
> with very unusual combinations), there is no need to separate it
> from the rest of Antlr, AFAICT.
>
> >(b) pyANTLR.zip    =>  The pyANTLR Python library. Technically, this would
> >be the "lib/python/**" part of antlr-*.tar.gz (or other source code
> >distribution) modified to have a proper license while otherwise unchanged.
>
> Since this is not part of the binary JAR in the Maven Central
> repository, this does not affect the part of me that writes
> this from the dayjob. Choose any licence you want here ;-) In
> fact, GPL is probably good here if you’re into copyleft.
>
> With a Debian Developer hat on, I can also just say that this
> needs a licence declared; any Open Source licence that is DFSG-free
> (which almost all of them are) will do.
>
> >You, Debian, you would then ignore (or wipe) the pyANTLR part of the
> >original antlr-2.* distribution and instead add at least (b) to your
> >system.
>
> I think that, for Debian, all we need is a statement from you
> which licence(s) you choose for which parts. Everything else
> is up to the package maintainers. Debian probably does not need
> to split, wipe, ignore, etc. anything then.
>
>
> Sorry for making this situation so complicated. I’m writing with
> two separate “hats” on, which both have a shared problem (absence
> of a licence). Only the “work” hat looks at the JAR in the Maven
> repository (and compatibility with the majority of the Java™ eco-
> system). The “Debian” hat looks at the source code, ignores all
> binary artefacts (Debian builds them by itself), and looks at
> licence compatibility only within Debian (which does ship such a
> large majority of the entire Open Source ecosystem that there is
> a saying “if it’s not in Debian it doesn’t exist”).
>
>
> So, tl;dr:
>
> • For Debian, please just state which licence(s) you choose for
>   1) antlr/actions/python/
>   2) lib/python/
>
>   They need not be the same.
>
> • For compatibility, I ask you to choose a permissive licence,
>   like MIT or BSD, for antlr/actions/python/ which is included
>   in the JAR file.
>
> • Let’s discuss Maven Central elsewhere, it does not pertain
>   to Debian. But resolving the above first will help.
>
> Thanks,
> //mirabilos
> --
> (gnutls can also be used, but if you are compiling lynx for your own use,
> there is no reason to consider using that package)
>         -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
>

-- 
Wolfgang Häfelinger
häfelinger IT - Applied Software Architecture
http://www.haefelinger.it
+49 1520 32 52 981
(+31 648 27 61 59)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20140711/667fe6b3/attachment-0001.html>