www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <he...@yandell.org>
Subject Re: What constitutes a source release?
Date Wed, 01 May 2013 01:13:15 GMT
On Tue, Apr 30, 2013 at 7:22 AM, Kevan Miller <kevan.miller@gmail.com>wrote:

> On Apr 30, 2013, at 9:59 AM, Sam Ruby <rubys@intertwingly.net> wrote:
> > 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...

Though if we're going to take the license as gospel on the subject, I'd
point out that 'media types' suggests your media files are Objects and not
Source. Still, I don't think there's any value in restricting a
source-distribution to not have media files, beyond the reality that
whatever media files we have are probably hard to recreate and the
originals may not even be in our svn.

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

I don't see that the quote from the charter in Roy's old email limits us as
much as he suggests. Community/Industry use of the phrase Open Source
doesn't restrict it to only applying to source, and it covers what we
create/maintain, not what we include. It would be unhealthy for us though
to have a project releasing its core creativity in only binary form, so
there's a lot of importance to the source-only point.

I think there's a decision of hair splitting to decide on (to refer to your
email that I snipped :) ).

If source in tarballs is a critical bar, then we need to decide what
binaries are okay (media etc) and which are not. We also need to decide how
magic distribution (pom.xml and other behind the scene network installs)
can be fine.

Alternatively, the bar is somehow different. To me it feels that the bar is
less that the tar.gz must contain source and more that source must be
obtainable. The Category B text hits that point, though for a different
context than src tarballs. If including a Category B text, you must point
to where the source is installed. So when dependning on JUnit, projects
should be pointing to that. The same is true of one Apache project
depending on another. It should be fine for one project to include another
project in binary form, providing its source is available.

Something to watch for in that second alternative is that we think through
the use of the NOTICE file. Should, as an easy example, Commons Lang's
NOTICE file contain a mention that it depends on JUnit, licensed under the
CPL 1.0? It's definitely true for the source tar.gz, but for a user who
takes the Lang jar it's not true because the Lang jar is independent of the
JUnit use.


View raw message