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
signature.asc
Description: Digital signature
