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
Re: click through license support?
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.
Re: click through license support?
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?)
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
RE: click through license support?
From: Nick Chalko [mailto:[EMAIL PROTECTED] ASL does not require click's for it's license. I think this is out of scope. It is an important discusion for tools, but we are not doing tools here. R, Nick Yes and no. It would be useful if the repository could host virtual artifacts. This enables: . a unified view of artifacts to be presented to both users and tools . virtual artifacts to be augmented with meta-data E.g, sun jars could have associated maven project.xml files. . federation support At the very least, tools would need to be aware that they need to follow http redirects to get to the real artifact. This group could make recommendations as to how virtual artifacts could be supported.
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 Software. I don't think a repository for distributing jars fits the requirements for (i) or (ii), and may possibly break (iii). And I don't think the ASF would like to agree to (vi). -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/
[Fwd: Re: click through license support?]
Sent this to nicola directly by mistake. Nicola is your mail client overwritting the reply-to? -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society ---BeginMessage--- On Tue, 2003-11-18 at 09:31, Nicola Ken Barozzi wrote: [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. The fact is it doesn't matter what we think. I asked the board and they said work it out with Sun. Sun doesn't actually care if we put the JavaMail jar on ibiblio and they would never take legal action but we still can't put it there. I don't see any problem with the scraper approach either but it contravenes what Sun intends for users and so we need their express permission. At any rate we can't do it any other way so says the board. So it is moot what we think or that it is actually reasonable, we are dealing with lawyers who could turn something simple like this into an incomprehensible mess. I have seen a drop in replacement for JavaMail and I would like to put that in the repository and find other replacements like it. Sun isn't going to out of their way to help us unless there is an extreme amount of pressure placed on them and they get some good PR out of it. 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. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society ---End Message---
Re: click through license support?
[EMAIL PROTECTED] wrote: ... I don't think a repository for distributing jars fits the requirements for (i) or (ii), and may possibly break (iii). And I don't think the ASF would like to agree to (vi). Well, IIUC it's because it's a jar repo you are talking about. I'm taking about downloading the whole thing from the sun site as users manually do. So there is effectively no distribuition difference. I am aware that you guys know more about this because you have been pushing for this for such a long time. It's just that the issue was about distributing the jar, and thought that getting the whole distribution would be ok. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
RE: click through license support?
I'm taking about downloading the whole thing from the sun site as users manually do. So there is effectively no distribuition difference. You would have to pass through the license request to the user. It would be a bad idea for the tool to pose as a user without requiring user approval of the actual license. Not sure if you've already said that; just making sure that it gets noted. Nick has a point that this is more of a tools discussion. Any reference to a click-through license would come from meta-data describing the location of a dependency. --- Noel
click through license support?
One of the current problems with repositories such as http://www.ibiblio.org/maven is their inability to host products which have restrictive licensing schemes. (See http://maven.apache.org/sun-licensing-journey.html for background) E.g, ibiblio cannot host jars from Sun, because of the requirement that users must manually accept Sun's license before downloading the jars. This reduces the usefulness of using the repository for dependency resolution. I see several possible workarounds for this: Virtual hosting --- With this approach, none of the artifacts are hosted within the public repository. http redirection is used to direct 'virtual' artifact accesses to the real artifact. The limitation of this approach is that automatic artifact resolution can only work if the redirect is to the real artifact. This rules out all of the Sun jars which require acceptance of Sun's license first. A tool can 'screen scrape' the redirected page, prompt the user to accept the license and only download if the license is accepted, but this doesn't work in the general case. Direct hosting -- With this approach, artifacts are hosted within the public repository, but download is only enabled if the user agrees to the license. This implies that http redirection must be used and that tools have to be intelligent enough to handle the redirection and prompt the user. The limitation of this approach is that direct hosting can only be supported if an agreement can be made with the license holder. Thoughts?
Re: click through license support?
Tim Anderson wrote: ... Virtual hosting --- With this approach, none of the artifacts are hosted within the public repository. http redirection is used to direct 'virtual' artifact accesses to the real artifact. The limitation of this approach is that automatic artifact resolution can only work if the redirect is to the real artifact. This rules out all of the Sun jars which require acceptance of Sun's license first. 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. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
