www-legal-discuss 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: Non OSI approved licenses
Date Wed, 03 May 2017 18:24:09 GMT
On Wed, May 3, 2017 at 11:03 AM, Jim Jagielski <jim@jagunet.com> wrote:
>> On May 3, 2017, at 8:54 AM, Christopher <ctubbsii@apache.org> wrote:
>> For what it's worth, the *only* reason I initially considered ALv2 for my own projects
and recommended it to my employer for theirs, before I started contributing to Apache software,
was because it was approved by both OSI and FSF. I doubt I'm not alone in that.
> No, you are not. In my somewhat "extensive" travels, it is quite
> common that licenses not approved by OSI and/or FSF are
> simply Not Allowed. My point has always been that it would
> be a dead shame, and I would imagine quite a surprise, if
> people found out that we include/depend on s/w that is not
> so licensed.
> I know, for example, that Capital One would not approve the
> use of any ASF software that has a non-OSI approved licensed
> s/w component lumped in. I also know that they would be quite
> "alarmed" by it as well, since this type of stuff is not
> expected by traditionally "safe" ASF code.

So to disassemble this specific example, an ASF Foo package
with the the third-party Bar component, which of two paths should
we elect moving forwards?

You seem to suggest we simultaneously beg the Bar project to
re-license with a familiar OSI recognized license (you did this
successfully with nghttp2), beg the OSI for license recognition
of Bar's license (I can't recall when this last happened), and
reject the appeal for the ASF Foo project to utilize the Bar
component until one of those two events occurs. This would
be an ASF policy change.

Others have suggested that we simultaneously beg the authors
of Bar project to re-license with a familiar OSI recognized license,
yet evaluate Bar's license on its own merits, and approve the JIRA
ticket to accept that license provided that the ASF judges the license
to be compatible with the AL 2.0 (which by also means that this
license likely meets the OSD.) This is the current model; yours has
been the one voice to change 20 years of precedence.

Roy seems to suggest it was always the businesses' business
of accepting the Bar project's license and in this case, Capital One
delegates the decision to the OSI. So it is up to them to ask OSI
to evaluate and reach it's own decision to declare the license
compatible with the OSD or grant OSI recognition. The ASF Foo
project champions or prospective Captial One users could point
the OSI to the ASF's JIRA ticket which evaluated and judged the
license of the Bar component to be compatible with the AL 2.0.
And the ASF Foo project can elect to drop that Foo project
dependency if the OSI is intractable, and they want to enjoy
potentially wider adoption.

The ASF Bar PMC in this example should be the arbiter of how
to handle the conflict, not the ASF organization, and not the OSI.
The ASF organization is simply the best judge of what licenses
are compatible and which are incompatible with the AL 2.0, but
once that JIRA ticket is evaluated as compatible, it's back to the
PMC's hands whether the OSI recognition is important or not.

To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message