I'll note that this seems to be the approach taken by Sybase overall; the number of licenses that you have access to is just a number in a system table that anyone with "sa" access can update. I assume they've made a business decision that it's not worth a technological restriction.

Now, if your market is mostly small businesses, I can see why the "trust the customer" approach wouldn't immediately be too attractive. However, I would encourage you to consider it, or rather a simple variation: don't enforce your license with technological measures, but with legal ones. As you're doing custom development with each client (you're building them a site), I assume that you have some standard contract with that site. Add the license of the CMS into that standard contract, and make the customer sign it in person rather than having it be one of those click-through licenses that few people read.

Spell out exactly what they can and can't do, and then have a simple reminder in the source code about the terms of the license, in terms of legal boilerplate comments in each file. You might also want to add a bit in the source code so that the CMS knows which domain it's licensed for, and puts an ugly "This is unlicensed" banner at the top of each page when used on an unlicensed site. However, I wouldn't go overboard worrying technological solutions to this ultimately legal problem - legal solutions should be good enough.

@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/
[download]

Great points fizbin. Your main point, plain and simple honesty, is the way I honor the licensing for my wysiwyg editor.

I especially like your point about Sybase's business decision. I think you implied, or if not, I will, that too many restrictions might turn off the average customer and they might go elsewhere for their solution. And it is the simplist technologically.


—Brad
"The important work of moving the world forward does not wait to be done by perfect men." George Eliot

I think you've hit it right on the head. I once had a boss who summed it up nicely: "Locks are to keep honest people honest". A determined crook can break into your house or your software protection. Fortunately, those folks are relatively rare. The rest of us do tend to pay up, especially if it's not *too* easy to pinch a copy.

Excellent points, indeed. I have said time and time again that good technological solutions to this type of issue should have but one purpose: to inform the ignorant of a potential violation.

I believe that most people want to stay on the legal side, but I also know that something that gets passed to a friend for evaluation (a good thing, IMO) needs to have a simple control that reminds an unlicensed user that they have an unlicensed copy. This could be as simple as a UUID in a database table that indicates a licensed copy. Yeah, it's easy to bypass, but people who really don't care about licensing will find a way to bypass any control.

By using a simple measure, you provide a gentle reminder that a user needs to license your software; however, you avoid placing an unfair onus on legitimate users of your software. But, if you don't place some kind of simple control like this, the chances are high that people who are willing to pay for the right number of licenses (etc.) will accidentally use many more than they've paid for.

As with most things, balance is the key.

<-radiant.matrix->
Larry Wall is Yoda: there is no try{} (ok, except in Perl6; way to ruin a joke, Larry! ;P)
The Code that can be seen is not the true Code
"In any sufficiently large group of people, most are idiots" - Kaa's Law

Just as a point of interest, I work for Kineticode, Inc. and our primary product, Bricolage, is an enterprise-class (really) open source content management system. So far our business is doing very well.

If your product is robust enough, does things people want and other software products cannot do easily, your skill and expertise in maintaining and developing the product are a valuable commodity. Most companies are basically honest and despite what the BSA might want you to think, few companies are "stealing" software deliberately. If they slap something on a server and forgot to license it, they're still not turning around and reselling it. If you open source your software, they're no threat to you.

Anyone heard of Pmail? It is a free email application written by a friend of mine who has done very well by just selling the documentation for the software.

The company that I work for sells a data recording and analysis system. We often refer to the data recorder as a "dongle" and it is that that we sell. Until a few years ago the software was pretty much considered "free". Then, mostly to emphasise to our customers that the software had value, we introduced a license that is keyed on the customer's name. This has the advantage that our software isn't keyed to a particular machine, but, because the customer's name is fairly obvious, makes it less likely that clients are going to rip off newer versions of our software and the added value plugins that we write.

Our licence code does not use heavy weight security, but it does manage to pack a bunch of constraint information into about 12-16 characters and is extensible to allow for constraints we've not thought of yet. If there is interest, I could ask if it were ok for me to work up a Perl variant of the code and publish it.

You can try to build copy-protection in a program, but a) if it's popular, it will be cracked anyway and b) companies (assuming you're selling to companies / institutions) don't like the idea of having illegal software around, so they'll buy it eventually, even if they start out with an unauthorized copy. The situation might be different for consumer software, but MS office can be copied without modifications and microsoft is doing pretty good compared to most companies. I agree with the posts that say you should assume your customers are honest. You can always sue them if nessecary :-)

Of course, none of that applies if you're not distributing the program itself.

Having said that, selling "boxed" software is not the only way to make money. I currently make most of my money developing (from scratch and extending) and deploying open-source products for companies. If you can get your CMS popular enough (and giving it away helps a lot there) there might be good money in development, deployment (as in setting up sites with the CMS) support contracts etc. Basically charging for the work you do with the software, not the software itself.

If you're considering making the software "open", take your time to figure out which license you'll want to use. I'd recommend taking a popular license over inventing your own - if only because it'll save potential users a lot of head-ache if they don't have to figure out the fine-print of some unknown license.

Open source licenses are abundant and they are not all the same; it takes a while to get at the differences. Two of the popular ones are the GPL license, which basically states that if you want to distribute a GPL program - or anything based on a GPL program - it should have the GPL license itself (keeping any derivative code open/free), and the BSD license, which more or less gives the reciever the right to do what they want with the code, as long as the original producer is mentioned (so you can build a "closed source" program based on BSD code).

That's typically only true only if you link to a libmysqlclient version later than 3.23 (maybe later - of the versions I have on my machine right now, 4.0.24 is GPL and 3.23 is LGPL licensed). It's permitted (with a few restrictions) to link any program to an LGPL library. By the way, there seems to be some question as to weather dynamic linking can legally be seen as a derivative work (though I would not try to put my eggs in that basket).

Also, you have no obligations under the GPL or LGPL if you don't distribute your work - both licenses are only activated by distributing a (derivative) work. Merely using MySQL does not force you to do anything.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Actually, it's if you "bundle" MySQL in with your non-OSS application, then you trigger the commerical side of MySQL's dual-license and you have to puchase a commerical license. However, merely the use of MySQL on a customer's machine doesn't trigger anything. The customer has chosen to install MySQL as part of their system and then chosen to use your application. You haven't bundled anything. The same goes for the web application you're hosting on your machine and other people pay you to use it.

In other words, unless you're distributing a Win32 app for the masses, the commerical side of MySQL's license is usually irrelevant.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

No, an application that links to GPL code (as last versions of MySQL client library are) can only be distributed as GPL'd.

No you don't. That's like saying if you use Linux to run your product, your whole product becomes GPL'd.

Walking the road to enlightenment... I found a penguin and a camel on the way.....
Fancy a yourname@perl.me.uk? Just ask!!!

That's like saying...

No, it isn't.

MySQL is distributed under the GPL license, and specifically, the MySQL client library is distributed under the GPL license and so, any code that links that library (as DBD::MySQL does) has to be released GPL'ed.

This document explains it all.