SVN and distribution (was: [VOTE] Release Apache Pivot 1.1 (second try))

[sebb <se...@gmail.com>]

On 18/04/2009, Upayavira <uv...@odoko.co.uk> wrote:
> On Sat, 2009-04-18 at 10:18 +1000, Gavin wrote:
>  >
>  > > -----Original Message-----
>  > > From: Upayavira [mailto:uv@odoko.co.uk]
>  > > Sent: Saturday, 18 April 2009 9:23 AM
>  > > To: general@incubator.apache.org
>  > > Subject: Re: [VOTE] Release Apache Pivot 1.1 (second try)
>  > >
>  > > On Fri, 2009-04-17 at 10:48 +0800, Niclas Hedhman wrote:
>  > > > On Thu, Apr 16, 2009 at 11:07 PM, sebb <se...@gmail.com> wrote:
>  > > >
>  > > > > As far as I know, putting a file in a publicly accessible SVN
>  > > > > repository is considered as distribution too.
>  > > >
>  > > > No, I am very positive that this is not the case. Legal dilligence is
>  > > > done on the release artifacts separately from SVN issues. Unlike
>  > > > release artifacts, SVN are at times incomplete, incorrect and
>  > > > inaccurate. "Tags" have no legal meaning whatsoever, and should not
>  > > > even be part of the discussion.
>  > > >
>  > > > So, since we are looking at a "Release", please spare the SVN
>  > > > discussion for later.
>  > >
>  > > Personally, I give a lot of weight to what Larry said on legal-discuss.
>  > >
>  > > Both SVN and releases are distribution. So, we _must_ be sure that
>  > > anything that goes into SVN we have the right to distribute.
>  >
>  > Are you talking about trunk, or release tags/branches ?
>  >
>  > SVN in my opinion is a place where we place code to work on collaboratively
>  > , it's a developer resource - anything in there is subject to being broken
>  > code-wise, documentation-wise and for short bursts may contain 3rd party
>  > jars and items without appropriate licensing. Acceptable I think, until some
>  > volunteer dev cleans it up.
>  >
>  > I do not agree that anything in svn is distribution, the same as snapshots
>  > and nightlies are not (supposed to be) advertised to joe bloggs the user,
>  > but jane bloggs the dev being on the dev list will know where to get her
>  > hands on it.
>  >
>  > And now I just read the bit about sparing svn discussion for later, oops.
>

Hence the subject change.

> There is a distinction between 'distribution' and 'release'.
>
>  As Larry pointed out, someone from company X (say, IBM) may do a
>  checkout from our SVN. That means a transfer of intellectual property
>  from ASF to IBM. That is distribution - no question about it.
>
>  Thus, I cannot commit a bootlegged music track into Apache SVN, as
>  neither I, nor the ASF, have the right to distribute it. However, I
>  could commit an LGPL library, as we do have the right to distribute
>  that. We just have a policy to not allow it to be included within a
>  'release' - the release being the end-product of ASF effort, and the
>  thing that is intended for consumption by the public.
>

However, sticking a 3rd party jar in SVN is rather different from the
usual way jars are distributed. For example JUnit would normally be
downloaded from the JUnit website, where one can find the licence and
any other conditions associated with it. In Maven repos most jars have
an associated pom which gives the licence and other details.

I think need to make clear to the user what licence applies to the
items within SVN.

The NOTICE and LICENSE files serve this purpose for 3rd party jars
that will be included with the released product, but if the jars are
just stored in SVN for the convenience of developers, they will not be
(and should not be) listed in the NOTICE and LICENSE files.

Since public SVN constitutes distribution, we need to be sure that we
are complying with the appropriate distribution terms for the jar. It
could be something as simple as adding suitable readme files alongside
the additional jars. Merely putting copies of 3rd party jars into SVN
is not enough.

>  Upayavira
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org