OpenUru.org

Deledrius wrote:

JWPlatt wrote:Wording for MORE was to limit content to Plasma, now CWE, and I don't think the intent has changed. "MOUL" might be a misnomer. Not to say derivative use of CWE imagery (e.g., web pages) is not negotiable.

Incidentals like that make sense to be negotiated/FCAL'd.

My concept of this is that if there were registration, it could be a non-discriminatory click acceptance of terms that also possibly include what is generally known as the FCAL within typical bounds of fan use such as derivative content images on websites. Except now it is open, not confidential, while simultaneously unburdening Cyan from such management and the community from having to wait months for approvals. I feel this is necessary to encourage content development. Have I explicitly requested this yet? No, not yet. But it is implied in the questions we are asking and the desire for simplicity as we build toward a solution.

I've split this because I think it needs it's own thread...

Deledrius wrote:

Mac_Fife wrote: Associated with the previous item, Cyan wishes to maintain a list/register of developers using the licensed Cyan assets. In effect, this seems to be a desire to assign usage rights to individual licensees rather than declaring an "open house". I don't think it's really an attempt to restrict who can use the assets so much as reinforcing the point that the assets are "licensed by Cyan". There is no information on the mechanics of this yet.

Personally I think this is a very bad idea and as I've stated elsewhere illustrates a fundamental misunderstanding of the process on their side. Their attempts to restrict things only serve to strangle legitimate contributions while doing nothing to stem the people who have no interest in moral or legal obligations. As branan pointed out before, we will want to, by necessity, keep track of who is working on what simply for logistical reasons. This would be a transient registry, simply for the purpose of asset locking since there are few better merge strategies if I understand that thread properly, and not something Cyan would need to concern themselves with directly.

If their concern is to retain their license and copyright, the law already does that sufficiently, provided they select an effective license. Anything more elaborate than that will hinder what few contributors remain, and would serve no real purpose but to add a very inappropriate business-like bureaucratic process onto something which will not likely thrive in such an environment without the attending processes and other such aspect that no one has the money or interest to provide.

They're certainly within their rights to require it, but I'd strongly question them to find a good reason to justify it. As it is, it seems more like a knee-jerk sort of "must have a process" sort of thinking, before they've identified the problem it's trying to solve. If we knew the underlying concerns, it may be easier to either accept this solution, or suggest more effective ones.

I'm reading between the lines here, so this is somewhat speculative:

I don't think this has anything to do with knowing who's working on what or about asserting copyright. I do think it is about license control and the sense of "ownership". As I commented in the Non-commercial use thread, I think that Cyan is working to try to give content access to the fans and not to other entities. Licenses like the Creative Commons ones do not really limit who can use the licensed material - I'd term those "open licenses" due that lack of restriction. Because of that, I think Cyan is maybe more comfortable with a "closed license" where the licensees are named/listed. The barrier for gaining a license would need to be very low for that (maybe even a self-service sign-up), but just enough for Cyan to be able to say "No, you're not part of the target demographic" if such a need for rejection should ever arise.

I'm not arguing for or against: I'm just giving my view on what I feel the underlying thinking is here.

Since I'm trying my best to get more involved with OS I'll throw my two cents in here.

I have a decent amount of knowledge regarding CC licenses. (Half a year of unspoken opinions coming right up! Please bear with me... ) In the main thread some of the issues regarding them were mentioned back in September 2011:

Mac_fife wrote:I think another thing to keep in mind about the differences between CC (and I'd agree that CC-By-SA, or possibly CC-By-NC-SA, would seem to be the most likely license from the CC stable) and GPL is that CC does not have the "viral" element that GPL has: It is permissable to create "collections" that include licenses other than CC (provided that the other licenses are not directly incomptible, e.g. containing a viral clause that overrides the CC license).

In the case of the GPL being more "viral " than CC licenses, I believe this is an incorrect statement (At least as far as America is concerned.). Creative Commons has a VERY viral effect on free media today, and with it, creates it's own issues. For instance, media released under the CC-BY license can be altered, changed, even sold, as long as the author is credited. Cyan certainly doesn't want to go down this route, as it's not restrictive enough for their medium.

I could go on and on, but it appears that you all have already settled on proposing either the CC BY-SA or CC BY-NC-SA if Cyan chooses a CC license. These hold less of the issues as other CC licenses, but could possibly raise big red flags if Cyan intendeds to also license the SFX and music assets (Which I personally hope they do to an extent, as it could benefit everybody, including themselves. More on this will be provided if I'm asked. ).

Branan wrote:...and the CC FAQ is rather vague (and also unfortunately focused on audio and text, rather than digital art).

This is mostly by design, as it is VERY popular among audio communities. Artists like Kevin MacLeod, and even our very own Turjan Aylahn use them for their work. However, some music artists, like Tony Diana (A less outspoken community member), choose to not use them for their free work because they are less restrictive. That's not to say it's not a good license for art though; many images on DeviantArt are licensed under CC licenses, as are many images on Wikipedia and Wikimedia Commons. However, if Cyan prefers having more control (meaning, under a CC license, no one would have to ask them (Cyan) if they could modify something; likewise, if Cyan disapproved of any altered assets, they could not ask it to be removed or altered by the artist and stay inside their own license terms. Also, it is not possible to revoke a CC license, putting Cyan in a sticky situation should something like this actually arise. ) then they should pursue another license type. Creative Commons licenses greatly favor the end user, which is good in many cases; but like I said, Cyan likes to have a greater say in how folks use their creations, which I have come to respect some aspects of.

So, all that said, what are my personal suggestions on this? Well first of all I'd avoid a GPL license like the plague (Ok, maybe not like the plague, but, from what I know about it, I'd advise against it.). They're far less rounded than other licenses and could cause issues down the road, since all derivatives would also be under a GPL license (Which is not a very fair thing to ask artists and age creators if you ask me.). I don't see how this could be very attractive to Cyan either.

So with GPL and CC gone, what does that leave? I'd suggest that, since this is mostly an isolated case of protected sourcing, Cyan draft their own license; or, likewise, we could draft one and present it to them for further modifications or changes. It wouldn't even have to be more than a couple pages (More like a EULA of sorts, but quite a bit more restrictive.), and, if they wanted, they could model it after an applicable CC license. (To my knowledge there is no legal issue with this. CC licenses are consensual by their very nature, and creating one modeled after one, with it's own derivative text, shouldn't be against Creative Commons' (The foundation) terms.)

Now, back to the topic at hand, I do not believe people need to register with Cyan in order to alter or modify their assets under a public license. What's the purpose of the license in this case if Papa Cyan's gonna be looking over your shoulder the entire time? If they were doing that, this matter could have been settled months ago with a EULA between Cyan and the individual(s) making the changes (Similar in design to Cyan's FCA license agreement.). So I don't believe this sort of licensing is fair in terms of furthering OS development, as it creates an unnecessary barrier of bureaucracy between us and Cyan. Cyan doesn't have the time or resources to keep up with such a system either, and it would get confusing at that. Now, if an OpenUru repository was created that kept track of those who have downloaded or forked the assets is put in place, where the person acquiring the assets needs to leave a reason why they're using them (Similar to wiki edit notes) then I think that would work. Otherwise, you're looking at an overcomplicated mess.

Mac_fife wrote:The barrier for gaining a license would need to be very low for that (maybe even a self-service sign-up), but just enough for Cyan to be able to say "No, you're not part of the target demographic" if such a need for rejection should ever arise.

That isn't fair. Even if a person wanted to utilize the assets for, what I will call, "inappropriate designs," it should not be in the power of Cyan to make such restrictions. However, if they wanted to prevent such a thing and be fair about it, there could always be a clause in the license agreement that puts the person in violation of Cyan's copyright if they make such modifications. (Such "innapropriate designs" could be restricted to language, nudity, and vulgarity for instance, and could be broadened depending on Cyan's legal preferences.)

Also, if they license it at all it needs to be available to everyone on the planet, not just fans. A non-commercial clause in the license should fix anybody trying to make money off of their work.

JWPlatt wrote:My concept of this is that if there were registration, it could be a non-discriminatory click acceptance of terms that also possibly include what is generally known as the FCAL within typical bounds of fan use such as derivative content images on websites. Except now it is open, not confidential, while simultaneously unburdening Cyan from such management and the community from having to wait months for approvals. I feel this is necessary to encourage content development. Have I explicitly requested this yet? No, not yet. But it is implied in the questions we are asking and the desire for simplicity as we build toward a solution.

I would not request it yet; wait until further discussion can be had. I'm still personally against anything like this, but maybe, with further discussion, we'll all figure out a place where we can meet in the middle.

Additional links of interest:

• Kevin MacLeod explains how copyright applies to his works. He knows CC licenses forward and back, down and up, and every which way in between. This is definitely worth reading if you want to understand the CC licenses a little better. (Just a quick note about how Kevin's stuff has been used in the past, a piece of his was used in 2011's Hugo without his permission or consent. While he did not receive any royalties from this, he is properly credited in the film's credits. Unlike Kevin, Cyan obviously won't want anything like this happen with their assets.)
• http://wiki.creativecommons.org/Before_Licensing

Trekluver wrote:In the case of the GPL being more "viral " than CC licenses, I believe this is an incorrect statement (At least as far as America is concerned.). Creative Commons has a VERY viral effect on free media today, and with it, creates it's own issues. For instance, media released under the CC-BY license can be altered, changed, even sold, as long as the author is credited. Cyan certainly doesn't want to go down this route, as it's not restrictive enough for their medium.

Hmm, you seem to be saying one thing but giving an explanation that argues the opposite way? Maybe I'm misunderstanding you.
GPL licenses are "viral" in that they requires that all derivative works are licensed under terms that are compatible with GPL. Most of the CC licenses don't actually do that: If you license something under CC-BY you could license a derivative work under almost any other license (e.g. a more restrictive one) that still provides the appropriate accreditation of the originator. Under CC only the inclusion of the SA (Share Alike) clause makes the license viral, since that means that all derivatives must use the same license as the original.

Trekluver wrote:I could go on and on, but it appears that you all have already settled on proposing either the CC BY-SA or CC BY-NC-SA if Cyan chooses a CC license. These hold less of the issues as other CC licenses, but could possibly raise big red flags if Cyan intendeds to also license the SFX and music assets (Which I personally hope they do to an extent, as it could benefit everybody, including themselves. More on this will be provided if I'm asked. ).

Sound effects are one thing, but music may be another. Sound effects are probably Cyan's to do with as they please. Some music items will be too I expect, but others will not: The example that most immediately springs to mind is "Burn you up, Burn you down" (Zandi's favourite track) - I believe that this is licensed to Cyan by Real World/Geffen/EMI Records and I don't expect that Cyan have a right to re-assign.

Trekluver wrote:Well first of all I'd avoid a GPL license like the plague (Ok, maybe not like the plague, but, from what I know about it, I'd advise against it.).

I think we can forget GPL. The GPL creators will be the first people to tell you that it's simply not appropriate for something that isn't "software" and suggest you go look somewhere else.

Trekluver wrote:So with GPL and CC gone, what does that leave? I'd suggest that, since this is mostly an isolated case of protected sourcing, Cyan draft their own license; or, likewise, we could draft one and present it to them for further modifications or changes. It wouldn't even have to be more than a couple pages (More like a EULA of sorts, but quite a bit more restrictive.), and, if they wanted, they could model it after an applicable CC license. (To my knowledge there is no legal issue with this. CC licenses are consensual by their very nature, and creating one modeled after one, with it's own derivative text, shouldn't be against Creative Commons' (The foundation) terms.)

Personally, modelling a license after a CC one is the way I'd be thinking on this. More on this below.

Trekluver wrote:Now, back to the topic at hand, I do not believe people need to register with Cyan in order to alter or modify their assets under a public license. What's the purpose of the license in this case if Papa Cyan's gonna be looking over your shoulder the entire time? If they were doing that, this matter could have been settled months ago with a EULA between Cyan and the individual(s) making the changes (Similar in design to Cyan's FCA license agreement.). So I don't believe this sort of licensing is fair in terms of furthering OS development, as it creates an unnecessary barrier of bureaucracy between us and Cyan. Cyan doesn't have the time or resources to keep up with such a system either, and it would get confusing at that. Now, if an OpenUru repository was created that kept track of those who have downloaded or forked the assets is put in place, where the person acquiring the assets needs to leave a reason why they're using them (Similar to wiki edit notes) then I think that would work. Otherwise, you're looking at an overcomplicated mess.

I agree that having regisetered licensees makes it all seem very like the FCALs (and I think I said that somewhere). Maybe that's something that makes Cyan feel comfortable about the whole thing. I don't see what's "unfair" about it, unless you're thinking purely in terms of conventional Open Source licenses, and I think we're getting to the point of picking at the nuances of words here. Cyan haven't actually said that they want to "Open Source" the content, they've simply said they're prepared to "license" certain assets and what they've described so far sounds to me to be a more "closed" license. We can argue and propose and suggest whatever we think is ideal, but ultimately these are Cyan's assets, a product of their business, and we'll have to work within whatever rules they want to set if they feel they are in the best interests of Cyan as a business. Having said that, I don't expect their ears will be closed should a good case be presented on how to satisfy their needs without some of things that we might see as unnecessary obstructions.
Any registration scheme would really rule out any of the vanilla CC licenses (indeed most common open source/creative licenses) since none of those would carry terms that require downstream users to register at the point of origin. So if you assume that the register is a requirement, then you may be able to use a license derived from CC but probably not one of the CC licenses as they stand.
I don't share your concerns about the overheads in "admistering" a register, because I don't actually believe there's a whole lot of intent to do much "administration" - the register could as basic as adding your name to a forum thread. But that's me "reading between the lines" again. The idea of tracking users of a repository was also a thought but again it only has any effect on people who pull the first generation as it were, so I don't think that helps.

Trekluver wrote:Even if a person wanted to utilize the assets for, what I will call, "inappropriate designs," it should not be in the power of Cyan to make such restrictions. However, if they wanted to prevent such a thing and be fair about it, there could always be a clause in the license agreement that puts the person in violation of Cyan's copyright if they make such modifications. (Such "innapropriate designs" could be restricted to language, nudity, and vulgarity for instance, and could be broadened depending on Cyan's legal preferences.)

It is entirely within Cyan's power to make such restrictions, should they wish. But I think what you're really saying here is that if Cyan do wish to limit the scope of use of the assets that it should be set out in the terms of the license? I'd agree on that and didn't mean to suggest an arbitrary, after-the-fact decision that something was an unintended or inappropriate use. I also agree with the point Deledrius made earlier that even defining what is acceptable may be unduly difficult.

Mac_Fife wrote:I think we can forget GPL. The GPL creators will be the first people to tell you that it's simply not appropriate for something that isn't "software" and suggest you go look somewhere else.

This. A thousand times this.

Mac_fife wrote:GPL licenses are "viral" in that they requires that all derivative works are licensed under terms that are compatible with GPL. Most of the CC licenses don't actually do that: If you license something under CC-BY you could license a derivative work under almost any other license (e.g. a more restrictive one) that still provides the appropriate accreditation of the originator. Under CC only the inclusion of the SA (Share Alike) clause makes the license viral, since that means that all derivatives must use the same license as the original.

I was referring to their virality as a whole; they seem to be spreading like wildfire these days, and at the same time being used for stuff they are totally inappropriate for (For instance, many SFX libraries use them almost exclusively, which is a real pain when trying to properly credit the creators.).

However, if you're referring to them being viral in that manner then I'd say you are correct.

Mac_fife wrote:Sound effects are one thing, but music may be another. Sound effects are probably Cyan's to do with as they please. Some music items will be too I expect, but others will not: The example that most immediately springs to mind is "Burn you up, Burn you down" (Zandi's favourite track) - I believe that this is licensed to Cyan by Real World/Geffen/EMI Records and I don't expect that Cyan have a right to re-assign.

That would be correct.

Mac_fife wrote:I agree that having regisetered licensees makes it all seem very like the FCALs (and I think I said that somewhere). Maybe that's something that makes Cyan feel comfortable about the whole thing. I don't see what's "unfair" about it, unless you're thinking purely in terms of conventional Open Source licenses, and I think we're getting to the point of picking at the nuances of words here. Cyan haven't actually said that they want to "Open Source" the content, they've simply said they're prepared to "license" certain assets and what they've described so far sounds to me to be a more "closed" license. We can argue and propose and suggest whatever we think is ideal, but ultimately these are Cyan's assets, a product of their business, and we'll have to work within whatever rules they want to set if they feel they are in the best interests of Cyan as a business. Having said that, I don't expect their ears will be closed should a good case be presented on how to satisfy their needs without some of things that we might see as unnecessary obstructions.
Any registration scheme would really rule out any of the vanilla CC licenses (indeed most common open source/creative licenses) since none of those would carry terms that require downstream users to register at the point of origin. So if you assume that the register is a requirement, then you may be able to use a license derived from CC but probably not one of the CC licenses as they stand.
I don't share your concerns about the overheads in "admistering" a register, because I don't actually believe there's a whole lot of intent to do much "administration" - the register could as basic as adding your name to a forum thread. But that's me "reading between the lines" again. The idea of tracking users of a repository was also a thought but again it only has any effect on people who pull the first generation as it were, so I don't think that helps.

Eh, I think adding your name to a forum thread adds nothing more than unnecessary red tape to the process. Any license at it's core should be simple to acquire and be available to anyone, and should only be able to be revoked if a person violates the terms in the agreement. If they want to keep people's names (Just in case someone tried to sell Cyan's assets and they needed to sue them.) handy that's one thing, but having to register just for the sake of registering is quite silly. What you said about using a CC license would not work, because, as I said before, they are non-revokable; if Cyan chose a CC license, creating a register would be redundant and, coupled with a CC license, would limit their rights in unnecessary ways.

I do not believe the content should be completely open sourced. That said, whatever is proposed will need to be some hybrid of a closed and open source license. They can't simply leave it closed, as the files need to be modified (hence the purpose of the license in the first place). Likewise, they cannot make it entirely open source, as it would be open to modification by anyone and everyone. The issues in this case are slightly different, simply because it isn't a program we want licensed, but rather it's assets. (Which is another reason something similar to, or a derivative of a CC license, is very attractive.) Wherever this ends up, it will be quite interesting

Mac_fife wrote:It is entirely within Cyan's power to make such restrictions, should they wish. But I think what you're really saying here is that if Cyan do wish to limit the scope of use of the assets that it should be set out in the terms of the license? I'd agree on that and didn't mean to suggest an arbitrary, after-the-fact decision that something was an unintended or inappropriate use. I also agree with the point Deledrius made earlier that even defining what is acceptable may be unduly difficult.

Correct. It is not within their power to limit someone from using it if they chose an open license agreement (Not open source, just publicly open for anyone to acquire.). However, if they create their own license, they can restrict such behavior in a way that suits their fancy while not restricting everyone else in the process.

Something I thought of earlier today is that any license they create needs to have a specific provision limiting the content's use in other online games. Specifically, there needs to be a clause mentioning that if the content is used in OpenSim of Second Life, the license will be revoked (Specific, meaning they need to be individually named so folks don't try and worm around it. ).

So from here, where should further discussion go? Right now we're just talking about a problem rather than trying to correct it (Which is basically what's been going on for months now.). I say we begin drafting a test license and see where that leads us. There's no reason not to give it a try; the worse thing that could come from it is it being scrapped altogether.

Trekluver wrote:So from here, where should further discussion go? Right now we're just talking about a problem rather than trying to correct it (Which is basically what's been going on for months now.). I say we begin drafting a test license and see where that leads us. There's no reason not to give it a try; the worse thing that could come from it is it being scrapped altogether.

I've finally got a few moments to respond (hopefully I can get to all the stuff piled up this week soon), so...

Before we draft up a license, we need to define the problem. This is what I mentioned in the original thread, and I planned to do last weekend before things got crazy for me, and these other threads all popped up before I could do it.

What are the forseeable content we need access to, for what uses?

We definitely need to be able to redistribute the final/compiled resources (PRPs, LOCs, P2Fs). A license to modify the localization files would not be bad either, given that GULP has a good many decent translations. Those are just things that we have that we need a license from Cyan for... I'm not really sure where to begin WRT assets only Cyan has. Given my recent plugin work, the Guild of Writers leader inside me says that the source cavern textures would not be bad though . I'm sure there are other (more pressing) items though, such as GUI max files.

These are all things in the Community Request and, as such, already strongly represented to Cyan.

If you (plural) would like to work up some legal text which would extend an existing, stock license (such as CC) - which has that extensibilty built into it - to put forth, I recommend it. Use the Community Request as a guide for your terms. Writing a new license from scratch would add significant time, effort, analysis and cost (to Cyan) by corporate lawyers, making its completion and approval unlikely in our lifetime. A proven, well-known license with a few extensions to address community concerns and the Cyan concerns which Mac previously outlined will get much faster results. I also recommend that one person coordinate the effort and be responsible for it. Make a reach for what you want, but be realistic so that we do not waste time.

I will be away for one week and offline, so this is my last post for a while. Yippee.

(By the way, this thread has evolved back to the core topic )

Deledrius wrote:Before we draft up a license, we need to define the problem.

I guess that's true, although most of it has already been defined in some manner or another.

I have, for reference, created a wiki page containing a copy of the CC BY-NC-SA 3.0 license (I double checked it, the code itself is licensed under the CC BY-SA 3.0 so we're good on the editing/copying front.). For now it will be a good reference tool; at what time OpenUru is ready though, edits and rewrites can be made to change it into something fit for Cyan's purposes. At what time we do get to this stage, calling it something along the lines of the Cyan Worlds Art and Media Assets Content License Agreement might not be a bad idea.

Hoikas wrote:We definitely need to be able to redistribute the final/compiled resources (PRPs, LOCs, P2Fs). A license to modify the localization files would not be bad either, given that GULP has a good many decent translations. Those are just things that we have that we need a license from Cyan for... I'm not really sure where to begin WRT assets only Cyan has. Given my recent plugin work, the Guild of Writers leader inside me says that the source cavern textures would not be bad though . I'm sure there are other (more pressing) items though, such as GUI max files.

Interesting. Ok then, so here's a list including what you said, as well as what I'm thinking:

• 1. PRP's - Need to be licensed under a standard content license.
• 2. LOC files - Same as above.
• 3. P2F files - Same as above.
• 4. Cyan's raw file assets - I'm thinking these will require a separate, yet similar license to the above listed. Since we are moving entirely away from GPL and, for the most part, the standard CC licenses, the sign-up repo/log/forum thread-thing might not be a bad idea for these to be licensed out. It would need to be far more restrictive than the other agreement (Possibly even having a criminal prosecution clause (If used outside of Uru Open Source) tucked in there), but also allow redistribution on, or for, Open Source shards.
• 5. Texture files - We could probably get away proposing this to Cyan under a standard content license, provided that license does have clauses preventing non-commercial use.
• 6. Music files - This one I actually need to email Tor'i about. If I understood her correctly in the past, Cyan already offers a license to people wanting to use these. I'm not sure how it works though, and if this is indeed the case, Cyan may not want to license these in any other fashion. If they do though, I'd propose a CC BY-NC-SA 3.0 license or a derivative thereof.
• 7. SFX files - While a CC BY-NC-SA 3.0 or CC BY-NC 3.0 license could be good for these, I really think the standard content license would work best for this.

Ok, so going by this, we could do a dual content license deal: one for raw assets, and one for previously compiled assets. What do you all think? And what else, if anything, belongs in this list?