Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[JB]

I don’t know what is legal for sure but it seems to
me once the code was sold and then Livecode
made a commercial product using the code it
opens the door for others to use the code in a
similar fashion as Livecode since the sold the
code and the similar rights went with it.

What compiled code is allowed in a open
source project now?  Live code does not
go out of the way to help people add any
externals but they are allowed and Apple
could easily add certain parts as externals
and comply with the open source license.

Apple also had hyperCard and using code
that is similar would be legal.  Whatever
path they take Apple needs to simplify the
xCode interface.

John Balgenorth



> On Jul 22, 2016, at 8:04 PM, Dr. Hawkins  wrote:
> 
> On Fri, Jul 22, 2016 at 3:04 PM, JB  wrote:
> 
>> Around a year or so ago I read Apple was thinking
>> of making xCode open source.  If they do then it
>> seems like they could incorporate Livecode open
>> source to develope similar features in xCode.
>> 
> 
> If apple were to do that, it would be under a Free/BSD type license, not a
> viral/GPL type license.  Conversely, it wouldn't make any sense for
> livecode to use a non-viral license.
> 
> Xcode isn't the product; it's part of the support system, while livecode
> *is* the product.
> 
> 
> -- 
> Dr. Richard E. Hawkins, Esq.
> (702) 508-8462
> ___
> 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]

[Dr. Hawkins]

On Fri, Jul 22, 2016 at 3:04 PM, JB  wrote:

> Around a year or so ago I read Apple was thinking
> of making xCode open source.  If they do then it
> seems like they could incorporate Livecode open
> source to develope similar features in xCode.
>

If apple were to do that, it would be under a Free/BSD type license, not a
viral/GPL type license.  Conversely, it wouldn't make any sense for
livecode to use a non-viral license.

Xcode isn't the product; it's part of the support system, while livecode
*is* the product.


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: android sdk fyi

[Mark Schonewille]

Thanks Mike!
+1

Kind regards,

Mark Schonewille
http://economy-x-talk.com
https://www.facebook.com/marksch

Buy the most extensive book on the
LiveCode language:
http://livecodebeginner.economy-x-talk.com

Op 07-Jul-16 om 14:47 schreef Mike Bonner:

I recently started working with android again, and was having trouble
building successfully.  aapt.exe would crash every time.  If you happen to
run into this, go to the sdk manager and install the build tools 22.01,
then backup the aapt.exe in the most recent build tools (just in case) and
copy the aapt.exe from the 22.01 build tools in to replace it.

A version other than 22.01 might work, but during research of the problem I
ran across mention of that specific version. Unfortunately, I can't seem to
find it again, but hey, it worked!



___
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: UN-FullScreen a Stack?

[Paul Hibbert]

I doubt this is any use for what you need, but strangely, setting the 
liveResizing of the stack to false does exit fullscreen mode, although the 
stack grows in height by 22px!

Paul

> On Jul 22, 2016, at 3:35 PM, Scott Rossi  wrote:
> 
> I eventually figured out the stack's decorations were hidden behind the
> LiveCode toolbar (and the green button was changed to grey an OS version
> or two back).
> 
> But I'm still wondering if there's a command to exit the OS's fullscreen
> mode without making the menubar visible, like how most apps employ the
> escape key.
> 
> Thanks & Regards,
> 
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
> 
> 
> 
> 
> On 7/22/16, 3:16 PM, "use-livecode on behalf of Colin Holgate"
>  colinholg...@gmail.com> wrote:
> 
>> You mouse over the top of the screen, and the menu and titlebar will
>> appear. Then click the green button to come out of full screen mode. Same
>> thing works for all other Mac windows.
>> 
>>> On Jul 22, 2016, at 6:05 PM, Scott Rossi  wrote:
>>> 
>>> OK, on OS X 10.11 I decided to see what happens when maximizing a stack.
>>> The window went fullscreen and my script for repositioning controls
>>> works
>>> great, but now the display is stuck in fullscreen mode.  How do I get
>>> the
>>> view back to multi-window view?  Setting the width/height of the stack
>>> resizes the stack but leaves a black OS backdrop in place and the
>>> display
>>> remains set the fullscreen mode.  What's the command to un-fullscreen a
>>> stack?
>>> 
>>> Thanks & Regards,
>>> 
>>> Scott Rossi
>>> Creative Director
>>> Tactile Media, UX/UI Design
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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

copy/paste on mobile?

[Richard Gaskin]

The Dict says copy can be used with chunk expressions to copy text from 
a LiveCode field to the mobile OS clipboard, but I'm having no luck 
getting it to work.


Is that working for you folks, or is the Dictionary wrong?

--
 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: UN-FullScreen a Stack?

[Scott Rossi]

Thanks, good to know.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 7/22/16, 3:29 PM, "use-livecode on behalf of Monte Goulding"

wrote:

>Here it is http://quality.livecode.com/show_bug.cgi?id=16946
>
>Sent from my iPhone
>
>> On 23 Jul 2016, at 8:19 AM, Monte Goulding  wrote:
>> 
>> I have a bug report open about this. Apple decided to just change the
>>way windows worked in 10.11 and this has caused a number of issues we
>>need to resolve. For the moment you can't script a way out of fullscreen
>>mode so you need to use the widget again at the top of the screen.
>> 
>> Cheers
>> 
>> Monte
>> 
>> Sent from my iPhone
>> 
>>> On 23 Jul 2016, at 8:05 AM, Scott Rossi  wrote:
>>> 
>>> OK, on OS X 10.11 I decided to see what happens when maximizing a
>>>stack.
>>> The window went fullscreen and my script for repositioning controls
>>>works
>>> great, but now the display is stuck in fullscreen mode.  How do I get
>>>the
>>> view back to multi-window view?  Setting the width/height of the stack
>>> resizes the stack but leaves a black OS backdrop in place and the
>>>display
>>> remains set the fullscreen mode.  What's the command to un-fullscreen a
>>> stack?
>>> 
>>> Thanks & Regards,
>>> 
>>> Scott Rossi
>>> Creative Director
>>> Tactile Media, UX/UI Design
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>



___
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: UN-FullScreen a Stack?

[Scott Rossi]

I eventually figured out the stack's decorations were hidden behind the
LiveCode toolbar (and the green button was changed to grey an OS version
or two back).

But I'm still wondering if there's a command to exit the OS's fullscreen
mode without making the menubar visible, like how most apps employ the
escape key.

Thanks & Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 7/22/16, 3:16 PM, "use-livecode on behalf of Colin Holgate"
 wrote:

>You mouse over the top of the screen, and the menu and titlebar will
>appear. Then click the green button to come out of full screen mode. Same
>thing works for all other Mac windows.
>
>> On Jul 22, 2016, at 6:05 PM, Scott Rossi  wrote:
>> 
>> OK, on OS X 10.11 I decided to see what happens when maximizing a stack.
>> The window went fullscreen and my script for repositioning controls
>>works
>> great, but now the display is stuck in fullscreen mode.  How do I get
>>the
>> view back to multi-window view?  Setting the width/height of the stack
>> resizes the stack but leaves a black OS backdrop in place and the
>>display
>> remains set the fullscreen mode.  What's the command to un-fullscreen a
>> stack?
>> 
>> Thanks & Regards,
>> 
>> Scott Rossi
>> Creative Director
>> Tactile Media, UX/UI Design
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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: UN-FullScreen a Stack?

[Scott Rossi]

When the stack is maximized using the window decorations, setting the
fullscreen to false doesn't revert the stack back to its original
dimensions unless the fullScreen was enabled to begin with.  But manually
setting the stack's dimensions can resize/reposition it.

Thanks & Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 7/22/16, 3:16 PM, "use-livecode on behalf of Colin Holgate"
 wrote:

>You mouse over the top of the screen, and the menu and titlebar will
>appear. Then click the green button to come out of full screen mode. Same
>thing works for all other Mac windows.
>
>> On Jul 22, 2016, at 6:05 PM, Scott Rossi  wrote:
>> 
>> OK, on OS X 10.11 I decided to see what happens when maximizing a stack.
>> The window went fullscreen and my script for repositioning controls
>>works
>> great, but now the display is stuck in fullscreen mode.  How do I get
>>the
>> view back to multi-window view?  Setting the width/height of the stack
>> resizes the stack but leaves a black OS backdrop in place and the
>>display
>> remains set the fullscreen mode.  What's the command to un-fullscreen a
>> stack?
>> 
>> Thanks & Regards,
>> 
>> Scott Rossi
>> Creative Director
>> Tactile Media, UX/UI Design
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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: UN-FullScreen a Stack?

[Monte Goulding]

Here it is http://quality.livecode.com/show_bug.cgi?id=16946

Sent from my iPhone

> On 23 Jul 2016, at 8:19 AM, Monte Goulding  wrote:
> 
> I have a bug report open about this. Apple decided to just change the way 
> windows worked in 10.11 and this has caused a number of issues we need to 
> resolve. For the moment you can't script a way out of fullscreen mode so you 
> need to use the widget again at the top of the screen.
> 
> Cheers
> 
> Monte
> 
> Sent from my iPhone
> 
>> On 23 Jul 2016, at 8:05 AM, Scott Rossi  wrote:
>> 
>> OK, on OS X 10.11 I decided to see what happens when maximizing a stack.
>> The window went fullscreen and my script for repositioning controls works
>> great, but now the display is stuck in fullscreen mode.  How do I get the
>> view back to multi-window view?  Setting the width/height of the stack
>> resizes the stack but leaves a black OS backdrop in place and the display
>> remains set the fullscreen mode.  What's the command to un-fullscreen a
>> stack?
>> 
>> Thanks & Regards,
>> 
>> Scott Rossi
>> Creative Director
>> Tactile Media, UX/UI Design
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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: UN-FullScreen a Stack?

[Monte Goulding]

I have a bug report open about this. Apple decided to just change the way 
windows worked in 10.11 and this has caused a number of issues we need to 
resolve. For the moment you can't script a way out of fullscreen mode so you 
need to use the widget again at the top of the screen.

Cheers

Monte

Sent from my iPhone

> On 23 Jul 2016, at 8:05 AM, Scott Rossi  wrote:
> 
> OK, on OS X 10.11 I decided to see what happens when maximizing a stack.
> The window went fullscreen and my script for repositioning controls works
> great, but now the display is stuck in fullscreen mode.  How do I get the
> view back to multi-window view?  Setting the width/height of the stack
> resizes the stack but leaves a black OS backdrop in place and the display
> remains set the fullscreen mode.  What's the command to un-fullscreen a
> stack?
> 
> Thanks & Regards,
> 
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
> 
> 
> 
> 
> 
> 
> ___
> 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: UN-FullScreen a Stack?

[Colin Holgate]

You mouse over the top of the screen, and the menu and titlebar will appear. 
Then click the green button to come out of full screen mode. Same thing works 
for all other Mac windows.

> On Jul 22, 2016, at 6:05 PM, Scott Rossi  wrote:
> 
> OK, on OS X 10.11 I decided to see what happens when maximizing a stack.
> The window went fullscreen and my script for repositioning controls works
> great, but now the display is stuck in fullscreen mode.  How do I get the
> view back to multi-window view?  Setting the width/height of the stack
> resizes the stack but leaves a black OS backdrop in place and the display
> remains set the fullscreen mode.  What's the command to un-fullscreen a
> stack?
> 
> Thanks & Regards,
> 
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
> 
> 
> 
> 
> 
> 
> ___
> 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: UN-FullScreen a Stack?

[Devin Asay]

> On Jul 22, 2016, at 4:05 PM, Scott Rossi  wrote:
> 
> OK, on OS X 10.11 I decided to see what happens when maximizing a stack.
> The window went fullscreen and my script for repositioning controls works
> great, but now the display is stuck in fullscreen mode.  How do I get the
> view back to multi-window view?  Setting the width/height of the stack
> resizes the stack but leaves a black OS backdrop in place and the display
> remains set the fullscreen mode.  What's the command to un-fullscreen a
> stack?

set the fullscreen of this stack to false

Did that not work? (I’m still on 10.10.)

Devin


Devin Asay
Office of Digital Humanities
Brigham Young University

___
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

UN-FullScreen a Stack?

[Scott Rossi]

OK, on OS X 10.11 I decided to see what happens when maximizing a stack.
The window went fullscreen and my script for repositioning controls works
great, but now the display is stuck in fullscreen mode.  How do I get the
view back to multi-window view?  Setting the width/height of the stack
resizes the stack but leaves a black OS backdrop in place and the display
remains set the fullscreen mode.  What's the command to un-fullscreen a
stack?

Thanks & Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design






___
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]

[JB]

Around a year or so ago I read Apple was thinking
of making xCode open source.  If they do then it
seems like they could incorporate Livecode open
source to develope similar features in xCode.  With
their money, attorneys, and laws in different countries
they can pretty much use what they want.  They need
to simplify their interface whatever path they take.

John Balgenorth


> On Jul 22, 2016, at 10:32 AM, Kevin Miller  wrote:
> 
> Hi folks,
> 
> We do review our licensing from time to time and I will at some point look
> again at whether we can clarify this further or introduce changes that
> make it clearer to our end users. Iąm not a lawyer and until this stuff
> gets tested in court it seems hard to say what will and wonąt stand up.
> 
> A few comments on the statements below though. Firstly, the article Mark
> helpfully references is based on USA law. LiveCode is based in the UK.
> There isnąt the same concept of łfair use˛ over here, and various other
> aspects of copyright law are different. It would be hard to say that the
> statements in that article, if correct in the USA (and as I say they
> havenąt been tested) would apply here.
> 
> Secondly, LiveCode is very different from Wordpress. Stacks are executable
> binaries that incorporate aspects of the engine. That's even more the case
> now when they start to use and include widgets. There isnąt a good
> comparison with other text based languages. I personally doubt our script
> only components are GPL, but as Iąve said this hasnąt been tested in court
> and its not up to me.
> 
> GPL does not alter the copyright assignment of the work that you create.
> Nor does it kick in at all on work on your own machine, it only applies at
> the point you distribute. When it applies, it simply requires that your
> work be distributed with certain additional freedoms. That does not remove
> your copyright, it just adds some rights for other people. You can change
> that any time by buying a commercial license.
> 
> If all stacks were not GPL, then there would be far less need for
> standalones any more. Just build a commercial product and ship it, let the
> user install the IDE to run it. Maybe fork the source to add in password
> protection. That impact wouldnąt apply as quickly to iOS but it would take
> another chunk of our revenue away overnight on all other platforms. Which
> means less features for you, less bug fixes, less engineers and less
> progress on the platform. There are other ways to encourage commercial
> license use (e.g. by adding features) but we arenąt there yet to the
> extent we would need to be. Maybe when we get further down that path this
> sort of change might start to stack up economically. In the mean time it
> is surely in everyoneąs interests that we are strong and healthy.
> 
> Mark Iąm very happy to sit down with you (and anyone else) over a whisky
> and debate all of this. If we can find a clearer license that continues to
> bring in sufficient revenue for our core team to develop the platform and
> grows our community even better, Iąd be truly delighted. In order to have
> that debate, you would need to be more aware of the actual economics of
> our specific situation and that not something we can do on list. As yet I
> havenąt come up with a better license combination for where we are today
> and its not for lack of thought on the subject.
> 
> Kind regards,
> 
> Kevin
> 
> Kevin Miller ~ ke...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> 
> 
> 
> On 22/07/2016, 02:52, "use-livecode on behalf of Mark Wilcox"
>  m...@sorcery-ltd.co.uk> wrote:
> 
>> On Fri, Jul 22, 2016, at 03:38 AM, Richard Gaskin wrote:
>>> 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)?
>> 
>> OK, it's not wise to pull too hard on this thread, because LiveCode does
>> potentially have an issue with people distributing stackfiles
>> commercially, separate from a copy of the engine.
>> 
>> That said, several noteworthy points exist in this regard:
>> 1) First, the Software Freedom Law Centre - which tends to be rather
>>  biased in attempting to push copyright law interpretations in a way
>>  that strengthen's copyleft licenses - has only given an opinion on
>>  WordPress themes, not plugins. That analysis suggested that the PHP
>>  code in themes was essentially trivial, just calling a fixed set of
>>  APIs to enable the CSS and images to be used in the right places.
>>  It's debatable but not unreasonable to suggest that the PHP code in
>>  themes is subject to the GPL. The SFLC specifically said that the CSS
>>  and images were not subject to the GPL.
>> 
>> 2) A core WordPress contributor, Mark Jaquith, publicly stated at the
>>  time of the SFLC statement on themes that the same 

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

[[-hh]]

Being a naive user I created a new stack with LC 8.0.1
and scripted it:

on resizestack
  set rect of widget "browser" to the rect of this card
end resizestack

Then dragged the browser widget to the stack, pasted
http://livecode.com/updated-platform-support-policy/
into the URL-field

and everything works as a charme: *Responsive* page,
wonderful overview, I have'nt seen such a clear list before.





--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/ANN-Updates-to-LiveCode-s-platform-support-policy-tp4706840p4706900.html
Sent from the Revolution - User mailing list archive at Nabble.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

[Geoff Canyon]

On Thu, Jul 21, 2016 at 9:51 AM, Roger Eller 
wrote:

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

​For me on Safari, changing from one accordion entry to a lower one scrolls
up the content (because it's hiding the higher entry) meaning that the
opened  entry is off the top of the window. The accordion serves no purpose
other than to be potentially buggy or mess with the user, and the list
would be better as a simple page with sequential entries -- in other words
roughly what you would get if all the accordion entries were open at once.
___
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]

[Peter TB Brett]

On 22/07/2016 18:57, Mark Talluto wrote:



On Jul 22, 2016, at 9:07 AM, Peter TB Brett
 wrote:

If someone wants to try out LiveCode with a view to making
closed-source software, they can register for a free trial of
LiveCode Indy here: https://livecode.com/trial/


Very cool! This should go a long way to introducing the value of the
commercial versions of LiveCode.



Note that the trial includes _all_ the "added-value" features of 
LiveCode Indy, including all the mergExt externals, stack protection, 
device camera support, etc.


  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 Talluto]

> On Jul 22, 2016, at 9:07 AM, Peter TB Brett  wrote:
> 
> If someone wants to try out LiveCode with a view to making closed-source 
> software, they can register for a free trial of LiveCode Indy here: 
> https://livecode.com/trial/

Very cool! This should go a long way to introducing the value of the commercial 
versions of LiveCode.

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: Licensing AGAIN [was: Sharing FontLab Plugin]

[Sannyasin Brahmanathaswami]

@ kevin

Thanks for your careful attention to this. I am clearly out of my depth on 
licensing issues and have a naively, simplistic look at things.

I do want to go on record that I am and always will be "on your side"…. if I 
were the CFO of Livecode and looked at a graph 

A) community downloads next to 
B) the annual revenue stream for licensed editions

and if B <= (total operations budget, + reasonable compensation packages and 
party money for the team + funds for on-going development/innovation.)

Then obviously, we have a problem. 

Good luck with finding a solution where we can freely advocate for LiveCode 
adoption, in an ocean where commercial and free code swim together virtual 
indistinguishable for 75% of the developers (students, teachers hobbyists, team 
leaders), like me who have no clue about licenses and just "go to work to get 
things done."

What the solution is, I don’t know… but the current EULA clearly works against 
your stated goal (I recall that video interview) "make LiveCode one of the ten 
most popular languages in the world"

BR


 Kevin wrote:

 It was one of our longer 
meetings, in which we reviewed the specific examples Kay, 
Bramanathaswami, and others have presented.

___
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]

[Kevin Miller]

Hi folks,

We do review our licensing from time to time and I will at some point look
again at whether we can clarify this further or introduce changes that
make it clearer to our end users. I¹m not a lawyer and until this stuff
gets tested in court it seems hard to say what will and won¹t stand up.

A few comments on the statements below though. Firstly, the article Mark
helpfully references is based on USA law. LiveCode is based in the UK.
There isn¹t the same concept of ³fair use² over here, and various other
aspects of copyright law are different. It would be hard to say that the
statements in that article, if correct in the USA (and as I say they
haven¹t been tested) would apply here.

Secondly, LiveCode is very different from Wordpress. Stacks are executable
binaries that incorporate aspects of the engine. That's even more the case
now when they start to use and include widgets. There isn¹t a good
comparison with other text based languages. I personally doubt our script
only components are GPL, but as I¹ve said this hasn¹t been tested in court
and its not up to me.

GPL does not alter the copyright assignment of the work that you create.
Nor does it kick in at all on work on your own machine, it only applies at
the point you distribute. When it applies, it simply requires that your
work be distributed with certain additional freedoms. That does not remove
your copyright, it just adds some rights for other people. You can change
that any time by buying a commercial license.

If all stacks were not GPL, then there would be far less need for
standalones any more. Just build a commercial product and ship it, let the
user install the IDE to run it. Maybe fork the source to add in password
protection. That impact wouldn¹t apply as quickly to iOS but it would take
another chunk of our revenue away overnight on all other platforms. Which
means less features for you, less bug fixes, less engineers and less
progress on the platform. There are other ways to encourage commercial
license use (e.g. by adding features) but we aren¹t there yet to the
extent we would need to be. Maybe when we get further down that path this
sort of change might start to stack up economically. In the mean time it
is surely in everyone¹s interests that we are strong and healthy.

Mark I¹m very happy to sit down with you (and anyone else) over a whisky
and debate all of this. If we can find a clearer license that continues to
bring in sufficient revenue for our core team to develop the platform and
grows our community even better, I¹d be truly delighted. In order to have
that debate, you would need to be more aware of the actual economics of
our specific situation and that not something we can do on list. As yet I
haven¹t come up with a better license combination for where we are today
and its not for lack of thought on the subject.

Kind regards,

Kevin

Kevin Miller ~ ke...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps




On 22/07/2016, 02:52, "use-livecode on behalf of Mark Wilcox"
 wrote:

>On Fri, Jul 22, 2016, at 03:38 AM, Richard Gaskin wrote:
>> 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)?
> 
>OK, it's not wise to pull too hard on this thread, because LiveCode does
>potentially have an issue with people distributing stackfiles
>commercially, separate from a copy of the engine.
> 
>That said, several noteworthy points exist in this regard:
>1) First, the Software Freedom Law Centre - which tends to be rather
>   biased in attempting to push copyright law interpretations in a way
>   that strengthen's copyleft licenses - has only given an opinion on
>   WordPress themes, not plugins. That analysis suggested that the PHP
>   code in themes was essentially trivial, just calling a fixed set of
>   APIs to enable the CSS and images to be used in the right places.
>   It's debatable but not unreasonable to suggest that the PHP code in
>   themes is subject to the GPL. The SFLC specifically said that the CSS
>   and images were not subject to the GPL.
> 
>2) A core WordPress contributor, Mark Jaquith, publicly stated at the
>   time of the SFLC statement on themes that the same argument applied
>   to plugins as well. He has since reconsidered that opinion and isn't
>   so convinced about themes any more either (see his comment on this
>   blog:
>   
>https://enriquesthoughts.wordpress.com/2014/01/05/wordpress-is-gpl-must-yo
>ur-plugin-be-as-well/
>   - specifically:
>"Very well argued. My thinking on this matter has evolved since I wrote
>my post, 3+ years ago. The thing about the GPL is that it is a legal
>hack. For it to work, it relies on legal concepts like what constitutes
>a derivative work. And while some plugins could unambiguously be
>derivative works, I no 

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Robert Mann]

For the WE, you might find these links on the issue of applying copyright to
programming languages, informative :
Can Copyright Protect a Language?

  
Google beats Oracle—Android makes “fair use” of Java APIs

  
Programming language can't be copyrighted: EU court
  





--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/On-rev-support-problem-tp4706664p4706894.html
Sent from the Revolution - User mailing list archive at Nabble.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

Possible to use a mobile printer?

[Andrew Niemantsverdriet]

Is is possible for LiveCode to communicate with a bluetooth mobile printer
on Android? I have a Star Micronics SM-T300 Mobile Printer and would like
to use LiveCode to print to it but have no idea where to even begin.

Thanks,
 _
/-\ ndrew
___
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 -

Thank you for taking the time to write up your views on the distinctions 
between LiveCode Ltd's interpretation of the GPL and those of the 
Drupal, Wordpress, and Joomla projects.  I'm quoting it here in its 
entirety because I believe it's worth a second read; IMO it represents 
some of the most cogent thinking on the subject we've seen, well 
expressed in the spirit of fostering a healthy ecosystem for everyone.


There is one difference between LC and Drupal/Wordpress/Joomla which is 
inherent though, rather than interpretive:  LC is offered under dual 
license, while the others are not.


Of course that only affects the questions specific to mixing license 
types, but those seem to comprise the majority of this discussion here.


In this morning's Community meeting Peter and I spent the bulk of our 
time reviewing both sets of questions, those relating to GPL 
interpretation and those relating to possible mixing of the license 
types, and many other considerations as well.  It was one of our longer 
meetings, in which we reviewed the specific examples Kay, 
Bramanathaswami, and others have presented.


Peter, Kevin, Mark Waddingham, and the rest of the core team have the 
same goal as everyone here:  an earnest embracing of open source while 
also making sure the project remains sustainable for the benefit of both 
open source and proprietary developers alike.


They recognize that further guidance would be useful, but as a practical 
matter the conference planning is very much a key demand on their time 
right now, since we're just a couple weeks from kickoff of their biggest 
annual event.


So the plan at the moment is to review the use-cases presented in light 
of precedent established by other GPL-governed projects, and to provide 
guidance on how that applies to the position LC is in with its dual 
licensing, sometime soon after the conference.


This has been a useful discussion, touching on specifics that are 
important to all of us.  So far, in my own view I haven't seen anything 
that can't be resolved to everyone's satisfaction, so I'm hopeful that 
once the core team has the conference behind them we'll be in a good 
position to reach a set of guidelines that will be productive for all.


In the meantime, Mark Waddingham's earlier suggestion may suffice for now:

If your project's goal is to share source code the GPL-governed 
Community Edition can be a good choice, and for any other goals the 
proprietary license as we've always had is available as well.


If there's a pressing circumstance requiring immediate action with 
regard to licensing, please write to support AT livecode.com and they 
may be able to work out special licensing considerations for your 
use-case, as they've done with their EULA terms for developers facing 
unusual circumstances in the past.


--
 Richard Gaskin
 LiveCode Community Liaison
 rich...@livecode.org



Mark Wilcox wrote:


On Fri, Jul 22, 2016, at 03:38 AM, Richard Gaskin wrote:

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)?


OK, it's not wise to pull too hard on this thread, because LiveCode does
potentially have an issue with people distributing stackfiles
commercially, separate from a copy of the engine.

That said, several noteworthy points exist in this regard:
1) First, the Software Freedom Law Centre - which tends to be rather
   biased in attempting to push copyright law interpretations in a way
   that strengthen's copyleft licenses - has only given an opinion on
   WordPress themes, not plugins. That analysis suggested that the PHP
   code in themes was essentially trivial, just calling a fixed set of
   APIs to enable the CSS and images to be used in the right places.
   It's debatable but not unreasonable to suggest that the PHP code in
   themes is subject to the GPL. The SFLC specifically said that the CSS
   and images were not subject to the GPL.

2) A core WordPress contributor, Mark Jaquith, publicly stated at the
   time of the SFLC statement on themes that the same argument applied
   to plugins as well. He has since reconsidered that opinion and isn't
   so convinced about themes any more either (see his comment on this
   blog:
   
https://enriquesthoughts.wordpress.com/2014/01/05/wordpress-is-gpl-must-your-plugin-be-as-well/
   - specifically:
"Very well argued. My thinking on this matter has evolved since I wrote
my post, 3+ years ago. The thing about the GPL is that it is a legal
hack. For it to work, it relies on legal concepts like what constitutes
a derivative work. And while some plugins could unambiguously be
derivative works, I no longer think they must necessarily be so, and I
suspect the majority would not be considered derivative works (by a US
court, at least). Same goes with themes with the caveat that themes are
more likely to contain code lifted from WordPress, 

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Robert Mann]

I also don't see anything wrong with the GPL license being attached to LC
community.
i've although thought it was a great way to differentiate.

And i find absolutely right and positive that any standalone built with the
community version be under GPL, as far as the code is concerned.

But, having a little legal background, I never thought that LC would try and
extend GPL by an interpretation of GPL which is highly debatable, both
technically and on the ground of it.
a) to Script language, script files and stack files. 
b) to media content of a stack

So i double on that Mar Wilcox again : the issue is not on GPL & livecode
but on the interpretation/extrapolation and revendication that Livecode
seems to make on :
a) to Script language, script files and stack files. 
b) to media content of a stack

Choosing a basic minimalistic interpretation of GPL would 
-- make things fluid again eliminating all that fuss we (rightly) make here.
-- allow LC and all of us to communicate and do things with the education
community
-- give back freedom to use code in many ways
basically boost NRJ around!!! 

LC is totally in power on that point and can make the sky blue again in just
one little paragraph!
or keep it grayish for years and years and again, and again... 






--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/On-rev-support-problem-tp4706664p4706891.html
Sent from the Revolution - User mailing list archive at Nabble.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]

On Fri, Jul 22, 2016, at 04:53 PM, Rick Harrison wrote:
> Like I said, LC should consider creating their own license then.
> 
> After this little debate, I will never touch any GPL license ever
> in the future.  In fact, I now consider the community version
> of LC to be worthless.  I’ve always had an indy type license of 
> LC which I’m fine with.  I’m just now totally disappointed that 
> I can’t even suggest the community version to my friends to 
> try out since they wouldn’t be able to use any code generated 
> by it to be used in a later commercial product after they have 
> purchased an indy or business license.  What a waste.

I really don't think there's anything wrong with the GPL for this kind
of usage. The issue is with LiveCode (the company) and how they are
attempting to interpret its application to their code. To be honest I
very much doubt even the FSF and SFLC would support LiveCode's current
position.

___
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]

[Peter TB Brett]

On 22/07/2016 16:53, Rick Harrison wrote:


After this little debate, I will never touch any GPL license ever
in the future.  In fact, I now consider the community version
of LC to be worthless.  I’ve always had an indy type license of
LC which I’m fine with.  I’m just now totally disappointed that
I can’t even suggest the community version to my friends to
try out since they wouldn’t be able to use any code generated
by it to be used in a later commercial product after they have
purchased an indy or business license.  What a waste.


The whole point of the open source version of LiveCode is that it's for 
making open source apps.  I'm actually quite shocked that this seems to 
have come as a surprise to you.


We have clearly been doing something very wrong in our communication 
about the open source version of LiveCode, and for that I am very sorry.


Also, don't forget that open source and commercial are not necessarily 
conflicting things.  There are many commercial products that are also 
Free Software distributed with the GPL license -- take the software 
running on your home's Internet router, for example; it is almost 
certainly running Linux which is GPL software _and_ also a commercial 
product.


If someone wants to try out LiveCode with a view to making closed-source 
software, they can register for a free trial of LiveCode Indy here: 
https://livecode.com/trial/


 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]

[Richard Gaskin]

Rick Harrison wrote:

> If the GPL license is overly restrictive perhaps LC should consider
> releasing the community version under a license similar to that used
> by PostgreSQL, MIT, or create it’s own Community License.  Clearly
> what they are doing now is creating a mess that is causing confusion
> in the marketplace for them.

Very desirable indeed, and achievable as well if LiveCode had the level 
of support from their user base that PostgreSQL does:  Many (perhaps 
most) full-time salaries of programmers contributing to PostgreSQL are 
paid by other companies.


For example a friend who's a technical director at Heroku tells me they 
have two people on staff whose full-time job is to write code for 
PostgreSQL.  And there are many companies doing that, like Google's 
staff that contributes to Python, the teams at Apple, Google, and other 
big companies coding for WebKit, and many others.


If anyone here is in a position to pay a few salaries for full-time 
LiveCode engine developers then a more permissive license may well be 
achievable.


But at the moment we don't see quite that level of support, so like most 
companies that offer dual licenses (MySQL, ownCloud, etc.) the open 
source edition uses GPL to provide a clear distinction:


Those who embrace the spirit of proliferating software and contributing 
to the world's knowledge through sharing source code enjoy the GPL.  The 
freedoms expressed in the GPL are among  the reasons it remains one of 
the most popular open source licenses available.


For anyone whose goals are different, a different license is available, 
as it has been for decades.


This clarity tends to influence purchasing decisions, since those whose 
business model is based around the sale of proprietary work then share 
back with the core team to keep the LiveCode project going by purchasing 
licenses.


Perhaps as community contributions to the code base increase, once it 
reaches a substantial level that reduces the core team's considerable 
overhead they may be in a position to consider different licensing.


But at the moment, even with the ever-increasing community contributions 
we're beginning to see (kudos to all who've submitted pull requests for 
code and docs!), we're still quite some ways from making a material 
difference in operational costs.  We may get there, but it'll take time.



Here's an example of how more permissive licensing can kill a project 
that doesn't already have major companies covering payroll expense:


Appcellerator used to be available for both desktop and mobile, but over 
time they decided to focus on mobile only. Rather than kill off the 
desktop edition altogether, they released that source under MIT license, 
and a new org was created to maintain and enhance it.  The new toolkit 
was called TideSDK.


In this blog post one of the project leaders described how they got only 
$600 in donations for the entire year, covering only a day or so of one 
programmer's development time:

http://www.tidesdk.org/blog/2013/04/11/tidesdk-in-numbers/

Yes, it's 404.  The project died not long after that post was made.

This discussion is about a transition from TideSDK to a new team with a 
new version called TideKit:

http://stackoverflow.com/questions/24440371/is-tidesdk-defunct

...which is also now defunct:
https://news.ycombinator.com/item?id=9875553


Good software is expensive to make; great software very expensive.

Having looked around for years for another tool that offers high-level 
scripting with integrated GUI elements in the language that runs on as 
many platforms, I've come up empty.  No one else even dares to take on 
the expense.


Fortunately we have enough licensees of the proprietary editions to 
cover the expenses for everyone, and supplemented by the community 
through pull requeats and crowd-funding both camps get a great LiveCode: 
those who want to participate in the libre software movement have a 
Community Edition supporting that, and everyone else has proprietary 
editions as we've always had.


--
 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]

[Rick Harrison]

Hi Mark,

Like I said, LC should consider creating their own license then.

After this little debate, I will never touch any GPL license ever
in the future.  In fact, I now consider the community version
of LC to be worthless.  I’ve always had an indy type license of 
LC which I’m fine with.  I’m just now totally disappointed that 
I can’t even suggest the community version to my friends to 
try out since they wouldn’t be able to use any code generated 
by it to be used in a later commercial product after they have 
purchased an indy or business license.  What a waste.

I supported both the community version and the html5
kick starters.  I’m now very sorry to have supported them
as neither one has fulfilled what I felt were their intended
goals.  They are both useless to my friends, and for the
many others who wanted to make use of them.

Rick


> On Jul 22, 2016, at 10:54 AM, Mark Wilcox  wrote:
> 
> On Fri, Jul 22, 2016, at 03:10 PM, Rick Harrison wrote:
>> If the GPL license is overly restrictive perhaps LC should consider
>> releasing the
>> community version under a license similar to that used by PostgreSQL,
>> MIT,
>> or create it’s own Community License.  Clearly what they are doing now is
>> creating a mess that is causing confusion in the marketplace for them.
> 
> That would be fatal to LiveCode's business. No-one would need a
> commercial license if the engine was MIT licensed.
> 
> I don't actually have any problem with the GPL for a dual-licensing
> model. It's pretty tried and tested. Qt has been doing it for very many
> years and yet they have never tried to claim any copyright in their
> users software, they just insist that a program distributed with the GPL
> version of the Qt libraries is released under a GPL-compatible license.
> Developers working with the GPL version can create plugins for others
> and sell them commercially, the user of those plugins would need to get
> their own commercial license to make use of them in a closed source app.
> The Qt company folks view this as very positive activity in their
> ecosystem.
> 
> -- 
>  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


___
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]

Hi Kay! i'm "stunned" when I read this sentence :


> LiveCode the language, just like the AppleScript language, is 
> proprietary subject to license terms and conditions.

It would be helpful if you could precise your source, thanks
Is that an extract from the LC license? 

It would also be helpful if you could precise a little the consequences of
that sentence : what does it mean?
Does it mean that all Script Language scripts are in fact "owned" by LC?? So
is that a total negation of the copyright law?

*I double what I wrote a little above : to my knowledge in law, a language
is not copyrightable BY ESSENCE, *and I really do hope that that is not the
path that LC would try and make, because I personally totally disagree, on
the ground (ethically) and technically as the law stands.

The main reason for that strong line in copyrights is the notion of
generative capacity :
“It is the infinitely generative capacity of a language, the ability to
communicate new thoughts and ideas, that makes a set of sounds and
grammatical rules into a language,”
see:: the Klingon language case

  
and copyright on a language would hijack all created work.

*A language is regarded, and rightly to my view, as a tool for the mind to
process information.* And it has long been accepted for the good balance of
our societies, that tools maker cannot extend their ownership to goods
created by one's tools. And we're talking humanism here and I can feel I'm
not the only one around to be rather sensitive to these issues at some
point.

We all agree to pay for tools : hence the licensing policy of the indie and
commercial versions. The script language needs money for tools to make it
easier to build useful things.

But LC is not only a tool, it's a framework, to promote the use of the
script language : hence the move to the community edition on a parallel
basis to* spread the use of the script language.* The Script Language (and i
don't write the livecode language!) needs ENERGY from a group of users, just
like a language needs people to talk it.

-- The traditional balance and boundary between these 2 is about visibility
: close source or "open" sources, as "readable" by all. That was dead simple
and I thought quite operational from my user viewpoint.

-- Enforcing some kind of "open source" license along the community version
seemed a good move.

*BUT Letting the GPL hijack that simple world and turn it into a LEGAL
NIGHTMARE* looks to me a very bad move, as it just kills the ENERGY source
in people's mind : 

People will poor energy into it if they feel the're free to think freely and
do "ENOUGH THINGS" things freely with it. *And that discussion will reappear
every time some LC community user will ask himself the question : ok i've
invested some time, I like that, what can I do with that?*

So far LC mantra is (hope I get it right though… it's not so clear!)
-- you're free at your home
-- if you communicate outside your home, then super hyper hard GPL to all
content including text and media of a stack file that goes out of your home
-- and could even extend to : "and by the way the language you think as
common good, is in fact ours!"

The mere understanding of the consequences of GPL onto stack content will
already burn a lot of NRJ, and finally the awareness of consequences on
media will considerably restrict that practicability, that "ENOUGH THINGS"-
that matters.

*In particular, to my humble view, use of the community in the education
environment will stumble on that media GPL issue :* FSF strategy is
defendable in the precise domain of reusable code to avoid recoding the
wheel housands of time, but may not be applicable to all educative material
and medias. We're into different worlds. And that would be a big pain since
it is to my view again the main target of the community version, and *the
Script language community needs to spread in education, or die out*.

/[here in France NO geography teachers will EVER buy a livecode license to
output stacks for the kids at their spare time, let that be clear - i've
been a publisher of teaching media in France -- they MIGHT take that time on
a free Community Version if it is dead simple, and if we put some efforts
into that to reach over to them -- by the way, the french LC community just
closed, most active members where now retired teachers who steeped in at the
time they could freely distribute stacks to their classes, long ago!]/

So in practice, I do praise for *a much softer GPL interpretation* and a
good sound clarification and communication on the subject.

*That could actually boost Livecode along, or kill it!*









--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/On-rev-support-problem-tp4706664p4706886.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-livecode 

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Dr. Hawkins]

On Fri, Jul 22, 2016 at 7:10 AM, Rick Harrison 
wrote:

> If the GPL license is overly restrictive perhaps LC should consider
> releasing the
> community version under a license similar to that used by PostgreSQL, MIT,
> or create it’s own Community License.  Clearly what they are doing now is
> creating a mess that is causing confusion in the marketplace for them.
>

I think the GPL is a horrid choice, as it's incompatible with every other
license (except relabeled GPL).

A non-viral license, however, would be a horrible choice for livecode--or
any other company whose business is selling the code.

When you look at the projects that have free rather than viral open source
licenses and corporate "owners", you find things such as Darwin and Swift
that the parent needs to exist, but is "in support" of the actual product.
Apple needs such a language, and needs such a Unix under its Mac interface.

If LC was put under a free license, a competitor could pop up overnight
selling ZombieCode, with enhancements that it didn't share back to
LiveCode.  With a viral license, however, ZC has to stay under the same
license.  (A viral license that doesn't require revealing the code is
conceivably possible, but I've never seen one, and don't see the point in
one)


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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]

[Dr. Hawkins]

On Thu, Jul 21, 2016 at 9:57 PM, Kay C Lan  wrote:

> 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.
>

It's also important to understand that the the FSF's desire to interpret in
a certain way does not suggest that a court will do the same.

A fundamental rule of construction is that the author of a document has had
its chance to speak in writing a document, and the opinion of the author
carries no weight.  In fact, documents are construed *against* the drafting
party.

That is,your opinion, my opinion, and the janitor's opinion each carry more
weight than the FSF's.

As a separate manner, as an attorney, I would be *shocked* to find a court
agree with the claim that plain text code is a derivative work.  An object
or executable, certainly, but the form of the code was fixed by the time it
hit the typist's fingers. (as an aside, autocorrect might change that--just
a passing thought)

All of that said, I won't touch GPL code with a 10 foot code; I won't even
look at it.  If I accidentally download a community version of LC, I delete
it the moment I see that the icon is the wrong color.  As an attorney, I
think that any person or organization that owns or might own intellectual
property in the future that goes near GPL3 code is just plain reckless.

Almost 20 years ago, I wrote a mail merge function to control a word
processor or editor.  It danced circles around what MS word could do.  It
could have become part of LyX, but I wasn't willing to subject it to the
GPL.

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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]

On Fri, Jul 22, 2016, at 03:10 PM, Rick Harrison wrote:
> If the GPL license is overly restrictive perhaps LC should consider
> releasing the
> community version under a license similar to that used by PostgreSQL,
> MIT,
> or create it’s own Community License.  Clearly what they are doing now is
> creating a mess that is causing confusion in the marketplace for them.

That would be fatal to LiveCode's business. No-one would need a
commercial license if the engine was MIT licensed.

I don't actually have any problem with the GPL for a dual-licensing
model. It's pretty tried and tested. Qt has been doing it for very many
years and yet they have never tried to claim any copyright in their
users software, they just insist that a program distributed with the GPL
version of the Qt libraries is released under a GPL-compatible license.
Developers working with the GPL version can create plugins for others
and sell them commercially, the user of those plugins would need to get
their own commercial license to make use of them in a closed source app.
The Qt company folks view this as very positive activity in their
ecosystem.

-- 
  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: Licensing AGAIN [was: Sharing FontLab Plugin]

[Rick Harrison]

If the GPL license is overly restrictive perhaps LC should consider releasing 
the
community version under a license similar to that used by PostgreSQL, MIT,
or create it’s own Community License.  Clearly what they are doing now is
creating a mess that is causing confusion in the marketplace for them.

Just my 2 cents for the day.  ;-)

Rick


___
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]

Kay C Lan wrote:

...
>  wrote:
>> 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.

I don't think there's a bad guy here.  The Apple's TOS and the GPL are 
simply incompatible.


Just as it was possible to resolve the VLC situation by choosing a 
different license, it's also possible for Apple to choose to remove the 
download limits to bring it on par with Android.


The GPL predates the Apple app store by decades; it certainly wasn't 
written with the app store in mind.  Each org has its own reasons for 
preferring their terms as they've written them.  I believe they do so 
because they reflect the organization's goals, and not all orgs have the 
same goals.


Baking soda and vinegar are both useful things, each fine on its own. 
Just don't try to store them in the same container. :)



> 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.

What features of MPL or BSD interest you?

There are so many licenses that it may be quite a task to outline them 
all.  And the ROI for the effort would be minimal, since the only 
license relevant for the Community Edition is the GPL, and almost 
everyone using the proprietary Indy or Business Editions does so because 
they want a custom proprietary license, which can vary so broadly it 
would be beyond the achievable scope of such a document.


The most common middle ground is MIT, so if we were to draft such an 
outline that was both useful and achievable it may well include little 
more than the summary I posted here the other day:



Venturing beyond those may represent a significant effort, and one with 
diminishing returns.  For the very small number of developers using the 
proprietary editions and who have specific reasons to want neither a 
custom proprietary license nor the MIT license, so many good 
descriptions of licenses exist across the Web that personally I'd be 
hard-pressed to decide which features I'd ask the team to set aside to 
replicate that documentation.  In my 20 years in this community I've 
seen only two such cases, and both found existing materials satisfying 
to help them make their license decision.


--
 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

[ANN] DatePicker for LiveCode LC8 update

[FlexibleLearning.com]

DatePicker for LiveCode

A free update has been released that is LC8 compatible. You can download
Build 33 from...

www.FlexibleLearning.com/datepicker


and see the What's New page here...

www.flexiblelearning.com/datepicker/versioning/whatsnew.htm


Note that DatePicker is not compatible with the free Community editions of
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]

On Fri, Jul 22, 2016, at 03:38 AM, Richard Gaskin wrote:
> 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)?
 
OK, it's not wise to pull too hard on this thread, because LiveCode does
potentially have an issue with people distributing stackfiles
commercially, separate from a copy of the engine.
 
That said, several noteworthy points exist in this regard:
1) First, the Software Freedom Law Centre - which tends to be rather
   biased in attempting to push copyright law interpretations in a way
   that strengthen's copyleft licenses - has only given an opinion on
   WordPress themes, not plugins. That analysis suggested that the PHP
   code in themes was essentially trivial, just calling a fixed set of
   APIs to enable the CSS and images to be used in the right places.
   It's debatable but not unreasonable to suggest that the PHP code in
   themes is subject to the GPL. The SFLC specifically said that the CSS
   and images were not subject to the GPL.
 
2) A core WordPress contributor, Mark Jaquith, publicly stated at the
   time of the SFLC statement on themes that the same argument applied
   to plugins as well. He has since reconsidered that opinion and isn't
   so convinced about themes any more either (see his comment on this
   blog:
   
https://enriquesthoughts.wordpress.com/2014/01/05/wordpress-is-gpl-must-your-plugin-be-as-well/
   - specifically:
"Very well argued. My thinking on this matter has evolved since I wrote
my post, 3+ years ago. The thing about the GPL is that it is a legal
hack. For it to work, it relies on legal concepts like what constitutes
a derivative work. And while some plugins could unambiguously be
derivative works, I no longer think they must necessarily be so, and I
suspect the majority would not be considered derivative works (by a US
court, at least). Same goes with themes with the caveat that themes are
more likely to contain code lifted from WordPress, so they might veer
towards derivation more often than plugins do."
Proprietary WordPress plugins are extremely common and largely
tolerated. Proprietary themes do still exist but are slightly more
frowned upon.
 
3) Drupal modules/plugins are frequently designed to modify the way that
   Drupal works. That does create some reasonable case for them being
   derivative works. The reality is probably that some Drupal plugins
   are derivative and some are not.
 
4) LiveCode is basically claiming that anything written in the language
   is derivative. There is no precedent for this anywhere. Also, large
   parts of the language itself are not really owned by LiveCode, it has
   been previously released under more permissive licenses. Effectively
   by creating a language, you create a new form of expressing creative
   works. It is almost certainly not possible to copyright everything
   expressed in a language. Add to this that the language is "English-
   like" and a lot of the time LiveCode are trying to claim copyright
   over English words... likely to be laughed out of court.
 
5) One of the most critical elements in a court's decision on whether or
   not any use of a copyrighted work is "fair use" is the degree of
   transformative nature of the work. The LiveCode engine is a general
   purpose runtime designed to execute arbitrary programs, on its own it
   doesn't "do" anything. The same broadly applies to any APIs it
   provides. It would be very easy to argue that creating almost any app
   that has a useful specific function is highly transformative of the
   engine code.
 
6) All is not lost for LiveCode in (5) because distributing a standalone
   would involve a direct copying of the entire engine, which would very
   likely override the transformative nature of the use in almost every
   conceivable case. However, the amount of LiveCode owned copyrightable
   material in a stackfile is likely very small and the amount in a script-
   only stack almost non-existent.
 
7) No-one can know the actual position for certain because this has
   never been tested in court.
 
>  > I'd really hope to see a more enlightened policy here
>
> Apparently some clarification would be useful.
 
Don't try to force the GPL on stackfiles created with the community
edition, only standalones. Encourage dual licensing or permissive
licensing. Allow the community edition users to create valuable code
that can also benefit commercial users. Even encourage them to dual
license and sell that without getting a commercial license (we're not
talking about a big market LiveCode would lose out on here). By all
means suggest that anyone building a successful business around this
practice should buy a license to support LiveCode but don't try to force
them to do so with GPL FUD.
 
Frankly, even with a commercial license, the idea that someone else
owns copyright over the essence of my own 

Re: Licensing AGAIN [was: Sharing FontLab Plugin]

[Kay C Lan]

On Fri, Jul 22, 2016 at 2:02 PM, Erik Beugelaar  wrote:
> 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.

I think a big problem for developers coming from another environment
is that they have become accustomed to using a language that is 'open'
or libre and very much inline with the FSF ideal of sharing the wheel
rather than reinventing it. The thought that the language itself is
propriety, not just the IDE you are using, is probably rather foreign.

You can not copyright an idea, only the implementation of that idea.
If your implementation method is libre, then all the credit is yours.
If your implementation method uses licensed material, then you are
bound by  the license. It may be your voice and your guitar, but if
you are singing Stairway to Heaven then copyright exists and royalties
may be due.

LiveCode the language, just like the AppleScript language, is
proprietary subject to license terms and conditions. If you get 100
people to write 3 different versions of a Hello World app, one in C,
one in LiveCode, and the last in AppleScript. Anyone familiar with all
3 will be able to accurately differentiate which is which - therefore
the uniqueness is unquestionable and a license holder would be able to
say 'hey that's mine, you haven't abided by the license agreement'. In
much the same way that those familiar with the band Spirit and their
song Taurus were able to claim that Stairway to Heaven was ripped off
by Led Zeppelin.

The license for use of the AppleScript language is fairly straight
forward and rather similar to the MIT license. Basically you simple
have to acknowledge that AppleScript is a product of Apple, Apple is a
registered trademark, and Apple take no responsibility for the
functionality of whatever the AppleScript does. If you write a book
with a typewriter and include a snippet of AppleScript, the license
requires you include the above acknowledgement in your book. If you
have a website, the same thing. The license isn't restricted to just
apps you build.  I will happily admit that I've posted LC script
examples on this List that use the 'do . as applescript' that have
included snippets of AppleScript statements but have NOT posted the
legally required acknowledgement. This is wrong of me, by the letter
of the license if I post AppleScript code I should include the
acknowledgement. It doesn't matter if I think it's
hard/irrelevant/childish/illogical/inconsequential, I accepted the
license terms and conditions.

Any LC Business/Indy license holder whose app contains 'do  as
applescript' is legally required to include the Apple acknowledgement.

As for LC Community licenses and the adversity of the FSF to
proprietary software, I'm not sure of the compatibility of mixing
AppleScript with GPL v3. My impression is that the AppleScript License
in no way restricts the sharing or redistribution of code snippets, so
it should be compatible with GPL v3. Although history tells me that I
occasionally don't interpret the GPL in the same way as the FSF does
;-(

In the case of LC Community, the language is licensed under GPL v3 and
it's requirements are it's requirements. The idea may be yours, but if
you've used LiveCode the language to implement that idea, even if it's
pen on napkin, that implementation is subject to the GPL v3 license.
These may seem unfair/counterproductive/counterintuitive but it
doesn't matter, the license is what the license is, it's requirements
are what they are and you either agree to them and use LC, or you
don't.

I think a plain English License Guide would be helpful, not just to
those new to programming, OSS and LC Community, but also to seasoned
coders who may have come from a lifelong background of libre languages
where they may have never thought that the programming language itself
my come with license requirements.

AppleScript is a registered product of Apple. Apple is a registered
Trademark. ;-)

___
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 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