You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 14, 2020. It is now read-only.
It's great that parts of the libu2f-host package are now LGPLv2 licensed. However, other parts are still GPLv3, and the only way to tell which is which is checking the license headers in individual source files. Having a package with per-file licensing is very confusing and error-prone.
The ideal solution would be splitting into two packages, each with a single license. Then organizations that cannot use GPLv3 code could import the LGPLv2 code with no fear of accidentally using the wrong file and causing legal problems.
The text was updated successfully, but these errors were encountered:
I think this makes good points. Our current thinking is to re-license everything to LGPLv2 but we have some internal hoops to jump through to get there.
@klali: in general, e.g. Debian does not consider the build system "a part of" the package, in any case, the build system is not included in the output of the build. So I think it would be helpful to clarify that the project is LGPLv2.1+ as a whole, to avoid confusion.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It's great that parts of the libu2f-host package are now LGPLv2 licensed. However, other parts are still GPLv3, and the only way to tell which is which is checking the license headers in individual source files. Having a package with per-file licensing is very confusing and error-prone.
The ideal solution would be splitting into two packages, each with a single license. Then organizations that cannot use GPLv3 code could import the LGPLv2 code with no fear of accidentally using the wrong file and causing legal problems.
The text was updated successfully, but these errors were encountered: