Jeremy, If they are going to *withdraw* entitlement (as reported by the OP) by right associated with ownership of a license and make it contingent upon a separate maintenance contract then yes, I expect to see a *commitment *expressed as well as an entitlement.
Note: this isn't primarily about whether or not there will be any updates/hotfixes to the current version, which a customer may not be in a position to transition to, but whether that customer can *expect* to receive any updates or hotfixes to the previous version they own a license for and may be currently "stuck" on. The expression of entitlement to updates and hotfixes for up to 3 prior versions is offered as part of the value proposition of SA. But there is no *commitment* to realise this value. Historically EMBT have abandoned each Delphi version as soon as a new version is released, almost without exception. Worse: in some cases they have regressed defects previously fixed! Based on that, an entitlement to updates to previous versions is completely and utterly meaningless. If EMBT had a track record of actively and effectively supporting older versions then there wouldn't be an issue. But they don't. It would be quite straightforward to commit to something along the lines of "defects fixed in the current version *will* also be fixed in up to 3 prior versions where affected by the same defect". i.e. yes an "unknown", in terms of exactly what will be fixed, but a quantified and express commitment that certain fixes applied in the current version WILL be fixed in applicable, qualifying prior versions. And to be fair there are a LOT of *known* bugs reported in prior Delphi versions and some of these are claimed to have been fixed in XE8. So where are the updates to fix these for XE5, 6 and 7 ? Some other things to bear in mind: This is the same company that attempted to surreptitiously impose a restriction in their EULA on the use of 3rd party products to extend the capabilities of their own (the prohibition on the use of client/server API's with Pro SKU in XE3). This is the same company that attempted to impose a 5% price rise on [my!] SA renewal in clear and direct contravention of their own terms and conditions for imposing such a rise. This is the same company that advertised and sold cross-platform development in the Pro SKU to entice new users/customers, only to then withdraw that capability. Quite simply this is not a company that has earned the right to be trusted implicitly when it comes to their license and contract terms. Customers - new and old - would be well advised to pay very close attention and to interpret any vague or ambiguous terms in the context of the conduct of the vendor. An empty promise costs nothing to make. EMBT's assessment that at least some people will be naive enough to believe that it represents "value" appears to be right on the money [sic]. There is of course an alternative approach: If there is no intention of providing updates to older versions then simply say so. At least then the value proposition could be more honestly evaluated. The ever-benevolent, butter-wouldn't-melt, fairy godmothers that some people seem to believe are at the helm at EMBT would always have the option of providing such updates as ex gratia on an ad-hoc basis if they wish, they simply wouldn't be obliged to. *But nothing in the current SA obliges them to either*. On 13 April 2015 at 17:45, Jeremy North <[email protected]> wrote: > So you want them to quantify an unknown. > > Good luck with that. Perhaps it's just the areas of the industry you touch > that's in trouble. > > > > Sent from my iPhone > > On 13 Apr 2015, at 3:20 pm, Jolyon Smith <[email protected]> wrote: > > If this is what get's dismissed as pedantry these days then the industry > is in deeper trouble than I imagined. It used to be called "paying > attention to important details" and "sounding notes of caution where > warranted". > > An Entitlement is not the same as an Obligation or even an Expectation, > and ignoring the distinction is a recipe for disaster in any contract > negotiation (which is what a license and support agreement is, lest we > forget). > > On 13 April 2015 at 16:26, Jeremy North <[email protected]> wrote: > >> pedantic much? >> >> On Mon, Apr 13, 2015 at 1:52 PM, Jolyon Smith <[email protected]> >> wrote: >> >>> Updates and hot fixes for up to two (2) years and three (3) major >>>>> releases >>>> >>>> >>>> This is meaningless unless there is also a money-where-your-mouth-is >>>> commitment to *provide* updates and hotfixes for versions other than >>>> the current one. >>>> >>> >>> > This is actually what it says doesn't it. >>> >>> Not really. It says that SA entitles you to *receive* updates and >>> hot-fixes. It says nothing about any commitment to *provide* any such >>> updates or hot-fixes. Of course, there is no way to predict just how bad a >>> release is in order to determine how many updates or hotfixes would be >>> required. >>> >>> >>> On 13 April 2015 at 15:24, Jeremy North <[email protected]> wrote: >>> >>>> >>>> On Mon, Apr 13, 2015 at 12:56 PM, Jolyon Smith <[email protected]> >>>> wrote: >>>> >>>>> Native mobile controls OSX iOS Android for many controls (eg DateTime >>>>>> picker) >>>>> >>>>> >>>>> In one review I read it was noted that this is a NO-OP on everything >>>>> except iOS. On all other platforms you still get the doppelganger >>>>> FireMonkey controls, even if you have configured for "native". >>>>> >>>>> >>>> The native controls are basically for iOS as mentioned - not all have >>>> native support. >>>> >>>> The "doppelganger" fmx controls are good if you are creating a bespoke >>>> look and feel for your corporate brand across all supported platforms. >>>> >>>> >>>>> >>>>> Updates and hot fixes for up to two (2) years and three (3) major >>>>>> releases >>>>> >>>>> >>>>> This is meaningless unless there is also a money-where-your-mouth-is >>>>> commitment to *provide* updates and hotfixes for versions other than >>>>> the current one. >>>>> >>>> >>>> This is actually what it says doesn't it. The intention is apply fixes >>>> to previous versions. I understand it won't be all fixes as some will not >>>> be possible without breaking interface compatibility. >>>> >>>> If it is done as they say, it will be a welcome change but then again, >>>> how can we trust a company that can't even keep their newsgroups >>>> operational consistently and have drones looking at submitted requests and >>>> closing them with nonsensical resolutions. >>>> >>>> >>>> >>>>> When was the last time EMBT released more than a token update or >>>>> hotfix for anything other than the current version ? Is their any >>>>> commitment to do better in this regards in the future ? >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> NZ Borland Developers Group - Delphi mailing list >>>> Post: [email protected] >>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>>> Unsubscribe: send an email to [email protected] >>>> with Subject: unsubscribe >>>> >>> >>> >>> _______________________________________________ >>> NZ Borland Developers Group - Delphi mailing list >>> Post: [email protected] >>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>> Unsubscribe: send an email to [email protected] with >>> Subject: unsubscribe >>> >> >> >> _______________________________________________ >> NZ Borland Developers Group - Delphi mailing list >> Post: [email protected] >> Admin: http://delphi.org.nz/mailman/listinfo/delphi >> Unsubscribe: send an email to [email protected] with >> Subject: unsubscribe >> > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: [email protected] > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [email protected] with > Subject: unsubscribe > > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: [email protected] > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [email protected] with > Subject: unsubscribe >
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
