www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LEGAL-117) Aggregation of GPL dictionaries with Apache OpenOffice (incubating) binary releases
Date Sun, 11 Dec 2011 07:27:40 GMT

    [ https://issues.apache.org/jira/browse/LEGAL-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13167060#comment-13167060

Dennis E. Hamilton commented on LEGAL-117:


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.


@Sam Ruby

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.
> Aggregation of GPL dictionaries with Apache OpenOffice (incubating) binary releases
> -----------------------------------------------------------------------------------
>                 Key: LEGAL-117
>                 URL: https://issues.apache.org/jira/browse/LEGAL-117
>             Project: Legal Discuss
>          Issue Type: Question
>            Reporter: Andrea Pescetti
> Localized versions of OpenOffice.org have traditionally included dictionaries (a term
used to designate data files for writing aids in general, like spell-checking dictionaries
and thesauri) under the GPL license. These dictionaries are provided in the form of data files.
> Dictionaries are not a dependency of OpenOffice.org: they are packaged, even in the installer
for native builds, as extensions. Any Windows version of OpenOffice.org is shipped as one
file, containing separate modules for OpenOffice.org and for each linguistic extension (i.e.,
the dictionaries).
> This is possible because OpenOffice.org dictionaries, as confirmed by the Free Software
Foundation in 2007 https://issues.apache.org/ooo/show_bug.cgi?id=65039 fall in the "mere aggregation"
provision of the GPL license http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
> The only remaining issue to be able to include GPL dictionaries in Apache OpenOffice
is thus the Apache policy http://www.apache.org/legal/resolved.html which forbids GPL software
from being included in Apache projects; but the rationale for this choice http://www.apache.org/licenses/GPL-compatibility.html
clearly states that "This licensing incompatibility applies only when some Apache project
software becomes a derivative work of some GPLv3 software", definitely not the case under
> In light of the above, can Apache OpenOffice include GPL spell-checking dictionaries
with its binary releases? 

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message