incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryant Luk <bryant....@gmail.com>
Subject Re: [VOTE] Release Wink 1.0
Date Tue, 27 Oct 2009 21:23:32 GMT
Hi Leo,

Thanks for the links.  One general comment I have is that I understand
this is part of the incubation process (and no offense intended to Leo
since obviously taking energy and time for this) but if I can't look
and see if other Apache projects are doing things the right way, I
think we should have more examples of what goes in the NOTICE and
LICENSE files and points out licenses/situations/projects/wording that
require that they be put in LICENSE/NOTICE files and not.  It seems to
be a common sticking point on this list for incubator projects.  I
would put up a patch for the website but obviously I am still
learning.

On Tue, Oct 27, 2009 at 2:37 PM, Leo Simons <mail@leosimons.com> wrote:
> On Tue, Oct 27, 2009 at 4:45 PM, Bryant Luk <bryant.luk@gmail.com> wrote:
>>> The source release has a LICENSE and a NOTICE file that indicates it
>>> contains a bunch of stuff it does not actually contain. AFAICS it
>>> should simply have a LICENSE that is just the Apache License and a
>>> NOTICE file that has just our standard license header.
>>
>> I think you're suggesting a different LICENSE/NOTICE for source versus
>> binary distributions.
>
> Yep, I see how it looks like that....though maybe I'm _really_
> suggesting a source-only distribution :-)
>
> Look, the general rule is quite simple: LICENSE files MUST contain all
> the license information that applies to an artifact, and SHOULD
> contain only the license information that applies to that artifact.
> Similarly, NOTICE files MUST contain all the notices that apply to an
> artifact, and SHOULD contain only the notice information that applies
> to that artifact.
>
> Whenever you violate that SHOULD, you are turning lazyness/sloppiness
> into a mess for your users.
>
> For example, with this current wink distribution, you are (appear to
> be?) passing on a lot of CDDL obligations down to wink users, which is
> annoying to users that care about such things. If all your user wants
> to do is copy/paste the glue code from GzipHandler, that's a rather
> heavy license to wade through. Similarly, that user of that
> GzipHandler code now has to copy/paste the entire contents of the
> NOTICE file.
>
> Do you really want to place a burden on your users like that?

I wouldn't, however just out of curiosity, how does this apply with
Section 4.4 of the Apache license?

"If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained within
such NOTICE file, excluding those notices that do not pertain to any
part of the Derivative Works, in at least one of the following places:
within a NOTICE text file distributed as part of the Derivative
Works;"...

I would consider that a copied portion of just the Apache Wink code to
be a Derivative Work, and none of the other NOTICE attributions (CDDL)
apply to the user (hence excluding those notices so their NOTICE file
is relatively brief).  I'm not a lawyer but just want some
clarification for this "use case" for personal knowledge.

>> I did some random checking looking at some
>> source versus binary Apache project distributions (incubator and
>> non-incubator) and as far as I can tell, they kept their same LICENSE
>> and NOTICE files even though they were not re-distributing the
>> dependency binaries in the source archive.
>>
>> Don't mean to say we should just follow the crowd, but I don't think
>> this is standard practice unless another thread has a viewpoint on
>> this.
>
> Unfortunately, most apache projects are not as good at following
> policies as they should be, and most engineers (including me! :-) )
> are not nearly as good at applying legal rules and guidelines as they
> should be.

Agreed.

> http://www.apache.org/dev/release.html#license
>
> "What Are The Requirements To Distribute Other Artifacts In Addition
> To The Source Package?
> ...
> Nothing in this section is meant to supersede the requirements defined
> <here> and <here> that all releases be primarily based on a signed
> source package."
>
>>> The NOTICE file for the binary release should include only those
>>> notices that are actually required by the included library
>>> dependencies, and they should reproduce the exact text of those
>>> notices. For example, the slf4j notice line should not be there since
>>> slf4j does not require it.
>>
>> I see varying degrees of attribution to slf4j in other Apache
>> (incubating and non-incubating) projects (some have none, some have a
>> line).  The slf4j line was kept from the Wink 0.1 release.  IMHO, this
>> is not a release blocker, but we can remove it in a future release if
>> it is the right thing to do.
>
> Fortunately we have quite a clear rule on this topic these days, so no
> opinions are necessary:
>
> http://www.apache.org/dev/release.html#notice-content
>
> "What Content Is Appropriate For The NOTICE File?
> ...
> Only mandatory information required by the product's software
> licenses. Not suitable for normal documentation."
>
> For background color, here's an earlier thread on this list (which is
> where I learned about the existence of that clear rule):
>
> http://mail-archives.apache.org/mod_mbox/incubator-general/200909.mbox/%3Cf767f0600909090615t6582bfd1m36e4d8abe1392b23@mail.gmail.com%3E

Thanks for the link to the information.  However, I would like to get
a consensus to make sure that we should not be attributing SLF4J at
all.

http://slf4j.org/license.html

Just for reference, I see Geronimo and Cassandra attributing in:

https://svn.apache.org/repos/asf/geronimo/server/trunk/NOTICE
https://svn.apache.org/repos/asf/incubator/cassandra/trunk/NOTICE.txt

which I believe have been used in recent release votes.  I'm fine with
deleting/re-wording the attributions (afterall, less for us to
maintain) and hope not too troublesome but I would like some consensus
to make sure that this and future releases are right (without quotes
;-) ).

> cheers,
>
>
> Leo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message