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 ;).
Cheers,
Pedro.
On Wed, 31 Aug 2011 09:22:46 -0400, Rob Weir <[email protected]> wrote:
On Wed, Aug 31, 2011 at 3:42 AM, Mathias Bauer
<[email protected]> 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
