Return-Path: X-Original-To: apmail-legal-discuss-archive@www.apache.org Delivered-To: apmail-legal-discuss-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9B15510B4C for ; Tue, 30 Apr 2013 14:30:25 +0000 (UTC) Received: (qmail 57050 invoked by uid 500); 30 Apr 2013 14:30:25 -0000 Delivered-To: apmail-legal-discuss-archive@apache.org Received: (qmail 56780 invoked by uid 500); 30 Apr 2013 14:30:25 -0000 Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: Reply-To: legal-discuss@apache.org List-Id: Delivered-To: mailing list legal-discuss@apache.org Received: (qmail 56772 invoked by uid 99); 30 Apr 2013 14:30:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Apr 2013 14:30:25 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates 209.85.212.172 as permitted sender) Received: from [209.85.212.172] (HELO mail-wi0-f172.google.com) (209.85.212.172) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Apr 2013 14:30:20 +0000 Received: by mail-wi0-f172.google.com with SMTP id hm14so3985469wib.11 for ; Tue, 30 Apr 2013 07:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=SRcal9xb7uUJ0f16o48BWozKJrNqw8uJk7+xhA1E7Cc=; b=U88eyS0cWevgverEjwnkB5ZSfjwLGq048a6GpbVtdT2h2FpLp8W4J0rG2s5bxCdYdK aFgfB//6tEPXYim5fRHRlpAc4TWPc6tZjK2e0ZdsAR8m4vczaY/GHaaQQFCtVm6ywMxh CX8EFnoG7iZ4MotybpxZd1zDRK0Iw3l79mE0y9Mzbw/pbFSyzS6dJxxeaGwCpJ3V5XXE 1cSG77nRZN4YtCrjTTwHOE560HqbiApLrnC+i2wEQCnBBwkFLyoxV859UIFM2f6QN411 plPn0boFWy+femFSfBDjvRxar4TxW81DLs0FI82nfQw6tZFNJhTzCZQHp5YlrGvQYf6B P3Jg== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr18150793wjb.17.1367332199067; Tue, 30 Apr 2013 07:29:59 -0700 (PDT) Received: by 10.194.177.198 with HTTP; Tue, 30 Apr 2013 07:29:58 -0700 (PDT) In-Reply-To: References: <1165B607-1FDE-4563-A8F9-920F1E0A8B35@gmail.com> Date: Tue, 30 Apr 2013 15:29:58 +0100 Message-ID: Subject: Re: What constitutes a source release? From: sebb To: legal-discuss@apache.org Content-Type: multipart/alternative; boundary=047d7b5d8cff03f67104db94d689 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b5d8cff03f67104db94d689 Content-Type: text/plain; charset=ISO-8859-1 On 30 April 2013 15:22, Kevan Miller wrote: > > On Apr 30, 2013, at 9:59 AM, Sam Ruby wrote: > > > On Tue, Apr 30, 2013 at 9:54 AM, Kevan Miller > wrote: > >> I'm moving a "discussion" from LEGAL-163 ( > https://issues.apache.org/jira/browse/LEGAL-163) to the mailing list. > >> > >> In the Jira, Henri wrote: > >> > >>> So to paraphrase, (facetiously :) ): > >>> > >>> * A Java project that stores junit.jar in lib/, cannot include that in > the foo-src.tar.gz but instead has to either tell the user to download it > manually or setup a magic download that the user is only vaguely aware of > (pom.xml for example). > >>> * A project cannot include images, but has to provide the 'source' for > those images. > >>> > >>> I can see there being an idealistic argument made that all parts of > the source tarball must be built from source (which would be a shock to the > system for Java projects), and I can see media artifacts being treated > differently. I can also see category A, B and X all having dependencies > that are optional and put manually in place by the users. > >>> > >>> I can't see, though, that there is any difference between a source > tarball that contains a binary dependency and a source tarball that > provides a build script that magically downloads binaries behind the scenes. > >> > >> > >> :) > >> > >> So, I think we're agreed that there certain "binary" formatted files > (e.g. media files) which can be treated as "source". And from my naive > background, I probably would have placed fonts into that category (and > since the font file is extremely unlikely to be changed, I'd have allowed > under the category B exclusion). But that's not really germane > >> > >> I agree that building some of our Java projects entirely from scratch > is an extremely difficult undertaking. I have known companies/projects that > have done this for Geronimo. > >> > >> We may be splitting hairs, but including Java class/jar files or .o > files, .exe files in a *source* release does not meet my definition of open > source. > > > > Our license[1] contains the following definitions: > > > > "Source" form shall mean the preferred form for making modifications, > > including but not limited to software source code, documentation > > source, and configuration files. > > > > "Object" form shall mean any form resulting from mechanical > > transformation or translation of a Source form, including but not > > limited to compiled object code, generated documentation, and > > conversions to other media types. > > :) I guess our *license* is a pretty good starting point... > > > > >> FYI, found the following discussion in Incubator -- > http://s.apache.org/rk5 > > Strange. Does this work? > > > http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3C0F5691A1-97C0-444F-A514-B2E4E8E907DA@gbiv.com%3E > > Looks like the mail archive server is unwell at present [1]; neither works for me [1] http://monitoring.apache.org/status/ --kevan > --------------------------------------------------------------------- > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org > For additional commands, e-mail: legal-discuss-help@apache.org > > --047d7b5d8cff03f67104db94d689 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 3= 0 April 2013 15:22, Kevan Miller <kevan.miller@gmail.com> wrote:

On Apr 30, 2013, at 9:59 AM, Sam Ruby <rubys@intertwingly.net> wrote:

> On Tue, Apr 30, 2013 at 9:54 AM, Kevan Miller <kevan.miller@gmail.com> wrote:
>> I'm moving a "discussion" from LEGAL-163 (https:/= /issues.apache.org/jira/browse/LEGAL-163) to the mailing list.
>>
>> In the Jira, Henri wrote:
>>
>>> So to paraphrase, (facetiously :) ):
>>>
>>> * A Java project that stores junit.jar in lib/, cannot include= that in the foo-src.tar.gz but instead has to either tell the user to down= load it manually or setup a magic download that the user is only vaguely aw= are of (pom.xml for example).
>>> * A project cannot include images, but has to provide the '= ;source' for those images.
>>>
>>> I can see there being an idealistic argument made that all par= ts of the source tarball must be built from source (which would be a shock = to the system for Java projects), and I can see media artifacts being treat= ed differently. I can also see category A, B and X all having dependencies = that are optional and put manually in place by the users.
>>>
>>> I can't see, though, that there is any difference between = a source tarball that contains a binary dependency and a source tarball tha= t provides a build script that magically downloads binaries behind the scen= es.
>>
>>
>> :)
>>
>> So, I think we're agreed that there certain "binary"= formatted files (e.g. media files) which can be treated as "source&qu= ot;. And from my naive background, I probably would have placed fonts into = that category (and since the font file is extremely unlikely to be changed,= I'd have allowed under the category B exclusion). But that's not r= eally germane
>>
>> I agree that building some of our Java projects entirely from scra= tch is an extremely difficult undertaking. I have known companies/projects = that have done this for Geronimo.
>>
>> We may be splitting hairs, but including Java class/jar files or .= o files, .exe files in a *source* release does not meet my definition of op= en source.
>
> Our license[1] contains the following definitions:
>
> "Source" form shall mean the preferred form for making modif= ications,
> including but not limited to software source code, documentation
> source, and configuration files.
>
> "Object" form shall mean any form resulting from mechanical<= br> > transformation or translation of a Source form, including but not
> limited to compiled object code, generated documentation, and
> conversions to other media types.

:) I guess our *license* is a pretty good starting point...

>
>> FYI, found the following discussion in Incubator -- http://s.apache.org/rk5

Strange. Does this work?

http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%= 3C0F5691A1-97C0-444F-A514-B2E4E8E907DA@gbiv.com%3E


Looks like the mail archive server is unwell at present [1= ]; neither works for me

[1] http://monitoring.apache.org/status/

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


--047d7b5d8cff03f67104db94d689--