Cyan Content Licensing Proposals

Content Licensing Request

Introduction

Open source is succeeding as the community provides its first tested update to MOULa. We are directly experiencing the next challenge in our progress toward "Open Uru," Open Uru being what is created by code, content, creativity and participation. The ability to work with and distribute MOULa content under license will determine what we can and cannot do for the future of the Cyan Worlds Engine and MOULa. Working with content will in large part be responsible for increasing the interest and participation of developers, artists, and players to create a broader audience.

We are not attempting a complete statement of the aspirations of the fans with respect to MOULa content licensing. This is an exemplar of specific cases representative of fan efforts to improve MOULa for the community where it is hindered by the absence of a suitable license for the adaptation and distribution of MOULa content. These examples are used as a means to explore the licensing possibilities with Cyan Worlds and to elicit feedback on its own potential difficulties so that we might collectively establish a way forward.

Examples

• Localization - Cyan Worlds, Myst, Uru and MOULa all have an international audience. MOULa has an extensible localization system that allows content creators to provide translated text automatically. Unfortunately, many of the dialogs currently in MOULa don't take advantage of this capability and cannot be adapted properly without modifying them. GULP (formerly the Uru Localization Project) has a database of community-contributed translations in a large number of languages. H'uru has done Unicode development to allow non-US keyboards.

• Derivation - We have textures and limited content (KI and avatars) but they are unlicensed. We cannot distribute work such as scrollbars for the KI for the community to enjoy. We would like to be able to create, serve, test, and contribute work that is consistent with existing MOULa ages for eventual inclusion on MOULa.

• Distribution - Shards cannot serve binary MOULa content files. This raises the barrier against non-technical users faced with manually copying MOULa content to their shard folder as part of the shard install. The technical support load is increased, creating barriers of time, effort and cost for shard owners as well.

• Improvements - MOULa ages cannot be repaired by fans to function as designed. For example, a player who links to AhnonayCathedral always finds the automatic door closed while at the same time players who are already there see it wide open. The fix requires a change in the .prp file which currently calls the door responders directly instead of calling an intermediate Python file. We need a content license to change, test and distribute .prp files.

Community Needs

There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:

• A permissive license to allow copying, translation, and distribution of information available in MOULa. For example, the .loc and .prp files. This would legalize, for example, the translation work already done by the community and enable its distribution and enjoyment.

• Access to 3ds Max source files for GUIs or other useful materials used in MOULa to normalize their use of the provided hooks in the code which they currently do not use, and a license to redistribute at least the compiled output with fixes applied. If that is impossible, an alternative is a license to modify and distribute existing .prp files containing fixes or new features such as translatable GUI items.

Questions

• Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?

• Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?

• Are there specific limitations that fans should place on their hopes for content licensing?

• Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?

Summary

We have presented collaborative concerns about the problems the community seeks to resolve regarding content licensing. We believe Cyan Worlds knows best what solutions are available to it. We hope this will be a successful collaborative path to a general solution.

The representative community members who sign below collaborated to discuss and contribute to this letter of many authors. Thank you for reading and considering this request.

This document's history on the wiki: http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals

Full discussion on the OpenUru.org forums: http://forums.openuru.org/viewtopic.php?f=91&t=635

Signatures

OHB 19:24, 2 February 2012 (MST)

Hoikas 19:31, 2 February 2012 (MST)

Branan 21:08, 2 February 2012 (MST)

Christian Walther 05:28, 3 February 2012 (MST)

Leonardo 06:16, 3 February 2012 (MST)

Mac Fife 12:12, 3 February 2012 (MST)

Nadnerb 14:36, 3 February 2012 (MST)

Malfhok, an explorer 05:14, 4 February 2012 (MST)

Deledrius 08:57, 4 February 2012 (MST)

Marten 09:44, 5 February 2012 (MST)

D'Lanor 00:00, 8 February 2012 (CET)

GPNMilano 23:36, 8 February 2012 (MST)

JWPlatt 10:51, 15 February 2012 (EST), Jonathan Platt, OpenUru.org, (Address TBI)

---

Following is additional technical information.

Technical Information

The .loc files are XML files containing translations for all textual items in Uru. GULP (http://rel.to/gulp) already has an extensive library of translations and a system to export that database to Uru-ready .loc files. Not all of Uru uses these however, as some values are hard-coded in Python scripts or the PRPs themselves, but this can be converted as the GUI items have the ability to reference the XML paths directly. Much of this Python code references the GUI items by TagIDs, which are arbitrary unique numbers used to refer to the resource. This is messy, as it must be updated when the GUI is updated and can otherwise become out of sync; it is also problematic in the current data set as not all translatable GUI items have been assigned TagIDs, meaning they must be found (if at all) by very fragile code. There is also an embedded text field in these items, which currently contains only the English text. Fortunately, these items support a self-describing LocalizationPath which automatically informs the Plasma engine's LocalizationManager which string to use, allowing localization to be handled cleanly and consistently. All of these items are a part of the data and without a license to modify and distribute the PRPs, we cannot continue the efforts to localize Uru outside of using hacks and shims to the existing elegant but under-utilized engine.

As an additional benefit to Cyan: the changes made under the proposed licensing could be relatively easy for Cyan to integrate back into their own assets without affecting current functionality. This would be impossible if only binary changes are allowed to the exported PRPs rather than the .max sources, and it allows Cyan to take advantage of the localization code changes in the engine once it reaches maturity in the community testing with very little friction.

An extra note about the alternative suggestion in (2) which only allows modification of PRPs -- The reason this is inferior, aside from the obvious, is that while it would allow the immediate goal of activating the built-in localization, I anticipate minor bugs such as text flow and sizing in the UI when displaying languages other than the one for which they were designed. These will be extremely difficult to fix under the limited alternative solution and should be far simpler with access to the original 3D Studio Max source files.

License Suggestions

I was going to wrap up by suggesting licenses in order to simplify the burden on Cyan, but as the OU Content Licensing thread proves there are many viable options and they all address different needs. Unfortunately, in order to find where that spot of compromise is we'll need feedback from Cyan on this point. I implore Cyan, should they wish to consider this request, to respond with their concerns and needs first. At that point tangible suggestions can be made regarding the specifics and the proposal can move forward should they be agreeable.

At any rate, for the .loc files I'd suggest terms which preserves Cyan's ownership of the text (some of which, being canon from the Myst universe, has inherent value to them), while allowing edits and distribution by the community. A disclaimer stating that Cyan is only responsible for the original English text may also be desirable.

Links

Forum link: Content Licensing