www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefano Bagnara (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LEGAL-26) LICENSE and NOTICE in svn
Date Mon, 04 Aug 2008 16:26:44 GMT

    [ https://issues.apache.org/jira/browse/LEGAL-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619574#action_12619574
] 

Stefano Bagnara commented on LEGAL-26:
--------------------------------------

@Henri
Yes, my personal opinion is that "People shouldn't use code, or fork code, from SVN." or better
they can do that but we shouldn't "fool" them with a possibly not-up-to-date LICENSE/NOTICE
files. In my opinion the PMCs cannot ensure that the LICENSE/NOTICE that are in svn are correct
and updated all the time, otherwise we won't need a release procedure and we won't vote on
releases but on every commit. I would prefer to have a private svn server instead of having
to worry about keep updating every LICENSE/NOTICE file we have in every folder of the asf
repository (related: what is a folder wrt distributions?).

@David: I don't share your source definition. IMHO we release a source package, the fact that
we use an svn server to work on this sources does not make svn "the source". We don't release
svn tags, we release packages. In fact we (and I think most PMCs) vote packages, not svn tags.

> LICENSE and NOTICE in svn
> -------------------------
>
>                 Key: LEGAL-26
>                 URL: https://issues.apache.org/jira/browse/LEGAL-26
>             Project: Legal Discuss
>          Issue Type: Question
>            Reporter: Stefano Bagnara
>
> www.apache.org documentation/policy make it clear that we have to include a NOTICE/LICENSE
in released package, but a question raise from time to time in mailing lists and big discussions
about the need for a NOTICE/LICENSE in some svn folder.
> I personally don't like to have to do that and I don't share the legal references made
to justify the existence of this policy, but I agree that most people in the legal-discuss
thread back from january agreed on something along these line:
> -------
> expected svn checkout points are supposed to include LICENSE and NOTICE files at their
root covering everything in the checkout, and nothing else.  These should be kept up to date
via "best-effort" by the pmc and committers, and should definitely be accurate for svn tags.
> -------
> The problem with this sentence is "expected checkout" related to the "checkout points"
that is not so defined. Expecially with multimodule maven project: many times people simply
checkout a single module and not the whole project.
> Furthermore the "definitely be accurate for svn tags" is a problem: tags and branches
in svn are simple copies. If that sentence is needed I would suggest to replace it with "for
releases tags".
> Anyway my personal opinion/preference on this "policy" is worthless (I'm not a lawyer,
I'm not an ASF member, I'm a simple PMC committer), I just open this issue because I would
really like to see this policy, a similar policy or something telling there is not such a
policy about NOTICE and LICENSE in svn trees added to this page:
> http://www.apache.org/legal/src-headers.html
> references:
> http://markmail.org/message/jangmpbssvvd73az
> http://markmail.org/message/lbhyjzh5ynizhdx3

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message