In the last 10 years, I've sold software to over 500 "mid-market" customers.
Only 8 of those customers read the software license agreement that I provided to them. Which is fine--I don't read them either.
But 8 of my customers did actually read the license agreement--all were large corporations. Presumably they reviewed the license agreement because it is their corporate policy, and likely because they actually have a "legal department" or some legal resource that handles the task of reviewing software licenses. Fun job, for sure.
 |
| We've all ignored it |
If you've ever had a lawyer read a legal document drafted by someone else, you know that they will always come back with requested changes. Always. Whenever I hear "legal department", I know what happens next.
Of the 8 customers who had their lawyer read my license agreement, all 8 requested changes to the agreement.
The most common request was to change the "location" or "venue" for the software license terms. For example, a customer may want the laws of New York to apply, because their headquarters or their lawyer is in New York. Or they want to change the terms of arbitration to use the Commercial Arbitration organization of their country, or have arbitration or legal proceedings occur in their state.
Surprisingly, perhaps because most of my customers are in the US, and because my license agreement does not mention "privacy" at all, I haven't yet had a single customer inquire about or require specific terms related to "privacy" or data protection. But between GDPR, European privacy laws, the South African Data Protection Act, and California's eager sprint to enact a half-baked privacy law, this is invariably going to be an issue that more customers raise.
But let's back up a bit.
Why am I even writing about software EULAs? (End User License Agreement)
Because when you create an app for Business Central, you need to include a link to your software License Agreement. And you also have to provide a link to your Privacy Policy. You do have a Privacy Policy, don't you?
 |
| The fine print for every Business Central app |
And although 99% of customers will never look at either the License Agreement or Privacy Policy, perhaps 1% of customers will. And it will be the customer's lawyer who reviews those documents. And that lawyer will, of course, request changes. Always.
So, from my layman perspective, we have two different challenges.
1. Customers: Most won't read the License Agreement or Privacy Policy but will purchase Business Central apps without any understanding of the legal details. Over 99% of the time, that is fine--no dispute will arise, and no data privacy issues will occur. But if a customer in the UK installs an app that does something with data that is technically not compliant with one lawyer's interpretation of GDPR, and some issue does occur, what then? Is that the customer's fault? Or is the developer liable because they allowed the UK customer to use the software? Or for the 1% of customers with lawyers who do read the documents, and invariably request changes, will the developer entertain such requests? How will the developer agree to requests for 20 changes from 20 countries? Lawyers $$$$?
2. Developers: No developer will pay a team of lawyers to create a massive License Agreement and Privacy Policy that will conform to the thousands of legal venues and dozens of privacy laws that exist throughout the world. Developers will prepare legal documents that work for them in the context of their legal venue. And customers in other countries either accept those terms, or...what? If a customer uses your software in a country that has laws that aren't covered in your EULA or Privacy Policy, could you be exposed in that country, despite clauses attempting to limit such exposure?
When you publish an app to AppSource, you can select which countries are supported.
 |
| Choose wisely |
In the context of this discussion, does this list of countries seem realistic?
Can any EULA and Privacy Policy possibly accommodate or navigate the laws of these 17 countries? How many lawyers would that require? So let's take a guess that the developer isn't actually able to simultaneously comply with laws of all of those countries. Are they exposing themselves to legal issues in some of those countries?
Conversely, if a license agreement is not tailored to the customer's country, what should the customer do?
In the example app shown above, the developer privacy policy mentions GDPR and an Italian privacy law. But I live in California, which has its very own CCPA data privacy manifesto. Need I call my lawyer who will then demand that the developer comply with CCPA so that I can use this app? I'll let you guess what the developer will tell me.
Or, if I use an app that is not CCPA "compliant", do I expose myself to liability if I store data for California consumers? Will my use of the app as a California consumer cause the developer to be liable under CCPA if they didn't block me from using it?
Can we see the absurdity of attempting to comply with every legal jurisdiction and every privacy law on the planet?
Given this challenge, how do we deal with EULAs and Privacy Policies in the age of SaaS software that can be accessed from anywhere in the world with a single click?
For developers, I assume the easiest option will be to only include the few countries that your EULA and Privacy Policy can cover. For most US developers, that will likely mean only offering apps to US customers. Which could mean preventing customers from other countries from using the app. And coming soon: Preventing access to the app by US state, as some developers may not want to deal with individual state privacy laws.
For developers, it won't be worth the hassle of dealing with that one additional country for the handful of potential customers. For customers, I suspect it will mean they simply won't have access to many apps.
How should developers and customers deal with this?
Steve Endow is a Microsoft MVP in Los Angeles. He works with Dynamics 365 Business Central, Power Automate, Power Apps, Azure, Dynamics GP, SQL Server, and .NET
No comments:
Post a Comment
All comments must be reviewed and approved before being published. Your comment will not appear immediately.