Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Mathias_Bauer@gmx.net
 designates 213.165.64.23 as permitted sender)
Message-ID: <4DFAFE1D.6090603@gmx.net>
Date: Fri, 17 Jun 2011 09:11:25 +0200
From: Mathias Bauer <Mathias_Bauer@gmx.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Mnenhy/0.8.3
 OracleBeehiveExtension/1.0.0.2-OracleInternal
 ObetStats/CATCATCATCATCATCAFCATLAF_1292428138647-396660266 Thunderbird/3.1.10
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: External dependencies (was Re: [discuss] remove of binfilter
 module)
References: <4DF7D090.5090000@lippka.com>	<4DF7D79D.9020106@gmx.net>
	<4DF7DA4C.6080007@gmx.ch>	<1308091258.3010.26.camel@localhost.localdomain>
	<4DF7E7A8.4090901@ahrens-netz.de>
	<edcd5fa1c8f152dccb765b1d76b161df@tutopia.com>
	<BANLkTin-exSN=FR5_pwjaGXO=Q6g=0kQ6A@mail.gmail.com>
	<4DF87460.4010802@gmx.net>	<460ddaf3effcbe50956e5843081688c8@tutopia.com>
	<BANLkTi=VK+tXC6J4pUnqMCOAfTJXZ9=q+A@mail.gmail.com>
 <BANLkTin00FOkbYaz9X6JYr=GdznZApk_+A@mail.gmail.com>
 <4DFA2C23.9040601@gmx.net> <4DFA76B9.7010103@oracle.com>
In-Reply-To: <4DFA76B9.7010103@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 16.06.2011 23:33, Andrew Rist wrote:
>
> On 6/16/2011 9:15 AM, Mathias Bauer wrote:
>> On 16.06.2011 16:45, Rob Weir wrote:
>>> On Wed, Jun 15, 2011 at 11:39 PM, Greg Stein<gstein@gmail.com> wrote:
>>>> On Wed, Jun 15, 2011 at 12:09, Pedro Giffuni<giffunip@tutopia.com>
>>>> wrote:
>>>>> On Wed, 15 Jun 2011 10:59:12 +0200, Mathias
>>>>> Bauer<Mathias_Bauer@gmx.net>
>>>>> ...
>>>>>> Correct me if I'm wrong, but my understanding was that nowhere in the
>>>>>> code repository we can have code that links against LGPL code. And of
>>>>>> course extensions are part of our code base also.
>>>>
>>>> The repository can contain code that is licensed with a permissive
>>>> license (ALv2, MIT, BSD). Of course, we try to have only "our" code,
>>>> but over in httpd is a copy of PCRE, and APR has a copy of Expat.
>>>> Stuff that is not "our" code must be listed in the NOTICE file.
>>>>
>>>> We cannot have any code in the repository that has a reciprocal
>>>> license.
>>>>
>>>
>>> Could you clarify one thing for me, please?
>>>
>>> I thought we could take the Oracle code as-is, and check it in, verify
>>> that it is complete and builds, but that we would then be required to
>>> resolve the license issues before could have a release or graduate.
>>> Is that incorrect? Are we required to resolve these issues before we
>>> even accept the SGA'ed code? It makes it difficult to collaborate on
>>> resolving these issues if we cannot get the initial code into SVN.
>>>
>>> -Rob
>>>
>>
>> The Oracle code as-is will not be sufficient to build anything.
>> The initial list of files from Oracle misses several thousand files
>> (e.g. nearly the complete build system files) because these files
>> don't have copyright headers in them. To the best of my knowledge,
>> they are under Oracle's copyright, but it's not up to me to decide on
>> that.
>>
>> People are working on that, but we obviously have to wait. Let's use
>> the time to go through all files where the copyright situation is
>> unclear or where we already know that the copyright holder is someone
>> else (I have posted a first list already).
>>
>> Regards,
>> Mathias
>>
> I think this is a misunderstanding of "the Oracle code". I think Rob is
> talking about the entire contents of the OOo source control, where
> Mathias is thinking of the files in the SGA.
>
> So the questions are:
> - Is there anything in the Apache process that stops us from pulling in
> the entire source control from OOo?
> - Will that set of files enable us to build OOo (across platforms, etc.)?
> - Is that the best starting place for beginning the code remediation,
> like removing bits that cannot be relicensed, or are not license
> compatible?

That sounds like a great idea that would allow us to work on the 
different duties (checking licences and copyright, bootstrapping the 
build etc.) in parallel.

As Greg pointed out that our incubator status can allow us to do so, I 
would welcome this way of operation. As I wrote in another mail, in this 
case we should export the code from the OOO340m1 milestone, apply my 
list of "naughty" files to remove them and see what adjustments in the 
build this will cause. In the meantime we also can continue to look for 
more "naughty" files.

We also have to check how to deal with "external" source tarballs we 
used to pull in before the build starts (this happens in the "bootstrap" 
step). My recommendation is to do it in the same way: create the first 
build with all of them and remove the LGPL stuff step by step, adding 
configure switches to allow for optional builds in case they don't exist.

Regards,
Mathias