I don’t enjoy posting this news. I really don’t. I had hoped that my next post would be a more positive report following the Auckland leg of the XE3 World Tour this morning (and that will come later today).
But I feel this news is so important that it has to be mentioned, so here it is.
From XE3 onwards, your Delphi Professional EULA will prohibit you from using Delphi Professional for anything other than local data access.
If you want to build client/server database applications using Delphi Professional, you will be required to purchase a “Client/Server Add-On” pack.
This goes beyond the fact that you do not get (or can otherwise use or install) client/server drivers for the DBExpress or other “built in” data access frameworks, but extends even to 3rd party data access technologies.
That is, whatever you may be able to do or achieve – technically – using some 3rd party component or library with your Delphi Professional compiler, you cannot legally create a client/server application.
Never mind any 3rd party components or libraries, this same prohibition will apply even if you are using naked, unadorned Microsoft ADO.
Grandfathering
It is worth mentioning that this will apply to new licensees only. That is, if you have a current XE2 or XE license and upgrade to XE3 (or presumably are on SA), then your rights (or rather the lack of any restriction in this area) from those prior EULA’s in this area will roll forward.
But if you fall outside the eligible upgrade window or are otherwise a brand new user, then this new EULA restriction will apply to you. Then again, with this restriction in place I don’t think we need to worry about any new Delphi users, do we ? 🙁
Not that this “grandfathering” is any great generosity on the part of Embarcadero. More likely they would have loved to put the screws down on all of us [Pro licensees], but I presume they were prevented from trying to do so only on the advice of their legal department.
And obviously, if you are an ISV with current Delphi Professional licenses then those licenses can be upgraded to XE3 and continue to be used to create client/server applications. But if you acquire any further new licenses for new staff members (your Delphi team is growing, right?) then those new licenses will be prohibited from being used for client/server application development.
So if your existing application is already client/server, and you need additional Delphi licenses for new team members, then from now on you are forced to purchase Enterprise licenses or the Client/Server Add-On Pack.
Arguably they may have a hard time trying to enforce this and some people might suggest that we can just ignore it. But whether or not that is the case, as an insight into the mindset of the management (or whoever it is that is making these decisions) at Embarcadero, it is revealing and, more particularly, upsetting.
Are they trying to kill Delphi ?
Provenance
I stress, this is not speculation, rumour, scare-mongering or FUD.
I cannot and will not say how the post in that forum came to my attention. I certainly did not post it myself. But I can say that at first it was too outrageous and scandalous to believe. My initial reaction was disbelief that Embarcadero would try anything so foolish or mean spirited. So I checked and double-checked.
Had there been even the slightest question of doubt as to it’s authenticity I would not have mentioned it.
Of course, if Embarcadero want to retract this change and perhaps even deny it was ever going to happen, then I for one will be over the moon.
Now, I have to pack some bags and go door knocking on the local foreign diplomatic missions …. 😉
@Deltics: Thank you for your effort and courage, to be a critical friend. It’s greate to see there is at least someone out there, who keeps us (Delphi developer) informed what’s going on with Delphi and EMB (behind the curtain). I am fed up with all the “american” style of marketing, which tend to spend more money in marketing as in the product itself.
# eat like a bird and poop like an elephant, says everything to me!
All your information is very valuable, in order to make proper decissions for the future.
I cannot take the credit for any courage – I am not covered by any NDA.
Any courage should be credited to the person, or persons, that saw to it that this came to my attention. I simply then brought it to wider notice as I felt appropriate. And only reluctantly, as I say, because it give me no joy to see Delphi being handled in this fashion, let alone wished to perpetuate the notion that I am only ever looking to criticise.
I criticise when I feel criticism is due. It is not my fault that that has been more often than not lately. 🙁
Messengers have historically often been shot for bringing bad news. The trend has not abated.
I’m under the impression that David I is another messenger that is taking and will take a whole lot of shots.
I think the real David is retired. He has been replaced by a robot, or an emb employee (probably a robot too) who speaks on its behalf.
@Deltics, you are 100% correct
I had to add.
I just realized.
Virtually any network connection is off limits to XE3 pro.
Almost every network access today goes via TCP protocols.
Almost every network access today goes via Domain names rather than bare IP digits.
What is DNS ? Remote server.
What does DNS use ? back-end database. http://cr.yp.to/djbdns/other.html
Even the most no-SQL DNS server would use some kind of database – like http://cr.yp.to/cdb.html
How to allow Delpho Pro program to connect to network resources then ?
Way 1: statically put all domains needed to \Windows\system32\drivers\etc\hosts file
Way 2: install local DNS server, warm it up, and then prohibit from updating from outside word.
Both ways are… ahem… impractical.
DNS queries are prohibited for Delphi Pro now.
95% of network access is now off limits.
Let’s congratulate new no-connection multiverse!
“Are they trying to kill Delphi ?”
They are not trying, alas !
Do, or do not. There is no try.
It appears to be the same as if you simply placed a bullet directly in the brain. If it costs $2500 to hook to a database server, while I can use a TCL proc, and 50 lines of code to hook to MySQL, why am I as a developer going to look back.
Stupid does not begin to describe it, and as I notice that David I has weighed in on this forum in the past, the sound of crickets are deafening.
I have always had in my mind that I really need to focus on the issues with using Lazarus/FPC for thick client development. It was always a back burner issue. Now: Simmer -> Boil.
It should read: “in some – rather stupid – countries”.
These kind/type of EULA’s are in contradiction with European Community laws if the software allows you to write client/server applications (albeit with 3th party add-on’s) .
That is called intentional crippling, which is: forbidden….
It is also not in line with EEC laws regarding competition….
They probably know that….
HELLO Code Typhon! (and continue with Delphi7/XE which we have.)
Goodbye XE 2,3, etc.
Its would imo only be fair, to mention that the mentioned EULA has been replaced with an EULA that do not have that restriction in it.
Its basically the older XE2 EULA that is being reinstated for XE3 afaik.
best regards
Kim Madsen
C4D
https://forums.embarcadero.com/thread.jspa?threadID=76285&tstart=0
We now have a final license agreement. There should be nothing in the final
EULA – when it is truly finalized in the RTM version – that should cause any
problems for partners or our customers. The license (EULA) is basically
similar to the XE2 file. The EULA (which is included with every shipping product)
will become “final” when the we sign off the release to manufacturing build. We
have included portions of the final EULA below. Note that any Professional
edition restrictions still included are only related only to the use of “dbExpress”
technology and do not restrict the use of technolgy partner or other 3rd party
client/server or multi-tier technologies by Professional edition customers.
Those are sweet news.
But the fact is that now before every upgrade we should have a habit of searching bombs in EULA.
Developer should be so careful with Delphi like mine with the minefield.
New users may miss this, but old users would never be able to forget.
They may have backed down but who would trust Embarcadero now?
>They may have backed down but who would trust Embarcadero now?
IF EMBT put reverse will show us really listen to customers and repair mistakes.
Hey Jolyon, feel free to report that the new rule in the EULA you write about is not the actual XE3 EULA, so were just leaking FUD (again)…
Bob, it is disappointing, but no surprise, that the army of “Yes Men”, in the form of MVP’s are now being pressed into service to help Embarcadero spin this. Every Technology Partner knows that the new EULA was a done deal. The initial response from Embarcadero was not to say “don’t worry, this hasn’t been finalised” but rather “this doesn’t affect existing customers”.
Keep telling the lie often enough and you might end up believing it yourself, but you can’t change the facts. Sorry.
Agreed. Sorry Bob, but that position is just not tenable. If David I had stayed absolutely silent during the firestorm then you might just get away with calling this leaked FUD, except he didn’t. Add to that the later reported communication from resellers stating that the change had been reverted and you won’t convince anyone that has been following this that is was a non issue to start with.
It is good news that the change has been reverted and we should at least recognize that Embarcadero have listened. It still leaves a bad taste in the mouth knowing that this change looked like it was going to appear without any fanfare or notice. Without the leak, you might argue that they would have highlighted the change on the world tour of XE3, but I don’t subscribe to that belief myself.
Wow what a way to complete destroy your credibility: personally attacking someone making a reference to egregious EULA terms. I would have rather wished that this was the case, as it would have finally given me enough ammunition to convince my boss to move off of Delphi. Will have to wait. I’m almost there since I can show him that the yearly “tax” is only for bug fixes.
Even the consideration is scary. It makes sense that somebody that knew how stupid it was, dropped the dime to prevent the nuclear explosion.
My bet is that David I was fit to be tied.
It is amazing that EMB is having such a hard time figuring out it’s developers, and realizing that they are on the upper end of the price curve. Given the brain drain over there, the most reasonable explanation is that Management isn’t listening.
I LIKE Delphi. I would really love it if they were to go all Zombie over there and start hunting some brains. Turn over the business to someone who understands developers, and drive the truck out of the hole.
The tool has been beaten against a tree time and time again by pointy headed types that refuse to allow the Slide Rules to tie on the rope to pull it out and do the proper tune up. There are many good directions being taken with the investment, but the business side appears clueless. Many developers have jumped ship already, so they need to take a drastic step sooner rather than later.
How many times over the life of this product have we heard this same song?
I was in error considering that this was a leak. I was mis-informed.
Still, I would like to root for Delphi to rise from the ashes…
but they continue to deepen….
that was a leak. But a later confirmed one.