incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eike Rathke <...@erack.de>
Subject [code][repo] Integration of CWSs
Date Tue, 06 Sep 2011 16:50:52 GMT
Hi,

And now for something completely different: CODE

As lined out in

Message-ID: <20110831191817.GF29051@kulungile.erack.de>
http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3C20110831191817.GF29051@kulungile.erack.de%3E

there are 2 possible approaches to integrate pending CWSs and I favoured
one of them. I've seen no response to that other than Pedro's, maybe my
suggestion was buried too deep in that thread and people are too busy
with fighting over forum and documentation governance. I'm tired of
wading through those piles of mails wasting the project's time and
efforts and putting people off. In the mean time -- I'm referring a time
span of more than the last week that passed since my mail -- we could
have had the CWSs integrated, identified copyright/license problematic
bits of code, and maybe even found some solutions for copyleft code
removal to get things going.

I offered my help with the CWSs since the beginning, hoping that the
code repository would had been there much earlier. Summer here was
almost non-existing with weather conditions just right to keep me
indoors, but now I will focus on other things, spare time life is short
enough and can be enjoyed.. as for my part that means I'll enjoy staying
away from computer keyboards for some time starting next week and have
fun under the sun.

For reference, here the body of the mail mentioned above:

| 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