#9466 closed license violation (invalid)
FFmpeg documentation saying libx265 is GPLv2 or later, libx265 is GPLv2 only?
Reported by: | Josef Andersson | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | documentation |
Version: | unspecified | Keywords: | |
Cc: | Josef Andersson | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug: Is the FFmpeg documentation regarding libx265 wrong? It implies that it is GPLv2 or later, but in reality it is GPLv2 only as far as I can read after looking at the project.
How to reproduce:
Read the documentation at https://www.ffmpeg.org/general.html#x265
and then the FAQ at https://www.x265.org/x265-licensing-faq/ and the project license itself.
Why does this matter? Following FFmpegs current advise (GPLv2 or later) one could be led to belivie that it is possible to create a distribution binary, including libx265 and release it under GPLv3, together with for example, codecs that are only GPLv3 ++ compatible, and not GPLv2 only compatible, allowing all kinds of compliance mess for the distributor. I hope I'm wrong, but otherwise the FFmpeg documentation should be corrected.
Change History (11)
follow-up: 2 comment:1 by , 3 years ago
comment:2 by , 3 years ago
Replying to Balling:
Are you being serious right now? https://softwareengineering.stackexchange.com/questions/238748/can-gpl-v2-code-link-to-an-lgpl-v3-library
I don't quite see the relevance of this SoftwareEngineering.SE link; could you elaborate further on your meaning? The answer there ("the effective license for the product becomes GPLv3") seems in agreement with the instructions in FFmpeg's documentation linked in the bug report ("you must upgrade FFmpeg's license to GPL in order to use [x265].")
The question here is whether you must (or may) follow that "must upgrade" directive by upgrading to the GPLv2 or GPLv3: the FFmpeg documentation says x265 is offered under the option of either GPLv2 or GPLv3, while the x265 site itself says they offer it only under the GPLv2.
comment:3 by , 3 years ago
Again, you cannot be serious, this is not derivative work, this is combined work. I.e. you can link GPL 2.0 stuff to GPL 3.0 stuff, but you cannot include code from GPL 2.0 in GPL 3.0 project. What we are using is a wrapper, but API interfaces are not copyrightable (technically LGPL that we use on that file will not work, so if somebody will sue over that file license violations he should lose) so it does not matter. https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx265.c
It would have been even more obvious were it a header file, but whatever. It also uses FFmpeg API, so have to be .c.
to belivie that it is possible to create a distribution binary, including libx265 and release it under GPLv3
It is possible.
There is no static linking exception though in GPL 2.0 used in x265. But in practice, the idea in very vague. Indeed, GPL prohibits static linking from non-GPL code to GPL code, but permits dynamic linking from non-GPL code to GPL code. In practice in the only case http://en.wikipedia.org/wiki/Galoob_v._Nintendo Court of Appeals ruled that derivative work "must incorporate a portion of the copyrighted work in some form". Which is not the case with true dynamic linking that thus happens on end-user system. Were x265 or x264 to use some ffmpeg structures, that would be different. There is strong separation consept. Anyway, that would be a problem with Intel Trade Secret code, but we have a GPL 2.0 with GPL 3.0.
comment:4 by , 3 years ago
Would it be fair to summarize your position as: the question of whether GPLv2 or v3 is sufficient to satisfy FFmpeg's documented instructions that you "must upgrade... to GPL" to use x265 is a moot question, because the document is altogether wrong to say such an upgrade is required.
Is it your position that that "must upgrade" language ought to be removed, or does it still serve some purpose even in light of your position about the separability of libx265 from FFmpeg? If it should be removed, that seems like the much more important resolution of this ticket (although correctly stating libx265 is GPLv2-only, not GPLv2+, will not hurt anything, either).
comment:5 by , 3 years ago
Or is it more correct to summarize your position as: yes, FFmpeg does need to be upgraded to GPLv2 to use libx265, but the particular scenario detailed in the ticket, wherein FFmpeg's status as GPLv2 interacts with a GPLv3 plugin, is not a problem. Other problematic scenarios may arise
from the mistaken idea that libx265 has a GPLv3 option (e.g., suppose I wanted to add GPLv3 code directly into an FFmpeg fork, then my use of GPLv2-only x265 option would indeed cause a conflict). Is my first or second reading of your position more correct?
follow-up: 7 comment:6 by , 3 years ago
But x265 is licensed as GPLv2+ https://bitbucket.org/multicoreware/x265_git/src/8003e43825ee83b8ef346c8c3562c508ab23f117/source/dynamicHDR10/BasicStructures.h#lines-10
project license itself.
There is no "or later" part in COPYING file. That is per code files in x265.
comment:7 by , 3 years ago
Replying to Balling:
But x265 is licensed as GPLv2+ https://bitbucket.org/multicoreware/x265_git/src/8003e43825ee83b8ef346c8c3562c508ab23f117/source/dynamicHDR10/BasicStructures.h#lines-10
project license itself.
There is no "or later" part in COPYING file. That is per code files in x265.
THAT is the answer I'm looking for. The source codes states it clearly. Thanks!! to you BOTH. For an interesting ( and a bit heated but hey...that how it goes with these things) discussion touching various topics that ended up leading to the answer. The FFmpeg documentation is CORRECT - however that "documentation for x265 could surely add a notice so one does not have to check the source files themselves. I'll add an improvement task there. This bug report can be closed. Thanks gentleman and have a great weekend.
comment:8 by , 3 years ago
For completeness, I'll leave an link to the issue I created https://bitbucket.org/multicoreware/x265_git/issues/607/license-faq-enchancement-suggestion
(And this report is no longer FFmpeg related at all, and from my point of view could be closed as resolved)
comment:9 by , 3 years ago
As a participant in this discussion, I'd also like to add that Balling's latest comment certainly resolves the matter (thanks!) and that Wikipedia's entry on x265 could also do with an update that it is GPLv2+ rather than GPLv2 only (in addition to x265's own website).
comment:11 by , 3 years ago
Great co-op!! We'll certainly spare someone a bit of confusion in the future!
Are you being serious right now? https://softwareengineering.stackexchange.com/questions/238748/can-gpl-v2-code-link-to-an-lgpl-v3-library