libidn2 and Apache license compatibility
ojab opened this issue · 5 comments
JFYI deepfryed/idn-ruby#8
Thx for the report!
idnx interfaces via FFI with libidn2 and doesn't ship neither with source code nor the binaries, so I don't think this restriction applies. Or is there something I'm not seeing?
/shrug IANAL
AFAIK FFI is still counts as linking, which makes idnx [when using libidn2] derived work and Apache 2.0 can't be applied.
And while idnx doesn't bundle libidn2, any product shipping working solution (i. e. idnx + libidn2) under Apache 2.0 license would be in violation.
I'm struggling to parse this tbh.
I guess idnx complies with the "may not distribute" part, however "YOU MAY RELY ON THEM WHEN THEY SUPPORT AN OPTIONAL FEATURE" seems debatable, as libidn2 is indeed required under linux/mac to provide functionality.
I still believe that this would not be enforcable given that one won't be able to use idnx without externally installing libidn2 though. A workaround to this could perhaps be "bundling" a pure ruby punycode implementation, and offer it when libidn2 isn't available, which complies with "desirable level of quality". There's none supporting IDNA 2008, which is the whole point of idnx, but it'd at least be compliant.
WDYT?
Looks like a sensible solution, addressable has such fallback (not sure if it's intentional due to licensing concerns or due to binary ext ones, filled sporkmonger/addressable#432 for that).
Again IANAL, but IMHO it would be something like Apache 2.0 or LGPL-[2? 3?] if libidn is used anyway.
I don't think that a license upgrades if a sensible non-idn2 fallback is in place. It's just not a license conflict.