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-27) LICENSE/NOTICE content vs package content
Date Tue, 05 Aug 2008 15:38:44 GMT

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

Stefano Bagnara commented on LEGAL-27:
--------------------------------------

@Martijn: I see 2 issues with current Wicket solution and current answers from Henri to LEGAL-26
and LEGA-27.

#1. Henri, here, is saying that LICENSE/NOTICE must be up-to-date also in trunk and not only
in releases. So if you have a mean to generate it you have also to make sure you generate
it every time you change something in each sub module and not only at release time (I would
hate such a policy, but that's what we are discussing here..).

#1b. Furthemore I see your NOTICE file say that you include slf4j, but I don't see slf4j in
the tree. So you don't include it, and it should only be referenced in packages including
the slf4j,jar (e.g: a binary with runtime dependencies) if you want to follw what Henri say
in his comment.

#2. I see you release a single artifact including sources and binaries: I think this is not
what ASF suggest, but this may be the right approach to avoid having to deal with multiple
LICENSE/NOTICE (one tuple for the binary with runtime dependencies, one tuple for the source
with compile dependencies or one for the sources with no dependencies included). On the other
side see #1b because you mix binary/source distribution but you don't bundle dependencies
(If I don't miss anything)

I also see further issues in some random artifact I checked:
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/wicket/wicket-spring/1.4-m3/wicket-spring-1.4-m3-sources.jar
This does not contain NOTICE/LICENSE.

http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/wicket/wicket/1.4-m3/wicket-1.4-m3.jar
This include a NOTICE saying that the package include slf4j, but it is not true (same as #1b)
Furthermore the NOTICE include a reference to "[2]: licenses/sun-u.c.license.pdf " but this
file is not in this package.

http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/wicket/wicket/1.4-m3/wicket-1.4-m3-sources.jar
This does not contain NOTICE/LICENSE: AFAIK this is critical, even if this is not related
to this specific LEGAL issue.

http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/wicket/wicket/1.4-m3/wicket-1.4-m3-tests.jar
This file include the same NOTICE/LICENSE of the main jar. I bet some of the "This software
include" you listed are only appropriate for the main jar and not for the test.jar, e.g: org.apache.wicket.util.io.IOUtils
is declared in NOTICE but is not in this test jar.

And I probably could continue with more issues... What I want to raise is that the policy
that we are going to define is too difficult to be strictly followed, so let's think twice
and define a policy that people will be able to follow without working 90% of their ASF time
againt the LICENSE/NOTICE files.

I'm frustrated by the LICENSE/NOTICE issue because every time my PMC try a release there are
plenty of policies or requirements that are raised, but then I see 90% of them are followed
only by 10% of ASF projects.


> LICENSE/NOTICE content vs package content
> -----------------------------------------
>
>                 Key: LEGAL-27
>                 URL: https://issues.apache.org/jira/browse/LEGAL-27
>             Project: Legal Discuss
>          Issue Type: Question
>            Reporter: Stefano Bagnara
>
> Most apache releases included a LICENSE/NOTICE tuple (I will refer to them as LICENSE/NOTICE
tuple to make it easier, even if they deserve different treatment sometimes) including references
to every 3rd party work in that svn tree. This LICENSE/NOTICE tuple was then added to every
package released from that tree even if some of the packages created didn't really include
all of the work referenced there.
> To my understand this was the standard accepted practice until a broader maven adoption.
Using maven most projects started releasing jar-packages (and not only the bin/src packages)
so the question about the LICENSE/NOTICE oversized content came out.
> If people agree that is good to have a NOTICE/LICENSE specific to each release I think
it should be written in a policy but I would hope this is not enforced because this would
probably be a cause for limiting the number of packages released (creating a new assembly
for the same work is much less work than mantaining a special NOTICE/LICENSE for it).
> Here is the "practice" as described by David Jencks to me:
> ----
> released artifacts should include LICENSE and NOTICE files applying exactly to their
content.   If this goal is not achieved, its better to have unnecessary stuff in the LICENSE/NOTICE
files than missing stuff.
> ----
> The introduction of the 1.4 version for org.apache:apache-jar-resource-bundle changed
the LICENSE/NOTICE added to jars to not include dependencies by default, so people upgrading
from 1.3 will ask this again and again.
> A clear policy IMHO is also a good way to let some smart people create/improve maven
plugins to better manage what the policy says. No written policy means that we all do what
the plugin developer prefererred ;-) (kudos to plugin developers)

-- 
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