You are viewing a plain text version of this content. The canonical link for it is here.
Posted to repository@apache.org by Tim Anderson <tm...@netspace.net.au> on 2003/11/15 07:02:56 UTC
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?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: click through license support?
Posted by Tim Anderson <tm...@netspace.net.au>.
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
This group can certainly make statements about [1]-[4],
as they are language and platform neutral.
However, for the java space, [5] is perhaps the most useful.
I would like it to be part of the scope for this group,
to enable compatibility between tools.
E.g, given the URI:
http://repo.apache.org/sun/jndi/jars/jndi-1.2.1.jar
a tool would automagically go to the Sun website, prompt the user
to accept the license, download the jndi-1_2_1.zip distribtion and
extract the jar.
In terms of implementation, this could be done via redirection
to a descriptor containing instructions for obtaining the
real artifact. This descriptor might consist of:
. the URL of the real artifact
. licensing requirements
. processing requirements to:
. extract the artifact
E.g, if the artifact is part of a larger distribution,
how to extract it from that distribution.
. massage the artifact
E.g, renaming the artifact, or changing
MANIFEST.MF Class-Path entries to use repository naming
conventions.
The meta data required to support this are language and platform
specific. However, I think it should be easier to form a concensus
on the meta-data requirements and format to support this than
for other meta-data proposals which are more to do with
artifact description than artifact resolution.
-Tim
> -----Original Message-----
> From: Nick Chalko [mailto:nick@chalko.com]
> Sent: Thursday, 20 November 2003 11:03 AM
> To: repository@apache.org
> Subject: 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?
Posted by Nick Chalko <ni...@chalko.com>.
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?
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Nick Chalko [mailto:nick@chalko.com]
>
> 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?
Posted by Nick Chalko <ni...@chalko.com>.
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
RE: click through license support?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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
Re: click through license support?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
dion@multitask.com.au 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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: licensing issues for virtual artifacts (was RE: click through license support?)
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Nick Chalko [mailto:nick@chalko.com]
>
> 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?)
Posted by Nick Chalko <ni...@chalko.com>.
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: licensing issues for virtual artifacts (was RE: click through
license support?)
Posted by Geir Magnusson Jr <ge...@optonline.net>.
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)
geir@4quarters.com
Re: licensing issues for virtual artifacts (was RE: click through
license support?)
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> 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.
Dw
Re: licensing issues for virtual artifacts (was RE: click through
license support?)
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
I'd like to jump in here. I'm lazy and will go back and read all the
threads later, but I've been overwhelmed recently, and just want to
relay some info :)
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.
That said, I'm going to go back through the thread and catch up. If
someone wants me to stop this activity with Sun, let me know.
Otherwise, I will do what I can to make the whole issue go away for us.
geir
On Nov 20, 2003, at 6:53 PM, 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.
>
> 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: dion@multitask.com.au [mailto:dion@multitask.com.au]
>> Sent: Wednesday, 19 November 2003 2:46 AM
>> To: repository@apache.org
>> Subject: Re: click through license support?
>>
>>
>> Nicola Ken Barozzi <ni...@apache.org> wrote on 19/11/2003
>> 01:31:13 AM:
>>
>>>
>>> dion@multitask.com.au wrote:
>>>
>>>> Nicola Ken Barozzi <ni...@apache.org> 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/
>>
>>
>>
>>
>>
>
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
RE: licensing issues for virtual artifacts (was RE: click through license support?)
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Sunday, 23 November 2003 5:25 PM
>
> > > How do you propose to implement such artifacts? What impact will
> > > that have on web site deployment and mirroring requirements?
>
> > 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.
>
> Whoa, so there is no reality for the artifact? We just redirect to a
> descriptor containing meta-data? I think we can clean that up, and we'll
> both be happy.
A zero-length file would be better, so it appears in automatically
generated indexes for users browsing the repository.
MD5 checksums etc can still be hosted within the repository alongside
the dummy jar, so tools can verify that what they get after
download is that which is expected.
Alternatively, require that the repository supports WebDAV,
don't use redirects, instead including the descriptor in
http://repo.apache.org/sun/jndi/1.2.1/jars/jndi-1.2.1.jar
and assign it a content type of "application/artifact-descriptor",
to enable WebDAV aware tools that it is a descriptor rather
than a real jar. Could be misleading for users browsing the
repository however.
>
> > [...] obtaining permission from the 3rd party first.
>
> And if they say no, we'll need to do it without such an artifact
> anyway, so
> we might as well drop the fiction.
>
> --- Noel
>
>
RE: licensing issues for virtual artifacts (was RE: click through license support?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > How do you propose to implement such artifacts? What impact will
> > that have on web site deployment and mirroring requirements?
> 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.
Whoa, so there is no reality for the artifact? We just redirect to a
descriptor containing meta-data? I think we can clean that up, and we'll
both be happy.
> [...] obtaining permission from the 3rd party first.
And if they say no, we'll need to do it without such an artifact anyway, so
we might as well drop the fiction.
--- Noel
RE: licensing issues for virtual artifacts (was RE: click through license support?)
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Sunday, 23 November 2003 11:42 AM
> To: repository@apache.org
> 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
RE: licensing issues for virtual artifacts (was RE: click through license support?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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?
> 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.
--- Noel
Re: licensing issues for virtual artifacts (was RE: click through
license support?)
Posted by Nick Chalko <ni...@chalko.com>.
dion@multitask.com.au 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?)
Posted by di...@multitask.com.au.
Nicola Ken Barozzi <ni...@apache.org> wrote on 25/11/2003 07:23:15 PM:
>
> dion@multitask.com.au 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?)
Posted by Tim Anderson <tm...@netspace.net.au>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Wednesday, 26 November 2003 1:34 PM
>
> Nicola Ken Barozzi wrote
> > dion@multitask.com.au 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?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Nicola Ken Barozzi wrote
> dion@multitask.com.au 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?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
dion@multitask.com.au 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.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: licensing issues for virtual artifacts (was RE: click through license
support?)
Posted by di...@multitask.com.au.
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*.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
"Tim Anderson" <tm...@netspace.net.au> wrote on 23/11/2003 11:06:08 AM:
> 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
>
> They are not about:
> . hosting 3rd party artifacts within ASF repository
> . circumventing licenses of 3rd party products
> . exposing ASF to liability
>
> So far, no one has demonstrated that virtual
> artifacts would expose ASF to liability -
> although I'm not privvy to discussions held on
> non-public ASF lists.
>
> -Tim
>
> > From: Noel J. Bergman [mailto:noel@devtech.com]
> > Sent: Sunday, 23 November 2003 10:41 AM
> > To: repository@apache.org
> >
> > > 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?)
Posted by Tim Anderson <tm...@netspace.net.au>.
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
They are not about:
. hosting 3rd party artifacts within ASF repository
. circumventing licenses of 3rd party products
. exposing ASF to liability
So far, no one has demonstrated that virtual
artifacts would expose ASF to liability -
although I'm not privvy to discussions held on
non-public ASF lists.
-Tim
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Sunday, 23 November 2003 10:41 AM
> To: repository@apache.org
>
> > 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?)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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?)
Posted by Tim Anderson <tm...@netspace.net.au>.
See inline.
> From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> Sent: Friday, 21 November 2003 11:12 AM
>
> I'm not sure of the relevance of this to an ASF repository, but....
Convenience. ASF repository can provide a single point of
access for commonly used artifacts. This avoids the need
for users to be directed via documentation to various websites
to locate JARS for example, in order to build ASF programs.
As a consequence, it cuts down on emails like "I tried to build
X but it failed because class javax.foo.Bar not found".
>
> "Tim Anderson" <tm...@netspace.net.au> wrote on 21/11/2003 10:53:47 AM:
>
> > 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.
>
> IANAL, but the download tool is distributing the binary version of the
> code.
IANAL either, but how is this different to a user manually
downloading the distribution using IE, and then extracting it
with winzip? Neither Microsoft nor Winzip have any liability.
-Tim
Re: licensing issues for virtual artifacts (was RE: click through license
support?)
Posted by di...@multitask.com.au.
I'm not sure of the relevance of this to an ASF repository, but....
"Tim Anderson" <tm...@netspace.net.au> wrote on 21/11/2003 10:53:47 AM:
> 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.
IANAL, but the download tool is distributing the binary version of the
code.
[snip]
> . "(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.
This depends on how someone defines 'distribute'.
> . "(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 the download tool has distributed the software, and it's ASF's download
tool....
> If this has been discussed elsewhere, could you post a link?
Maybe Jason can provide a link to the board discussion asking us to stop
doing the distribution.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
licensing issues for virtual artifacts (was RE: click through license support?)
Posted by Tim Anderson <tm...@netspace.net.au>.
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: dion@multitask.com.au [mailto:dion@multitask.com.au]
> Sent: Wednesday, 19 November 2003 2:46 AM
> To: repository@apache.org
> Subject: Re: click through license support?
>
>
> Nicola Ken Barozzi <ni...@apache.org> wrote on 19/11/2003 01:31:13 AM:
>
> >
> > dion@multitask.com.au wrote:
> >
> > > Nicola Ken Barozzi <ni...@apache.org> 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/
>
>
>
>
>
Re: click through license support?
Posted by di...@multitask.com.au.
Nicola Ken Barozzi <ni...@apache.org> wrote on 19/11/2003 01:31:13 AM:
>
> dion@multitask.com.au wrote:
>
> > Nicola Ken Barozzi <ni...@apache.org> 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/
Re: click through license support?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
dion@multitask.com.au wrote:
> Nicola Ken Barozzi <ni...@apache.org> 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.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: click through license support?
Posted by di...@multitask.com.au.
Nicola Ken Barozzi <ni...@apache.org> wrote on 15/11/2003 10:00:07 PM:
>
> 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.
But still illegal.
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.
See http://maven.apache.org/sun-licensing-journey.html
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Re: click through license support?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------