Re: [iam-dev] Re: [technology-pmc] Eclipse IAM: Possible need for 3rd pa

[Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>]

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