My favorite board game, Agricola, has been turned into a mobile game app twice. The first time, Lookout Games had rights in the board game and, presumably, entered into a license agreement with Playdek to develop the mobile app. The result was an excellent adaptation of the board game with a few bugs. Later, Asmodee acquired Lookout and released a revised edition of Agricola (which most players see as objectively worse). Asmodee then had Playdek build a second app. The second app, however, was buggy to the point of being unplayable for diehard fans.

I have sometimes wondered why the second app was so relatively unplayable despite being developed by the same app developer as the first app. Did Playdek not start with the original app as a base? Was there something in the original license from Lookout that prevented them from doing so despite Asmodee acquiring Lookout?

The story is illustrative of the challenges of developing cross-platform (and cross-medium) derivative works, and it’s not unique to Agricola or to board games. Video game devs run into the same dynamics constantly: a video game gets adapted into a board game or trading card game (“TCG”), or a game gets ported and reimagined across platforms, or in some cases a game is used to develop a film, TV series, comic book series, or book (or vice versa). These cross-platform adaptations can be lucrative, but they raise questions devs do not always think through before signing. For example: “what does the license allow, and who owns what gets created along the way?”

Licensing the Adaptation

There are a myriad of rights that attach to creative works (like copyrights, trademarks, etc.). For simplicity, we will call these intellectual property (or, even simpler, “IP”). Before any adaptation gets built, the dev who is adapting someone else’s board game, existing video game or other property into a new work will need a license from the owner of the underlying intellectual property (which we will call “The Work”). A handful of deal terms tend to make or break these arrangements.

Exclusivity. Is the developer the only party allowed to build a digital adaptation, or could the IP owner license a competing studio to build a different app or game for a different platform? The parties should make clear exclusive rights by platform, territory, and time period.

Approval and quality control. IP owners often want approval rights over how their game is adapted, since a bad app can damage the reputation of The Work (or just not be worth the cost). Developers should understand what triggers an approval requirement, how long the IP owner has to respond, and what happens if the IP owner simply goes silent.

Sublicensing and assignment. Businesses get bought and sold, as happened when Asmodee acquired Lookout Games. A license agreement should say whether rights can be assigned to a successor or sublicensed to a third-party developer, and what happens to the existing adaptation if that transfer occurs. Developers who build an app assuming they are working with one company that is good to work with may suddenly find themselves working under an entirely different one that is terrible to work with.

Term, termination, and reversion. What happens when the license ends? Does the developer have to take the app down? What rights will the developer lose or retain? A license without a clear termination and provision giving the rights back (or clearly not giving rights back) leaves both sides guessing.

Revenue share and royalties. Who gets paid, how much, and on what revenue streams? If royalties are paid on net revenues, what deductions are made from gross revenues to calculate net revenues?

Getting the license terms right is not just paperwork. It determines what a developer can actually build, for how long, and what happens if the relationship changes, which leads to the second issue:

Who Owns the Derivative Work?

Licensing The Work is only half the picture. Once a developer starts building the adaptation itself, new material gets created: new code, new user interface design, new art assets, sometimes new mechanics that did not exist in the original work. That new material is its own copyrightable work, and ownership of it does not automatically follow ownership of The Work being adapted.

A license agreement should say, explicitly, who owns the new derivative content. A few common structures:

• The IP owner owns everything, including new content the developer creates, typically through a work-for-hire or assignment provision built into the license.
• The developer owns the new content it creates (code, UI, original art), while the IP owner retains ownership of The Work, characters, and branding being adapted.
• Ownership is split by category, for example the IP owner owns anything derived from or resembling the original game while the developer owns purely technical or platform-specific elements.

None of these structures is inherently right or wrong, but silence on the question is a problem. If the license does not address it, developers may find themselves unable to reuse their own code or assets on a future project, and IP owners may find they do not own the very adaptation meant to showcase their game. This is the same issue we have discussed before in the context of work-for-hire agreements between devs and contributors: copyright vests in whoever creates a work, unless a contract says otherwise.

Developers should also think ahead to what happens to the derivative work if the license ends. If the developer built new assets and code specific to the adaptation, can those be reused elsewhere once the license terminates, or do they belong to the IP owner going forward? Answering that question at signing avoids a scramble (or loss) later.

The Takeaway

Cross-platform adaptation, video game to board game or TCG, or film or comic book to video game, or any other combination, is a real opportunity for developers. But it starts with a license agreement that spells out scope, exclusivity, approval rights, assignment, termination, reversion and more, and it should just as clearly say who owns what gets built along the way. Get both pieces right and everyone knows what they are building and what they will walk away with. Get either piece wrong and a developer could end up finding out the hard way that they have far fewer rights than they expected.

For now, I’m going to go play some Agricola.

Have questions? Reach out!