Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
Received-SPF: pass (athena.apache.org: domain of kevan.miller@gmail.com
 designates 209.85.213.174 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: What constitutes a source release?
From: Kevan Miller <kevan.miller@gmail.com>
In-Reply-To: 
 <CAFG6u8G+S4ooTmYzeZ4qOsPYN3=OWEW_zM9+Uq+zQDEUGFNsWA@mail.gmail.com>
Date: Tue, 30 Apr 2013 10:22:26 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <E5DBBCFF-1069-4EBF-9A42-242E9E26848C@gmail.com>
References: <1165B607-1FDE-4563-A8F9-920F1E0A8B35@gmail.com>
 <CAFG6u8G+S4ooTmYzeZ4qOsPYN3=OWEW_zM9+Uq+zQDEUGFNsWA@mail.gmail.com>
To: legal-discuss@apache.org


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.
>>=20
>> In the Jira, Henri wrote:
>>=20
>>> So to paraphrase, (facetiously :) ):
>>>=20
>>> * 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>>=20
>> :)
>>=20
>> 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
>>=20
>> 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.
>>=20
>> 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.
>=20
> Our license[1] contains the following definitions:
>=20
> "Source" form shall mean the preferred form for making modifications,
> including but not limited to software source code, documentation
> source, and configuration files.
>=20
> "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...

>=20
>> 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/%3C=
0F5691A1-97C0-444F-A514-B2E4E8E907DA@gbiv.com%3E

--kevan=

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