Distributing software: protecting the source code
Parker Jones
intellectual property. Languages like C/C++ are intrinsically hard to
reverse-engineer and going from binary to source code is near
impossible.
Has anyone found a good way to protect their Prolog source code? Even
when software written in Prolog is distributed as a binary I believe
it's always possible to retrieve the source because Prolog reflection
is powerful. How does Prolog compare to Lisp or Haskell in this
regard?
I believe this inability to protect the source is one reason Prolog
isn't used more widely because software can't be distributed without
giving way the source.
Parker
Tom Schrijvers
> Has anyone found a good way to protect their Prolog source code? Even
> when software written in Prolog is distributed as a binary I believe
> it's always possible to retrieve the source because Prolog reflection
> is powerful.
users to inject
additional reflective code?
Another option is code obfuscation. I know of such tools for Java
because
Java bytecode is easy to decompile and retains much of the structure
of the original code.
If you replace Prolog predicate, functor and variable names with
meaningless ones, it would be
very hard to figure out what the code is doing. Some code structure
transformations might
further help obfuscation.
> How does Prolog compare to Lisp or Haskell in this regard?
offers hardly anything in terms of reflection.
Tom
Jan Wielemaker
> On 30 Oct, 10:14, Parker Jones <humanc...@gmail.com> wrote:
> > Has anyone found a good way to protect their Prolog source code? Even
> > when software written in Prolog is distributed as a binary I believe
> > it's always possible to retrieve the source because Prolog reflection
> > is powerful.
>
> Maybe it is possible to distribute Prolog binaries that don't allow
> users to inject
> additional reflective code?
>
> Another option is code obfuscation. I know of such tools for Java
> because
> Java bytecode is easy to decompile and retains much of the structure
> of the original code.
> If you replace Prolog predicate, functor and variable names with
> meaningless ones, it would be
> very hard to figure out what the code is doing. Some code structure
> transformations might
> further help obfuscation.
I have discussed this approach with commercial users. It never got to
implementation, but I'm sure it is doable. You need some extra guiding
to find a symbols you should not mangle because they generate/match data
from the outside world. I once understood that Quintus has something
like this (not sure).
Note that for popular compilers and CPUs, reverse engineering of C and
C++ upto this level is also possible.
Then, there are young and eager teenagers that are perfectly willing to
extract the core from the assembler for a little money :-) That is good
enough to crack your small clever algorithm or attempt to protect your
code from illegal usage (as we all know). For the program as a whole,
this is a lot of work, but that is most likely much easier to copy by
simply looking at the outside and reimplement it. For short, in my
opinion this is mostly a myth.
> > How does Prolog compare to Lisp or Haskell in this regard?
>
> I can tell you that the GHC Haskell compiler generates binaries, and
> offers hardly anything in terms of reflection.
Neither does Prolog for static code. Ok, some (most?) of the
implementations do allow for reflection on static code.
Cheers --- Jan
Andrzej Lewandowski
" it's always possible to retrieve the source because Prolog reflection
is powerful."
What "reflection"?...
" In commercial settings it can sometimes be important to protect
intellectual property."
Assume that you reverse engineer CPLEX linear programming code (what is
C++). What is the chance that as the result you will also re-discover
Simplex algorithm and pivoting strategy? "intellectual property" is not the
code, but the algorithms that are behind the code.
Moreover, we distribute Prolog as *.exe file. I wish you good luck in
extracting Prolog code from exe file.
A.L.