Return-Path: 
 <repository-return-433-apmail-repository-archive=apache.org@apache.org>
Delivered-To: apmail-repository-archive@www.apache.org
Received: (qmail 69474 invoked from network); 23 Nov 2003 01:23:23 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 23 Nov 2003 01:23:23 -0000
Received: (qmail 45225 invoked by uid 500); 23 Nov 2003 01:23:07 -0000
Delivered-To: apmail-repository-archive@apache.org
Received: (qmail 45190 invoked by uid 500); 23 Nov 2003 01:23:07 -0000
Mailing-List: contact repository-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:repository-help@apache.org>
list-unsubscribe: <mailto:repository-unsubscribe@apache.org>
list-post: <mailto:repository@apache.org>
Reply-To: repository@apache.org
Delivered-To: mailing list repository@apache.org
Received: (qmail 45168 invoked from network); 23 Nov 2003 01:23:06 -0000
Received: from unknown (HELO mail.netspace.net.au) (203.10.110.72)
  by daedalus.apache.org with SMTP; 23 Nov 2003 01:23:06 -0000
Received: from binky (CPE-203-45-8-11.vic.bigpond.net.au [203.45.8.11])
	by mail.netspace.net.au (Postfix) with SMTP id 1F40A68303
	for <repository@apache.org>; Sun, 23 Nov 2003 12:23:14 +1100 (EST)
Reply-To: <tma@netspace.net.au>
From: "Tim Anderson" <tma@netspace.net.au>
To: <repository@apache.org>
Subject: RE: licensing issues for virtual artifacts (was RE: click through
 license support?)
Date: Sun, 23 Nov 2003 12:23:16 +1100
Message-ID: <AHEMLCHGJOKOCPPFEOIHAEKNHKAA.tma@netspace.net.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
In-Reply-To: <NBBBJGEAGJAKLIDBKJOPGEHIFIAB.noel@devtech.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Sunday, 23 November 2003 11:42 AM
> To: repository@apache.org
> Subject: RE: licensing issues for virtual artifacts (was RE: click
> through license support?)
>
>
> > Virtual artifacts have the potential to:
> > . simplify build environments
> > . simplify installation documentation
> > . reduce the bar of entry for building ASF software
> > . reduce support requests
> > . allow meta-data to be associated with 3rd
> >   party artifacts
>
> How do you propose to implement such artifacts?  What impact will
> that have
> on web site deployment and mirroring requirements?

Not 100% sure. I imagine the redirects would need to be set
up manually. If mirroring uses rcp or similar, then
the redirection info would be copied.

Given the URI:
  http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar
This could redirect to:
  http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar.descriptor

The .descriptor file could have a specific mime type to let tools
know that they need to do additional processing, or they could rely
on the extension as an indicator.

Assume the .descriptor contains the following:

<java>
  <artifact-adapter>
    <main-class>org.apache.artifact.sun.VirtualSunArtifact</main-class>
    <class-path>

<path>http://repo.apache.org/apache/artifact/1.1/jars/sunartifact-1.1.jar</p
ath>
    </class-path>
    <param name="product" value="jndi"/>
    <param name="version" value="1.2.1"/>
    <param name="artifact" value="jndi-1.2.1.jar"/>
  </artifact-adapter>
</java>

VirtualSunArtifact implements an interface 'VirtualArtifact'
which allows tools to:
. specify where to download the distribution to
. specify where to place the jndi-1.2.1.jar artifact,
  extracted from the distribution.

VirtualSunArtifact pops up a browser on the Sun JNDI download page,
and requires the user to accept the license. Once accepted,
it proceeds to download the distribution and extract the artifact.

>
> > They are not about:
> > . hosting 3rd party artifacts within ASF repository
> > . circumventing licenses of 3rd party products
> > . exposing ASF to liability
>
> The issue I had in mind was more about confusion, e.g., confusing
> the source
> of the file, which might not be acceptable to the distributor.
> In our case,
> consider this page: http://www.apache.org/info/referer-dotcom.html.
>
> Look, you never know what is going to happen in the real-world.
> Some years
> ago we (DevTech) wrote a search engine.  As a demo, we indexed
> the Star Wars
> site, which was otherwise hard to navigate at the time, and
> provided people
> with search capabilities.  We had none of their IP on our site.
> We offered
> a site-specific search, similar to asking Google to restrict its search to
> their site, except we offered a few other views of the data.  Even so, we
> received an official request from Lucas' legal council to cease.
> The legal
> basis they claimed was that they can control who uses their trademark, and
> their URL contains their trademark.
>

This can be avoided by obtaining permission from the 3rd party first.
The download tool can also require acknowledgement of disclaimers
stating that the ASF does not host the artifact, is in no way
responsible for the end-user's use of the artifact, and that
by downloading the artifact, they are bound by the license
of the artifact.

-Tim