we are planning to use InstallShield for your product build. Unfortunately, I was not able to find explicitly written if you can use InstallShield and all his components after 1 year of usage.
I am aware of the fact that it works like it for most of software (you only lose right for support and updates) but I need to be sure. (I was able to find the information explicitly written for all other software we tend to use or with help of their support.)
I also tried to contact InstallShield support but it seems that without Maintenance subscription you cannot ask anything and browsing their forum only confused me more.
This depends on the license you purchase. Most licenses for InstallShield are perpetual licenses: once you buy it, you are entitled to use it forever. Some licenses with explicit term lengths on them do expire. Note that the licensing implementation expects to connect to the server periodically, and if it cannot do so it will believe the license has expired.
FYI, these questions are probably easier to ask of a sales representative than of the support team.
Related
Say there is a npm package which enables me to do functionality A. Say I write a wrapping software which basically just offers functionality A, just packages it more nicely but -apart from that- is nothing more.
Would it be legal to sell this software? Does the original contributor of functionality A (the person who wrote the npm package) get anything?
I feel like some people have done some great work, and I don't understand how it's possible that I can just use their packages and, theoretically, sell them as mine (as it were). Or am I misunderstanding some fundamental things here?
Generally the answer is:
Yes you are allowed to sell it (most of the time).
Pretty much any software you buy these days includes free software
More detailed:
there are really many licenses. Start with https://spdx.org/licenses/.
the license of the original package may not allow the selling part. This is very rare
Sometimes you need to distribute your code (e.g. GPL3) but you can sell the software.
Most free licenses try to make sure the work gets reused and sometime add conditions that they or their software gets attributed. They are not so much interested in money
Where to ask these questions:
https://opensource.stackexchange.com/
Management has asked us to look into implementing licensing features into some existing applications. Up to this point these apps were simply paid for and customers could install them as they please. We need to implement a new licensing model to generate more revenue because our older products work well enough that people do not have a reason to upgrade. So our new customers will have to pay licensing fees and/or be limited to how many installations they can have. I have never dealt with this stuff before, so please pardon my ignorance. I need as much guidance as possible (steering me in the right direction would be great!). We need the following...
Time limited demo versions. When they install the software, it works with full features for a fixed amount of time. After that, when they try to run it, it tells them their license has expired.
Licensing option that limits the app to run on a particular machine.
Licensing option that limits the app to being run by a particular user.
Licensing option that limits the app to a certain total number of users or concurrent users.
Number one is pretty simple to figure out, but I have no idea how to go about implementing the other three. Any advice is greatly appreciated.
I would look at 3rd party solutions for this honestly. There are a lot of concepts intrinsically involved in licensing, and for the cost of one week of development time you can buy a fully featured licensing product to integrate into your stuff. This is a case where writing your own is probably not worth the hassle.
I've previously used the Desaware licensing system for user and machine based licensing. Works well enough, no complaints. I believe their framework will be robust enough to handle all 4 of your requirements. http://www.desaware.com/products/licensingsystem/index.aspx
All these scnarios can be pretty complicate to implement and get just right (and hassle-free). Instead of wasting your time on this, consider using a commercial licensing solution like CryptoLicensing. It supports all the scenarios you want including trials, machine-locked, user-locked and floating/concurrent.
DISCLAIMER: I work for LogicNP Software, the developers of CryptoLicensing.
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 7 years ago.
Improve this question
I have a commercial plug-in on top of Visual Studio.
My product is licensed per individual developer, so the developer may make copies on more than one computer, as long as the use of the product is by the same developer.
After a period of time I discovered that many of my customers purchase one developer license and distribute the product over all the team members (and it is not rare case).
I spent many hours (here in StackOverFlow and outside) searching on how to prevent this issue, but I found most of people talk about protecting per-machine license.
My question is how can I prevent my legitimate customers from illegally distribute my product over more machines if I can not restrict them to any number of machines?
Throw my search I get one solution, but I want to ask you if it is acceptable or not?
I can restrict the license per Windows user name, while the customer activate the product for the first time I record the windows username with the product serial number, so he can not run (or even reactivate) the product on any machine with another Window username.
If you purchase any product that licensed per-developer, is this approach is acceptable for you?? (or in the other side this policy may be reduce my sales?).
Best Regards,
You can use many forms of DRM to protect your product. Consider though that you will be hurting and annoying legal owners on occasion. If someone changed computers or reinstalled windows then he will not be able to install your product again. DRMs can also be broken and are usually never worth the time invested in them.
My advice is that you don't try to prevent piracy of your software, since you can't stop it. If you are aware of a specific client that abuses your license, send them a friendly but firm Email requesting they acquire legal licenses for all their copies. Failing that, you might want to pursue legal actions.
All in all, trying to fight software piracy is a lost cause. You might consider other types of licenses that make it easier for a company with multiple developers to acquire your plugin. If you give group discounts they are more likely to pay.
I guess it depends on how the plugin is used. If it's primarily used in an office environment where having computers set up in a windows domain is the de facto standard, then yes, it could be acceptable.
It could become a problem if the developers are used to being able to use the plugin at home on their home computer as well, since the username will probably not match.
Edit: You could perhaps set a limit of 2 usernames per user. That could solve the use-at-home problem.
I'd say trying to bind the license to the windows user name would be sufficient, and somewhat acceptable. In your case you likely don't have any protection against several machines/users/etc. using many copies of your license - making it trivial for several people to use it. Most legitimate people will buy the additional licenses if it becomes non-trivial to do otherwise, binding it to the login name provides easy incentive to get additional licenses.
Just keep in mind:
You can't protect against every way to circumvent licensing.
You don't need fancy license protection, you just need it to be easier
to get an additional license than it is to circumvent the licensing.
Don't make it hard to use a licensed product.
One caveat I have as a sole developer on some projects though, is stuff bound to just 1 machine (or perhaps user account) - I always need 1 additional license for my build server and/or my machine-at-home.
it is very annoying to have to pay for a license for that machine even if it's just me using it - so think about that. For your product, it'd mean I'd have to have at least 2 licenses - one for my work computer, one for my home cumputer (different users/domains).
Invent some kind of setting which everyone will want to have set their own way, and keep that setting value on your server, for a license. If it's the same programmer using the app from three different PCs, he'll have no complaints on that the setting is the same everywhere. (In fact, he'll like it). But different people have different tastes, and people will soon be tired of re-setting the option the way they like it only to later find it reset back to someone else's preference again. They'll think that maybe buying a cheap personal copy instead of going through all this crap is not a bad idea after all.
The more of user preferences you automatically move around, the better it is for a single user and the worse it is for cheaters.
Goerge, what you describe is pretty common in your industry. The battle is lost already. Small companies will not purchase as much license as they should, but bigger ones will eventually respect your licensing terms.
You must adapt your pricing strategy and take in consideration this fact.
Adding more protection will do the inverse, preventing you from getting new customers or keeping the existing ones.
Don't make it hard to use. I have seen bad results, like Blu-ray which almost failed because of so much DRM on them. Some people had to resort to Slysoft Any HD-DVD to play blu-ray because software player that was supposed to play Blu-ray wouldn't play the disc they bought.
Our clients must pay a monthly Fee... if they don't, what is the best way to block the asp.net software usage?
Note: The application runs on the client own server, its not a SaaS app...
My ideas are:
Idea: Host a Web Service on the internet that the application will use to know if the client can use the software.
Issue 1 - What happen if the client internet fails? Or the data center fails?
Possible Answer: Make each web service access to send a key that is valid for 7 or 15 days, so each web service consult will enable the software to run more 7 or 15 days, this way the application will only be locked after 7 or 15 days without consulting our web service.
Issue 2 - And if the client don't have or don't want to enable internet access to the application?
Idea 2: Send a key monthly to the client.
Issue - How to make a offline key?
Possible Answer: Generate a Hash using the "limit" date, so each login try on software will compare the today hash with the key?
Issue 2 - Where to store the key?
Possible Answer: Database (not good, too easy to change), text file, registry, code file, assembly...
Any opinion will be very appreciated!
Ah, the age old issue of DRM. And that's what you're talking about here. Frankly, the fundamental answer to your question is: you can't. No matter what you do to the system, it can be hacked and modded in such a way that your DRM authentication scheme can be bypassed and/or broken.
This is a fundamental fact of software development: it can and will be pirated.
So, the answer to your question is that you will have to trust the client to pay you the fees you determine to be correct (which is the whole point of contracts in this situation).
Any other actions you take are a hardship and annoyance on your paying customer, and has the potential to erode your customer base.
Now, if you want control of your software in the nature described, then do not provide it to users to run on their own servers. Force them to be SaaS. In that way, you control all of that. But this is the only way.
Something that you don't appear to be thinking about, but I have seen networks which do not allow any type of "dial home" solutions, as a majority of the systems were internally focused and thus these internal servers were NOT allowed to contact the outer internet. At all. It was deemed a security risk to even allow them access. How would you handle those networks?
Frankly, if I was the customer, and I paid my fees to license your software (which I installed on my own device) I would be irate if I had to allow that device access to the internet in order for it to work. Doubly so, if the software in question was any type of financial management, customer management, HR management, quality management, inventory management, sales, or just anything related to my business, customers or employees. I don't trust software developers enough to have their software talk to something else when my business-relevant data is held in their software.
In the end, what you are describing is an antagonistic approach to take with your paying customers. If you don't believe me, look at the comments that UbiSoft is getting for their latest customer-hating DRM scheme.
IMO, you have two good paths here:
Go SaaS
Ensure your contract has a
bite for non-payment
usually you provide an scrambled key that includes a valid authorization token and the expiration date through which service is paid. Then the installer will use this to "activate" your software. Not sure how this would be viewed if you have 1-2 week periods. you'd want to warn them about upcoming expiration. Also not sure how to tell if they've set their own clock back.
In short, nothing will be perfect.
I've dealt with this before and its not possible to make a perfect system. There are risks in anything you do. The best thing is to weigh your options, and determine the method that has the least likelihood of being hacked and the most likelihood of working correctly and easily for the customer.
Like others have said, they could change their clock and invalidate the license checking mechanism. If you didn't trust the user, you could make the license system connect to your servers. You would then need to ensure that they always have a connection to your servers to check the license.
What if there is a valid reason that they cannot access your server?
Their internet connection has a problem.
YOUR internet connection has a problem.
In that case, should you disable the application? Probably not. But then again, what if they shut down the connection on purpose? Then you would WANT to disable the application.
If you give them a monthly key, you're adding a monthly annoyance and you may lose a customer after a while (people tend to do business with those who make it easy).
For example: If you base it on their clock, and the application needs their clock to be accurate for some reason, then its unlikely that the customer will change their clock.
I agree with Stephen but ultimately, I think that your contract is your best ally here.
As been previously mentioned, you don't want to inconvenience customers, especially if you have a large deployment.
As for SaaS, if I were a customer using your product and you said that the model is changing and we need to access the software from your server and ours must be decommissioned, I'd not be happy. I'd probably use the opportunity to switch packages.
In corporate settings, the contract really is the best way to handle these issues. I've worked on licensing issues for desktop and ASP.NET applications and they can cause a number of headaches for both you and your client.
However, if you insist on using something like this I suggest you go with a middle ground. Instead of only unlocking the application for a week or two, provide a license for 6 months or a year. This way, if you run into licensing issues (and you will run into issues) they only occur once a year rather than a couple of times per month. That will be cheaper for you in support and your clients will be less unhappy about dealing with licensing issues. If the company stops paying and you need to terminate the license you can handle that on a one-off basis, using contract enforcement as needed.
On the web service or client license options, I think a good license system would incorporate both. A client license to provide a the application a stable license and a web service to generate and deliver the license key when it is time for the application to be renewed. If the client won't allow the application to call home to get the license key also provide a manual entry method.
If you are going to store a license on the client, do not try to build a component yourself. There are many components available which will be much more robust and reliable than the one you build. There is a .NET .licx-based licensing method and a number of 3rd party methods that you can use. Which one is most appropriate depends on your scenario: how flexible you want the license and what other options you need. Most importantly, find something reliable - any time your customers spend fixing problems caused by licensing is non-productive for them and will reflect poorly on the application.
The important thing to keep in mind is that no system is fool proof. If your application is valuable, someone is going to figure out how to steal it. But at the corporate level and with custom software it's more likely the licensing will be used to remind people to pay rather than stop wholesale piracy.
I am looking for a Sybase PowerBuilder 8.0 setup. I found http://www.sybase.com/detail?id=1013232, but the all dowload links are broken.
Where can I download PowerBuilder 8?
You might ask Sybase, but I doubt they'd sell it to you. AFAIK, they haven't sold PB8 in about 8 years, and it hasn't been supported in 6 years. The current eval (11.5 at the time of this writing) is available off their main product page, if free is what you're after.
If it's PB8 you need, then you may be out of luck. Occasionally, you see an old copy sold on eBay, but I've had someone suggest to me that the license terms don't allow resale, so I'm not sure how legal this option is. (I'm no lawyer; maybe you'd want to ask that on "Litigation Overflow".) I'm sure I can leave the even less legal options up to your imagination.
Availability might be another reason to argue for an upgrade, beyond the technical reasons and new features, like operating system support. The PHBs won't like it, but then again, some live to aggravate PHBs; not you I'm sure.
Sorry, and good luck,
Terry
PB8? Sounds like you have to work on an existing system. The company that owns the code and is sponsoring the project surely has a legal license for you to use. It would need to provide you access to its copy if you don't have your own to work with.
Barring that, if you have access to the original code, it should be possible to migrate the application to a newer version of PB, although as Terry notes, PB8 is out of support and I'm not sure if there would be difficulties migrating. There would most certainly be some if the code features any special customizations or usage of now obsolete objects. In that case I can see how you would probably be best served by having PB8 to make adjustments noted by the migration assistant before completing the code conversion.