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.
(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
