Heads-Up: License change for FMS for Data API!

From section 1d in license agreement for 19.3 FMS:

You cannot use the Data API as a client replacement. By way of example, if you intend to serve 10 users, you must purchase a 10 user license or concurrent connections license.

Be aware of this!


I wonder how to understand this. One needs to buy at least 5 licences and that entitles him to 10 G of Data API per year. Data API is not really a replacement for say, FMP, because that would mean having a second 'client app' to use the same solution. What you save in terms of licenses would be spent to create that other app.

Any way Claris should define what they mean by 'Client replacement'. I will have a look at the license.

Thanks for the head-up, this is very important.

1 Like

This is straight out of SAP's playbook:


Anything that consumes data is a client by definition. Does that mean I now need a license for each consumer or connection to the data API? If so, then something is wonky here.

FileMaker once said that a client needs not be bandwidth limited because the license has been paid for. I understood the 10 Gb limit for the data API was a licensing perk to account for the fact users of the data API did not pay for a license. You can even pay for additional bandwidth. FileMaker is now telling us all Data API users or connections need to have their own licenses? And those users are still limited to a 10 Gb yearly cap per license?

Did I understand this right?

1 Like

From the article:

A judge ruled that SAP's named-user licensing fees must cover any and all software that connects – even indirectly – to data held in a customer's SAP systems.

Named-user licensing, looks like FMI/Claris didn't come with something new !

And the amount due to SAP by his customer in the judgment is really high :weary:.

1 Like

After re-reading the terms it is my understanding that this seems to be the case.

This is a really difficult clause.

I've built many things in FileMaker that used the web technologies to reach a large audience.

Membership systems: The staff seat count was small but the web site reached out to membership bases of hundreds. In some cases, these were read only outputs. In other cases members would manage their own information. That use really seems to fit the definition of a client.

Shopping Carts: Shopping carts require a user account, and the user generates new records, edits them, and supervises them. This is a client, surely?

Inputs from Web Forms Creating records from user inputs. That is a client isn't it?

Interesting, the case of a Webshop: a 3-people team that runs the shop and about 1000 customers with customer accounts and shopping carts, using FMS as a data backend.

No one should take that lightly. One big ERP vendor took number of their customers to court for license infringement related to 'indirect access'.

Has anyone seen official information from the vendor regarding that very important change, other than the EULA shipping with the product?

Rick Kalman is advising:

The only intent is to prevent native client replacements that run on device, similar to Pro or Go, that use DAPI to communicate with FileMaker Server. No other uses are prohibited.


The only document relevant in court, the one that is legally enforceable, is the EULA.
What is written there does exist, legally. Anything else does not exist, legally, and is opinion.
Rick Kalman's statement does not coincide with the content of the EULA.
If Rick Kalman's statement reflects the true intention of the vendor, the EULA's sloppiness is very disappointing.


looks like Claris is telling us not to use the LiveCode promoted runtime replacements without paying for the usage...


That wide opens the EULA to interpretation. Does that mean that to access to data located in a file served by FMS can only be accesses through Claris Software if the device runs Windows, MacOS or iOS/iPadOS ? Using DAPI would be fine if a solution runs on Linux for example ? Looks like CWP is now dead.

I wonder where we are heading with that.

Maybe it's more a thing what the main purpose of your Mac app is.
FM Pro replacement or more like an app doing something else with a FM integration?

I'm reading it like this:
Can you can use Go or Pro to do that job?
Why aren't you using Go or Pro to do that job?

Modern web frameworks make it fairly easy to develop frontends and DAPI is an excellent connector. Because the barrier to implementation is now so low there is a temptation to implement more and more functionality into a DAPI solution.


In a land where Go/SDK provided a modern iOS experience, this would be true. But there are significant blind spots in the feature set that can only be overcome by building your own iOS app + DAPI. For devs who need to deliver those features, the extra development outweighs the cost.

Some businesses are able to get by with Go/SDK apps, others can't.

Re: the desktop client (Pro), there are fewer blind spots in the feature set. So I agree the case for re-creating a desktop app doesn't hold up quite as well.

1 Like

It is unfortunate that the vendor tries to ‘motivate’ customers using FM-branded client applications through legal constraints rather than an appealing product.

There are many areas in the filemaker developer UI that have not seen an update in years, despite developer requests. Also what can be offered to users on the UI side falls short now (i.e. dynamic scriptable sorting in portals, sliding portals, drag & drop functionality).
Last year I worked in a project where a SQL Server-based application was developed with MS tools. They have it all!

We can get these things only outside FM. JS in a webviewer is only a patch with limited applicability. And in my opinion, doing all this in webviewer runs against the FM philosophy, is no longer RAD.


Rick Kalman promotes FM 19.3 as more ‘open, and extensible than ever’, with virtually ‘no limits’:


Unfortunately, the new legal constraints imposed by the EULA of v 19.3 are not explained or even mentioned in the article cited above. A remarkable omission.


Licensing has been FileMaker/Claris’s Achilles heal for as long as I can remember (30 plus years) and, we believe, has severely limited its adoption.

Although FM Pro and Go have been mentioned, there are projects, one of which we are half-way through, where FM Go is communicating purely using the Data API, as the traditional method of connection between Pro/Go and Server is not appropriate. Continual changes to licensing makes long term planning almost impossible and we will need to report the impact of this to our client. The change will not go down well and further diminishes our and Claris‘ s reputation.

However, there remains the, very expensive, option of concurrent licensing and presumably additional Gb for the Data API. We will see if this remains competitive against the competition, but I fear it will trigger more developers leaving the FileMaker ‘platform’.

Equally, if it is Claris’s goal to chase away commercial developers and focus purely on in-house developers, then this could be a conscious decision.


Interesting. I'm also discussing this as an option for a client because it gets around connectivity issues. I don't think there are licensing issues in my case because the client will be using only three seats in a five seat license pack and the Go client would be one of them.

Malcolm, ours is a care in the community project. Could result in a lot of clients making about 4 to 5 connections to the server a day.

We need to better understand this new twist before contacting our customer. However, they have already expressed an interest in taking this to market within their sector, which could be brilliant for a Filemaker project. Once again licensing could put this in jeopardy.