Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

heic2any violates libheif license #59

Open
farindk opened this issue Jun 21, 2024 · 2 comments
Open

heic2any violates libheif license #59

farindk opened this issue Jun 21, 2024 · 2 comments

Comments

@farindk
Copy link

farindk commented Jun 21, 2024

Hi,
I'm the libheif author on which your wrapper is based and I'm afraid that your wrapper code is violating the usage terms of libheif.
Libheif is released under the LGPL license. You have integrated the code compiled to JavaScript verbatim into your repository, and released that with the incompatible MIT license.
Moreover, there is no mention that your wrapper uses libheif (and libde265), which violates at least against section 4a) of the LGPL.

I am fine that you use libheif and provide a wrapper for it, but to be compliant, you have to do at least these two things:

  • Conform to section 3, 4, and 5 of the LGPL. In particular, place a prominent note that your code makes use of the libheif and libde265 libraries and include its licensing terms.
  • You also have to change your license from MIT to GPL as there is no way for the end user to replace libheif.
@zzzb123
Copy link

zzzb123 commented Aug 19, 2024

Another option (what I have seen most often) is to explicitly denote portions of the project that are transpiled from the LGPL codebase as LGPL (usually with a file header), and leave a note in your license that some files are licensed differently. From my understanding of the LGPL, you may also want to put a note on how the file was generated in there too.

Avoids the need to change your licensing, and should be compliant with the terms of the LGPL.

The LGPL makes mention of linking (separating into its own module/library in this case), but from my reading does not require it, instead only requiring clear separation from the code that is yours. File separation should be more than fine enough.

Replacement does not have to be done afree compilation if the project is open source (as this one is), so long as the user is able to replace it with their own variant. An open source build system like you already have and clear "generated by..." instructions on your bytecode version of libheif should cover that requirement if I am understanding correctly.

Please credit the authors of projects you borrow from. It's the right thing to do and (in this case) it's the law. Easiest way to do it is a folder in your repo containing the GPL and LGPL licenses, as well as a note in your README saying that libheif is used. I have also seen many projects adding a link to the LGPL under the usage note instead of the folder of licenses. Its not completely correct to my understanding, but close enough that I feel it to be in the spirit of the license terms.

Please feel free to correct me if any of this is incorrect.

@DavidBuchanan314
Copy link

DavidBuchanan314 commented Aug 19, 2024

if the project is open source (as this one is)

This one is, but if someone forked it, the MIT license would (in theory) allow them to keep their changes private. In practice, someone doing this would be violating libheif's license too, which is why heic2any should be GPL licensed if it wishes to use libheif in this way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants