| As suggested by Wayne, since the user explicitly request an artifact to be used, we can assume that he has already allowed IAM to access it. So we can skip displaying the license explicitly (as you mention, it can break the user workflow quite easily).
This is an excerpt of the guidelines for 3rd party dependencies describing exempt pre-reqs, so we all are on the same page:
A pre-req may be classified as "exempt" by the EMO if the software is pervasive in nature, expected to be already on the user's machine, and/or an IP review would be either impossible, impractical, or inadvisable.
With that in mind, getting approval for the central repository as an exempt pre-req makes a lot of sense. We are providing default configuration that access it, but it is impossible to conduct an IP review on the full contents of the repository (for many reasons, the most obvious one is that it can grow unbounded).
I find Wayne's comments as a good solution, but if there is any concern, please let me know so we can bring it to the PMC.
On a related note, Joakim comments made me think that license filtering could make for a great feature, so corporate users can disallow the use of unsafe licenses. I can also see this being useful inside the Eclipse foundation (once we lure everyone to use maven for describing their projects ;-) ) or (maybe) the Apache Foundation so that no project uses GPL'd code. Of course, this should be in addition of other checks outside the IDE (maybe something already exists as a maven mojo?).
El 18/12/2008, a las 19:06, Joakim Erdfelt escribió: Some things to think about.
a) The metadata present on the artifacts can (and in large part do) have License information indicating the project's chosen licensing mechanism.
This metadata license can either be direct (example: http://repo1.maven.org/maven2/com/jcraft/jsch/0.1.38/jsch-0.1.38.pom which declared license BSD)
or can be referenced from a parent definition (example: http://repo1.maven.org/maven2/org/apache/commons/commons-io/1.3.2/commons-io-1.3.2.pom references parent http://repo1.maven.org/maven2/org/apache/commons/commons-parent/3/commons-parent-3.pom which references parent http://repo1.maven.org/maven2/org/apache/apache/4/apache-4.pom which has the license defined as ASL)
This information can be presented to the user. Either passivly, as a license indicator on the dependency as present on the project's "maven classpath container", or interactively, as an approval dialog (which would turn out to be quite annoying in a very short order, unless some UI for blanket approval based on license type or artifact groupId could be established)
b) The archetype bundles being fetched from the repository system (yes, there can be more than 1 repository) is just a jar file containing metadata on how to generate a project boilerplate. There are no binaries (or bytecode) present in that jar file.
b.1) Archetype licensing is in part 2 fold. The archetype author has a license attached to the archetype metadata, and the generated project will often have its own license, usually chosen and assigned by the new project creator.
- Joakim
On Thu, Dec 18, 2008 at 9:09 AM, Wayne Beaton <wayne@xxxxxxxxxxx> 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.
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.
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.
Does this make sense/help?
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
|
