Protect Julia Code against reverse engineering / copying

[bernhard]

Dear all

We have some Julia code which we would like to "deploy" client side. 

Installing Julia (and possibly dependencies) on the clients machine(s) should not be an issue. There are however two important restrictions we face:

1. The client data (on which our code will work) cannot leave their IT environment.

2. We want to protect our intellectual property (i.e. our code) at any cost.

Is this feasible today? Or is it partially feasible (i.e. in a way such that decompliation is possible only to a certain extent).

I must admit that I do currently not even know whether compilation is possible (I think it is not in 0.3.10) and until now I always copied the raw Julia code to other machines when I needed to calculated something on other machines. 

Bernhard

[Páll Haraldsson]

I would also like to know an answer to this (that is, is my answer complete.. this would be an issue for many proprietary makers.. (and I hate for people to have excuses to not use Julia) say making games.. might be more of a deal-breaker to most, not whether Julia could actually work for [high-performance/AAA] game making that I'm not sure is in dispute except for - maybe the GC - and that it's not been done - yet - only simple games/demos).

This is not something I've tried and "doesn't require any julia source code", below, may be misleading wrong. I'm not sure it means your code gets compiled to native code and distributed that way. [It could, then still be, theoretically (or practically?) be decompiled. That would also apply to Intel and any language:] Intel also had a Julia2C source-to-source compiler. Either of these might work.. but I'm not sure how supported the latter (that may be buggy?/incomplete..?), or even the former is.

Isn't this what you are after:

https://groups.google.com/forum/#!topic/julia-users/MtF4wHc77sw

repeated on Julia's Wikipedia page:

In version 0.4,^[25] a standalone "executable that doesn't require any julia source code" can be built with build_executable.jl^[26] while by default the Julia runtime needs to be pre-installed.

[Scott Jones]

We have some of the same issues, we will be using Julia code in a production environment, but at first,

we will be hosting it, so we won't have the deployment issues.

Deployment means that you will need to build your own version of Julia, without any GPLed code.

There is a flag to do that.

[Páll Haraldsson]

Strictly speaking, according to Stallman himself compilers do not affect the license of binary produced by a compiler. However, the the C library, that you usually incorporate, that is GPL, it would make the whole binary GPL, if it were not for the GPL exception used.

I wander what would be true for Julia code (that wouldn't at least use the GPL parts of Julia). Yes, you are using Julia in the same process, but would that mean all source code of yours would be automatically derived software of Julia? That would make all Julia code GPL.. and doesn't seem to make sense (any more than, Linux programs, derived software of the Linux kernel, but it has an explicit, notice to that effect, mostly so people to not assume that?)

Maybe as Julia is unusual, has macros/metaprogramming, Julia should not be considered as a generic compiler.. same argument should be made as for any Lisp-compiler/system.

[Scott Jones]

On Thursday, August 27, 2015 at 1:10:33 PM UTC+2, Páll Haraldsson wrote:

Strictly speaking, according to Stallman himself compilers do not affect the license of binary produced by a compiler. However, the the C library, that you usually incorporate, that is GPL, it would make the whole binary GPL, if it were not for the GPL exception used.

That's not the issue.  There are some pieces of Julia, such as FFTW, SparseSuite, and one other I can't recall, that

are under the GPL (and not the LGPL), so you can't even deploy them simply as a library.

Without those, you're fine to deploy.

[Isaiah Norton]

1. Up to you to design for and verify software security, just like any other platform.

2. Extensive use of `precompile`, plus the mentioned build_executable/userimg.jl, are the only two current options for precompiled native code. There is no attempt at obfuscation. Several such libraries exist for LLVM; in principle one could be integrated with Julia's codegen. However, this is not something I can imagine any core contributor would be willing to work on for free.

[Andreas Lobinger]

Hello,

is there some docu available on build_exec and similar. I've tried now a few times, but failed a few times like

 
LoadError(at "sysimg.jl" line 319: LoadError(at "/home/lobi/julia04/base/userimg.jl" line 1: LoadError(at "/home/lobi/juliarepo/s1.jl" line 7: UndefVarError(var=:STDOUT))))

when trying to use @printf,

like this

LoadError(at "sysimg.jl" line 319: LoadError(at "/home/lobi/julia04/base/userimg.jl" line 1: LoadError(at "/home/lobi/juliarepo/s1.jl" line 7: Base.MethodError(f=display, args=(-2962033225986919792,)))))

when trying to use display and like this,

NFO: Linking sys.so
INFO: System image successfully built at /home/lobi/julia04/usr/lib/libs1.exe.so
INFO: To run Julia with this image loaded, run: julia -J /home/lobi/julia04/usr/lib/libs1.exe.so

running: gcc -g -Wl,--no-as-needed `` -I/home/lobi/julia04/usr/include/julia -I/home/lobi/julia04/src -I/home/lobi/julia04/src/support -I/home/lobi/julia04/usr/include /tmp/tmptXPRwY/start_func.c -o /home/lobi/julia04/usr/bin/s1.exe -Wl,-rpath,/home/lobi/julia04/usr/lib -L/home/lobi/julia04/usr/lib -ljulia -ls1.exe
/tmp/tmptXPRwY/start_func.c: In function ‘main’:
/tmp/tmptXPRwY/start_func.c:19:5: error: too few arguments to function ‘jl_atexit_hook’
     jl_atexit_hook();
     ^
In file included from /tmp/tmptXPRwY/start_func.c:1:0:
/home/lobi/julia04/src/julia.h:1130:16: note: declared here
 DLLEXPORT void jl_atexit_hook(int status);
                ^
ERROR: LoadError: failed process: Process(setenv(`gcc -g -Wl,--no-as-needed

recently.