Publishing contracts and recycling of code

Creating and correcting publishing contracts for computer games is just as much my day-to-day business as contracts for freelancers and other agreements. Again and again, in addition to questions of deductible costs, copyright is not only a problem, but can also quickly become a trap/risk for a developer studio, which is sometimes not noticed until years later.

Since I have one of these traps on the table as a mandate, I would like to have been here before. It is about the recycling of programming code in computer games. While most developer studios may be aware that things like graphics, sounds, and the like that licensed to a publisher under a publishing contract can’t be easily used in another game, so many developers can do that. program code is often not so obvious.

Whether this is possible or whether the recycling constitutes a copyright infringement to the detriment of the former publisher depends on the details of the contract. If, as is very often the case, the problem is not resolved at all, it depends on the interpretation of the Treaty to decide exactly which rights were originally conferred. It may well be very relevant which legal order the Treaty is subject to.

Of course, there are other conditions for possible copyright infringement. The code snippet itself must be protected by copyright, which may not be available for things such as rudimentary functions, for example for the response of hardware. However, larger code components may have their own protection, and at some point the question arises as to how far code can be reused. You may need to think of functions for AI, server control, multiplayer, lobby management and, of course, the graphics engine.

In the USA and in contracts with partners from the USA, very complicated questions in connection with software patents can also become relevant.

If one makes mistakes here in the original publishing contract and transfers too many components – often carelessly – exclusively, this can only mean more work/costs in case of doubt in later negotiations/contracts, since the respective things have to be redeveloped. In the worst case, however, this may also lead to claims by the original partner, including damages or distribution bans for the new game.

In the worst case, such a mistake can also mean the end/insolvency of an entire studio and thus the destruction of years of work. There have already been many such cases in industry. It is important to be aware of the problem and to knock contracts to precisely these problems. Incidentally, this also applies if a contract – which is always a good idea in principle – is checked by a lawyer. In fact, this can only be as good in contracts as the client provides information. This includes questions such as future code handling, corporate strategy and much more.

As reported at the beginning, the problem is one that is very often overlooked, because the developer in particular is not aware of the problem.