4

Our application currently has a licence which is not compatible with AGPL. We need to use a library licensed under AGPL (currently the best one for the job and the client would like us to use it).

We thought about creating a web service using this library and we would license it under AGPL. Our application would directly depend on it to function properly. We wanted to create two svn repositories, one for the main project and one for the web service AGPL. To install our application, one would need to retrieve the code from both repositories, compile and run the applications.

Does that count as a derivative work? Both source codes are open and publicly available. The main project needs to keep its license and cannot be licensed under AGPL.

The web service can work as-is. One can just use it without the other project, it is just kind of useless since the web service validates metadata with rules only valid for the main project. The web service has default config files valid only for the main project but they can all be replaced by something completely unrelated. The main problem is that the web service contains default files which make me think that it is potentially a derivative work and if my main project uses this web service, it will be forced to be AGPL to be able to use the web service.

Maybe that makes a different but the library AGPL is only used and not changed.

Does anybody have an idea if I can use this AGPL web service and keep my license on the main project? If that's not the case, I will need to create another web service with a compatible license and keep the AGPL web service for internal use only.

Improve this question
3

2 Answers 2

Reset to default
1

I assume a technical trick (like your web service idea) to avoid the intent of the license wouldn't work. But your assumption about compatibility is wrong.

The EUPL (you stated in your answer that that is the licence your project is under) has statements of compatibility that work with the AGPL:

  • EUPL v1.1 states compatibility to CeCILL v2.0, which states compatibility to GPL v2 or later and GPL v3 states compatibility to AGPL v3.
  • EUPL v1.2 states compatibility to AGPL v3.

You only need to comply with both licenses, not change your projects license.

If both EUPL and AGPL licensed code were distributed together a potential licensee may discard the AGPL code if they wish to only comply with the license of the rest of the code.

You may not convert AGPL to EUPL, i.e. you are not allowed to distribute a combination and tell your licensee only about the EUPL. The EUPL states how to do the conversion to other licenses via the compatibility mentioned above. What I called conversion here is an additional step that you don't need to do.

Improve this answer
2
  • Good morning. Thanks for the info. I used this matrix : joinup.ec.europa.eu/software/page/eupl/… I thought that AGPL v3 could use EUPL but not the opposite. The same way that any project can use Apache/MIT/BSD without having any problem.
    – ghgh
    Jun 1, 2017 at 5:50
  • Yes, you may not convert AGPL to EUPL, i.e. you are not allowed to distribute a combination and tell your licensee only about the EUPL. That is what the matrix in your link talks about. (I added this to the answer.)
    – Jan Zerebecki
    Jun 1, 2017 at 7:45
0

We ended up implementing our own things and license it with EUPL license so now we are good and we don't have to distribute any source code licensed under AGPL.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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