license issues (was mystery exception)
rjb at rz.uni-potsdam.de
Wed Mar 12 04:16:00 EST 2003
>Now think about this for a minute. If your standalone were unlocked,
>yes, someone might create a competing IDE. But even if they just
>used your standalone to create their own software, that is one less
>copy that Runtime would sell. You and I, as developers, are staking
>our future on this technology. We should *want* Runtime to guard
>their product, sell lots of copies, and have a huge customer base so
>they will survive to be there for us. Why would anyone pay for a
>developer copy when any old standalone with a message box was fully
>The script limitation is the one, single, sole, solitary, and only
>protection that Runtime has.
All true but how easy is it to use the engine of a standalone to
couple it with full development GUI to produce new products? Is
message box really fully functional in standalones? If so, I rather
have no message box than do limit. I also think that while
distributing an unlocked engine could lead to problems you describe,
it should be possible to couple the engine to a specific standalone,
for example by requiring the stacks in the standalone to pass the
license key with certain calls. Such an approach would allow us to
realize the unfullfilled promise of being able to distribute any!
MC/Rev-based standalone without it being crippled by this restriction.
And I agree with Alex that this should be clearly spelled out. I have
actually found about this restriction when producing a test version
of a standalone program (see below) -- after I paid for the license.
I was quite upset. Fortunately, that specific program was not the
only reason for me to buy the dev environment.
>There's also the issue of abstract versus reality. In the 16 or more
>years in which I have been writing x-talk scripts, I can honestly
>say I have never once needed an 11-line "value" function. I can't
>imagine the convoluted script that would require something like
>that. I can't even imagine a script where the syntax would work out.
>I suppose someone might want to plop a whole field's worth of script
>into a "do" command, but not only is that rarely necessary, there
>are ways to break the code up if it really is required. Only it
>hardly ever is. I've never needed a "do" statement that long.
>In practice, I think you will find the script limitation to be a
>completely minor inconvenience, worthy of almost no consideration at
>all, except as a great big chunk of insurance against the future for
>all of us.
Well, this may be true for most people but it can be a show stopper
for some. Consider a scientific application that involves modelling
or function fitting. I have written such a program some years ago
(sold as shareware) and would love to recreate it with MC/Rev (users
still ask for it but the old code stopped working with OS 8). It
requires users entering complex math functions that program matches
to the provided set of experimental data, calculating statistical fit
and producing graphical output. It would be trivial to run it through
"do", but the 10-line limit is a killer. The only alternative I see
is to write my own interpreter/compiler in MetaTalk but that ain't so
trivial and slows things down. Of course, another alternative is to
have each user buy their own copy of MC or Rev but that would be akin
to asking users of programs written in C to buy CodeWarrior (although
I am sure that MC/Rev folks would love it).
More information about the use-livecode