Re: click through license support?

2003-11-20 Thread Nick Chalko
Tim Anderson wrote:
This group could make recommendations as to how
virtual artifacts could be supported.
 

Agree that we should deal with license issue's and virutal artifacts 
when we take on metadata.




[proposal] signature artifact specifier v0.1

2003-11-20 Thread Tim Anderson
[not too happy with the terminology used here. Open
to suggestions]

Overview


This proposal extends the URI Syntax proposal:
  http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax

Signature artifacts are artifacts used to verify the integrity
of another artifact. These include PGP/GPG signatures and keys, 
MD5 and SHA checksums.

The key aims of this proposal are to:
. formalise artifact-specifier for signature artifacts;
. provide a set of best practices for such artifacts; and
. enable tools to construct a URI to unambigously locate
  a particular signature artifact using a set of known
  criteria

URI Components
==

An absolute repository URI is written as follows:
  repository-uri = access-specifier / product-specifier /
   version-specifier / artifact-specifier

For signature artifacts, artifact-specifier is:
  artifact-specifier = signature-artifact-specifier
  signature-artifact-specifier = key-artifact | integrity-artifact

Key artifacts
-

For artifacts digitally signed using PGP/GPG, there is an associated
KEYS artifact.
  key-artifact = pgp-keys
  pgp-keys = pgp/KEYS

E.g:
  http://repo.apache.org/apache/ant/1.5.4/pgp/KEYS

Integrity artifacts
---

Each artifact may have an associated integrity artifact:

  integrity-artifact = artifact-specifier . sig-type
  sig-type = pgp | md5 | sha

Where:
. pgp indicates the artifact was digitally signed using PGP/GPG
. md5 indicates an md5 checksum
. sha indicates a SHA checksum

E.g: 
  The artifact:
http://repo.apache.org/apache/ant/1.5.4/jars/ant-1.5.4.jar  

  may have integrity artifacts:
http://repo.apache.org/apache/ant/1.5.4/jars/ant-1.5.4.jar.md5
http://repo.apache.org/apache/ant/1.5.4/jars/ant-1.5.4.jar.pgp
http://repo.apache.org/apache/ant/1.5.4/jars/ant-1.5.4.jar.sha


Rationale
=

Integrity artifacts located alongside artifacts
---

This approach enables integrity artifacts to be 
located easily.


Tool support


Key artifacts
-

Tools can unambigously locate a key artifact given the
project-version URI and signature type.

E.g, given:
  uri = http://repo.apache.org/apache/ant/1.5.4/
  sig-type = pgp

The key artifact URI would be:
  uri = http://repo.apache.org/apache/ant/1.5.4/pgp/KEYS

Integrity artifacts
---

Tools can unambigously locate an integrity artifact given
the repository URI of the associated artifact, and the signature
type.

E.g, given:
  uri = http://repo.apache.org/apache/ant/1.5.4/jars/ant-1.5.4.jar 
  sig-type = md5

The integrity artifact URI would be:
  uri = http://repo.apache.org/apache/ant/1.5.4/jars/ant-1.5.4.jar.md5




Re: click through license support?

2003-11-20 Thread Nicola Ken Barozzi
Tim Anderson wrote:
I was thinking of something like the following:
1. all artifacts in the repository are real or virtual.
2. real artifacts are hosted in the repository
3. virtual artifacts are not hosted, but refer to
the real artifact via:
4. http redirection
5. http redirection requiring processing
Exactly :-)
I'll leave the spec to you guys, but as for this, definitely +1
Apache must publish Apache artifacts, but if we really want this to 
scale, we should make it possible for others to publish their own stuff 
in their own repos.

(Thanks to spell checking now I always write 'definitely' correctly :-)
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


licensing issues for virtual artifacts (was RE: click through license support?)

2003-11-20 Thread Tim Anderson
Can you clarify the licensing issues further? I'm having trouble
seeing what the problems are.

Suppose ASF has the following link in the repository:
  http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar

This is a virtual artifact, not hosted at ASF.

Via http redirection and magic, a download tool:
A. pops up a browser, requiring the user to accept Sun's license
B. downloads the corresponding jndi-1_2_1.zip distribution
   if and only if the user *manually* accepts the license
C. caches the distribution locally
D. extracts jndi.jar from the distribution for local use

Taking the Sun license points one at a time:
. (i): you distribute the Software complete and unmodified and only
   bundled as part of, and for the sole purpose of running, your Java
   applets or applications (Programs)

   I don't see a violation here. The repository is not distributing
   JNDI - its facilitating its download.
   The download tool is not distributing JNDI - its facilitating
   its use by an application.
   As far as I can tell, the only requirement is that the
   onus is on the end user to satisfy this part of the license.

. (ii) the Programs add significant and primary
   functionality to the Software,

   Again, the onus is on the end user to satisfy this part of the license.

. (iii) you do not distribute additional software intended to
   replace any component(s) of the Software

   Not violated by the repository nor the download tool.

. (iv) you do not remove or alter any proprietary legends or
   notices contained in the Software,

  When unpacking the distribution, the tool needs to ensure
  that license information is retained.

. (v) you only distribute the Software subject to a license
   agreement that protects Sun's interests consistent with the terms
   contained in this Agreement, and

   Again, the onus is on the end user to satisfy this part of the license.

. (vi) you agree to defend and indemnify Sun and its licensors from
  and against any damages, costs, liabilities, settlement amounts
  and/or expenses (including attorneys' fees) incurred in connection with
  any claim, lawsuit or action by any third party that arises or results
  from the use or distribution of any and all Programs and/or Software.

  The ASF has not distributed the software, so it can't be liable.

If this has been discussed elsewhere, could you post a link?

Thanks,

Tim

 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, 19 November 2003 2:46 AM
 To: [EMAIL PROTECTED]
 Subject: Re: click through license support?


 Nicola Ken Barozzi [EMAIL PROTECTED] wrote on 19/11/2003 01:31:13 AM:

 
  [EMAIL PROTECTED] wrote:
 
   Nicola Ken Barozzi [EMAIL PROTECTED] wrote on 15/11/2003
 10:00:07
 PM:
  
  
  Tim Anderson wrote:
  ...
  A tool can 'screen scrape' the redirected page, prompt the user
  to accept the license and only download if the license is accepted,
  
  If the tool is made to work like a web browser, ie show the pages and
  then download when the user clicks on the button, IMHO it would be
  perfectly acceptable.
  
   But still illegal.
 
  I still don't understand why.
 
  I mean, if:
 
1-  the program opens the browser on the product download page
2 - the user does the download steps as usual
3 - the program gets the downloaded artifact from the local download
location
 
  Why would we be breaking the license? The only difference between this
  approach and the usual one is that the download location is linked.
 
   We've been down this road and are working with Sun on a solution. We
 have
   (had?) a tool that would do the above in Maven ages ago.
 
  Yes, I'm aware of that.
 
   See http://maven.apache.org/sun-licensing-journey.html
 
  Very good that you have this page, thanks for the pointer.

 For example, the JavaMail v1.3 BCL has Supplemental License Terms which
 state in Point 2. :

  ...Sun grants you a non-exclusive, non-transferable, limited license to
 reproduce and distribute the
 Software in binary code form only, provided that (i) you distribute the
 Software complete and
 unmodified and only bundled as part of, and for the sole purpose of
 running, your Java applets or
 applications (Programs), (ii) the Programs add significant and primary
 functionality to the
 Software, (iii) you do not distribute additional software intended to
 replace any component(s) of
 the Software, (iv) you do not remove or alter any proprietary legends or
 notices contained in the
 Software, (v) you only distribute the Software subject to a license
 agreement that protects Sun's
 interests consistent with the terms contained in this Agreement, and (vi)
 you agree to defend and
 indemnify Sun and its licensors from and against any damages, costs,
 liabilities, settlement amounts
 and/or expenses (including attorneys' fees) incurred in connection with
 any claim, lawsuit or action
 by any third party that arises or results from the use or distribution of
 any and all Programs
 and/or