Licensing source code.

[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.

 

[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]

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.

 

[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]

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.

 

[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]

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]

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.

 

[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.

 

[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.