Looks like they’re keeping Classic around for a bit longer, but you have to move to their new licensing by the end of the year.
Yes, this is a very good thing and actually a major retreat.
No need to be worried about existing licenses, I am sure all remaining license holders will be approached “during 2027” as it says. And surely LC Ltd will always sell you a new one whenever commercial closed-source work is on the table (or mobile platforms have to be addressed, as it is).
We might mull a bit here on what the implications for HyperXTalk are in this. Until now HXT had a twin/step/whatever sister that was set to die and had not to be regarded therefore. Now it will live on (for at least till the next strategic backflip). I see one question from this, should we actively work for best compatibility between LC and HXT in language and (modern) features or should HXT just follow its own path and priorities and not pay attention?
That’s a good question. For the most part we’ve added features to the file format that aren’t compatible with LiveCode, but I don’t think they’ve added anything so it should be okay to open a LiveCode stack in HyperXTalk. But seeing as they’ve completely closed off any downloads of their software, it’s impossible for me to test or to keep abreast of their changes.
It has to be resolved by year-end. We already received an email about it, including encouraging us to migrate and negotiate new terms by year-end. As usual, LC tries to make it sound enticing to sign up now, because your remaining term will be added on (pay now…).
Unless the licensing model is wildly adjusted (without the steepest price cut ever, there is no way we’re paying per seat for our mobile apps), we’re a hard “no”. Thus all my encouragement for a mobile solution that is compatible with hxt, even one that is separate and therefore not GPL. Flutter, Swift, Kotlin, RN are fine. They don’t make me happy.
Of course LC tries to paint it as a support, etc. issue, but we almost never reach out to support, and when we do, it’s almost always because of some bug or feature request that never gets resolved anyway.
Ok, so Emily was right with “end of the year”. Sorry, my post was a bit across-the-board with only specific use cases and aspects in mind. The announced new licensing structure itself of course remains a shame and will be untenable for publishers like you.
Neither can you sit it out much into 2027, nor is it painless to switch to the other tools (as you partly already did), nor can we expect a short-term solution for mobile xTalk apps given the stalemate in our GPL debate. If there is hope that new engine code eventually might provide a lifeline we would need to invest energy in a discussion how to obtain it at some point.
I’ve been following the discussion carefully. For clarity on my position:
I am currently using LiveCode strictly for maintaining legacy projects. All my new development work is already done in PureBasic, Xojo, and Ring Lang because the current licensing model is not viable for me.
Here is my stance on the new terms:
I am willing to return to LiveCode for commercial development ONLY if the “5% royalty” on revenue is removed.
If LiveCode insists on taking 5% of my app revenue, I will not sign the new commercial license. In that case, I will continue to develop exclusively in my current stack (PureBasic, Xojo, Ring) and only maintain old LiveCode stacks as needed.
The 5% revenue share is the dealbreaker. If that clause is removed, I might reconsider. If it remains, I am not bound to LC Ltd’s new terms, regardless of how enticing the other migration offers sound.
Don’t forget about the kill-switch feature too. That’s a deal breaker for me.
3 Likes
Is your business model compatible with sharing source?
Heather’s post suggests that things are not going so well with Create and while I could live with the annual fees I can’t accept the terms of the new licensing which don’t seem to have changed.
I also wonder who outside Xtalk circles has ever heard of LC Create? In comparison I keep seeing adverts for Base44 with Lena and her budgeting app.
S
Yes, I build applications for companies as a freelancer. If I have to pay a 5% revenue share and also pay for a seat, then LiveCode’s pricing plan isn’t a good fit for me.
If they’re asking for a revenue share, the tool itself should be free, and they should provide a Stripe API integration so LiveCode can automatically deduct its percentage from each payment.
In the current AI era, LiveCode’s syntax feels outdated. With vibe coding, you can simply describe what you want to an AI, and it produces remarkably good results. I subscribe to Claude and GitHub Copilot, and for me as a solo developer, that approach makes much more sense.
I’m envious. In my 30 years as a freelance consultant, I’ve had very few (two?) contracts where the project goals included open source.
If you’ve found a market that embraces sharing their source code to proliferate free variants of their product, I’d be very happy to work as a subcontractor with you should the need arise. It’s a great ethos (we arguably wouldn’t have an Internet without it), but rare.
Most open source projects I’ve used and volunteered with are strapped for funding. There are service-oriented business models where sharing the code still keeps the moat, but they’re rare compared to proprietary products.
tell us more about your setup. i’m using github copilot, but not claude code
Sure thing! Here’s my setup:
-
Editor & Tools: I use VS Code with GitHub Copilot enabled.
-
Local AI Integration: To help the AI understand my codebase better, I created a local offline API using LiveCode. This allows the AI to read my files locally. I built this API based on the structure from HyperXTalk.
-
Workflow for AI Agents:
- Since LiveCode doesn’t offer a CLI for building or checking syntax, I set up a simple workflow to debug the scripts generated by my AI agent.
- I ask the AI agent to write the specific scripts I need for my projects.
- Once the script is ready, I use the “Start using stack…” option to build a standalone application. Sometimes, I just insert the script directly without a full build.
This approach helps me stay flexible and efficient as a solo developer.