Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
MIME-Version: 1.0
References: <0ACD0AAF-BE23-4039-83B7-DD7519A1CBC8@jaguNET.com>
In-Reply-To: <0ACD0AAF-BE23-4039-83B7-DD7519A1CBC8@jaguNET.com>
From: Christopher <ctubbsii@apache.org>
Date: Fri, 28 Apr 2017 12:55:51 +0000
Message-ID: <CAL5zq9bn5L-c81ezB11KcC8LN7K4W6oVGBJa1ZHov3-56aq-cQ@mail.gmail.com>
Subject: Re: Non OSI approved licenses
To: legal discuss <legal-discuss@apache.org>
Content-Type: multipart/alternative; boundary=001a1142e19873aa2d054e399816
archived-at: Fri, 28 Apr 2017 12:56:05 -0000

--001a1142e19873aa2d054e399816
Content-Type: text/plain; charset=UTF-8

On Fri, Apr 28, 2017, 08:08 Jim Jagielski <jim@jagunet.com> wrote:

> I will simply state that I remain a bit uncomfortable with
> us continuing to approve inclusion of non-OSI/FSF approved
> licensed s/w in our projects.
>
> As a developer as well as end-user, and as someone who works
> at a company that leverages FOSS, s/w obtained from the ASF
> has always been "safe" in that there were always expectations
> related to the s/w... one of which, as I have phrased it
> before, is that it is "brain dead easy", legal-wise, to
> consume it; that there's nothing in there that would cause lawyers
> to get itchy.
>
> Inclusion of non-OSI approved licenses make lawyers itchy.
>
> ESPECIALLY when they don't expect something they get from the
> ASF to HAVE IT.
>


I share that discomfort.

For me, I worry that use of these licenses will undermine the argument I've
made to my employer to stick with the set of widely recognized ones for our
own open source software. Lawyers seem to have "itchy trigger fingers",
constantly wanting to write some "custom" legalese for each specific
scenario. For several reasons, I think that is usually a mistake. However,
my position is harder to argue when ASF's acceptance of non-OSI/FSF
approved licenses gives the illusion of wider community acceptance of
software distributed under those licenses, which is not necessarily the
case (as Jim rightly points out, and I agree with).

--001a1142e19873aa2d054e399816
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p dir=3D"ltr">On Fri, Apr 28, 2017, 08:08 Jim Jagielski &=
lt;<a href=3D"mailto:jim@jagunet.com" target=3D"_blank">jim@jagunet.com</a>=
&gt; wrote:<br></p><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">I will simply state that I remain a bit uncomfortable with<br>
us continuing to approve inclusion of non-OSI/FSF approved<br>
licensed s/w in our projects.<br>
<br>
As a developer as well as end-user, and as someone who works<br>
at a company that leverages FOSS, s/w obtained from the ASF<br>
has always been &quot;safe&quot; in that there were always expectations<br>
related to the s/w... one of which, as I have phrased it<br>
before, is that it is &quot;brain dead easy&quot;, legal-wise, to<br>
consume it; that there&#39;s nothing in there that would cause lawyers<br>
to get itchy.<br>
<br>
Inclusion of non-OSI approved licenses make lawyers itchy.<br>
<br>
ESPECIALLY when they don&#39;t expect something they get from the<br>
ASF to HAVE IT.<br>
</blockquote><div><br></div><div><br></div>I share that discomfort.<br><br>=
For me, I worry that use of these licenses will undermine the argument I=
9;ve made to my employer to stick with the set of widely recognized ones fo=
r our own open source software. Lawyers seem to have &quot;itchy trigger fi=
ngers&quot;, constantly wanting to write some &quot;custom&quot; legalese f=
or each specific scenario. For several reasons, I think that is usually a m=
istake. However, my position is harder to argue when ASF&#39;s acceptance o=
f non-OSI/FSF approved licenses gives the illusion of wider community accep=
tance of software distributed under those licenses, which is not necessaril=
y the case (as Jim rightly points out, and I agree with).<br></div><div cla=
ss=3D"gmail_quote"><br></div></div>

--001a1142e19873aa2d054e399816--