incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: What is the legal basis for enforcing release policies at ASF?
Date Fri, 21 Aug 2015 16:12:06 GMT
On Fri, Aug 21, 2015 at 10:51 AM, Jim Jagielski <jim@jagunet.com> wrote:

>
> > On Aug 20, 2015, at 11:19 PM, William A Rowe Jr <wrowe@rowe-clan.net>
> wrote:
> >
> > On Thu, Aug 20, 2015 at 8:52 AM, Jim Jagielski <jim@jagunet.com> wrote:
> >
> >>
> >> A snapshot is not a release. Licenses "kick in" at distribution/
> >> release.
> >>
> >
> > Lets just imagine if Jim, VP Legal is actually correct in his
> > interpretation, and that there are no AL 2.0 licenses applicable to our
> > source code repositories, svn or git.
> >
>
> I did NOT SAY that... holy moley. I said that licenses kick in
> at a release, but I not not say that they don't kick-in at
> other times; also, a release is guaranteed to be under ALv2
> (it is our "work") and there is no guarantee on said snapshot,
> depending on how it is created.
>

Ok, so a license applies to the release.  A license applies to the sources
in SVN, to the sources in snapshots, ad nasuem...

A license also applies to the snapshot.  I'd suggest that all
snapshots/nightly builds etc, any of them distributing ASF code, have to
carry the COPYRIGHT and NOTICE that any other distribution is required to
have.  They must be present in the source control tree.  Leaving out the
LICENSE and NOTICE from a non-release is no more correct than leaving them
out of the release itself.  But the "kick in" meme doesn't serve us well.

Back to the top-post, enforcing that any releases from any packager
correspond to what we've published as an ASF release, that authority comes
from asserting our marks, and we spell out how we enforce this in AL 2.0
section 6.  But the question of what is "close enough" to the ASF release
and what is arguably confusing to users is really up to the individual
PMC's because only they are familiar with their users expectations and what
constitutes a fork, vs. a practical distribution of the source code they
released. We offer reasonable leeway to distributors at the apr and httpd
projects and haven't run into too much confusion...

...except in one case, we did have an external entity shipping
pre-release-vote binaries without clarifying that these were not releases.
They were asked to stop, and voila, that entity is now a much more
respected member of the extended community, just because we asked and they
obliged.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message