Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of dennis.hamilton@acm.org
 designates 75.98.160.130 as permitted sender)
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: <ooo-dev@incubator.apache.org>
References: 
 <CAP-ksogrPV9RWOvDGEUJv4w+K77NbnyGnn8WzN7SxHXHgS2tHw@mail.gmail.com>
 <4E83040D.7000601@gmx.net>
In-Reply-To: <4E83040D.7000601@gmx.net>
Subject: RE: A systematic approach to IP review?
Date: Wed, 28 Sep 2011 15:42:36 -0700
Organization: NuovoDoc
Message-ID: <014a01cc7e2f$ec424330$c4c6c990$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQJX/plZxsSWPrJQxMFxj9coWsGgowEiK9tIlENFM3A=
Content-Language: en-us

It is unlikely that machine-generated files of any kind are =
copyrightable subject matter.  I would think that files generated by =
Visual Studio should just be regenerated, especially if this has to do =
with preprocessor pre-compilation, project boiler-plate (and even =
build/make) files, MIDL-compiled files, resource-compiler output, and =
the like. =20

(I assume there are no MFC dependencies unless MFC has somehow shown up =
under VC++ 2008 Express Edition or the corresponding SDK -- I am behind =
the times.  I thought the big issue was ATL.)

Meanwhile, I favor what you say about having a file at the folder level =
of the buildable components.  It strikes me as a visible way to ensure =
that the IP review has been completed and is current.  It also has great =
transparency and accountability since the document is in the SVN itself. =
 It also survives being extracted from the SVN, included in a tar-ball, =
etc.  In short: nice!

 - Dennis

-----Original Message-----
From: Mathias Bauer [mailto:Mathias_Bauer@gmx.net]=20
Sent: Wednesday, September 28, 2011 04:25
To: ooo-dev@incubator.apache.org
Subject: Re: A systematic approach to IP review?

On 19.09.2011 02:27, Rob Weir wrote:

> 1) We need to get all files needed for the build into SVN.  Right now
> there are some that are copied down from the OpenOffice.org website
> during the build's bootstrap process.   Until we get the files all in
> one place it is hard to get a comprehensive view of our dependencies.

If you want svn to be the place for the IP review, we have to do it in=20
two steps. There are some cws for post-3.4 that bring in new files.=20
Setting up a branch now to bring them to svn will create additional work =

now that IMHO should better be done later.

>
> 2) Continue the CWS integrations.  Along with 1) this ensures that all
> the code we need for the release is in SVN.

see above

> e) (Hypothetically) files that are not under an OSS license at all.
> E.g., a Microsoft header file.  These must be removed.

I assume that you are talking about header files with a MS copyright,=20
not header files generated from e.g. Visual Studio. In my understanding=20
these files should be considered as contributed under the rules of the=20
OOo project and so now their copyright owner is Oracle.

> 5) We should to track the resolution of each file, and do this
> publicly.  The audit trail is important.  Some ways we could do this
> might be:
>
> a) Track this in SVN properties.
IMHO this is the best solution. svn is the place of truth if it comes=20
down to files.

The second best solution would be to have one text file per build unit=20
(that would be a gbuild makefile in the new build system) or per module=20
(that would be a sub folder of the sub-repos). The file should be=20
checked in in svn.

Everything else (spreadsheets or whatsoever) could be generated from=20
that, in case anyone had a need for a spreadsheet with >60000 rows=20
containing license information. ;-)

Regards,
Mathias