9

I want to use this library in my project. Author says it is under the LGPL license, but one of its dependencies is under the EUPL license.

EUPL license isn't clear about if a closed-source application that uses the libraries inherits the EUPL license. What I understood so far is the following:

  • LGPL licence is compatible with EUPL license, so a library under LGPL license that uses another library under EUPL can be used for a closed-source commercial product.
  • It is not mandatory to put a derived product under the EUPL license if it uses a library under the EUPL license (despite it mentions that Copyleft stuff).

References I read:

In short: Can I use a library under the EUPL license for my closed-source commercial product?

  • 1
    You appear to be asking two different questions: 1) Can I use library X which is LGPL'd (and has an EUPL dependency)? 2) Can I use library Y which is EUPL'd? Those probably have different answers, so which one are you more interested in? – Ixrec Aug 5 '15 at 23:20
  • 1
    Why don't you read the actual license? The terms seem clear enough. joinup.ec.europa.eu/sites/default/files/eupl1.1.-licence-en.pdf ... In short, it appears to say that you must provide access to the source code of your work, in its entirety, when you distribute. – Robert Harvey Aug 5 '15 at 23:39
  • From what I've read so far, it seems like the only unclear part is at what point your work and the EUPL'd work count as a single work rather than two works that happen to interact. The LGPL is also unclear on this, but with the LGPL most people (probably correctly) assume that dynamic linking means separate works. I suspect the same criterion would be reasonable for dealing with the EUPL. – Ixrec Aug 5 '15 at 23:46
  • @RobertHarvey I read it and I found it rather confusing. It mentions compatibility with other licenses like GPL, and version 1.2 is compatible with LGPL. EUPL licesnse says that the library can be use in any way, but the dereived work must have its code published. But my app will use an intermediate library under LGPL, that depends on a library under EUPL. That's my confusion: LGPL allows me to use that library for closed-source projects, but the EUPL doesn't. – Broken_Window Aug 6 '15 at 13:50
  • 1
    @Ixrec my problem is tha tI'm dealing with two licences: a librry under EUPL that is used by a library under LGPL, and my app that will use the library under LGPL.That's my confusion: LGPL allows me to use that library for closed-source projects, but the EUPL doesn't. – Broken_Window Aug 6 '15 at 13:52
5

The answer to your question turns on that hardy perennial favorite dilemma: aggregation versus derivation. The 'intermediate-ness' of the intermediate library doesn't matter. The reason it doesn't matter is that the question is asked about the work, as a whole. I do not believe that anyone thinks that the precise order and arrangement of the call graph is important; what matters is what people think about dynamic linking. From the standpoint of, well, ldd, the EUPL library is linked into your work. Either that triggers obligations or it doesn't.

Thus, what matter is what (a) the copyright holder, and (b) a court, thinks of this. The FSF, authors of the GPL, see all dynamic linking as resulting in a derived work and thus source distribution obligations. What do the authors of the EUPL think?

If you believe Wikipedia, the dynamic linking situation of the EUPL is completely up in the air, subject to the legal breezes of each individual jurisdiction. So we have even less 'principle' to apply to predicting the legal view of dynamic linkage with an EUPL license than we do with the GPL.

Really, your best best is to ask the copyright holder of the library for her or his view of dynamic linkage. If the copyright holder gives you permission, you're good. If not, whatever anyone else thinks of the EUPL and dynamic linkage, you might be on the wrong end of a legal action.

| improve this answer | |
  • thanks for the explanation. I forgot to mention, I'm in a country in South America, not in Europe! and the EUPL says that the permissions may change from country to country because of law. – Broken_Window Aug 10 '15 at 13:44
4

Is EUPL alone compatible with proprietary softwares?

Short answer: Yes, you can use an EUPL library in your proprietary application.

There are lots of information about this topic on the official website of the European Union:

It all says: virality does not exist legally in Europe, even for the GPLv3 or AGPLv3. And you are bound to the EU law for the code corresponding to EUPL. Here are some slides from Patrice-Emmanuel Schmitz, a lawyer that participated in drafting EUPL, where he clearly question the legality of "strong" copyleft licenses in Europe.

(To be fair, there is a debate around this, as the lawyers of FSF Europe does not really agree with that. Can't find the link about this anymore though. You can find cases where the GNU GPL seems to have been successfully enforced in Germany.)

While the FSF wishes there is virality and tries to enforce it as much as they can with their own GNU licenses, the EU did not intend that in any way. The EUPL is closer to the weak copyleft MPL or EPL in intention than to the GPL. And when it comes to licensing, the only person that may sue you is the copyright owners that initially released their software under the said license. Therefore, if they say it is not viral, especially on the official European Union website you can feel safe and use it.

There's a big misunderstanding with the EUPL, probably because of Google treatment of the license (they literally banned it without much explanations).

LGPL library that depends on an EUPL library: which license is applied to the combined work?

EUPL is a compatible copyleft license. What is "compatible about"? It means that you can combine a EUPL licensed software with a LGPL/GPL/AGPL/EPL/MPL software and the licensed of the third-party software will apply.

Example in your case: the library you want to depend on is licensed under LGPL and rely on an EUPL software. Therefore, EUPL somehow disappears and only LGPL applies. Don't get me wrong the initial library is still under EUPL, but as a whole, the two combined libraries can just be licensed under LGPL. It is very closed to dual licensing for the EUPL Library. As a consequence you can treat the library you depend on as a standard LGPL library. You don't need to care about its EUPL dependency.

Some links that may help:

So in your case, you only need to know whether you can link the LGPL library with your application. With LGPL, it comes down to dynamic vs static linking.

Side note on Free software (as in Freedom) vs open-source

I noticed you seem to confuse "commercial", "proprietary", "open-source", "free software" and "closed-source". This article is a good read to get your head straight about all these terms and know what you can and cannot do. Disclaimer: I am biased, I wrote it myself.

In short, LGPL is incompatible with proprietary softwares to some extent. LGPL is not incompatible with commercial products. LGPL softwares can be sold for a price. Proprietary softwares are not necessarily closed-source: they can be made "source-available". A free software can be closed-source, as "not available online for the general public". A free software source code is always available to the people to which it has been distributed to, that's all.

Open-Source refers to any software that is distributed under a license approved by the Open Source Initiative. Closed-source is strictly defined as opposed to Open-Source, but can also mean: "not available online for the general public".

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.