Since quite a few business-oriented questions have been raised lately, I thought I'd throw in one of my own. I don't have anything ready yet, so all of this is hypothetical. However - suppose I have a library that I want to distribute so that anyone can use it free for non-profit purposes; however, as soon as the project makes a profit, I want a cut. Questions follow: 1) which payment system would be the least intrusive/just to both parties: a one-off fee per project, exclusive use of a current version of the library (I want to reserve upgrade fees as an option) or a per cent cut from the game's revenue? Some other option? 2) the library generates output geometry. What additional steps can I take to protect it apart from providing the library as a dynamic link option only? What if the user uses the library for offline generation and then goes on to use the geometry without the library included with the program? I know this last question is way too paranoid. I'd just like to know if there are any watermaking or other options I would do well to be aware of. 3) being a sole developer I cannot provide adequate customer support. How should I go about phrasing support-related clauses in the EULA? (How) should I go about adjust pricing? What are the test alternatives to using an anonymous tester pool? 4) Has anyone had closed beta testing experience with GameDev members? 5) am I too paranoid about everything? I do not have personal commercial release experience so I find some refuge in the justification that some questions may be missing and some might be stupid :)

Quote: Original post by irreversible

1) which payment system would be the least intrusive/just to both parties: a one-off fee per project, exclusive use of a current version of the library (I want to reserve upgrade fees as an option) or a per cent cut from the game's revenue? Some other option?

One that you can enforce. How will you collect the payment after the fact? If they use it in for-profit work, how to make them pay? Typically this would be handled with lawyers. Percentage? Forget it, unless the technology is patented, they are already using it, and you can sue them. Voluntarily it's next to impossible for an indie to get percentage.

Anyone who makes non-trivial money will be big business (not indie or such). This means they have procurement department. Those manage a lot of paperwork. They stall. They issue more paperwork. They'll take you for a ride. It's a full time job dealing with them. It requires coming to a licensing agreement, and all of that must be done upfront before they even look at your library.

For small-time payments (one-time, no restrictions, < ~$700) it may be simpler, but still require paperwork. I forgot exactly how big various budget limits are, but individual department heads can authorize up to a certain amount.

Quote: 2) the library generates output geometry. What additional steps can I take to protect it apart from providing the library as a dynamic link option only? What if the user uses the library for offline generation and then goes on to use the geometry without the library included with the program? I know this last question is way too paranoid. I'd just like to know if there are any watermaking or other options I would do well to be aware of.

First - nobody will even look at your library if they will not be guaranteed life-time ability to use it. Since you are not Microsoft who will be around in 50 years, there is effectively nobody in business that will accept anything that is not in source form. If you have an existing business, the technology you own is licensed (patented, trademarked, something with monetary value that can be sold off in case company goes bankrupt), then it's worth exactly zero to anyone who is in business (aka is earning money). The risk of tying any non-trivial part of development to a library you don't have 100% permanent control over is simply too high.

Exception would exist if the technology you offered were novel and patented. Then you'd sell license to the patent, along with proprietary/closed-source implementation.

Quote: 3) being a sole developer I cannot provide adequate customer support. How should I go about phrasing support-related clauses in the EULA? (How) should I go about adjust pricing? What are the test alternatives to using an anonymous tester pool?

Without support there isn't much on table. Might as well open source it.

Another big issue will be patents. Any large company will require a statement that you are not in violation of any. Considering it's a geometry library, there's likely plenty of them.

Buyer may also require you to assume responsibility for any IP claims and damages. In practice, if someone sues big publisher for IP violation, they just shift the costs to you, both for process as well as damages. CAD companies have patented effectively every possible permutation of geometry manipulation, so your best bet is to prove via expired patents.

It really is an annoying and difficult issue, which is, in practice, side-stepped via open source and support contracts, rather than by selling packaged products. Those do not eliminate liability, but make many issues simpler. The claim about non-profit work can also be made, thereby negating many damages claims.

Quote: 5) am I too paranoid about everything?

Unrealistic with regard to value of such software.

If developing technology, then it's about patents and trademarks. Ugly and expensive.
If it's about tools, then it's all about support and customization.

But all of the above is general big picture. It's always possible to find a niche, if your work is interesting (or not interesting - i.e. others don't think it's worth their time) enough.


As a more practical advice - without strong corporate backing, these types of technologies these days are released as open source. If they gain traction, and they really are useful, a big company will usually become a beneficiary, and often hire the developer to continue the support and development, or provide long-term support contract.

Otherwise, for technically advanced algorithms, the libraries are often provided by universities, sponsored by grants, and then published as some basic open source version for users to adapt to their needs.

Third option is "boring" support. If library needs to support many platforms, language bindings and other such trivialities, then users may find just maintenance of the library adequate saving (rather simple, but slow and time consuming work), and will likely license that as on-going support contract. The value there lies in delivering tested library that works out-of-box on many platforms the buyer uses. Prices here are small, and rely on having adequate number of customers. Fast turnaround and issue resolution rates are a must under this model.

Sorry for not getting back to you sooner - I was away for the w/e.

I have a few followup questions as you managed to bring my level of unrealism down (or, conversely, my level of realism up) a fair amount.

a) When you say I should be prepared for a full source release, you mean only as part of a sold copy, right? Not open source in general. I still want to provide a free use option for non-commercial projects, but I do not want to release open source.

b) I hadn't considered the patents issue. I've written all of the source code myself so I shouldn't have any IP conflicts. However, I couldn't really be sure of patent violations. What's the easiest way to check? What procedure should I follow to identify as many of the potential patents I might be using? I know of two algorithms that I can check as I know the name and have the original freely available papers on (one of the algorithms being an adjusted implementation of Laidlaw's CSG routine). However, I'm not sure how to approach the rest of the code.

c) the library derives from a paper and implements it practically fully; the catch is that I'm expanding the algorithm itself so much that the original paper only amounts to the very core backbone. For the love of me, it's not my aim to start dealing with patents. I really hate the legal aspect of it seeing as I've sweated and bled my way each and every step of the progress so far by purposefully avoiding any and all external dependencies.

d) I think the library fills a niche in the industry and has a rather broad spectrum of potential uses. The realistic uses I cannot predict. I choose to remain optimistic, though.

e) "First - nobody will even look at your library if they will not be guaranteed life-time ability to use it.". So, effectively, asking for per-project compensation would be a logical impossibility? Or am I misunderstanding you? It's not a piece of software that can have regular version upgrades. Once it ships inside a piece of software, it's in there forever. I'm not sure I completely understand why asking for per-project or "per-engine" compensation would be too difficult. Or am I being too naive again?

f) "For small-time payments (one-time, no restrictions, < ~$700) it may be simpler, but still require paperwork. I forgot exactly how big various budget limits are, but individual department heads can authorize up to a certain amount." I haven't thought of pricing yet, but if the library could be licensed per project, I would imagine a $300-$1000 fee would be reasonable for a non-AAA title. I would not expect AAA titles to use this library due to the sub-par testing reasons mentioned in the OP - at least not initally, even though some might pick it up the way box2D and such have been as they've improved and become community-tested.

g) "If it's about tools, then it's all about support and customization." I have a VERY heavy stress on customization. Which is what should make this library rather unique - in addition to the fact that I really do not know of any other product that would fill an even similar role. The technology itself, however, is not that new. I already mentioned my concerns about support.

h) "Otherwise, for technically advanced algorithms, the libraries are often provided by universities, sponsored by grants, and then published as some basic open source version for users to adapt to their needs." This is not the case here - I'm not developing a new algortihm; rather I'm providing a relatively internally complex, but externally very sleek and straightforward customization module that can be used both in an editor (provided by me) to design and from source code to replicate a result. I would really consider the coding part non-trivial, even though the logic it employs is relatively straightforward.

i) I've no idea how to go about enforcing any of the mentioned payment schemes. I should think a one-off would be easiest, but I do want to tie the one-off to a measurable entity - preferably a single title in which it will be used.

j) supposing I go open-source like box2D or Chipmunk - would there be any consolation I could take refuge in, thinking that I also want to have a commercial version or the library? Would there be any way of truly limiting/controlling branching, which I do not want to occur? To put it simply: what would you suggest? After all, it's not like I could write a new Google alone, and I do not claim to be doing that.


To recap: I want to make some money off of it as I've put too much blood into this already. I do not expect to get filthy rich. Once in alpha v1.0, I want to continute testing and bug fixing it before expanding it further. I do want to have a free version of the library available to encourage general game development, however.

Target crowd: game dev, visualization, film and presentations; possibly, but unlikely physical simulations. Stress remains on game development.

PS - thanks for a beautiful a reply, Antheus!