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