The second bit ("it only requires that all source be provided to those who have received binaries built from it") looks extremely odd: surely the source should be provided to ANYONE WHO REQUESTS IT whether they have downloaded the "binaries built from it" or not?GPL does not require binaries to be provided, nor even a project to build for a thirdparty - it only requires that all source be provided to those who have received binaries built from it.
The "Pre-Built Binaries"
- richmond62
- Posts: 4239
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: The "Pre-Built Binaries"
I would be extremely interested in what our resident GPL and licensing mage (FourthWorld) has to say about this:
https://richmondmathewson.owlstown.net/
- richmond62
- Posts: 4239
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: The "Pre-Built Binaries"
Woogly-Googly:
"If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer."
https://www.gnu.org/licenses/gpl-faq.en ... en%20offer.
"If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer."
https://www.gnu.org/licenses/gpl-faq.en ... en%20offer.
https://richmondmathewson.owlstown.net/
- tperry2x
- Posts: 2782
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
Re: The "Pre-Built Binaries"
https://gpl-violations.org/gpl/
They are still offering it. To imply otherwise is false: = Their github page is still active, so it's still being offered. They have to provide it for 3 years (as from the point they pulled it in 2021), so they should be offering it until August 31st, 2024. They are simply just waiting out the clock, hoping nobody will notice until it's too late.
The reason? Because if the engine development of OXT ceases, then ultimately their single greatest direct competition just fades away when the engine is no longer capable of being updated.
'any third party', includes us.Accompany it with a written offer, valid for at least three years, to give any third party, [...], a complete machine-readable copy of the corresponding source code.
They are still offering it. To imply otherwise is false: = Their github page is still active, so it's still being offered. They have to provide it for 3 years (as from the point they pulled it in 2021), so they should be offering it until August 31st, 2024. They are simply just waiting out the clock, hoping nobody will notice until it's too late.
The reason? Because if the engine development of OXT ceases, then ultimately their single greatest direct competition just fades away when the engine is no longer capable of being updated.
- richmond62
- Posts: 4239
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: The "Pre-Built Binaries"
I do hope that FourthWorld will get involved, as he, unlike me, "knows his stuff" re the GPL and so forth.
https://richmondmathewson.owlstown.net/
-
- Posts: 389
- Joined: Sat Sep 11, 2021 4:37 pm
- Contact:
Re: The "Pre-Built Binaries"
If that company is no longer offering an open source package, what current obligation could they have?richmond62 wrote: ↑Wed Mar 06, 2024 4:52 pm Woogly-Googly:
"If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer."
https://www.gnu.org/licenses/gpl-faq.en ... en%20offer.
- tperry2x
- Posts: 2782
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
- tperry2x
- Posts: 2782
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
Re: The "Pre-Built Binaries"
I'll also mention that Paul hit the nail on the head 2 years ago.
Or rather, they were. The fact they are walled off effectively makes what should be open source (while the github page exists) into a closed source offering.prebuilt binaries" are in a sub-module repo
- richmond62
- Posts: 4239
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: The "Pre-Built Binaries"
Where, for the sake of argument, would one go looking for pre-built binaries inside a LC 9.6.3 Mac package?
AND, as 'those people' have been pulling 'fast ones' on people for a long time (the 'goals', the 'stretch goals' for the Open Source appeal spring immediately to mind.
The 'dirty, brown sofa' video was probably staged to give a false impression.
Why do some people round these parts appear surprised?
AND, as 'those people' have been pulling 'fast ones' on people for a long time (the 'goals', the 'stretch goals' for the Open Source appeal spring immediately to mind.
The 'dirty, brown sofa' video was probably staged to give a false impression.
Why do some people round these parts appear surprised?
https://richmondmathewson.owlstown.net/
- tperry2x
- Posts: 2782
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
Re: The "Pre-Built Binaries"
That's just it. You won't find them visible inside a Mac package, because when compiling the engine they become part of the engine itself. When compiled into an application / binary, the original source is lost and imalgamated into an application.richmond62 wrote: ↑Wed Mar 06, 2024 7:38 pm Where, for the sake of argument, would one go looking for pre-built binaries inside a LC 9.6.3 Mac package?
- richmond62
- Posts: 4239
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: The "Pre-Built Binaries"
I am not going to let sleeping turds lie:
-
-
https://richmondmathewson.owlstown.net/
- tperry2x
- Posts: 2782
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
Re: The "Pre-Built Binaries"
Thank you Richmond.
As far as I'm concerned, we have just shy of 5 months of persistent constant nagging - which I hope it doesn't come to.
[redacted]
As far as I'm concerned, we have just shy of 5 months of persistent constant nagging - which I hope it doesn't come to.
[redacted]
-
- Posts: 389
- Joined: Sat Sep 11, 2021 4:37 pm
- Contact:
Re: The "Pre-Built Binaries"
The three-year consideration may obligate them to continue making the source available through August.
This thread has "pre-built" in the title, and much of the discussion seems to be about pre-builts.
Are non-source materials included in that section about source materials?
Is what's requested here actually about source code?
It's a long thread, so please be patient if I missed the post that would make it obvious that no one's asking about pre-builts all, but instead about source code.
This thread has "pre-built" in the title, and much of the discussion seems to be about pre-builts.
Are non-source materials included in that section about source materials?
Is what's requested here actually about source code?
It's a long thread, so please be patient if I missed the post that would make it obvious that no one's asking about pre-builts all, but instead about source code.
- tperry2x
- Posts: 2782
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
Re: The "Pre-Built Binaries"
Just to be clear, this also includes anything deemed as a referenced and required library, which the prebuilts are.
- OpenXTalkPaul
- Posts: 2391
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: The "Pre-Built Binaries"
The response Richmond received is what I expected, they have no incentive to help anybody build the open-source version.
After bragging for quite a few years about being an 'Open-Source Company' they then blamed the open-source users for their lack of success, so if they actually believe that (which I'm not sure that they do) then there could be some hard feelings on their side of it too. But I'd hardly call it relevant competition, since OXT and anything made from it will always be open-source.
The binary builds of 3rd party libraries is not technically a requirement of the GPLv3 license. It's only required that they provided the source for any modifications that they may have made to those libraries, which according to their response, they've met that obligation with that ''LiveCode 3rd party' source repo that has no binary releases. You could try asking The Free Software Foundation or similar for advice, but I doubt there's any legal grounds to demand they hand over '3rd party binaries'.
I understand that they wanted to speed-up the Engine building time, but it certainly seems a bit disingenuous to have them linked in a build script that downloads a generically named zip file, behind a now-non-public password-walled-off server, where we now can not even inspect those binaries to ensure that when we build these libraries for ourselves they match (as far as version or any library symbols used) so that we can produce the same exact binary that was distributed. I mean we don't even have a simple file names list of the contents of those archives.
It's just another barrier to building the thing from source that didn't need to be. But it is a barrier that (according to their response) we should be able to overcome by building those libraries ourselves and then modifying the build process to skip the download / extract parts. I've built most, if not all, of the Mac (debug) versions of these libraries from the v9.6.3 source (there was something missing, I can't recall exactly what, maybe OpenSSL? or 'libScript'?) or from 'Homebrew' (which I believe always builds the dev .a versions for most build formulas).
That's what we need the code archive ( '.a' -Dev Build) versions of all of these libraries, one for each of the platforms and architectures where the engine requires them. Personally I would be happy if we can al least get it together for macOS x86_64 builds, and we already have them for Linux builds.
After bragging for quite a few years about being an 'Open-Source Company' they then blamed the open-source users for their lack of success, so if they actually believe that (which I'm not sure that they do) then there could be some hard feelings on their side of it too. But I'd hardly call it relevant competition, since OXT and anything made from it will always be open-source.
The binary builds of 3rd party libraries is not technically a requirement of the GPLv3 license. It's only required that they provided the source for any modifications that they may have made to those libraries, which according to their response, they've met that obligation with that ''LiveCode 3rd party' source repo that has no binary releases. You could try asking The Free Software Foundation or similar for advice, but I doubt there's any legal grounds to demand they hand over '3rd party binaries'.
I understand that they wanted to speed-up the Engine building time, but it certainly seems a bit disingenuous to have them linked in a build script that downloads a generically named zip file, behind a now-non-public password-walled-off server, where we now can not even inspect those binaries to ensure that when we build these libraries for ourselves they match (as far as version or any library symbols used) so that we can produce the same exact binary that was distributed. I mean we don't even have a simple file names list of the contents of those archives.
It's just another barrier to building the thing from source that didn't need to be. But it is a barrier that (according to their response) we should be able to overcome by building those libraries ourselves and then modifying the build process to skip the download / extract parts. I've built most, if not all, of the Mac (debug) versions of these libraries from the v9.6.3 source (there was something missing, I can't recall exactly what, maybe OpenSSL? or 'libScript'?) or from 'Homebrew' (which I believe always builds the dev .a versions for most build formulas).
That's what we need the code archive ( '.a' -Dev Build) versions of all of these libraries, one for each of the platforms and architectures where the engine requires them. Personally I would be happy if we can al least get it together for macOS x86_64 builds, and we already have them for Linux builds.
- tperry2x
- Posts: 2782
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
Re: The "Pre-Built Binaries"
Exactly this ^.
Anything will be helpful - even a file list.
Also for anyone building the engine from the "Livecode Community" source afresh. With the greatest of respect to Paul (and also mirrored back at me) they might not want all of our changes we made to OXT. They may want to compile things and go their own direction.
My point is without having the prebuilts available, it also stymies any attempt for anyone else to compile the engine too. This is why the redit comment 2 years ago by that other poster. They were quite correct as they had hit the hurdle we now face.
People reading this probably think "oh, here he goes again... having a winge about the prebuilts...", but I keep going on about it as it relies on further assistance. If it was all under my / our control, we'd have done something about it all by now. Not just for the OXT project, but for anyone compiling the engine as above.
On the download page, I've put the mega link (revised source > "Windows tools you will need") - just trying to collect everything together to allow the engine compile to stand a chance under Windows.
Anything will be helpful - even a file list.
Also for anyone building the engine from the "Livecode Community" source afresh. With the greatest of respect to Paul (and also mirrored back at me) they might not want all of our changes we made to OXT. They may want to compile things and go their own direction.
My point is without having the prebuilts available, it also stymies any attempt for anyone else to compile the engine too. This is why the redit comment 2 years ago by that other poster. They were quite correct as they had hit the hurdle we now face.
People reading this probably think "oh, here he goes again... having a winge about the prebuilts...", but I keep going on about it as it relies on further assistance. If it was all under my / our control, we'd have done something about it all by now. Not just for the OXT project, but for anyone compiling the engine as above.
On the download page, I've put the mega link (revised source > "Windows tools you will need") - just trying to collect everything together to allow the engine compile to stand a chance under Windows.
-
- Posts: 285
- Joined: Thu Sep 16, 2021 1:40 pm
- Contact:
Re: The "Pre-Built Binaries"
I was not expecting this fiasco and initiated a little publicity for OpenXTalk.
I don't know when or how soon or if it all that publicity will take place but there will be 238,000 pairs of eyes and ears that may get their first impression of Livecode and RunRev Inc. as bad actor in the open source community.
Way to spoil the good will. Could have been the Blender of the RAD world.
I know you guys all love this IDE, it's really a work of art, but there is PASCAL.
And they even have a 3D game engine.
We could just compile every last xTalk script file, build a GPT, and have the GPT build a wrapper for xTalk that works in PASCAL.
Just putting that on the table. I have a theory someone in LC is trying to undermine the company so they can buy it out from under them in their most desperate hour. Loss of 75% of their user base in the age of NO CODE? And not even an open source legacy to say "We made the world of programming a better place for all mankind?"
Hello dinosaurs, meet meteor.
*I mention PASCAL because they have a user interface as opposed to "Do everything blindly in a text editor and hope it works out."
What do we love about this software:
1. language, easy enough to copy the parts we like into any environment, could define and run the same commands in Fallout 3 if we wanted to
2. user interface, it's so smooth and good, I tell everyone to copy it. Maybe it's our lot in life to make our own user interface.
3. it builds apps for multiple platforms, do we care about that anymore? Are we doing it for other people to use apps? Not me, I do it for other people to find working code. The apps are a convenience from time to time, but 9 times out of 10 over 20 years...I use my little app I built two or three times and that's it. Could have done whatever I was doing from Python or Lua or BASIC in the terminal most the time.
Maybe we should port the whole language over to Blender.
I don't know when or how soon or if it all that publicity will take place but there will be 238,000 pairs of eyes and ears that may get their first impression of Livecode and RunRev Inc. as bad actor in the open source community.
Way to spoil the good will. Could have been the Blender of the RAD world.
I know you guys all love this IDE, it's really a work of art, but there is PASCAL.
And they even have a 3D game engine.
We could just compile every last xTalk script file, build a GPT, and have the GPT build a wrapper for xTalk that works in PASCAL.
Just putting that on the table. I have a theory someone in LC is trying to undermine the company so they can buy it out from under them in their most desperate hour. Loss of 75% of their user base in the age of NO CODE? And not even an open source legacy to say "We made the world of programming a better place for all mankind?"
Hello dinosaurs, meet meteor.
*I mention PASCAL because they have a user interface as opposed to "Do everything blindly in a text editor and hope it works out."
What do we love about this software:
1. language, easy enough to copy the parts we like into any environment, could define and run the same commands in Fallout 3 if we wanted to
2. user interface, it's so smooth and good, I tell everyone to copy it. Maybe it's our lot in life to make our own user interface.
3. it builds apps for multiple platforms, do we care about that anymore? Are we doing it for other people to use apps? Not me, I do it for other people to find working code. The apps are a convenience from time to time, but 9 times out of 10 over 20 years...I use my little app I built two or three times and that's it. Could have done whatever I was doing from Python or Lua or BASIC in the terminal most the time.
Maybe we should port the whole language over to Blender.
- tperry2x
- Posts: 2782
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
Re: The "Pre-Built Binaries"
I think it's fair to say we all have a soft spot for the language.
The interface could do with redesigning throughout.
Ultimately, it's the xtalk language why we are here (I can't speak for everyone, but I suspect those who use it - they do so because of it's "natural language underpinnings" - ack; sorry. Acid reflux ).
Seriously though, what we need is something that can interpret xtalk at lightning speed, render the results to screen (again, preferably using the GPU inside the computer if available). If not, do it in software for older computers.
Have everything externalised, so we don't need to be experts in C++ to add something to the engine, or have to dabble in other languages to achieve what we are after.
That's a huge ask of course. We take a lot for granted that we've "inherited" over. However, we've also gained a huge task in other respects.
Ultimately though, it's why I'm not spending all my time in Godot (some of it, granted)... okay, a better example. It's why I'm not using xCode because C++ is like pulling teeth compared to xtalk. Just as painful, but with less results.
This was why I started work on my new engine. The idea was it was going to be predominantly coded in Zig, as that's hugely cross-compilable (I'd like to keep the ability to deploy to multiple operating systems of any flavour, as that's perhaps one of the other things that sets OXT/LCC apart from many other programming tools out there). There's not really much else like it.
But, making the new engine is a huge process too. I have to first create a list of keywords (even down to basic 'put', 'get'), then there's the if else logic to deal with, then tokenise it (split up each command the user might type into sections), so it can be processed in realtime, and made sense of by the xtalk to C++ interpreter.
It would be really good if we could use a similar project's underpinnings without the baggage. This is EXACTLY why I was interested in openxion, and I contacted the developer (Rebecca G. Bettencourt), but heard nothing unfortunately. That's a real shame, because I'm sure she'd love to see her project find a whole new audience and be developed further.
I wish we could use it as a base for a revised engine. (Once we have a base to work from, and are in xTalk, I'm sure we could all go at it and everyone could add things such as colour support - and all the things we take for granted). In my view, if xTalk has a future, it's going to be in an engine such as openxion. Rebecca mentions on her github page that "version 2 will be ported to a lower-level language", which I take to mean C++ or something. This is great, but if we can get it to load a new window on startup where it puts us into a script editor. Which basically has:
That's all we need. "All" he says...
I don't see a future in OXT when it's based on the LC engine and the interwoven mess that is the IDE. (Change something small and risk breaking something drastically somewhere else).
Does anyone know Rebecca, or has spoken to her before? Does Rebecca browse these posts? Is she totally against this idea, or would she give us free-reign of a fully open-source fork of her code with her permission? I just don't know.
The interface could do with redesigning throughout.
Ultimately, it's the xtalk language why we are here (I can't speak for everyone, but I suspect those who use it - they do so because of it's "natural language underpinnings" - ack; sorry. Acid reflux ).
Seriously though, what we need is something that can interpret xtalk at lightning speed, render the results to screen (again, preferably using the GPU inside the computer if available). If not, do it in software for older computers.
Have everything externalised, so we don't need to be experts in C++ to add something to the engine, or have to dabble in other languages to achieve what we are after.
That's a huge ask of course. We take a lot for granted that we've "inherited" over. However, we've also gained a huge task in other respects.
Ultimately though, it's why I'm not spending all my time in Godot (some of it, granted)... okay, a better example. It's why I'm not using xCode because C++ is like pulling teeth compared to xtalk. Just as painful, but with less results.
This was why I started work on my new engine. The idea was it was going to be predominantly coded in Zig, as that's hugely cross-compilable (I'd like to keep the ability to deploy to multiple operating systems of any flavour, as that's perhaps one of the other things that sets OXT/LCC apart from many other programming tools out there). There's not really much else like it.
But, making the new engine is a huge process too. I have to first create a list of keywords (even down to basic 'put', 'get'), then there's the if else logic to deal with, then tokenise it (split up each command the user might type into sections), so it can be processed in realtime, and made sense of by the xtalk to C++ interpreter.
It would be really good if we could use a similar project's underpinnings without the baggage. This is EXACTLY why I was interested in openxion, and I contacted the developer (Rebecca G. Bettencourt), but heard nothing unfortunately. That's a real shame, because I'm sure she'd love to see her project find a whole new audience and be developed further.
I wish we could use it as a base for a revised engine. (Once we have a base to work from, and are in xTalk, I'm sure we could all go at it and everyone could add things such as colour support - and all the things we take for granted). In my view, if xTalk has a future, it's going to be in an engine such as openxion. Rebecca mentions on her github page that "version 2 will be ported to a lower-level language", which I take to mean C++ or something. This is great, but if we can get it to load a new window on startup where it puts us into a script editor. Which basically has:
Code: Select all
on startup
-- this is where the C++ code ends, and the xTalk magic begins!
-- we are now in an xtalk environment and ready to create a new GUI.
-- this file is the "home" stack, and is the first stack to be loaded. Build out from here!
end startup
I don't see a future in OXT when it's based on the LC engine and the interwoven mess that is the IDE. (Change something small and risk breaking something drastically somewhere else).
Does anyone know Rebecca, or has spoken to her before? Does Rebecca browse these posts? Is she totally against this idea, or would she give us free-reign of a fully open-source fork of her code with her permission? I just don't know.
-
- Posts: 285
- Joined: Thu Sep 16, 2021 1:40 pm
- Contact:
Re: The "Pre-Built Binaries"
I checked in on Rebecca, she's employed as a programmer so she may be under some agreement like "Anything you develop (or even discuss) while working for us, belongs to us.", and she's a bit on the older side so she may leave work at work and spend time with her grandkids instead of more work. She's working in California so it may be a 10 hour commute each way the two miles to and from work.
Does anyone run Java anymore? I haven't it installed in like 15 years.
I think we have to poke around the no-code solutions to roll an IDE before we break our brain with C++ to reinvent the wheel.
You know, we could build xTalk in Godot. Do they have their C# act together yet? That's like super BASIC, until it's not.
I'm really in favor of RayLib Try RayLib Layout, I was making a parser for it the othe rnight and then I got very distracted doing other things.
Does anyone run Java anymore? I haven't it installed in like 15 years.
I think we have to poke around the no-code solutions to roll an IDE before we break our brain with C++ to reinvent the wheel.
You know, we could build xTalk in Godot. Do they have their C# act together yet? That's like super BASIC, until it's not.
I'm really in favor of RayLib Try RayLib Layout, I was making a parser for it the othe rnight and then I got very distracted doing other things.
- tperry2x
- Posts: 2782
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Somewhere in deepest darkest Norfolk, England
- Contact:
Re: The "Pre-Built Binaries"
Java is everywhere.
In fact, it's so interwoven in everything. You might not have the JRE or JDK installed, but every OS these days has the java libs included as so much software sees it as a dependency.
The java libs are even present in an original Nokia 3310, - when I say everywhere, I really mean everywhere.
So people probably use it without knowing they are using some part of it. Unless you are in something like MacOS 10.9 where Apple deliberately stripped it out of the OS (they had a falling out with Oracle at the time over licensing), only to add it back in when they got to MacOs 10.10 Yosemite.
(I remember having to deal with a lot of upset creative types that came in, rightly complaining that they couldn't open Photoshop anymore because it said Java libraries were missing in 10.9) it was a decision that Apple eventually ironed out by throwing money at the problem and having a slightly modified version. There were quite a few differences with the variant of Java that shipped in 10.10 with the version you could download from the main Java site at the time. But, it was enough to get these programs to function and take the heat off Apple. You wouldn't think you were using Java by opening Photoshop at the time (this is before it did anything online, before any AI in it, before creative cloud). It kept everything local on your machine. Still used java underpinnings.
But, that's exactly why I hoped the version of openxion, ported to a lower level language, would happen. To get away from a reliance on other code and start with a fresh base.
I mean, we'd need Rebecca's permission, full agreement and to be on-side with what we are trying to create here.
If that was possible, then we don't have to reinvent the xtalk interpreter from nothing, which is a huge amount of work in itself that we then wouldn't have to do.
In fact, it's so interwoven in everything. You might not have the JRE or JDK installed, but every OS these days has the java libs included as so much software sees it as a dependency.
The java libs are even present in an original Nokia 3310, - when I say everywhere, I really mean everywhere.
So people probably use it without knowing they are using some part of it. Unless you are in something like MacOS 10.9 where Apple deliberately stripped it out of the OS (they had a falling out with Oracle at the time over licensing), only to add it back in when they got to MacOs 10.10 Yosemite.
(I remember having to deal with a lot of upset creative types that came in, rightly complaining that they couldn't open Photoshop anymore because it said Java libraries were missing in 10.9) it was a decision that Apple eventually ironed out by throwing money at the problem and having a slightly modified version. There were quite a few differences with the variant of Java that shipped in 10.10 with the version you could download from the main Java site at the time. But, it was enough to get these programs to function and take the heat off Apple. You wouldn't think you were using Java by opening Photoshop at the time (this is before it did anything online, before any AI in it, before creative cloud). It kept everything local on your machine. Still used java underpinnings.
But, that's exactly why I hoped the version of openxion, ported to a lower level language, would happen. To get away from a reliance on other code and start with a fresh base.
I mean, we'd need Rebecca's permission, full agreement and to be on-side with what we are trying to create here.
If that was possible, then we don't have to reinvent the xtalk interpreter from nothing, which is a huge amount of work in itself that we then wouldn't have to do.
-
- Posts: 389
- Joined: Sat Sep 11, 2021 4:37 pm
- Contact:
Re: The "Pre-Built Binaries"
Where do you have the attention of a 238,000-member audience?xAction wrote: ↑Thu Mar 07, 2024 5:38 pm I was not expecting this fiasco and initiated a little publicity for OpenXTalk.
I don't know when or how soon or if it all that publicity will take place but there will be 238,000 pairs of eyes and ears that may get their first impression of Livecode and RunRev Inc. as bad actor in the open source community.
Since LC isn't in the open source community it's hard to imagine either side would care much.
But I'm keenly interested in an engaged 238,000-member audience.
Who is online
Users browsing this forum: No registered users and 1 guest