Many thanks for the clarification on the iOS situation. I did some research on this. The stance of the copyright holder is a very strict or tight one, it does not automatically transfer to everything we do here, and the real issues at stake would have to be expounded, but maybe in a new topic, as the current one is already stretched to its limits. Are you willing to join and dissect this special license question a bit? I would paint a picture that is not as grim, and maybe we find some interesting common ground then. It might be worth it as the App Store restrictions might be duplicated by other ecosystems sooner or later, and we need a general understanding of what is going on and how to deal with it.
LC never released a FOSS edition for iOS.
I donāt know that thereās much more to it than that, except maybe to just retitle this thread to be about Android only, since thatās the only mobile platform this project has source for.
Great, Iāll open a new topic as soon as I am back at my desk and find the time for it.
Maybe @mwieder can chime in as well then because the core aspect to regard would be where his iOS build would be able to run and how it would look like. A license discussion must be oriented at a practical scenario.
The Android build might be worth a new topic as well then, the core questions are a bit different there.
If he wrote it all he decides how it can be used.
If it includes any LC code, itās a nonstarter unless the copyright holder changed their mind. I wouldnāt hold my breath for that.
We should not hold our breath at all, it is not a healthy habit. 
1 Like
To put this part to rest, I took the easy way out for iOS. I left it up to the user. The scenario goes like this: if you have the iOS libraries legitimately from LC, you copy those libraries into the Runtime folder and build on them. That seems to me (IANAL) to be a legit use of the iOS libraries, falling into the same category as embedding the library into a standalone app you built with LC in the first place. If you donāt have the libraries in the first place youāre not going to be building for iOS. I donāt have much interest in iOS, or in mobile stuff at all for that matter, but adding them as standalone targets was a fun project. Android builds are much easier because itās mostly just a matter of hooking into the Android development app.
Was there ever a way to obtain those for redistribution under GPL v3 license?
Donāt know. I figure if theyāre being built into iOS standalones in LC then theyāre being distributed, no? Anyway, I just set up the mechanism for building the standalones with the proviso that you need to legitimately have the libraries because you own an LC version that includes them. Not interested in jumping through Appleās hoops myself.
This is highly unlikely. So here we have a showstopper of some importance, not so much in the GPL v3 license itself. Is this what you wanted to say all the time?
And thanks Mark for describing your plan!
Au contraire, that is very much the heart of the issue. This article describes the incompatibility between the GPL and Appleās app store restrictions:
The VLC case was referenced in early discussions shortly after LC announced the FOSS crowdfunding. That article does a better job than most in providing the background on this incompatibility.
A way forward would be for the copyright holder to relicense under different terms, as would be allowable via the exceptions mechanism in GPL v3, or by using an entirely different license.
But since that would require work from them with no upside for their current business model, that seems an unlikely outcome.
GPLv3 is a virally replicating licence, and in my view not really in the spirit is open source. You are not free to do what you want.
LC has had a tricky relationship with this licensing model, as Appleās app store is 100% incompatible with this. They basically had to make an exception to cheat the viral licensing.
Quite why they chose this rather than permissive OSS licenses such as MIT or Apache2-0 isnāt obvious to me.
The only way to change that now is to get all original licence holders to agree which seems unlikely as this would be in direct competition.
Or re-write from scratch (valid to copy all methods but implement with own code without copying any of the original code - that may actually not be far off what is happening now).
If all the code is demonstrably different from source, there may be scope to licence as permissive Open source so that App Store can be used.
According to chatGPT:
Even if you donāt copy code, avoid:
-
Unique structure or architecture that is clearly derived
-
Copying comments, naming schemes, or idiosyncratic logic flows
-
Reusing test cases verbatim (they can be copyrighted too)
What is safe to reuse
You can use:
-
Public protocols, file formats, APIs
-
Observed behaviour (black-box testing)
-
Mathematical algorithms (not copyrightable per se)
-
Your own independently written tests
1 Like
Forgive the unusual formatting, but Discourse doesnāt make inline comments easy.
Stam wrote:
GPLv3 is a virally replicating licence
The Free Software Foundation and many other open source advocates consider āviralā in this context a pejorative, since of course viruses are generally harmful and not something one freely chooses. The term as it relates to open source was popularized by the famous hostility of Steve Ballmer back when he also referred to Linux as āa cancerā (these days Windows Pro ships with Linux pre-installed, and Nadellaās MS widely supports open source).
More value-neutral might be to refer to copy-left licensesā inheritance of rights and responsibilities.
and in my view not really in the spirit is
open source. You are not free to do what you want.
Doing whatever one wants is not generally the goal of any software license, and certainly not the goal of Richard Stallman or the FSF. Public domain would be a good choice if an author has that goal.
The GPLās goal is that the source is always available to any user that wants it. To ensure this happens, the license applies to derivative works.
Other open source licenses that do not have the copy-left inheritance requirements allow for ecosystems in which one can take without having to give anything back (MIT is the most popular choice for those with that goal).
These three categories of source sharing each reflect different priorities. Personally I donāt regard any as ābetterā than another, and simply respect that different authors have different needs and goals.
LC has had a tricky relationship with this licensing model, as Appleās app store is 100% incompatible with this. They basically had to make an exception to cheat the viral licensing.
To be clear, they never made such an exception, which is why weāre having this discussion. They never released an iOS system under any open source license. All the way back to the initial crowdfunding, as far as I can recall this was never even intended.
Quite why they chose this rather than
permissive OSS licenses such as MIT or Apache2-0 isnāt obvious to me.
Their goal with license choice seems to be similar to other projects like MySQL that have used dual licensing: survival.
When a business model is based around licensing revenue, eliminating the need for anyone to ever pay for a license would undermine project viability.
Some orgs with models based on service revenue can do quite well, but most MIT-licensed projects are only an incidental part of a companyās operations, and tend to have a high percentage of developers in their audience who might contribute back to the code base.
With LC none of these were the case, so the most plausible path (tho obviously in hindsight not guaranteed) to sustainable open source was pursued through dual licensing, which also reflected the dual needs of their audience.
The only way to change that now is to get all original licence holders to agree which seems unlikely as this would be in direct competition.
On the one hand, their process required contributor license agreements for submissions, so it seems the company is the sole copyright holder.
But I agree, it would not be in their interest to go through the steps that would be needed to release an open source version of their iOS engine today.
Another option would be to write an engine from scratch, but I think weād all agree that would be prohibitively expensive.
So we are where we are, which isnāt a bad place: on mobile, the clumsy workarounds (scrolling fields, etc) or completely missing features (clipboard integration, etc) always held it back to the also-ran category among the vast range of alternatives that have sprung up in the mobile gold rush.
But on the desktop, this engine shines at least as brightly as the best multiplatform options that have ever seen the light of day.
If I had to choose only one supported form factor for this engine, Iād choose where it is in a heartbeat.
@ToolGuy itās a showstopper for me. i donāt know about someone else.
as @Stam pointed out, if the code gets rewritten, say, by claude, then a different license could be adopted.
we started rewriting our mobile apps in flutter, because the LCC fees are not acceptable. sure, we might come to some arrangement with lc, but trust is gone. itās time to move on.
if hxt gets to where i hope it gets to, then of course choose that route.
Great discussion, thanks! I am learning a lot. Instead of opening a new GPL topic, I might have to edit the title of this topic sooner or later as we seem to be in the middle of a GPL debate already. Maybe we are even through with it, and I need not edit.
Why this?
My conclusion is that it would be fruitless to poke license terms for LiveCode intellectual property.
-
No-one will step forward and ask LiveCode for a change in terms. After all these years? Please someone take the flag. Even if an attempt is made, the most probable result has been described by some posts here already.
-
And what would we get? The change would concern the iOS code as one incarnation of the mobile offering. This is a part of the codebase that also has been described here spot on. The mobile offering is not up to the standards of other tools to implement mobile apps (which is why not too many of them are written in LiveCode). It is not up to the standards of the xTalk folks who rightly expect their accustomed comfort on all platforms - and do not want chores of copying weird code patterns to simulate mobile-native UI gestures, and learning arcane codesigning and stapling rituals that go haywire every other week because of incessant environment updates.
-
Also no loving words for the desktop offering will bring back xTalk relevance. The gap is in the now relevant other market segment (mobile is roughly two thirds of usage, roughly four or five times in device sales, right?).
-
No GPL debate here will have any influence on the situation of Free Software and the App Store. This is political matter, and sadly insignificant in the grand play of things. I am throwing out three irksome (or entertaining but pointless) paragraphs on Richard Stallmann, Free Software and Apple now, and why all of them might be rightly called viruses.
The much more pressing question is what to do for the HiveCode community regarding mobile, and generally.
Yes, āletās take AI and create or recreate whatever we need!ā
The relevant problem with that is not so much expenses. Much of the prohibitive cost might have evaporated already. The Anthropic Safeguards team recently had a purely agentic set-up create a C Compiler in Rust which was then able to build Linux on different architectures. The 100k lines codebase cost 20k dollars in API tokens to create. You are all surely aware that the evolution we observe here is still just beginning and hardly mature, nobody can tell where the culmination point may be.
The relevant problem for a re/creation proposal is having the right plan. āGetting the right plan also is expensive, see!ā Well yes. I am not sure yet about meaningful proposals/next steps. More on this maybe later. Or we go for a bit for informal conferencing right away. Another five paragraphs skipped. 
1 Like
No loving words for any form factor will make the world forget that it moved from Pascal to C decades ago, and with that came the change in scripting flavor popularity.
If youāre looking for one language that runs anywhere, we no longer need to think about it; the choice was made for us years ago: JavaScript is the only language that runs in browsers. With Node on servers, and packagers like Electron for native deployment for desktop and mobile, where ubiquity is needed itās got you covered, and with the help of a vast ecosystem around it.
xTalks are an odd bird in the second quarter of the 21st century. Iām fine using them to do equally odd things. They remain a best-of-breed option for multiplatform desktop deployment.
Hardware sales matters for hardware stores. Phones get replaced more often; computers have a longer consumer lifecycle.
Usage is tricky to measure in meaningful ways. The easiest method is the most common: Internet usage. But more phone apps are fully dependent on server connections than desktop apps are.
Consider your own usage. Thatās what xTalkers do with their time.
I do almost nothing on my phone that doesnāt touch the Internet. Most of my phone time is in my browser, email, YouTube, and other connected apps.
On my desktops I run LibreOffice, Inkscape, Krita, Scribus, Blender, video and audio tools, music production tools, and of course a couple xTalks. Aside from occasional email and browser time, I could spend all day on my laptop without an Internet connection and never miss it.
If one were measuring my Internet time without knowing my actual usage time, they might get the impression I never use my computer at all, even if I spend more hours with it than I do with my phone.
Thereās a place for xTalks. But a good place need not be every place.
Hi Richard,
I think weāll have to agree to disagree on some of these pointsā¦ obviously open source conundrums will not be solved here, butā¦
But I still view this as viral as it self-replicates without being alive 
The GPLv3 mindset, which I know is prevalent in many places, is in my view at odds with the mantra āfree as in speech, not free as in beerā which is often wheeled out when describing open source.
Speech is not free when you canāt say what you want - or in this specific case, distribute to App Store. When it comes to the App Store, my understanding is that the main sticking points are
- Users should be able to run, study and modify software
- Users should be able to redistribute modified software as they see fit, even outside the App Store, not possible for iOS apps.
- Code-signing is possible under GPLv3, but only conditionally.
What it does not prohibit is sharing source through the app on the App Store, that will allow users contribute to source or generate they own, new unique app code signed by themselves (copycats, like just changing icons, are generally rejected by App Store and rightly so in my view).
But the specific phrasing of GPLv3 and especially the termination clause of not being able to distribute software at all if you break any one rule makes this needlessly incompatible with the App Store, which offers guarantee of software integrity and availability.
While it is for-profit, free software is abundant on the App Store - the impositions are to provide some safety guarantees to the end-user which, not to put too fine a point on, GPLv3 just sh*ts on because of these restrictionsā¦
Yes, all open source runs that risk, but you can distribute MIT or Apache2.0 freely on the App Store, either free or for profit and provide the minimum expected software security guarantees.
There are ways to attain the goals of GPLv3, even its viral license replication, with App Store apps, but as it stands GPLv3 makes that impossible.
Well, they did and they didnātā¦ in theory this is correct, but in practice you could build an app and submit to iOS store? I know there was dual licensing but in practical terms what difference did that make to the community version?
Not quite sure what you mean by that, but a simple search online shows that 96% to 97% of all commercial codebases contain open-source components and that MIT and Apache-2.0 are by far the dominant forms used. Sounds bit different when you say it like that!
Well that didnāt work well though, did it! (in the sense that both open source and livecode original has gone the way of the dodo, to be replaced by LCC)
MySQL? Not quite sure what the equivalence with LiveCode is thereā¦ it was acquired by Sun who are locking it down and phasing it out as I understand it, and the original author has forked this to MariaDB which is doing well.
I fully agree the desktop is where xTalk platforms shines only because when HC/SC/MC were conceived, there was no such thing as mobile apps. Mobile apps are a de facto part of life now and while web apps can fill a gap, native mobile apps are preferable.
While mobile is not a concern for now - maybe in a few yearsā time when HXT has found itās feet - unless GPLv3 modifies itās position to allow for iOS apps, sticking with this will be a limitation and a disadvantage. Not that we can do much about this mind youā¦ (re-writing the engine might be a good kickstarter when the time is right, but not now).
I say all this being a purely desktop app creator - but Iād like to think Iād get to mobile at some point 
@FourthWorld You made your point clear (again). Your preference already is a reality, as neither HyperXTalk (by decision of Emily) nor OpenXTalk (by negligence) have mobile binaries. (Both do not have server builds as well afaik, which could become even more of a pain point, but at least we have an issue by you on the HXT GitHub for this.)
This is a topic about mobile HXT builds. There are people here who are interested in making them possible, see above. You are not, I hope I get this right. I always wonder how these people should read your argument. Is it a warning against investing energy (time and maybe money) in a lost cause? Energy that should better be invested solely in the desktop offering, or in the HXT website, or the HXT GitHub readme file (all needing work), or even outside, in JavaScript-based web apps or enjoying nature?
I am not ironic here. This could be a valid warning and a call for reachable goals. I also would advise against flogging dead horses. Just state your gist clearly please. We can come to a conclusion on this (everyone individually and also as a bunch of xTalk goofballs, after discussion here).
A cut like this would actually change a lot. I see the horse being far from dead. There are ways to use xTalks beyond the packaged bootstrap-IDE-on-desktop world, but these need server and also eventually mobile builds of the engine, otherwise this branch will die sooner or later.
Also it might be interesting to hear from @Emily-Elizabeth now what the reasons were to take all mobile code out. I never asked because some reasons are obvious and comprehensible. Still it would help to have all of them all listed now given this discussion. We might have a better understanding where we stand then.
And thanks @Stam ābut Iād like to think Iād get to mobile at some pointā - it is instructive to think you would already be doing this totally naturally if we had some kind of competent offering for it. This shows the pain in the missing part, and the horse breathing.
We each make our own choices about how we present ourselves.
Aiming to attract GPL contributors, Iāll continue using more neutral terms.
Choices made by a company in 2013 are unlikely to be altered by anyone outside the company in 2026.
Its non-existence is more than theoretical.
The copyright holder simply hasnāt consented to iOS distribution terms for their GPL-governed work.
I donāt know that itās any deeper than that.
I prefer a lot of things, but can be content with what exists.
The only relevant preference is that of the copyright holder.
They chose not to release a FOSS build for iOS.
If we want one we can write our own.
Seems like a lot of work. Iām content to not write it.
Others may be more ambitious. I know only enough about the innards of xTalks to caution against such an ambitious undertaking. But given enough coffee perhaps even a clean-room rewrite may become achievable, and possibly also worth the effort.
My interests affect nothing here.
What matters is what we have on hand: we have a thread title which notes both Android and iOS, but we only have code for one of those.
Iāve brought some background as to how we got here, but where we go is up to the consent of contributors.
Given the background on why there is no LC FOSS distribution for iOS, the choice at hand is to either change the thread title, or write an iOS code base of our own under license agreed to by all contributors.
Seems simplest to change the title of this thread for now, moving the more ambitious subject of writing an iOS engine to a separate thread.
Funny, even before I read your last paragraph I thought I should really make the title more precise now. I hate changing titles. Done.
@Emily-Elizabeth while doing this I saw that in the beginning you actually gave GPL as the one clear reason to take out all mobile stuff. Is there any other reason or anything you want to add to the debate here?
We should be aware that doing it this way not only is the Android binary already affected by the GPL issue contracted in the iOS part. The same thing might happen sooner or later to MacOS and Windows builds as obviously both domains move towards managed software distribution. It starts with sideloading-discouraged (scary warnings), it could end with store-only.
Sure we can just wait and see, I would rather discuss and prepare. Just to add that the seemingly idyllic world of Linux has its own problems here. Not only is it small, but also split up distribution-wise, just go and read our topic on this here.