incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: [Repo][Proposal]After the code is checked in to SVN
Date Wed, 31 Aug 2011 16:29:02 GMT
For (3) If we do check-ins of changes against compatibly-licensed source, we are potentially
doing check-ins under that license.   So we need to be careful there too.  There is more ceremony
required to embrace compatibly-licensed code than the simple procedure for the SGA code (1
and eventually 2).

The procedures for third-party code apply.  That may have been attended to by Sun/Oracle in
their handling of the THIRDPARTYLICENSE notices and files.  I don't know how it was handled
with regard to the source code itself.  We need to walk softly.

 - Dennis

-----Original Message-----
From: [] On Behalf Of Rob Weir
Sent: Wednesday, August 31, 2011 06:23
Subject: Re: [Repo][Proposal]After the code is checked in to SVN

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?


> Regards,
> Mathias

View raw message