Dual licensing EPL 2.0/AGPL 3.0 for Xtend and Xbase runtime libraries?

[raner]

There are a number of open-source libraries that are licensed under the GNU Affero General Public License 3.0 (AGPL 3.0).
AGPL-3.0-licensed libraries require that any derivative software (i.e., software using such a library) be licensed under AGPL 3.0 itself. I just learned that EPL 2.0 is incompatible with AGPL 3.0, i.e. a project that uses EPL 2.0 libraries cannot be licensed under AGPL 3.0.
I've been told that the only way out of this conundrum is if the EPL-licensed libraries offer AGPL 3.0 as a secondary license.

Is this something that the Xtend and Xbase maintainers would consider?

I really have no idea if this is feasible and what's involved in it. In my case this means that an entire project might have to be rewritten in a language other than Xtend, since the project could only be licensed under AGPL 3.0 due to some of the libraries it needs.

[cdietrich]

@raner this is something you should ask the eclipse foundation first what is possible and what is not.
also which runtime libs you are referring to?

[cdietrich]

ping @raner

[waynebeaton]

I am not a lawyer and cannot give legal advice. If anybody wants legal advice, they must consult with their own lawyer.

I'm not as familiar with Eclipse Xtend as I probably should be, but my understanding is that Xtend generates regular Java content, and that generated Java code requires certain libraries to complie and run.

The Hello World sample, for example, requires InputOutput to compile and run. So, my understanding is that @raner would need to deploy this library (and possibly others) as part of an Xtend-based solution.

AFAICT, that library (and possibly others) is licensed EPL-2.0, which both the Eclipse Foundation and FSF believe is incompatible with (A)GPL, which is the problem that @raner needs to solve.

Is my assessment (so far) correct?

[raner]

Thanks for your response, @waynebeaton
Yes, your summary captures the situation accurately.
A possible solution, I'm told, would be to add AGPL as a secondary license to the affected library. As of version 2.0, EPL explicitly allows offering such a secondary license. Assuming that there aren't any legal obstacles, I'm trying to determine how I would go about requesting such a secondary license to be added.

@cdietrich the runtime libraries I'm referring to are:

org.eclipse.xtend:org.eclipse.xtend.lib.macro
org.eclipse.xtext:org.eclipse.xtext.xbase.lib

The latter depends on Google Guava, which is ASL2-licensed (not sure if and how this affects the feasibility of my request).

[cdietrich]

the problem is: i am not a lawyer neither
=> affects unclear. possibility unclear

am not sure if you can create a drop in replacements for these libs

[raner]

Where are all the lawyers when you need one? ;-)

Within the Eclipse Foundation, is there some sort of licensing contact person that could shed some light on this?

Also, does anyone know any sort of precedent where a previously EPL2-licensed library later added (A)GPL as a secondary license?

I found this thread, and while it's a bit difficult to follow, I interpret some of the statements to mean that adding a secondary license after the fact poses additional challenges (e.g., the libraries' contributors signed the ECA, so the expressly permitted their work to be distributed under EPL, but no such permission has been given for distribution under (A)GPL).

[waynebeaton]

I'm the licensing contact person for the Eclipse Foundation (but still not a lawyer).

Step one is to define the problem as well as possible. I think that I understand the problem space (at least in principle) well enough to describe it to my team here so that we sort out what options might be available.

Two runtime libraries have been identified. Are there more? @cdietrich can I reasonably assume that all of the "lib" bundles are runtime libraries? (e.g., should we add org.eclipse.xtend.lib.gwt to the list?)

By way of expectation management, it's not a simple matter of just adding a secondary license provision. Adding the secondary license is a license change. Changing a license requires that we (at least) get approval from all of the copyright holders of the affected content. The Eclipse Foundation is not the copyright holder.

I have some thoughts, but I need to do a bit more research and then check with my team before I make any suggestions. I'll try to have a response by early next week.

[raner]

@waynebeaton Thank you so much for looking into this!

[cdietrich]

The gwt things are replacements for the libs to be used in gwt context.
Thus my question: could the libs be reimplemented
Providing the same api

if you don’t use the active annotations in Xtend lib you should not need that neither or at least not at runtime

[raner]

@cdietrich Are you basically suggesting a clean-room reimplementation of the runtime libraries under AGPL license? I guess that would be another option. Probably tedious, but mostly straightforward? My code doesn't use active annotations, so I need the runtime libraries mostly for the extension classes (IterableExtensions, ListExtensions, ArrayExtensions, etc.).

[cdietrich]

@raner yes. if you dont use active annotations in a first step you should remove xtend.lib from your dependencies and use xbase.lib only.

as the current library uses guava unter the hood i dont know how how apache 2.0 and agpl work together anyway.

[waynebeaton]

Thanks for your patience.

Disclaimer: I am not a lawyer and nothing here should be considered legal advice. If you want legal advice, please contact your lawyer.

I see two possible solutions:

1. build a clean-room implementation of the required runtime libraries as suggested above; or
2. change the license on the existing runtime libraries (not the whole project, just those binaries).

In either case, I recommend applying a permissive license (a permissive license on the runtime libraries might help adoption in general).

Changing the license will require approval from all copyright holders.

If the project team wants to pursue a relicensing option, connect with the EMO and the team will help.

[raner]

@cdietrich Yes, you are correct, the library I'm talking about is org.eclipse.xtext.xbase.lib, sorry about the confusion there, too many similarly named libraries starting with an x... My understanding is that using Guava is not an issue, since Apache 2.0 does not stipulate that derived products need be licensed under any specific license.

@waynebeaton Yes, I think you've outlined the two viable options. I agree, that for a clean-room implementation it makes sense to choose a permissive license like Apache 2.0, not AGPL 3.0 (which would perpetuate the problem that derived products need to be licensed under the same license).
Changing the license to just the runtime libraries and not the entire project sounds like a good way to break this down into something more manageable. Here too, applying a permissive license sounds like the preferred approach, though I don't know how that would jive with the (weak) copyleft spirit of the EPL (i.e., my question is can the sources be covered by a copyleft license like EPL, and the binaries licensed under a permissive license?). At least, for the "secondary license" option that is offered by EPL 2.0 my understanding was that the secondary license would also have to be a copyleft license (e.g., GPL, AGPL), but I might be mistaken about that. Also, I believe you are talking about a different mechanism here (i.e., different licenses for sources and binaries, not generally adding a secondary license in addition to EPL).

In terms of going forward, realistically, I don't think I have the CPU cycles to spare to engage in a cleanroom rewrite of org.eclipse.xtext.xbase.lib any time soon (it seems entirely straightforward, but still a good amount of work). However, I'm happy to prepare pull requests to the Xbase lib project for any bulk changes in license headers, etc., if someone can outline to me what needs to be done (though, frankly, it sounds like the majority of the work necessary is not even about changes to the code).
I still think it's worth looking into this, as it would remove some barriers for projects that use (A)GPL libraries and are written in Xtend (which are pretty much non-starters, today).

For my project, I will probably have to make a decision within the next couple of months about how to go ahead. The current project written in Xtend cannot be published due to the inherent license conflicts/violations. My fallback solution is probably to switch the project to Kotlin (the code is written in a heavy functional style, so I need a language that has a concise lambda syntax, etc.; Kotlin runtime libraries are licensed under Apache 2.0).

[cdietrich]

I don't think I have the CPU cycles to spare to engage in a cleanroom rewrite of org.eclipse.xtext.xbase.lib any time soon

do you have the cycles for

Changing a license requires that we (at least) get approval from all of the copyright holders of the affected content.

as the future of Xtend is unclear anyway

My fallback solution is probably to switch the project to Kotlin

might be an option

you also might be able to write your xtend code in a way that xbase.lib is not used at runtime and test that with archunit as it is done in lsp4j

[waynebeaton]

A secondary license concept doesn't make sense in this case.

FWIW, per the EPL-2.0

“Secondary License” means either the GNU General Public License, Version 2.0, or any later versions of that license, including any exceptions or additional permissions as identified by the initial Contributor.

Besides, the effort to add a secondary license is the same as the effort required to just change the license.

I misused the word "binaries". What I meant was that we could consider relicensing the source for the runtime libraries (and--by extension--the binaries created from that source). This directory, for example: https://github.com/eclipse/xtext/tree/main/org.eclipse.xtend.lib

If the project team wants to consider that option, they should connect with the EMO for assistance.

[cdietrich]

sorry. i still dont understand what you are talking about and i have no lawer access.

we could consider relicensing the source for the runtime libraries

what does that mean

so i propose to stay as we are.

[cdietrich]

will close this for now