License upgrade to support GPL'ed projects

[rapgro]

You wrote in an older thread:

Something like GPL would not have allowed for that, but EPL seemed to fit the bill.

https://groups.google.com/forum/#!msg/asyncssh-users/lS8FlyxSVEo/MZrBpNMK_AUJ

The Eclipse project tries with EPL 2.0 to have better compatibility to projects licensed under GPL and recommends to upgrade all parts.
Please consider to upgrade as well because EPL 1.0 can be considered as EOL.
https://www.eclipse.org/legal/epl-2.0/faq.php#h.60mjudroo8e5

Further:
"You must re-license to EPL-2.0 adding GPL Compatibility as per Exhibit A."
but not always needed for LGPL.
https://www.eclipse.org/legal/epl-2.0/faq.php#h.r4jspab0hx2c
https://www.eclipse.org/legal/epl-2.0/faq.php#h.hsnsfg4e0htq

"a project can use the new version by simply updating the file headers and notices. […] You must gain permission from all copyright holders to re-license the content"
https://www.eclipse.org/legal/epl-2.0/faq.php#h.tci84nlsqpgw
https://www.eclipse.org/legal/epl-2.0/faq.php#h.cktcxkzh8ks4

Asking in behalf of the package review for Fedora.
https://bugzilla.redhat.com/show_bug.cgi?id=1611828#c11

[ronf]

Just to be clear, is Fedora specifically asking not only for EPL-2.0 here, but also for the clause listing GPL 2.0 as an allowed secondary license? I'm happy to look into this, but a few questions come to mind:

• In some of the other examples I was able to find online, there were a couple of common variants of this. Specifically, I found references to "GNU General Public License, version 2 with the GNU Classpath Exception" (https://www.gnu.org/software/classpath/license.html) and "GNU General Public License, version 2 with OpenJDK Assembly Exception" (http://openjdk.java.net/legal/assembly-exception.html). Are either or both of these being requested? I'm fairly sure that the assembly exception wouldn't apply at all since AsyncSSH is written in Python, not Java, but I'm less clear on the class path exception. The terminology there is Java-specific, but the concept of linking against other independent modules could potentially apply.

• Do you know of any other example of open source Python packages which have been re-licensed under EPL-2.0 with any form of GPL secondary license that I could look at as a reference?

[gsauthof]

Just to clarify. Both EPL 1.0 EPL 2.0 (with/or without secondary license) are considered good licenses by the Fedora legal team.

There are some good arguments for upgrading from EPL 1.0 to EPL 2.0, even without adding a secondary license. The good argument for going EPL 2.0 + secondary license is GPL compatibility, i.e. then also GPL projects could use asyncssh without issues. All these arguments aren't specific to packaging asyncssh for Fedora.

IANAL, but the openjdk assembly exception seems to be very specific tailored for openjdk and GPLv2.

The classpath exception looks more generic and has a similar effect to LGPL. That means if you add it then other projects may choose to use asyncssh under the GPL but this doesn't require GPL in the calling code. Perhaps this is more important in ecosystems (like opensource java) where there are already a lot of libraries that use GPL+classpath. That means: with the classpath exception asyncssh could be used by other Python code that is already licensed under GPL+classpath without any issues. However, there probably isn't much Python code licensed under GPL+classpath - if any.

I've searched github for EPL licensed Python packages and I just found very few that use the EPL license. And none that explicitly opted in to the secondary license clause.

After reading the FAQ/license closely, opting in to the secondary license can be done with a file header like this:

# Copyright (c) {date} {owner}[and others]
# 
# This program and the accompanying materials are made available under the
# terms of the Eclipse Public License 2.0 which is available at
# http://www.eclipse.org/legal/epl-2.0.
# 
# This Source Code may also be made available under the following
# Secondary Licenses when the conditions for such availability set forth in the
# Eclipse Public License, v. 2.0 are satisfied:
# GNU General Public License, Version 2.0, or any later versions of that license
#
# SPDX-License-Identifier: EPL-2.0 OR GPL-2.0-or-later

See also the SPDX page on EPL 2.0 on the representation of the secondary clause in such identifieres.

Edit (2018-08-14): Accidentally copy'n'pasted the wrong SPDX identifier (GPL-2.0-only) which doesn't match the EPL 'Exhibit A' text. Fixed it now.

[rapgro]

Additionally to say, the FAQ for promotion of EPL 2.0 explicitly mentions Javascript (and other scripting languages). Python code might be also considered as scripting.
https://www.eclipse.org/legal/epl-2.0/faq.php#h.a0eux401qus

[ronf]

Thanks. I've created issue #162 to track this change, requesting that other contributors to the code provide their consent.

[gsauthof]

I've updated my header example - I replaced the wrong SPDX identifier. I previously used GPL-2.0-only just by accident - it wouldn't make any sense alone for practical reasons - and, the EPL 2.0 text only allows for GPL-2.0-or-later, anyways.

[ronf]

This change is now in the "develop" branch via commit 0b6eb7a. I'll be moving it to master and cutting the 1.14.0 release with this in the next few days.

[ronf]

These changes are now available in AsyncSSH 1.14.0.