www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@intertwingly.net>
Subject Re: Move Category B, binary, labeled into resolved (was: Move Overview, Category X and ...)
Date Sun, 15 Jun 2008 15:21:34 GMT
oops, meant to send to the list

On Sun, Jun 15, 2008 at 11:20 AM, Sam Ruby <rubys@intertwingly.net> wrote:
> On Fri, Jun 13, 2008 at 4:10 PM, Henri Yandell <bayard@apache.org> wrote:
>> On Fri, Jun 13, 2008 at 10:28 AM, Sam Ruby <rubys@intertwingly.net> wrote:
>>> On Fri, Jun 13, 2008 at 11:31 AM, Henri Yandell <bayard@apache.org> wrote:
>>>> On Fri, Jun 13, 2008 at 8:02 AM, Sam Ruby <rubys@intertwingly.net>
>>>>> On Thu, Jun 12, 2008 at 2:33 AM, Henri Yandell <bayard@apache.org>
>>>>>> I've incorporated the below into resolved.html.
>>>>>> I did some more editing on the discussion points, making sure Category
>>>>>> B and System Requirements were not discussed. Keeping it simple etc.
>>>>> Excellent!
>>>>> Looking at the 3party draft again, I believe that the next low hanging
>>>>> fruit is that we can move properly labeled binary artifacts licensed
>>>>> under Category B into resolved.  By that I mean stating that artifacts
>>>>> licensed under category B licenses which are distributed in binary
>>>>> form and properly labeled are allowed.  If we can manage to say that
>>>>> without saying that such artifacts when distributed in source form are
>>>>> always disallowed and must be removed, then I think the point will
>>>>> enjoy consensus.
>>>>> Thoughts?
>>>> Take a stab at the wording. As long as we achieve the above (not
>>>> saying no to source form), then sure.
>>> Here's a stab:
>>> """
>>> How should so-called "Reciprocal" Licenses be handled?
>> "Weak Copyleft" rather than "Reciprocal".
> Either works for me.  If you prefer "Weak Copyleft", I'm OK with that.
>>> Each license in this category requires some degree of reciprocity;
>> 'limited degree' or maybe 'localized degree'.
> OK
>>> this may means that additional action is warranted in order to
>>> minimize the chance that a user of an Apache product will create a
>>> derivative work of a reciprocally-licensed portion of an Apache
>>> product without being aware of the applicable requirements.
>>> Software under the following licenses may be included in binary form
>>> within an Apache product if the inclusion is appropriately labeled:
>>>    * CDDL 1.0
>>>    * CPL 1.0
>>>    * EPL 1.0
>>>    * IPL 1.0
>>>    * MPL 1.0 and MPL 1.1
>>>    * SPL 1.0
>>> By including only the object/binary form, there is less exposed
>>> surface area of the third-party work from which a work might be
>>> derived; this addresses the second guiding principle of this policy.
>>> By attaching a prominent label to the distribution and requiring an
>>> explicit action by the user to get the reciprocally-licensed source,
>>> users are less likely to be unaware of restrictions significantly
>>> different from those of the Apache License; this addresses the fourth
>>> guiding principle of this policy.
>> We don't have any guiding principles yet :)
> Oops.  Strike "; this addresses" on from that paragraph.
>>> For small amounts of source that is directly consumed by the ASF
>>> product at runtime in source form, and for which that source is
>>> unlikely to be changed anyway (say, by virtue of being specified by a
>>> standard), inclusion of appropriately labeled source is also
>>> permitted. An example of this is the web-facesconfig_1_0.dtd, whose
>>> inclusion is mandated by the JSR 127: JavaServer Faces specification.
>> a) Do we say "don't modify"?
> Agreed.  s/unlikely/unmodified and unlikely/
>> b) Do we limit this to specifications?
> Determining what is or is not a recognized specification turns out to
> be a deceptively hard problem.  There are a number of dubious
> standards bodies out there, and a number of recognized standards
> bodies that occasionally act in a dubious fashion.
> I'd rather avoid this.  If the PMC and the licensees of the product in
> question agree that the the artifact in question is not only
> unmodified but likely to remain so, I believe that no additional
> actions beyond notification are required.
>> Hen
> - Sam Ruby

DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message