[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| 
Re: [iam-dev] Re: [technology-pmc] Eclipse IAM: Possible need for	3rd	party dependency approval
 | 
IMHO it is very simple. If the infrastructure is downloading licensed 
stuff then the user must be aware of the license and have agreed to it.
Say some project Foo's POM declares a requirement for builder/plugin 
Bar.  As I understand it, to build Foo, Bar will have to be downloaded 
and installed.  The user asking for a build of Foo then will, 
unknowingly cause the download and install of Bar without ever having 
been told about the licenses or be given a chance to agree.  I don't 
think it matters that the POM states this requirement.  It does not 
state the license nor does it present itself to the user.
I certainly understand that this is a bummer and am not suggesting that 
everyone have to go through this workflow.  I am saying that the maven 
tools should facilitate prompting the user to accept licenses before 
they install stuff.  You can have a preference to turn that off if you like.
I am also not understanding the relationship here to the maven repo 
discussion.  Presumeably the repo can contain all manner of stuff under 
all manner of licenses.  There is no way the IP team can approve the 
blanket consumption of everything in the repo.  Stepping back though I 
think the question itself does not make sense.  if you put the license 
accpetance question in the hands of the user then maven is just acting 
as a broker.  the POM states the need and the user agrees to the 
license.  Nothing in Maven itself has the dependency.
For bits of the maven integration projets (IAM, m2e and any other 
project at eclipse being built with Maven) it is an interesting question 
as to what dependenceis they can declare in their POMs.  For example is 
is allowed for some m2e project to say that it needs a GPL maven plugin 
to be built?  That effectively forces community members to install the 
GPL thing into their Eclipse IDE in order to build the project.  That;s 
a good one for the IP team.
Jeff
Eugene Kuleshov wrote:
 Just to give some background, generally, Maven allow to specify 
external configuration in its global configs, user's config, as well 
as per-project. Depending on configuration, Maven can just go ahead 
and download and even execute 3rd party components and it is not 
always obvious when this is triggered or what repository those 
components came from.
 I think that from the end user point of view it is fair to say that 
when user to choose to import some project in Eclipse workspace, then 
he basically allowed to go outside and grab everything that project 
declared. But it would be great to get common understanding from 
Eclipse Legal team on that.
 There is also some local configuration on Eclipse side where user 
could declare additional repositories and other external stuff that 
can be used by Maven, which also imply that user confirmed that. For 
example, in M2E project we have separate feature with the reference to 
the Maven central repository that is installed using standard update 
mechanism, and show the license or agreement info at the installation 
time, but such agreement info may not be obviously noticeable to all 
end users and yet this link is very critical for the core functionality.
 regards,
 Eugene
Abel Muiño Vizcaino wrote:
Hello Wayne,
El 18/12/2008, a las 17:09, Wayne Beaton wrote:
Hi Abel.
It sounds to me like the "central Maven repository" is a potential 
"exempt pre-requisite".  Which means that IAM should be able to 
include some knowledge of how to find and access that respository. 
Ultimately, we'll need to get EMO approval on that.
That would be a manageable solution if approved by the EMO.
Further, my sense is that by adding a link to another repository (or 
however it is that you do this sort of thing), the user is giving 
IAM explicit permission to access the archetypes available from that 
repository.
I agree with that.
Other artifacts downloaded by maven would fall in the same category 
(the user enters the information to locate them or otherwise requests 
their use, so he is allowing IAM to work on his behalf).
FWIW, it's true that p2 can be used to install arbitrary things 
without the user's consent. However, that's not how it *is* being 
used (or rather how it should be used by an Eclipse project). A 
company could take p2 and use it as part of their project to install 
whatever they want; this would be an issue between that company and 
their end users.
Of course do not support or encourage installing anything without the 
user consent. It was my perception that by providing the information 
to identify the archetype/artifact the user was already allowing 
access. You summarized it perfectly above.
Does this make sense/help?
Sure. I think these can solve all the IP concerns being addressed and 
can be managed by the IAM team. Thank you very much!
We only need EMO approval regarding the maven central repository. How 
shall we proceed with this task?
Wayne
Abel Muiño Vizcaino wrote:
Hello Wayne,
El 12/12/2008, a las 19:58, Wayne Beaton escribió:
Does the user enter the URL for the Archetype, or is the URL 
somehow embedded in the software?
If the URLs are provided by the user, then there should be no 
problem.
It is a bit complicated... there is not such thing as "the URL". 
The user only declares the archetype to use. That declaration is 
then looked up in an artifact repository (by default maven central 
repository, but it is considered good practice to use a corporate 
"mirror"). The actual repository used depends on a set of rules set 
by the end user.
I've been thinking that writing an overview of how IAM/maven 
operates and relate that to the policy for 3rd party dependencies 
(http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf) 
could help us moving forward. What do you think?
If the IAM project contains built-in URLs to existing 
repositories, then we'll need a works-with CQ (probably one for 
each URL, but this may require additional thought). We'll have to 
get EMO agreement.
It should not be a problem from our side if it is limited to the 
url or the maven central repository. However, as noted above, that 
repository might not be used at all (and as stated previously, it 
is impossible to review every possible artifact in a maven 
repository).
In either case, the download needs to be obvious. We need IAM to 
show a dialog saying something to the effect of "you're about to 
download some code not vetted by the Eclipse IP process" or 
something to that effect (it might be enough to say that the code 
is "external"). If the thing being downloaded has a license 
attached to it, the user needs to be given an explicit opportunity 
to view and accept that license.
Technically, that can be done, although I'm very worried about the 
resulting user experience. What would you consider "obvious"? 
Showing the download progress? A note on the user interface?
FWIW, Buckminster and P2 both do this.
No attack intended on any of these projects.
But we use the P2 director (headless)  application to assemble out 
target platform (installing EPL'ed and non EPL'ed bundles) and it 
does not show any license agreement.
And I strongly believe that this is the right thing to do (from an 
end-user point of view, I've explicitly declared what I want to 
use, so I know what I'm getting into).
_______________________________________________
iam-dev mailing list
iam-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/iam-dev
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc