incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: What is the legal basis for enforcing release policies at ASF?
Date Fri, 21 Aug 2015 01:42:15 GMT
On Aug 20, 2015 8:19 PM, "William A Rowe Jr" <> wrote:
> On Aug 20, 2015 7:39 PM, "Alex Harui" <> wrote:
> >
> >
> >
> > On 8/20/15, 5:27 PM, "William A Rowe Jr" <> wrote:
> >
> > >It is generally AL code all the time.  I don't know where you invented
> > >'kick-in' concept, but unless the committers are violating their
> > >nothing could be further from the truth.
> >
> > Committers sometimes make mistakes.  IIRC, Justin recently caught a
> > mistake where some files accidentally got their non-AL headers replaced
> > with AL headers.
> >
> > Large codebase contributions, especially initial podling code grants
> > be messy as well until scrubbed and approved for an official ASF
> > I know from experience.
> We don't disagree on this point.  Sometimes, they are caught through the
release process, or by peer review.  Other times, we must retract the claim
we offered.
> Nothing changes the fact that code is either offered under the AL 2.0 or
another license, unless the author/licensor changes their license

Your comment also hones in on the logical fallacy our VP fell into... While
it may be true that the ASF granted its own AL 2.0 license to the release
package, the ASF is unable to change component licenses in incompatible
ways.  And the warranty the ASF offers on an inaccurate license claims is -
nil - c.f. AL 2.0

However, if our repositories are under another license, that VP needs to
make public this information, because I never got the memo, and I must
notify friends and the many companies I advise and consult to that they all
need to cease looking at the ASF's repositories, and let their respective
legal departments each sort this all out, if those repositories are
licensed with terms and conditions differing from the AL 2.0.

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