I don't understand this per-developer licensing model. Not only is it completely non-enforceable but feels really out-dated and out of touch in the era of FOSS.
I will pay for an awesome charting product, but I don't want to have to think about how many developers will touch the code, when, how or why.
Something like a license per production site or an unlimited license makes a whole lot more sense to me and allows me to quantify the cost in terms of the value it provides to my business rather than how many developers I have.
I don't understand this per-developer licensing model. Not only is it completely non-enforceable but feels really out-dated and out of touch in the era of FOSS.
Hasn't commercial software been licensed effectively per-user since forever? It used to be per-machine but these days with lots of developers using a desktop and a laptop I think it makes sense to say it's for one user at a time instead and avoid creating lots of silly infringements.
If you don't like anything resembling that form of licensing, perhaps you're projecting a preference for everything-should-be-free culture onto commercial development where someone has to pay the bills? Unfortunately, sometimes that just doesn't work.
Having a per-user or per-machine licence where the licence is not transferrable seems crazy to me, though. We consider such licensing conditions toxic, because all it takes is someone to leave or a hard drive to crash and you've lost your investment, so usually seeing that will end our interest immediately.
(For completeness: We will make a grudging exception for software that is essential to our business and can't be had any other legal way or replaced with any better alternative. However, you don't buy software like that with a quick web site download anyway, and if we get screwed on that kind of deal lawyers are involved. Obviously a charting library is nowhere near this level, though.)
In no way am I projecting a preference for everything should be free. I specifically said I was willing to pay, but per developer makes no sense to me at all.
I build a commercial product myself that I charge for.
My point is that per-developer licensing doesn't make sense on any level... just because "that's how people have always done it" doesn't make it a good idea and that type of pricing doesn't allow me to compare the cost to the value. Instead of thinking, this product is awesome and I can use it on my 5 sites for $X.. I have to think, ok I have 20 developers and 5 of them work on site A, 7 on site B and the rest float around so how many people would need to be developing with the library, etc etc.
Right? or am I missing something here and am crazy? which is entirely possible.
I agree there are certainly other models that would make sense, given that this is probably a library that's going to be incorporated as part of a larger project rather than a standalone piece of software for in-house use.
It seems reasonable to have a predictable price up-front, particularly one that can be transferred to a client as part of an overall project budget if necessary.
It also seems reasonable to have a more transparent level of scalability. Something like per-domain pricing might make a lot of sense as an approximation of buying it once for each project where it'll be used.
I suspect a commercial project like this is mostly going to be used by larger organisations who aren't going to sneeze at real money, because there are too many good-enough alternatives for the little guys. That being the case, if you want to allow for increasing value as a project grows, you could do something like per-(public-facing)-server instead of per-developer and just make as many in-house machines as you want free.
That might be awkward with cloud-based projects that activate and deactivate instances on the fly, so maybe just band it "$x for up to n public servers/instances at once", "$y for up to m public servers/instances at once", "for more servers/instances contact us for special rates".
Licensing is always a mess, unfortunately. I think the best you can ever do is probably to present something that is clear in what is covered, realistic in what it costs, and reasonably consistent/predictable.
Agree, I don't think per developer makes sense for this charting library but might make sense for other software. Say a text editor like Textmate or Sublime Text 2. Really, we might as well call it per user licensing.
I will pay for an awesome charting product, but I don't want to have to think about how many developers will touch the code, when, how or why.
Something like a license per production site or an unlimited license makes a whole lot more sense to me and allows me to quantify the cost in terms of the value it provides to my business rather than how many developers I have.