incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: [VOTE] Release Wink 1.0
Date Tue, 27 Oct 2009 22:10:39 GMT
On Tue, Oct 27, 2009 at 9:23 PM, Bryant Luk <> wrote:
> 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.

Yeah it's painful isn't it? "How to get the legal stuff right" remains
surprisingly difficult after all these years. Help making it easier is
always very welcome! [1]

>> 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.
> just out of curiosity, how does this apply with
> Section 4.4 of the Apache license?

Ooh, you're getting into this now, eh? Good :-)

IANAL, I don't really know. I suspect the precise nitty-gritty legal
case is actually a little more lenient than our policies. As in, even
if legally all is sound whatever way, our release policies try to
enforce some additional clarity and consistency to make things as easy
as possible for the user.

>> "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):
> 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.

In an artifact that does not contain SLF4J (like your source distro),
do not attribute (at all).

In an artifact that does contain SLF4J (like your binary distro),
well, see to figure out
that no-one is really that sure. If you look at HTTPD, it has the
expat license (which is MIT) inside its LICENSE file:

but no mention about it in its NOTICE file:

Is that ok? Probably. Is that the *only* right way? Not so sure. My
personal rule is that "when in doubt do what Roy voted +1 on" is not a
bad strategy when it comes to licensing stuff [2].

> 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
> ;-) ).

Please note, I didn't actually vote on the release, I just pointed out
a few things that probably ought to change. I didn't vote because I
don't want to go and review all those very many binaries (or the build
process that creates them) and I'm not familiar enough with the
codebase to somehow "know" that all those binaries are somehow ok. If
I had thought these minor tidbits that I raise are enough to actually
vote -1, I would've made that clear, sorry that it wasn't.

Even if I _did_ vote, releases are majority votes, and 2 +1 beats a
single -1. Its just you need 3 votes.

In other words, all you need is one more +1 :)



[1] Oh, and for reference, my first encounter with apache licensing
policy was when someone had imported the entire codebase of some
non-apache project into apache CVS, stripped all the license headers
including copyright info, and replaced them with apache ones. We got a
polite note from the original projects' owners to fix that pretty
please. We got spanked around pretty bad for that one at the following
apachecon, and then we all had lots of beer :)
[2] there is another rule, "have whatever Greg is having, though less of it"

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message