Bug#750643: antlr: missing licence for PyANTLR

[Thorsten Glaser]

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