> From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: Sunday, 23 November 2003 11:42 AM > To: [EMAIL PROTECTED] > Subject: RE: licensing issues for virtual artifacts (was RE: click > through license support?) > > > > Virtual artifacts have the potential to: > > . simplify build environments > > . simplify installation documentation > > . reduce the bar of entry for building ASF software > > . reduce support requests > > . allow meta-data to be associated with 3rd > > party artifacts > > How do you propose to implement such artifacts? What impact will > that have > on web site deployment and mirroring requirements?
Not 100% sure. I imagine the redirects would need to be set up manually. If mirroring uses rcp or similar, then the redirection info would be copied. Given the URI: http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar This could redirect to: http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar.descriptor The .descriptor file could have a specific mime type to let tools know that they need to do additional processing, or they could rely on the extension as an indicator. Assume the .descriptor contains the following: <java> <artifact-adapter> <main-class>org.apache.artifact.sun.VirtualSunArtifact</main-class> <class-path> <path>http://repo.apache.org/apache/artifact/1.1/jars/sunartifact-1.1.jar</p ath> </class-path> <param name="product" value="jndi"/> <param name="version" value="1.2.1"/> <param name="artifact" value="jndi-1.2.1.jar"/> </artifact-adapter> </java> VirtualSunArtifact implements an interface 'VirtualArtifact' which allows tools to: . specify where to download the distribution to . specify where to place the jndi-1.2.1.jar artifact, extracted from the distribution. VirtualSunArtifact pops up a browser on the Sun JNDI download page, and requires the user to accept the license. Once accepted, it proceeds to download the distribution and extract the artifact. > > > They are not about: > > . hosting 3rd party artifacts within ASF repository > > . circumventing licenses of 3rd party products > > . exposing ASF to liability > > The issue I had in mind was more about confusion, e.g., confusing > the source > of the file, which might not be acceptable to the distributor. > In our case, > consider this page: http://www.apache.org/info/referer-dotcom.html. > > Look, you never know what is going to happen in the real-world. > Some years > ago we (DevTech) wrote a search engine. As a demo, we indexed > the Star Wars > site, which was otherwise hard to navigate at the time, and > provided people > with search capabilities. We had none of their IP on our site. > We offered > a site-specific search, similar to asking Google to restrict its search to > their site, except we offered a few other views of the data. Even so, we > received an official request from Lucas' legal council to cease. > The legal > basis they claimed was that they can control who uses their trademark, and > their URL contains their trademark. > This can be avoided by obtaining permission from the 3rd party first. The download tool can also require acknowledgement of disclaimers stating that the ASF does not host the artifact, is in no way responsible for the end-user's use of the artifact, and that by downloading the artifact, they are bound by the license of the artifact. -Tim