Skip to main content

[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

Thanks for the background and clarification.  I'll supply a bit of my own :-)

My position has related to the downloading and running of maven plugins not the downloading of artifacts against which you were going to compile for example.   I might be using the wrong Maven term but I mean the stuff that would be downloaded and run to actually execute the build.  Not the stuff that is needed to compile against.  To me this is like dynamically provisioning the IDE itself . While it is true that the p2 infrastructure does not flash licenses in, for example, headless cases, the intent is that users of the IDE are aware of the licenses related to the software they are actually running.  This is more of an IDE "product" statement than an infrastructure issue.

Further, I have been talking about the workflow that ideally Maven integration would present to the user not what IP review is needed.  You need to get IP review for stuff that you ship or that your shipping code actually requires.  Otherwise we would have to clear every library in the universe as technically Equinox could be driven by a config.ini to download and run the library.  The question is not could it but is it.  We agree here.

The idea of listing the maven repo as a exempt prereq does not make sense any more than listing or as exempt.

The challenge here is one of transparency for Eclipse IDE (Maven integration) users.  Developers should know what licenses they are consuming.  There is AFAIK no IP team requirement for p2 to present the licenses to the user.  It was simply a community driven requirement that people using the IDE in products and dev shops placed on the project. IMHO it would make perfect sense for Maven integration users to want the same thing.  Note here that my position here relates to the download and install/running of code in/for the IDE.  This is the equivalent to what p2 does and it seems the same community requirement would play here.

Having said all that, any stuff that IAM or m2e *itself* actually requires and/or is being directly or indirectly supplied by the project plugins should be IP reviewed.  This should NOT include requirements that are embedded in USER data such as projects or POMs.  That is the user adding the dependencies not the project.

With that I believe I have no more to say :-)

Abel Muiño Vizcaino wrote:
I still find Wayne's suggestion reasonable, but if there is no agreement on it, we might need to start over.

I will try to recap and explain how the conversation started, what are my open questions and, finally, explain my understanding of the situation based on the IP documentation available.

The IAM project submitted an initial code contribution for maven integration and during the full review, the ip team detected that the code can download archetypes from repositories and use them to create projects (the same thing is done for any maven artifacts although only archetypes were detected by the ip-team).

By detecting this download, the ip-team required separate IP-review for the downloaded artifacts and suggested contacting the PMC.

From that point on, I have been trying to find a way to allow IAM (and M2E, which is in a similar case) to download and use the artifacts as instructed by the end user.

I would like to know why the IP is needed in the first place. Maven integration work is more like CVS than P2, since the downloaded artifacts are used on the user workspace and not on his eclipse workbench. Because of this, my assumption (and I can see that Eugene's) is that there is no need for IP request or licensing terms.

The P2 example has been brought several times (initially by me) and there is a wrong assumption that it shows licensing information. This is only true for the update manager inside the workbench. On the command line the license is not shown, which I think is perfectly OK since the user is asking P2 to download something (and its dependencies). This is similar to what we are doing with maven...

So, taking an step back and in order to focus the conversation, I think that we need some explanation for:
  a) Why IP review of downloaded artifacts is needed (an extreme counter-example: the browser control in Ecllipse can download anything without a license, just as it can access external javadoc without asking any license agreement)
  b) How is this "let me download the jars for you and make them available to your projects" behavior different from CVS/SVN.

References to IP documents would be extremely useful in focusing the conversation... as I pointed previously, the Guidelines for 3rd party dependencies state in their Background section that:
The key issue we need to address is the one where projects are essentially bypassing 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.

a) "bypassing the IP due diligence": Maven integration (iam or m2e) is NOT trying to bypass IP due diligence. The maven embedder (the only required component) will go through IP review as it stabilizes.

b) IAM (and I suspect M2E) are not "prereq'ing third party software" other than the maven embedder (which is not being discussed)

c) No software "is to be downloaded and installed separately by the user". 

My understanding is that the document does not apply to this case, based on the 3 points above.

El 19/12/2008, a las 0:41, Jeff McAffer escribió:

Fundamentally I belive there is a difference between downloading source for use in a workspace and transparently downloading and running binaries.  The CVS thing is a red herring under this assumption.  I'm not a lawyer and neither is anyone else on this thread.  The IP team should decide on that.

As for the Maven core libs being Apache Licensed.  That's great.  What about the many other plugins that people will end up using?


Eugene Kuleshov wrote:
Jeff McAffer wrote:
Otherwise, this is jumping the gun IMHO.  Its like saying, enter a URL and then assuming that because the user entered the URL they are giving you implicit consent to agree to all licenses on all things in that repo.
Jeff, if I follow your logic, we have pretty much the same situation with CVS plugin distributed with Eclipse Platform. So, user can enter an CVS url and then checkout some projects with gazillion of dependencies and custom builders configured to run on JDT build. But there was not any license confirmation or anything in the CVS project checkout UI.
INAL but I think there si a difference here in that one is downloading source that the user will then see the license for (e.g., in the copyright headers) and is not yet shipping vs. downloading binary that is then combined with existing binaries and used/run.  
I still see no difference. The project you checked out from CVS can have all kind of binaries, e.g. it is a pretty common practice to put jars in a lib folder and then commit it to CVS or SVN, then nothing actually stops committer of that project to configure builder that would run his binaries automatically on the project build in Eclipse.
I am just saying that there is a common sense, otherwise Eclipse Foundation is already in deep troubles because of that small CVS plugin in Eclipse Platform. :-)

While I am not that familiar with Maven, someone saying that they want to have a Foo is not equivalent to them saying, "hey I am ok with you installing GPL code".  The if you are getting something on the user's behalf then the user should know about and be agreeing to the licenses.  If this is the case then there should not be an issue with the repository since it is just another place to get stuff.  The list of "known repos" should be open, modifiable/extensible but beyond that I don't see an IP issue.

of course, I could be completely off base here ...
Generally, all artifacts in Maven repositories have license placeholder (and artifacts that came from the Maven namespace are all APL licensed).
The archetype license could be shown to the user, but as a user I think I will find it quite annoying if license confirmation would be shown to me every time I need to create project.
Just imagine that new Java project wizard would ask you to confirm the EPL license every time. :-)
I'm not saying anything about how, when or how many times the license notice is show to the user except that how many >= 1 and when = before the licensed code is installed.  Presumably you do not download/install the plugins for each project so doing it once the first time you encounter each plugin should be sufficient.

Sidenote:  Ultimately it is likely out of scope for the IP team to mandate that you do this workflow  whoever without this function there are quite some number of development shops that will not accept Maven tooling.  There is a reason we have to ask the license questions that are asked in p2.  It was driven by people wanting to ensure that the dev team knew the licenses for the tools they were using.  Take these comments as you will.
I understand that, but at the same time I don't think it is a job of Maven tooling to provide complete project procurement and License/IP completeness for all dependencies and plugins used during build of some particular project. I actually wonder if Buckminster ask license for every piece it downloads...

Also, in case of Maven, number of dependencies much bigger then you had to deal in p2, so noise ratio when asking licenses may just make whole thing useless. Besides, in practice core Maven plugins are usually licensed under APL.


technology-pmc mailing list
technology-pmc mailing list

_______________________________________________ technology-pmc mailing list technology-pmc@xxxxxxxxxxx

Back to the top