On 2/13/2011 9:34 AM, Paul Gilmartin wrote:
IANAL, but "vendor's own product" might be a slippery concept. Would this preclude the vendor's using code licensed from a subcontractor? If not, might the vendor engage the actual customer as a subcontractor who licenses the payload code to the vendor, who then licenses it back (exclusively) to the customer in order to circumvent the EULA?
IANFA either. But, I don't think your legal 'workaround' would hold up. (Otherwise, it would have been used years ago by people craftier than you and me.) Also, the customer's EULA is not relevant here. Rather, I was referring to a separate agreement between IBM and the ISV that is licensing their zIIP-enablement technology. Basically, the vendor's "offering"--the part eligible for zIIP enablement--is what they "shrink wrap" and sell. The customer's code is not part of that offering. Now if the vendor liked the customer's code so much that they agreed to license/purchase it and include it as part of their "offering," making it available to the community at large, then that would probably be OK. Otherwise, I think it would be a clear violation of the obvious intent of the agreement between IBM and ISV wherein no 'third party' code should be zIIP enabled. (Again, IANFA!) And there is still the issue of running (what's intended to be) problem state user TCB code in an SRB. Imagine if an ordinary CICS transaction written in COBOL could circumvent RACF, look at and/or write on any storage, or bring down the system or sysplex deliberately or accidentally. That's why it's called an integrity exposure! ;-) I can't imagine any responsible ISV would deliberately take such risks and enable such a thing. I suspect the SRB runs only the vendor's own code, which renders this entire discussion purely hypothetical. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 [email protected] http://www.phoenixsoftware.com/
