topic Re: Preventing sharing of commercial GDL objects in GDL

Preventing sharing of commercial GDL objects

BenjiDev — Wed, 20 May 2026 16:09:51 GMT

An author of a GDL object might want to sell it while also preventing buyers from sharing it with others. How is it done?

A GDL object cannot make HTTP requests and, to my knowledge, does not have access to any crypto libraries.

I have some ideas, but there may exist simpler solutions already:

The GDL author creates a C++ Add-On and sets up a license server. The sole purpose of the Add-On is to communicate with the license server, since the GDL object itself cannot make HTTP requests.

The flow:

A GDL object is placed, and the Add-On gets notified through ACAPI_Notify_CatchNewElement.
The Add-On queries the license server using:
- a unique ID for the GDL object (essentially a product ID)
- the Graphisoft user ID
The server responds with a signed license (for example containing expiry date etc.). The important part is that the license is signed with the license server’s private key (for example using RSA).
The Add-On writes the license as a string parameter into the GDL object.
The GDL object verifies the license signature internally using the public key of the license server, validates the contents of the license, and disables itself (for example by not drawing any geometry) if the signature or contents are invalid.

Since a GDL object can be password protected, a user would not be able to simply remove the license check from the script itself. And you cannot easily edit the GDL code outside of ArchiCAD either.

The problem is step 4.

How would you realistically verify RSA signatures inside a GDL object? It does not seem very feasible to implement RSA verification manually in GDL.

The simpler alternative would be to let the C++ Add-On perform the license validation and then simply write an is_valid parameter into the GDL object. However, that seems insecure because someone could create a fake Add-On that just writes is_valid = true without checking any license.

Operating system used: Windows

Re: Preventing sharing of commercial GDL objects

Patrick M — Wed, 20 May 2026 21:57:00 GMT

TBH, I've never made enough $ from selling my objects to care much about who's sharing them. In fact, when a firm pays me to build a custom template, I often just load the embeded library with a bunch of the more useful objects.
I think you'd need to get into an add-on/plug-in that ties to a given GS license/GSID... similar to cadimage. Maybe buy a c/i seat and reverse engineer how they did it?

Re: Preventing sharing of commercial GDL objects

Lingwisyer — Thu, 21 May 2026 01:45:47 GMT

https://community.graphisoft.com/t5/GDL/Cloud-Licensing-and-GDL/m-p/589158#M6356

You can request the UserID & OrganisationID so you can just hardcode in a check value against one of those. I think Ben's library has a seperate licencing object which all of the others reference that contains this check as well as an expiry date.

Ling.

Re: Preventing sharing of commercial GDL objects

BenjiDev — Sat, 23 May 2026 16:54:00 GMT

Thanks for the link, that looks like a good and simple solution. If i understand it when a user makes a purchase you encode that user id into the GDL object? I wonder if it is possible to automate.

And if you want a recurring subscription model using only a GDL object the user would have to manually renew it after expiry date?

Re: Preventing sharing of commercial GDL objects

BenjiDev — Sat, 23 May 2026 17:03:10 GMT

Thanks for the tip, at least if you want automated recurring subscription model you probably need an Add-On to make web requests to a license server.

And I'm not 100% sure but I think GDL datetime uses the system clock which can be changed by the user. If that is the case then using it for expiry checking might not be suitable.

Re: Preventing sharing of commercial GDL objects

Piotr Dobrowolski — Wed, 10 Jun 2026 11:57:16 GMT

The drawback is that the OrganisationID which is better in such cases will load all organizations that the user is a guest, so there can be cases where the object will work for the "guest", and it is impossible to lock parameters with this request, as it was with old "req" command.

Re: Preventing sharing of commercial GDL objects

BenjiDev — Thu, 11 Jun 2026 08:02:13 GMT

Before you could make specific GDL add-ons in C++:

https://archicadapi.graphisoft.com/downloads/gdl-development-kit

So you could maybe have created a GDL add-on for license checking (using a C++ RSA library) with the public key of the license server embedded.

Perhaps you could even have created a GDL-addon that made web requests.

But looks like they don't work for AC versions above 23:

https://community.graphisoft.com/t5/Archicad-C-API/Why-there-is-no-forward-version-of-GDL-Development-Kit/td-p/687639

I cannot find much information about it.

And I'm not sure if it would be more secure/better compared to a normal C++ Add-On because the GDL Add-On could perhaps also be replaced.

Re: Preventing sharing of commercial GDL objects

runxel — Thu, 11 Jun 2026 09:46:11 GMT

The GDL add-ons are formally discontinued.

I wrote about how to make one a long time ago along with a template. But I'm pretty sure that will not compile anymore for newer versions.

I think that the "modern" way is the other way around: You make an add-on that injects data into an object, instead of having the object requesting it. But for that type of convo @BerndSchwarzenbacher is better equipped in knowledge.

Re: Preventing sharing of commercial GDL objects

BenjiDev — Thu, 11 Jun 2026 12:42:23 GMT

Thanks for the links and context.

Alright, yes I know you can inject data through parameters. But it feels complicated for a license as there are no crypto functions in GDL. A "license checker" Add-On could do the license check and write "is_valid=true" to a parameter but that could be written by a fake Add-On too. This parameter could be hidden/obfuscated of course. But this requires an Add-On that exists purely to verify licenses...

Encoding the customers GSID into to GDL object maybe is the best solution, what Lingwisyer mentioned. Perhaps it could be automated with the converter tool https://gdl.graphisoft.com/tips-and-tricks/how-to-use-the-lp_xmlconverter-tool/ by keeping the GDL source as XML and inserting the customer GSID on the correct line, and converting it back to .gsm before sending it to the customer, no C++ Add-On needed. I have not tried it so I'm not sure the tool works like that though, especially if the GDL object is password protected.

Re: Preventing sharing of commercial GDL objects

runxel — Thu, 11 Jun 2026 14:07:47 GMT

Making a central macro that checks for the correct ID is exactly what I would do honestly. The only tricky part would be an automatic generation of that object. Otherwise your customer needs to wait for you to make it.

Re: Preventing sharing of commercial GDL objects

Lingwisyer — Fri, 12 Jun 2026 01:13:08 GMT

Do you manually create it @Ben Cohen , or do you have some automated way?

Re: Preventing sharing of commercial GDL objects

BerndSchwarzenbacher — Fri, 12 Jun 2026 11:52:39 GMT

I'd be careful with using a macro object for this. I think a "malicious" user could easily replace the macro with their own and just unlock all your objects.

Re: Preventing sharing of commercial GDL objects

runxel — Fri, 12 Jun 2026 12:39:21 GMT

I know, but what would be the alternative?

I clearly would not like the overhead to have every object doing it's own validation.

Actually, thinking about this a bit longer: An additional secret that's returned as well and validated in the object might do the trick.

Re: Preventing sharing of commercial GDL objects

BerndSchwarzenbacher — Fri, 12 Jun 2026 18:16:18 GMT

Yeah it's very annoying to add that code part to every single object and basically have to recompile the whole library for each customer.

I also thought about additional secrets, but I always failed to actually make it work. Every way I can think about, it's always relatively easy to replace either the object or the macro and get to the secret this way.

Re: Preventing sharing of commercial GDL objects

Lingwisyer — Mon, 15 Jun 2026 02:16:30 GMT

Even if either gets duped, would not the actor would be required to know what is being requested in order to fish the secret?

Re: Preventing sharing of commercial GDL objects

runxel — Mon, 15 Jun 2026 08:13:04 GMT

@Lingwisyer schrieb:

Even if either gets duped, would not the actor would be required to know what is being requested in order to fish the secret?

I think so too. One would need to know the order and the contents of the returns. That's a bit far fetched imho.

Re: Preventing sharing of commercial GDL objects

Piotr Dobrowolski — Mon, 15 Jun 2026 09:34:03 GMT

Regarding licensing macro...it can be kind of safe if the "on/off" switch was not on the parameters list, but in "returned_parameters" - as it cannot be sniffed with schedule setup.

Re: Preventing sharing of commercial GDL objects

Davor P — Mon, 15 Jun 2026 13:42:46 GMT

Like Lucas suggests - macro works - I tested this quite a bit. You could solve it with a "worker" mac or PC that polls every x minutes. If an order comes through it can insert company ID to xml and convert to password protected gsm. Then upload somewhere where you serve download link to customer.
Also @BerndSchwarzenbacher - highly recommend for anything add-on related.