On Wed, Sep 28, 2011 at 6:42 PM, Dennis E. Hamilton <dennis.hamil...@acm.org> 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 [mailto:mathias_ba...@gmx.net] > 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 > 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 > >
