Open RPG Creative (ORC) License Draft Published

​

Paizo Publishing and Azora Law have published the initial draft of the Open RPG Creative license (ORC) for public feedback. This license was concieved of during January's Open Gaming License (OGL) controversy and was designed as an independent, irrevocable replacement for that license. Also available is an FAQ, or the 'Answers & Explanations" (AxE) which explains the structure.

Commentary can be left until April 21st, and the intention is to finish the license by the end of April.

So what is ORC? It's an open license which can be used by any creator to 'open' their game up so that other creators can use it. It is independent and irrevocable, and cannot be updated or revised.

paizo.com - Community / Paizo Blog

 

[Bawylie]

Can anyone explain it for the dummies (me)?

 

[Xohar17]

"Interesting to see they ended up registering the license at the Library of the Congress instead of leaving the license's control to a neutral organisation. The license doesn't seem that different from what the OGL 1.0 set out to do, let's see if the large number of adopters makes a difference!"

What does neutral mean in this case?

 

[Morrus]

Interesting to see they ended up registering the license at the Library of the Congress instead of leaving the license's control to a neutral organisation.

That doesn't mean the library controls the license. It just means that there's a permanent record of the license in a safe place. If anybody disputes what the license says, the original text is right there. It's basically like putting the original in a vault to protect it from being altered.

(admittedly in this day and age, it's pretty easy to prove what the original says, as there will be a thousand copies online, so it's just an abundance of caution)

 

[Morrus]

So looking through it... very basic simple overview (I am not a lawyer, I am defintely not your lawyer, and this is not legal advice!)

• SI defines Product Identity (the stuff you want to keep), ORC Content (the stuff you want to share), and a few other terms. Obviously you can't make somebody's PI into ORC Content, and you can't make somebody's ORC Content into PI.
• SII grants you the right to use other creators' ORC Content. It's worldwide, royalty free, irrevocable. It also grants everybody else the right to use your ORC Content. You can't limit usage, charge for it, or impose any conditions.
• SIII tells you how to put the ORC notice in your product. Doing that is required to use the license. You include attribution of the creator or Orc Content you are using, info on how you should be credited for your ORC Content, and identification of what you want to designate as Product Identity.
• SIV is legal stuff which stops people suing you if you use the license wrong and somebody downstream from you unwittingly uses content they shouldn't because of your mistake. Basically, it's up to each user to double check, not to rely on the previous user to have done it right.
• SV is how the license terminates if you breach it. You get 60 days to fix the breach, and if your license terminated, those downstream from you are still OK. It also explains how the license can't be amended, revoked, etc.

It's a bit more nuanced than that, but them's the basics. It is very similar to the OGL in concept, just with more solid protection (which is what most of the extra words are about).

 

[Morrus]

Let's look at Product Identity and ORC Content. These are analogous to the Product Identity and OGC in the OGL. (Note, common point of confusion I see, Product Identity -- PI -- is not the same term as Intellectual Property -- IP).

You have to make a "reasonable, good-faith effort" to idenfity your PI and ORC Content (that needs an abbreviation: I'll go with OC for now) to the next user. That's kinda vague, of course, and subject to interpretation, and I'm sure some people will obfuscate it while claiming to have met that requirement as they did with the OGL.

Product Identity
Much like the OGL, this is the content you want to keep to yourself. Names, art, etc. are common (eg WotC in the OGL keeps back stuff like 'Dungeons & Dragons' and 'Forgotten Realms'. Those are the bits other people cannot use. You need to list them all. It also includes stuff like trade dress (the reason why you shouldn't make your OGL product look like an official D&D book in layout!)

Note you cannot include anything previously designated as OC, or which belong to somebody else, or which are public domain. Your stuff only.

ORC Content
There's two types - the stuff you declare is OC, and the stuff you are using from somebody else's OC (which the license calls Adapted ORC Content, so I'll go with AOC).

OC is specifically declared by you. You need to make that "reasonable, good-faith effort" to identify it to the reader.

Additionally, game rules are automatically OC. It has a complicated definition in the license, but basically mechanics are OC.

AOC is stuff that you've taken from other OC sources and adapted or used.

Rights
Anybody can use OC (or AOC, which is OC). You cannot stop them, limit their use, impose conditions, charge them, or ask for royalties. All they have to do is use the ORC. These rights apply to all media and formats, even those which haven't been invented yet.

Again, very basic overview. There is more detail and nuance. But that's the gist of it.

 

[kenada]

Well, I mean, people will probably still use it that way if they can: that's just market forces at work.

They can try, but the ORC License seems to account for that. If something is definitionally ORC Content, and they declare it Product Identity anyway, the license says (in section III.c.) the definition shall control. That seems like it would provide for a much stronger defense if one used the mechanics anyway, and the publisher tried to sue.

 

[Morrus]

Using the Required Notice

To use ORC you need to put the Required Notice stuff in your product. This is like a legal block of info--they provide an example, but you don't have to format it like that. Basically you must include:

ORC Notice. A couple of sentences of legal text you can copy and paste.

Attribution Notice: You have to attribute all upstream creators of OC you use in the way they requested. This is like the OGL, and is 'viral' in nature, so you might have a big long list of upstream creators you need to credit, which you inherit from the creator you're borrowing from. You can probably copy and paste this from the product(s) you're using, and then add the requested attribution from that product.

Product Identity Notice: List the stuff you're designating as PI (as in my previous post). A "reasonable, good-faith effort".

ORC Content Notice: Identify the stuff you're desgnating as OC. A "reasonable, good-faith effort". Note of course, as mentioned before, game rules and OC which you have borrowed are automatically OC, whether you declare it or not. That doesn't mean you don't have to declare it though, you still have to make that "reasonable, good-faith effort", but it does cover things you might miss.

 

[Cadence]

I love the forced sharing of rules in ORC and OGL... but the having to go through and parse product identity vs. OC and AOC and exactly how much wording you can just reuse for it and...

It makes me really like the idea of a CC-BY repository of individual product SRD files where if you want to know what you can copy you just go there. (I can picture a badge for products that indicates that all the game rules are in the repository for example, so that folks new if what they were buying was in to sharing).

 

[Dragonblade]

Perfect. Well done Paizo and Azora. This is exactly the type of license I was hoping to see. This looks great as is. Hope to see it released soon.

 

[kenada]

It makes me really like the idea of a CC-BY repository of individual product SRD files where if you want to know what you can copy you just go there. (I can picture a badge for products that indicates that all the game rules are in the repository for example, so that folks new if what they were buying was in to sharing).

One thing I don’t like about the CC-BY/SRD approach is it puts the burden on the publisher to produce the SRD instead of on the user to comply with the license (not using Product Identity, using correct attribution, etc). It also seems like we get SRDs for core systems but rarely for supplements and 3PP material, which limits what can be used (without additional effort to clone the non-SRD content).