REQUEST: I want to start laying out information on the extensions that might be bundled with binary releases of Apache OpenOffice from the podling. Bundling is a special case of general extension handling and I wonder if an Extension-Support Plan might be the best place to gather material on the OOOUSERS wiki.
Does anyone have a different preference? I am developing material off-line now, and I'd like to know an appropriate place to put it. - Dennis FEW DETAILS There has been further discussion, mostly among Andrea, Sam Ruby, and myself, on LEGAL-117: <https://issues.apache.org/jira/browse/LEGAL-117>. While I believe the aggregation case should hold up, there is not likely to be much more resolution until after the end-of-year holidays. Meanwhile, I have been doing some forensic work into the writing aids that are likely the most-critical for proper handling and also assessment of the various license and IP clearance issues that arise. I want to put up an inventory of a couple of dict-NL[.oxt] structures so that it is clear what is involved and what may have to be dealt with (1) to accomplish arms-length aggregation and (2) ensuring that the various licenses that apply are honored. -----Original Message----- From: Andrea Pescetti [mailto:pesce...@openoffice.org] Sent: Sunday, December 04, 2011 09:39 To: ooo-dev@incubator.apache.org Subject: Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?) On 11/11/2011 Andrew Rist wrote: > On Nov 10, 2011, at 3:18 PM, Andrea Pescetti wrote: >> Excluding dictionaries from builds would result in confused/enraged >> users... > Do you have a proposal as to how we can handle this under Apache? The proposal is to apply the same rules that we had in place for OpenOffice.org: mere aggregation of dictionaries. > How do you suggest we produce an Apache compliant product that has all of > the features expected by our users? For libraries the removal/replacement will be necessary, so I have no suggestions other than going on with the current removal/replacement procedures. For dictionaries, if https://issues.apache.org/jira/browse/LEGAL-117 is accepted we will be able to retain the features with no effort. Regards, Andrea.
smime.p7s
Description: S/MIME cryptographic signature
