Reply to: Licensing source code.

[vetran]

Our deliverable is a toolkit in the form of source code... In Java and C#...

Thanks though.

So display the encrypted text files in a roll your own viewer (create your own filetype xxxxxx.spodview), this uses the locked software.

Do you want to protect the development toolkit or code derived from it?

If its the code then you are a lot stuffed they will just remove it.

Install keys work fine, so long as they have sensible notification options and an easy semi offline option e.g. send seed online receive key by email. Grace period essential.

[Sysman]

Quite right processors can fail or get upgraded although in the upgrade scenario, especially the software Iuse, you would need to get a new license key anyway as you're limited to the processor you can use. As for failure, in the systems where I know this type of licensing is used I have never heard of a processor failure and then as the systems as multi-processor (and use a form of clustering) the system continues to run and the software too as it has built in redundancy (i.e. your license runs out but you have a 30 day grace period to get it renewed.)

As for dongles, we went to a dongle based system and they too fail sadly but not as often as NICs.

I like the idea of the software having a grace period of n days. That takes away much of the pain involved in getting a broken system back up and running.

[darmstadt]

Processors can fail or get upgraded too. Anything that ties a license to a specific piece of hardware suffers from the same shortcomings. The hardware dongle approach is about the only one that doesn't but then you have issues with securing dongles (i.e. to stop theft, loss or accidental damage) and customers find them just as much of a PITA (I know this for a fact as I have to suffer several of them myself).

Personally I think from a customers perspective the less intrusive the licensing the better, but obviously the less intrusive schemes are also much less effective.

Quite right processors can fail or get upgraded although in the upgrade scenario, especially the software Iuse, you would need to get a new license key anyway as you're limited to the processor you can use. As for failure, in the systems where I know this type of licensing is used I have never heard of a processor failure and then as the systems as multi-processor (and use a form of clustering) the system continues to run and the software too as it has built in redundancy (i.e. your license runs out but you have a 30 day grace period to get it renewed.)

As for dongles, we went to a dongle based system and they too fail sadly but not as often as NICs.

[doodab]

One licensing system used by a lot of software I use is to get the processor serial number where the software is running and use a hash algorithm to build the license key into the software. This doesn't use too many cycles and is quite effective.

Processors can fail or get upgraded too. Anything that ties a license to a specific piece of hardware suffers from the same shortcomings. The hardware dongle approach is about the only one that doesn't but then you have issues with securing dongles (i.e. to stop theft, loss or accidental damage) and customers find them just as much of a PITA (I know this for a fact as I have to suffer several of them myself).

Personally I think from a customers perspective the less intrusive the licensing the better, but obviously the less intrusive schemes are also much less effective.

[darmstadt]

I've used the MAC address as a hardware ID and public/private key signing of a hash of the license info i.e. the license file contains mac address, serial no, optional expiry date and a key that is just a digital signature of a hash of the other info. The key thing here is that they can see the license info but they cannot edit it without rendering the license key invalid. Of course when you can manually set the MAC address on a network adapter it doesn't work very well.

As has already been pointed out NIC cards can fail. I used to build and support mission critical systems which used this method of licensing and used to insist that the customer buy 2 NIC cards in case of failure. One problem I had was outsourcing the builds of systems when the BP would use the MAC address of the onboard NIC which means that the whole motherboard needs to be replaced. The software supplier used to insist that the failing NIC had to be sent to them which if it was an onboard NIC then the whole motherboard needed to be sent to them. We then went to a dongle based licensing which was much better and for emergencies we had a remote dongle server which worked over the network. (And don't get me on about rebuilding the Kernel in UnixWare when a NIc had to be replaced...)

One licensing system used by a lot of software I use is to get the processor serial number where the software is running and use a hash algorithm to build the license key into the software. This doesn't use too many cycles and is quite effective.

[doodab]

Ahhh, latency would be an issue with the "Cloud" - customers want to run our software on their own kit.

Yes, I wasn't suggesting it, just pointing out why it's really quite different to licensing by nodename, hardware ID or anything else.

[SupremeSpod]

Not really the same thing at all. If they control the platform there is no need for complex licensing systems tied to specific hardware, hostnames or anything else, it's simply a case of keeping track of the number of users or instances or whatever and either enforcing limits or billing accordingly.

Ahhh, latency would be an issue with the "Cloud" - customers want to run our software on their own kit.

[doodab]

And then we are back to nodenames, no? Call 'em instance names if you like but it's the same thing.

Not really the same thing at all. If they control the platform there is no need for complex licensing systems tied to specific hardware, hostnames or anything else, it's simply a case of keeping track of the number of users or instances or whatever and either enforcing limits or billing accordingly.

[Sysman]

Yes, agreed that it's a PITA, but you will have the same problem using any specific piece of hardware to ID the machine.

Going back to the nineties some of the network gear I used had the MAC address on a chip which could be transferred to a new piece of kit. This was very handy (if the engineer remembered to do it).

At the other end of the spectrum we have the MS approach which allegedly looks for a combination of hardware changes, yet pronounced my Windows 7 licence dead when I brought my work system home and at the same time made some partition changes. A couple of reboots might have got around that, but at the time I was looking for an excuse to lob Linux on it, so did

You can see why IT services firms are so keen to sell the cloud.

And then we are back to nodenames, no? Call 'em instance names if you like but it's the same thing.

[doodab]

I think it's a useful exercise to look at this from the customer point of view.

As a customer I definitely do not want anything tied to a MAC address. Network cards die and I don't want to have to deal with software licensing issues on top of any other network reconfiguration I may have to do as the result of a new MAC address because a NIC was replaced. As you say, doodab, they can be faked anyway. Also what happens in your scheme if an extra NIC is added to a system? Incidentally if a VMS machine running DECnet is in the equation (yes they still exist), DECnet itself knobbles the MAC address before TCP/IP sees it (and while it's unique for a given network, it is not necessarily unique across all customers).

Yes, agreed that it's a PITA, but you will have the same problem using any specific piece of hardware to ID the machine.

You can see why IT services firms are so keen to sell the cloud.

[VectraMan]

IMO attempting any kind of licencing always costs more in support and development hassle than it would cost in lost revenue from the small number of customers that are likely to try to cheat you. But management types don't tend to see it that way. And if you're supplying code than that suggests a much higher degree of trust with the customer anyway. Paying for a source code licence for a library and then having to deal with additional licencing issues would just piss most people off.

[Sysman]

EDIT: in my case, the string was in a file, not the exe. And I used the machine's IP address, not nodename, to tie it.

I prefer nodename, simply because the "network nazis" can and sometimes do impose IP changes on you. There's also the impending switch to IPv6 to think of here: stick to nodenames and you can neatly avoid any hassles that will bring.

I've used the MAC address as a hardware ID and public/private key signing of a hash of the license info i.e. the license file contains mac address, serial no, optional expiry date and a key that is just a digital signature of a hash of the other info. The key thing here is that they can see the license info but they cannot edit it without rendering the license key invalid. Of course when you can manually set the MAC address on a network adapter it doesn't work very well.

I think it's a useful exercise to look at this from the customer point of view.

As a customer I definitely do not want anything tied to a MAC address. Network cards die and I don't want to have to deal with software licensing issues on top of any other network reconfiguration I may have to do as the result of a new MAC address because a NIC was replaced. As you say, doodab, they can be faked anyway. Also what happens in your scheme if an extra NIC is added to a system? Incidentally if a VMS machine running DECnet is in the equation (yes they still exist), DECnet itself knobbles the MAC address before TCP/IP sees it (and while it's unique for a given network, it is not necessarily unique across all customers).

I have also come across licencing schemes which hide things in file headers. With one product a simple backup and restore of the system disk lost that and whoops, the software refused to start. The supplier made it easy to get a new licence key in this event, but they were abroad so we could only call them from certain phones. See the problem? What made this worse was that this product was a scheduler which kicked off jobs on a bunch of other systems. Oops. (We promptly migrated our sysadmin jobs such as backups back to using standard OS schedulers.)

My plea from the customer point of view is to make it easy for the customer to comply with licencing. Make your licencing scheme a pain in the neck to administer and folks will be tempted to look for workarounds. A simple tool to help the customer manage multiple licences might be appropriate, especially if it gives them a nice printout to give to auditors, and you can use this as a selling point too.

And please don't force me to type long sequences of gibberish into a box where pasting isn't allowed.

Maybe consider omitting ambiguous characters from licence keys too. For example, the VMS licence checksums were completely unambiguous - no struggling to distinguish between zero and "O", "1" and "l" etc.

13. Enter 1-BGON-IAMA-GNOL-AIKO for the checksum.

Note

The checksum string always begins with a number. The other 16 characters are always alphabetic characters from A through P.

[AtW]

This thread is more appropriate in Accounting / Legal.

[SupremeSpod]

It's quite possible to implement a challenge / response activation system that works offline, so I wouldn't rule that out altogether. Nearly all of the online one's I've seen offer an offline fallback.

I've used the MAC address as a hardware ID and public/private key signing of a hash of the license info i.e. the license file contains mac address, serial no, optional expiry date and a key that is just a digital signature of a hash of the other info. The key thing here is that they can see the license info but they cannot edit it without rendering the license key invalid. Of course when you can manually set the MAC address on a network adapter it doesn't work very well.

Whatever scheme you use for the licensing, the bigger problem is writing licensing checks into the code in such a way that it doesn't degrade performance and it isn't trivially easy to circumvent or replace the license checks with a stub. If you are supplying source code then you make this method of avoidance much easier, to the point where I'd say you're more or less wasting your time unless you are going to turn your product into unreadable difficult to maintain spaghetti.

Yep. A toughy, init?

Thanks for all your suggestions though, keep 'em coming.

[doodab]

It's quite possible to implement a challenge / response activation system that works offline, so I wouldn't rule that out altogether. Nearly all of the online one's I've seen offer an offline fallback.

I've used the MAC address as a hardware ID and public/private key signing of a hash of the license info i.e. the license file contains mac address, serial no, optional expiry date and a key that is just a digital signature of a hash of the other info. The key thing here is that they can see the license info but they cannot edit it without rendering the license key invalid. Of course when you can manually set the MAC address on a network adapter it doesn't work very well.

Whatever scheme you use for the licensing, the bigger problem is writing licensing checks into the code in such a way that it doesn't degrade performance and it isn't trivially easy to circumvent or replace the license checks with a stub. If you are supplying source code then you make this method of avoidance much easier, to the point where I'd say you're more or less wasting your time unless you are going to turn your product into unreadable difficult to maintain spaghetti.