[R] Making a trial based Package for 30-days.

[Spencer Graves]

On 5/12/2014 8:21 AM, Barry Rowlingson wrote:
> On Mon, May 12, 2014 at 3:45 PM, Spencer Graves
> <spencer.graves at structuremonitoring.com> wrote:
>
>>         One company I know installed an S-Plus or R package only on
>> servers, so their customers had to use it on a server.  (In this case,
>> the customers had a GUI and may not have known that it was S-Plus or R
>> behind it.)  This company also developed techniques for encrypting their
>> code.  I don't think it was perfect, and they eventually wrote it in C
>> or C++ or Matlab.
>   If the code runs on a server controlled by the company, and the user
> uses the code via some network API, then it might be practical to give
> a user a password that is revoked after thirty days. If the server is
> controlled by the user, then all bets are off.
>
>   Any "encrypted" code has to be decrypted in order to be executed, so
> it is only obfuscated code. Even systems where the decryption keys are
> hidden in hardware chips covered in resin have been cracked by
> enthusiasts with a sharp blade, small probes, and a digital
> oscilloscope. We are talking hardware encryption/DRM systems developed
> by companies like SONY.
>
>>         So part of the answer is you can write part of your package in a
>> compiled language.  That part can check your web site to check the date
>> and other things.
>   Still easily circumventable (poke the code, preload a different date
> library DLL, turn the clock back...), so why bother? You can't
> consider how you'd have self-destructing code without having a debate
> about the cost and effort you want to put in and the cost and effort
> crackers want to put in. I the SONY case (or similar) crackers will
> compete like mad to crack the DRM, even if only for fame and not
> fortune or free access to pirated games.
>
>   I think it would take me under an hour to write a package that
> self-destructed. Its not difficult, you create a file somewhere when
> the system first runs, then on subsequent runs check the date is less
> than 30 days after the file, and run file.remove over the package if
> its expired.


       Agreed.  The only certainties are death, taxes, and uncertainty ;-)


       Some of us are fortunate enough to be able to contribute to R and 
CRAN without having it jeopardize our access to adequate food and 
shelter.  Many people get paid for writing code, and some of those get 
paid from license fees.  A better world is possible, but that's beyond 
the scope of this discussion.


       Spencer


> Barry