Content Licensing

[Malfhok]

Hey everybody… Common average joe explorer here who's been reading along and looking for ways to help. Would you guys find my signature helpful at all? I'm unclear with the discussion if an "average explorer's" signature would be useful to the proposal.

[Mac_Fife]

I think you can answer the question for yourself - If you've read and understood the request (which you clearly have because you made a correction) and it's something that you feel you'd like to see progress on, then you should feel free to sign it.

I think what JW was getting at is that this shouldn't be treated as an exercise in simply getting "as many signatures as possible" but in demonstrating a widespread support for the purposes behind making the request.

[Malfhok]

I shall, then.

[Deledrius]

Thanks everyone, it's looking great. I tweaked a few words based on the feedback and added my signature.

And now, some things to which I've been meaning to respond:

One comment I might make (in general) is to avoid trying to suggest that anything might be "a benefit to Cyan" when talking about MOUL - Maybe better to talk about "benefit to MOULa" or "to the community". The logic here is that from a business perspective "Cyan" gains nothing from Open Source or MOULa; it's all more a personal gratification for the folks involved, if you see what I mean.

I think I would agree with Mac on this point, even without the example he gives. If I'm Cyan (Disclaimer: I am obviously not Cyan.), and I'm reading a proposal that talks about the work I do for product I'm not selling benefiting me, I would either be greatly amused or marvel at how stupid the idea sounds. After all, something that doesn't bring in cash is likely not beneficial to them right now. Of course, such a statement could have the unintended effect of causing said proposal to be taken less seriously. People tend to do that when they read things that they think are stupid.

I don't know. I suppose it's possible (and given their behaviour, likely) that Cyan sees the entire community as "those kids out back tinkering aimlessly with the old junker car we tossed" but the way I see it the only way to expect them to respect the work we're doing is to treatit like something they respect. If they truly see nothing we do here as a benefit to them since they've moved on to more modern engines as Rand mentioned at Mysterium, then I hope that they have enough sense to see that Cyan, as custodian of MOULa, still benefits from community-based enhancement. I have faith that they will see this. I wish, for the sanity of OpenUru's management (as well as everyone else's), that we had a clearer path for sending those enhancements to them. For now I must be content with letting them know through the wording of this request/proposal that we are interested in submitting enhancements as usefully and smoothly as possible.

The document so far is really a good job; nice and short, good style. I have to go back to read Deledrius' post to compare how his concepts have been carried forward. I'd like to just note that the letter at the moment reads like a treatise on localization. While that is part of it, I believe the document is too specifically focused on it and I am realizing now any specific use case will channel thought too strictly on any one thing. In matters like this you probably don't want to restrict the dialog to specific requests, even if it is a starting point. I think it should be broader so Cyan can sit back and ponder a while about their own implications. When I have a chance, soon, I intend to add a bit more scope and deal with serving content. I'd either add that as a second use case or reduce both and add a third thing by writing "such as localization and serving content..." kind of thing.

I still disagree with your idea of scope on this. You've surely had more contact with Cyan regarding these things, so if you know something specific it may be helpful to share if possible. Barring that additional information, I strongly believe that a small, concise, direct request for something we can use right now is best. It's easier to push a small pebble through a straw than a large boulder.

I would also not use absolute words like "all" (GUIs) because it looks like a demand and part of the point is that we don't know Cyan's situation enough to specify "all" even if you are trying to say that "all" is the only choice for a complete solution.

I chose the word "all" specifically because anything less would leave us incomplete, and needing to go back to ask for more on the same topic again later. I chose my wording carefully to make this request as complete as possible, so that future requests could build upon its success, rather than repeat it to fill its cracks. Perhaps it is a demand to expect 100% of a small piece of something, but I do not feel it is an unwarranted one nor one that is presumptuously made; I justify this in the request. Currently, the request now reads "the GUIs", and while that can reference all it is ambiguous in doing so and may result in an unfortunate misunderstanding should this go forward.

"Inferior" is a subjective word and projects an attitude or opinion and "at least" does the same thing with more grace. Cyan is smart enough to understand it's inferior by implication. I think we'd be better off to keep it objective. Those are my specific criticisms for now.

I agree, it has been changed by recommendation to "alternative". Together with the later explanation of re-integration upstream to Cyan, I'm sure it will be obvious implicitly that this is inferior. My intent with the original wording was to direct Cyan away from the "easier" route which would have been insufficient in the long-term but presumably tempting due to the less far-reaching implications to their property.

Not being accustomed to such public displays of unity, Cyan should at least take notice and be encouraged to try.

Let's hope so!

[JWPlatt]

Greetings,

Before you all ask, "What's happening with this?" here's a personal update. This week or by this weekend, I will carefully review the document and post any tweaks I would recommend for it. After giving it some time for everyone to complete their final reviews, assuming no more community edits, we'll send it to Cyan. There's a pretty good representation among the signatures so far, but if you feel any important signatures are missing, please tell the persons about this thread.

JW

[Deledrius]

This week or by this weekend, I will carefully review the document and post any tweaks I would recommend for it. After giving it some time for everyone to complete their final reviews, assuming no more community edits, we'll send it to Cyan.

Great news! Thanks for the update JW!

[Nalates]

We are still going to have some challenge getting Cyan to spend time and effort on what may be a complex legal issue for them. I can imagine Rand or Tony thinking of the prospect of reviewing all the agreements with dread. I can't imagine it being an easy task. Also, they may have to spend time dealing with others involved in the agreements and working out additional agreements.

The idea of crowd funding is in discussion on the MOUL forum. So, this might be a project where the community can kick in money to pay for the time to do the necessary reviews. We just need Cyan to give us an amount. For them to do that we probably need to give them a clear definition of the project they are estimating cost for. This licencing doc may be able to provide that.

See:Adventure Game Kickstarter by Double Fine Productions! and my post.

And... this coin has another side. If we are given an amount and fail to meet it... what will that say and how will Cyan handle it. I do not know the players well enough to guess. I think JW, Mac, Andy, and others that work with the Cyan side will have to make the call.

[OHB]

I don't think we can just be like "Here do this" and throw some money at them as incentive. This is the process that Cyan asked for, right?

[JWPlatt]

Greetings. I am presenting here first, before doing anything on the wiki, some alternatives for your consideration to include or modify the working document on the wiki. Please understand there is more thought and experience behind this than what I write here that I cannot hope to convey in its entirety. I hope the rationale will be self-evident, but I'll do my best up front.

To skip all this and get to the point, my proposed revision is at the bottom of this post.

There's lots of good in the document as it stands. Most of the words are already there. My comments to follow only discuss what I think needs improvement or reorganization.

We need more than one use case. Localization is important, but the document to too centered on it. I'd like to trim it. The heading of "Localization Licensing Request" is misleading because that's really not everything this is about. Mentioning only GULP isn't enough for a letter representing an entire community. We are much, much more than just one project. But I do like the solid example of something tangible that's waiting for permission to act. Is there an additional example of a successful community project that could directly benefit MOULa that we can include? I'd be more comfortable with two, or even three, than one.

I want to add four bullet points for use cases. I disagree that Cyan needs one use case as a starting point. These are very smart people who will see the implications and consequences better with a little more information that makes our plight clear. They will still be able to read this document in about three minutes and understand these are just examples in a larger scope. Other portions of the existing text do explain this. If Cyan feels they need to limit what they can do immediately or over time, they'll have more ideas up front to choose from and prioritize.

There are some habitual, filler phrases such as "Please note," "At this time," "utilize," or "in order to" that can be removed from the text without changing the message. The voice of the document becomes stronger and more active while reducing the word count as much as possible and increasing the information density. i.e., Don't waste words getting to the point. We can get wordy when a true dialog begins and knowing the details becomes more important.

I would avoid words like "implore" because they are overly dramatic and obviously used as hyperbole in an effort to sway the reader through an artificially dire tone. If you want to reach professionals on their level, try to keep it emotionally honest and realistic.

"What the Community Has Accomplished Thus Far" mentions just one achievement. We've done much more. Such a heading literally demands a fuller account of everything the community has done. We don't want that because we want something brief and to the point. I also wouldn't change the heading just to suit the localization project. So I would remove it entirely and put the substance - not verbatim - of the text in the bullet point below about localization.

"What the Community Needs to Continue" is okay in essense, but needs a trim and at least some of it I think is better broken out into a last word or summary.

I've written a paragraph for the preface that I wanted to keep to four sentences with a progression through the problem from the good faith of current success, to the problem of content, to the hope of what a solution could achieve. That leads in to a request for a dialog or discussion.

I have tried to be more inclusive: "fans" instead of "fan developers".

I am making edits that do not include the assumption of a single use case.

Where "Uru" is mentioned, except the term "Open Uru," which is unencumbered, I have limited it to "MOULa" because Uru as a product can be confused with the retail games. Our concerns are strictly limited to MOULa. It should be clear that we are not trying to reach into other Cyan products that might be encumbered. Also, MOULa is something Cyan cares about so they should be able to identify better with what can benefit MOULa.

I added a question. Are there too many now? Or is that good?

There are other minor edits and such.

Thanks much to D'Lanor for providing in one of his posts here some material I saw about fixing MOULa content (AhnonayCathedral). It makes a great bullet point.

I apologize for taking this long to get to it and hope you like it. I will leave this for comment for a little while before making edits on the wiki. After a suitable wait for more comment, we will send it on to Cyan Worlds. How long should we wait?

That said, here's my practical example of how I would incorporate my concerns into the existing document to be more effective in getting what we want:

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 and 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 needed 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, the community would enjoy an alternative solution that allows any specific goal 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 in a uniquely cooperative effort 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 ... _Proposals
Full discussion on the OpenUru.org forums: : viewtopic.php?f=91&t=635

[Deledrius]

That looks fine to me.

Given that it's almost entirely different from what we've been working on, I'm not exactly clear why you solicited the community's help when you appear to be more comfortable writing it yourself. Regardless, if you feel this is more likely to have a positive response, go ahead and submit it. I'm not really interested in how this gets done, just that it happens. I think we can all agree on that. We need these things to continue improving Uru. Whatever will convince Cyan of this is all that matters.