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? Jeff 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.
regards,
Eugene
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc
_______________________________________________ technology-pmc mailing list technology-pmc@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/technology-pmc
|
