Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
What is Software Escrow? Is Software Escrow something you want?
This is where, when a customer purchases the software or a service, a vendor will put their codebase into the control of a third-party with contractual terms that it can be released to the customer should the vendor cease trading.
As a customer buying in a closed-source product from a small vendor where their longevity is unclear it can be a make-or-break on a deal providing some assurance of continuity should they cease trading.
Software escrow is when you nominate a 3rd party company to take possession of your source code. They keep your code safe and don't release it to anyone.
In the event that your company ever goes bankrupt, or closes down, the escrow provider will release your source code to any clients who were using your application (who also usually will an account with the escrow provider).
You will find that if you provide software to large institutions (like Banks, etc) they are likely to demand escrow agreements so they can ensure that if in the future something goes terribly wrong in your company, they aren't left with an app that can't be supported.
Usually the escrow provider will perform some form of validation on your source code to confirm that the code you have provided is enough to produce a fully compiled and working copy of your application. Often this validation takes the form of a demonstration of the full build process from the provided media.
The cases under which the escrow provider can release your code will vary slightly from provider to provider and your specific contract with them, but will usually only be for outright company closures. They don't usually just give out your source code just because you've decided not to fix a particular bug in your next release.
With regards to whether or not escrow is something you want, it depends on which side of the fence you're on. If you are development company selling software, then only do it if you client requires it. Escrow providers charge a fee, and it can be time consuming to ensure that the escrow is kept regularly up to date (particularly if you don't have full clean build scripts).
If you are buying software, consider what would happen if the company you are buying from went bankrupt. Is the software you are buying so critical that you wouldn't just be able to switch for something new? Also, are you big enough, that you could realistically take on the cost of getting your own (or new) developers to maintain the application.
softwareescrowguide.com is but a google away. The short version - software escrow is where a third party has a copy of a software product's source code, guaranteeing that, say, a business using that software product can continue development of the product if the vendor goes under.
Is it something you want? Depends on who you are and what you want, I guess.
It's something the purchaser definitely wants. Is it something the developer wants? Probably, in that it will help make the deal. The catch is to write the contract so that you retain control as long as it makes sense for you to retain control.
Software Escrow generally refers to a provision in Software licensing agreements that allow the party the licenses the software to acquire the source code in certain circumstances, typically bankruptcy (or something similar) of the party that wrote the software. Often times a neutral third party will "hold" the code in escrow and be the arbiter of whether they should give the code to the licensee.
They tend to be used when small companies license software to big companies since big companies want to protect themselves incase of bankruptcy of a small company. In practice, these things cost money and time. A neutral third party will charge money for the service and the team the wrote the software will need to update the escrow account periodically.
As to whether you want it -
If you are a software vendor, then not unless the client asks and only then if you have to. It is a pain to manage.
If you are licensing the software, you probably don't care unless you are a large company with a lot of resources. In practice, if you need to maintaining someone else's code it not particularly practical
From a user's perspective: If the user does not have access to an application's source code, software escrow is the insurance policy that in the event of a "disaster" the escrow agent will release a copy of the source code to the user. The user needs to determine the risk associated with not being able to get the business critical or mission critical software maintained as their business needs change.
From a developer's perspective: There are two perspectives.
1) It is a tool to ensure their intellectual property (the source code) is kept in-house unless a "disaster" occurs when the escrow agent will release a copy of the source code to the user. 2) It can also be used as a tool to help marketing their application.
"Disasters" or release events are explicitly defined in the escrow agreement.
Software Escrow Guardians is an escrow agent and has been providing software escrow services for nearly twenty years. The company has an escrow agreement template suitable as a framework for an escrow service involving an individual user and a developer. It also has an escrow agreement template suitable for multiple users and a developer.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
What is your experience from real-life, who should be responsible for a choice of agile planning tools to be used by the agile/scrum team?
Team should decide whether a tool is to be used; but I think suggestion most commonly comes from the Scrum Master as (s)he is most likely to have experience using tools. Any team member can suggest tools of course.
Anyway, my feeling is that given Scrum philosophy, the whole team needs to agree on this in my opinion. Usually things start with "let's try this, see if it works", and is refined along the way, just like anything else in Scrum. It should not be top-down enforcement, same way as using Scrum methodology should be team decision, not handed down from top.
Great question. There is a lot of value to embracing the self organization of agile and allow the teams to choose their tools. However, there are usually constraints imposed by the business. For instance, the business may not be able to support/want each scrum team rolling its own scm solution. The more established the business, the more constraints and push back. Even established businesses can change. Don't be afraid to question a constraint if the team can justify the change.
Agile planning tools will follow these same rules. The business may have a full software life cycle management solution in place. This solution may or may not have an agile module. However the business may have reasons (regulated industries for example) to require that design inputs / outputs are documented in the life cycle management software solution they have. The business usually needs to balance keeping the teams happy / productive with staying in business.
I don't think there will be a black or white solution (unless you are one of the first devs at a start up). Agile teams will need to embrace the open communication. If the tools are impediments the business needs to know.
I'm going to make simple answer, because I actually think this is a simple question.
The WHOLE team is responsible of that.
Let me explain a little bit.
We first have to accept that every context is different, so this is not a biblical answer.
Let's say you start your project. I always love starting my projects/products with nothing.
NOTHING. Sometimes, just a task board, with todo, in process, done.
That's it. And I fill the todo column.
And that's all my point: I build my agile process incrementally and iteratively.
Why should I have to create a Burndown Chart? Because literacy tells me so?
Hell no, because, maybe, eventually, at some point, I might need to have some visibility for my planning.
Same with everything. And never forget, Agile tools serve as a support for the process.
So, you're a PO, and you're tired of the simple todo list, and fell the need to do a Backlog?
2 Solutions:
-- you're already in a highly mature team, you just have to tell everybody during stand up meeting that you're taking the lead on it. Eventually it'll need a retrospective to accept that.
-- you're migrating from a V, W or whatever product management model. Then, wait the retrospective and ask everybody and explain your pain. Give solution (here the backlog), and ask for a shot.
So, you're a scrum master, and you find a "systemic bug" in your process, let's take the classic one: Too many bugs. Then take the lead to promote TDD, or systematic testing.
So, you're tech lead and feel... Well, you understood me.
My point is: never over tool your process at the beginning. Build the process slowly, add tools slowly, when you need them. And by doing so, don't worry, people will take reponsability to create the tool and add it to the process, to lobby it to the rest of the team.
Hope this helps.
What is your experience from real-life, who should be responsible for a choice of agile planning tools to be used by the agile/scrum team?
Well my experience from real life is that, certain "Agile Planning Tools" tools were handed to the Scrum Teams before they even started their Sprints, fortunately the Teams liked it, but we were free to inspect and adapt to using something else if it did not work out for us.
I think it should be in the Teams power to use, accept or reject a tool in a completely transparent way. They could very well take suggestions from the Scrum Master or an Agile Coach because (s)he may have more knowledge in the Agile Tools area. Secondly, the Team should be courageous enough to have a collective discussion and decide on using a tool based on the Agile Coach's suggestions, and see how it works for them, and adapt and adjust from using it if it does not work for them (productivity-wise)
The bigger question which you did not ask is, how do you manage the differing tool set chaos when the company scales into having multiple Scrum Teams who use their own Agile Planning tools?.
Well, I think realistically, in a scaling agile software company, a little bit of uniformity in tool usage across Scrum Teams can be beneficial and productive but that may be directed by the self organised enterprise project Team instead of each Team having their own tools. Off course there can be exceptions, where certain teams are working on completely different features and they need a totally different tool set, but the benefit of using common Agile tools will help scaling projects view their Teams progress without much of change in gear.
The above can be done by having a Technical, Infrastructure and Process Tools Story which not many companies use or create. This EPIC story can be the starting point for discussion of what Agile tools and other tools can be used, to have a little uniformity within the project. While deriving the EPIC story the whole project team could be involved around project kick off, if it is too big then 1 - 2 members can represent each of the Teams. The story could be broken down exactly like business user stories, and modified accordingly and calibrated, estimated and prioritized through out the project from an infrastructure and tools stand point. Let me know if you want me to go in more detail about this.
Ideally the scrum master, but they may inherit some legacy which needs some evolution.
If the organisation is new to Scrum, then an experienced Scrum Master should be able to advise the best tools for the maturity of the team.
Typically, if a team already has some tools, a scrum master can adapt what is already there, regardless of the organisational choice. Some of the best boards are on Excel Spreadsheets and work just as well as a purpose built system. Every technology creates 'constraint'. So, it is up to the scrum master to support the business in ensuring the tools are fit for purpose and delivering the value the team needs.
Typical mistake I experienced as a coach was decision made by managers or even senior management according some study done by 'specialist' or even external consultant. Those people are many times not aware about what, how and who will yse the tool. In this case I see dissapointed people once they should use chosen tool.
You have to consider who is going to use the tool for most of the day. Team members are better target community. Tool must support ScrumMaster role due to daily work she needs to done. Include experienced product owners into selection of the tool as tools have different support for planning that is necessary to be usable.
Consider your organization (complexity of products, projects, number of locations)
The responsibility (and authority) of choosing a planning tool should be with the team. Often the surrounding organization will have a stake in terms of licensing costs and consistency across teams. Depending on how autonomous your teams are it should be OK for them to chose their own tool, though.
Within the team, the product owner usually has the highest stake in the decision, since he will be the one who is going to use it the most for continuous refinement and prioritizing. The rest of the team often only interacts with the planning tool during refinement and planning sessions once or twice each sprint. So he is usually the one driving the decision-making, but should definitely involve the team.
If the chosen tool also includes a board that the team uses daily to track their work, they will want to have more of a say in the choice.
I'm working on a project where we collect payments from users using credit/debit/PayPal payments.
The service is taking payments from users on behalf of a 3rd party organisation.
Once we take the payment, minus fees, we want to transfer the amount to the organisations bank account.
For now, what we can do is pay the organisation using Online Banking BACS bank transfer.
But I would like to know if there is a way to do this automatically using an API.
If we need to somehow register the 3rd parties bank account details before making transfers, this is fine.
We just want to automate the whole process, since at the moment the transfer is a manual step.
Are there any gateways or APIs I can use for this? In the UK?
As this is still un-answered I'll throw my hat into the ring.
For the benefit of non-UK users, the UK has a central clearing system called Bacs, which is run by the major banks in the country. However, companies can also makes submissions directly to that clearing system, by using Bacs Software.
There are a number of companies that sell on-premise and online services/APIs that allow you to send money directly via Bacs (and collect Direct Debits).
DISCLAIMER: I currently work for a software company (Bottomline Technologies) which sells a Bacs API - I won't mention the product name and to see alternative companies you can simply Google for 'bacs software api'
Hope this helps
You are going in the wrong direction. You should talk to payment processors (which may or may not include your bank) about the business considerations, which probably are more important than the technological considerations. Generally you can expect something somewhat reasonable that you will (after fiddling with it enough) be able to convince to work. It doesn't matter whether this involves some sort of api library, soap calls, or other communication method.
If you honestly consider having the technological considerations more important than the business considerations, then just go with Paypal and don't write your own shopping cart stuff at all. This is easier to use and will do more of the heavy lifting for you, but which will also probably charge you more.
Once you create a real shopping cart and start handling payments yourself (i.e. taking in CC information and sending it to a payment processor), you start getting into a mess of legal and technical concerns involving PCI compliance and the like, which will apply regardless of your choice of payment processor*.
*This is US-specific, but I bet the UK has something similar.
Rather than using a third party code escrow service, I was thinking about giving customers our source code in encrypted form and then have my attorney produce a document that contains the password for decrypting the source and the conditions under which it is released.
The benifits of doing it this way are not just cost. Would you be shocked to hear if one of the big escrow services was hacked?
The implementation could be very simple. A Win32 commandline program could be written that uses some obscure combination of AES, random nonces, etc to encrypt and decrypt a file using a password. This program is then packaged with the encrypted source file and instructions and made available to customers via any number of methods. So customers already have the source. All they need is the password to decrypt it.
To obtain the password, the customer would simply contact the legal group acting as the escrow agent and claim that one of the conditions for releasing the code has been reached such as bankruptcy, the product was discontinued, etc.
Has anyone done this or do you see a flaw in the system?
The escrow system is also a guarantee that the source code will be delivered. What if the encrypted file or media is found to be corrupted when decryption is attempted? What if the key is not correct? The service needs to be provided as specified in the escrow contract at a time when you will not be able to provide the code yourself. How far will your lawyer go to ensure that the client's contract is fulfilled? That is basically what you are paying an escrow service for.
Another option is to simply release them the code as it is while you are still a going concern for a price increase equivalent to the escrow fees and pocket the escrow fees. What is the risk in giving them the source code now?
Part of the escrow account process is a legal and financial guarantee that, even if both you and the escrow provider are struck by lightning or hit by a falling meteor or toilet seat from a deorbited space station, the code will be available to the client. We've been required by military contractors to hand over source for our compiler (that we develop) to escrow so that they can use it if we go out of business.
Also, compared to the price of an attorney, I'd think that escrow would be relatively cheap. Just factor it in to your bid if it's a client requirement.
I was asked implement a licensing schema for our product. They are very expensive products with few customers sparsely distributed around the world and basically every one of them has a design environment (a windows application installed on single windows machines, from 1 to 150 client machines per customer) and a web server that hosts production environment (1 to 8 machines per customer). Our product is licensed for server usage so customers can use any number of clients; we've decided not to license the server part (because it's subject to SLA agreements) but only the client, because, after some time without capability to use the client the system becomes basically useless.
Our basic assumption is that the customer is "honest enough" and only thing we would like to cover is stopping the client design environment if not properly licensed with a time expiration license.
I've evaluated different licensing product and they are or too expensive or too difficult to manage, so I've come up with this simple solution:
The license will be a simple signed XML file, signed using the standard XML Signature feature of w3c, using a private key that will be given to the admin department on a USB key; if they lose of copy it then the licensing schema will fail but it will be their fault
The client will open the license file on startup and check its validity using a public key embedded in the binaries
If license XML is valid and the data in it (expiration date and product name) are correct than the designer work; if not, an appropriate message will be shown
Any ideas about possible problems or how to improve the scenario?
I have yet to see a licensing scheme that wasn't broken in a few weeks provided there was sufficient interest. Your scheme looks very good (though be certain that if someone really wants to, they'll break it).
Whatever you do, you should follow Eric Sink's advice:
The goal should simply be to "keep
honest people honest". If we go
further than this, only two things
happen:
We fight a battle we cannot win. Those who want to cheat will succeed.
We hurt the honest users of our product by making it more difficult to
use.
Since you're implementing a license scheme for a program designed for corporate use, you can go even simpler and just keep some kind of id and expiration date along with a simple signature on the client and refuse to start if the license expired or signature failed. It's not that hard to break it, but no licensing scheme is and if you consider your customers honest, this will be more than enough.
It's not completely clear from your question how your scheme works. Does every instance of the client software have a different key? How long does the license last? Do you have a different key per customer? How is the license paid for? How is a license renewed?
If you are trying to control numbers of usages of the client code then only the first one above will do it.
At the end of the day, in the world you appear to inhabit, I suspect that you are going to have to live in trust that there are no blatant infringements of your license. Most decent sized organisations (which it sounds like your customers would be) have a responsibility not to infringe which can lead them to serious consequences if they break the license agreements. They will be audited on it periodically too and you probably have some statutory rights to go and check their usage (if not you should write it into your license agreement).
Where it becomes very dangerous for you is if the contents of the USB keys find their way onto the web. In that regard any scheme which uses a published key is vulnerable to a wilful disclosure of the secrets.
I'm certain there is a lot of literature on this subject, so it is probably worth you continuing your research.
BTW I'm not sure about your reference to SLAs in the middle part about your server licensing. Licensing and SLAs are very different. A license is the clients obligation an SLA is yours.
if you give them the private key, what is to prevent them from creating more signed XML files instead of buying additional licenses from you? or is it a site-license? if the latter, what is to prevent them from creating licenses for other people/sites?
in general, development licensing schemes tie the license to a particular machine using the MAC address and/or hard drive serial number, or sometimes just with an activation key (which is usually just a hash of the hardware info)
and typically the encoding is done with a private key that you keep secret, and the license is verified with a public key; the client never has the private key, otherwise they can - if so inclined - generate their own licenses
I agree with Steven A. Lowe (I don't have 15 reputation, so I couldn't vote him up).
This also seems too complicated. Do you want it to be unbreakable? you can't. Any sufficiently motivated guru would find a way around it.
Sometimes a simple licensing scheme works best:
I suggest a simple encrypted file that the admin puts somewhere the client can access - it would contain the client name and expiry date. You use the client name from the file in all printed reports (that's what most PHBs care About, that way they would not use the license that prints somebody else's name).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I am curious about how do you protect your software against cracking, hacking etc.
Do you employ some kind of serial number check? Hardware keys?
Do you use any third-party solutions?
How do you go about solving licensing issues? (e.g. managing floating licenses)
EDIT: I'm not talking any open source, but strictly commercial software distribution...
There are many, many, many protections available. The key is:
Assessing your target audience, and what they're willing to put up with
Understanding your audience's desire to play with no pay
Assessing the amount someone is willing to put forth to break your protection
Applying just enough protection to prevent most people from avoiding payment, while not annoying those that use your software.
Nothing is unbreakable, so it's more important to gauge these things and pick a good protection than to simply slap on the best (worst) protection you are able to afford.
Simple registration codes (verified online once).
Simple registration with revokable keys, verified online frequently.
Encrypted key holds portion of program algorithm (can't just skip over the check - it has to be run for the program to work)
Hardware key (public/private key cryptography)
Hardware key (includes portion of program algorithm that runs on the key)
Web service runs critical code (hackers never get to see it)
And variations of the above.
Whatever route you go, charge a fair price, make it easy to activate, give free minor updates and never deactivate their software. If you treat your users with respect they'll reward you for it. Still, no matter what you do some people are going to end up pirating it.
Don't.
Pirates will pirate. No matter what solution you come up with, it can and will be cracked.
On the other hand, your actual, paying customers are the ones who are being inconvenienced by the crap.
Make it easier to buy than to steal. If you put mounds of copy protection then it just makes the value of owning the real deal pretty low.
Use a simple activation key and assure customers that they can always get an activation key or re-download the software if they ever lose theirs.
Any copy protection (aside from online-only components like multiplayer games and finance software that connects to your bank, etc.) you can just assume will be defeated. You want downloading your software illegally, at the very least, to be slightly harder than buying it.
I have a PC games that I've never opened, because there is so much copy protection junk on it that it's actually easier to download the fake version.
Software protections aren't worth the money -- if your software is in demand it will be defeated, no matter what.
That said, hardware protections can work well. An example way it can work well is this: Find a (fairly) simple but necessary component of your software and implement it in Verilog/VHDL. Generate a public-private keypair and make a webservice that takes a challenge string and encrypts it with the private key. Then make a USB dongle that contains your public key and generates random challenge strings. Your software should ask the USB dongle for a challenge string and send it up to the server for encryption. The software then sends it to the dongle. The dongle validates the encrypted challenge string with the public key and goes into an 'enabled' mode. Your software then calls into the dongle any time it needs to do the operation you wrote in HDL. This way anyone wanting to pirate your software has to figure out what the operation is and reimplement it -- much harder than just defeating a pure software protection.
Edit: Just realized some of the verification stuff is backwards from what it should be, but I'm pretty sure the idea comes across.
The Microsoft Software License scheme is crazy expensive for a small business. The server cost is around $12,000 if you want to set it up yourself. I don't recommend it for the feint of heart.
We actually just implemented Intellilock in our product. It lets you have all of the decisions for how strict you want your license to be, and it is very cost effective as well. In addition it does obfuscation, compiler prevention, etc.
Another good solution I have seen small/med businesses use is SoloServer. It is much more of an ecommerce and license control system. It is very configurable to the point of maybe a little too complex. But it does a very good job from what I have heard.
I have also used the Desaware license system for dot net in the past. It is a pretty lightweight system compared to the two above. It is a very good license control system in terms of cryptographically sound. But it is a very low level API in which you have to implement almost everything your app will actually use.
Digital "Rights" Management is the single biggest software snake-oil product in the industry. To borrow a page from classic cryptography, the typical scenario is that Alice wants to get a message to Bob without Charlie being able to read it. DRM doesn't work because in its application, Bob and Charlie are the same person!
You would be better off asking the inverse question, which is "How do I get people to buy my software instead of stealing it?" And that is a very broad question. But it generally starts by doing research. You figure out who buys the type of software you wish to sell, and then produce software that appeals to those people.
The additional prong to this is to limit updates/add-ons to legit copies only. This can be something as simple as an order code received during the purchase transaction.
Check out Stardock software, makers of WindowBlinds and games such as Sins of a Solar Empire, the latter has no DRM and turned a sizable profit off a $2M budget.
There are several methods, such as using the processor ID to generate an "activation key."
The bottom line is that if someone wants it bad enough -- they'll reverse engineer any protection you have.
The most failsafe methods are to use online verification at runtime or a hardware hasp.
Good luck!
Given a little time your software will always be cracked. You can search for cracked versions of any well known piece of software in order to confirm this. But it is still well worth adding some form of protection to your software.
Remember that dishonest people will never pay for your software and always find/use a cracked version. Very honest people will always stick to the rules even without a licensing scheme just because that is the kind of person they are. But the majority of people are between these two extremes.
Adding some simple protection scheme is a good way of making that bulk of people in the middle act in an honest way. It is a way to nudge them into remembering that the software is not free and they should be paying for the appropriate number of licenses. Many people do actually respond to this. Businesses are especially good at sticking to the rules because the manager is not spending his/her own money. Consumers are less likely to stick to the rules because it is their own money.
But recent experience with releases such as Spore from Electronic Arts shows that you can go to far in licensing. If you make even legit people feel like criminals because they are constantly being validated then they start to rebel. So add some simple licensing to remind people if they are being dishonest but anything more than that is unlikely to boost sales.
Online-only games like World of Warcraft (WoW) have it made, everyone has to connect to the server every time and thus accounts can be constantly verified. No other method works for beans.
Generally there are two systems that often get confused -
Licensing or activation tracking, legal legitimate usage
Security preventing illegal usage
For licensing use a commercial package, FlexLM many companies invest huge sums of money into licensing think they also get security, this is a common mistake key generators for these commercial packages are prolifically abundant.
I would only recommend licensing if your selling to corporations who will legitimately pay based on usage, otherwise its probably more effort than its worth.
Remember that as your products become successful, all and every licensing and security measure will be breached eventually. So decide now if it is really worth the effort.
We implemented a clean room clone of FlexLM a number of years ago, we also had to enhance our applications against binary attacks, its long process, you have to revisit it every release. It also really depends on which global markets you sell too, or where your major customer base is as to what you need to do.
Check out another of my answers on securing a DLL.
As has been pointed out, software protection is never guaranteed to be foolproof. What you intend to use depends largely on your target audience. A game, for instance, is not something you are going to be able to protect forever. A server software, on the other hand, is something far less likely to be distributed on the Internet, for a number of reasons (product penetration and liability come to mind; a large corporation does not want to be held liable for bootleg software, and the pirates only bother with things in large-enough demand). In all honesty, for a high-profile game, the best solution is probably to seed the torrent yourself (clandestinely!) and modify it in some way (for instance, so that after two weeks of play it pops up with messages telling you to please consider supporting the developers by purchasing a legitimate copy).
If you put protection in place, bear two things in mind. First, a lower price will supplement any copy protection by making people more inclined to pay the purchase price. Secondly, the protection must not get in the way of users - see Spore for a recent example.
DRM this, DRM that - publishers who force DRM on their projects are doing it because it's profitable. Their economists are concluding this on data which none of us will ever see. The "DRM is evil" trolls are going a little too far.
For a low-visibility product, a simple internet activation is going to stop casual copying. Any other copying is likely negligible to your bottom line.
Illegal distribution is practically impossible to prevent; just ask the RIAA. Digital content can just be copied; analog content can be digitised, and then copied.
You should focus your efforts on preventing unauthorised execution. It's never possible to completely prevent the execution of code on someone else's machine, but you can take certain steps to raise the bar sufficiently high that it becomes easier to purchase your software than to pirate it.
Take a look at the article Developing for Software Protection and Licensing that explains how best to go about developing your application with licensing in mind.
Obligatory disclaimer & plug: the company I co-founded produces the OffByZero Cobalt software licensing solution for .NET.
The trouble with this idea of just let the pirates use it they wont buy it anyway and will show their friends who might buy it is twofold.
With software that uses 3rd party services, the pirated copies are using up valuable bandwidth/resource which gives legit users a worse experience, make my sw look more popular then it is and has the 3rd party services asking me to pay more for their services because of the bandwidth being used.
Many casual wouldn't dream of cracking the sw themselves but if there is an easy assessible crack on a site like piratebay they will use it, if there wasn't they might buy it.
This concept of not disabling pirated software once discovered also seems crazy, I don't understand why I should let someone continue to use software they shouldn't be using, I guess this is just the view/hope of the pirates.
Also, its worth noting that making a program hard to crack is one thing, but you also need to prevent legit copies being shared, otherwise somebody could simply buy one copy and then
share it with thousands of others via a torrent site. The fact of having their name/email address embedded in the license isn't going to be enough to disuade everyone from doing this, and it only really takes one for there to be a problem.
The only way I can see to prevent this is to either:
Have server check and lock license on program startup every time, and release license on program exit. If another client starts with same license whilst the first client has license then it is rejected. This way doesn't prevent the license being used by more than one user, but does prevent it being used concurrently by more than one user - which is good enough. It also allows a legitimate user to transfer the license on any of their computers which provides a better experience.
On first client startup client sends license to server and server verifies it, causing some flag to be set within the client software. Further requests from other clients with the same license are rejected. The trouble with this approach is the original client would have problems if they reinstalled the software or wanted to use a different computer.
Even if you used some kind of biometric fingerprint authentication, someone would find a way to crack it. There's really no practical way around that. Instead of trying to make your software hack-proof, think about how much extra revenue will be brought in by adding additional copy protection vs. the amount of time and money it will take to implement it. At some point, it gets to be cheaper to go with a less rigorous copy protection scheme.
It depends on what exactly your software product is, but one possibility is to move the "valuable" part of the program out of the software and keep it under your exclusive control. You would charge a modest fee for the software (mostly to cover print and distribution costs) and would generate your revenue from the external component. For example, an anti-virus program that is sold for cheap (or bundled for free with other products) but sells subscriptions to its virus definitions update service. With that model, a pirated copy that subscribes to your update service wouldn't represent much of a financial loss. With the increasing popularity of applications "in the cloud", this method is becoming easier to implement; host the application on your cloud, and charge users for cloud access. This doesn't stop someone from re-implementing their own cloud to eliminate the need for your service, but the time and effort involved in doing so would most likely outweigh the benefits (if you keep your pricing model reasonable).
If your interested in protecting software that you intend to sell to consumers I would recommend any of a variety of license key generating libraries (Google search on license key generation). Usually the user has to give you some sort of seed like their email address or name and they get back the registration code.
Several companies will either host and distribute your software or provide a complete installation/purchase application that you can integrate with and do this automatically probably at no additional cost to you.
I have sold software to consumers and I find this the right balance of cost/ease of use/protection.
The simple, and best solution, is just to charge them up front. Set a price that works for you and them.
Asking paying customers to prove that they are paying customers after they've already paid just pisses them off. Implementing the code to make your software not run wastes your time and money, and introduces bugs and annoyances for legitimate customers. You'd be better off spending that time making a better product.
Lots of games/etc will "protect" the first version, then drop the protections in the first patch due to compatibility problems with real customers. It's not an unreasonable strategy if you insist on a modicum of protection.
Almost all copy-protection is both ineffective, and a usability nightmare. Some of it, such as putting root-kits on your customers' machines becomes downright unethical
I suggest simple activation key (even if you know that it can be broken), you really don't want your software to get in your users way, or they'll simply push it away.
Make sure that they can re-download the software, I suggest a web page where they can logging and download your software only after they paid (and yes they should be able to download as many times they wish it, directly, without a single question about why on your part).
Thrust your paid users above all, there is nothing more irritating that being accused from being a criminal when you are a legit users (DVD's anti-piracy warnings anyone).
You can add a service that checks the key against a server when online, and in case of two different IPs are using the same key, popup a suggestion to buy another license.
But please don't inactivate it, it might be a happy user showing your software to a friend!!!!
Make part of your product an online component which requires connection and authentication. Here are some examples:
Online Games
Virus Protection
Spam Protection
Laptop tracking software
This paradigm only goes so far though and can turn some consumers off.
I agree with a lot of posters that no software-based copy protection scheme will deter against a skilled software pirate. For commercial .NET based software Microsoft Software License Protection (SLP) is a very reasonably priced solution. It supports time-limited and floating licenses. Their pricing starts at $10/month + $5 per activation and the protection components seem to work as advertised. It's a fairly new offering, though, so buyer beware.