incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: A systematic approach to IP review?
Date Wed, 28 Sep 2011 23:09:29 GMT
On Wed, Sep 28, 2011 at 6:42 PM, Dennis E. Hamilton
<> wrote:
> 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.

That is my understanding as well, wrt computer-generated files.
However the lack of copyright does not mean lack of concern.  For
example, some code generation applications have a license that puts
additional restrictions on the generated code.  Some versions of GNU
Bison, the YACC variant, did that.

> (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 []
> Sent: Wednesday, September 28, 2011 04:25
> To:
> 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 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
> two steps. There are some cws for post-3.4 that bring in new files.
> 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,
> not header files generated from e.g. Visual Studio. In my understanding
> these files should be considered as contributed under the rules of the
> 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
> down to files.
> The second best solution would be to have one text file per build unit
> (that would be a gbuild makefile in the new build system) or per module
> (that would be a sub folder of the sub-repos). The file should be
> checked in in svn.
> Everything else (spreadsheets or whatsoever) could be generated from
> that, in case anyone had a need for a spreadsheet with >60000 rows
> containing license information. ;-)
> Regards,
> Mathias

View raw message