On 1/29/07, Bob Buffone <[EMAIL PROTECTED]> wrote:
Some clarification, if it can't be included in a release can it still be store in SVN?
this is a little bit complicated and involves legal, policy and best practice but i'll do my best to attempt an explanation (at least as i see them). these are just my personal opinions: i'm not speaking with my mentor's hat on. apache projects need to exercise legal oversight in particular, this means checking that apache has the appropriate rights required to distribute any document which is stored in the repository. before a commit is made, the committer needs to be sure that they have the rights required for the document. the other committers (and in particular the PMC) need to read the commit logs and check that this is the case. this is why headers and commit messages are important all original code that is created by a committer for apache is covered by their CLA and should have the header. any code that is not an original contribution by the committer should have it's origin noted in the commit message. this allows the origin to be traced later. (i've had questions about code arise five years after the original commit.) for example, when i commit a JIRA patch, i say something like "Foo bar function. Really cool. Contributed by A.N.Other. http://issues.apache.org/JIRA/etc/etc";. the apache license version 2 means that code submitted through JIRA is sublicensed to apache unless explicitly excluded (though it's polite to confirm this). so contributions through JIRA should have apache headers. whenever a committer sees a commit message without a header then the content needs to be checked. if anyone doesn't know the license and the origin of a document without a header: ask! (the traditional way is to reply to the commit message.) oversight of legal issues is important and crucially important when creating official releases. it is nearly impossible for apache to withdraw releases once distributed. so, the potential legal liability is much higher. so, check when documents are contributed but audit before the release. mistakenly committed proprietary documents are usually easy to spot (or next to impossible if a contributor misrepresents their origin). more subtle legal issues arise when a document is distributed under a license. it's easy for issues to arise. questions of interpretation often arise. it is often necessary to keep track any modifications made to the document as well as the origin. in this case, following apache policy and best practice makes things easy. if you stick to the approved licenses and avoid importing source, then the apache legal team has done the hard thinking. apache policy tends to work from the principal of respecting rights and making the job of license auditing apache code as easy as possible. users trust apache to provide legally clean source that can be used and modified safely. this reputation has been hard earned. many organizations downstream give blanket approval to apache since our products have known and uniform legal characteristics. one hard aspect to understand about apache policy is that it's not set in stone: it's a living, evolving consensus. unfortunately, we're haven't been very good at writing things down so there's often a lot of asking involved. if a situation isn't covered by documentation, search the archives for legal discuss or post a question there. in the incubator, the elements of policy that are not legally important are loosened at the start. it's ok to have documents in the repository which are ok from a legal perspective but not from a policy one. however, a podling can't graduate without complying with policy. this is a difficult line since some policy is about the interpretation of licenses. apache tries to avoid trouble and respect other people intentions. for example, the apache policy is to respect the FSF's views on license compatibility even though we differ on the likely legal interpretation of their licenses. when there's any doubt, ask (the right list is legal discuss). finally, there's best practice. it ok from a policy perspective to have DoJo documents in the repository. i would recommend thinking about whether it's really the best practice maintaining a local fork. if the source is in the repository then there's a chance that it may drift away from the original. it's almost always better to work with upstream library creators than to maintain local forks. but this is just something for the community to think about... to summarize, for a podling, all documents in the repository must be ok legally, should be ok from a policy perspective and may be ok from a best practice perspective. this same is true for a release (but there may be some legal differences). so, my answer (to the original question) is possible yes but it's a bad idea :-) - robert
