Agreed. I think this is moving toward more helpful and more correct.
Some proposed changes:
"I'm a commercial (closed-source) game developer. Can I use this art?'
This depends on the license under which it is submitted..."
Does it, though? How they use, credit, or share the art depends on the license, but whether or not it can be used in a commercial project doesn't depend on the license, does it? As a new visitor to OGA seeing this, my next question would be "ok, then which licenses don't allow commercial use?" but all of them say "commercial use is ok".
It is true that making a derivative out of two assets- one of which is not a compatible license with the other- is a problem, but it doesn't make the derivative Non-Commercial; it makes it Non-Usable, commercial or not.
Next proposed change: CC-BY-SA section.
If you are using art, that means commercial use is ok, so long as you provide appropriate credit, don't distribute the work in a way that includes DRM, and are prepared (and able) to release your project or parts of it as CC-SA-BY should they be deemed to constitute a derivative of the original work. Those working on projects for which this might be an issue (eg. closed source, commercial or non-CC-BY-SA open source development) are advised to seek qualified legal counsel before using CC-BY-SA 3.0 or CC-BY-SA 4.0 works in their project.
(ephasis mine) Perhaps I'm picking nits here. I feel like we should change "don't distribute the work in a way that includes DRM" to something like "distribute the work in a way that does not impose DRM". The difference being the former looks like it is recommending not distributing the derivative as an option for being compliant with the license.
Next: "closed source, commercial" - The conflicts that come up with using CC-BY-SA in some projects is not because they are commercial or closed source projects. It is because of the way the CC-BY-SA asstes may be combined with incompatibly-licensed assets in that project. An open source non-commercial project can still run afoul of derivative problems if the project derives CC-BY-SA assts with proprietary royalty-imposed assets.
It is possible I am missing a detail discovered in the talks with lawyers and FSF, so please let me know if I am wrong about this. I beleive closed/open source doesn't mean closed/open asset. An open source project can use non-libre assets and vice versa. The exceptions are when the assets are inseperable from the code, which is almost never: edge-cases only.
Next: CC-BY-SA and what constitutes a derivative:
"Generally speaking, an asset is considered a derivative if another asset was used in any way in the creation of the new asset. Generally speaking, simply displaying two game assets on the screen together does not constitute a derivative of the two. However, the definition of a derivative work is not black and white and there is some ambiguity about how the term applies to using art works in a video game or related project. For instance, one use case is clear and spelled out explicitly by the CC-SA-BY licenses: if you synchronize a moving image to a piece of music or sound effect licensed as CC-BY-SA, then you must distribute the resultant work* as CC-BY-SA also. Creative Commons has attempted to provide some guidance on the issue here."
I am still not super happy with this, but I feel like this gives more useful guidance on derivatives. There are a whole list of examples we can add to help outline what is- as is not- a derivative, but I'm not sure if we should list those on some other page (like a forum thread?) and just link to them from the FAQ, or if the examples should all be listed in the FAQ itself.
*Also, do we have a good handle on what "the resultant work" means in the sprite-synced-to-sound-effect example above? Can we tell people that syncing a sound effect to an animation makes the output the derivative, but not the inputs? Does the sound effect, and the animation spritesheet, need to be CC-BY-SA? or just the rendering of the two together? Is it only a derivative if someone saves that as a video? or is the thing that rendered them together (the game itself) the derivative? Even then, it would be the compiled game executable itself and not the source code that is the derivative, right? I'm not advocating one way or another, but the question of input vs output makes a huge difference here. We don't have to address these questions in the FAQ necessarily, but if we aren't able to address them at all, then we are adding more confusion by including that example. Not saying we just omit it, I'm saying we should know where we stand before we include it.
Are people still happy with the proposed changes above? Or does the response from CC and the attorney make it difficult to give an official firm answer?
After re-reading the full thread, I wonder if the language proposed for the CC-BY-SA section is really helpful to anyone. The goal is to provide guidance that is more clear than what we have now, but most of the blurb about what constitutes a derivative is just confirming that its very wishy-washy and ambiguous. However, that ambiguity seems to be mostly about edge-cases. I think we can provide a more summarized general guidance about what is and is not a derivative (covering 90% of circumstances), but also note that there are edge-cases and exceptions to be aware of.
There haven't been all that many offenders, really. I mean, more lately than ever, but that's mostly due to an uptick in site traffic, which is a good thing. Anyone with good art to share will stick around and they'll know better next time. :)
Not in the site's current form, no. However, any time someone submits about 5 or 6 submissions in a row, those submissions are removed from the front page for about 24 hours. Has that not been sufficient?
I think the underlying issue is that no one really reads the submission guidelines. This issue is only the flavor of the month. Next month it will be some other thing that is also already addressed in the guidelines. Unless the expectation is to eventually repost the entirety of the guidelines right below the upload-file box, the solution may be to make the guidelines more prominant.
I see. Well, just so you know, this post wouldn't help anyone resist a DMCA placed on your assets. This post doesn't counteract such a claim because it contains no provenance for any specific asset. However, simply having the assets on OGA does help people defend against incorrect DMCA's because the presence of your assets shows the open license and when they were available.
On the other hand, if you're planning on registering your assets with automated intellectual propery claiming services, such as YouTube's ContentID, then you need to make sure you do not register anything that is remarkably similar to the content you're sharing here on OGA. The automated systems can't tell the difference and don't care if the DMCA claim is false or not. In order to avoid getting user's falsly copyright-striken, and until such automated systems stop being pure trash, we do not allow content here on OGA that has been registered with such services.
I wasn't saying MIT is revokable. I was saying all the licenses you had already listed your assets under are irrevokable, so there is no need to create a 'proof of permission' post like this.
Agreed. I think this is moving toward more helpful and more correct.
Some proposed changes:
Does it, though? How they use, credit, or share the art depends on the license, but whether or not it can be used in a commercial project doesn't depend on the license, does it? As a new visitor to OGA seeing this, my next question would be "ok, then which licenses don't allow commercial use?" but all of them say "commercial use is ok".
It is true that making a derivative out of two assets- one of which is not a compatible license with the other- is a problem, but it doesn't make the derivative Non-Commercial; it makes it Non-Usable, commercial or not.
Next proposed change: CC-BY-SA section.
(ephasis mine) Perhaps I'm picking nits here. I feel like we should change "don't distribute the work in a way that includes DRM" to something like "distribute the work in a way that does not impose DRM". The difference being the former looks like it is recommending not distributing the derivative as an option for being compliant with the license.
Next: "closed source, commercial" - The conflicts that come up with using CC-BY-SA in some projects is not because they are commercial or closed source projects. It is because of the way the CC-BY-SA asstes may be combined with incompatibly-licensed assets in that project. An open source non-commercial project can still run afoul of derivative problems if the project derives CC-BY-SA assts with proprietary royalty-imposed assets.
It is possible I am missing a detail discovered in the talks with lawyers and FSF, so please let me know if I am wrong about this. I beleive closed/open source doesn't mean closed/open asset. An open source project can use non-libre assets and vice versa. The exceptions are when the assets are inseperable from the code, which is almost never: edge-cases only.
Next: CC-BY-SA and what constitutes a derivative:
I am still not super happy with this, but I feel like this gives more useful guidance on derivatives. There are a whole list of examples we can add to help outline what is- as is not- a derivative, but I'm not sure if we should list those on some other page (like a forum thread?) and just link to them from the FAQ, or if the examples should all be listed in the FAQ itself.
*Also, do we have a good handle on what "the resultant work" means in the sprite-synced-to-sound-effect example above? Can we tell people that syncing a sound effect to an animation makes the output the derivative, but not the inputs? Does the sound effect, and the animation spritesheet, need to be CC-BY-SA? or just the rendering of the two together? Is it only a derivative if someone saves that as a video? or is the thing that rendered them together (the game itself) the derivative? Even then, it would be the compiled game executable itself and not the source code that is the derivative, right? I'm not advocating one way or another, but the question of input vs output makes a huge difference here. We don't have to address these questions in the FAQ necessarily, but if we aren't able to address them at all, then we are adding more confusion by including that example. Not saying we just omit it, I'm saying we should know where we stand before we include it.
Are people still happy with the proposed changes above? Or does the response from CC and the attorney make it difficult to give an official firm answer?
After re-reading the full thread, I wonder if the language proposed for the CC-BY-SA section is really helpful to anyone. The goal is to provide guidance that is more clear than what we have now, but most of the blurb about what constitutes a derivative is just confirming that its very wishy-washy and ambiguous. However, that ambiguity seems to be mostly about edge-cases. I think we can provide a more summarized general guidance about what is and is not a derivative (covering 90% of circumstances), but also note that there are edge-cases and exceptions to be aware of.
That is quite a fun puzzle game. Thanks for sharing it.
There haven't been all that many offenders, really. I mean, more lately than ever, but that's mostly due to an uptick in site traffic, which is a good thing. Anyone with good art to share will stick around and they'll know better next time. :)
Not in the site's current form, no. However, any time someone submits about 5 or 6 submissions in a row, those submissions are removed from the front page for about 24 hours. Has that not been sufficient?
I think the underlying issue is that no one really reads the submission guidelines. This issue is only the flavor of the month. Next month it will be some other thing that is also already addressed in the guidelines. Unless the expectation is to eventually repost the entirety of the guidelines right below the upload-file box, the solution may be to make the guidelines more prominant.
Fixed.
I see. Well, just so you know, this post wouldn't help anyone resist a DMCA placed on your assets. This post doesn't counteract such a claim because it contains no provenance for any specific asset. However, simply having the assets on OGA does help people defend against incorrect DMCA's because the presence of your assets shows the open license and when they were available.
On the other hand, if you're planning on registering your assets with automated intellectual propery claiming services, such as YouTube's ContentID, then you need to make sure you do not register anything that is remarkably similar to the content you're sharing here on OGA. The automated systems can't tell the difference and don't care if the DMCA claim is false or not. In order to avoid getting user's falsly copyright-striken, and until such automated systems stop being pure trash, we do not allow content here on OGA that has been registered with such services.
Let's start with an alteration to the submission guidelines. What would you propose?
I wasn't saying MIT is revokable. I was saying all the licenses you had already listed your assets under are irrevokable, so there is no need to create a 'proof of permission' post like this.
Still not sure what the purpose of this post is.
Pages