|Re: [iam-dev] Re: [technology-pmc] Eclipse IAM: Possible need for 3rd party dependency approval|
Jeff McAffer wrote:
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. :-)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.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.
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...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.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.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. :-)of course, I could be completely off base here ...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.
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.
Back to the top