Thanks for your reply. I think we're pretty much in agreement on the things you covered, so let me just address this one area to see if I can provide a little clarification:

On 3/31/11 10:12 AM, Wilhelm Sanke wrote:
Of course, I fully agree. We do our own maintenance and I have
contributed to it, as you know. But it is another matter when that
maintenance is made more difficult because of new features (for that
matter new engines and standalone builders) that are extremely
troublesome to integrate.
When they have now moved the build process into the engine, why is the
standalone builder still encrypted?

My understanding of Kevin's agreement with Scott on acquisition of the engine was that RunRev not do anything specifically to prevent an alternative IDE from being developed and enhanced.

I do not believe that these terms went so far as requiring Kevin to limit the scope of what he can do with the product he acquired so that it's especially convenient for our of volunteers to maintain MC. That would have been impractically onerous, and Raney is nothing if not practical; he would never have asked for that.

I feel Kevin has held up his end of the bargain admirably, going out of his way several times to make work on alternate IDEs easier than it might have been.

I can't blame him for not making it a higher priority to do even more. As the keeper of the engine, all of us depend on his team to prioritize his own company's ROI first and foremost; if RunRev goes, the future of the MC IDE would at best be in doubt, and at worst would have no engine to drive it at all.

One of the areas any software business owner is free to do as he chooses is to determine the model used for demo versions, and I believe this is the only area where his needs have caused us any difficulty at all -- and even then he still directed his staff to provide whatever assistance was needed to help us achieve our goals.

Some background on the differences in the demo model and how it plays our with locked stacks:

Raney's demo version was feature-limited, but Kevin feels a time-limited model is more appropriate for his own business. I may have my own opinions, but Kevin runs his own business and I run mine and we both like it that way. :)

You may recall that MC's license enforcement was also encrypted, the only difference being which stack was encypted: in Rev it's the Standalone Builder, and in MC it was Home. But in both cases the reason was the same: license enforcement.

AFAIK Scott Raney never gave the password to the MC Home stack to anyone in the MC IDE project. The stack was made available under an open source license of our choosing, but the Home stack on which it depended remained locked with no means of accessing its code.

Raney never needed to lock his SB because it wasn't relevant to his business model. He felt that if people wanted to make standalones with only 10 executable lines per script they could knock themselves out. But standalone building is directly relevant to Kevin's model, as outlined in the LC license agreement which expressly forbids any standalone from also building its own standalones.

FWIW, Kevin has said that if you have a specific app that really NEEDS to make standalones he would be willing to take the time to discuss the possibility of a unique license agreement to allow that. But the off-the-shelf license prohibits it.

I don't know to what degree the current engine-based binding method may be restricted to the IDE engine only, or whether it could theoretically be used by the standalone engine. I'll get clarification from him on that.

As for why he locks his own standalone builder, that's entirely up to him. What the engine does is primarily the bit-level binding stuff (embedding the engine, icons, and UAC info), and there's a lot of other steps involved in making a working set of builds (which is why mine remains so weak at this point). I have no idea what else his SB is doing, and given the variety of deployment options I wouldn't be surprised if at least some of the license enforcement is handled in scripts.

The upside to all of this for us MC folks is that RunRev's move to engine-based license enforcement finally freed us up from the last locked stack in the MC environment, Home. Now you can make your own Home stack any way you want to do whatever you want.

With that background, let's step back and look at the big picture:

The ONLY area in which it's at all inconvenient to do darn near anything you want with any IDE you can dream up is standalone building.

In every other respect, what RunRev has provided for us MC users goes well beyond what he provides most other customers in terms of engine enhancements and info on undocumented features.

And even with standalone building, he still devoted resources to making sure we can at least get the job done.

So we're free to do whatever we want with all aspects of developing software with the LiveCode language.

I'm committed to providing a standalone builder that'll more than address our needs.

If we can kindly move past that, it would seem a more interesting question might be:

What else do we want to do to make MC more powerful for our work?

 Richard Gaskin
 Fourth World
 LiveCode training and consulting:
 Webzine for LiveCode developers:
 LiveCode Journal blog:

metacard mailing list

Reply via email to