This is a great help. I have analyzed your downloadable dict-it.oxt Writing Aids extension. Nice work. (For those following along at home, the *.oxt file can be opened with a Zip utility. It is in a jar-like format that goes back to what appear to be pre-ODF times.)
It needs to be clear that we are talking about Writing Aids extensions. These are compilations that contain at least six files, typically, and can contain many more. (The dict-it.oxt that Andrea distributes contains 34 files). The parts may be individually licensed and the package itself may have an overall license. They are named as dictionary extensions but each such Native Language extension pachages several parts including a spelling dictionaries, thesauri, and hyphenation rules. For some languages, several variants are covered in the same dictionary extension. (English is this way with en-US, en-GB, en-ZA, all in one extension.)
Building on the original questions and the responses from Andrea Pescetti. All of the specifics are for Windows. Other platforms will vary:
1. Dictionary extensions incorporated in a binary release are installed into subfolders of the run-time configuration directly. Dictionary extensions obtained separately are in dic-<NL>.oxt packages that can be read by the run-time and expanded into folders that the run-time has access to.
Licensing is all over the place. The dictionary extension is itself a combined work and may have an extension-level license as well as notices of licenses of material that is employed. In addition, the individual parts may be subject to separate license conditions described in part-related README files and also in readable text of the part itself. There is generally no differentiation between source and non-source and whether or not what is provided is source (as defined by the GPL) or object. In many cases, it appears that this can be handled by cleaning up some wording and details in the many README files.
For English, French, Spanish, German, and Italian, I found GPL, LGPL, MPL, BSD, Princeton WordNet (BSD-like with a retention-of-title clause), LaTEX Project Public License, and a special COPYING-OASIS (having nothing to do with OASIS) that prohibited use with any product that does not have ODF as a native format. Finally, these all appear to be derivative works, and there are change logs and multiple copyright notices that reflect that.
2. It is clear that these are not editable by the run-time. The ones shipped as part of the binary-release installation are in places that are normally read-only to all but administrators.
3. Ones that are installed separately do not require administrator privileges to set up, but they are placed in "Application Data/" (a hidden folder name) and on a non-obvious path where the parent folder has a generated *.tmp/ name. The dictionary extension files themselves are not read-only, however. Still, there is no provision to modify them via the run-time and additions of further spellings are npt made to these dictionaries.
4. I agree that the README files and also extension-folder license notices provide ample indication that there are various licenses applicable to the extension and its components. I think there is adequate notice. The present README information is typical.
It appears that there is so much variability in how licensing arises in individual dictionary extensions, and in the content of the extensions themselves, that a simple question about GPL being applicable to a dictionary data file (actually, two files, *.dic and *.aff where it is difficult to know how either of them is a source for use together). is not necessarily going to provide the answer that is needed to deal with these cases.
I think the holiday pause can also be exploited to relook at the variety of dictionary-extension cases. It needs to be seen whether the cases can be reparsed into some small number of specific, concrete reusable practices. Then we can determine if ASF concerns are satisfied by what those might be.