Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: local policy)
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <6.2.1.2.2.20050718161150.08effc90@pop3.rowe-clan.net>
Date: Mon, 18 Jul 2005 16:18:45 -0500
To: Jeffrey Thompson <jthom@us.ibm.com>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: IBM and Apache
Cc: Niclas Hedhman <niclas@hedhman.org>, legal-discuss@apache.org
In-Reply-To: <OF89D9AFF5.5E3C407D-ON04257042.006FB12C-04257042.0072BB0D@
 us.ibm.com>
References: <200507190309.52146.niclas@hedhman.org>
 <OF89D9AFF5.5E3C407D-ON04257042.006FB12C-04257042.0072BB0D@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 03:53 PM 7/18/2005, Jeffrey Thompson wrote:

>NICE TO HAVEs 
>c)  Helpful:  A really easy PCo process for obtaining that license -- no paperwork  (maybe a click thru on a website, or something like that) 
>d)  More helpful:  An automatic license from PCo to all recipients of the Apache implementation that would cover their implementations derived from it.  (That could be part of Apache's license -- people creating new implementations from Apache's code could be covered as "Additional Licensees".  Or, it could be separate) 
>e)  Most helpful:  An license that automatically covers all implementations of the standard regardless of whether derived from Apache's code.  (would probably have to be separate) 

IMHO, and from discussions on other channels, it's my impression
that d) is the minimal acceptable level of 'help' for users.  It's
been suggested that e) is the minimum since, at any arbitrary point
in time, the PCo could choose to *stop* granting additional licenses,
or create additional restrictions, thus killing a project.

It's been my understanding that, if folks download a tarball or binary
to use, there should be no restrictions from them simply using it in
terms of external, 3rd party licenses.  And that, if there are any
small requirements to modify the code, they should be in the form of
an unbreakable agreement, not a sublicense scenario.  Perpetual RF 
might be considered, RAND would not.  And some even think that just
a perpetual RF is too much of an onus against calling the software
'open'.

This is going to be a case of going to the foundation and asking what
level of pain are we willing to inflict on users and devs, and then
conforming our projects and licensing around that.

Bill


---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org