On Tue, Oct 11, 2011 at 6:09 PM, A Zege <andre.z...@gmail.com> wrote: > OK, gentlemen, i agree with you in general. I was not talking about a general > purpose, general use package that one prepares for CRAN. I am sure you are > familiar professionally or can imagine situations where you need to > demonstrate a solution to a specific task without fully disclosing the > details -- sometimes even hard core open source adherents need to sacrifice > desire for openness for some prosaic purposes, like getting paid :). > Compilable languages give an easy solution of a binary code. It sounds like > if one wants true binary, he has to recode in C++. I thought it's possible > in R as well, i thought this was discussed even as a default behavior for > next version of R to make stuff go faster. Maybe not. Thanks, anyway. >
[deja vu all over again] What you seem to want to do is code obfuscation. With C, the obfuscation is caused by it being turned into machine code instructions, making exact reconstruction of the C source impossible, but reconstruction of the code as assembly language and hence reverse engineering very possible. With R, there is no compilation to machine code, so plain R source code has to be available to the R interpreter [exception: see Simon's talk of bytecode]. Any encryption you put on has to be decrypted by the user in order to run it. I've said this a few times on R-help and maybe R-devel too. If someone is offering to pay you, then if you tell them they can see the source code then they should want to pay you more. There's also nothing to stop you putting a restrictive license on your source code - including clauses like 'if you look at the contents of any *.R files you are in breach of this license'. These things might even stand up in court. Barry 'Not a lawyer' Rowlingson ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
