Content Licensing

[Christian Walther]

I have a theory on all this (and somehow I missed Branan's earlier post where he suggested different licenses for ages and assets): Possibly Cyan are uncomfortable about an "open source" license on content, i.e. "open" in the conventional sense that you can use the material however you like. Maybe they want to say "Yes, we want you to have this, but we want it only to be used for MOUL/Plasma/CWE in which case you can use it freely. We don't want it to be used with any other engine or in any other context. We also don't want you messing with our age designs in a way that changes our stories or that makes us look bad". That would be a much more difficult license to construct.

Playing devil’s advocate, I wonder if even such expectations might be seen as demanding and ungrateful by Cyan, lowering their inclination to talk to us. What if they would rather not have their neighborhoods fitted with different lamps, or even their textures replaced by higher-resolution ones, no matter how much of an improvement we may consider it? I’d be conservative for now and set my expectations at “You don’t get to modify it, period”.

[branan]

Playing devil’s advocate, I wonder if even such expectations might be seen as demanding and ungrateful by Cyan, lowering their inclination to talk to us. What if they would rather not have their neighborhoods fitted with different lamps, or even their textures replaced by higher-resolution ones, no matter how much of an improvement we may consider it? I’d be conservative for now and set my expectations at “You don’t get to modify it, period”.

The updated CAVCON stats make it pretty clear that there just aren't enough fans willing or able to give Cyan enough money to support development. If they're not willing to let the community take over the content and story, then URU is going to stagnate and die. Hopefully they want to see URU thrive more than they want to keep tight control over what they've created so far.

EDIT: I realized this might have come off as a bit harsh, so I wanted to add a bit more here.

If Cyan was in a position where they could continue their story and content, I'd want to see it play out - warts and all. But that's just not going to happen. Everyone, Cyan and fans alike, needs to accept that and look at how to handle things moving forward. We've all seen the fantastic work that this community can do. To allow URU to stagnate while such amazing talent is available and willing to work for free is rather depressing.

I would hope that the Cyan leadership is able to recognize that it's time to let go, and let the community have control. The fans are in a far better position to care for URU than Cyan is.

Yes, this will mean some of what Cyan has done will be changed. I understand the desire to take a creation and enshrine it, but URU has always been a world that was meant to change and grow. I wouldn't want to see that aspect fade in the face of changing circumstances.

[Aloys]

If I may pop from under my rock for a moment:
Didn't we already have that discussion last year? And the year before that? And the year before that? And...

As much as I enjoy everybody's commitment here (or the 2.5 other forums that we still call the Uru community) Uru is already dead. Has been for a while. Some of us are just playing crazy doctors injecting electroshocks in the proverbial dead horse to make it twitch and claim "it's alive!". It's not. It's been dying a slow death for years and we all know that.
I don't mean to undermine anybody's good will; heck I'm still working on Ages on the side. I just state the truth as it is.

As for Cyan trying to balance control vs success. This too has been going in circles for a while. Trying to keep control made business sense in 2006; but that was 6 years ago and we know now that success is not around the corner (or anywhere else). But it still makes 'ethical' sense given that Uru is their creation and they have every right to want to keep control over it. And that's not something I'm going to argue with. Some (many?) people might think it's silly at this point in history; I'm pretty sure most of those people never had one of their cherished creations defaced and exposed publicly.

The bottom line is Uru is dead/dying, and there is not much that can hurt it more. If only for one thing: the community is so small by now, that I think we must have only 2 griefers left. Most of the people left who could care enough to create content for Uru would most likely care enough not to 'deface' it or damage it.. (no flying purple penises in the Cavern, ha.)
If anything I think opening content would be a nice testament of respect/love from Cyan to the Uru community. But I'd be impressively surprised if that happened. That would have happened long ago IMO.
Yes, the community is in a better position to take care of Uru than Cyan is, but that doesn't mean they're going to *totally* let it go any soon.
Ah well..

My honnest opinion is: if some people are caring enough and motivated enough to make some good meaningful changes to the content they should do it. If it is indeed good stuff, I don't think Cyan will sue anybody. Besides, by now only a handful people would see that content anyway. :/

[Mac_Fife]

I’d be conservative for now and set my expectations at “You don’t get to modify it, period”.

I think that, along with an authority to redistribute the age binaries, would be a big help to shard operators (gets rid of a lot of client install/setup issues) at least as a starting point. I think the current TOS probably covers it from a use/modification restriction perspective already.

I'd agree with Aloys that the prospect of any Cyan led story development seems very remote now, but I wouldn't be quite as inclined to take the same pessimistic view on the Cavcon status: Dropping to 3 through December/January was probably predictable as people have other things to think, and other things to spend money on. The recovery to 4 once it was realized that the true state had been hanging around 2 for some time was fairly dramatic, and while there was obviously something of a "panic boost" at that time I think it's still evidence that there are people who care.

But, any story development aside, there are still things that could be fixed by fans in Cyan's ages, and fixed more easily with access to the Max files (e.g. missing/misaligned collisions, etc.), and without really "altering" the ages.

[Leonardo]

Dropping to 3 through December/January was probably predictable as people have other things to think, and other things to spend money on. The recovery to 4 once it was realized that the true state had been hanging around 2 for some time was fairly dramatic, and while there was obviously something of a "panic boost" at that time I think it's still evidence that there are people who care.

And I also think that what "helped" to drop CAVCON from 4 to 3 is that Chogon has been doing some things for Uru lately: updating the website, working a bit on the code. I think that is the main reason for it dropping from 4 to 3, along with Christmas being in the middle.

[Deledrius]

Here's a direct proposal, broken up into bite-sized pieces. Any feedback is welcome.


-- Problem --

Uru has an amazing international audience, and a very awesome and extensible Localization system which allows content creators to provide translated text to be utilized automatically at runtime. Unfortunately, many of the dialogs currently in Uru (particularly those added for MOUL) don't take advantage of this capability, presumably due to lack of budget and manpower, and cannot be adapted to do so properly without modifying them.


-- What the Community Has Accomplished Thus Far --

Thanks to the amazing efforts of OHB and everyone at the UruLocalizationProject, we have a database of translations in a large number of languages. It is constantly growing and has several near or at completion. My own minor changes to the code re-enable the functions which had fallen into disuse after UU's closure. Several others across the community have contributed code fixes which address various problems in the input routines that now allow non-US keyboards, among other things.


-- What the Community Needs to Continue --

There are two primary allowances we need from Cyan in order to continue our efforts to expand Uru's accessibility:

1) We need a permissive license that would allow us to copy, translate, and distribute all textual information available in Uru, currently located in the .loc files. This would legalize translations and allow their distribution, a necessary step to put all of the community's work into use.

2) We need access to the source files for all GUI used in Uru so that we can normalize their use of the provided hooks in the code which they currently do not use, and a license to re-distribute at least the compiled output with those fixes applied. If that is deemed impossible, an inferior solution that would allow at least this specific goal is a license to modify and distribute the existing PRPs containing translatable GUI items.


That's the short form. If you're not technically-minded, you can safely consider your reading complete. Thanks for reading and considering our proposal.



-- Technical Information --

The .loc files are XML files containing translations for all textual items in Uru. The ULP (http://rel.to/ulp) 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, with some values 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; also it is 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 with the efforts to localize Uru outside of hacks and shims to the existing elegant but un-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 inferiority of (2b) -- The reason I mention 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 flow and sizing in UI when languages other than the one for which they were designed are used. These will be extremely difficult to fix under (2b) and should be far simpler under (2a).


-- License Suggestions --

I was going to wrap up by suggesting licenses in order to lighten the load 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 proposal, 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.

[Hoikas]

*tumbleweed*

/me brushes that crap away

This seems like a good idea to me.

[Mac_Fife]

This hadn't been forgotten about; other things have been grabbing our attention over the past few days, and I've been considering how best to reply to Deledrius' post, because I think it's too little and at the same time too much.

Don't get me wrong, I think it's a great first cut to work from and I certainly don't dismiss any of it, but I think it really only addresses one "use case", the localization of Uru. It doesn't perhaps consider others valid uses of content such as shard owners wanting to redistribute content wholescale, or age creators wanting to reuse textures or small objects within their own ages. Beyond that there's what I think may turn out to be a slightly more vexed question of modifying/adapting the Cyan ages themselves. I think in taking a proposal to Cyan we need to have a reasonable handle on the scope of all the use cases, so we don't end up saying "Yeah, see that license we all bought into? Turns out it doesn't cover XYZ. Can we get a different one?". So, that's the "too little" part.

In doing that we also need to make sure that we do it concisely. We're presenting to people who've got a business to run, and don't really want to read and try to understand lengthy emails about something that isn't going to generate any revenue. So once we've got all our ideas together we need to distill those down into a fairly punchy set of bullet points that can grab their attention. At this point we don't really know what Cyan's issues with content licensing are so we can't immediately offer a solution and all we can do initially is present what our problems are and what we'd like to be able to do, and invite Cyan to explain it's position. We can start to work through the technical details once we know what the hurdles are that need to be negotiated.

In summary, I'd like to see more contributions like Deledrius' one, but adressing other aspects of content use. Then we can collectively cherry pick our way to that bullet point email.

[Deledrius]

It's specifically meant to only address one specific thing: the localization of Uru. JW stated that Cyan is having trouble grasping the larger picture. This proposal addresses a specific, concise need and presents a simple concise solution.

Either we do this bit by bit or we do it all at once. We've been told all at once isn't an option.

If you have cases to counter my proposal's completeness, I'd appreciate the feedback. So far, I've heard nothing until now. Not even recognition that it's been read. I was hoping for a dialog that would improve the proposal if necessary so that it could be presented to Cyan soon. This is something that, code-wise is ready right now to be implemented, which is why I started with this proposal. If we had permission to do this, Uru could presently support the community efforts with the code that is on the master branch as of last week and has been actively in limited testing on other branches since last July.

By keeping the proposal small my hope is that it should make it easy to assess consequences, as well as easy to read for those at Cyan with little time or interest in devoting to it. Also, it is precisely what is needed (and no more than is necessary in this regard) to continue improving the quality of play for international Uru players everywhere.

In doing that we also need to make sure that we do it concisely. We're presenting to people who've got a business to run, and don't really want to read and try to understand lengthy emails about something that isn't going to generate any revenue. So once we've got all our ideas together we need to distill those down into a fairly punchy set of bullet points that can grab their attention. At this point we don't really know what Cyan's issues with content licensing are so we can't immediately offer a solution and all we can do initially is present what our problems are and what we'd like to be able to do, and invite Cyan to explain it's position. We can start to work through the technical details once we know what the hurdles are that need to be negotiated.

I've been as concise as possible, using bullet points, and breaking it up into two halves: the part to show to Cyan, and then a larger explanation. I've done exactly what you're saying I need to have done, exactly for the reasons you mention, even regarding needing to hear from them before we can take any further steps. I don't mean to be rude (I'm really trying hard not to be, as I really mean to be constructive here) but I'm having a very hard time telling if you didn't read my entire post, or you're just repeating it for reasons I don't understand as an explanation for why it's incomplete. Please accept my apologies if you perceive undue hostility in my tone as I'm feeling exceptionally frustrated with what feels like valuable contributions running up against a wall for many years.

I personally believe the best way to deal with this problem is to present well-broken down problem-solution sets, as I've done here, one at a time so they can be dealt with as time permits by Cyan. Not lumping them all together into a monolithic lists of things that need to be done. Cyan (and to be quite honest, OU) have proven to have difficulty with such situations. Please do not misunderstand, this is not a condemnation; I understand that time and attention is limited. I'm suggesting that this may be the best way to work within those limitations. Certainly, there are tradeoffs to each course of action.

However, should we be taken the path of a long list of single items, then this proposal can be boiled down to this bullet point, and I would ask that it be added to the list:

• License for the localization-file contents and GUI items' 3D Studio Max sources.

[Mac_Fife]

@Deledrius: Your frustration is shared. Widely. Yes, I've read your post, several times in fact, and I do appreciate the fact that you separated out the technical detail into a distinct block. I think you've done generally all the right things there, but (and this is just my opinion) I get the feeling that the "problem statement", which is how I'd categorize the whole of the first section of the post, just seems too "wordy". I'm not trying to sound like a schoolteacher marking an essay, but I've seen how things can end up getting shoved into the "I'll look at that later" pile if it can't be absorbed on the spot. On the other hand I think the single bullet point is just too lean.

And yes, that runs contrary to my suggestion that we need have the bigger picture to present. You may be right that looking at a specific aspect is much more manageable for Cyan; I can't argue with that. What my worry is here is that we end up withat a repeat of the CWE licensing issue where once the code was visible, then the appropriateness of the license came into question and required a re-working that took several months to happen. Maybe there's an option that specific uses can be licensed separately - that's not really something I'd been considering, but I guess it's a possibility. For example we know that right now, shard operators (including the OU Minkata shard) would love to be able to redistribute the MOULa content - it makes for less hassle with client installs and repairs - but we can't really do that although the existing TOS probably isn't far off from being an adequate license to cover that Age creators have in the past been able to get access to assets under FCALs - is that an acceptable way to continue? Probably not if it means Cyan has to spend time issuing those individually, but it's an option.

At this point I'm just happy that this is stimulating a bit more discussion of the subject. None of us want this to drop out of sight.

Heh! If there was anything I was going to crticize in your post, it's that the technical information makes reference to "(2a)" and "(2b)" which I can't correlate with anywhere else in the post