Other Licenses
Hello, this is my first post in the forums. I did a quick search for this subject but did not find any information neither here in the forum nor in the FAQs. I apologize if this issue has already been discussed.
Are there plans to add more licensing options? Such as BSD, MIT, and zlib licenses. Or are they not compatible with the philosophy of OpenGameArt?
I think the idea is to minimize license proliferation and so maximise license compatibility between submissions.
If you hold the copyright over something you wish to submit you can always pick whatever OGA license option(s) best fits and add any extra licensing permissions you may wish to grant in the description.
If you don't hold the copyright over something you wish to submit then you could always ask the copyright holder the allow relicensing under an OGA license option, but otherwise I guess you're out of luck.
Red warrior needs caffeine badly.
The issues with most open source liscenese is that they dont make much sence when applied to art, that being said if there is a liscense you think really should be here we can look into adding it.
=======
Full Steam Ahead! o/ <-- little ascii fist in the air holding a debugging hammer.
BSD license talks 50% about a certain university, then the most part about compiled software and does not allow re-licensing - it's a dead end licensewise.
MIT could possibly make sense in that it allows relicensing - like CC-BY already does. So CC-BY allows an "art-consuming-project" to "relicense" the art for inclusion thus making BSD and MIT unecessary for assets anyway.
That said, BSD and MIT licenses talk about "this software", I am certain even courts understand that static assets alone aren't software. Well, patent trolls may argue (irony on): "a bmp file is a program that tells an interpreter where to place values into video ram which is then converted through a DAC into analogue or digital video signals which are then through an external device converted into light with the according wavelength.", haha, good one. Here is another one: Try to sell a car using an appartment rent contract.
A thing to consider is that game assets have been licensed in the past with the same license as games because both came from the same project - with OGA assets come from a central source to many projects and can be licensed different - further the licensing should allow to go along with lot of projects and their licensing.
Therefore asset licenses should either play nice with other licenses or allow relicensing.
Anyway I'm not against granting *additional* software-licenses if at least an asset-license was selected - the art-submission form could look like this:
Choose at least one of these asset-licenses (required): CC0, CC-BY, ....
Choose additional code-re-licensing options (optional, but may be required for specific projects): GPL, ...
That the later licenses are basically void until the asset is included into an according project doesn't harm here - it would merely say that you may include the art into such licensed projects:
I allow the inclusion and licensing into such and such licensed software projects.
Asset-License = Licensing the asset.
Code-License = I allow these licenses when the art is used. This is not the same as licensing the art under these licenses which is invalid! It's actually wrapping the code-license into an custom-asset-license that unfolds the code-license. It's meta-licensing.
@bart: I kindly request the OGA submission form really should be that way with mandatory asset-license and optional non-exclusive code-licenses (here you could if you choose even add a free-text-field for the later).
Code-License = I allow these licenses when the art is used. This is not the same as licensing the art under these licenses which is invalid! It's actually wrapping the code-license into an custom-asset-license that unfolds the code-license. It's meta-licensing.
This may work its a bit more complex tho legally then it sounds ill have a chat with bart about it.
=======
Full Steam Ahead! o/ <-- little ascii fist in the air holding a debugging hammer.
You should consider this out of the view of someone searching for open source art and someone who does this wants it as simple as possible. I for example would search only for CC0 and CC-BY.
@Duion: It wouldn't influence searching or using art, just a change on the submission form and maybe a small annotation on the art site similar to he current info already there: "The authors of this content agree to license it under later versions of the licenses they selected above."
@Botanic: The wording on the submission page may be as simple as possible. My sentences are just to get the details out *why* this is necessary: Because you just can't license art as software and it isn't sensible nor necessary. You just need to grant the right to use in such projects where then the license applies: The right to relicense under such licenses.
Eg. Submission page:
"Additionally to these wonderful asset licences I allow inclusion and re-licensing into projects with the following code-licenses." ;)
Eg. Asset page:
"The artist allows you to use this asset in any project under these licenses or later versions"
Basically OGA needs to make it clear for itself that that it is the legal intention of the submitter. We all assume it is but legaly it isn't: "You should have read the contract"-moment-of-truth.
The benefits of this small change would be:
+ to force use of at least an accepted asset-license: "[..] minimize license proliferation and so maximise license compatibility between submissions" (surt) !
+ getting the message out that code-licenses-only for art and assets is bad practice on OGA
+ solving the same problem by explicitly allowing re-licensing for projects with code-licenses for art - thus making inclusion into these projects safe.
There were mit/bsd licensing options but they were not used.
Feel free to state such additional licensing inside of the description and pick licenses that are compatible.
I guess my big concern is that I am not all that familiar with art licensing and the CC licenses (other than CC0). And I've been told that some CC licenses are not compatible with the GPL. However this does not seem to be the case here on OGA. I have a love-hate relationship with the GPL :p.
Many define "compatibility" in different ways.
If you can describe specific situations, we can share our view on how the license(s) would apply.
A problem with the proposed code licence, saying some art can only be used in projects with some licences, is it's basically writing a new copyleft licence, which I think we want to avoid. Any new licences need lawyers to look over them, and I'm not sure it's good to add more licences, risking more incompatibility.
Also, since it isn't the same as putting the art under that licence, I don't see how it helps anyway?
Are there cases where art is licenced as bsd, or is this hypothetical?
I don't agree with the concept of having different licenses -- or even different license needs -- for code and for art. I don't even agree with any definition of either code or art which excludes the other. The reason being that simple mutations allow software (by which I mean any data in digital form, not just what somebody might call "programs") to change its type (or category or whatever you would call these artificial divisions).
I have produced CG visual art by writing a program whose only purpose is to produce a single PNG. The program source code, the compiled program, and the produced PNG essentially are different forms of the same work. I wouldn't feel comfortable with tagging this work as either program or image. Sure, there is a definite point in the build process where we can cut a line between the program and its output (the PNG), But still it is one work and should have one license.
You can rip some parts from the source code and use them to create another program (or maybe a library) which is not an image at all. Then you have a program which is a derivative work of a PNG.
In these cases it feels awkward to use a license which is written specifically for programs or specifically for art. And this was just what I could come up with without much imagination. I expect that with some creativity and several mutations (aka. software reuse / derivative works), even stanger cases could appear.