RE: licensing issues for virtual artifacts (was RE: click through license support?)
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?)
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?)
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?)
[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?)
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?)
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?)
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?)
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
