Linking fbpdf against mupdf may be a copyright violation #10
Comments
|
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
|
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.
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 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. |
|
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
|
|
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
|
|
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, |
|
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. |
|
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
|
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.
The text was updated successfully, but these errors were encountered: