You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Pedro Giffuni <pf...@apache.org> on 2011/11/05 01:30:12 UTC
GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
Hi Andrea;
I have been looking at the situation of the dictionaries,
and particular the italian dictionary.
You are right that it will not be covered by the SGA.
Perhaps more worrying is that the italian dictionary is
the only dictionary under the GPL; most others are triple
licensed (LGPL/MPL/GPL).
We are not allowed to use it, so it will be removed
from the SVN server for sure. Beyond that ... well
I am not a lawyer and I don't have any idea how the
GPL could be enforced in this case, but things are
not nice.
Pedro.
--- On Fri, 11/4/11, Andrea Pescetti wrote:
> Marcus (OOo) wrote:
> > Am 11/04/2011 03:01 PM, schrieb Rob Weir:
> >> Did we lose the ftp site as well? ...
> >> I don't know how widely that was used, but it
> seems to have been where
> >> many of the NL spell checking dictionaries were
> stored:
> > Many dic's are stored in the mirror network like
> here:
> > http://ftp5.gwdg.de/pub/openoffice/contrib/dictionaries/
> > But I don't how current it is when looking at the
> timestamps.
>
> The Italian dictionary listed there is a rather outdated
> version (2005 and 2006). The current version is at
> http://extensions.services.openoffice.org/node/1204
> and in general all (or "all the relevant") dictionaries, as
> far as I know, are now packaged as extensions.
>
> >> If these dictionaries are under the SGA and part
> of the project, they
> >> should probably go into SVN or onto the website.
> Otherwise they could
> >> go to Apache-Extras.
> > It seems that this is valid for 2.x releases. I
> remember that we have
> > build-in these for 3.x. But I'm not sure.
>
> The Italian dictionary is not under Oracle's copyright and
> it can't be covered by the SGA (which leaves us with many
> practical issues now); the same probably holds for many
> other dictionaries.
>
> Most dictionaries there are now repackaged as extensions,
> but this doesn't affect their licence or the copyright
> owners, it is mere packaging.
>
> Regards,
> Andrea.
>
Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
Posted by Gianluca Turconi <in...@letturefantastiche.com>.
Pedro Giffuni ha scritto:
> 1) We have buildbots.
> 2) If a volunteer offers a binary for a platform
> we dont support, or an extension, we still
> have to control its content and GPLd stuff will
> not be carried by Apache servers.
> 3) We could provide a link to a third party site
> though (Apache-Extras or whatever).
>
> Maybe we should keep all dictionaries in an Apache
> extras site and keep in SVN only some for reference?
This is what I think may be a good compromise. :-)
But I don't know if it is technically feasible.
Regards,
Gianluca
--
Lettura gratuita o acquisto di libri e racconti di fantascienza,
fantasy, horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/
Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Gianluca;
My understanding, but I can be wrong because I have never
done a release:
1) We have buildbots.
2) If a volunteer offers a binary for a platform
we dont support, or an extension, we still
have to control its content and GPLd stuff will
not be carried by Apache servers.
3) We could provide a link to a third party site
though (Apache-Extras or whatever).
Maybe we should keep all dictionaries in an Apache
extras site and keep in SVN only some for reference?
Cheers,
Pedro.
--- On Mon, 11/7/11, Gianluca Turconi <in...@letturefantastiche.com> wrote:
> From: Gianluca Turconi <in...@letturefantastiche.com>
> Subject: Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
> To: ooo-dev@incubator.apache.org
> Date: Monday, November 7, 2011, 5:14 AM
> Firstly, thanks to Eric for the
> explanation.
>
> I'm not a developer so, it's rather important that I
> understand how the whole thing technically works. :-)
>
> More comments follow below.
>
> eric b ha scritto:
> > 3) at buildtime, the content of every locale is zipped
> as an extension
> >
> > At least this is what I read in
> dictionaries/util/makefile.mk
> >
> >
> > 4) every zipped dictionary is delivered in the solver,
> and included in the final package, depending on the goal as
> an extension
> >
> > See
> main/setup_native/source/packinfo/package_names.txt
> for the list of available dictionaries.
> >
> > 5) at packaging time :
> >
> > when packaging an archive, on a given OS, a list of
> dictionary is used, to add the one needed for a given
> locale.
> >
> > See
> main/setup_native/source/packinfo/spellchecker_selection.txt
> to check what dictionary will be installed, for a given
> locale.
> >
> > I'm a bit unsure, but the pre-installed dictionaries
> (or maybe they are at user install time) are installed as
> extensions.
> This is the conclusion that Andrea also gave.
>
> However, I'm trying to understand Apache legal approach to
> code and binary releases.
>
> What I've understood is that Apache doesn't allow a code
> release that includes parts ruled from a license not
> compatible with Apache license.
>
> However, if I'm not wrong, all those not compatible parts
> can be hosted elsewhere (Google extras?) and incorporated at
> phase 3) or 5) by an external builder/packager.
>
> Would the resulting binary/combined package legally
> distributable as "Apache OOo" or not ? Would it be
> distributable via the OOo usual mirror network?
>
> What I'm trying to understand is whether the *binary*
> release of OOo would be managed through internal Apache
> hardware or not.
>
> If the answer is no, and the normal binary release phase is
> managed by external
> volunteers/corporations/put-here-your-preferred-entity, I
> think there is no need to distribute an executable file for
> *end users* without all the linguistic tools needed by those
> users.
>
> The linguistic tools (and GUI translations too?) may be
> hosted elsewhere and incorporate as described above, until
> the project will have enough manpower to change the main
> spell checking engine and dictionaries.
>
> I hope I've clearly explained what I meant saying. :-)
>
> Regards,
>
> Gianluca
>
> -- Lettura gratuita o acquisto di libri e racconti di
> fantascienza,
> fantasy, horror, noir, narrativa fantastica e
> tradizionale:
> http://www.letturefantastiche.com/
>
>
Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
Posted by Gianluca Turconi <in...@letturefantastiche.com>.
Firstly, thanks to Eric for the explanation.
I'm not a developer so, it's rather important that I understand how the
whole thing technically works. :-)
More comments follow below.
eric b ha scritto:
> 3) at buildtime, the content of every locale is zipped as an extension
>
> At least this is what I read in dictionaries/util/makefile.mk
>
>
> 4) every zipped dictionary is delivered in the solver, and included in
> the final package, depending on the goal as an extension
>
> See main/setup_native/source/packinfo/package_names.txt for the list
> of available dictionaries.
>
> 5) at packaging time :
>
> when packaging an archive, on a given OS, a list of dictionary is
> used, to add the one needed for a given locale.
>
> See main/setup_native/source/packinfo/spellchecker_selection.txt to
> check what dictionary will be installed, for a given locale.
>
> I'm a bit unsure, but the pre-installed dictionaries (or maybe they
> are at user install time) are installed as extensions.
This is the conclusion that Andrea also gave.
However, I'm trying to understand Apache legal approach to code and
binary releases.
What I've understood is that Apache doesn't allow a code release that
includes parts ruled from a license not compatible with Apache license.
However, if I'm not wrong, all those not compatible parts can be hosted
elsewhere (Google extras?) and incorporated at phase 3) or 5) by an
external builder/packager.
Would the resulting binary/combined package legally distributable as
"Apache OOo" or not ? Would it be distributable via the OOo usual mirror
network?
What I'm trying to understand is whether the *binary* release of OOo
would be managed through internal Apache hardware or not.
If the answer is no, and the normal binary release phase is managed by
external volunteers/corporations/put-here-your-preferred-entity, I think
there is no need to distribute an executable file for *end users*
without all the linguistic tools needed by those users.
The linguistic tools (and GUI translations too?) may be hosted elsewhere
and incorporate as described above, until the project will have enough
manpower to change the main spell checking engine and dictionaries.
I hope I've clearly explained what I meant saying. :-)
Regards,
Gianluca
--
Lettura gratuita o acquisto di libri e racconti di fantascienza,
fantasy, horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/
Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
Posted by eric b <er...@free.fr>.
Hi Gianluca,
Le 7 nov. 11 à 09:29, Gianluca Turconi a écrit :
> Rob Weir ha scritto:
>> 1) The user can download the dictionaries onto their own machines, if
>> they agree to uphold the license.
>>
>> 2) We could have a UI in the product that helps the user download
>> dictionaries. This could state the license and require the user to
>> click "agree".
> Like I've wrote to Pedro, it would be useful, at least to me, to
> know how the compiling and releasing structure of AOOo *binaries*
> will be organized.
>
> If the binaries will be *contributed* by external volunteers and
> structures, the inclusion of GPL'd parts would be consented anyway,
> since the code repository would be untouched and only the binaries
> would be hypothetically ruled by GPL.
>
Well, a fast read in the sources (please other, correct me if I'm
wrong) leads me to that :
1) there is one module (say a directory in the main OOo tree) named
"dictionaries"
2) inside, the tree is organized into
- one subdir per locale,
- inside every locale, you find
More precisely, main/dictionaries/ contains one subdir per locale +
util, containing the main makefile for the module "dictionary" :
af_ZA da_DK de_DE es_ES gl hu_HU lt_LT no
pt_BR sk_SK sv_SE util
ca de_AT diclst et_EE he_IL it_IT ne_NP pl_PL
ro sl_SI sw_TZ vi
cs_CZ de_CH en fr_FR hr_HR ku_TR nl_NL prj
ru_RU sr th_TH zu_ZA
e.g. in main/dictionaries/it_IT, we got :
README_hyph_it_IT.txt desc_en.txt
hyph_it_IT.dic makefile.mk
README_it_IT.txt desc_it.txt
ico.png manifest.xml
README_th_it_IT.txt description.xml
it_IT.aff th_it_IT_v2.dat
delzip dictionaries.xcu
it_IT.dic th_it_IT_v2.idx
If I'm not wrong, the dictionary itself is the it_IT.dic file.
3) at buildtime, the content of every locale is zipped as an extension
At least this is what I read in dictionaries/util/makefile.mk
4) every zipped dictionary is delivered in the solver, and included
in the final package, depending on the goal as an extension
See main/setup_native/source/packinfo/package_names.txt for the list
of available dictionaries.
5) at packaging time :
when packaging an archive, on a given OS, a list of dictionary is
used, to add the one needed for a given locale.
See main/setup_native/source/packinfo/spellchecker_selection.txt to
check what dictionary will be installed, for a given locale.
I'm a bit unsure, but the pre-installed dictionaries (or maybe they
are at user install time) are installed as extensions.
My 2 cts
Eric Bachard
--
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news
Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
Posted by Gianluca Turconi <in...@letturefantastiche.com>.
Rob Weir ha scritto:
> 1) The user can download the dictionaries onto their own machines, if
> they agree to uphold the license.
>
> 2) We could have a UI in the product that helps the user download
> dictionaries. This could state the license and require the user to
> click "agree".
Like I've wrote to Pedro, it would be useful, at least to me, to know
how the compiling and releasing structure of AOOo *binaries* will be
organized.
If the binaries will be *contributed* by external volunteers and
structures, the inclusion of GPL'd parts would be consented anyway,
since the code repository would be untouched and only the binaries would
be hypothetically ruled by GPL.
It would be a transient solution, of course.
> 5) We could create a new dictionary.
English is a simple language with a simple grammar, but believe me that
more complex languages like Italian, French and German may need several
thousands of work hours to recreate a good dictionary for OOo.
Regards,
Gianluca
--
Lettura gratuita o acquisto di libri e racconti di fantascienza,
fantasy, horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/
Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
Posted by Rob Weir <ro...@apache.org>.
On Sun, Nov 6, 2011 at 5:18 PM, Pedro Giffuni <pf...@apache.org> wrote:
> --- On Sun, 11/6/11, Rob Weir <ro...@apache.org> wrote:
> ...
>> Dennis E. Hamilton wrote:
>> > +1 I heartily agree with Dave's suggestion.
>> >
>> > The issue has been made very clear by Andrea and I
>> think it would be good to raise an issue on the LEGAL JIRA.
>> (Registration required, but I don't think committer status
>> is needed.) Also, legal-discuss@ apache.org is an useful
>> place, but my experience is that eventually a LEGAL JIRA
>> issue will obtain more consistent attention.
>> >
>>
>> Just make sure that you explain what a spell checking
>> dictionary is.
>> Otherwise any legal types will be confused. This is
>> not a dictionary like Webster's, with words and definitions,
>> where the definitions are creative content. A spell checking
>> dictionary is more of a word list.
>
> Makefiles are also a basically a list with little or no
> creative content and they don't even leave a trace in the code
> but we are relicensing them.
>
It varies from country to country, see:
http://en.wikipedia.org/wiki/Threshold_of_originality
But we'll never resolve this on legal grounds. At Apache we would not
bundle a dictionary under a legal theory if the compiler of the
dictionary did not want us to. I think we should respect the
dictionary compiler's wishes and intent, even if legally we're not
obligated to.
But we do have options:
1) The user can download the dictionaries onto their own machines, if
they agree to uphold the license.
2) We could have a UI in the product that helps the user download
dictionaries. This could state the license and require the user to
click "agree".
3) We could contact the compilers of the dictionary and ask if they
would make them available under a difference license. Generally
people make things available under an OSS license because they want to
see other projects use them. If we tell them that a leading
application like OpenOffice can no longer user their dictionary, this
might persuade them to change their license.
4) We could convert another word list or dictionary, one that has a
better license, into Hunspell format.
5) We could create a new dictionary.
> I am concerned that we are talking about the GPL. If it
> were MPL or a documentation license it would be different
> but last time we discussed it we were not accepting copyleft
> documentation either.
>
> cheers,
>
> Pedro.
>> I'm not sure what the creative expression is in a
>> list of all common
>> words in a language and how that could be
>> copyrighted. Of course, I
>> am not a lawyer. But this case seems relevant:
>>
>> http://en.wikipedia.org/wiki/Feist_v._Rural
>>
>> > I also think Pedro raises an important concern. My
>> sense of other materials I have seen about that is binaries
>> (or at least not human-readable and editable) might work
>> since it is possible to make it clear that a non-Apache
>> license applies and there is no confusion by having source
>> anywhere in a release for something with an unacceptable
>> license. I don't know how this applies to the present
>> case. I suspect it has some bearing on how safe inclusion
>> of various dictionaries in binary distributions is seen to
>> be.
>> >
>> > - Dennis
>> >
>> > -----Original Message-----
>> > From: Dave Fisher [mailto:dave2wave@comcast.net]
>> > Sent: Sunday, November 06, 2011 12:57
>> > To: ooo-dev@incubator.apache.org
>> > Subject: Re: GPL'd dictionaries (was Re:
>> ftp.services.openoffice.org?)
>> >
>> > HI Andrea,
>> >
>> > This looks like some good questions for Apache Legal.
>> You should send this to legal-discuss@a.o.
>> >
>> > Regards,
>> > Dave
>> >
>> > On Nov 6, 2011, at 11:06 AM, Andrea Pescetti wrote:
>> >
>> >> On 05/11/2011 Gianluca Turconi wrote:
>> >>> 2011/11/5 Pedro Giffuni
>> >>>> I have been looking at the situation of
>> the dictionaries,
>> >>>> and particular the italian dictionary.
>> >>>> You are right that it will not be covered
>> by the SGA.
>> >>
>> >> Sure, and to be more precise there are no portions
>> of which Oracle has the copyright in the Italian dictionary.
>> And we are discussing about three completeley separate tools
>> (this is true of all languages): a dictionary (used for
>> spell-checking), a thesaurus (for synonyms) and hyphenations
>> patterns. Each has its own licence and copyright holders; in
>> most cases, hyphenation patterns come from the LaTeX
>> project.
>> >>
>> >>>> Perhaps more worrying is that the italian
>> dictionary is
>> >>>> the only dictionary under the GPL; most
>> others are triple
>> >>>> licensed (LGPL/MPL/GPL).
>> >>>> We are not allowed to use it, so it will
>> be removed
>> >>>> from the SVN server for sure.
>> >>
>> >> The fundamental thing to consider here is that
>> dictionaries cannot be considered like libraries, for the
>> following reasons:
>> >> - OpenOffice.org dictionaries are not code; their
>> binary form is coincident with their source form.
>> >> - OpenOffice.org dictionaries are not a
>> dependency: they are pluggable data files, and they are
>> packaged (all of them, even in the installer for native
>> builds) as extensions to remark that there is no dependency
>> whatsoever on them.
>> >> - OpenOffice.org dictionaries fall in the "mere
>> aggregation" provision in the GPL license; even though it is
>> customary to distribute a package containing, say, the
>> Italian version of OpenOffice.org and the Italian
>> dictionary, it is considered the same as distributing an
>> Ubuntu ISO file, containing software with different licenses
>> aggregated together.
>> >>
>> >> The existing Apache policy probably assumes that
>> we are talking about code and that the (L)GPL libraries
>> constitute a dependency, and it was probably built by
>> examining what the implications of (L)GPL components would
>> have been in that case. But this is a much different
>> situation.
>> >>
>> >>>> I am not a lawyer and I don't have any
>> idea how the
>> >>>> GPL could be enforced in this case, but
>> things are not nice.
>> >>
>> >> I can't understand these worries about enforcing
>> the GPL. We even got an answer from the Free Software
>> Foundation that said it is absolutely OK to include GPL
>> dictionaries into OpenOffice.org, since it is "mere
>> aggregation"; see the (long) story in
>> >> https://issues.apache.org/ooo/show_bug.cgi?id=65039
>> >>
>> >>> We've discussed a lot about this issue, but
>> there isn't any consensus yet
>> >>> about *how *to solve the problem, in a
>> pragmatic way that doesn't include a
>> >>> license change.
>> >>
>> >> Gianluca is right, in our situation we won't be
>> able to change the license of the dictionary and thesaurus
>> (at least, not to Apache License); we might get the
>> hyphenation patterns released under the Apache License, but
>> since virtually all of them are taken from the LaTeX project
>> it's probably better that the legal team checks whether it's
>> fine to import from the LaTeX project with the existing
>> license.
>> >>
>> >>> An AOOo without a native language GUI and
>> linguistic tools would be just
>> >>> useless outside the anglosaxon world and,
>> indeed, a rather disastrous
>> >>> presentation of the new project for people who
>> don't speak English.
>> >>
>> >> Sure, especially considering that the project
>> description says that OpenOffice.org supports 110
>> languages...
>> >>
>> >> What I would recommend is:
>> >>
>> >> 1) Recheck the Apache policy and find out the
>> rationale behind it; I have nothing to teach to the legal
>> team, but this is a very rare case where the "virality" of
>> GPL does not apply.
>> >>
>> >> 2) See if we can find a way to keep dictionaries
>> as they are; note that no dictionary is developed in the OOo
>> trunk, they are synchronized from time to time, usually
>> before a release; the Italian dictionary SVN trunk, for
>> example, is not in the OOo sources. Even just the
>> possibility to provide an extension that can be included in
>> binary releases would be OK for me.
>> >>
>> >> 3) If there is really no way to include a GPL
>> extension this way, then we should think about downloading
>> the extension at installation time. But we managed to get
>> Sun and the FSF agree to ship dictionaries in the most
>> convenient way (i.e., included in the installer), so we
>> might succeed this time as well.
>> >>
>> >> Regards,
>> >> Andrea.
>> >
>> >
>>
>
Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
Posted by Pedro Giffuni <pf...@apache.org>.
--- On Sun, 11/6/11, Rob Weir <ro...@apache.org> wrote:
...
> Dennis E. Hamilton wrote:
> > +1 I heartily agree with Dave's suggestion.
> >
> > The issue has been made very clear by Andrea and I
> think it would be good to raise an issue on the LEGAL JIRA.
> (Registration required, but I don't think committer status
> is needed.) Also, legal-discuss@ apache.org is an useful
> place, but my experience is that eventually a LEGAL JIRA
> issue will obtain more consistent attention.
> >
>
> Just make sure that you explain what a spell checking
> dictionary is.
> Otherwise any legal types will be confused. This is
> not a dictionary like Webster's, with words and definitions,
> where the definitions are creative content. A spell checking
> dictionary is more of a word list.
Makefiles are also a basically a list with little or no
creative content and they don't even leave a trace in the code
but we are relicensing them.
I am concerned that we are talking about the GPL. If it
were MPL or a documentation license it would be different
but last time we discussed it we were not accepting copyleft
documentation either.
cheers,
Pedro.
> I'm not sure what the creative expression is in a
> list of all common
> words in a language and how that could be
> copyrighted. Of course, I
> am not a lawyer. But this case seems relevant:
>
> http://en.wikipedia.org/wiki/Feist_v._Rural
>
> > I also think Pedro raises an important concern. My
> sense of other materials I have seen about that is binaries
> (or at least not human-readable and editable) might work
> since it is possible to make it clear that a non-Apache
> license applies and there is no confusion by having source
> anywhere in a release for something with an unacceptable
> license. I don't know how this applies to the present
> case. I suspect it has some bearing on how safe inclusion
> of various dictionaries in binary distributions is seen to
> be.
> >
> > - Dennis
> >
> > -----Original Message-----
> > From: Dave Fisher [mailto:dave2wave@comcast.net]
> > Sent: Sunday, November 06, 2011 12:57
> > To: ooo-dev@incubator.apache.org
> > Subject: Re: GPL'd dictionaries (was Re:
> ftp.services.openoffice.org?)
> >
> > HI Andrea,
> >
> > This looks like some good questions for Apache Legal.
> You should send this to legal-discuss@a.o.
> >
> > Regards,
> > Dave
> >
> > On Nov 6, 2011, at 11:06 AM, Andrea Pescetti wrote:
> >
> >> On 05/11/2011 Gianluca Turconi wrote:
> >>> 2011/11/5 Pedro Giffuni
> >>>> I have been looking at the situation of
> the dictionaries,
> >>>> and particular the italian dictionary.
> >>>> You are right that it will not be covered
> by the SGA.
> >>
> >> Sure, and to be more precise there are no portions
> of which Oracle has the copyright in the Italian dictionary.
> And we are discussing about three completeley separate tools
> (this is true of all languages): a dictionary (used for
> spell-checking), a thesaurus (for synonyms) and hyphenations
> patterns. Each has its own licence and copyright holders; in
> most cases, hyphenation patterns come from the LaTeX
> project.
> >>
> >>>> Perhaps more worrying is that the italian
> dictionary is
> >>>> the only dictionary under the GPL; most
> others are triple
> >>>> licensed (LGPL/MPL/GPL).
> >>>> We are not allowed to use it, so it will
> be removed
> >>>> from the SVN server for sure.
> >>
> >> The fundamental thing to consider here is that
> dictionaries cannot be considered like libraries, for the
> following reasons:
> >> - OpenOffice.org dictionaries are not code; their
> binary form is coincident with their source form.
> >> - OpenOffice.org dictionaries are not a
> dependency: they are pluggable data files, and they are
> packaged (all of them, even in the installer for native
> builds) as extensions to remark that there is no dependency
> whatsoever on them.
> >> - OpenOffice.org dictionaries fall in the "mere
> aggregation" provision in the GPL license; even though it is
> customary to distribute a package containing, say, the
> Italian version of OpenOffice.org and the Italian
> dictionary, it is considered the same as distributing an
> Ubuntu ISO file, containing software with different licenses
> aggregated together.
> >>
> >> The existing Apache policy probably assumes that
> we are talking about code and that the (L)GPL libraries
> constitute a dependency, and it was probably built by
> examining what the implications of (L)GPL components would
> have been in that case. But this is a much different
> situation.
> >>
> >>>> I am not a lawyer and I don't have any
> idea how the
> >>>> GPL could be enforced in this case, but
> things are not nice.
> >>
> >> I can't understand these worries about enforcing
> the GPL. We even got an answer from the Free Software
> Foundation that said it is absolutely OK to include GPL
> dictionaries into OpenOffice.org, since it is "mere
> aggregation"; see the (long) story in
> >> https://issues.apache.org/ooo/show_bug.cgi?id=65039
> >>
> >>> We've discussed a lot about this issue, but
> there isn't any consensus yet
> >>> about *how *to solve the problem, in a
> pragmatic way that doesn't include a
> >>> license change.
> >>
> >> Gianluca is right, in our situation we won't be
> able to change the license of the dictionary and thesaurus
> (at least, not to Apache License); we might get the
> hyphenation patterns released under the Apache License, but
> since virtually all of them are taken from the LaTeX project
> it's probably better that the legal team checks whether it's
> fine to import from the LaTeX project with the existing
> license.
> >>
> >>> An AOOo without a native language GUI and
> linguistic tools would be just
> >>> useless outside the anglosaxon world and,
> indeed, a rather disastrous
> >>> presentation of the new project for people who
> don't speak English.
> >>
> >> Sure, especially considering that the project
> description says that OpenOffice.org supports 110
> languages...
> >>
> >> What I would recommend is:
> >>
> >> 1) Recheck the Apache policy and find out the
> rationale behind it; I have nothing to teach to the legal
> team, but this is a very rare case where the "virality" of
> GPL does not apply.
> >>
> >> 2) See if we can find a way to keep dictionaries
> as they are; note that no dictionary is developed in the OOo
> trunk, they are synchronized from time to time, usually
> before a release; the Italian dictionary SVN trunk, for
> example, is not in the OOo sources. Even just the
> possibility to provide an extension that can be included in
> binary releases would be OK for me.
> >>
> >> 3) If there is really no way to include a GPL
> extension this way, then we should think about downloading
> the extension at installation time. But we managed to get
> Sun and the FSF agree to ship dictionaries in the most
> convenient way (i.e., included in the installer), so we
> might succeed this time as well.
> >>
> >> Regards,
> >> Andrea.
> >
> >
>
Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
Posted by Rob Weir <ro...@apache.org>.
On Sun, Nov 6, 2011 at 4:10 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> +1 I heartily agree with Dave's suggestion.
>
> The issue has been made very clear by Andrea and I think it would be good to raise an issue on the LEGAL JIRA. (Registration required, but I don't think committer status is needed.) Also, legal-discuss@ apache.org is an useful place, but my experience is that eventually a LEGAL JIRA issue will obtain more consistent attention.
>
Just make sure that you explain what a spell checking dictionary is.
Otherwise any legal types will be confused. This is not a dictionary
like Webster's, with words and definitions, where the definitions are
creative content. A spell checking dictionary is more of a word list.
I'm not sure what the creative expression is in a list of all common
words in a language and how that could be copyrighted. Of course, I
am not a lawyer. But this case seems relevant:
http://en.wikipedia.org/wiki/Feist_v._Rural
> I also think Pedro raises an important concern. My sense of other materials I have seen about that is binaries (or at least not human-readable and editable) might work since it is possible to make it clear that a non-Apache license applies and there is no confusion by having source anywhere in a release for something with an unacceptable license. I don't know how this applies to the present case. I suspect it has some bearing on how safe inclusion of various dictionaries in binary distributions is seen to be.
>
> - Dennis
>
> -----Original Message-----
> From: Dave Fisher [mailto:dave2wave@comcast.net]
> Sent: Sunday, November 06, 2011 12:57
> To: ooo-dev@incubator.apache.org
> Subject: Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
>
> HI Andrea,
>
> This looks like some good questions for Apache Legal. You should send this to legal-discuss@a.o.
>
> Regards,
> Dave
>
> On Nov 6, 2011, at 11:06 AM, Andrea Pescetti wrote:
>
>> On 05/11/2011 Gianluca Turconi wrote:
>>> 2011/11/5 Pedro Giffuni
>>>> I have been looking at the situation of the dictionaries,
>>>> and particular the italian dictionary.
>>>> You are right that it will not be covered by the SGA.
>>
>> Sure, and to be more precise there are no portions of which Oracle has the copyright in the Italian dictionary. And we are discussing about three completeley separate tools (this is true of all languages): a dictionary (used for spell-checking), a thesaurus (for synonyms) and hyphenations patterns. Each has its own licence and copyright holders; in most cases, hyphenation patterns come from the LaTeX project.
>>
>>>> Perhaps more worrying is that the italian dictionary is
>>>> the only dictionary under the GPL; most others are triple
>>>> licensed (LGPL/MPL/GPL).
>>>> We are not allowed to use it, so it will be removed
>>>> from the SVN server for sure.
>>
>> The fundamental thing to consider here is that dictionaries cannot be considered like libraries, for the following reasons:
>> - OpenOffice.org dictionaries are not code; their binary form is coincident with their source form.
>> - OpenOffice.org dictionaries are not a dependency: they are pluggable data files, and they are packaged (all of them, even in the installer for native builds) as extensions to remark that there is no dependency whatsoever on them.
>> - OpenOffice.org dictionaries fall in the "mere aggregation" provision in the GPL license; even though it is customary to distribute a package containing, say, the Italian version of OpenOffice.org and the Italian dictionary, it is considered the same as distributing an Ubuntu ISO file, containing software with different licenses aggregated together.
>>
>> The existing Apache policy probably assumes that we are talking about code and that the (L)GPL libraries constitute a dependency, and it was probably built by examining what the implications of (L)GPL components would have been in that case. But this is a much different situation.
>>
>>>> I am not a lawyer and I don't have any idea how the
>>>> GPL could be enforced in this case, but things are not nice.
>>
>> I can't understand these worries about enforcing the GPL. We even got an answer from the Free Software Foundation that said it is absolutely OK to include GPL dictionaries into OpenOffice.org, since it is "mere aggregation"; see the (long) story in
>> https://issues.apache.org/ooo/show_bug.cgi?id=65039
>>
>>> We've discussed a lot about this issue, but there isn't any consensus yet
>>> about *how *to solve the problem, in a pragmatic way that doesn't include a
>>> license change.
>>
>> Gianluca is right, in our situation we won't be able to change the license of the dictionary and thesaurus (at least, not to Apache License); we might get the hyphenation patterns released under the Apache License, but since virtually all of them are taken from the LaTeX project it's probably better that the legal team checks whether it's fine to import from the LaTeX project with the existing license.
>>
>>> An AOOo without a native language GUI and linguistic tools would be just
>>> useless outside the anglosaxon world and, indeed, a rather disastrous
>>> presentation of the new project for people who don't speak English.
>>
>> Sure, especially considering that the project description says that OpenOffice.org supports 110 languages...
>>
>> What I would recommend is:
>>
>> 1) Recheck the Apache policy and find out the rationale behind it; I have nothing to teach to the legal team, but this is a very rare case where the "virality" of GPL does not apply.
>>
>> 2) See if we can find a way to keep dictionaries as they are; note that no dictionary is developed in the OOo trunk, they are synchronized from time to time, usually before a release; the Italian dictionary SVN trunk, for example, is not in the OOo sources. Even just the possibility to provide an extension that can be included in binary releases would be OK for me.
>>
>> 3) If there is really no way to include a GPL extension this way, then we should think about downloading the extension at installation time. But we managed to get Sun and the FSF agree to ship dictionaries in the most convenient way (i.e., included in the installer), so we might succeed this time as well.
>>
>> Regards,
>> Andrea.
>
>
RE: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
+1 I heartily agree with Dave's suggestion.
The issue has been made very clear by Andrea and I think it would be good to raise an issue on the LEGAL JIRA. (Registration required, but I don't think committer status is needed.) Also, legal-discuss@ apache.org is an useful place, but my experience is that eventually a LEGAL JIRA issue will obtain more consistent attention.
I also think Pedro raises an important concern. My sense of other materials I have seen about that is binaries (or at least not human-readable and editable) might work since it is possible to make it clear that a non-Apache license applies and there is no confusion by having source anywhere in a release for something with an unacceptable license. I don't know how this applies to the present case. I suspect it has some bearing on how safe inclusion of various dictionaries in binary distributions is seen to be.
- Dennis
-----Original Message-----
From: Dave Fisher [mailto:dave2wave@comcast.net]
Sent: Sunday, November 06, 2011 12:57
To: ooo-dev@incubator.apache.org
Subject: Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
HI Andrea,
This looks like some good questions for Apache Legal. You should send this to legal-discuss@a.o.
Regards,
Dave
On Nov 6, 2011, at 11:06 AM, Andrea Pescetti wrote:
> On 05/11/2011 Gianluca Turconi wrote:
>> 2011/11/5 Pedro Giffuni
>>> I have been looking at the situation of the dictionaries,
>>> and particular the italian dictionary.
>>> You are right that it will not be covered by the SGA.
>
> Sure, and to be more precise there are no portions of which Oracle has the copyright in the Italian dictionary. And we are discussing about three completeley separate tools (this is true of all languages): a dictionary (used for spell-checking), a thesaurus (for synonyms) and hyphenations patterns. Each has its own licence and copyright holders; in most cases, hyphenation patterns come from the LaTeX project.
>
>>> Perhaps more worrying is that the italian dictionary is
>>> the only dictionary under the GPL; most others are triple
>>> licensed (LGPL/MPL/GPL).
>>> We are not allowed to use it, so it will be removed
>>> from the SVN server for sure.
>
> The fundamental thing to consider here is that dictionaries cannot be considered like libraries, for the following reasons:
> - OpenOffice.org dictionaries are not code; their binary form is coincident with their source form.
> - OpenOffice.org dictionaries are not a dependency: they are pluggable data files, and they are packaged (all of them, even in the installer for native builds) as extensions to remark that there is no dependency whatsoever on them.
> - OpenOffice.org dictionaries fall in the "mere aggregation" provision in the GPL license; even though it is customary to distribute a package containing, say, the Italian version of OpenOffice.org and the Italian dictionary, it is considered the same as distributing an Ubuntu ISO file, containing software with different licenses aggregated together.
>
> The existing Apache policy probably assumes that we are talking about code and that the (L)GPL libraries constitute a dependency, and it was probably built by examining what the implications of (L)GPL components would have been in that case. But this is a much different situation.
>
>>> I am not a lawyer and I don't have any idea how the
>>> GPL could be enforced in this case, but things are not nice.
>
> I can't understand these worries about enforcing the GPL. We even got an answer from the Free Software Foundation that said it is absolutely OK to include GPL dictionaries into OpenOffice.org, since it is "mere aggregation"; see the (long) story in
> https://issues.apache.org/ooo/show_bug.cgi?id=65039
>
>> We've discussed a lot about this issue, but there isn't any consensus yet
>> about *how *to solve the problem, in a pragmatic way that doesn't include a
>> license change.
>
> Gianluca is right, in our situation we won't be able to change the license of the dictionary and thesaurus (at least, not to Apache License); we might get the hyphenation patterns released under the Apache License, but since virtually all of them are taken from the LaTeX project it's probably better that the legal team checks whether it's fine to import from the LaTeX project with the existing license.
>
>> An AOOo without a native language GUI and linguistic tools would be just
>> useless outside the anglosaxon world and, indeed, a rather disastrous
>> presentation of the new project for people who don't speak English.
>
> Sure, especially considering that the project description says that OpenOffice.org supports 110 languages...
>
> What I would recommend is:
>
> 1) Recheck the Apache policy and find out the rationale behind it; I have nothing to teach to the legal team, but this is a very rare case where the "virality" of GPL does not apply.
>
> 2) See if we can find a way to keep dictionaries as they are; note that no dictionary is developed in the OOo trunk, they are synchronized from time to time, usually before a release; the Italian dictionary SVN trunk, for example, is not in the OOo sources. Even just the possibility to provide an extension that can be included in binary releases would be OK for me.
>
> 3) If there is really no way to include a GPL extension this way, then we should think about downloading the extension at installation time. But we managed to get Sun and the FSF agree to ship dictionaries in the most convenient way (i.e., included in the installer), so we might succeed this time as well.
>
> Regards,
> Andrea.
Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
Posted by Dave Fisher <da...@comcast.net>.
HI Andrea,
This looks like some good questions for Apache Legal. You should send this to legal-discuss@a.o.
Regards,
Dave
On Nov 6, 2011, at 11:06 AM, Andrea Pescetti wrote:
> On 05/11/2011 Gianluca Turconi wrote:
>> 2011/11/5 Pedro Giffuni
>>> I have been looking at the situation of the dictionaries,
>>> and particular the italian dictionary.
>>> You are right that it will not be covered by the SGA.
>
> Sure, and to be more precise there are no portions of which Oracle has the copyright in the Italian dictionary. And we are discussing about three completeley separate tools (this is true of all languages): a dictionary (used for spell-checking), a thesaurus (for synonyms) and hyphenations patterns. Each has its own licence and copyright holders; in most cases, hyphenation patterns come from the LaTeX project.
>
>>> Perhaps more worrying is that the italian dictionary is
>>> the only dictionary under the GPL; most others are triple
>>> licensed (LGPL/MPL/GPL).
>>> We are not allowed to use it, so it will be removed
>>> from the SVN server for sure.
>
> The fundamental thing to consider here is that dictionaries cannot be considered like libraries, for the following reasons:
> - OpenOffice.org dictionaries are not code; their binary form is coincident with their source form.
> - OpenOffice.org dictionaries are not a dependency: they are pluggable data files, and they are packaged (all of them, even in the installer for native builds) as extensions to remark that there is no dependency whatsoever on them.
> - OpenOffice.org dictionaries fall in the "mere aggregation" provision in the GPL license; even though it is customary to distribute a package containing, say, the Italian version of OpenOffice.org and the Italian dictionary, it is considered the same as distributing an Ubuntu ISO file, containing software with different licenses aggregated together.
>
> The existing Apache policy probably assumes that we are talking about code and that the (L)GPL libraries constitute a dependency, and it was probably built by examining what the implications of (L)GPL components would have been in that case. But this is a much different situation.
>
>>> I am not a lawyer and I don't have any idea how the
>>> GPL could be enforced in this case, but things are not nice.
>
> I can't understand these worries about enforcing the GPL. We even got an answer from the Free Software Foundation that said it is absolutely OK to include GPL dictionaries into OpenOffice.org, since it is "mere aggregation"; see the (long) story in
> https://issues.apache.org/ooo/show_bug.cgi?id=65039
>
>> We've discussed a lot about this issue, but there isn't any consensus yet
>> about *how *to solve the problem, in a pragmatic way that doesn't include a
>> license change.
>
> Gianluca is right, in our situation we won't be able to change the license of the dictionary and thesaurus (at least, not to Apache License); we might get the hyphenation patterns released under the Apache License, but since virtually all of them are taken from the LaTeX project it's probably better that the legal team checks whether it's fine to import from the LaTeX project with the existing license.
>
>> An AOOo without a native language GUI and linguistic tools would be just
>> useless outside the anglosaxon world and, indeed, a rather disastrous
>> presentation of the new project for people who don't speak English.
>
> Sure, especially considering that the project description says that OpenOffice.org supports 110 languages...
>
> What I would recommend is:
>
> 1) Recheck the Apache policy and find out the rationale behind it; I have nothing to teach to the legal team, but this is a very rare case where the "virality" of GPL does not apply.
>
> 2) See if we can find a way to keep dictionaries as they are; note that no dictionary is developed in the OOo trunk, they are synchronized from time to time, usually before a release; the Italian dictionary SVN trunk, for example, is not in the OOo sources. Even just the possibility to provide an extension that can be included in binary releases would be OK for me.
>
> 3) If there is really no way to include a GPL extension this way, then we should think about downloading the extension at installation time. But we managed to get Sun and the FSF agree to ship dictionaries in the most convenient way (i.e., included in the installer), so we might succeed this time as well.
>
> Regards,
> Andrea.
Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
Posted by Andrea Pescetti <pe...@openoffice.org>.
On 05/11/2011 Gianluca Turconi wrote:
> 2011/11/5 Pedro Giffuni
>> I have been looking at the situation of the dictionaries,
>> and particular the italian dictionary.
>> You are right that it will not be covered by the SGA.
Sure, and to be more precise there are no portions of which Oracle has
the copyright in the Italian dictionary. And we are discussing about
three completeley separate tools (this is true of all languages): a
dictionary (used for spell-checking), a thesaurus (for synonyms) and
hyphenations patterns. Each has its own licence and copyright holders;
in most cases, hyphenation patterns come from the LaTeX project.
>> Perhaps more worrying is that the italian dictionary is
>> the only dictionary under the GPL; most others are triple
>> licensed (LGPL/MPL/GPL).
>> We are not allowed to use it, so it will be removed
>> from the SVN server for sure.
The fundamental thing to consider here is that dictionaries cannot be
considered like libraries, for the following reasons:
- OpenOffice.org dictionaries are not code; their binary form is
coincident with their source form.
- OpenOffice.org dictionaries are not a dependency: they are pluggable
data files, and they are packaged (all of them, even in the installer
for native builds) as extensions to remark that there is no dependency
whatsoever on them.
- OpenOffice.org dictionaries fall in the "mere aggregation" provision
in the GPL license; even though it is customary to distribute a package
containing, say, the Italian version of OpenOffice.org and the Italian
dictionary, it is considered the same as distributing an Ubuntu ISO
file, containing software with different licenses aggregated together.
The existing Apache policy probably assumes that we are talking about
code and that the (L)GPL libraries constitute a dependency, and it was
probably built by examining what the implications of (L)GPL components
would have been in that case. But this is a much different situation.
>> I am not a lawyer and I don't have any idea how the
>> GPL could be enforced in this case, but things are not nice.
I can't understand these worries about enforcing the GPL. We even got an
answer from the Free Software Foundation that said it is absolutely OK
to include GPL dictionaries into OpenOffice.org, since it is "mere
aggregation"; see the (long) story in
https://issues.apache.org/ooo/show_bug.cgi?id=65039
> We've discussed a lot about this issue, but there isn't any consensus yet
> about *how *to solve the problem, in a pragmatic way that doesn't include a
> license change.
Gianluca is right, in our situation we won't be able to change the
license of the dictionary and thesaurus (at least, not to Apache
License); we might get the hyphenation patterns released under the
Apache License, but since virtually all of them are taken from the LaTeX
project it's probably better that the legal team checks whether it's
fine to import from the LaTeX project with the existing license.
> An AOOo without a native language GUI and linguistic tools would be just
> useless outside the anglosaxon world and, indeed, a rather disastrous
> presentation of the new project for people who don't speak English.
Sure, especially considering that the project description says that
OpenOffice.org supports 110 languages...
What I would recommend is:
1) Recheck the Apache policy and find out the rationale behind it; I
have nothing to teach to the legal team, but this is a very rare case
where the "virality" of GPL does not apply.
2) See if we can find a way to keep dictionaries as they are; note that
no dictionary is developed in the OOo trunk, they are synchronized from
time to time, usually before a release; the Italian dictionary SVN
trunk, for example, is not in the OOo sources. Even just the possibility
to provide an extension that can be included in binary releases would be
OK for me.
3) If there is really no way to include a GPL extension this way, then
we should think about downloading the extension at installation time.
But we managed to get Sun and the FSF agree to ship dictionaries in the
most convenient way (i.e., included in the installer), so we might
succeed this time as well.
Regards,
Andrea.
Re: Localization on the Oracle software grant [was Re: GPL'd
dictionaries (was Re: ftp.services.openoffice.org?)]
Posted by Gianluca Turconi <pu...@letturefantastiche.com>.
In data 18 novembre 2011 alle ore 13:13:30, Ariel Constenla-Haile
<ar...@apache.org> ha scritto:
> comparing this list with the localize.sdf files in
> http://svn.apache.org/viewvc/incubator/ooo/trunk/extras/l10n/source/
> every localized.sdf is included in the software grant.
Well, these are *really* good news.
One important item less on the IP clearance list! :-)
Regards,
Gianluca
--
Lettura gratuita o acquisto di libri e racconti di fantascienza, fantasy,
horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/
Re: Localization on the Oracle software grant [was Re: GPL'd dictionaries
(was Re: ftp.services.openoffice.org?)]
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 11/18/11 1:13 PM, Ariel Constenla-Haile wrote:
> Hi Gianluca, *
>
> On Sat, Nov 05, 2011 at 09:53:44AM +0100, Gianluca Turconi wrote:
>> We discussed about other ways (on line download via a wizard during
>> installation time) to let the user chose these linguistic tools and, IMO,
>> it would be time to define such changes in a surer way than a simple
>> discussion.
>
> I think I will bring that topic once more, to find a final conclusion
> for once :)
>
>> In fact here:
>>
>> https://cwiki.apache.org/OOOUSERS/ipclearance.html
>>
>> I see that even translations for the localizations *may *be not covered by
>> Oracle SGA.
>
> today, looking for other stuff, I found that they are covered:
> http://svn.apache.org/viewvc/incubator/ooo/pmc/ip-review/oracle-sga-2.txt?view=markup#l31610
> or better check them out:
>
> svn co https://svn.apache.org/repos/asf/incubator/ooo/pmc
>
> comparing this list with the localize.sdf files in
> http://svn.apache.org/viewvc/incubator/ooo/trunk/extras/l10n/source/
> every localized.sdf is included in the software grant.
>
> @Jürgen: you have that task assigned. Can you confirm the localization
> is on the software grant?
>
yes, i will mark it as completed. The last time i have checked it these
files weren't included.
@Andrew, thanks for the update
Juergen
>
> Regards
Localization on the Oracle software grant [was Re: GPL'd
dictionaries (was Re: ftp.services.openoffice.org?)]
Posted by Ariel Constenla-Haile <ar...@apache.org>.
Hi Gianluca, *
On Sat, Nov 05, 2011 at 09:53:44AM +0100, Gianluca Turconi wrote:
> We discussed about other ways (on line download via a wizard during
> installation time) to let the user chose these linguistic tools and, IMO,
> it would be time to define such changes in a surer way than a simple
> discussion.
I think I will bring that topic once more, to find a final conclusion
for once :)
> In fact here:
>
> https://cwiki.apache.org/OOOUSERS/ipclearance.html
>
> I see that even translations for the localizations *may *be not covered by
> Oracle SGA.
today, looking for other stuff, I found that they are covered:
http://svn.apache.org/viewvc/incubator/ooo/pmc/ip-review/oracle-sga-2.txt?view=markup#l31610
or better check them out:
svn co https://svn.apache.org/repos/asf/incubator/ooo/pmc
comparing this list with the localize.sdf files in
http://svn.apache.org/viewvc/incubator/ooo/trunk/extras/l10n/source/
every localized.sdf is included in the software grant.
@Jürgen: you have that task assigned. Can you confirm the localization
is on the software grant?
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
Posted by Gianluca Turconi <in...@letturefantastiche.com>.
Hi Pedro,
2011/11/5 Pedro Giffuni <pf...@apache.org>
> Hi Andrea;
>
> I have been looking at the situation of the dictionaries,
> and particular the italian dictionary.
>
> You are right that it will not be covered by the SGA.
> Perhaps more worrying is that the italian dictionary is
> the only dictionary under the GPL; most others are triple
> licensed (LGPL/MPL/GPL).
>
> We are not allowed to use it, so it will be removed
> from the SVN server for sure. Beyond that ... well
> I am not a lawyer and I don't have any idea how the
> GPL could be enforced in this case, but things are
> not nice.
>
We've discussed a lot about this issue, but there isn't any consensus yet
about *how *to solve the problem, in a pragmatic way that doesn't include a
license change.
I know for sure that GPL is not the preferred license for at least one
co-author who liked the even stricter Affero GPL because of several GPL
violations of the Italian dictionary license made by on line web services.
We even contacted a specialized copyright lawyer, though we then decided
not to file any claim against those people.
Nevertheless, the Italian dictionary is one of the oldest dictionary, maybe
the oldest one except, maybe, English and German, included into the OOo
binary distribution and that wasn't owned by Sun/Oracle. So whatever change
would be made that caused its exclusion from the distribution, it would be
a real regression for our user base.
We discussed about other ways (on line download via a wizard during
installation time) to let the user chose these linguistic tools and, IMO,
it would be time to define such changes in a surer way than a simple
discussion.
In fact here:
https://cwiki.apache.org/OOOUSERS/ipclearance.html
I see that even translations for the localizations *may *be not covered by
Oracle SGA.
An AOOo without a native language GUI and linguistic tools would be just
useless outside the anglosaxon world and, indeed, a rather disastrous
presentation of the new project for people who don't speak English.
So, we may try to discuss deeply and practically these topics.
Regards,
Gianluca
--
Lettura gratuita o acquisto di libri e racconti di fantascienza,
fantasy, horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/