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/vim25/AgentInstallFailed.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/LEGAL-180 >>>>>> >>>>>> 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 >>>>>>>> >>>>> >>>> >>> >
