Hi Robert,

I just went through this exercise with another project, and I now believe best practice is to import the files with the original copyright notices intact and then as part of the evolution of the project, modify the files to the new Apache headers, moving the copyright notices to the NOTICE file at the root of the svn repo.

I'd even go farther and say that best practice is to import the files with their original package names (Java projects) even though they will subsequently be moved to a new location in svn. The svn commit notice should have a comment to the effect of "Initial import to Apache with original license headers" so nit-pickers don't complain about checking code into Apache with wrong license headers (me guilty).

I think it's less important exactly where the files are checked in originally. It might be best practice to check them directly into a <project>/trunk/import/src/ directory, change the headers, svn copy them into place (renaming them to the correct file names) and finally change the package names inside the files.

This practice allows folks who are doing due diligence to see the code provenance in the Apache repository without having to scour the internet trying to find the original code. And anyone, including those with a copyright interest in the original code, can see exactly what happened.

Craig

On Mar 13, 2008, at 1:20 PM, Robert Burrell Donkin wrote:

i'm trying to pull together some best practice documentation for the initial code import. i'm going to throw some (quite possibly incoherent) opinions out there to start discussion but if anyone has opinions feel free to ignore
the strawman...

IMO the original sources covered by the appropriate agreement should be available as part of the public record of the project. JIRA most likely covers this. checking in the unconverted code most definitely covers this (where? into a stage/inport directory? into position?). it is better to
convert the originals outside and commit only cleaned up code to the
repository? (this has the advantage that uncleaned code is not committed to
the code stream). useful tools for relicensing (i know about those in
committers)?

- robert

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to