Return-Path: Delivered-To: apmail-commons-issues-archive@locus.apache.org Received: (qmail 94137 invoked from network); 4 Jan 2008 18:08:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Jan 2008 18:08:56 -0000 Received: (qmail 90730 invoked by uid 500); 4 Jan 2008 18:08:45 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 90238 invoked by uid 500); 4 Jan 2008 18:08:44 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 90228 invoked by uid 99); 4 Jan 2008 18:08:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Jan 2008 10:08:43 -0800 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Jan 2008 18:08:29 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 470987141F1 for ; Fri, 4 Jan 2008 10:08:34 -0800 (PST) Message-ID: <12492531.1199470114287.JavaMail.jira@brutus> Date: Fri, 4 Jan 2008 10:08:34 -0800 (PST) From: "Simon Kitching (JIRA)" To: issues@commons.apache.org Subject: [jira] Commented: (COMMONSSITE-21) commons-parent-6 pom changes In-Reply-To: <25419103.1197338983463.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/COMMONSSITE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556003#action_12556003 ] Simon Kitching commented on COMMONSSITE-21: ------------------------------------------- Yes, it does seem that there is no official policy on license/notice files in svn. However I'm not convinced by the argument that since any dir can be checked out, there is no logical place to put license/notice files in svn. The svn contents are very clearly structured into modules which are "compilable units". Yes, theoretically someone could check out some leaf directory then claim that the files "have no license information available", but that's a pretty thin excuse. Anyone capable of reusing java code would know where the module ("compilable unit") starts. That is the sensible point at which to check things out - and the license/notice info should be available at that level. It's just like putting copyright info inside the cover of a book. It doesn't need to be on every page, because the book is the minimum distributable unit. But in the case of a book series, it is not adequate to put the information in just one of the books in the set. Ok, the analogy isn't perfect because books do not have a "raw" and "compiled" form both available to users. But making source code available on the web via svn *is* publishing, and so notice/copyright should be available there too, without requiring someone to look into a pom and determine where a maven plugin will pull the information from during a build. > commons-parent-6 pom changes > ---------------------------- > > Key: COMMONSSITE-21 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-21 > Project: Commons All > Issue Type: Improvement > Components: Commons Parent Pom > Reporter: Niall Pemberton > Attachments: commons-valdiator-generated-NOTICE.txt, COMMONSSITE-21-commons-parent-pom-v1.patch, COMMONSSITE-21-commons-parent-pom-v2.patch > > > Opening this ticket to discuss changes for Version 6 of the commons-parent pom. > See thread: http://tinyurl.com/39eo9z for related discussion/issues -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.