Re: Euphoria will be Free and Open Source!
------=_Part_8789_1842326.1159070934052
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi folks,
I haven't written to this list for a looong time... actually I haven't
written any new Euphoria programs for many years now, but I still
occasionally check the list and website to see how things are going.
Open-sourcing Euphoria is a great decision; I just might go back to playing
with the open Eu someday. Congratulations and thanks, Rob!
Just a thought on this binder/shrouder thing: distributing a closed-source
module or shared library to be linked with the open-source code seems like a
bad idea to me. If the module only performs the decryption, since it would
have to give the decrypted IL for the open-source part to execute, it would
be possible to create a program that feeds the encrypted code into the
module and outputs the corresponding plain code. So, to really protect the
shrouded code, it would be necessary for the module to contain an
independent, closed interpreter for running it, which doesn't look like an
interesting option and would cause all sorts of problems.
So I believe the most feasible and secure option is that running shrouded
code should continue to be possible only via closed executables distributed
by RDS. Since such executables are already available for the most recent
Euphoria version and all existing shrouded code can be run with them, maybe
support for them could simply be dropped from future releases. Registered
users who want to use their code with new Euphoria versions can use the
compilers or distribute normal IL files (which should be hard enough to
decompile already - maybe this will create a new market for Euphoria IL
obfuscators, similar to what happens in the Java world).
Depending on the license chosen for the open-source Eu, mantaining a closed
version of Euphoria incorporating other people's code might be possible, or
it may require special steps, such as requiring contributors to assign
copyright on their code to RDS or to license it separately to RDS for
inclusion in the closed software. If this is too much trouble but Rob
doesn't want to abandon his registered users completely, he could create a
final 3.0 closed version with the modifications he has made so far to give
them more time to adapt to the new situation.
Of couse, since I've been away for so long, there may have been changes that
make what I'm saying irrelevant or just plain wrong...
Best wishes,
Davi
On 9/20/06, ags <guest at rapideuphoria.com> wrote:
>
>
> posted by: ags <eu at 531pi.co.nz>
>
> Robert Craig wrote:
> [shrouding]
> > I guess I'll have to "deprecate" that feature (i.e. maybe support it
> > using a non-open subroutine for this release, but eventually
> > discontinue it. I'm open to suggestion on this.
>
> I think a shared library which only you control is fair enough, as long as
> it is supported on all the platforms that Euphoria is supported on.
>
> I think it is needed for backward compatibility, but then I guess Euphoria
> would need some sort of plug-in system where you can link things into the
> front end (or whatever).
>
> Gary
>
>
------=_Part_8789_1842326.1159070934052
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi folks,<br><br>I haven't written to this list for a looong time... actually I
haven't written any new Euphoria programs for many years now, but I still
occasionally check the list and website to see how things are going.
Open-sourcing Euphoria is a great decision; I just might go back to playing with
the open Eu someday. Congratulations and thanks, Rob!
<br><br>Just a thought on this binder/shrouder thing: distributing a
closed-source module or shared library to be linked with the open-source code
seems like a bad idea to me. If the module only performs the decryption, since it
would have to give the decrypted IL for the open-source part to execute, it would
be possible to create a program that feeds the encrypted code into the module and
outputs the corresponding plain code. So, to really protect the shrouded code, it
would be necessary for the module to contain an independent, closed interpreter
for running it, which doesn't look like an interesting option and would cause all
sorts of problems.
<br><br>So I believe the most feasible and secure option is that running
shrouded code should continue to be possible only via closed executables
distributed by RDS. Since such executables are already available for the most
recent Euphoria version and all existing shrouded code can be run with them,
maybe support for them could simply be dropped from future releases. Registered
users who want to use their code with new Euphoria versions can use the compilers
or distribute normal IL files (which should be hard enough to decompile already -
maybe this will create a new market for Euphoria IL obfuscators, similar to what
happens in the Java world).
<br><br>Depending on the license chosen for the open-source Eu, mantaining a
closed version of Euphoria incorporating other people's code might be possible,
or it may require special steps, such as requiring contributors to assign
copyright on their code to RDS or to license it separately to RDS for inclusion
in the closed software. If this is too much trouble but Rob doesn't want to
abandon his registered users completely, he could create a final
3.0 closed version with the modifications he has made so far to give them more
time to adapt to the new situation.<br><br>Of couse, since I've been away for so
long, there may have been changes that make what I'm saying irrelevant or just
plain wrong...
<br><br>Best wishes,<br>Davi<br><br><br><div><span class="gmail_quote">On
9/20/06, <b class="gmail_sendername">ags</b> <<a href="mailto:guest at
rapideuphoria.com">guest at rapideuphoria.com</a>> wrote:</span><blockquote
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt
0pt 0pt 0.8ex; padding-left: 1ex;">
============ The Euphoria Mailing List ============<br><br><br>posted by: ags
<eu at <a href="http://531pi.co.nz">531pi.co.nz</a>><br><br>Robert Craig
wrote:<br>[shrouding]<br>> I guess I'll have to "deprecate" that
feature (
i.e. maybe support it<br>> using a non-open subroutine for this release, but
eventually<br>> discontinue it. I'm open to suggestion on this.<br><br>I think
a shared library which only you control is fair enough, as long as it is
supported on all the platforms that Euphoria is supported on.
<br><br>I think it is needed for backward compatibility, but then I guess
Euphoria would need some sort of plug-in system where you can link things into
the front end (or whatever).<br><br>Gary<br><br></blockquote></div><br>
------=_Part_8789_1842326.1159070934052--
|
Not Categorized, Please Help
|
|
