|Re: [technology-pmc] Eclipse IAM: Possible need for 3rd party dependency approval|
If the URLs are provided by the user, then there should be no problem.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.
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.
FWIW, Buckminster and P2 both do this. HTH, Wayne Abel Muiño Vizcaino wrote:
There is information about the download taking place (although it might be non obvious) and there are no licenses displayed in the process (maven doesn't display one and most archetypes lack license information, even those released by the maven project).El 10/12/2008, a las 17:03, Wayne Beaton escribió:Is it the case that the user is aware that the download is happening and explicitly accepts the license for the archetype before it is downloaded?Wayne Abel Muiño wrote:Dear PMC members, During the IP review of the code contribution for IAM (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2723), we have been prompted to ask the PMC the appropriate dependency type for maven archetypes used by the code. I'm forwarding the whole conversation and copying Sharon so she'saware of the PMC decision.Maven Archetypes are project templates that are downloaded on demand from maven repositories. As such, they can have any content and license and thefull list of available archetypes can not be determined in advance.A similar thing happens with maven artifacts (archetypes are just a type ofartifacts). To put it simply, a maven artifact is anything that can bedownloaded from a maven repository (public or corporate, with any licensingterms and any content). Typical artifacts are binary jars, source code, javadocs and metadata. By reading the Eclipse Policy and Procedure for 3rd PartyDependencies<http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf>,I think that we don't need to declare a dependency:*The key issue we need to address is the one where projects are essentiallybypassing the IP due* *diligence process by prereq'ing third party software, which is to be downloaded and installed separately** **by the user, instead of redistributing such software in their projects.* (Emphasis mine)Since IAM downloads the files on its own, I don't think the policy rulesapplies (the user does not download or install anything).To me, IAM behavior is no different than P2, Buckminster, WTP installable runtimes, Mylyn issue and patch management and many other eclipse projectswhich use available external resources.In any case, if the policy is to be followed, I think that IAM would need todefine a "works-with maven artifacts" dependency (if such a generic statement is valid).On the same line, IAM is able to download repository indexes from arbitrarylocations. Should we ask for a "works-with repository indexes" also?It can also download archetype lists from any location (like a wiki page).Does this require a "works-with artifact lists"? Thanks! Abel Muiño ---------- Forwarded message ---------- From: Abel Muiño <amuino@xxxxxxxxx> Date: Tue, Nov 25, 2008 at 4:35 PM Subject: Re: CQ2723: q for Eclipse To: Sharon Corbett <sharon.corbett@xxxxxxxxxxx> Cc: Carlos Sanchez <carlossg@xxxxxxxxx>, Barb Cochrane < barb.cochrane@xxxxxxxxxxx> Thanks for the detailed explanation.Everything is clear except for "Point 2 - files are not packaged with IAM orin SVN - they are downloaded at Runtime", which I think I didn't expain clearly enough.The user of IAM can describe the artifacts (files) that he will be using andit will then ask IAM to download them as needed. Those files are not required by IAM and, more importantly, are not known in advance.Those files are downloaded from locations unknown to us (the user can pointto several locations, some of the files might be internal to his organization).I would say the IAM's situation is not different from P2/Update Manager or Buckminster (which can download any kind of file), CVS/SVN tooling, (which also can fetch some files in behalf of the user) or maybe the "downloadable runtimes" from WTP (which are created by third parties without knowledge ofthe WTP developers). We can talk this with the PMC, but I'm hoping that it is just my badexplanation which caused a misunderstanding, and we can skip IP review of every single file that can be downloaded while using IAM (which, to put itsimply, is an infinite number). Thanks for your time and good advice! On Tue, Nov 25, 2008 at 3:36 PM, Sharon Corbett <sharon.corbett@xxxxxxxxxxx>wrote:Hi Guys:Regarding Point 2 - files are not packaged with IAM or in SVN - they are downloaded at Runtime. This means that your project has a dependency on these files. As such, please see the Eclipse Guidelines for Third Party Dependencies<http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf>. You will need to discuss which dependency applies in this situation with your PMC via the PMC Tech Mailing List. You will note that "works with" dependencies can be approved solely by your PMC. However, "pre-exempt"dependencies must be approved by the EMO via a submitted CQ.Regarding Points 3 and 9 – Even a few lines of code from any third partypackage must be requested via a CQ if they are being distributed fromEclipse. You can request a "subset" of files for any component from Maven that you require. You do not have to request the entire component. Please note in cases where a small amount of third party code is included in an EPL File, we would expect to see a reference to the third party license and identification of third party package below the EPL header. In the case where third party files are modified and distributed by Eclipse, a CQ again is required and the modified files would be solely under the third partylicense not the EPL. Regarding the last point of delaying the submission of CQs for Mavencomponents (29 source/binary dependencies), we typically do not review alpha or beta code unless there are extenuating circumstances involved which are dealt with on a case by case basis. However, if any of the componentsare in RC stages, we would recommend that you enter the CQs now as theNonEpl due diligence queue is quite long. For third party code where a full release is imminent, you can enter the CQ now with the latest version and update the CQ when the code is fully released as long as the CQ has not yetbeen reviewed – this will ensure you are in the queue. Regarding the advice concerning once a version of a component has beenapproved; new versions are easier to process. Yes, this is mostly true depending on the length of time and the amount of changes in the approved code base versus the new code. If both of these are minimal we perform a"diff" scan which typically takes less time but again keep in mind the NonEPL queue is long.I hope this helps. I'm copying my colleague, Barb Cochrane, on this emailas Barb handles most of the third party reviews. Regards, Sharon -----Original Message----- From: Content-filter at foundation.eclipse.org [mailto: virusalert@xxxxxxxxxxx] On Behalf Of Abel Muiño Vizcaino Sent: Monday, November 24, 2008 4:51 PM To: Sharon Corbett Cc: Abel Muiño Vizcaino; Carlos Sanchez Subject: CQ2723: q for Eclipse Hi Sharon, I have some questions that I think would be better addressed outside of the CQ. Point 2: I'm not sure we need a CQ for this. The files are not packaged with IAM or in svn. They are downloaded as needed at runtime. Points 3 and 9 are not covered by another CQ. Since we only use a few lines of code, I'm wondering if we need to file a CQ for the whole Maven component (I guess that we can file a CQ for the XSD files alone, not so sure about java files). Slightly related to this is that we've been delaying the submission of CQs for maven components (29 source/binary dependencies), since many of them have not made an official release yet and we might need to update them very often. We currently host them outside of eclipse. Our mentors told us that once a version of a component has been approved, new versions are easier to process. If that's the case, we can submit the current (unreleased) versions of the components for review and re-submit released versions later. Is that right? can we submit a zip of code for an unreleased version of the maven components and have it approved? Thanks! Abel- -- Abel Muiño - http://ramblingabout.wordpress.com/ - -- Abel Muiño - http://ramblingabout.wordpress.com/------------------------------------------------------------------------_______________________________________________ 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_______________________________________________ technology-pmc mailing list technology-pmc@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/technology-pmc
Back to the top