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

2003-11-27 Thread Tim Anderson
 From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, 26 November 2003 1:34 PM
 
 Nicola Ken Barozzi wrote
  [EMAIL PROTECTED] wrote:
   I'm failing to see the requirement for us to do [virtual artifacts]
 *now*.
  Because Apache projects using the repository would need also non-asf
  jars that we don't want to distribute - virtual artifacts.
 
 I still maintain that non-ASF jars are specified in meta-data 
 made available
 to client tools, and thus virtual artifacts are unnecessary.
 
 The meta-data files will need to be present repository in order for the
 tools to work.
 
   --- Noel
 

The idea behind virtual artifacts is that they allow users and tools
to determine if an artifact is available or not.

Given the artifact:
  http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar

A user browsing the repository on seeing jndi-1.2.1.jar 
can assume that a tool will be able to download it,
regardless of whether the repository hosts it or not.

Without the virtual artifact:
. users might not be aware that corresponding meta-data indicates
  to tools that the real artifact is hosted elsewhere

. tools would need to do a 2 stage lookup to find an artifact,
  even if its not present:
  1. determine if the artifact is hosted directly
  2. on failing [1], determine if there is any meta-data indicating
 that the tool should look elsewhere

-Tim




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

2003-11-26 Thread Noel J. Bergman
Nicola Ken Barozzi wrote
 [EMAIL PROTECTED] wrote:
  I'm failing to see the requirement for us to do [virtual artifacts]
*now*.
 Because Apache projects using the repository would need also non-asf
 jars that we don't want to distribute - virtual artifacts.

I still maintain that non-ASF jars are specified in meta-data made available
to client tools, and thus virtual artifacts are unnecessary.

The meta-data files will need to be present repository in order for the
tools to work.

--- Noel



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

2003-11-25 Thread dion
Nicola Ken Barozzi [EMAIL PROTECTED] wrote on 25/11/2003 07:23:15 PM:

 
 [EMAIL PROTECTED] wrote:
 
  Why don't we just focus on:
  
  a) getting an ASF-only repository up first, and
  b) Getting the management and tooling for that
  
  before taking on virtual hosting.
  
  I'm failing to see the requirement for us to do that *now*.
 
 Because Apache projects using the repository would need also non-asf 
 jars that we don't want to distribute - virtual artifacts.

And there are other places those jars can be found.

I'm failing to see how this impacts a repo that stores ASF-only content.

I agree it would be a nice to have, but is it a requirement for an ASF 
repo?
--
dIon Gillard, Multitask Consulting
Blog:  http://blogs.codehaus.org/people/dion/






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

2003-11-25 Thread Nick Chalko
[EMAIL PROTECTED] wrote:
I agree it would be a nice to have, but is it a requirement for an ASF 
repo?
 

Agree,  lets wrap up the other specs first.  I think we should delay,  
but a week or two maybe enough. 
Comment on the / issue.  Help decidce in the version name not allowing 
release or latest  etc.
When that is done, then we can come back to this. 
I do think with all of Tim's excelent work we can wrap this up in a week 
or two.




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

2003-11-24 Thread Geir Magnusson Jr
On Nov 23, 2003, at 4:02 PM, Dirk-Willem van Gulik wrote:

I'm the Apache JCP rep, and have had some talks with Sun about this
issue.  The object is to get a formal agreement from Sun to allow us 
to
do this, without us having to try and interpret the license agreement.
+1 to short circuit this and directly arrange the right thing with 
SUN; an
das the ASF simply document a permission with them.

We've got every indication from them that they _want_ these sort of 
things
to be fixed - and not be a hurdle. I expect there to be enough trust
between us and SUN that we can move the way/place/method of the click
through.

I've head that Jason has been having similar covnerstation - may be 
good
for you two to sync up and make sure there is no overlap.
There shouldn't be.  I initially got the conversation going between 
Jason and Tom, but it stopped.  I mentioned it to Graham at a JCP EC 
meeting to help get it jumpstarted again, thinking that it had sunk 
into the legal quagmire that can be the sun legal team :)

geir
Dw

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]


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

2003-11-22 Thread Tim Anderson
 From: Nick Chalko [mailto:[EMAIL PROTECTED]
 
 Tim Anderson wrote:
 
 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.
 
   
 
 I think what you describe was fine. 
 I was looking the otherway. 
 The ability to host a jar and ensure that a user accepts a license 
 first. 
 
 
 So what would we need  for a virutal artifact.
 
 A entry-url  and the rest is up to the user/tool?
 

There are a few approaches. The following assumptions
are made:
. virtual artifacts which require processing redirect
  to a descriptor hosted within the repository which
  describes how to get the real artifact.
. the descriptor refers either to the real artifact,
  or an artifact (call it target) containing the real
  artifact.

Possible approaches:

1. descriptor includes URL of target artifact.
   The limitation of this approach is that the tool
   has to be aware of the licensing and distribution of
   the target artifact.

2. descriptor includes code to get the target artifact
   For java, this could be a scripting mechanism based on BSF, 
   ant or jelly.
   This may not be portable between tools:
   . tool requires a dependency on the scripting mechanism
   . tool may not be able to specify where the artifact
 is downloaded to

3. descriptor refers to code which can get the artifact
   For java, this would include the main class and URL classpath
   of the code to get the artifact. This code could be hosted
   in the repository.   
   For portability between tools, an API would need to be specified
   to give tools control over how the target artifact is processed 
   subsequent to its download.

-Tim




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

2003-11-22 Thread Noel J. Bergman
 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.

I do not like the idea of virtual artifacts.  I think that the meta-data for
any component that needs a foreign artifact should contain the information
needed by some tool.  I don't think that we want to include foreign
components in the ASF namespace.  In fact, there is a situation right now
where someone else has done that to the ASF, and we're not happy about it.

--- Noel



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

2003-11-21 Thread Nick Chalko
Tim Anderson wrote:
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.
 

I think what you describe was fine. 
I was looking the otherway. 
The ability to host a jar and ensure that a user accepts a license 
first. 

So what would we need  for a virutal artifact.
A entry-url  and the rest is up to the user/tool?
R,
Nick


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