7

For a new OSS project, I came across the AGPL 3.0 license ("GNU Affero General Public License 3.0") for the first time, and I'm a little unsettled now as to what license I should (and legally can) choose for my project.

Just for background, my project uses both the iText 7 PDF library (AGPL 3.0), as well as the Flying Saucer iText 5 renderer (itself LGPL 2.1), which internally uses iText 5 (again AGPL 3.0). My project also uses additional libraries licensed under ASL 2.0, EPL 2.0, and BSD 2-clause licenses.

From this question I gather that my project needs to be licensed under AGPL 3.0 because it uses AGPL-3.0-licensed code. However, that seems to be contradicted by the Flying Saucer iText 5 renderer using LGPL 2.1 while also utilizing AGPL-3.0-licensed libraries (unless their choice of license is incorrect/illegal, which I'm not really sure about what consequences that would have for my own project?!). Assuming that (from an AGPL 3.0 compatibility point of view), both AGPL 3.0 and LGPL 2.1 are an option, would either one raise incompatibilities with the ASL-, EPL-, and BSD-licensed libraries that I'm using?

In short, my question is: how do I determine what license options I have for a project that uses libraries licensed under AGPL 3.0, LGPL 2.1, ASL 2.0, EPL 2.0, and BSD 2-clause?

(I don't expect anyone to do my work for me, I'm happy to do the necessary research if someone could just point me towards how I would go about that in the first place)

1
  • 1
    The iText license is fundamentally and intrinsically problematic and directly causes these kinds of issues across the board from both closed source as well as FOSS perspective. This doesn't answer your question, but if it were me I would take absolutely every measure to remove the use of iText from your solution if at all possible. Apr 18 at 17:44

2 Answers 2

7

I'll assume that the FSF is right about linking to a library making a derivative work, and the consequences thereof. This isn't a settled question, and you can find more about it elsewhere on this site, but I'm going to assume it's so.

LGPLv2.1 doesn't impose any requirements on the licence for your code. It has some other requirements, but those would be met by licensing youyr code under AGPLv3. I had some worries about the onward conveyability of the result, but the FSF's compatibility matrix suggests that an LGPLv2 library can be used with GPLv3 code without having to "trapdoor" the library to GPLv3, so I think use with AGPLv3 will be comparably fine.

The BSD2 and Apache2 libraries will be fine.

Your biggest problem is the EPL2 library. According to the compatibility list, EPL2 code is only compatible with GPLv3 code if the EPL licensor offers the option of a secondary licence, and includes GPLv3 under that option; otherwise, they say, the licences are incompatible. So as I read it, unless you're really lucky, and the EPL2 licensor has designated AGPLv3 as a permissible secondary licence, you can't use that library as you propose.

You might try approaching the library's athor(s) and asking if they will so designate AGPLv3. You might well strike gold; EPL is a copyleft licence, so their aims are already likely to be aligned with yours. Otherwise, I fear you may need to do without that library.

4
  • Thanks for the comprehensive answer, @MadHatter. I had not anticipated that the EPL-licensed libraries would be the issue. Unfortunately, this poses a major problem in my case, because the EPL-licensed libraries happen to be the runtime libraries for the programming language that the project is written in (Xtend). Getting rid of these libraries means that the entire project will have to be rewritten in a different programming language...
    – raner
    Apr 17 at 6:11
  • Small follow-up question: since Apache 2.0 and BSD 2-clause libraries appear to be unproblematic, would it be a viable alternative to offer one of those licenses as secondary license for the libraries that are EPL?
    – raner
    Apr 17 at 6:47
  • 2
    @raner as I read EPL2, any licence offered as a secondary licence must be a copyleft licence, so no, they wouldn't do; moreover, it seems less likely to me that people who picked a copyleft licence would permit its replacement by a permissive licence than they would by a different copyleft licence. I'm trawling through the Xtend source in the hope of finding some kind of runtime licence exception, but have not yet succeeded.
    – MadHatter
    Apr 17 at 7:22
  • Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on Open Source Meta, or in Open Source Chat. Comments continuing discussion may be removed.
    – MadHatter
    Apr 18 at 9:46
6

MadHatter's answer pointed you to a roadblock in your project, based on license compatibility, or rather incompatibility, between EPL2 and AGPL.

There are options you can consider to overcome this 'situation' by removing a) the AGPL-licensed code or b) its copyleft implications.

  1. You could avoid the AGPL license of iText by choosing their commercial license program.
  2. You could try to replace the AGPL-licensed code by other code with a more permissive license. One thing that comes to mind is Apache PDFBox, but there might be other libraries that better fit your purpose and requirements.
  3. You could use a PDF-library, which is accessible through a command line interface or another loosely coupled connection, which will ensure that this code and your other code are considered an 'Aggregate'. In this case, independent of the license of the PDF library, the code of the rest of your project would not be impacted by any copyleft implications of the license of the PDF library. Such command-line tools might have to be installed independently from the other app, Ghostscript is a typical example for this category of software, available for some platforms.
1
  • 1
    Thanks for pointing out these alternatives, @Martin_in_AUT. You make a good point that there are other potential ways to resolve this situation. In my specific case, I have considered Apache PDFBox, and unfortunately it doesn’t work very well for my particular use case. Unfortunately, there is also no funding for obtaining a commercial iText license. I’m still exploring your suggestion #3, but it might be difficult since the entire code needs to run as part of a Maven build, and it’s difficult to ensure that packages like Ghostscript or pdftools will be available.
    – raner
    Apr 17 at 18:09

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.