Livecode Create - thoughts?

[kevinmiller]

Some of you will have seen this as it went out by email yesterday. However I know for whatever reason not all of you get our emails so I’m going to post this here for those that haven’t seen it. I think it’s important to set the record straight.

https://livecode.com/an-open-letter-to-the-community/

I don’t mind a little bit of feedback on this if you want to share it but after that I think we need to get back to discussing how to use the product on these forums and move licensing discussions to direct contact.

[PaulDaMacMan]

Some of you will have seen this as it went out by email yesterday. However I know for whatever reason not all of you get our emails so I’m going to post this here for those that haven’t seen it. I think it’s important to set the record straight.

https://livecode.com/an-open-letter-to-the-community/

I don’t mind a little bit of feedback on this if you want to share it but after that I think we need to get back to discussing how to use the product on these forums and move licensing discussions to direct contact.

Thanks for writing and posting this Kevin, and for the links to more details on LC 'Create' that it contained.
Also, thank you for all of your years of dedication in keeping LiveCode (and xTalk scripting in general) alive and kicking!
Sleeping at your parent's and all of that, now that IS some dedication!

For what it's worth (nothing really), I think you're doing the right thing in shifting gears at this time.
Also with the new syntax, new widgets/controls, the lo-code / code blocks, AI helper, etc. 'Create' looks really good!

As a hobbyist who wouldn't mind making an extra buck or two in this 'side hustle' economy, I honestly think that the 'Apps for Sale' / Create Native introductory price of $308 per year (which comes out to about $25/month) + small percent profit-sharing is a very attractive model. Basically it would pay for itself at about 14 x $2 app sales per month. Still, as a workin' '9-to-5' regular dad kinda guy with children and all the expenses that goes with that, I would have a hard time justifying that yearly lump-sum expense until such time when it could be paying for itself. A monthly payment plan would be easier to justify, specially if such an app were to take a year or more to build up to that point.

I do have a question about 'Create Native', basically I would like to know more details about Create Native's 'Native' capabilities:
Based on the available screenshots, obviously Widgets are still in, but what about the rest of 'LiveCode Builder', particularly the foreign function interface? Will that still be supported with the new 'Create Native' platform/engine? Beyond having easier, non-web-sandboxed access to the local file system than a web app could have, I don't see much point in building a 'Native' app if there is not also the ability to access Operating System's APIs, other code libraries and/or physically attached devices. My primary interest in building 'native' apps, and with xTalk scripting in general, has always been centered around Music/MIDI software and hardware. That is certainly not something I would expect LC to invest your development resources into. You may not be aware, but I learned how to use LCB FFI specifically so that I could add the capabilities I wanted on my own. If I couldn't continue working on that sort of thing in 'Create Native', then I don't know that I could justify the expense (even as reasonably priced as it may be). Also would 'LC Native' retain the ability to use shell() commands and call on other scripting languages on the host computer? I assume it would, but Create does seem like a very big shift, a re-build of the LC platform, and so I can't be 100% certain.

[jacque]

LC Native is the desktop version and as I understand it, will do pretty much what we can do now.

[cmhjon]

I reached out to LC for clarification on my situation. As I have only written apps for my co-workers and make no money on them, the plan that would fit my situation is the "App Payments" option. According to LC, I would only have to pay the early developer license. In the event that I start selling apps, THEN additional licensing costs would be required.

I hope this helps clarify things for other users like me.

Best regards,
Jon

Just to be clear - you can only apply app payments when you are selling apps outside your company. Your own company will still need an Internal license for every seat. There is an exception in the FAQ if you own the LiveCode license and are building the apps in your own time. If you are building apps for your company in company time, or the company owns the license, it is Internal. You cannot choose the Apps for Sale model for Internal apps.

Then sadly, I can no longer afford LiveCode and I know my company won't pay for it. Although I own my license, I do write apps on and off company time but make no money on them nor could I charge my customers as the apps I have written do not add value to the jobs my company prints for them. For example, one app I wrote does nothing more than convert inches to centimeters. My intention was only to make my co-workers' lives a little easier and the little things my apps do will never justify $4400 - $8800/year. Please know that I am extremely sad and disheartened by this.

[stam]

Then sadly, I can no longer afford LiveCode and I know my company won't pay for it. Although I own my license, I do write apps on and off company time but make no money on them nor could I charge my customers as the apps I have written do not add value to the jobs my company prints for them. For example, one app I wrote does nothing more than convert inches to centimeters. My intention was only to make my co-workers' lives a little easier and the little things my apps do will never justify $4400 - $8800/year. Please know that I am extremely sad and disheartened by this.

Actually, that's not the case I don't think...
My use case is similar - but Kevin has clarified that 'internal users' does not apply to this.
I think it was intended for developers who are employed by a company to write software (either on a permanent or ad-hoc basis) and the software is then owned by the company.

As far as I can tell from the examples in the revised FAQ, it boils down to who owns the IP for the software. If the company does, then it's internal users. If it's the developer, then the developer is either selling apps or gifting freeware, and it comes under the app payments licence.
At least that's my interpretation, but I may well be wrong.

See my post here: viewtopic.php?f=9&t=39255&start=75#p231286
The relevant excerpt from the new FAQ (also linked at the start of that post) is:

I create apps for my colleagues in my own time using a license I own personally. I do not get paid by that company to make the apps in any way (I am creating them in my own time, not as an employee). My company does not pay for the LiveCode license and I own the IP for the software I create.

You need one license for each developer of the app. Your app is “sold” by you to your colleagues under the Apps For Sale model, which as it is free does not incur any additional costs.

[Simon Knight]

Stam,

I think the problem for cmhjon is in this line

Although I own my license, I do write apps on and off company time but make no money on them

If the code is written in company time then cmhjon is being paid to create the code despite coding not being part of their job description. QED the company is benefitting from the code through better productivity meaning RunRev will require a license for either each person using the application or each computer it is installed on. So the company pays a minimum of one licence to convert simple measurements. Hard new rules !

Obviously I may be mistaken but thats my understanding; the only way to create free apps for co-workers appears to be to do it entirely in your own time and not benefit in any way from the applications.

[stam]

Ah I missed the “on” bit, I only saw “off company time”.

I would imagine “on company time” to mean either commissioned by the company, or that the ownership/IP belongs to the company.

If that is the case, yeah, much more expensive as each user would need a licence for every user, and software would work only as long as the company upheld payments per user.

However it doesn’t apply if the work is not commissioned or paid for/reimbursed in any way by the company - apps can be shared as freeware with coworkers with apps for payment.

At least as I understand it.

[Simon Knight]

reimbursed in any way by the company

The devil is in the detail. My understanding is that if I use Livecode while at work on a normal working day then in effect I am being reimbursed by the company as I am being paid and it can be argued that they are getting benefit and therefore additional license fees are needed.

At least as I understand it.

This is another problem: none of us fully understand the new licensing partly because these grey areas have not, in my opinion, been very well explained and may well have been changed since the launch of Livecode Create. I think that the applications will be free of additional charge if they are created and tested entirely in your own time, otherwise again additional licences are required.

If I were still working and needed to create a small utility to for example prepare some data then I would not use Livecode Create because of these licensing questions. It would be far simpler to use a different language such as Apple Script, VBA or Python and not have to worry about licensing issues. This is the reason why I presently have an Indy License. Before I get jumped on I fully support the concept that RunRev needs to make money however I think that the new licensing will dissuade so called "subject matter experts" (SMEs) from using the language which was one of the use cases that were advertised when I first started using RunRevolution while working as a subject matter expert. I also accept that the SME market is comparatively small.

Changing the subject very slightly I asked Heather what the licensing situation would be if my last paid application had been written in Livecode. As a sub-contractor I was tasked with updating two MSAccess databases. Initially I pushed to use Livecode for the frontend but this was rejected so the updated/new databases were written in MSAccess and delivered to the company that had given me the task. They delivered the databases to the UK MOD who then delivered them to a group of NATO nations. These nations then issues the databases to units and structures that needed to manage the data within the two databases. I have no idea how many copies of the database are out in the wild but would guess its over fifty.

In a similar situation today (or had I used Livecode), using Livecode Create, NATO would be responsible for buying a per seat license. Given that NATO has thirty two nation states as members just managing the licenses would cause quite a headache whereas an MSAccess database may be run on any machine using the free Access runtime. The principal argument for using Livecode Create is that it saves time when compared with other languages. This may well be true but in my example the value of time saved would not offset the cost of the enduser licenses.

Lastly I question how attractive a Livecode License will be to new and often young software authors. The closest analog I can think of is that my daughter has purchased a license from Adobe having completed a degree in Art and Design. The difference is that Adobe applications are the industry standard and are used by a multitude of organisations.

I have signed up for the demonstration of LC Create later today and hope it is really really good.

[stam]

The devil is in the detail. My understanding is that if I use Livecode while at work on a normal working day then in effect I am being reimbursed by the company as I am being paid and it can be argued that they are getting benefit and therefore additional license fees are needed.

Sorry I didn't express myself clearly - anyone creating apps for coworkers is of course reimbursed unless working as a volunteer, which is not a common scenario. What I meant by that is reimbursement for the IP of the software (again, that's my understanding and indeed you make a very good point about the level of clarifications needed).

This may well be true but in my example the value of time saved would not offset the cost of the enduser licenses.

I'm in agreement with you.
You could argue NATO probably has deep pockets, but as with any organisation, they would balk at paying £20,000 per annum just for licensing (on top of a maintenance contract) and as soon as they stopped paying, the software would die.
This is the crux of the problem and a real risk people will not use LiveCode in such situations (much as you wouldn't).

Lastly I question how attractive a Livecode License will be to new and often young software authors.

Well, it's all about affordability. You could argue people are now used to paying subscriptions for software but generally at lower cost. Affordability will be weighed against time-saving/efficiencies but only up to a point. If the price point exceeds that, no one will be enticed.

There are a number of interesting pricing structures out there.
One I like and mentioned previously is the one used by Parorama DB: http://www.provue.com/#pricing
This strikes me as
a) much fairer,
b) could be applied to 'internal users' and developers and
c) would, in my inexpert opinion, be more likely to draw in developers from other languages as well as new developers.

I really like this model because it feels fair and friendly, but not sure how financially viable it would be for LC.
On the one hand it would almost certainly lead to a drop in income from existing users - but on the other hand this strikes me as something that would entice new users. But again that's my view and I'm no expert...

[Simon Knight]

One I like and mentioned previously is the one used by Parorama DB: http://www.provue.com/#pricing

I had forgotten about Parorama. The pricing is really competitive and the application looks interesting and is described as Hypercard like.

[cmhjon]

I paid for my license and have never asked my company to reimburse me nor do I get specifically reimbursed for app development nor has my company has never asked me to build an app for them (it's not even a part of my job description!). Every app I have written was born from hearing about an annoyance somewhere. The aforementioned Inches to Centimeters app was born after walking by a co-worker and noticed him looking at his smart phone followed by entering something into the PC that is attached to the equipment he works on. When I asked him what he was doing, he explained that he had to go to a website on his smart phone to do inch to centimeter conversions as the equipment he works on only accepts measurements in centimeters so I offered to build an app that could be put on the PC attached to his equipment. It took about an hour to build.

As mentioned prior, I develop on and off site but some of my apps must ultimately be tested and tweaked on-site as they read from a network resource which I cannot test from home.

The apps I build do not make my company money. They only address annoyances.

[Simon Knight]

Hi,
I suggest that you contacted Runrev directly with you use case as no one here fully understands the fine print. Stam may well be correct in that as you retain the IPR of the applications and make no money from them that there will be no further license payments required.

Good luck

Simon

[dunbarx]

I have a feeling (a hope?) that people like cmhjon (and myself) will find that in the end this will not be a financial deal killer. I believe that Kevin fully understands the personal/semi-personal use cases, and will not dismay that group.

That such a group exists at all is, I bet, unique to LC. That is both a worry (it always has been) and also a testament to its beauty and power.

Craig

[stam]

I paid for my license and have never asked my company to reimburse me nor do I get specifically reimbursed for app development nor has my company has never asked me to build an app for them (it's not even a part of my job description!). Every app I have written was born from hearing about an annoyance somewhere.
<snip>
The apps I build do not make my company money. They only address annoyances.

Well that is exactly my situation and I've discussed this with Kevin; the addition to the FAQ I quote above was borne out of this (see Kevin's reply to my post I've linked to above).

So unless I've grossly misunderstood, the same applies to you and the App Payments license, rather than Internal users, should apply, which as freeware entails no extra costs and no need to purchase further licences and as sold software provides LC with a fair % of profit. Always good to check with the LC team of course, but I think on this they've been explicit.

I had gently enquired about making it clearer by simplifying licensing to "who owns the IP":

One further question: Unless I've misunderstood the example use cases, the appropriate licensing really hinges upon who owns the IP for the software - if it's the developer then its the Apps For Sale licence, if not then it's the Internal Users licence... is this correct?

As far as I can tell that largely holds true. Internal apps are those apps created for use within your own company as an employee, or as a single bespoke project for one other company. Apps for Sale are apps being sold to customers. In your case, the company is not paying you to write the apps, nor for the LiveCode license and you own the IP. Thus you own these apps and are selling them to the business. You have chosen the model as freeware. Almost everyone creates apps in company time and/or the company owns the IP and does need an Internal license in that case.

To me it seems clearer to define licensing this way, but of course I can't speak for LiveCode Ltd and don't know what their intentions are in this regards - but that how I read them based on the example use cases given here: https://future.livecode.com/which-license-do-i-need/

[Simon Knight]

Kevin quoted from above

Almost everyone creates apps in company time and/or the company owns the IP and does need an Internal license in that case.

This seems open to interpretation to me and

As far as I can tell that largely holds true

also seems to introduce a level of uncertainty.

I wish you both good luck and think I shall withdraw.

S