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:
key issue we need to address is the one where projects are essentially
bypassing the IP due
process by prereq'ing third party software, which is to be downloaded
and installed separately
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
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
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
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
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