And per > (1) We would slowly work to replace our existing license headers with > this new standard license header. (Or, if possible, do a giant bulk > replace of our existing headers for the 1.7.0 release)
The license:format plugin in the dspace-pom will facilitate this batch across the entire project. This is how all the projects under "modules" should probably always be configured... it automates all licensing header inclusion. > (2) We would move our current DSpace LICENSE file to our root of our > source tree, and add a corresponding NOTICE file which details the > latest DSpace copyright info (and update Maven references as needed) Theres already one that Brad and I worked on here: http://scm.dspace.org/svn/repo/licenses/ Your free to adjust as the organization sees fit. > (3) I would work to get our DSpace license & copyright info also > displayed publicly at 'http://dspace.org/license/' (as that URL > currently doesn't exist) Sounds good... Mark On Jun 11, 2010, at 10:41 AM, Mark Diggory wrote: > +1 > > We came up with the more concise format last year to reduce the amount of > commenting at the top of the files and to standardize the licensing includes > int he maven release process. The new dspace-pom projects assure that > licensing is always validated on all the files prior to release. > > I will second the "even more succinct license header" idea. And I will add > that we should remove the svn keyword replacement and place it elsewhere. > The maven license formatting plugin we are using to generate the licenses > when they are absent is "coughing" on the keyword replacement which makes us > have to run mvn license:format prior to mvn release. > > Mark > > On Jun 11, 2010, at 9:46 AM, Tim Donohue wrote: > >> All, >> >> Just thought I'd bring this up while it's fresh in my mind. A few of us >> in DuraSpace got into a license header discussion, and it made me >> re-discover our current DSpace license header situation. >> >> Most of our codebase still uses the policy of including the entire >> license as a header in a source file. For example: >> http://scm.dspace.org/svn/repo/dspace/trunk/dspace-api/src/main/java/org/dspace/core/Context.java >> >> However, I've noticed that several of our newer projects (including 2.0 >> work) use a shortened license header (which links off to a full license >> available elsewhere). For example, in dspace-services we see: >> http://scm.dspace.org/svn/repo/modules/dspace-services/trunk/api/src/main/java/org/dspace/kernel/DSpaceKernel.java >> >> In a quick comparison across the DuraSpace projects, we realized that >> Fedora uses a much small (less likely to change) comment at the top of >> its code. Here's Fedora's standard header: >> >> /* >> * The contents of this file are subject to the license and copyright >> * terms detailed in the license directory at the root of the source >> * tree (also available online at http://fedora-commons.org/license/). >> */ >> >> That sort of small header is nice as it requires less frequent >> modifications. You'll notice it doesn't even contain the copyright >> statement, which tends to include changing years, and sometimes even a >> changing organization name -- e.g. much of our java code still says >> "Copyright DSpace Foundation", when it should now obviously say "DuraSpace". >> >> To this end, DuraSpace would like to recommend changing to a shorter, >> standard license header at the top of each source code file. We mocked >> up a "standard" DuraSpace license header to be: >> >> /* >> * The contents of this file are subject to the license and copyright >> * detailed in the LICENSE and NOTICE files at the root of the source >> * tree and available online at >> * >> * http://<project>.org/license/ >> */ >> >> (NOTE: None of our DSpace licensing or copyright info is changing, >> obviously. We're just trying to standardize our headers a bit better, >> and cleanup old out-of-date headers in our codebase.) >> >> Should we (DSpace developers) approve this idea, this would mean three >> things for DSpace: >> (1) We would slowly work to replace our existing license headers with >> this new standard license header. (Or, if possible, do a giant bulk >> replace of our existing headers for the 1.7.0 release) >> (2) We would move our current DSpace LICENSE file to our root of our >> source tree, and add a corresponding NOTICE file which details the >> latest DSpace copyright info (and update Maven references as needed) >> (3) I would work to get our DSpace license & copyright info also >> displayed publicly at 'http://dspace.org/license/' (as that URL >> currently doesn't exist) >> >> Again -- this is just a recommendation we are putting forward for >> comments/suggestions. >> >> I'll also add this as a discussion topic for our next Developers Meeting >> (Weds, June 16 at 20:00UTC in #duraspace IRC). So, if you will be able >> to attend that meeting, you are welcome to hold your comments until then. >> >> In the meantime, feel free to comment on this idea in this thread on >> dspace-devel, or send me an email with your thoughts. >> >> Thanks all! >> >> - Tim >> >> -- >> Tim Donohue >> Technical Lead for DSpace Project >> DuraSpace.org >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Dspace-devel mailing list >> Dspace-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dspace-devel > ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
