openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <>
Subject Re: [Repo][Proposal]After the code is checked in to SVN
Date Wed, 31 Aug 2011 14:42:03 GMT
 Hi Rob;

 The FreeBSD fixes surely won't introduce IP problems and have
 been up for review in bugzilla for a while, so I would think
 your comment is not (dis)regarding the FreeBSD port, but
 just concerning the general issue of adding new code.

 Now, I understand IBM has some replacements for copyleft
 components, could you give us some insight on that to reduce
 duplicated work?

 Also you are now probably aware that Symphony (and LO) should
 be including a copy of the lcc CPYRIGHT file ;).



 On Wed, 31 Aug 2011 09:22:46 -0400, Rob Weir <> wrote:
> On Wed, Aug 31, 2011 at 3:42 AM, Mathias Bauer 
> <> wrote:
>> Am 30.08.2011 19:08, schrieb Maho NAKATA:
>>> Hi Mathias,
>>> Is it the time to push FreeBSD patches?
>>> Now I'm at Dener to attend a conference, and just now my talk has 
>>> finished.
>>> I'll work when I go back to Japan. Maybe next Monday or so.
>> Building on FreeBSD surely is important - and if the patches are
>> necessary to enable further contributions from your side we should
>> integrate them better sooner than later. I would like to see other
>> opinions here, especially from those who are afraid that we might do 
>> too
>> much things at a time.
> 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.
> So maybe the general rule should now:  Don't check it in unless you
> are sure the file is either ALv2 or a compatible license?
> -Rob
>> Regards,
>> Mathias

View raw message