Trialware/stratégies de licence

Question

J'ai écrit un utilitaire pour les photographes que je prévois de vendre en ligne pas cher (10 $). Je voudrais permettre à l'utilisateur d'essayer le logiciel pendant environ une semaine avant de demander une licence. Puisqu'il s'agit d'un projet personnel et que le logiciel n'est pas très cher, je ne pense pas que l'achat des services de fournisseurs de licences professionnels en vaille la peine et je suis en train de lancer le mien.

Actuellement, l'application recherche une clé de registre contenant une chaîne cryptée qui spécifie quand l'essai expire ou qu'elle a une licence valide. Si la clé n'est pas présente, une clé de période d'essai est créée.

Donc tout ce que vous auriez besoin de faire pour obtenir une autre semaine gratuitement est de supprimer la clé de registre. Je ne pense pas que beaucoup d'utilisateurs feraient cela, surtout quand l'application est seulement 10 $, mais je suis curieux de savoir s'il existe une meilleure façon de le faire qui n'est pas onéreuse pour l'utilisateur légitime. J'écris normalement des applications Web et je n'ai pas traité ce genre de choses auparavant.

L'application est en .NET 2.0, si cela est important.

Answer 1

EDIT: Vous pouvez rendre votre schéma de licence actuel beaucoup plus difficile à résoudre en stockant les informations de registre dans l'autorité de sécurité locale (LSA). La plupart des utilisateurs ne seront pas en mesure de supprimer vos informations clés à partir de là. Une recherche de LSA sur MSDN devrait vous fournir les informations dont vous avez besoin. Les opinions sur les régimes de licences varient d'un individu à l'autre, plus chez les développeurs que chez les groupes d'utilisateurs spécifiques (comme les photographes). Vous devriez inspirer profondément et essayer de voir ce que votre utilisateur cible accepterait, étant donné le besoin d'affaires que votre application résoudra.

Ceci est mon opinion personnelle sur le sujet. Il y aura des personnes vocales qui ne sont pas d'accord.

La réponse à cette question dépend grandement de la manière dont votre application doit être utilisée. Si vous pensez que l'application sera utilisée plusieurs fois par jour, vous bénéficierez le plus d'une très longue période d'essai (plusieurs mois), pour créer une situation de blocage. Pour que cela fonctionne, vous devrez avoir une période de grâce où le logiciel avertit l'utilisateur que le paiement sera bientôt nécessaire. Avant la période de grâce, vous aurez plus de succès si le logiciel est silencieux sur la période d'essai.

Que vous choisissiez ou non de croire en cette déclaration plutôt audacieuse, c'est bien entendu à vous de décider. Mais si vous le faites, vous devriez réaliser que moins votre demande sera utilisée, plus la période d'essai devrait être courte. Il est également très important que le paiement soit très rapide et facile pour l'utilisateur (aussi peu de données que possible et aussi peu de clics que possible).

Si vous n'êtes pas sûr de l'utilisation de l'application, vous devez choisir une période d'essai très courte. Selon mon expérience, vous obtiendrez de meilleurs résultats si la demande est muette sur le fait qu'elle est en période d'essai dans ce cas.

Bien que efficace à des fins de licence, les fonctions «Appel à la maison» sont considérées comme une menace pour la vie privée par de nombreuses personnes. Personnellement, je ne suis pas d'accord avec l'idée que c'est un mauvais choix pour un client qui est prêt à payer pour le logiciel qu'il utilise. Par conséquent, je suggère de mettre en œuvre un système de licences où l'application vérifie régulièrement le statut de la licence (essai, payant) et aide l'utilisateur à payer pour le logiciel lorsqu'il est temps. Cela pourrait être exagéré pour une petite application utilitaire, cependant.

Pour les applications utilitaires très petites, ou même simples, je soutiens que le paiement initial sans période d'essai est le plus efficace. En ce qui concerne la sécurité de la solution, vous devez la rendre proportionnelle à l'effort de développement. Dans mon domaine d'activité, la sécurité est très importante car il y a des partenaires et des concessionnaires impliqués, et parce que l'investissement dans le développement est très élevé. Pour une petite application utilitaire, il est plus logique de fixer le prix juste et de compter sur les utilisateurs honnêtes qui paieront pour le logiciel qui répond aux besoins de leur entreprise.

Answer 2

Dans ce genre de circonstances, je ne pense pas vraiment que ce que vous faites soit important. Si vous avez une sorte de protection, cela arrêtera 90% de vos utilisateurs. Les 10% restants - s'ils ne veulent pas payer pour votre logiciel, ils trouveront un moyen de contourner la protection, peu importe ce que vous faites.

Si vous voulez quelque chose d'un peu moins évident, vous pouvez mettre un fichier dans System32 qui sonne comme un fichier système que l'application vérifie l'existence de au lancement. Cela peut être un peu plus difficile à traquer.

Answer 3

Il n'y a pas grand intérêt à faire des schémas de protection complexes. Fondamentalement l'une des deux choses se produira:

1. Votre application n'est pas assez populaire, et personne ne la fissure. Votre application devient populaire, quelqu'un la craque et la libère, alors n'importe qui avec aucune connaissance peut simplement télécharger cette fissure si elle veut vous tromper.

Dans le cas de # 1, il ne vaut pas mettre beaucoup d'efforts dans le régime, parce que vous pourriez faire une ou deux personnes supplémentaires achètent votre application. Dans le cas de # 2, ça ne vaut pas la peine de faire beaucoup d'efforts parce que quelqu'un va le casser de toute façon, et l'effort sera gaspillé. Fondamentalement, ma suggestion est de faire quelque chose de simple, comme vous le faites déjà, et c'est tout aussi efficace. Les gens qui ne veulent pas vous tromper/voler vous paieront, les gens qui veulent vous tromper vont le faire malgré tout.

Answer 4

Si vous hébergez votre page d'accueil sur un serveur que vous contrôlez, vous pouvez faire en sorte que la version d'essai téléchargeable de votre logiciel compile automatiquement tous les soirs un nouveau fichier binaire. Cette compilation remplacera une valeur datetime codée en dur dans votre programme pour quand le logiciel expire. De cette façon, la seule façon de "tricher" est de changer la date sur votre ordinateur, et la plupart des gens ne le feront pas à cause des problèmes qui vont créer.

Answer 5

Si vous envisagez de continuer à développer votre logiciel, vous pouvez envisager le modèle de rançon:

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

Essentiellement, vous développez des améliorations du logiciel, puis demander une certaine quantité de dons avant les libérer (sans DRM).

Answer 6

Une façon de le faire qui est facile pour l'utilisateur, mais pas pour vous est de coder en dur la date d'expiration et faire de nouvelles versions de l'installateur chaque maintenant et puis ... :)

Si je vous cependant, je ne le ferais pas plus avancé que ce que vous faites déjà. Comme vous dites que c'est seulement 10 $, et si quelqu'un veut vraiment casser votre système, il le fera, peu importe comment vous le compliquez.

Vous pouvez faire une version légèrement plus avancée de votre schéma en demandant une connexion réseau et en laissant un serveur générer la clé de test. Si vous faites quelque chose le long des lignes de signe (hash (unique_computer_id + when_to_expire)) et que l'application vérifie avec une clé publique que votre serveur a signé la date d'expiration, elle doit exiger un "vrai" hack pour contourner.

De cette façon, vous pouvez stocker le côté serveur de l'identifiant unique et refuser de générer une date d'expiration plus d'une ou deux fois. Vous ne savez pas quoi utiliser comme ID unique, mais il devrait y avoir un moyen d'obtenir quelque chose d'utile à partir de Windows.

Answer 7

Essayez le Shareware Kit de démarrage. Il a été développé Microsoft et peut avoir d'autres fonctionnalités que vous voulez.

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

Answer 8

Je suis face à la même problème avec une application que je vends pour un prix très bas aussi bien. Outre l'obfuscation de l'application, je suis venu avec un système qui utilise deux clés dans le registre, l'un d'eux est utilisé pour déterminer cette heure d'installation, l'autre la clé de licence réelle. Les clés sont nommées obscurément et une clé manquante indique une falsification de l'installation.

Bien sûr, la suppression des deux clés et la réinstallation de l'application redémarrent le temps d'évaluation. Je me suis dit que ce n'est pas grave, car quelqu'un qui veut pirater l'application va réussir à le faire, ou trouver un crack par quelqu'un qui a réussi à le faire. Donc, au final, je ne parviens qu'à rendre l'application TROP facile, ce qui, je suppose, empêchera 80 à 90% des clients de le faire. Et après tout: comme l'application est vendue à un prix très bas, il n'y a aucune raison pour moi d'investir plus de temps dans ce problème que je l'ai déjà fait.

Answer 9

juste être cool sur la licence. expliquez d'avance que c'est votre passion et un enfant de votre travail. donner aux gens une chance de faire la bonne chose. si quelqu'un veut le pirater, cela arrivera éventuellement. Je me souviens encore de mon désespoir en voyant mes livres sur bittorrent, mais c'est quelque chose que vous devez faire avec. Ne cédez pas à la piraterie occasionnelle (ce que vous faites maintenant semble bien), mais ne paralysez pas la chose au-delà de cela. Je crois toujours qu'il y a assez de gens honnêtes pour faire un effort de codage à but lucratif.

Answer 10

Ne pas avoir l'évaluation basée sur "jours depuis l'installation", au lieu de faire le nombre de jours utilisés, ou le nombre de fois couru ou quelque chose de similaire. Les gens ont tendance à télécharger le shareware, à l'exécuter une ou deux fois, puis à l'oublier pendant quelques semaines jusqu'à ce qu'ils en aient besoin. À ce moment-là, la période d'essai a peut-être expiré et ils n'ont donc eu que quelques tentatives pour utiliser votre application, même s'ils l'ont installée depuis un moment. Le nombre d'activation/jours leur permet à la place de prendre l'habitude d'utiliser votre application pour une tâche, et rend également la vente plus forte (c'est-à-dire que vous avez utilisé cette application 30 fois ...).

Encore mieux, en limitant les fonctionnalités fonctionne mieux que le dépassement de délai. Par exemple, peut-être votre application de photographie pourrait limiter l'utilisateur à des images de 1 mégapixel, mais laissez-les l'utiliser aussi longtemps qu'ils le veulent.

En outre, envisagez de tarifer votre application à 20 $ (ou 19,95 $). Les gens ont tendance à avoir une aversion à acheter des choses en ligne en dessous d'un certain prix (qui est autour de 20 $ selon le type d'application), et les gens assument subconscient si quelque chose est bon marché, ça ne doit pas être très bon. Vous pouvez réellement augmenter votre taux de conversion avec un prix plus élevé (jusqu'à un point bien sûr).