Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Kay C Lan]

On Fri, Jul 22, 2016 at 10:03 AM, Sannyasin Brahmanathaswami
 wrote:
>
>  "Apple's walled garden is not a fertile pasture for growing Free Software.  "
>
> ?? there are 10's of thousands of free apps in the app store. How is that an 
> "unfertile pasture?"
>
You started so well and then fell into a common misconception. As
Richard pointed out Free and Libre are two different things.

> If your app has zero In-App purchases… it is really, really free.
>
> Just because of Apple's policy you want me

> just feeling Apple Thorn in the side ...

>allowing Apple's rules become the ruling mandate...

Another common misconception is people incorrectly blame Apple. This
has NOTHING to do with Apple and everything to do with what License
you choose to use. It is the FSF who have INTENTIONALLY made the GPL
incompatible with proprietary software and ergo Apple, not the other
way around. Apple is more than happy to distribute OSS on it's
website, and there are many examples of that. You the Developer just
have to choose a license compatible with proprietary systems, of which
there are several. As mentioned previously, the struggle with VLC and
the eventual adoption of Mozilla Public License v2.0 is a perfected
example of Apple doing absolutely nothing to it's rules and the
developer choosing the right license so their app could be libre from
the restrictions actively enforced (in court) by the FSF.

In the case of LiveCode, you can buy your libre to choose the license
you distribute you app with by purchasing a Business or Indy License.
If you choose a Community License then you have no libre in the choice
of license for your work

I think a License Guide would be helpful to clear up some
misconceptions, particularly that all OSS licenses offer the same
libre and in particular with LC, some Buisness/Indy combined with
Community contribution apps may be incompatible with the desired
destination/audience/distribution method.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: Licensing AGAIN [was: Sharing FontLab Plugin]

[Erik Beugelaar]

Working as a hired consultant in many teams with colleague developers I have
never met one developer who did not "steal" some code from whatever resource
(internet, books etc) to use it in a project that's needs to get done. Every
developer looks around to prevent inventing the wheel again over and over.
To keep a tracklist of used handler/scripts from community license
developers during the development process is for me an insane option. More
insane to force to publish it under a GPL/3 license after if you are
developing a commercial product with a paid closed source indy option.
My grandfather who was a fighter (and surviver) in WorldWar II has told me
one lesson to remember forever: If you stay between the lines you will never
move on (that is what sheeps are doing), you have to walk on it and even
sometimes you have to cross the lines to go further and take the
consequences after and deal with it.

Just my 2 cents.

Erik


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Kay C Lan
Sent: vrijdag 22 juli 2016 06:57
To: How to use LiveCode 
Subject: Re: Licensing AGAIN [was: Sharing FontLab Plugin]

On Thu, Jul 21, 2016 at 5:54 AM, Peter TB Brett 
wrote:
>
> - If the app is closed-source, this definitely violates the LiveCode 
> Indy end user license agreement and probably also the LiveCode 
> Community copyright license.
>
Just to clarify, what you are saying is:

if ANY Business or Indy license holder has taken ANY handler/script
submitted to this List or the Forums, and that handler was the creation of a
Community License holder, that handler is subject to
GPLv3 so the released software CAN NOT be closed and can NOT end up on
Apples' store.

OR, to put it another way:

Business and Indy license holders should ONLY accept help, in the form of
scripts/handlers, from other Business and Indy license holders, if they
intend to create a closed app that does not raise the ire of the FSF.

OR, to put in another way:

Business and Indy license holders who include scripts/handlers created by
Community License holders, MUST release their work under GPL v3; which can
NOT be released via Apple.

It is important to understand that the Company's (LC) 'intention' can NOT
deviate from the GPL v3 legal requirements which the FSF will enforce, i.e.
just because the Company (LC) would like to interpret a paragraph one way,
and allow a certain situations/circumstances, doesn't mean the FSF (court)
will interpret it the same way.

> Apple's walled garden is not a fertile pasture for growing Free Software.
> If you want to make Free Software apps for mobile devices, target Android.

Hmm, I think this is a common misconception of the situation. Apple is more
than happy to distribute OSS. I think VLC is an important case to consider.
Apple was more than happy to distribute it and many of the code contributors
were more than happy for Apple to do that. It was a few zealots at the FSF
who pointed out it was not legally possible under GPL v2. So the OSS
contributors who wanted VLC on the App Store went ahead and, if I remember
correctly, recoded VLC under the less restrictive LGPL v 2.1, but this still
upset a few at the FSF (not
Apple) so the only way the intention of the VLC community could be fulfilled
was to abandon GPL and relicense under the OSS Mozilla Public License v 2.0.
Apple is now happily distributing it for them and where it seems to be
extremely popular and well received (this last bit based purely on my own
assessment that VLC is one of the few apps that I've checked out on the App
Store that comes with a bunch of ratings and reviews rather than the
ubiquitous "We have not received enough ratings" blurb). It was the FSF
who stunted VLCs growth, not Apple.

As Richard has stated, it's very important to consider which OSS license is
right for you, some (MIT, BSD, MPL v2.0) offer you the freedom to do what
you want, like distribute via Apple, whilst others, notably those from the
FSF (GPL), are less permissive and the constraints are actively enforced in
court.

I think a blog post on this topic would be engaging, a License Guide that
lived in the LC Dictionary helpful, using plain English and a
infographic/matrix.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Sannyasin Brahmanathaswami]

Mark Wilcox wrote:

Having the investment of a lifetime license, I'm not
keen to see LiveCode basing part of their business model on a very
dubious interpretation of copyright law, which also restricts the useful
sharing of code between community edition users and commercial license
holders.

@ Mark: well said. While I don't have a lifetime license I am paid through 2021 
or something like that and have been on board since the beginning. 

All my advocacy of LiveCode has been geared to having possible collaborators. 
But having just now done a thorough reading of the EULA… it seems I will 
henceforth just keep my mouth shut because I can't be asking people to go spend 
$700.00 just to help design screens.

This has very real consequences in this world. I'll have to get others to join 
a team on Lucid Chart, or use Balsamiq and other such tools to help develop UI; 
 and the number of free or inexpensive options for this front end development 
is exploding, so it will not be difficult to find viable alternatives to 
LiveCode. or they can just make "boxes" in MS word. Off now to the  web to look 
for the latest UI dev stuff, anyone have ideas on this? send me ideas off list. 
I was using Draw.io for a while… very cool… I'll get back into it. Easily 
adapted for mobile screens and can integrated into Google app/docs…

Sadly, this it not direction the direction I wanted to go in, because in every 
case where someone "bit on the hook" and tried the community edition, they were 
smitten by Livecode within a few days… "wow, that easy! Awesome! Now how to I 
make a group that is a background?"   and off they go to the LC newbie races…

But now we have no choice but to ask these would be collaborators on front end 
stack development to use other tools.   Exactly the opposite to contributing to 
the "health of the livecode ecosystem."  

Mahalo

Brahmanathaswami  


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Kay C Lan]

On Thu, Jul 21, 2016 at 5:54 AM, Peter TB Brett
 wrote:
>
> - If the app is closed-source, this definitely violates the LiveCode Indy
> end user license agreement and probably also the LiveCode Community
> copyright license.
>
Just to clarify, what you are saying is:

if ANY Business or Indy license holder has taken ANY handler/script
submitted to this List or the Forums, and that handler was the
creation of a Community License holder, that handler is subject to
GPLv3 so the released software CAN NOT be closed and can NOT end up on
Apples' store.

OR, to put it another way:

Business and Indy license holders should ONLY accept help, in the form
of scripts/handlers, from other Business and Indy license holders, if
they intend to create a closed app that does not raise the ire of the
FSF.

OR, to put in another way:

Business and Indy license holders who include scripts/handlers created
by Community License holders, MUST release their work under GPL v3;
which can NOT be released via Apple.

It is important to understand that the Company's (LC) 'intention' can
NOT deviate from the GPL v3 legal requirements which the FSF will
enforce, i.e. just because the Company (LC) would like to interpret a
paragraph one way, and allow a certain situations/circumstances,
doesn't mean the FSF (court) will interpret it the same way.

> Apple's walled garden is not a fertile pasture for growing Free Software.
> If you want to make Free Software apps for mobile devices, target Android.

Hmm, I think this is a common misconception of the situation. Apple is
more than happy to distribute OSS. I think VLC is an important case to
consider. Apple was more than happy to distribute it and many of the
code contributors were more than happy for Apple to do that. It was a
few zealots at the FSF who pointed out it was not legally possible
under GPL v2. So the OSS contributors who wanted VLC on the App Store
went ahead and, if I remember correctly, recoded VLC under the less
restrictive LGPL v 2.1, but this still upset a few at the FSF (not
Apple) so the only way the intention of the VLC community could be
fulfilled was to abandon GPL and relicense under the OSS Mozilla
Public License v 2.0. Apple is now happily distributing it for them
and where it seems to be extremely popular and well received (this
last bit based purely on my own assessment that VLC is one of the few
apps that I've checked out on the App Store that comes with a bunch of
ratings and reviews rather than the ubiquitous "We have not received
enough ratings" blurb). It was the FSF who stunted VLCs growth,
not Apple.

As Richard has stated, it's very important to consider which OSS
license is right for you, some (MIT, BSD, MPL v2.0) offer you the
freedom to do what you want, like distribute via Apple, whilst others,
notably those from the FSF (GPL), are less permissive and the
constraints are actively enforced in court.

I think a blog post on this topic would be engaging, a License Guide
that lived in the LC Dictionary helpful, using plain English and a
infographic/matrix.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Richard Gaskin]

Mark Wilcox wrote:

> My concern around LiveCode over-reaching with their derivative
> work claims (which are significantly stronger than those made
> by WordPress and Drupal)

In what way(s)?


> I'd really hope to see a more enlightened policy here

Apparently some clarification would be useful.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> but first  Peter wrote:
>
> "- If the app is closed-source, this definitely violates the
> LiveCode Indy end user license agreement"
>
> ?
>
> https://livecode.com/products/livecode-platform/pricing/
>
> has a check mark next to "Protect your source code"
>
> What are we missing there?

See my earlier reply about build farms:



> Apple does allow you to put up your apps up for free. ergo, the
> statement
>
>  "Apple's walled garden is not a fertile pasture for growing Free
> Software.  "
>
> ?? there are 10's of thousands of free apps in the app store. How is
> that an "unfertile pasture?"
>
> If your app has zero In-App purchases… it is really, really free.

As has been mentioned here many times before, any discussion of "free" 
with regard to the GPL uses the word in the sense of "libre". not "gratis".


The GPL expresses no opinion about price, but does grant the user 
specific freedoms.  Some of those freedoms are widely viewed as 
incompatible with Apple's app store TOS, which among other things limits 
the number of downloads per account.


With all the requests we see for a modestly-priced option for limited 
proprietary license allowing gratis software to be submitted to Apple's 
app store, it may be helpful to remember that LiveCode Ltd. offered 
exactly that not all that long ago.  Apparently it wasn't the big "this 
will put LiveCode on the map!" success hoped for or it'd still be available.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Robert Mann]

Mark, your words reflect 100% my position on that epic subject.

-- It seems to me a good thing to outline again and again, that any ruling
on such a license matter will "set the law" and will most probably override
any subsequent change in the license.

I do have a legal background, and we're all in the same boat : there are
some pieces of law that just apply. And in our field  copyright is the basic
block on which all licensing is built. If some ruling goes against the wish
of LC, we'll just have to do with it. And I do not find particularly healthy
and positive and worth quoting such thought as :
 
" …if that does happen then we will 
 immediately change the license of the community version of 
 LiveCode… "

The issue at stake is the freedom to write/create something with a "tool".
Can the maker of the tool impose some restrictions to the rights of the
writer/creator? How much? how far? how long?

So far the line seem to have been drawn in softwares with the inclusion test
: does the created work include part of another work? "Work" in our context
is something like a "piece of code that does something & and is original".  
And that does not seem to include the language tokens, nor the grammar that
governs its use.

This is directly derived from copyright law applicable to written materiel.
And the position in that field in France where I have been a publisher seems
clear : a word is not a work. A sentence can be in some circumstances, but a
work will have to be something constant and original. That is why the
language in itself will stay unprotected.

Since a script can be written on any code editor and text editor there is
little evidence to me that a script can be regarded as a derivative work, in
itself.

Requiring in the indie license that work published be created/drafted by the
license owner himself,
a) is kind of an evident ethical request. I assume that a vast majority of
indies do share that point (so do I!). And the advantage of relying on a
community here is that any commercial offering to do so will hopefully be
reported by the community and would not be welcomed even if that turned out
to be ruled legal.

b) but, that clearly indicates that LC considered seriously that LC script
could not be a derivative work.

c) and it is in practice just not enforceable proof wise, unless you team
with the NSA guys!!!
 
d) and such a  clause has little chance of surviving over here in France
since it would contradicts the very basic rights built in the copyright law
: a license between the indie and LC cannot restrict the rights of the
initial author to dispose of his intellectual work as he wishes. So far I am
acquainted with our french copyright law, that clause stands a high chance
to be declared just not applicable. Copyright law is a very high level law,
in france we call that "d'ordre public" : any contractual agreement that
goes against it is just read as being void, null. And the right of the
author to dispose of his work as he wishes is gold stone in the copyright
construction, (provided it is not derivated work of course!)

So as Mark points out, the assumption that this license is ok just because
it is in line with LC wishes, maybe a little bold and i'm sure LC can and
will find some elegant solutions as they always have done, coming up with
something new eventually!

hint : when the law does not cover you, there could be other ways. And to
take back the example of some school kids who get together and eventually
get an app to apple store (a kind of kid dream that I would not just kill
like that... hence my stepping in the debate here again!) There could be a
way to organize and actually help these rare cases by organizing a network
of "LC coding uncles and taties" that would help these kids, in good
understanding with LC in order to encourage theses wonderful things and
accompany and monitor theses adventures, rather than firing at them!

• Some of us have acquired an indie license that they might not use much, it
will not hurt the company if some of these guys that are in a good relation
with LC since many years, find a way to help the community like that and
become "LC code uncles or taties".
• Communicating over that would help reach attention of kids and schools,
which is a huge challenge for LC community.
• and comunicating over such successful adventures would even better promote
livecode where it should be promoted most : our kids.
• As I pointed out earlier in another much, much, much, debated thread,
there are also some other negative drawbacks in trying to over reach with
the derivative work claim : it creates a real mess concerning all medias
that can be referenced or included (like text from an author) into a script
file. And that mess, if not cleared out positively, will turn LC of little
use in the education field,  and that is not in the interest of the LC
community.

My 2 cents.

As Mark wrote it down the road what matters now is health of the livecode
ecosystem.
 

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Sannyasin Brahmanathaswami]

Hmm. still a lot of gray edges here.

but first  Peter wrote:

"- If the app is closed-source, this definitely violates the LiveCode 
Indy end user license agreement"

?

https://livecode.com/products/livecode-platform/pricing/

has a check mark next to "Protect your source code"

What are we missing there?

-

Re collaboration teams + making apps that go to Apple Store:

Please don't take this as argumentative… imagine we are sitting in peaceful 
garden just "talking story" as we say in Hawaii for about the long term growth 
of LiveCode… a mutually agreed upon objective:

The  issue must still be incredibly dense or fairly intelligent people like Kay 
and myself would not still be asking these questions

Apple does allow you to put up your apps up for free. ergo, the statement

 "Apple's walled garden is not a fertile pasture for growing Free Software.  "

?? there are 10's of thousands of free apps in the app store. How is that an 
"unfertile pasture?"

If your app has zero In-App purchases… it is really, really free.

 makes no sense … unless:

there is a difference between "Free Software" and "Free App."  

the concept of "business license"  is also mute, as there is zero revenue 
involved… nothing, zilch… the entire "enterprise runs in the red, by design… 
even the terms of the Indy license from this perspective are "non-sensical"

"For small businesses and startups with annual revenues up to $500K"   (as 
stated on your web site)

when a non-profit aka "class room full of students-- group of volunteers" 
obviously makes no money at all.

By allowing at least one parent to pony up for an Indy license… doesn’t that 
help LiveCode Company by $699.00?  Assuming the app distributed for free the 
question of "business" doesn't enter at any level. X number of those students 
will grow up, get inspired and once they have some earning power, by their own 
Indy license… wouldn't that be a good thing? 

I'm being an advocate here on Kay's behalf, because in fact all the people on 
our team but one, have an Indy license… so it's not as if I am "cheating" -- 
LiveCode is doing just fine with respect to our team…

 When I created  the Gurudeva.app, which I built myself, top to bottom with 
help from another developer who had an indy license. If I had a third developer 
with an Indy license… that's $699 X 3 = $2,100 revenue for LiveCode enterprise… 
even more than the business license. So obviously Edinborough Mother Ship can't 
be complaining if 2-10 different Indy developer's collaborate on a single app. 

But for the poor teacher: Your clarification answer's Kay's question with a big 
 "NO"  So her classroom  cannot generate code as a team and push it using a 
single Indy license for Apple. ergo LiveCode as a company is saying to them 
"You have to use some other tools for what you want to do… don't use LiveCode." 
  And there are lots of them out there now. HTML 5 IDE's and Cloud platforms 
are growing rapidly. It would be a simple matter for the teacher to say "Sorry 
guys, we can use LiveCode, because of Apple's policies, let's use XYZ instead." 

I don't see how that is a useful strategy. Sad…  Just because of Apple's policy 
you want me (or any indy owner) to stop being advocates of LiveCode? 

I have turned on quite a few new users to LC this past year since community 
came out… So if one of them sends me a really super ugly prototype stack with 
no code other than "go next, go previous"  but their UX is brilliant… you're 
saying I can't clone a card from the stack, refine the UI and revise it for an 
app that we might push to the Apple store?  Again, I don't mean to be 
argumentative… my interest is for LiveCode's long term growth potential. 

Also if the "widgets" text stacks/ LCB thing thing takes off, there could be 
(hopefully!) thousands of "plug-ins" any number of which may have been created, 
tested run from a community version, that an Indy author might add to his app 
that goes into the Apple store.  How does that work? 

Again, not being critical/argumentative at all, just feeling Apple Thorn in the 
side and wondering if LiveCode's long term interests are best served by 
allowing Apple's rules become the ruling mandate for LiveCode spreading… the 
recent survey of popular language on GitHub… Livecode doesn't even appear.  To 
make LiveCode as ubiquitous as Javascript (Kevin's declared goal some years 
back in an interview, of seeing it as one of the top 10 languages used in the 
world…

 I don't think we want teachers in any context telling students "We can't use 
it because of Apples rules" 


BR
 

On 7/20/16, 11:54 AM, "use-livecode on behalf of Peter TB Brett" 
 
wrote:

On 20/07/2016 20:53, Sannyasin Brahmanathaswami wrote:
>Kay C Lan wrote:
>
>" Fortunately one of the parents is extremely supportive and is happy
>to pony up for an LC Indy License. Is it kosher that this app, built
>by multiple people using Community, is now licensed by a single Indy

Re: [ANN] Updates to LiveCode's platform support policy

[Stephen MacLean]

> On Jul 21, 2016, at 2:03 PM, Peter TB Brett  wrote:
> 
> On 21/07/2016 15:08, Colin Holgate wrote:
> 
>> 2. It could be worth changing the title to OS X / macOS, and
>> including version 10.12 in the list. I know that it’s not released,
>> but it is in public beta, and I’m pretty sure you intend to support
>> it. LiveCode seems to be running well in 10.12.
>> 
>> As far as I can tell LiveCode apps run under iOS 10 ok too, which
>> again is not released, but would there be any harm in stating now
>> that you intend to support it?
> 
> Thank you for bringing it up, since clearly some clarification is needed!
> 
> We do not currently intend to officially support beta releases of Mac OS
> or Mac OS X or iOS.  When I say this, I mean that we would like to know
> if there are any problems, and we will certainly investigate
> problems promptly; however, beta and/or preview releases are not included in 
> the list of tests that must pass in order to release LiveCode, and we can't 
> commit to providing technical support if you run into problems.
> 
> LiveCode might well run fine on these preview releases!  However, until Apple 
> releases a version of Mac OS 10.12 to general availability, using LiveCode on 
> it will not be officially supported.  Realistically, we need time to get our 
> systems and staff up to speed!
> 
> I can happily state that we intend to extend official support to any new 
> stable releases of OS X / Mac OS / iOS that Apple come out with.  So, since 
> 10.12 stable isn't out yet, it's not yet supported.  I will clarify the text 
> in the blog post.
> 
> Note that Ubuntu Linux 16.10 alpha, and Fedora Linux "Rawhide", and Debian 
> Unstable, and Android N previews and Windows  are all 
> _also_ not officially supported.  But LiveCode, and apps made with it, may 
> very well work perfectly on any or all of them!
> 
> I hope that clarifies the situation.  Please let me know if you have any 
> further questions or concerns.
> 
>Peter

While I understand why you might want to limit support to “released” OSes, I 
would say that LC needs to checking against each “early” release, looking for 
issues and checking for new features that might be supported. LC should take 
bug reports against these early releases and, while maybe not acting right away 
on them, making sure that as they approach release status, those bugs get fixed.

As a development tool it is imperative that LC be ready for a new OS release. 
If there is a change that breaks a LC app with a new OS release, it is 
imperative that LC be updated and ready to go so the developer can release an 
updated app on day one. Having to wait weeks or longer to update your LC app 
after the “Official” release of an OS makes the developer and their app look 
bad at best.

Both Apple and Microsoft (and any linux tools I’m sure) make sure that their 
tools support these early releases so that developers can keep their apps 
updated and ready as well as take advantage of any new features and technology 
that they are adding. By NOT keeping LC updated in the same fashion, LC becomes 
a second class citizen and choice for development.

I really can’t stress this enough. Use VM’s, don’t mess with your production 
systems, but have LC ready for whatever NEW OS that LC supports when it comes 
out. 

Best,

Steve MacLean



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backspace unrecoverably deletes an object ....

[Monte Goulding]

No. We aren't building 7 any more and also this issue is probably not the same 
as in 7.

Sent from my iPhone

> On 22 Jul 2016, at 6:50 AM, Mark Wieder  wrote:
> 
> Will that get merged as a bugfix into the 7.1.x branch or is that branch
> just officially dead?


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backspace unrecoverably deletes an object ....

[panagiotis merakos]

Both the 6.7.x and the 7.1.x versionsof LC are officially EOLed. The fix
will be included in 8.0.2 RC4 and then merged into 8.0.3 RC1 and 8.1.0 DP3

On Thu, Jul 21, 2016 at 11:50 PM, Mark Wieder 
wrote:

> panagiotis merakos  writes:
>
> > You can find more info here:
> >
> > http://quality.livecode.com/show_bug.cgi?id=17953
>
> Will that get merged as a bugfix into the 7.1.x branch or is that branch
> just officially dead?
>
> --
>  Mark Wieder
>  ahsoftw...@gmail.com
>
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backspace unrecoverably deletes an object ....

[Mark Wieder]

panagiotis merakos  writes:

> You can find more info here:
> 
> http://quality.livecode.com/show_bug.cgi?id=17953

Will that get merged as a bugfix into the 7.1.x branch or is that branch
just officially dead?

-- 
 Mark Wieder
 ahsoftw...@gmail.com




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Mark Wilcox]

So the important clause is this one:

b) The ability to create and distribute Created Software is intended for
You to use with applications You have created or been substantially
involved in developing. You are prohibited from using the Licensed
Edition to build standalone applications for others where You are not
the author of the application, or confer on others the ability to build
standalone applications by any means whatsoever. For the avoidance of
doubt, You may not use the Licensed Edition to create or distribute
Created Software for other users who are using the Community Edition of
LiveCode. This clause is intended to prevent You from providing any
facility or service which would reduce or eliminate the requirement for
other LiveCode users, including users of the Community Edition, to
purchase a Licensed Edition to distribute their own Created Software.

My interpretation (not professional legal advice) is that if you have a
commercial license and you decide to build an open source app released
under the GPL, such that community edition users can use the code if
they want, then you could take patches from community edition users and
as long as they assign copyright you can still release the app on the
App Store.  The reverse situation, where a community edition user has a
GPL app and you as a commercial license holder submit a patch, then
offer to take a non-GPL copyright license (or ownership of the
copyright) and publish on the App Store is clearly not allowed. Anything
in between seems like a grey area and would need clarifying with HQ.

I'm not interested in finding GPL loopholes but rather the health of the
LiveCode ecosystem and removing FUD from open source licensing in
general. My concern around LiveCode over-reaching with their derivative
work claims (which are significantly stronger than those made by
WordPress and Drupal) is that what constitutes a derivative work under
copyright law is not in any way altered by the license applied. So, if
the original code in an app written by a community edition user is
judged not to be a derivative work, then there is nothing that can be
altered in the license to fix that "loophole" in LiveCode's intended
licensing scheme. Having the investment of a lifetime license, I'm not
keen to see LiveCode basing part of their business model on a very
dubious interpretation of copyright law, which also restricts the useful
sharing of code between community edition users and commercial license
holders.

I'd really hope to see a more enlightened policy here. It's much like
the question of trying to prevent app piracy. There's no point. The
people who would pirate were never going to pay anyway. Give people good
reasons to do the right thing and pay, rather than try to scare them
into doing so with GPL-related FUD.

-- 
  Mark Wilcox
  m...@sorcery-ltd.co.uk



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backspace unrecoverably deletes an object ....

[panagiotis merakos]

You can find more info here:

http://quality.livecode.com/show_bug.cgi?id=17953

Best,
Panos
--

On Thu, Jul 21, 2016 at 9:59 PM, Scott Rossi  wrote:

> I haven't paid close attention to this thread -- has anybody determined
> what actions trigger the non-responsiveness? I seem to be dealing with
> this exact issue in 7.1.4.  Do a couple of updates in the stack, the
> window becomes unresponsive.  Drag the window a few pixels or click in the
> menubar, and controls become responsive again.
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
>
>
>
>
> On 7/21/16, 11:46 AM, "use-livecode on behalf of Mark Talluto"
>  m...@canelasoftware.com> wrote:
>
> >> On Jul 21, 2016, at 11:25 AM, Mike Kerner 
> >>wrote:
> >>
> >> I'll be happy to get the unresponsive window regression resolved :-)
> >>
> >> On Wed, Jul 20, 2016 at 6:44 PM, Monte Goulding 
> >>wrote:
> >>
> >>> Yes it does
> >>>
> >>> Sent from my iPhone
> >>>
>  On 21 Jul 2016, at 8:36 AM, Devin Asay  wrote:
> 
>  Do you know whether that regression shows up in 8.1.0 dp2?
> >>>
> >
> >I have learned that if you move the unresponsive window a little by its
> >title bar, it responds again. Clearly this bug needs to be fixed, but
> >this is the workaround I am using in development. Will have to wait for
> >the bug to be fixed before shipping anything.
> >
> >Best regards,
> >
> >Mark Talluto
> >livecloud.io
> >canelasoftware.com
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backspace unrecoverably deletes an object ....

[Scott Rossi]

I haven't paid close attention to this thread -- has anybody determined
what actions trigger the non-responsiveness? I seem to be dealing with
this exact issue in 7.1.4.  Do a couple of updates in the stack, the
window becomes unresponsive.  Drag the window a few pixels or click in the
menubar, and controls become responsive again.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 7/21/16, 11:46 AM, "use-livecode on behalf of Mark Talluto"
 wrote:

>> On Jul 21, 2016, at 11:25 AM, Mike Kerner 
>>wrote:
>> 
>> I'll be happy to get the unresponsive window regression resolved :-)
>> 
>> On Wed, Jul 20, 2016 at 6:44 PM, Monte Goulding 
>>wrote:
>> 
>>> Yes it does
>>> 
>>> Sent from my iPhone
>>> 
 On 21 Jul 2016, at 8:36 AM, Devin Asay  wrote:
 
 Do you know whether that regression shows up in 8.1.0 dp2?
>>> 
>
>I have learned that if you move the unresponsive window a little by its
>title bar, it responds again. Clearly this bug needs to be fixed, but
>this is the workaround I am using in development. Will have to wait for
>the bug to be fixed before shipping anything.
>
>Best regards,
>
>Mark Talluto
>livecloud.io
>canelasoftware.com



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backspace unrecoverably deletes an object ....

[Mark Talluto]

> On Jul 21, 2016, at 11:25 AM, Mike Kerner  wrote:
> 
> I'll be happy to get the unresponsive window regression resolved :-)
> 
> On Wed, Jul 20, 2016 at 6:44 PM, Monte Goulding  wrote:
> 
>> Yes it does
>> 
>> Sent from my iPhone
>> 
>>> On 21 Jul 2016, at 8:36 AM, Devin Asay  wrote:
>>> 
>>> Do you know whether that regression shows up in 8.1.0 dp2?
>> 

I have learned that if you move the unresponsive window a little by its title 
bar, it responds again. Clearly this bug needs to be fixed, but this is the 
workaround I am using in development. Will have to wait for the bug to be fixed 
before shipping anything.

Best regards,

Mark Talluto
livecloud.io
canelasoftware.com




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backspace unrecoverably deletes an object ....

[Mike Kerner]

I'll be happy to get the unresponsive window regression resolved :-)

On Wed, Jul 20, 2016 at 6:44 PM, Monte Goulding  wrote:

> Yes it does
>
> Sent from my iPhone
>
> > On 21 Jul 2016, at 8:36 AM, Devin Asay  wrote:
> >
> > Do you know whether that regression shows up in 8.1.0 dp2?
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: [ANN] Updates to LiveCode's platform support policy

[Peter TB Brett]

On 21/07/2016 15:08, Colin Holgate wrote:

A couple of comments about the OS X entry:

1. The description is unnecessarily political. Under linux you take
the time to explain the support for several different version of
Linux, all of which added together are not as popular as Mac OS.
Under OS X you’re almost apologizing for taking away support time for
other platforms.


It was very difficult to decide which of the many, many, many versions 
and variants of Linux to which to extend official support.  Some 
justification for that choice was required.


It was dead easy to choose which versions of MacOS to support: the ones 
that Apple themselves support.


Peter

--
Dr Peter Brett 
LiveCode Technical Project Manager

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: [ANN] Updates to LiveCode's platform support policy

[Peter TB Brett]

On 21/07/2016 15:08, Colin Holgate wrote:


2. It could be worth changing the title to OS X / macOS, and
including version 10.12 in the list. I know that it’s not released,
but it is in public beta, and I’m pretty sure you intend to support
it. LiveCode seems to be running well in 10.12.

As far as I can tell LiveCode apps run under iOS 10 ok too, which
again is not released, but would there be any harm in stating now
that you intend to support it?


Thank you for bringing it up, since clearly some clarification is needed!

We do not currently intend to officially support beta releases of Mac OS
or Mac OS X or iOS.  When I say this, I mean that we would like to know
if there are any problems, and we will certainly investigate
problems promptly; however, beta and/or preview releases are not 
included in the list of tests that must pass in order to release 
LiveCode, and we can't commit to providing technical support if you run 
into problems.


LiveCode might well run fine on these preview releases!  However, until 
Apple releases a version of Mac OS 10.12 to general availability, using 
LiveCode on it will not be officially supported.  Realistically, we need 
time to get our systems and staff up to speed!


I can happily state that we intend to extend official support to any new 
stable releases of OS X / Mac OS / iOS that Apple come out with.  So, 
since 10.12 stable isn't out yet, it's not yet supported.  I will 
clarify the text in the blog post.


Note that Ubuntu Linux 16.10 alpha, and Fedora Linux "Rawhide", and 
Debian Unstable, and Android N previews and Windows  
are all _also_ not officially supported.  But LiveCode, and apps made 
with it, may very well work perfectly on any or all of them!


I hope that clarifies the situation.  Please let me know if you have any 
further questions or concerns.


Peter

--
Dr Peter Brett 
LiveCode Technical Project Manager

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Flipping Graphics

[Richard Gaskin]

Richmond wrote:

> Hi, Klaus: I am well aware what the dictionary states.
>
> However, as there seems  a way to flip graphics within the menu
> system . . .

Everything in the LC IDE is written in LiveCode, and all of its scripts 
are available to learn from.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Flipping Graphics

[Richmond]

On 21.07.2016 19:48, Mike Bonner wrote:

DOH, or use the menu.

No? Really? Surely not?

I have a pupil who is trying to make a 'shooter' game featuring a 
rectangular graphic in which
he keeps changing the backPattern to get an animation effect, and a 
wiggly line graphic along

which his "bullets" move: both of which are in a group.

He cannot flip the group; but he'd like to be able to flip the bullet 
trajectory everytime the end-user
send the animated figure in the "other direction" so he doesn't shoot in 
the wrong direction.


I asked him why he didn't just duplicate the trajectory graphic and flip 
it initially . . . ah the joys

of asking questions of that sort of a 15 year old.

Richmond.


On Thu, Jul 21, 2016 at 10:46 AM, Mike Bonner  wrote:


"flip" is a built in that only works on images.  When the ide flips a
graphic, it uses the preceeding code.
Of course if you're only doing this in the ide you could use the message
box and call revideflipgraphics directly.

On Thu, Jul 21, 2016 at 10:45 AM, Richmond 
wrote:


Hi, Klaus: I am well aware what the dictionary states.

However, as there seems  a way to flip graphics within the menu system .
. .

Richmond.



On 21.07.2016 19:39, Klaus major-k wrote:


Hi Richmond,

Am 21.07.2016 um 18:36 schrieb Richmond :

As it is possible to *flip* a *graphic* via the *revMenubar*:
Menu/Object/Flip Graphic why does it not
appear to be possible to *flip* using code:

on mouseUp
   flip grc "XXX" horizontally
end mouseUp
?


as the dicitonary states, "flip" only works with images.

Richmond.
Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Flipping Graphics

[Richmond]

Thanks: I have just looked at that.

Richmond.


On 21.07.2016 19:45, Mike Bonner wrote:

Here is code in the ide that flips graphics, you can probably use it to
make your own version and stuff it in a library.

on revIDEFlipGraphics pGraphics, pOrientation
# Make sure targets are all graphics
if not revIDEEnsureControlsOfType(pGraphics, "graphic") then
   exit revIDEFlipGraphics
end if

repeat for each line tGraphic in pGraphics
   local tPoints, tNewPoints
   put the points of tGraphic into tPoints

   if pOrientation is "Horizontal" then
  ## 2014-08-20 EJB [[Bug 13191]]
  --flip graphic horizontally
  local tLeft, tRight
  put the left of tGraphic into tLeft
  put the right of tGraphic into tRight

  repeat for each line tPoint in tPoints
 -- added BN in case a line is empty
 if tPoint is empty then
put cr after tNewPoints
next repeat
 end if

 put tLeft + tRight - item 1 of tPoint, item 2 of tPoint & cr
after tNewPoints
  end repeat
   else
  --flip graphic vertically
  local tTop, tBottom
  put the top of tGraphic into tTop
  put the bottom of tGraphic into tBottom
  repeat for each line tPoint in tPoints
 -- added BN in case a line is empty
 if tPoint is empty then
put cr after tNewPoints
next repeat
 end if

 put item 1 of tPoint, tTop + tBottom - item 2 of tPoint & cr
after tNewPoints
  end repeat
   end if
   set the points of tGraphic to tNewPoints
end repeat
end revIDEFlipGraphics

On Thu, Jul 21, 2016 at 10:39 AM, Klaus major-k  wrote:


Hi Richmond,


Am 21.07.2016 um 18:36 schrieb Richmond :

As it is possible to *flip* a *graphic* via the *revMenubar*:

Menu/Object/Flip Graphic why does it not

appear to be possible to *flip* using code:

on mouseUp
  flip grc "XXX" horizontally
end mouseUp
?

as the dicitonary states, "flip" only works with images.


Richmond.

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Flipping Graphics

[Klaus major-k]

Hi Richmond,

> Am 21.07.2016 um 18:45 schrieb Richmond :
> 
> Hi, Klaus: I am well aware what the dictionary states.
> 
> However, as there seems  a way to flip graphics within the menu system . . .

yes, sorry, my fault!
What Mike wrote! :-)

> Richmond.
> 
> 
> On 21.07.2016 19:39, Klaus major-k wrote:
>> Hi Richmond,
>> 
>>> Am 21.07.2016 um 18:36 schrieb Richmond :
>>> 
>>> As it is possible to *flip* a *graphic* via the *revMenubar*: 
>>> Menu/Object/Flip Graphic why does it not
>>> appear to be possible to *flip* using code:
>>> 
>>> on mouseUp
>>>  flip grc "XXX" horizontally
>>> end mouseUp
>>> ?
>> as the dicitonary states, "flip" only works with images.
>> 
>>> Richmond.

Best

Klaus
--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Flipping Graphics

[Mike Bonner]

DOH, or use the menu.

On Thu, Jul 21, 2016 at 10:46 AM, Mike Bonner  wrote:

> "flip" is a built in that only works on images.  When the ide flips a
> graphic, it uses the preceeding code.
> Of course if you're only doing this in the ide you could use the message
> box and call revideflipgraphics directly.
>
> On Thu, Jul 21, 2016 at 10:45 AM, Richmond 
> wrote:
>
>> Hi, Klaus: I am well aware what the dictionary states.
>>
>> However, as there seems  a way to flip graphics within the menu system .
>> . .
>>
>> Richmond.
>>
>>
>>
>> On 21.07.2016 19:39, Klaus major-k wrote:
>>
>>> Hi Richmond,
>>>
>>> Am 21.07.2016 um 18:36 schrieb Richmond :

 As it is possible to *flip* a *graphic* via the *revMenubar*:
 Menu/Object/Flip Graphic why does it not
 appear to be possible to *flip* using code:

 on mouseUp
   flip grc "XXX" horizontally
 end mouseUp
 ?

>>> as the dicitonary states, "flip" only works with images.
>>>
>>> Richmond.

>>> Best
>>>
>>> Klaus
>>>
>>> --
>>> Klaus Major
>>> http://www.major-k.de
>>> kl...@major-k.de
>>>
>>>
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Flipping Graphics

[Mike Bonner]

"flip" is a built in that only works on images.  When the ide flips a
graphic, it uses the preceeding code.
Of course if you're only doing this in the ide you could use the message
box and call revideflipgraphics directly.

On Thu, Jul 21, 2016 at 10:45 AM, Richmond 
wrote:

> Hi, Klaus: I am well aware what the dictionary states.
>
> However, as there seems  a way to flip graphics within the menu system . .
> .
>
> Richmond.
>
>
>
> On 21.07.2016 19:39, Klaus major-k wrote:
>
>> Hi Richmond,
>>
>> Am 21.07.2016 um 18:36 schrieb Richmond :
>>>
>>> As it is possible to *flip* a *graphic* via the *revMenubar*:
>>> Menu/Object/Flip Graphic why does it not
>>> appear to be possible to *flip* using code:
>>>
>>> on mouseUp
>>>   flip grc "XXX" horizontally
>>> end mouseUp
>>> ?
>>>
>> as the dicitonary states, "flip" only works with images.
>>
>> Richmond.
>>>
>> Best
>>
>> Klaus
>>
>> --
>> Klaus Major
>> http://www.major-k.de
>> kl...@major-k.de
>>
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Flipping Graphics

[Richmond]

Hi, Klaus: I am well aware what the dictionary states.

However, as there seems  a way to flip graphics within the menu system . . .

Richmond.


On 21.07.2016 19:39, Klaus major-k wrote:

Hi Richmond,


Am 21.07.2016 um 18:36 schrieb Richmond :

As it is possible to *flip* a *graphic* via the *revMenubar*: Menu/Object/Flip 
Graphic why does it not
appear to be possible to *flip* using code:

on mouseUp
  flip grc "XXX" horizontally
end mouseUp
?

as the dicitonary states, "flip" only works with images.


Richmond.

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Flipping Graphics

[Mike Bonner]

Here is code in the ide that flips graphics, you can probably use it to
make your own version and stuff it in a library.

on revIDEFlipGraphics pGraphics, pOrientation
   # Make sure targets are all graphics
   if not revIDEEnsureControlsOfType(pGraphics, "graphic") then
  exit revIDEFlipGraphics
   end if

   repeat for each line tGraphic in pGraphics
  local tPoints, tNewPoints
  put the points of tGraphic into tPoints

  if pOrientation is "Horizontal" then
 ## 2014-08-20 EJB [[Bug 13191]]
 --flip graphic horizontally
 local tLeft, tRight
 put the left of tGraphic into tLeft
 put the right of tGraphic into tRight

 repeat for each line tPoint in tPoints
-- added BN in case a line is empty
if tPoint is empty then
   put cr after tNewPoints
   next repeat
end if

put tLeft + tRight - item 1 of tPoint, item 2 of tPoint & cr
after tNewPoints
 end repeat
  else
 --flip graphic vertically
 local tTop, tBottom
 put the top of tGraphic into tTop
 put the bottom of tGraphic into tBottom
 repeat for each line tPoint in tPoints
-- added BN in case a line is empty
if tPoint is empty then
   put cr after tNewPoints
   next repeat
end if

put item 1 of tPoint, tTop + tBottom - item 2 of tPoint & cr
after tNewPoints
 end repeat
  end if
  set the points of tGraphic to tNewPoints
   end repeat
end revIDEFlipGraphics

On Thu, Jul 21, 2016 at 10:39 AM, Klaus major-k  wrote:

> Hi Richmond,
>
> > Am 21.07.2016 um 18:36 schrieb Richmond :
> >
> > As it is possible to *flip* a *graphic* via the *revMenubar*:
> Menu/Object/Flip Graphic why does it not
> > appear to be possible to *flip* using code:
> >
> > on mouseUp
> >  flip grc "XXX" horizontally
> > end mouseUp
> > ?
>
> as the dicitonary states, "flip" only works with images.
>
> > Richmond.
>
> Best
>
> Klaus
>
> --
> Klaus Major
> http://www.major-k.de
> kl...@major-k.de
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Flipping Graphics

[Klaus major-k]

Hi Richmond,

> Am 21.07.2016 um 18:36 schrieb Richmond :
> 
> As it is possible to *flip* a *graphic* via the *revMenubar*: 
> Menu/Object/Flip Graphic why does it not
> appear to be possible to *flip* using code:
> 
> on mouseUp
>  flip grc "XXX" horizontally
> end mouseUp
> ?

as the dicitonary states, "flip" only works with images.

> Richmond.

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Flipping Graphics

[Richmond]

As it is possible to *flip* a *graphic* via the *revMenubar*: 
Menu/Object/Flip Graphic why does it not


appear to be possible to *flip* using code:


on mouseUp

  flip grc "XXX" horizontally

end mouseUp

?

Richmond.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: [ANN] Updates to LiveCode's platform support policy

[Richard Gaskin]

Colin Holgate wrote:

> 1. The description is unnecessarily political. Under linux you take
> the time to explain the support for several different version of
> Linux, all of which added together are not as popular as Mac OS.
> Under OS X you’re almost apologizing for taking away support time for
> other platforms.

I'm impressed by your sensitivity to the nuance there, but not 
surprised; you've always been among the more astute and considerate of us.


In this case, though, it may be a cultural thing:  Linux folks tend to 
have thick skins (well, except when they're arguing with other Linux 
folks), and generally accept the inherent complexity that comes with 
having so many distros to choose from.


While folks managing end-user-focused distros like Ubuntu or Mint tend 
to be picky about nomenclature and how it may affect the gestalt of the 
UX, you'll almost never see a developer running Kali or Qubes 
complaining that they weren't sufficiently catered to. :)


Like Roger, I didn't even notice it.


I'm not sure what this has to do with LC's support page, but it was 
interesting just the same:

>  http://9to5mac.com/2016/03/18/os-x-versus-linux-developers/

That Linux has earned enough of an audience for that to be even a 
question is noteworthy in itself.


But it's also worth noting that the survey only touches one side of the 
development workflow, the client.


Most development work these days is client-server, and like Apple 
themselves, with most devs the server side is usually Linux, sometimes 
Windows, and rarely Mac.


I had a good talk with a lead server engineer from Apple who had a booth 
at the SoCal Linux Expo looking for talent to help manage their 
ever-growing Linux installs, and Apple's investment in Linux to run so 
much of their backend infrastructure is impressive.



> 2. It could be worth changing the title to OS X / macOS, and
> including version 10.12 in the list.

Seconded.  Not only is it more au curant, but Apple's recent renaming 
back to a variant of its original name helps our humble language avoid a 
token change, since "macos" is the string constant returned with platform().


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: [ANN] Updates to LiveCode's platform support policy

[Richard Gaskin]

Roger Eller wrote:

> On Thu, Jul 21, 2016 at 7:09 AM, Peter TB Brett wrote:
>
>> Please read more this change on the LiveCode blog:
>> https://livecode.com/updated-platform-support-policy/
>>
> In Chrome on Yosemite, clicking OSX opens the Linux list.  OSX list
> will not open.  Works fine in Safari.

Thanks for reporting that.  FWIW it works well here on Chrome for Ubuntu.

This is an especially useful report for the readers of a list about a 
multi-platform development tool:


Those who do web development understand all too well that, despite using 
relatively limited APIs designed specifically for omni-platform 
interoperability and financed by some of the largest companies in 
history, inconsistencies between brands of browsers and versions of 
browsers and different OSes make for a tragically unpredictable world of 
development expense that not even the world's considerable investment in 
HTML5 as a common spec has yet eliminated.


Warts and all, compared to the best work of the world's biggest 
companies, LC looks pretty good, even more so when we compare the amount 
of financing for the respective teams.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Richard Gaskin]

Rick Harrison wrote:

> If student A wants to assign or sell student B all copyright rights
> for his work for let’s say $1.00 (which is consideration in the legal
> sense of then word.) then student B legally owns all copyright rights
> to that work.  It is treated as though it was a work for hire even
> though only $1.00 changed hands.

Transfer of copyright may not require a financial transaction.  Many 
open source projects use Contributor License Agreements to allow 
contributions while maintaining a single copyright holder:



The CLA for the LiveCode project is linked to from this "Contribute to 
LiveCode" page:




> Student B, who owns an Indy License, may then publish the work as
> if he had written the entire code, because he legally owns the whole
> work.
> Any revenue then obtained all accrues to student B.
>
> If the LiveCode Indy license does not allow this - at least for the
> U.S.A. then there is a problem with the LiveCode license.

I'm not a lawyer, but the restrictions on building for others seem 
geared to prevent build farms, where any number of people may attempt 
use the Community Edition to build a work and then one Indy licensee 
makes all their standalones for them for proprietary distribution - see 
section 3, "No Competition", here:



In my layman's reading this seems a reasonable restriction to prevent a 
single licensee from undermining the development of the platform by 
churning out proprietary works for people who have no proprietary license.


As with the questions about the GPL, if the current wording of either 
license later proves unenforceable that will be a very brief moment, 
since as Mark Waddingham noted during the last tediously lengthy 
discussion on licensing a few months ago:


I can say for certain that if that does happen then we will
immediately change the license of the community version of
LiveCode to that new iteration. As the computer world evolves
so fast, it really doesn't matter what source code is out
there in the wild under the current version as that source
will become obsolete in a relatively short space of time.



It may be possible to use loopholes in the current licenses against the 
intentions of the company, but personally I can't see spending my own 
time pursuing that.  I understand how expensive it is to produce a tool 
like this for so many platforms, and even though I can use the Community 
Edition for two of my biggest projects right now I'm still prepaid on my 
Indy license many years in advance because I would like the platform to 
continue providing the unique value it delivers for my business and 
those of my clients.


For myself (I do not offer legal advice for others), I especially 
appreciated this simple clarify from Mark's post linked to above:


   The fact of the matter is that it comes down to one of the following:

 1) If you are happy to buy into the ideal of the GPL and abide
by its terms then use the community edition.

 2) If not, buy a commercial edition.

I tend to follow that with all of my projects, whether LiveCode or 
Drupal or Wordpress or any others who hold a similar view of the GPL. 
After all, for most of LC's life there was no GPL option at all, so it's 
easy enough to ignore it whenever I prefer a project not to be bound to 
the GPL's terms and just keep using the proprietary edition as I've been 
doing for so many years.


The company's intentions seem reasonable to me, and both LiveCode Ltd. 
and the previous owner of the engine, MetaCard Corp., have been reliable 
business partners for nearly two decades.  In my own office I see no 
value in disrupting that, and much value in supporting it.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: [ANN] Updates to LiveCode's platform support policy

[Roger Eller]

There is political bias anytime the source of the info has "mac" in the
name of the website.  I think LiveCode was very thoughtful to detail their
reasons, and I didn't consider it a political apology at all.

~Roger


On Thu, Jul 21, 2016 at 10:08 AM, Colin Holgate 
wrote:

> A couple of comments about the OS X entry:
>
> 1. The description is unnecessarily political. Under linux you take the
> time to explain the support for several different version of Linux, all of
> which added together are not as popular as Mac OS. Under OS X you’re almost
> apologizing for taking away support time for other platforms.
>
> http://9to5mac.com/2016/03/18/os-x-versus-linux-developers/ <
> http://9to5mac.com/2016/03/18/os-x-versus-linux-developers/>
>
> 2. It could be worth changing the title to OS X / macOS, and including
> version 10.12 in the list. I know that it’s not released, but it is in
> public beta, and I’m pretty sure you intend to support it. LiveCode seems
> to be running well in 10.12.
>
> As far as I can tell LiveCode apps run under iOS 10 ok too, which again is
> not released, but would there be any harm in stating now that you intend to
> support it?
>
>
> > On Jul 21, 2016, at 7:09 AM, Peter TB Brett 
> wrote:
> >
> > Hi all,
> >
> > Today, we are announcing some changes to the list of
> officially-supported platforms, i.e. the platforms that we use to test
> LiveCode, and that you can normally expect our support team will be able to
> help you with.
> >
> > Please read more this change on the LiveCode blog:
> > https://livecode.com/updated-platform-support-policy/
> >
> >  Peter
> >
> > --
> > Dr Peter Brett 
> > LiveCode Technical Project Manager
> >
> > LiveCode 2016 Conference https://livecode.com/edinburgh-2016/
> >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: [ANN] Updates to LiveCode's platform support policy

[Colin Holgate]

A couple of comments about the OS X entry:

1. The description is unnecessarily political. Under linux you take the time to 
explain the support for several different version of Linux, all of which added 
together are not as popular as Mac OS. Under OS X you’re almost apologizing for 
taking away support time for other platforms.

http://9to5mac.com/2016/03/18/os-x-versus-linux-developers/ 


2. It could be worth changing the title to OS X / macOS, and including version 
10.12 in the list. I know that it’s not released, but it is in public beta, and 
I’m pretty sure you intend to support it. LiveCode seems to be running well in 
10.12.

As far as I can tell LiveCode apps run under iOS 10 ok too, which again is not 
released, but would there be any harm in stating now that you intend to support 
it?


> On Jul 21, 2016, at 7:09 AM, Peter TB Brett  wrote:
> 
> Hi all,
> 
> Today, we are announcing some changes to the list of officially-supported 
> platforms, i.e. the platforms that we use to test LiveCode, and that you can 
> normally expect our support team will be able to help you with.
> 
> Please read more this change on the LiveCode blog:
> https://livecode.com/updated-platform-support-policy/
> 
>  Peter
> 
> -- 
> Dr Peter Brett 
> LiveCode Technical Project Manager
> 
> LiveCode 2016 Conference https://livecode.com/edinburgh-2016/
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Mark Wilcox]

> If student A wants to assign or sell student B all copyright rights for
> his work
> for let’s say $1.00 (which is consideration in the legal sense of then
> word.)
> then student B legally owns all copyright rights to that work.  It is
> treated
> as though it 

Work for hire is a separate (although related) issue. I completely agree
that LiveCode cannot (with copyright law at least) prevent developers
doing work for hire using a community license only. Of course morally if
someone is making a living doing LiveCode contract development, then
they ought to have their own license but if they don't need to publish
their work themselves, the GPL doesn't place any restrictions on them.

The only reason copyright assignment is required in the collaborative
no-fee changing hands case with one license holder is because the GPL is
incompatible with the App Store EULA and so whoever has the LiveCode
license needs to own the copyright to the rest of the code to be able to
distribute on the App Store GPL-free.

-- 
  Mark Wilcox
  m...@sorcery-ltd.co.uk


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: [ANN] Updates to LiveCode's platform support policy

[Roger Eller]

In Chrome on Yosemite, clicking OSX opens the Linux list.  OSX list will
not open.  Works fine in Safari.

~Roger


On Thu, Jul 21, 2016 at 7:09 AM, Peter TB Brett 
wrote:

> Hi all,
>
> Today, we are announcing some changes to the list of officially-supported
> platforms, i.e. the platforms that we use to test LiveCode, and that you
> can normally expect our support team will be able to help you with.
>
> Please read more this change on the LiveCode blog:
> https://livecode.com/updated-platform-support-policy/
>
>   Peter
>
> --
> Dr Peter Brett 
> LiveCode Technical Project Manager
>
> LiveCode 2016 Conference https://livecode.com/edinburgh-2016/
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Rick Harrison]

Hi Mark,

If student A wants to assign or sell student B all copyright rights for his work
for let’s say $1.00 (which is consideration in the legal sense of then word.)
then student B legally owns all copyright rights to that work.  It is treated
as though it was a work for hire even though only $1.00 changed hands.

Student B, who owns an Indy License, may then publish the work as if
he had written the entire code, because he legally owns the whole work.
Any revenue then obtained all accrues to student B.

If the LiveCode Indy license does not allow this - at least for the U.S.A. then
there is a problem with the LiveCode license.

Just my 2 cents on this.  :-)

Rick

> On Jul 21, 2016, at 4:57 AM, Mark Wilcox  wrote:
> 
>> So If student A writes down some code on text wrangle and gives it to
>> student B who (thanks folks) have an indy license, that belongs to student B
>> and he can dispose of it as he wishes, open sourced or closed source.
> 
>> In that case it seems to me that it is just a case of confidence between the
>> group of happy co-contributers, co-thinkers.
> 
> If student A assigns his copyright in the code he has written to student
> B, and student B has an Indy license then student B can probably publish
> on the app store as long as he has written substantial portions of the
> whole app himself.
> 
> Student A might not be able to assign all of the copyright in his code
> to student B (because LiveCode claim it is a derivative work - although
> I doubt a judge/jury would agree with them, this has not been tested).
> However, any copyright LiveCode claim in the work is OK because student
> B already has a license for this anyway. So the GPL is not an issue in
> this.
> 
> The issue is the wording of the Indy license, which I was going to check
> but livecode.com seems to be down. I seem to remember there's an
> explicit clause against publishing the work of others, unless you've
> written substantial parts of it yourself.
> 
> Confidence between co-contributors has no legal basis here.
> 
> I continue to believe that despite the obvious struggles LiveCode is
> having getting enough licensing revenue, they're shooting themselves in
> the foot by trying to over-reach on claiming community users code is a
> derivative of the engine.
> 
> Mark
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

[ANN] Updates to LiveCode's platform support policy

[Peter TB Brett]

Hi all,

Today, we are announcing some changes to the list of 
officially-supported platforms, i.e. the platforms that we use to test 
LiveCode, and that you can normally expect our support team will be able 
to help you with.


Please read more this change on the LiveCode blog:
https://livecode.com/updated-platform-support-policy/

  Peter

--
Dr Peter Brett 
LiveCode Technical Project Manager

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Mark Wilcox]

> So If student A writes down some code on text wrangle and gives it to
> student B who (thanks folks) have an indy license, that belongs to student B
> and he can dispose of it as he wishes, open sourced or closed source.

> In that case it seems to me that it is just a case of confidence between the
> group of happy co-contributers, co-thinkers.

If student A assigns his copyright in the code he has written to student
B, and student B has an Indy license then student B can probably publish
on the app store as long as he has written substantial portions of the
whole app himself.

Student A might not be able to assign all of the copyright in his code
to student B (because LiveCode claim it is a derivative work - although
I doubt a judge/jury would agree with them, this has not been tested).
However, any copyright LiveCode claim in the work is OK because student
B already has a license for this anyway. So the GPL is not an issue in
this.

The issue is the wording of the Indy license, which I was going to check
but livecode.com seems to be down. I seem to remember there's an
explicit clause against publishing the work of others, unless you've
written substantial parts of it yourself.

Confidence between co-contributors has no legal basis here.

I continue to believe that despite the obvious struggles LiveCode is
having getting enough licensing revenue, they're shooting themselves in
the foot by trying to over-reach on claiming community users code is a
derivative of the engine.

Mark

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode