PMDG Boeing 777 was recently released for FSX and there have been many questions about whether 777 works in Prepar3D or not. Unfortunately, it doesn’t. 777 displays a message saying that it was not designed for Prepar3D, and does not load in the simulator.
To understand the underlying issue, we have to take a wider view on the subject.
Most software comes with End-User License Agreement (or EULA) saying that the software was “licensed, not sold” to you. The software, even after you’ve bought it, is not yours, but still belongs to the company who sold it, and they are just letting you to use the software. Such arrangements are called “licensing”, and in theory they allow to set any restrictions to the use of the software. At least that’s what the software companies want you to believe.
To be bound by any EULA, you must have had received a license to the software, not bought it.
Prepar3D’s developer’s license is an example of a pretty clear case of software licensing. For the price of 9,95 USD per month, the end user can install up to two copies of Prepar3D, which will cease working as soon as the user cancels the subscription. But if you make a one-time payment to buy a scenery and get to use it forever, things get muddy. Was it a license or a sale?
Let’s make it easier to follow:
- If you rent a house and make regular payments, then you are clearly renting the place.
- If you made a one-time payment and can use the house forever, you own it.
And now the trick question: if the previous owner gives you access to the house for indefinite period of time for a one-time payment and calls it “renting” (or a “license”), do you own the house or not? What determines the type of transaction – how it is formally called, or its essence?
In the US, decisions have so far been limited to particular provisions and terms and no court has ruled on the validity of EULAs in general. In some cases, clickwrap contracts (“Click here to agree”) have been found invalid as contracts of adhesion. In other cases, they have been found valid.
One of the most notable cases of an EULA restriction being invalid was McAfee’s attempt to stop users from spreading information on how well or how poorly their software performed. Their EULA contained the following restriction: “The customer shall not disclose the results of any benchmark test to any third party without Network Associates’ prior written approval.” After a magazine published a review of McAfee’s products and included information about their performance, McAfee tried to muzzle the magazine, crying EULA violation. To make long story short, New York General Attorney stepped in and McAfee got punished instead.
One simply can’t write whatever he/she wants into an EULA, and then go around telling that everyone has to follow it. I can easily write into Migration Tool’s EULA (if it had one) that Migration Tool’s users are allowed to vote only for Ron Paul. Do you believe I would ever find a court that would actually enforce it? Would those who try to be holier than the Pope on different forums call for following that restriction, too?
In my native Estonia, home of Skype, laws about contracts are stricter than in the US. EULAs are invalid if they are not displayed before the purchase, which makes perfect sense. How could I have agreed to a contract before I even saw it? Mind you, PMDG 777 EULA can be seen only after you’ve bought it. This means that whatever restrictions its EULA sets, they do not apply to me.
In short, EULAs – if they are enforceable at all – are so only within reason, and that reason is usually already defined in copyright law – that you can’t make copies for other people to use, that you can’t make copies and start selling them yourself, etc.
To bring an example of a EULA term that is most certainly void, PMDG NGX EULA does not allow addons to be resold. That restriction is void in the European Union, in a market the size of 500 million people.
Last but not least, let’s not forget that Flight Simulator X EULA does not allow the simulator to be reverse-engineered. Had PMDG developers followed FSX EULA, the 777 would never have been born. As such, the calls to religiously follow every single 777 EULA term and condition can rightfully called a hypocrisy.
As far as developers are concerned, there are two paths that can be taken:
- If a developer does not wish or is unable to support Prepar3D, they can take the passive path – that they don’t build their addon with Prepar3D compatibility in mind, that they don’t support their products’ use on Prepar3D, etc. This means that if you want to run the addon in Prepar3D, you’re on your own.
- Alternatively, a developer can take the active path – by deliberately making their product not function in Prepar3D. Ground Environment X and iFly 737 are two notable examples of such software.
With Migration Tool, addons that for one reason or another simply fail (for example, if they are unable to locate fsx.cfg which was been renamed to Prepar3D.cfg in Prepar3D) to function with Prepar3D are and will be supported. This includes addons that were designed for FSX and whose developers either have no interest in or resources for developing for Prepar3D, or whose developers are defunct and are not updating their products anymore.
A2A B-17 is a great example of an aircraft that was designed for FSX, and sold for FSX only, but has no EULA attached and can, with Migration Tool, very easily be installed into Prepar3D. B-17 installer looks for a text file that was moved from the location it was in FSX, and the installer fails if it doesn’t find it. Migration Tool restores that file, and B-17 can happily be flow in Prepar3D.
Addons that have deliberate locks to prevent them from being used on Prepar3D are not supported. There is simply no point in finding a way around an obstacle if the developers can place another obstacle in another place with the next update. Everyone’s time is much better spent on fixing addons that are genuinely broken, and where all parties wish (or at least don’t stop others from doing it) to fix it for Prepar3D. With the help of the community and several addon developers (hi, Umberto of FSDT!), we’ve managed to port over a lot of excellent addons to Prepar3D.
If you happen to like an FSX addon that has been deliberately locked to FSX, and you wish to use it with Prepar3D, make your wish known to the original developer, whoever it may be. I wish you best of luck in this pursuit and I hope that you will succeed.
I also hope that Lockheed Martin will renegotiate their deals with Microsoft to officially allow Prepar3D be used for entertainment (there’s no point in the restriction now that Flight has flopped) so that there would be no excuse for building artificial barriers between these two simulators. That would be nothing more than an acknowledgement of the situation we are already in – let’s be honest, we all know that Prepar3D is massively used for entertainment purposes.
To claim otherwise is nothing short of hypocrisy.