incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eike Rathke <...@erack.de>
Subject Re: [Repo][Proposal]After the code is checked in to SVN
Date Wed, 31 Aug 2011 19:18:17 GMT
Hi Rob,

On Wednesday, 2011-08-31 09:22:46 -0400, Rob Weir wrote:

> It is a trade-off.  Right now I think the most important task is to
> review the IP of the code and get that fixed where needed.  Right now
> all code in the repository is in one of these categories:
> 
> 1) Files that are in the Oracle SGA
> 
> 2) Files that Oracle owns that are not in their original SGA but will
> need ot be in their new SGA
> 
> 3) Files that are from 3rd party open source modules, where the code
> has a compatible license
> 
> 4) Files that are from 3rd party open source modules, where the code
> has an incompatible license
> 
> 5) Files where we cannot establish accurately their origin or license
> 
> I think the priority should be to identify all files in categories #2,
> #4 and #5, so we can fix them.
> 
> If people are adding new code to the repository, that introduces a new
> category, of changes made by committers, under ALv2.  The complexity
> would be if they are modify or adding files that are in categories #2,
> #4, or #5.  If we can avoid that, then I don't see a problem.
> 
> What we want to avoid is having us review a given AOOo module, clean
> it up from IP perspective, and move on to another modules, and then
> have it recontaminated by merging in, via a patch or CWS integration,
> code that is dirty.

CWS integration can be of two categories:

a) CWS does not introduce new code covered by an incompatible license,
   should not give any problem other than merge conflicts if it touches
   code that was already removed for #2, #3 or #4. All other code newly
   introduced in such a CWS is covered by the SCA/OCA and hence also
   covered by the SGA, if I understood correctly.

b) CWS does introduce new code covered by an incompatible license, will
   pollute the tree anyway and those code parts will have to be removed.

So, we can choose:

x) first identify and remove license incompatible code to be pointed to
   clashes when the CWSs will be integrated, additionally lookout for
   new license incompatible code when integrating CWSs thereafter, or

y) first integrate all CWSs, note down new license incompatible code the
   CWS introduces, and after all CWSs are integrated start the clean-up
   of the entire tree. CWSs rarely introduce new external code, so new
   code that would be covered by an incompatible license should be an
   exemption.

I'd favour y) because we wouldn't have to deal with additional merge
conflicts as would be the case with x).

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

Mime
View raw message