Trialware/estrategias de licencia

Question

Escribí una utilidad para fotógrafos que planeo vender en línea bastante barata ($ 10). Me gustaría permitir que el usuario pruebe el software durante una semana más o menos antes de solicitar una licencia. Como se trata de un proyecto personal y el software no es muy costoso, no creo que valga la pena comprar los servicios de proveedores de licencias profesionales y estoy haciendo lo propio.

Actualmente, la aplicación busca una clave de registro que contiene una cadena cifrada que especifica cuándo caduca la versión de prueba o si tienen una licencia válida. Si la clave no está presente, se crea una clave de período de prueba.

Así que todo lo que necesita hacer para obtener otra semana gratis es eliminar la clave de registro. No creo que muchos usuarios lo hagan, especialmente cuando la aplicación cuesta solo $ 10, pero tengo curiosidad por saber si hay una forma mejor de hacerlo que no sea onerosa para el usuario legítimo. Escribo aplicaciones web normalmente y no he tratado con esto antes.

La aplicación está en .NET 2.0, si eso es importante.

Answer 1

EDITAR: Puede hacer que su actual esquema de licencias sea mucho más difícil de descifrar almacenando la información del registro en la Autoridad de seguridad local (LSA). La mayoría de los usuarios no podrán eliminar su información clave desde allí. Una búsqueda de LSA en MSDN debería darle la información que necesita.

Las opiniones sobre los esquemas de licencia varían según cada individuo, más entre los desarrolladores que los grupos de usuarios específicos (como los fotógrafos). Debe tomar una respiración profunda y tratar de ver lo que su usuario objetivo aceptaría, dada la necesidad comercial que su aplicación resolverá.

Esta es mi opinión personal sobre el tema. Habrá personas vocales que no estén de acuerdo.

La respuesta a esto depende en gran medida de cómo esperas que se use tu aplicación. Si espera que la aplicación se use varias veces al día, se beneficiará al máximo de un período de prueba muy largo (varios meses) para crear una situación de bloqueo. Para que esto funcione, deberá tener un período de gracia en el que el software advierta al usuario de que el pago será necesario en breve. Antes del período de gracia, tendrá un mayor éxito si el software no dice nada acerca del período de prueba.

Ya sea que elija o no creas en esta afirmación bastante audaz, por supuesto, es totalmente tu decisión. Pero si lo hace, debe tener en cuenta que cuanto menos se use su aplicación, más corto será el período de prueba. También es muy importante que el pago sea muy rápido y fácil para el usuario (tan poca entrada de datos y tan pocos clics como sea posible).

Si tiene dudas sobre el uso de la aplicación, debe elegir un período de prueba muy corto. Según mi experiencia, obtendrá mejores resultados si la aplicación guarda silencio sobre el hecho de que está en período de prueba en este caso.

Aunque es efectiva para fines de licencia, muchas personas consideran que las características de "Llamar a casa" son una amenaza a la privacidad. Personalmente, no estoy de acuerdo con la idea de que esto sea perjudicial para un cliente que está dispuesto a pagar por el software que está utilizando. Por lo tanto, sugiero que se implemente un esquema de licencias donde la aplicación verifique el estado de la licencia (prueba, pagado) de forma regular y ayude al usuario a pagar el software cuando sea el momento. Sin embargo, esto podría ser excesivo para una pequeña aplicación de utilidad.

Para aplicaciones de utilidad muy pequeñas o incluso simples, defiendo que el pago por adelantado sin período de prueba es el más efectivo.

En cuanto a la seguridad de la solución, tiene que hacerlo proporcional al esfuerzo de desarrollo. En mi línea de trabajo, la seguridad es muy crítica porque hay socios y distribuidores involucrados, y porque la inversión hecha en desarrollo es muy alta. Para una aplicación de utilidad pequeña, tiene más sentido fijar el precio correcto y confiar en los usuarios honestos que pagarán por el software que satisfaga sus necesidades comerciales.

Answer 2

En este tipo de circunstancias, realmente no creo que importe lo que haces. Si tienes algún tipo de protección, detendrá al 90% de tus usuarios. El otro 10%: si no quieren pagar por su software, encontrarán la forma de evitarlo sin importar lo que hagan.

Si quiere algo un poco menos obvio, puede poner un archivo en System32 que suene como un archivo de sistema que la aplicación comprueba la existencia en el lanzamiento. Eso puede ser un poco más difícil de rastrear.

Answer 3

No tiene mucho sentido hacer complicados esquemas de protección. Básicamente una de estas dos cosas sucederá:

1. Su aplicación no es lo suficientemente popular, y nadie la rompe.

2. Su aplicación se vuelve popular, alguien la rompe y la libera, y cualquiera que no tenga conocimiento puede simplemente descargar esa grieta si quiere engañarlo.

En el caso de # 1, no vale la pena poner un gran esfuerzo en el esquema, ya que es posible hacer una o dos personas más compran su aplicación. En el caso del n. ° 2, no vale la pena esforzarse mucho porque alguien lo descifrará de todos modos, y el esfuerzo se desperdiciará.

Básicamente mi sugerencia es simplemente hacer algo simple, como lo que ya eres, y eso es igual de efectivo. Las personas que no quieren engañar/robar pagarán, las personas que quieran engañarlo lo harán independientemente.

Answer 4

Si está alojando su página de inicio en un servidor que usted controla, puede hacer que la versión de prueba descargable de su software se compile automáticamente en un nuevo binario todas las noches. Esta compilación reemplazará un valor de fecha y hora codificado en su programa para cuando expire el software. De esa forma, la única forma de "hacer trampa" es cambiar la fecha en su computadora, y la mayoría de las personas no lo hará debido a los problemas que creará.

Answer 5

Si usted está planeando para continuar el desarrollo de su software, es posible considerar el modelo de rescate:

http://en.wikipedia.org/wiki/Street_Performer_Protocol

En esencia, se desarrollan mejoras en el software, y luego pedir una cierta cantidad de donaciones antes libéralos (sin ningún DRM).

Answer 6

Una forma de hacerlo que es fácil para el usuario, pero no para usted es codificar la fecha de caducidad y hacer nuevas versiones del instalador de vez en cuando ... :)

Si yo fuera usted sin embargo, no lo haría más avanzado de lo que ya estás haciendo. Como dices, solo cuesta $ 10, y si alguien realmente quiere descifrar tu sistema, lo hará sin importar lo complicado que sea.

Puede hacer una versión un poco más avanzada de su esquema requiriendo una conexión de red y permitiendo que un servidor genere la clave de prueba. Si haces algo similar al signo (hash (unique_computer_id + when_to_expire)) y dejas que la aplicación compruebe con una clave pública que tu servidor ha firmado la fecha de caducidad, debería requerir un truco "real" para eludir.

De esta manera puede almacenar el lado del servidor de la identificación única y negarse a generar una fecha de caducidad más de una o dos veces. No estoy seguro de qué usar como ID único, pero debería haber alguna manera de obtener algo útil de Windows.

Answer 7

Pruebe el Shareware Starter Kit. Fue desarrollado mi Microsoft y puede tener algunas otras características que desee.

http://msdn.microsoft.com/en-us/vs2005/aa718342.aspx

Answer 8

estoy enfrentando el mismo problema con una aplicación que estoy vendiendo a un precio muy bajo también.

Además de ofuscar la aplicación, se me ocurrió un sistema que usa dos claves en el registro, una de las cuales se usa para determinar el momento de la instalación, la otra es la clave de licencia real. Las claves se nombran oscuramente y una clave faltante indica alteración de la instalación.

Por supuesto, eliminar ambas claves y volver a instalar la aplicación volverá a iniciar el tiempo de evaluación.

Pensé que no importa de todos modos, ya que alguien que quiera descifrar la aplicación tendrá éxito al hacerlo, o encontrará una grieta por alguien que haya tenido éxito en hacerlo.

Así que al final solo estoy logrando el objetivo de que no sea muy fácil crackear la aplicación, y esto es lo que, supongo, impedirá que el 80-90% de los clientes lo haga. Y después de todo: como la aplicación se vende a un precio muy bajo, no hay ninguna justificación para invertir más tiempo en este tema de lo que ya tengo.

Answer 9

acaba de ser bueno con la licencia. explique de antemano que esta es su pasión y un hijo de su trabajo. dale a la gente la oportunidad de hacer lo correcto. si alguien quiere piratearlo, eventualmente sucederá. Todavía recuerdo mi desesperación al ver mis libros en bittorrent, pero es algo con lo que tienes que lidiar. No caiga en la piratería casual (lo que está haciendo ahora suena bien) pero no paralice la cosa más allá de eso. Todavía creo que hay suficiente gente honesta para hacer que un esfuerzo de codificación con fines de lucro valga la pena.

Answer 10

No tiene la evaluación en función de "días desde la instalación", sino la cantidad de días utilizados, o la cantidad de veces que se ejecutó o algo similar. Las personas tienden a descargar shareware, lo ejecutan una o dos veces y luego lo olvidan durante unas semanas hasta que lo necesiten nuevamente. Para entonces, la versión de prueba puede haber expirado y, por lo tanto, solo han tenido algunos intentos para engancharse al uso de su aplicación, aunque la hayan tenido instalada por un tiempo. El número de días/activación en cambio les permite adquirir el hábito de usar su aplicación para una tarea, y también hace una venta más fuerte (es decir, usted ha usado esta aplicación 30 veces ...).

Mejor aún, la limitación de las funciones funciona mejor que el tiempo de espera. Por ejemplo, tal vez su aplicación de fotografía podría limitar al usuario a imágenes de 1 megapíxel, pero déjelos usar durante el tiempo que lo desee.

Además, considere valorar su aplicación a $ 20 (o $ 19.95). A menos que ya haya implementado un micropago (como iPhone store o XBoxLive o algo así) las personas tienden a sentir aversión por comprar cosas en línea por debajo de un cierto punto de precio (alrededor de $ 20 dependiendo del tipo de aplicación), y la gente asume de manera inconsciente algo es barato, no debe ser muy bueno. En realidad, puede aumentar su tasa de conversión con un precio más alto (hasta un punto por supuesto).