There are many issues with rolling your own license management software. If you lock to hardware, what happens when a server goes out and your customer wants to migrate to a new machine? Do you support hot standby? Do you support virtualization? Is it licensed per CPU or per instance? These are just a few sample questions that come into play; there are many, many more to consider.
Several years ago, I worked on a server system where we were required to implement license management and enforcement. We used FlexLM from Macrovision. It appears that it is now rolled into a new company and product suite as FlexNet. It was pricey but much better thought out for license management than a hand rolled solution, and, it can span pretty much any server licensing needs.
That said, I very much suggest that you do not approach license compliance in this way. Your customers are not likely to respond well to it, not because they want to cheat you on lincensing but because you are adding extra steps, however minor, to the use of the software that they are licensing. In my experience, much better solutions include simply trusting your customers to abide by the license agreement (as a jboss app I'm assuming you are dealing with corporate customers rather than a more easily "shared" consumer desktop app), include rights to audit via the license agreement, or setup the license so your customer can install at will and pay for licenses in use at specified periods. Your account managers should love having a touch point to ask about new licenses. In my experience with server software, when you make it easy for enterprise customers to expand use of your software, they tend to do so resulting in net positive sales.
I believe that MAC address restrictions are not a very good idea. First a server may have more than one network card. Second - sometimes network cards fail, and need to be replaced - hence MAC address is changed.
A possibility is to collect some kind of hardware fingerprints of as many components as you can, and then use them to decide if this is the same machine or not. If you allow for some changes changing a single component will not stop the software, but changing 2 or 3 will require your client to contact you, to obtain new license.
Of course the ultimate protection is the so called dongle. There is a nice Software protection dongle article in Wikipedia.
All in all, there is no protection, which cannot be cracked. So whatever you choose, make sure that it does not harm your user, or you can loose more customers by virtue of bad protection mechanism than by unlicensed use.
With Licenses, if you want to crack it you can crack it ;) That being said, If you intend to use MAC address to ensure that only only copy of your software is used, be prepared for the following:
You need to support a single license on multiple MAC addresses, this is because customers will usually have multiple NICs and keep one of them active at a time.
You will need to have a super fast customer service. Say your customer plans to transfer this software from one machine to another, then he will ask you for a transfer of license to the new MAC address. If the software is a time critical one then this transfer should happen very fast. Of course, you can combine solution 1 with Solution 2.
If the customers server, on which you install your software has access to internet, then the best option would be to have a online license renewal, where in your software will renew it's license with your license server. But cost is an issue here, considering all the infrastructure required.
由于硬件可以更换,因此您不能使用 MAC 地址等参数,因此必须使用 Install-Id 等通用参数。
You need to think about the following questions:
Would your customer breach the license agreement?
Is your customer skilled and could breach the protection?
If both answers are true, there is no chance to protect your software, except you will use a hardware component like a dongle.
If one answer is false, you could use this simple approach:
While installing your software generate an Install-Id on the customer machine using some secret algorythm and store it encrypted in an uncommon secret place on the machine and show it to the customer.
Request the Install-Id from customer and check whether it is really generated with your algorythm.
Generate a License-Key using a second secret algorythm and give it to the customer.
Validate in your software that the License-Key was generated using the Install-Id.
Since the hardware can be replaced you can not use parameters like MAC address, so you have to use something generic like an Install-Id.
The best way is to do this outside software, using the software agreement to place these restrictions. The customer can choose to follow the guidelines and be compliant or not. Chances are, if they're a public company, they're dealing w/ software audits and would rather just pay to be compliant than risk being sued.
发布评论
评论(6)
推出自己的许可证管理软件存在许多问题。如果您锁定硬件,当服务器出现故障并且您的客户想要迁移到新机器时会发生什么?支持双机热备吗?支持虚拟化吗?是按 CPU 还是按实例进行许可?这些只是一些起作用的示例问题;还有很多很多需要考虑。
几年前,我在一个服务器系统上工作,需要我们实施许可证管理和执行。我们使用 Macrovision 的 FlexLM。看来它现在已被整合到一个新公司和产品套件中,名称为 FlexNet。它价格昂贵,但在许可证管理方面比手工解决方案要经过深思熟虑,而且它几乎可以满足任何服务器许可需求。
也就是说,我强烈建议您不要以这种方式实现许可证合规性。您的客户不太可能对此做出良好反应,不是因为他们想在许可方面欺骗您,而是因为您在使用他们许可的软件时添加了额外的步骤,无论多么微小。根据我的经验,更好的解决方案包括简单地信任您的客户遵守许可协议(作为 jboss 应用程序,我假设您正在与企业客户打交道,而不是更容易“共享”的消费者桌面应用程序),包括审核权通过许可协议,或设置许可证,以便您的客户可以随意安装并为指定期限内使用的许可证付费。您的客户经理应该喜欢有一个接触点来询问新许可证。根据我在服务器软件方面的经验,当您让企业客户轻松扩展软件的使用时,他们往往会这样做,从而带来净销售额。
无论你走哪条路,祝你好运!
There are many issues with rolling your own license management software. If you lock to hardware, what happens when a server goes out and your customer wants to migrate to a new machine? Do you support hot standby? Do you support virtualization? Is it licensed per CPU or per instance? These are just a few sample questions that come into play; there are many, many more to consider.
Several years ago, I worked on a server system where we were required to implement license management and enforcement. We used FlexLM from Macrovision. It appears that it is now rolled into a new company and product suite as FlexNet. It was pricey but much better thought out for license management than a hand rolled solution, and, it can span pretty much any server licensing needs.
That said, I very much suggest that you do not approach license compliance in this way. Your customers are not likely to respond well to it, not because they want to cheat you on lincensing but because you are adding extra steps, however minor, to the use of the software that they are licensing. In my experience, much better solutions include simply trusting your customers to abide by the license agreement (as a jboss app I'm assuming you are dealing with corporate customers rather than a more easily "shared" consumer desktop app), include rights to audit via the license agreement, or setup the license so your customer can install at will and pay for licenses in use at specified periods. Your account managers should love having a touch point to ask about new licenses. In my experience with server software, when you make it easy for enterprise customers to expand use of your software, they tend to do so resulting in net positive sales.
Whichever way you go, good luck!
我认为MAC地址限制不是一个好主意。首先,一台服务器可能有多个网卡。其次 - 有时网卡会出现故障,需要更换 - 因此 MAC 地址会发生变化。
一种可能性是收集尽可能多的组件的某种硬件指纹,然后使用它们来确定这是否是同一台机器。如果您允许进行某些更改,则更改单个组件不会停止软件,但更改 2 或 3 个组件将要求您的客户与您联系,以获得新的许可证。
当然,最终的保护是所谓的加密狗。维基百科中有一篇很好的软件保护加密狗文章。
总而言之,没有任何防护,无法破解。因此,无论您选择什么,请确保它不会伤害您的用户,否则您可能会因为不良的保护机制而不是未经许可的使用而失去更多的客户。
I believe that MAC address restrictions are not a very good idea. First a server may have more than one network card. Second - sometimes network cards fail, and need to be replaced - hence MAC address is changed.
A possibility is to collect some kind of hardware fingerprints of as many components as you can, and then use them to decide if this is the same machine or not. If you allow for some changes changing a single component will not stop the software, but changing 2 or 3 will require your client to contact you, to obtain new license.
Of course the ultimate protection is the so called dongle. There is a nice Software protection dongle article in Wikipedia.
All in all, there is no protection, which cannot be cracked. So whatever you choose, make sure that it does not harm your user, or you can loose more customers by virtue of bad protection mechanism than by unlicensed use.
有了许可证,如果你想破解它,你就可以破解它;)
话虽这么说,
如果您打算使用 MAC 地址来确保仅使用软件的副本,请做好以下准备:
当然,您可以将解决方案 1 与解决方案 2 结合起来。
如果您安装软件的客户服务器可以访问互联网,那么最好的选择是在线续订许可证,您的软件将使用以下命令续订其许可证您的许可证服务器。但考虑到所需的所有基础设施,成本是一个问题。
在决定许可方案之前请考虑此讨论license-scheme
还有这个how-are-software-license-keys- generated
还有许可注意事项管理
JLicense 也是一个用于简单许可证管理的简单库。
With Licenses, if you want to crack it you can crack it ;)
That being said,
If you intend to use MAC address to ensure that only only copy of your software is used, be prepared for the following:
Of course, you can combine solution 1 with Solution 2.
If the customers server, on which you install your software has access to internet, then the best option would be to have a online license renewal, where in your software will renew it's license with your license server. But cost is an issue here, considering all the infrastructure required.
Consider this discussion before decide on license schemes license-scheme
Also this how-are-software-license-keys-generated
And this consideration for License Management
Also JLicense is a simple library to use for simple license management.
建议。内置功能缺陷的自动更新(安全补丁/错误修复/优化)。然后做一个ID& IP 检查。
Suggestion. Build in an automatic update of functional deficiencies (security patches/bug repairs/optimisations). And then do an ID & IP check.
您需要考虑以下问题:
如果两个答案都是正确的,则没有机会保护您的软件,除非您将使用加密狗等硬件组件。
如果一个答案是错误的,您可以使用这种简单的方法:
由于硬件可以更换,因此您不能使用 MAC 地址等参数,因此必须使用 Install-Id 等通用参数。
You need to think about the following questions:
If both answers are true, there is no chance to protect your software, except you will use a hardware component like a dongle.
If one answer is false, you could use this simple approach:
Since the hardware can be replaced you can not use parameters like MAC address, so you have to use something generic like an Install-Id.
最好的方法是在外部软件中执行此操作,使用软件协议来设置这些限制。客户可以选择遵循准则以及合规或不合规。如果他们是一家上市公司,那么他们很可能会进行软件审计,并且宁愿付费以保持合规性,也不愿冒着被起诉的风险。
The best way is to do this outside software, using the software agreement to place these restrictions. The customer can choose to follow the guidelines and be compliant or not. Chances are, if they're a public company, they're dealing w/ software audits and would rather just pay to be compliant than risk being sued.