Making a trial based Package for 30-days.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Making a trial based Package for 30-days.

Ashis Deb
Hi  all   ,


               I have   a  GUI  package , which  I  want  to  make  it
work  for  a  certain period,say-30days   ,after which  it should  be self
destructive  .

Could it  be possible  ??


ASHIS

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Making a trial based Package for 30-days.

Helios de Rosario
I guess you could write some instructions in the "configure" file
("configure.win" for windows) at the root level of the package
subdirectory, to create a scheduled task to uninstall and delete the
package after a fixed period. That script would normally execute at the
moment of installation. See "Package structure" in "Writing R
extensions".

Yes, easy to hack. But R is free software, so that's what you should
normally expect for any mechanism. In any event, I suppose that you
don't want a "trial-based" package for your own use alone, but you want
to distribute it. And if you want to distribute it by mainstream
repositories (e.g. CRAN), you should publish the source anyway, and
won't be allowed to include such "malicious" mechanisms.

Helios De Rosario


>>> El día 12/05/2014 a las 11:31, Ashis Deb <[hidden email]>
escribió:
> Hi  all   ,
>
>
>                I have   a  GUI  package , which  I  want  to  make
it
> work  for  a  certain period,say‑30days   ,after which  it should  be
self
> destructive  .
>
> Could it  be possible  ??
>
>
> ASHIS
>

INSTITUTO DE BIOMECÁNICA DE VALENCIA
Universidad Politécnica de Valencia • Edificio 9C
Camino de Vera s/n • 46022 VALENCIA (ESPAÑA)
Tel. +34 96 387 91 60 • Fax +34 96 387 91 69
www.ibv.org

  Antes de imprimir este e-mail piense bien si es necesario hacerlo.
En cumplimiento de la Ley Orgánica 15/1999 reguladora de la Protección
de Datos de Carácter Personal, le informamos de que el presente mensaje
contiene información confidencial, siendo para uso exclusivo del
destinatario arriba indicado. En caso de no ser usted el destinatario
del mismo le informamos que su recepción no le autoriza a su divulgación
o reproducción por cualquier medio, debiendo destruirlo de inmediato,
rogándole lo notifique al remitente.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Making a trial based Package for 30-days.

Barry Rowlingson
In reply to this post by Ashis Deb
On Mon, May 12, 2014 at 10:31 AM, Ashis Deb <[hidden email]> wrote:
> Hi  all   ,
>
>
>                I have   a  GUI  package , which  I  want  to  make  it
> work  for  a  certain period,say-30days   ,after which  it should  be self
> destructive  .
>
> Could it  be possible  ??
>

 Yes.

 But why bother? Can you stop people:

 a) turning back the clock on their PCs?
 b) reinstalling again after 30 days?
 c) installing on a fresh operating system?
 d) editing the program to remove the date check?

You have to decide if the effort in preventing all these things is
worth it. Unless your software is really going to make you millions of
dollars unless you do this, the answer is no.

 Easiest option is to just pop up a nag screen saying "You really
should stop using this after 30 days", but don't bother trying to
enforce it (and definitely don't go deleting it itself, you'll end up
deleting someone's files and then they will sue you).

 With a nag screen, people who are going to buy your product will buy
it, people who aren't going to buy your product will carry on using
it, but then they are going to do that anyway since these measures are
so easily circumvented. Unless you want to invest in some serious
licensing infrastructure.

Barry

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Making a trial based Package for 30-days.

Barry Rowlingson
On Mon, May 12, 2014 at 1:11 PM, Ashis Deb <[hidden email]> wrote:
> Well  it's  the company requirement to do  so  ,  and  give it on  a trial
> basis  to  client to check , if they  like they  will BUY  or  it will  self
> destruct itself ,

 No, if they like it they will BUY or they will CIRCUMVENT your
self-destruction mechanism.

 The company requirement has not been thought through to
practicalities, and is unrealistic, and is not constrained by
limitation. How do you prevent them re-installing?

 For a price, I will fly (first class) to all your clients after 30
days and delete the software for you.

Barry

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Making a trial based Package for 30-days.

Spencer Graves-2
On 5/12/2014 7:28 AM, Barry Rowlingson wrote:

> On Mon, May 12, 2014 at 1:11 PM, Ashis Deb <[hidden email]> wrote:
>> Well  it's  the company requirement to do  so  ,  and  give it on  a trial
>> basis  to  client to check , if they  like they  will BUY  or  it will  self
>> destruct itself ,
>   No, if they like it they will BUY or they will CIRCUMVENT your
> self-destruction mechanism.
>
>   The company requirement has not been thought through to
> practicalities, and is unrealistic, and is not constrained by
> limitation. How do you prevent them re-installing?
>
>   For a price, I will fly (first class) to all your clients after 30
> days and delete the software for you.


       Linux is free, open source software (FOSS), but people create
lots of commercial software to run on Linux.


       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.


       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.


       If you submit anything to CRAN, you must enter a legally binding
agreement that anything you submit is released under an acceptable FOSS
license.  I don't know what they do if they find an unacceptable license
in a CRAN package, but at minimum, the package will be removed.


       Spencer

> Barry
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Making a trial based Package for 30-days.

Barry Rowlingson
In reply to this post by Barry Rowlingson
On Mon, May 12, 2014 at 3:45 PM, Spencer Graves
<[hidden email]> 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.

Barry

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

Re: Making a trial based Package for 30-days.

Spencer Graves-2
On 5/12/2014 8:21 AM, Barry Rowlingson wrote:

> On Mon, May 12, 2014 at 3:45 PM, Spencer Graves
> <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.