On Jun 7, 2011 3:01 PM, "Simon Brouwer" <simon.o...@xs4all.nl> wrote:
>
> Op 7-6-2011 22:37, William A. Rowe Jr. schreef:
>
>> On 6/7/2011 3:17 PM, Simon Brouwer wrote:
>>>
>>> The OpenOffice.org installation packages contain code from a
considerable number of
>>> "external" libraries (i.e. third party ones that are developed in their
own projects, not
>>> copyright Oracle and have mostly LGPL license). So this would not be
allowed for releases
>>> by the podling?
>>
>> Binaries under category A or B license would be permitted, compiled from
>> releases under their original project.  We like to avoid forks (and don't
>> fork category B licenses such as MPL).  Category X licensed components
>> cannot be shipped by the ASF, which includes LGPL.
>>
>> http://www.apache.org/legal/resolved.html#category-a
>> http://www.apache.org/legal/resolved.html#category-b
>> http://www.apache.org/legal/resolved.html#category-x
>>
>> I entirely expect that LO today could not be shipped by the ASF.  There
>> is, as we have hinted, room to take LO further than OOo can be allowed,
>> given our licensing guidelines.  There is also the concept of optional
>> dependencies, where the ASF software is capable of interfacing to some
>> category x component, but the ASF does not complete that connection, and
>> allows the packager/distributor to elect to do so.  Support in httpd
>> for mysql, oracle db, freetds, postgresql, gdbm and berkely db all fall
>> into this category (and the package supports sqlite and sdbm to name
>> two examples of this optional functionality implemented in AL compatible
>> licensing).
>
> Then I expect that, even if a working OOo product could be shipped by the
ASF in the near future under these conditions, it will be a big step back
from the OOo/LO available today because many functions will be missing.

Yup... that will be part of the challenge! We gotta make things difficult
for ourselves, so that we feel awesome when we solve them :-) :-)

Cheers,
-g

Reply via email to