I have spent the last two years of evenings and weekends developing a small, but flexible, even powerful in places, little CMS (all Perl, HTML::Template, and MySQL). When we develop a site for a customer, we give them the option of purchasing a "license" to use the CMS in conjunction with their site (sliding scale based on number of users and pages).

Point here is: I've got hundreds of hours into this that I would like to protect. The fact that it sits on a customers host makes it available for the taking.

I've had two trains of thought: 1) this is commercial software so protect it, 2) consider this "open source" and not worry about it—we've all spent hundreds of hours writing programs. Anyway, let me unpack each.

Commercial tack:

I could think of this like other commercial software. But that is usually purchased and resides on my own hard drive. Those are usually easier to protect, e.g., using the machine's ID.

The web installation is a little trickier. For instance, our CMS uses a third-party wysiwyg editor that we purchase for each installation of our CMS. Of course, once we have it, we could just use it unlimitedly, but we're honest folk and just keep buying copies.

For our own CMS I've thought we could:

  1. require that we host their sites so we only one copy is necessary—a copy we have tucked away and can easy control and update
  2. let them host their own, but link to our server where the CMS resides and is run from. But this strikes me as messy, if it can even be done feasibly.
  3. have a chunk of core coding that remains on our server, and is called like any library module. Of course, any enterprising coder can simply write in the missing code.
  4. are there other ways?

Open Source tack:

To be honest, I'm not completely sure what qualifies as open source. With the number of excellent open source CMS's out there, why is another one necessary? Especially ours—one that is written specifically for graphic designers who want to limit the customer's use of colors/fonts/grids in order to keep the brand identity under control, and does require more extensive setup.

Bottomline: I want to protect and profit from my investment, but I want to be fair to the programming "community." I'm sure there are monks that work for companies, or have their own, that need the financial security of selling their software. However, though I had to buy my most excellent code editor, I still profit indirectly from the availability of Linux, MySQL, CPAN modules, and, of course, Perl itself.

What do others think/do? Any other software moguls out there? Or is everyone part of some programming commune? Thanks all!

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

Replies are listed 'Best First'.
Re: Protecting our work
by fizbin (Chaplain) on Aug 27, 2005 at 13:43 UTC
    There is another tack that a senior programmer at my job once suggested for our core software: consider it commercial but trust all of your customers to be basically honest. This is not hopelessly naive: it's based on the idea that those who really wanted to rip us off would anyway, no matter what we did, and that our customers were by and large big financial firms with regular internal audits. The upshot is that the monetary difference between "assume everyone's honest" and "lock the stuff down" was not big.

    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@/

      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.

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

      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
Re: Protecting our work
by Ovid (Cardinal) on Aug 27, 2005 at 18:18 UTC

    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.


    New address of my CGI Course.

Re: Protecting our work
by GrandFather (Saint) on Aug 27, 2005 at 21:56 UTC

    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.

    Perl is Huffman encoded by design.
Re: Protecting our work
by CountZero (Bishop) on Aug 27, 2005 at 21:31 UTC
    A good contract which clearly spells out the limits of their licence AND some <meta> tags in the web-pages' header which clearly identifies these pages as being made by your system and perhaps even identify the individual licence this page is linked to. GOOGLE will pick up the <meta>-tag and then checking if your customers are honest becomes as easy as GOOGLING for your custom <meta>-tag. Of course it can easily be circumvented but that would need some "hacking" into your code and if your customers are that good, there is probably little you can do to stop them from defrauding you.


    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Re: Protecting our work
by Joost (Canon) on Aug 28, 2005 at 01:17 UTC
    On closed programs: it is really hard to distribute a perl program which cannot be read by someone determined enough. The same can be said for most interpreted/vm-based languages by the way, including Java and .Net.

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

Re: Protecting our work
by themage (Friar) on Aug 30, 2005 at 14:42 UTC
    Hi Brad,

    I have mostly the same problem that you have, with the same type of software.

    Yes, there are too many open source CMS available out there, but I wanted something diferent, so wrote my own CMS using MySQL and HTML::Mason.

    But, for me, the licensing isn't a problem at all, since I decided some time ago that all software that I would write by myself would be licensed as GPL or similar, and made available at http://www.code.online.pt. The only software I wouldn't license as GPL would be the software that I write on request (and that is written for the client, the client choose what he want to do with it).

    The question remains, how do we profit from the software we write? Well, as I did write most (all) of my software to solve problems I had, including a simpler way to create sites to my clients, and to clients of my clients, I profit wroking less for the same result and, usually, the same profit.

    Before I used in average four days to complete a dynamic site, that with BWPMS (not yet stable, and not yet available) I complete in a single day.

Re: Protecting our work
by salva (Canon) on Aug 28, 2005 at 15:40 UTC
    if you are using MySQL, you have to release your code as GPL or buy a commercial license from them.
      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.

      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.