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 >>> >
