Where do we get the source code of vim25.jar the first place? VMware only releases WSDL but not the java source, we can either copy it from vijava or generate it ourselves to put it into our source repo, but if we do generate, it would be easier to maintain the code base if this generation step is also automatic and in our build scripts. I’m also fine to just put the source code into CloudStack if we can always get it from somewhere without a license issue
Kelven On 2/18/14, 2:43 PM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> wrote: >Why do we need the WSDL at all? Why can't we check in vim25 sources like >the vijava project has done? > >On 2/18/14 2:42 PM, "Kelven Yang" <kelven.y...@citrix.com> wrote: > >>The reason why it ended up at noredist build is that the binary jars are >>copied from VMware SDK, we are not sure about the license implication and >>we don’t build it from source. >> >>In VMware 5.1 SDK, vim25.jar is generated from importing WSDL plus a >>fix-up, the fix-up step is performed by a tool named >>FixJaxWsWsdlResource. I disassembled the tool and found that it merely >>replaces VimService.class resource search path before it compiles WSDL >>generated java files. >> >>So technically, if there is not any license concerns, we can put all >>these >>into our build scripts, but before I go ahead to do that, someone has to >>clear the legal concern of following steps >> >>1) include vim25.wsdl into CloudStack source code distribution >>2) Include a fixup tool, not sure we can directly take it from VMware’s >>SDK or is it a problem to rewrite it by us from license point of view. >>3) Build script to produce a vim25.jar from CloudStack >> >>Kelven >> >> >> >> >>On 2/18/14, 2:07 PM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> >>wrote: >> >>>If vim25.jar source is BSD then why are we including it in noredist? >>> >>>mvn install:install-file -Dfile=vim25_51.jar >>>-DgroupId=com.cloud.com.vmware -DartifactId=vmware-vim25 >>>-Dversion=5.1 >>> -Dpackaging=jar >>> >>> >>> >>>On 2/18/14 1:51 PM, "David Nalley" <da...@gnsa.us> wrote: >>> >>>>That's still licensed as BSD (the license header is in the file) >>>> >>>>--David >>>> >>>>On Tue, Feb 18, 2014 at 3:54 PM, Chiradeep Vittal >>>><chiradeep.vit...@citrix.com> wrote: >>>>> Not all. >>>>> >>>>>http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vim >>>>>2 >>>>>5 >>>>>/ >>>>>mo >>>>> /Alarm.java >>>>> >>>>> >>>>> On 2/18/14 12:05 PM, "David Nalley" <da...@gnsa.us> wrote: >>>>> >>>>>>Option 1 still needs licensing sorted. Being on a maven repo still >>>>>>doesn't fix the problem for us and our users. >>>>>> >>>>>>WRT to vijava the classes in source all appear to have a copyright >>>>>>header indicating that Steve is the author and licensed under BSD. >>>>>>In example: >>>>>>http://sourceforge.net/p/vijava/code/283/tree/trunk/src/com/vmware/vi >>>>>>m >>>>>>2 >>>>>>5 >>>>>>/A >>>>>>gentInstallFailed.java >>>>>> >>>>>>--David >>>>>> >>>>>>On Tue, Feb 18, 2014 at 2:47 PM, Chiradeep Vittal >>>>>><chiradeep.vit...@citrix.com> wrote: >>>>>>> I'd say option 1 is the easiest to digest. >>>>>>> On that note, are we gaining anything (legal-wise) by switching to >>>>>>>vijava? >>>>>>> I just uncompressed the download[1]. It bundles the compiled >>>>>>>classes >>>>>>>found >>>>>>> in vim25.jar which is (presumably) VMWare proprietary. >>>>>>> >>>>>>> >>>>>>> [1] http://vijava.sourceforge.net/ >>>>>>> >>>>>>> On 2/18/14 11:10 AM, "David Nalley" <da...@gnsa.us> wrote: >>>>>>> >>>>>>>>#1 would still need licensing sorted - explicitly it would need to >>>>>>>>be >>>>>>>>a Cat A or Cat B license. >>>>>>>>https://www.apache.org/legal/3party.html >>>>>>>> >>>>>>>>#2 or similar would work I think (though I'd imagine they'd choose >>>>>>>>MIT or BSD if going that route) >>>>>>>> >>>>>>>>#3 A statement that they don't consider the WSDL copyrightable (I >>>>>>>>can't imagine they'd go for that, but who knows, makes sense >>>>>>>>technically and Feist v Rural seems to suggest that 'information' >>>>>>>>or >>>>>>>>even 'collection of information' isn't copyrightable without an >>>>>>>>element of creativity. WSDL by it's nature is a description; and >>>>>>>>the >>>>>>>>phonebook analogy plays well there. >>>>>>>>http://en.wikipedia.org/wiki/Feist_v._Rural >>>>>>>> >>>>>>>>--David >>>>>>>> >>>>>>>> >>>>>>>>On Tue, Feb 18, 2014 at 1:26 PM, Chiradeep Vittal >>>>>>>><chiradeep.vit...@citrix.com> wrote: >>>>>>>>> I just pinged the attorney again (there is a live one assigned to >>>>>>>>>this >>>>>>>>> question on the VMWare side). >>>>>>>>> >>>>>>>>> What options will work? If we can provide some concrete options, >>>>>>>>>perhaps >>>>>>>>> they will pick >>>>>>>>> 1. Provide generated SDK jars in maven repo >>>>>>>>> 2. Explicitly add ASL to WSDL >>>>>>>>> 3. ? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Chiradeep >>>>>>>>> >>>>>>>>> On 2/18/14 7:14 AM, "Hugo Trippaers" <h...@trippaers.nl> wrote: >>>>>>>>> >>>>>>>>>>Chiradeep, >>>>>>>>>> >>>>>>>>>>Whats the progress on this? >>>>>>>>>> >>>>>>>>>>Cheers, >>>>>>>>>> >>>>>>>>>>Hugo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>On 22 jan. 2014, at 23:35, Chiradeep Vittal >>>>>>>>>><chiradeep.vit...@citrix.com> >>>>>>>>>>wrote: >>>>>>>>>> >>>>>>>>>>> Reached out to @strikesme and @danwendlandt >>>>>>>>>>> >>>>>>>>>>> On 1/21/14 10:14 PM, "Hugo Trippaers" >>>>>>>>>>><htrippa...@schubergphilis.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> We are now again at the exact same point as where Darren was. >>>>>>>>>>>> >>>>>>>>>>>> This is the legal ticket relevant to the license discussion: >>>>>>>>>>>> >>>>>>>>>>>>https://issues.apache.org/jira/plugins/servlet/mobile#issue/LEG >>>>>>>>>>>>A >>>>>>>>>>>>L >>>>>>>>>>>>- >>>>>>>>>>>>18 >>>>>>>>>>>>0 >>>>>>>>>>>> >>>>>>>>>>>> Either we get an ok from legal or we need to find an >>>>>>>>>>>>alternative. >>>>>>>>>>>>Kelven, >>>>>>>>>>>> Chiradeep, are you guys going to chase this ticket? >>>>>>>>>>>> >>>>>>>>>>>> Hugo >>>>>>>>>>>> >>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>> >>>>>>>>>>>>> On 22 jan. 2014, at 07:04, "Hugo Trippaers" >>>>>>>>>>>>><trip...@gmail.com> >>>>>>>>>>>>>wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Kelven, Chiradeep, >>>>>>>>>>>>> >>>>>>>>>>>>> What license governs the redistribution, what do we include >>>>>>>>>>>>>in >>>>>>>>>>>>>our >>>>>>>>>>>>> notice file and is that license compatible with the ASF >>>>>>>>>>>>>license >>>>>>>>>>>>>policy? >>>>>>>>>>>>> >>>>>>>>>>>>> Hugo >>>>>>>>>>>>> >>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>> >>>>>>>>>>>>>> On 22 jan. 2014, at 00:44, Kelven Yang >>>>>>>>>>>>>><kelven.y...@citrix.com> >>>>>>>>>>>>>>wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Q. Can I redistribute the VI SDK libraries and sample code? >>>>>>>>>>>>>> A. You can redistribute only those parts of the SDK package >>>>>>>>>>>>>>that >>>>>>>>>>>>>>have >>>>>>>>>>>>>> been >>>>>>>>>>>>>> designated as ³distributable code². >>>>>>>>>>>>>> In VI SDK 2.5, the following components can be >>>>>>>>>>>>>>redistributed: >>>>>>>>>>>>>>vim.jar, >>>>>>>>>>>>>> vim25.jar. To note developers typically generate web service >>>>>>>>>>>>>>stubs >>>>>>>>>>>>>>from >>>>>>>>>>>>>> the WSDL file that is included in the VI SDK using a SOAP >>>>>>>>>>>>>>toolkit. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The stubs source and the compiled stubs can also be >>>>>>>>>>>>>>>>distributed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could this solve our license problem, we discussed before >>>>>>>>>>>>>>that >>>>>>>>>>>>>> generating >>>>>>>>>>>>>> our own java stub can give us flexibility to support >>>>>>>>>>>>>>co-existence >>>>>>>>>>>>>>of >>>>>>>>>>>>>> different versions of VMware web service API inside >>>>>>>>>>>>>>CloudStack. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If we see this as urgency, we need to have someone work on >>>>>>>>>>>>>>to >>>>>>>>>>>>>>put >>>>>>>>>>>>>>WSDL >>>>>>>>>>>>>> generation process to maven build >>>>>>>>>>>>>> >>>>>>>>>>>>>> For latest names of VI SDK libraries that can be >>>>>>>>>>>>>>redistributed >>>>>>>>>>>>>>visit >>>>>>>>>>>>>> http://vmware.com/go/sdk-redistribution-info >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 1/21/14, 3:18 PM, "Chiradeep Vittal" >>>>>>>>>>>>>><chiradeep.vit...@citrix.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Apparently we can >>>>>>>>>>>>>>> https://communities.vmware.com/docs/DOC-7983 >>>>>>>>>>>>>>> http://markmail.org/thread/ttamcfb4d6azzbw7 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 1/21/14 2:46 PM, "Hugo Trippaers" <trip...@gmail.com> >>>>>>>>>>>>>>>>wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Chiradeep, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Even on the generated sources nobody seems willing to >>>>>>>>>>>>>>>>state >>>>>>>>>>>>>>>>that >>>>>>>>>>>>>>>>it >>>>>>>>>>>>>>>> is ok >>>>>>>>>>>>>>>> to include them at the moment. Otherwise I would have put >>>>>>>>>>>>>>>>them >>>>>>>>>>>>>>>>in >>>>>>>>>>>>>>>> already. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hugo >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 21 jan. 2014, at 19:32, Chiradeep Vittal >>>>>>>>>>>>>>>>> <chiradeep.vit...@citrix.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Suboptimal for? >>>>>>>>>>>>>>>>> Wouldn't the ACS user want the best / supported client >>>>>>>>>>>>>>>>>libraries? >>>>>>>>>>>>>>>>> Alternatively, can't we just compile the WSDL and check >>>>>>>>>>>>>>>>>in >>>>>>>>>>>>>>>>>the >>>>>>>>>>>>>>>>> generated >>>>>>>>>>>>>>>>> sources? Not check-in the WSDL, but the client sources. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 1/21/14 7:18 AM, "David Nalley" <da...@gnsa.us> >>>>>>>>>>>>>>>>>>wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Jan 21, 2014 at 9:46 AM, Chip Childers >>>>>>>>>>>>>>>>>> <chipchild...@apache.org> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> I bet we never got an answer. Frankly, I'd like to see >>>>>>>>>>>>>>>>>>>us >>>>>>>>>>>>>>>>>>>use >>>>>>>>>>>>>>>>>>> something where the licensing is clear. That, or we >>>>>>>>>>>>>>>>>>>don't >>>>>>>>>>>>>>>>>>>include >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> WSDL in our repo / distro. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Additionally, we are an open source project that is in >>>>>>>>>>>>>>>>>>the >>>>>>>>>>>>>>>>>> business of >>>>>>>>>>>>>>>>>> producing open source software. Depending on non-free >>>>>>>>>>>>>>>>>>and >>>>>>>>>>>>>>>>>> non-opensource libraries is suboptimal, but its worse >>>>>>>>>>>>>>>>>>when >>>>>>>>>>>>>>>>>>there >>>>>>>>>>>>>>>>>> is a >>>>>>>>>>>>>>>>>> open source alternative. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> --David >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> >
