Question

J'ai écrit un utilitaire pour les photographes que je prévois de vendre en ligne assez bon marché (10 $). J'aimerais permettre à l'utilisateur d'essayer le logiciel pendant une semaine environ avant de demander une licence. Etant donné qu’il s’agit d’un projet personnel et que le logiciel n’est pas très coûteux, je ne pense pas que l’achat des services de fournisseurs de licences professionnels en vaudrait la peine, et je me lance moi-même.

Actuellement, l’application recherche une clé de registre contenant une chaîne chiffrée spécifiant la date d’expiration de la période d’essai ou une licence valide. Si la clé n’est pas présente, une clé de période d’essai est créée.

Il vous suffira donc de supprimer la clé de registre pour bénéficier d'une semaine supplémentaire gratuite. Je ne pense pas que de nombreux utilisateurs le feraient, en particulier lorsque l'application coûte seulement 10 dollars. 's curieux de savoir s'il existe un meilleur moyen de le faire qui ne soit pas onéreux pour l'utilisateur légitime. J'écris des applications Web normalement et je n'ai jamais traité ce genre de choses auparavant.

L'application est dans .NET 2.0, si cela compte.

Était-ce utile?

La solution

EDIT: vous pouvez rendre votre schéma de licence actuel beaucoup plus difficile à craquer en stockant les informations de registre dans l'autorité de sécurité locale (LSA). La plupart des utilisateurs ne pourront pas supprimer vos informations de clé à partir de là. Une recherche de LSA sur MSDN devrait vous donner les informations dont vous avez besoin.

Les opinions sur les régimes de licence varient selon les individus, davantage parmi les développeurs que parmi les groupes d’utilisateurs spécifiques (tels que les photographes). Vous devriez prendre une profonde respiration et essayer de voir ce que votre utilisateur cible accepterait, étant donné le besoin commercial que votre application va résoudre.

Ceci est mon opinion personnelle sur le sujet. Il y aura des individus vocaux qui seront en désaccord.

La réponse à cette question dépend grandement de la manière dont vous envisagez d’utiliser votre application. Si vous prévoyez d’utiliser l’application plusieurs fois par jour, vous bénéficierez au maximum d’une très longue période d’essai (plusieurs mois) afin de créer une situation de blocage. Pour que cela fonctionne, vous devez disposer d'un délai de grâce au cours duquel le logiciel avertit l'utilisateur que le paiement sera bientôt nécessaire. Avant la période de grâce, vos chances de succès seront meilleures si le logiciel ne dit rien sur la période d’essai.

Que vous choisissiez ou non de croire en cette affirmation assez audacieuse, c’est bien sûr à vous de décider. Mais si vous le faites, vous devez savoir que moins votre application sera utilisée souvent, plus la période d’essai sera courte. Il est également très important que le paiement soit très rapide et facile pour l'utilisateur (aussi peu de saisies de données que de clics possible).

Si vous avez des doutes sur l’utilisation de l’application, vous devez choisir une période d’essai très courte. D'après mon expérience, vous obtiendrez de meilleurs résultats si l'application ne dit rien sur le fait qu'elle soit en période d'essai dans ce cas.

Bien qu'efficace aux fins de la gestion de la licence, "Call home". les fonctionnalités sont considérées par beaucoup de personnes comme une menace à la vie privée. Personnellement, je ne suis pas d’accord avec l’idée que c’est une mauvaise chose pour un client qui est prêt à payer pour le logiciel qu’il utilise. Par conséquent, je suggère de mettre en place un système de licence dans lequel l’application vérifie régulièrement l’état de la licence (version d'évaluation, payante) et aide l'utilisateur à payer pour le logiciel au moment opportun. Cela peut toutefois être excessif pour une petite application utilitaire.

Pour les applications utilitaires très petites, voire 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 travail, la sécurité est très critique car des partenaires et des revendeurs sont impliqués et l'investissement dans le développement est très élevé. Pour une petite application utilitaire, il est plus judicieux de choisir le bon prix et de faire confiance aux utilisateurs honnêtes qui paieront le logiciel qui répond à leurs besoins professionnels.

Autres conseils

Il n’est pas utile de mettre en place des systèmes de protection compliqués. En gros, deux choses vont se passer:

  1. Votre application n'est pas assez populaire et personne ne la craque.

  2. Votre application devient populaire, quelqu'un la craque et la publie, puis toute personne sans aucune connaissance peut simplement télécharger cette fissure si elle veut vous tromper.

Dans le cas du n ° 1, cela ne vaut pas la peine de faire beaucoup d'efforts, car vous pourriez obliger une ou deux personnes supplémentaires à acheter votre application. Dans le cas de # 2, cela ne vaut pas la peine de faire beaucoup d’efforts car quelqu'un le craquera quand même, et les efforts seront vains.

En gros, ma suggestion est de faire quelque chose de simple, comme vous l’êtes déjà, et c’est tout aussi efficace. Les gens qui ne veulent pas tricher / voler de vous vont payer, ceux qui veulent tricher vont le faire quand même.

Si vous hébergez votre page d'accueil sur un serveur que vous contrôlez, la version d'évaluation téléchargeable de votre logiciel peut être automatiquement compilée dans un nouveau fichier binaire tous les soirs. Cette compilation remplacera une valeur datetime codée en dur dans votre programme pour l'expiration du logiciel. De cette manière, le seul moyen de "tricher" est de changer la date sur votre ordinateur, et la plupart des gens ne le feront pas à cause des problèmes que cela créera.

Essayez le kit de démarrage Shareware. Il a été développé par Microsoft et peut avoir d’autres fonctionnalités que vous souhaitez.

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

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 vous demandez un certain nombre de dons avant de les publier (sans DRM).

Une façon de le faire facile pour l'utilisateur mais pas pour vous est de coder en dur la date d'expiration et de créer de nouvelles versions du programme d'installation de temps en temps ...:)

Si j'étais vous, je ne le ferais pas plus avancé que ce que vous faites déjà. Comme vous le dites, cela ne coûte que 10 dollars, et si quelqu'un veut vraiment faire craquer votre système, il le fera, quelle que soit sa complexité.

Vous pouvez créer une version légèrement plus avancée de votre schéma en exigeant une connexion Internet et en laissant un serveur générer la clé d'évaluation. Si vous faites quelque chose le long des lignes de signe (hash (unique_ordinateur + id_ quand_à_expirer)) et laissez l'application vérifier avec une clé publique que votre serveur a signé la date d'expiration, vous devrez alors indiquer un "réel". bidouille à contourner.

De cette façon, vous pouvez stocker le serveur de l’id unique et refuser de générer une date d’expiration plusieurs fois. Vous ne savez pas quoi utiliser comme identifiant unique, mais il devrait exister un moyen d'obtenir quelque chose d'utile de Windows.

Je suis confronté au même problème avec une application que je vends également à un prix très bas.

Outre l'obscurcissement de l'application, j'ai mis au point un système qui utilise deux clés dans le registre, l'une servant à déterminer le moment de l'installation, l'autre la clé de licence réelle. Les clés sont nommées de manière obscure et une clé manquante indique une altération de l'installation.

Bien sûr, la suppression des deux clés et la réinstallation de l’application relanceront l’évaluation.

Je pensais que cela importait peu, car quelqu'un qui veut casser l'application réussira à le faire, ou trouvera une faille de quelqu'un qui a réussi à le faire.

En fin de compte, je n’atteins que l’objectif de ne pas trop casser l’application, et c’est ce qui 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’est pas justifié que je consacre plus de temps à cette question que je ne l’ai déjà fait.

soyez simplement cool avec la licence. expliquez au préalable 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 finira par arriver. Je me souviens encore de mon désespoir en voyant mes livres sur BitTorrent, mais c’est quelque chose que vous devez gérer. Ne cédez pas à la piraterie occasionnelle (ce que vous faites maintenant semble génial) mais ne paralysez pas la chose au-delà de cela. Je crois toujours qu'il y a suffisamment de personnes honnêtes pour faire de cet effort de codage à but lucratif une réussite.

L'évaluation ne repose pas sur "jours depuis l'installation", mais sur le nombre de jours utilisés, le nombre de fois exécuté ou quelque chose de similaire. Les gens ont tendance à télécharger des partagiciels, à les exécuter une ou deux fois, puis à les oublier pendant quelques semaines jusqu'à ce qu'ils en aient de nouveau besoin. À ce moment-là, le procès a peut-être expiré. Ils n'ont donc eu que quelques tentatives d'utilisation de votre application, même s'ils l'avaient installée depuis un certain temps. Le nombre d'activations / jours leur permet à la place de prendre l'habitude d'utiliser votre application pour une tâche et de mieux vendre (c'est-à-dire que vous avez utilisé cette application 30 fois ...).

Mieux encore, limiter les fonctionnalités fonctionne mieux que le délai d'attente. Par exemple, votre application de photographie pourrait peut-être limiter l'utilisateur à 1 mégapixel, mais laissez-le l'utiliser aussi longtemps qu'il le souhaite.

Pensez également à attribuer un prix à votre application à 20 USD (ou 19,95 USD). Sauf s'il existe déjà une configuration de micropaiement en place (magasin iPhone ou XBoxLive, par exemple), les gens ont tendance à vouloir acheter en ligne à un prix inférieur à un certain niveau de prix (environ 20 USD selon le type d'application), 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 certain point).

Dans ce genre de situation, je ne pense pas vraiment que ce que vous fassiez 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 votre logiciel, ils trouveront un moyen de contourner la protection, peu importe ce que vous ferez.

Si vous voulez quelque chose de moins évident, vous pouvez placer un fichier dans System32 qui ressemble à un fichier système dont l'application vérifie l'existence au lancement. Cela peut être un peu plus difficile à localiser.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top