Linking fbpdf against mupdf may be a copyright violation

[mgorny]

Disclaimer: IANAL, *GPL is horribly controversial and I might be wrong (but I don't think I am)

mupdf is licensed under AGPL terms. Per these terms, any program linking against it (either statically or dynamically), must also be released as AGPL. Releasing fbpdf under BSD is a violation of mupdf license. For this reason, Artifex could extort you or your users into buying a commercial mupdf license.

Now, I'm not sure how to fix it. The 'obvious' solution would be to license fbpdf separately as AGPL. However, I'm not sure if AGPL doesn't require covering other files in the package, particularly the Makefile. Since you have poppler-based fbpdf2, removing fbpdf or splitting it to a separate package may be a better option.

[aligrudi]

Disclaimer: IANAL, *GPL is horribly controversial and I might be wrong (but I don't think I am) mupdf is licensed under AGPL terms. Per these terms, any program linking against it (either statically *or* dynamically), must also be released as AGPL. Releasing fbpdf under BSD is a violation of mupdf license. For this reason, Artifex could extort you or *your users* into buying a commercial mupdf license. Now, I'm not sure how to fix it. The 'obvious' solution would be to license fbpdf separately as AGPL. However, I'm not sure if AGPL doesn't require covering other files in the package, particularly the Makefile. Since you have poppler-based fbpdf2, removing fbpdf or splitting it to a separate package may be a better option.

That is sad. Thanks for referring to this issue. I am not an expert in legal issues. Two questions: Is there any problem with releasing the source code (not the binary package) under ISC? Note that Fbpdf is under ISC now. Also, since Fbpdf uses ISC, can binary packages be released under another license like AGPL? If so, distributions can use such licenses to resolve the issue. Thanks, Ali

[mgorny]

Is there any problem with releasing the source code (not the binary package) under ISC? Note that Fbpdf is under ISC now.

To the best of my knowledge, yes. AGPL explicitly states that anything using it must be AGPL as well. There is some provision for using plain GPL but I'm not sure when or how it applies. Though I don't think AGPL vs GPL makes any real difference for you here.

Also, since Fbpdf uses ISC, can binary packages be released under another license like AGPL? If so, distributions can use such licenses to resolve the issue.

I'm not sure. Technically, I don't think there's a problem in distribution 'forking' this project to relicense it into AGPL. However, it's a bit unclear if you can really relicense something if you don't make any changes. From my experience, Gentoo licenses team has been reluctant to relicense stuff on our end, and instead preferred that licensing issues are resolved upstream.

[mgorny]

Maybe a bit more explanation is in place. The idea behind GPL/AGPL is that GPL-ed software must never ever be used in proprietary software. That's why these licenses require that anything forking, incorporating or linking to GPL libraries must also use the same license.

Now, permissive licenses such as BSD/ISC have no similar restriction. It is entirely permitted to fork fbpdf and release its modified version as a proprietary program. This is where a conflict arises. You could basically say that your license is giving your users right that you're not permitted to give because of the underlying license.

As I've said, I'm not a lawyer. I'm not sure if somebody can sue you for doing this. However, there is a real danger that an user (or distro packager) will miss the problem and assume this package is actually entirely fine as ISC, and eventually someone will fall into the trap of not meeting AGPL requirements somewhere.

What's even more worrying is that Artifex is one of the companies that offer commercial licenses in parallel to AGPL. This means that they do have an interest in selling commercial licenses to people who happened to violate AGPL.

[aligrudi]

Michał Górny<notifications@github.com> wrote:

To the best of my knowledge, yes. AGPL explicitly states that anything using it must be AGPL as well. There is some provision for using plain GPL but I'm not sure when or how it applies. Though I don't think AGPL vs GPL makes any real difference for you here.

As far as I can say, the executable that results from linking is considered a derivative work and not the source code. If, for instance, another implementation of mupdf API was available using a more permissive license, then linking with that library would have been no problem.

> Also, since Fbpdf uses ISC, can binary packages be released under another license like AGPL? If so, distributions can use such licenses to resolve the issue. I'm not sure. Technically, I don't think there's a problem in distribution 'forking' this project to relicense it into AGPL. However, it's a bit unclear if you can really relicense something if you don't make any changes. From my experience, Gentoo licenses team has been reluctant to relicense stuff on our end, and instead preferred that licensing issues are resolved upstream.

Maybe I can add a statement to mention that the code is dual-licensed? Ali

[aligrudi]

Michał Górny<notifications@github.com> wrote:

Maybe a bit more explanation is in place. The idea behind GPL/AGPL is that GPL-ed software must never ever be used in proprietary software. That's why these licenses require that anything forking, incorporating or linking to GPL libraries must also use the same license. Now, permissive licenses such as BSD/ISC have no similar restriction. It is entirely permitted to fork fbpdf and release its modified version as a proprietary program. This is where a conflict arises. You could basically say that your license is giving your users right that you're not permitted to give because of the underlying license. As I've said, I'm not a lawyer. I'm not sure if somebody can sue you for doing this. However, there is a real danger that an user (or distro packager) will miss the problem and assume this package is actually entirely fine as ISC, and eventually someone will fall into the trap of not meeting AGPL requirements somewhere.

OK. I shall add a statement to fbpdf.c. I do not want to include AGPL though. Just a note that binary packages linking fbpdf with mupdf can be released under AGPL. Any suggestions?

What's even more worrying is that Artifex is one of the companies that offer commercial licenses in parallel to AGPL. This means that they do have an interest in selling commercial licenses to people who happened to violate AGPL.

That is one reason I prefer not to use *GPL. Furthermore, if the license of such a library changes or a new implementation of its API is available with another license, then ISC would not limit the license of the resulting binaries. Thanks, Ali

[mgorny]

Well, your previous suggestion of dual-licensing makes sense to me. However, if you go that way, please make it explicitly clear that when linking to AGPL-licensed versions of mupdf (doubt any other will ever happen but sure) only AGPL is applicable.

Also, I'm pretty sure all GNU licenses require you to include the license with sources, and ask people to mail them if you don't. A common layout for this would to have two files, COPYING.ISC, COPYING.AGPL and an explanation in plain COPYING.

[mgorny]

I've done some research and I was wrong a bit. I'm sorry for that.

According to https://www.gnu.org/licenses/gpl-faq.en.html#IfLibraryIsGPL, it's fine to release all sources as ISC, and then only indicate that the final executable is AGPL (if it links to AGPL mupdf). Dual-licensing is not strictly necessary.

[aligrudi]

Michał Górny<notifications@github.com> wrote:

According to https://www.gnu.org/licenses/gpl-faq.en.html#IfLibraryIsGPL, it's fine to release all sources as ISC, and then only indicate that the final executable is AGPL (if it links to AGPL mupdf). Dual-licensing is not strictly necessary.

That is good news. Thanks, Ali