1. RE: .il code/file questions
- Posted by Chris Bensler <bensler at nt.net>
Nov 17, 2004
-
Last edited Nov 18, 2004
Andy Serpa wrote:
>
>
> posted by: Andy Serpa <ac at onehorseshy.com>
>
> Robert Craig wrote:
> >
> > In theory, I could sell the translator source, but with
> > the restriction that it can only be used for private use,
> > and not for creating and distributing new versions of Euphoria
> > to the masses. It would involve extra
> > configuration/packaging/documenting/tech suport
> > work for me, and I don't think there are very many people,
> > other than potential competitors,
> > who would have the ability or desire to modify the translator
> > in a significant way, though some front-end changes might be easy.
> > In general, it's quite a bit more complicated than the interpreter.
> >
> > It provides me with one of my last "fig leaves" in this
> > age of openness. 
> >
>
> How about this? You already have an open-source front-end. Now we just
> have to get to the point where that can really be useful. <SNIP>
I agree.
I think that is what many of us were expecting.
Chris Bensler
Code is Alchemy
2. RE: .il code/file questions
Robert Craig wrote:
<SNIP>
> Sorry for the slow response.
> This is a tricky question to answer.
>
> It may be premature to even try to settle this issue now.
> After all, 2.5 has been out for all of two days.
> Derek and Andy, you have little experience in modifying the
> front end, and neither of you has described what
> changes you would like to make. You might discover that
> you actually need back-end changes as well, to properly implement
> some feature. The Euphoria back-end was designed
> specifically to execute Euphoria programs, not a wide variety
> of assorted programming languages.
I think you underestimate us. It's quite obvious that we can't modify
the front end to make runtime changes like exposing the vtable.
We certainly can make changes like fixing the include syntax, or fixing
the namespacing system, or adding assignment on declare, or private
constants, or structures, or oop, or labelled sequence elements, or
making it possible to overload routine_id()...
> The Source Code product lets you make any changes you like,
> to either the front end, or the back-end. The only "catch"
> is that the interpreter you create must be for your own use.
> You can't distribute it to the world (unless it runs on a new
> platform).
How many people are going to spend the money and effort to build an
interpreter that only they can use?
> The Public Domain source lets anyone in the world, for free,
> make any changes they like to the way the Euphoria interpreter works.
> The only "catch" is that it runs slower than
> the official interpreter. Translating it helps, but it's
> still slower.
The PD source is not practical. I don't see how you can think it is.
We can make all the changes we want, great, but who is going to use it?
> I feel I'm already walking a tight rope, balancing openness
> with the need to protect my income. It should be obvious
> that I can't make it easy for people to produce their
> own "enhanced" versions of Euphoria that run at the same speed
> as mine, and can be distributed widely. That would be
> financially reckless, if not suicidal. I'm not saying
> this proposal would necessarily do that, but I feel the tight rope
> getting narrower.
Why would it be wreckless? You aren't selling the syntax anymore
anyways, you are selling the ability to make executables. How does that
change if we make our own front-end? We are still restricted to the IL
that the offical RDS runtime uses.
You should be worried about what will happen if you don't provide a way
for us to utilize the backend, because it will mean people making their
own IL runtime modelled after the very code you gave us.
Once someone creates an opensource backend that runs the official IL,
you will be in direct competition then. Not partnerships. Not offshoots.
You will definitely have to pick up your heels then to just stay afloat.
Sometimes the best way to keep things from being stolen, is to leave
them in the open.
> I also feel I have enough product configurations on enough platforms
> to keep me busy for now. Adding another configuration that
> would be used by only a few people wishing to create fast
> personalized versions of Euphoria would probably not be a
> good use of my development/testing/documenting time.
> But maybe I'll "see the light" after 2.5 has been out a while longer.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
I think it's alot more than 'only a few people'.
Without the ability for us to take advantage of the optimized backend,
the PD source for the front-end is useless for making language
enhancements.
If we buy the source, we aren't allowed to distribute our changes.
So what's the point of having it available at all?
If you allow us a way to create IL code that will run on the backend, I
think you will find that the outcrop of new 'languages' will only
strengthen Euphoria's market. They will all rely on RDS's official
backend.
Every one of those offshoots is a new niche of potential programmers.
I don't see the threat if someone creates a new front-end for your
official runtime. If anybody wants the binder or shrouder, they still
have to register with RDS. Those offshoots are also advertisement for
the 'official' language. When those programmers that use an offshoot
that dies (which most fo them will), where do you think they are going
to go?
Chris Bensler
Code is Alchemy
3. RE: .il code/file questions
- Posted by Chris Bensler <bensler at nt.net>
Nov 19, 2004
-
Last edited Nov 20, 2004
Robert Craig wrote:
>
>
> posted by: Robert Craig <rds at RapidEuphoria.com>
>
> Pete Lomax wrote:
> >
> > On Thu, 18 Nov 2004 23:29:46 -0800, Robert Craig
> > <guest at RapidEuphoria.com> wrote:
> >
> > >Probably not, though I don't completely understand your point.
> > The point is the words that you use, not that you necessarily offer
> > anything radically different. Please correct me if I am wrong:
> >
> > The new eu.ex is open source. I can modify it and distribute it as I
> > please (but it's a tad slow).
>
> Yes. In fact it's more than just "open source". For example,
> the popular GNU license forces you to make your changes open.
> This PD source has no restrictions like that. You can make an
> open or closed source and/or commercial program
> and sell it for a million dollars.
>
> > Assuming I don't modify execute.e, then if I purchase the source, it's
> > a simple thing to create a full-featured (bar legacy shrouded code
> > support), full speed interpreter (say myexw.exe).
>
> Yes, for private use, not wide distribution.
> I can imagine some company needing/wanting to make
> a small change to Euphoria. This would allow them
> to do so, possibly saving thousands of dollars of
> effort for $79.
>
> Most (90%?) of the people who previously purchased
> the source product had no intention of widely distributing modified
> versions of Euphoria. Obviously, on this mailing list there
> are several people with the publicly-stated intention,
> and past history, of trying to develop Euphoria-like languages
> regardless of the effect that has on RDS's bottom line.
> ...I know, I know, you all want the best for Euphoria.
> You want to selflessly lead the Euphoria community to
> the "promised land". You don't want to put RDS out of business.
> You just want to clone Euphoria and distribute it free,
> at full speed, with open source, to all comers.
>
> > I can send myexw.exe to you, and it will or will not appear in the
> > archive at your discretion.
>
> Yes. If it provides some benefit to those who are using *Euphoria*,
> I'll probably post it.
>
> > Now, despite having purchased the source, I'm still at liberty to
> > distribute the PD bits I modified, but not myexw.exe (which is the
> > main change to the 2.5 license)
>
> Yes you can distribute the PD stuff.
>
> > I am allowed to tell people where to buy the source.
> > I can supply instructions for recreating myexw.exe, or, if someone can
> > prove they have purchased the source, I can send them myexw.exe.
> >
> > As I re-read the new source license, it dawns upon me that maybe this
> > is what you meant all along.
> >
> > It all now seems a lot more reasonable to me.
> >
> > You just want your $79 from every person in the chain, and then we can
> > do what we like. Sounds fair play to me.
>
> Yes, you can work with others on the source and you can
> give your version of Euphoria to others, e.g. people
> who have contracted with you to do a special app,
> but everyone must pay $79 for a source license.
>
> > One last thing, before anyone jumps on me. If you create an
> > application as opposed to an interpreter, the end users do not have to
> > pay a fee, though you may have to distribute it bound because of the
> > restriction on redistributing myexw.exe (if, that is, it uses any new
> > language features you have devised)
>
> I don't think that's spelled out explicitly,
> but the license does not say you can distribute
> executables in bound or packaged form without the $79/person rule
> kicking in. Nor does it say you can build/distribute something
> other than an interpreter and avoid the $79 rule.
>
> Of course the rules are completely different if you
> want to port Euphoria to a new platform that it
> doesn't already run on.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
We don't want the source for the backend, we just want to be able to
hook to it.
Rob I understand the arrangements that you have set up, and I don't
terribly disagree with it. I realize you are trying to protect your own
interests, but it really seems like are trying to pull the wool over our
eyes, with false choice. The point we are making, is that your options,
provide us with no options for what we want to acheive, and it's NOT to
put you out of business. Forcing everyone to buy a source liscense, so
they can use our hybrid front-ends, is futile.
And YES! We do want to distribute Eu to the 4 corners. What is wrong
with that? You don't think there would be positive reprecussion for
Euphoria's income? Or are you really that afraid we are going to one-up
you? If we were going to one-up you, we would publicly broadcast the
registered version products we have.
Consider that last notion, and consider it really hard, and weigh it
against the restrictions you are imposing, and look at how rediculous
you are being. You have 10 padlocks on the front door, and left the back
door WIDE OPEN.
If we wanted to sabotage you, it's alot less effort than any
modifications we can make to your code.
I beleive you are trying to protect more than your financial interests
here, and I don't blame you for wanting to protect your creation from
being tainted.
I know you *would like* to be releived to have got 2.5 out the door, and
we should be more considerate of that fact. I apologize on behalf of all
of us, for creating premature conflict. We should respect that you have
put alot of effort into producing what you have provided, but I'm sure
you can understand everybody's dissapointment.
2.5 is still in alpha, and only days old. We can wait until 2.5
solidifes at least, before we start casting our ballots.
And by all means Rob, use that excuse too. It will calm people down for
the time being, I assure you, so you can have a rest.
However, you really do need to consider this situation more thoroughly.
Can you at least agree to strongly reconsider your position on this?
We can start a formal *productive* thread to discuss any possible
options, to satisfy both, your interests and ours.
And for crying out loud, don't say no, to any of your customers, ever.
Even if that's what you mean.
The customer is always right, even when they are wrong.
Chris Bensler
Code is Alchemy
4. RE: .il code/file questions
- Posted by "Kat" <gertie at visionsix.com>
Nov 19, 2004
-
Last edited Nov 20, 2004
On 19 Nov 2004, at 21:24, Chris Bensler wrote:
<snip>
> Rob I understand the arrangements that you have set up, and I don't
> terribly disagree with it. I realize you are trying to protect your own
> interests, but it really seems like are trying to pull the wool over our
> eyes, with false choice. The point we are making, is that your options,
> provide us with no options for what we want to acheive, and it's NOT to
> put you out of business. Forcing everyone to buy a source liscense, so
> they can use our hybrid front-ends, is futile.
Well, or not. But since we cannot bind the modified front end to make an exe
anyhow, does it really make a difference? Will the customer accept an install
product from RDS which modifies their registry, when what they wanted was
a few files (the backend and binder) so they can run someone's modified
frontend.il or their application.il? I don't think so. Make them buy the $79
backend and binder if you want to try charging that much for just those 2
files, and let the developer make a file.bat to bind once on their customer's
machine and have their exe. NO INSTALL PROGRAM!
But the bug in the whole ointment is that we can't bind/shroud or otherwise
use the il code to do anything that RDS doesn't already do. So, for instance,
we cannot run an app that calls something else to make .il code which we
then run in the same variable space.
Kat
