Software de prueba/estrategias de licencia [cerrado]

Question

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

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

Entonces, todo lo que necesita hacer para obtener otra semana gratis es eliminar la clave de registro. No creo que muchos usuarios hagan eso, especialmente cuando la aplicación cuesta solo $10, pero tengo curiosidad por saber si hay una mejor manera de hacerlo que no sea onerosa para el usuario legítimo.Normalmente escribo aplicaciones web y no me he ocupado de estas cosas antes.

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

Answer 1

EDITAR:Puede hacer que su esquema de licencia actual sea mucho más difícil de descifrar almacenando la información de 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 brindarle la información que necesita.

Las opiniones sobre los esquemas de licencias varían según cada individuo, más entre los desarrolladores que entre grupos de usuarios específicos (como los fotógrafos).Debe respirar profundamente e intentar ver qué aceptaría su usuario objetivo, dada la necesidad comercial que resolverá su aplicación.

Esta es mi opinión personal sobre el tema.Habrá personas que expresarán su opinión y no estarán de acuerdo.

La respuesta a esto depende en gran medida de cómo espera que se utilice su aplicación.Si espera utilizar la aplicación varias veces al día, lo que más le beneficiará será 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 avise al usuario que pronto será necesario realizar el pago.Antes del período de gracia, tendrá mayor éxito si el software no dice nada sobre el período de prueba.

Si decide creer o no en esta afirmación tan audaz, por supuesto, depende totalmente de usted.Pero si lo hace, debe darse cuenta de que cuanto menos se utilice 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 sencillo para el usuario (la menor introducción de datos y el menor número de clics posible).

Si no está seguro del uso de la aplicación, debería elegir un período de prueba muy corto.En mi experiencia, obtendrá mejores resultados si la aplicación no dice que en este caso se encuentra en período de prueba.

Aunque son eficaces a efectos de concesión de licencias, muchas personas consideran que la función "Llamar a casa" constituye una amenaza a la privacidad.Personalmente, no estoy de acuerdo con la idea de que esto sea malo para un cliente que está dispuesto a pagar por el software que está utilizando.Por lo tanto, sugiero implementar un esquema de licencias donde la aplicación verifique el estado de la licencia (de prueba, pagada) de manera regular y ayude al usuario a pagar el software cuando llegue el momento.Sin embargo, esto podría resultar excesivo para una aplicación de utilidad pequeña.

Para aplicaciones de servicios públicos muy pequeñas, o incluso simples, sostengo que el pago por adelantado sin período de prueba es lo más efectivo.

En cuanto a la seguridad de la solución, hay que hacerla 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 que se hace en el desarrollo es muy alta.Para una aplicación de utilidad pequeña, tiene más sentido fijarle un precio adecuado y confiar en usuarios honestos que pagarán por el software que satisfaga sus necesidades comerciales.

Answer 2

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

1. Tu aplicación no es lo suficientemente popular y nadie la descifra.

2. Tu aplicación se vuelve popular, alguien la descifra y la lanza, luego cualquiera sin ningún conocimiento puede simplemente descargar esa crack si quiere engañarte.

En el caso número 1, no vale la pena poner mucho esfuerzo en el plan, porque podrías hacer que una o dos personas más compren tu aplicación.En el caso número 2, no vale la pena esforzarse mucho porque alguien lo resolverá de todos modos y el esfuerzo será en vano.

Básicamente, mi sugerencia es hacer algo simple, como ya lo haces, y que sea igual de efectivo.Las personas que no quieran engañarte o robarte pagarán, las personas que quieran engañarte lo harán de todos modos.

Answer 3

Si aloja 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 cada noche.Esta compilación reemplazará un valor de fecha y hora codificado en su programa para cuando caduque el software.De esa manera, la única forma de "hacer trampa" es cambiar la fecha en su computadora, y la mayoría de la gente no lo hace debido a los problemas que eso creará.

Answer 4

Pruebe el kit de inicio de Shareware.Fue desarrollado por Microsoft y es posible que tenga otras características que desee.

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

Answer 5

Si planea continuar desarrollando su software, podría considerar el modelo de rescate:

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

Básicamente, usted desarrolla mejoras en el software y luego solicita una cierta cantidad de donaciones antes de lanzarlas (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 crear nuevas versiones del instalador de vez en cuando...:)

Sin embargo, si fuera tú, no lo haría más avanzado de lo que ya estás haciendo.Como usted dice, cuesta solo $ 10, y si alguien realmente quiere piratear su sistema, lo hará sin importar cuán complicado lo haga.

Podrías hacer una versión un poco más avanzada de tu esquema al requerir una conexión de red y dejar que un servidor genere la clave de prueba.Si hace algo como sign(hash(unique_computer_id+when_to_expire)) y deja que la aplicación verifique con una clave pública que su servidor ha firmado la fecha de vencimiento, debería requerir un truco "real" para evitarlo.

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

Answer 7

También me enfrento al mismo problema con una aplicación que vendo a un precio muy bajo.

Además de ofuscar la aplicación, se me ocurrió un sistema que utiliza dos claves en el registro, una de las cuales se utiliza para determinar el momento de la instalación y la otra, la clave de licencia real.Las claves tienen nombres oscuros y una clave faltante indica manipulación de la instalación.

Por supuesto, eliminar ambas claves y reinstalar la aplicación iniciará nuevamente el tiempo de evaluación.

Pensé que no importa de todos modos, ya que alguien que quiera descifrar la aplicación lo logrará, o encontrará un descifrado de alguien que haya logrado hacerlo.

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

Answer 8

simplemente sé tranquilo con la licencia.Explícale desde el principio que esta es tu pasión y es fruto de tu trabajo.dar 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 cedas ante la piratería casual (lo que estás haciendo ahora suena genial) pero no destruyas la cosa más allá de eso.Sigo creyendo que hay suficientes personas honestas para que valga la pena un esfuerzo de codificación con fines de lucro.

Answer 9

No haga la evaluación basada en "días desde la instalación", en su lugar, haga la cantidad de días utilizados, o la cantidad de veces que se ejecutó o algo similar.La gente tiende a descargar shareware, ejecutarlo una o dos veces y luego olvidarlo durante unas semanas hasta que lo vuelve a necesitar.Para entonces, es posible que la versión de prueba haya caducado y, por lo tanto, solo hayan tenido unos pocos intentos para engancharse al uso de su aplicación, a pesar de que la han tenido instalada por un tiempo.En cambio, el número de días/activaciones les permite adquirir el hábito de usar su aplicación para una tarea y también genera una venta más sólida (es decir,has usado esta aplicación 30 veces...).

Aún mejor, limitar las funciones funciona mejor que suspender el tiempo.Por ejemplo, tal vez su aplicación de fotografía podría limitar al usuario a imágenes de 1 megapíxel, pero permitirle usarla todo el tiempo que quiera.

Además, considere ponerle un precio a su aplicación de $20 (o $19,95).A menos que ya exista una configuración de micropagos (como una tienda de iPhone o XBoxLive o algo así), las personas tienden a tener aversión a comprar cosas en línea por debajo de cierto precio (que ronda los $ 20 dependiendo del tipo de aplicación), y la gente asume inconscientemente que si algo es barato, no debe ser muy bueno.De hecho, puedes aumentar tu tasa de conversión con un precio más alto (hasta cierto punto, por supuesto).

Answer 10

En este tipo de circunstancias, realmente no creo que importe lo que hagas.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 una forma de evitar la protección sin importar lo que usted haga.

Si desea algo un poco menos obvio, puede colocar un archivo en System32 que suene como un archivo del sistema cuya existencia la aplicación verifica al iniciarse.Esto puede ser un poco más difícil de localizar.