I'd like to have a version of a package that doesn't include sources. I thought that this could be achieved by using binary option in R CMD build, but in fact it packages source code that could be easily printed once the library is loaded. Is there an option to avoid visibility of the source? Another related question is how to install two versions of the same package, so that i could load either of them? I am sure this could be done, just cannot find this in docs. I am using R 2.12.1 on Red Hat Lunix -- View this message in context: http://r.789695.n4.nabble.com/how-to-make-a-true-binary-package-tp3895117p3895117.html Sent from the R devel mailing list archive at Nabble.com.
how to make a true binary package?
9 messages · andre zege, Uwe Ligges, Simon Urbanek +4 more
On 11.10.2011 18:33, A Zege wrote:
I'd like to have a version of a package that doesn't include sources. I thought that this could be achieved by using binary option in R CMD build, but in fact it packages source code that could be easily printed once the library is loaded. Is there an option to avoid visibility of the source?
R is open source software ... Anyway, for C sources: these cannot be printed easily in a binary package. But then make sure your license is file given you link against something under GPL ...
Another related question is how to install two versions of the same package, so that i could load either of them? I am sure this could be done, just cannot find this in docs.
You can install each version of the package into a separate library. Uwe Ligges
I am using R 2.12.1 on Red Hat Lunix -- View this message in context: http://r.789695.n4.nabble.com/how-to-make-a-true-binary-package-tp3895117p3895117.html Sent from the R devel mailing list archive at Nabble.com.
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On 11/10/2011 12:33 PM, A Zege wrote:
I'd like to have a version of a package that doesn't include sources. I thought that this could be achieved by using binary option in R CMD build, but in fact it packages source code that could be easily printed once the library is loaded. Is there an option to avoid visibility of the source?
No. As Uwe said, R is an open source project. We like to encourage others to be open source too. Duncan Murdoch
Another related question is how to install two versions of the same package, so that i could load either of them? I am sure this could be done, just cannot find this in docs. I am using R 2.12.1 on Red Hat Lunix -- View this message in context: http://r.789695.n4.nabble.com/how-to-make-a-true-binary-package-tp3895117p3895117.html Sent from the R devel mailing list archive at Nabble.com.
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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. -- View this message in context: http://r.789695.n4.nabble.com/how-to-make-a-true-binary-package-tp3895117p3895262.html Sent from the R devel mailing list archive at Nabble.com.
On Oct 11, 2011, at 1:09 PM, A Zege 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 :).
Those are fairly disjoint concepts - open source doesn't mean you can't get paid. Also the fact that the source is accessible doesn't mean that it is legal for someone else to take it - you define what you allow in the license. Note, for example that Java bytecode can be easily disassembled into readable Java source form and yet there is a lot of commercial software written in Java.
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.
You can compile the functions and strip the source code from the bytecode objects. Such a thing can be serialized without revealing the original source code. However, you can still de-compile it, and R doesn't guarantee that such stripped objects will continue to work, so your mileage will vary and you may want to check if it's what you want. There are obvious other ways you could use that are much simpler - such as encrypt your sources. Nothing is completely bullet-proof, it's just a matter of how much work it requires to break whichever method you choose. Cheers, Simon
One of the most secure options, I think, is to provide a
web-based tool to do the computations. I know one case where this was
done. The clients probably did not even know that R was being used to
do the computations. They had an application or a procedure for
uploading their data to a secure web site, which then returned answers.
This too can be defeated by determined hackers, but if you are careful
about your encryption, etc., you can make it quite difficult for them.
Hope this helps.
Spencer
On 10/11/2011 10:41 AM, Simon Urbanek wrote:
On Oct 11, 2011, at 1:09 PM, A Zege 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 :).
Those are fairly disjoint concepts - open source doesn't mean you can't get paid. Also the fact that the source is accessible doesn't mean that it is legal for someone else to take it - you define what you allow in the license. Note, for example that Java bytecode can be easily disassembled into readable Java source form and yet there is a lot of commercial software written in Java.
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.
You can compile the functions and strip the source code from the bytecode objects. Such a thing can be serialized without revealing the original source code. However, you can still de-compile it, and R doesn't guarantee that such stripped objects will continue to work, so your mileage will vary and you may want to check if it's what you want. There are obvious other ways you could use that are much simpler - such as encrypt your sources. Nothing is completely bullet-proof, it's just a matter of how much work it requires to break whichever method you choose. Cheers, Simon
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On Tue, Oct 11, 2011 at 6:09 PM, A Zege <andre.zege at 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
If you want to hide some code from accidental or casual sight then I have had some success with adding something like this to the .R file for a package (the petals function in TeachingDemos in this case):
.onAttach <- function(...) {
petals <- petals
attr(petals,'source') <- "Don't Cheat!"
assign('petals',petals,'package:TeachingDemos')
}
Though that would only slow an experienced R programmer down by maybe 10 seconds if they really wanted to see the code, it might take an intermediate level R programmer a whole minute to figure out how to work around this. But it would prevent an honest user that knew of a license or agreement to not look at the code from accidentally seeing what they agreed not to.
You could also include something in the code that checked the attribute and stopped working if it was changed or somehow notified you of the change. Combining this with the license agreements as others have said might give you additional recourse.
You can see the petals.R file in the TeachingDemos package on R-forge for another example of obfuscating (bleaching) a key piece of code. Combining the 2 might slow down an expert by a whole 30 seconds, but at least they would not be able to claim that they accidentally saw the code.
Whether this violates the spirit of R licensing or not is another issue.
Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.snow at imail.org 801.408.8111 > -----Original Message----- > From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r- > project.org] On Behalf Of A Zege > Sent: Tuesday, October 11, 2011 11:09 AM > To: r-devel at r-project.org > Subject: Re: [Rd] how to make a true binary package? > > 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. > > > -- > View this message in context: http://r.789695.n4.nabble.com/how-to- > make-a-true-binary-package-tp3895117p3895262.html > Sent from the R devel mailing list archive at Nabble.com. > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
On 12/10/2011 3:57 PM, Greg Snow wrote:
If you want to hide some code from accidental or casual sight then I have had some success with adding something like this to the .R file for a package (the petals function in TeachingDemos in this case):
.onAttach<- function(...) {
petals<- petals
attr(petals,'source')<- "Don't Cheat!"
assign('petals',petals,'package:TeachingDemos')
}
Though that would only slow an experienced R programmer down by maybe 10 seconds if they really wanted to see the code, it might take an intermediate level R programmer a whole minute to figure out how to work around this. But it would prevent an honest user that knew of a license or agreement to not look at the code from accidentally seeing what they agreed not to.
You should be aware that this will no longer work in R 2.14.0, which
finally drops the "source" attribute. This would achieve a similar effect:
srcfile <- srcfilecopy("", "Don't cheat")
srcref <- srcref(srcfile, c(1,1,1,12))
attr(petals, "srcref") <- srcref
Duncan Murdoch
You could also include something in the code that checked the attribute and stopped working if it was changed or somehow notified you of the change. Combining this with the license agreements as others have said might give you additional recourse. You can see the petals.R file in the TeachingDemos package on R-forge for another example of obfuscating (bleaching) a key piece of code. Combining the 2 might slow down an expert by a whole 30 seconds, but at least they would not be able to claim that they accidentally saw the code. Whether this violates the spirit of R licensing or not is another issue.