Hi @MonkeybreadSoftware and everyone else who has asked about the Claris FileMaker EULA change,
We shared this information with Claris Partners by email today. I'm also sharing it here so that the developers who are not in the partner program will see the clarification.
We want to clarify the EULA change to alleviate any confusion or concerns about this change.
Why did we make the change?
The purpose of the change was to address a potential loophole in the terms that would allow licensees to utilize FileMaker Data API calls in a manner to circumvent the need for user licenses.
What does the change mean?
Specifically, you cannot use the XML functionality in FileMaker Pro to rebuild a runtime client in a native language and then use the FileMaker Data API license to sync to between the runtime client and FileMaker Server for the purpose of avoiding user licenses.
This change does not mean that visitors of membership websites would be required to have a user license, nor would it include shopping carts where a user is generating a new record, or web form users. The change would specifically prohibit enabling the FileMaker Data API for the purpose of avoiding user license fees.
We hope this helps clarify the updates to the End User License Agreement.
Best,
Rosemary Tietge
Community Engagement Manager, Claris
I am afraid the information muddies things even more for me.
One of the things I learned from lawyers is that a judge ultimately decides the interpretation of a contract in cases of disagreement. What the EULA says and what Claris intends are two distinct things. Intent must be written in a contract for it to constrain a contractâs interpretation.
Furthermore, a user, in the Claris licensing terms, is a named person. One needs not purchase user licenses. One can purchase concurrent or site licenses. The concept of a user is non-existant in the latter two. A licensee can therefore legally circumvent the need for user licenses if it so wishes.
So⊠when are users of a non-FileMaker client considered a user or not, from Clarisâs licensing point of view? I now have no clue. I am stuck telling my customers Clarisâs contract language may be too risky to use the Data API for data entry or consumption. That said⊠I am not a lawyer. I tell them to seek one's opinion⊠and that often scares them away from such solutions.
I appreciate Claris's sentiment to publicly clarify its intent. The clarification is unfortunately of little legal use and seems to add a new definition of users in addition to the one I understood. Would Claris separate the two definitions and update the EULA accordingly?
Anyone who uses software that is similar to a runtime and communicates with FileMaker Server via the Data API needs a User License or Concurrent Connection?
Websites that interact with FileMaker Server are not affected?
For that Claris would have to sue you. Unlikely in my opinion.
This sounds like it is specifically targeting anyone developing a clone for FileMaker Pro/Go for Android, iOS, MacOS or Windows, which replaces an user license. Sounds exactly what the LiveCode people are up to.
@bdbd's view is sustained by the EULA itself, which stipulates in paragraph 8:
"... .This License constitutes the entire agreement between the parties with respect to the Software licensed under these terms, and it supersedes all prior or contemporaneous agreement, arrangement and understanding regarding such subject matter. You acknowledge and agree that you have not relied on any representations made by Claris, however, nothing in this License shall limit or exclude liability for any representation made fraudulently. No amendment to or modification of this License will be binding unless in writing and signed by Claris. If any provision of this License shall be held by a court of competent jurisdiction to be contrary to law, that provision will be enforced to the maximum extent permissible, and the remaining provisions of this License will remain in full force and effect. No failure or delay by Claris in exercising its rights or remedies shall operate as a waiver unless made by specific written notice. No single or partial exercise of any right or remedy of Claris shall operate as a waiver or preclude any other or further exercise of that or any other right or remedy. ..."
Eeek! This entire discussion and chronic lack of clarity with constantly changing EULA terms further makes me wary of recommending FMS to clients as a solution. I'm almost afraid of using my own FMS expecting some nasty call or worse from FMI.
Though really not a fan, Microsoft, on the other hand, in all the years I've used their products, does NONE OF these legal shenanigans. Quite the contrary, MS welcomes and reveres developers. As just one example, look at what you get on Office 365 for a mere $150/year for a business subscription. That list of stuff you get GROWS not shrinks. (You also get free support now.)
Follow. The. Money. Narrowing choices for expensive options has a seemingly simple goal. ($$$)
I love FileMaker but this uncertainty and constantly changing EULA are getting really old.
In the update that Claris provided (the one which Rosemary shared above), there was an additional mention that the restriction only applies if you are leveraging the XML functionality in FMP.
I would take this to mean that the intent is to allow developers to build their own runtimes which communicate back to FMS via DAPI provided that such XML functionality was not leveraged to do so.
Being an old man, I was initially thrown by the term "XML functionality", as I took that to mean the XML API, but I think it much more likely this refers to the more recent features regarding Add Ons and the patch tool, or even the DDR or the new and upcoming replacement for the vintage DDR.
In other words, I would take the intent of the additional update posted above to mean:
If one takes XML output that documents a FMP solution file, and uses that output build a non-FMP client that communicates to FMS via DAPI, then this falls into the scope of the initial EULA change called out at the start of this thread, i.e. this will require the purchase of additional licenses.
On the other hand: If, without any use of a DDR or the v.2 XML, one creates a client application that connects to FMS via the DAPI, such a project/endeavor is excepted from the change to the EULA called out in this thread, and it would not require additional licenses.
Now, of course, I don't know if the above is accurate, or if it is what Claris intended -- obviously, I don't have that kind of authoritative stance on the matter. It is just one more interpretation that highlights the point about using the XML.
Thanks, Rosemary. So, when will we see any clarification in the EULA, so we can assuage the fears of our clients, existing and potential? As much as we appreciate you all you do for us, I fear "Rosemary said so," will likely not cut it with our clients.
I'm checking on this for you; give me a week or so to get an answer.
In the meantime, the message I shared above is the same one that we shared in the Partner Community -- so it's not just "Rosemary said so." It is a broader "Claris has publicly said this."
Information given in your partner community is behind a paywall, accessible to only a small fraction of all entities/people for whom the EULA is the sole legally binding agreement, with no exceptions, until written and signed by Claris (the EULA says so).
I am not sure if the label 'publicly available information' applies to paywalled information and if statements issued as posts to communities qualify for the EULA's '...in writing and signed by Claris' legal requirement.