Closed Bug 716482 Opened 10 years ago Closed 9 years ago
Clarify licensing status of intl/hyphenation code
There are several files in intl/hyphenation/src which purport to pertain to and explain the licensing, but they refer to other files (e.g. hyphen.tex) which are not actually present. If we are now the maintainers of this code, we should standardise the license blocks to MPL-tri-license (and then MPL2), and add a README explaining the situation. If we are not the maintainers, there should be a README explaining who is. Either way, incorrect or inaccurate statements in existing files need updating. jkew: is this something you could take on? Gerv
jfkthame: ping? Gerv
(Sorry for the long delay here.) The relevant source code there would be the files hyphen.c and hyphen.h. These come directly from the version of the Hyphen library (libhnj) that is part of the hunspell project; see hg log intl/hyphenation/src/hyphen.*. As such, I don't consider that we are now maintaining this code; we're simply importing it from an upstream project. So I left the various README and COPYING files from upstream intact. (The other source files in that directory are Mozilla-originated code, so I updated them to MPL2.0 recently in bug 846732.) I agree the various README files, etc., leave things pretty confusing; this is in part because the hyphen code itself has a fairly complex history, reflected in the layers of comments that have been added to the README files over the years. ISTM we have a few options here: (a) We could add a new chunk at the beginning of the README file, explicitly stating which files it relates to, where they come from, etc. The downside of this is that README itself may get updated in new upstream releases, so we'd then need to merge our additions. (b) We could leave everything from upstream untouched, and add a README.mozilla file to provide that information (which is currently only really available from the hg log). (c) If the existing license terms allow it, we could declare that we're using this code purely under the MPL and re-license the files under MPL2.0. (Can we do that for something that was offered upstream under MPL1.0?) Then we could discard upstream's README, COPYING, etc. However, given that we're not actually modifying upstream's source files in any way, and would like to continue taking new versions when they're released, I'm hesitant to do this; leaving the files untouched seems better to me. Any preference or advice? I'm inclined towards (b), but would value your opinion.
jfkthame: yes, please do (b). Gerv
Something like this?
Attachment #731216 - Flags: review?(gerv)
Comment on attachment 731216 [details] [diff] [review] Clarify licensing status of intl/hyphenation code. Super. Thank you :-) Gerv
Attachment #731216 - Flags: review?(gerv) → review+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.