I'm not sure proprietary formats makes things fuzzy, the same could apply to any proprietary programming language. I'd say the preferred form is whatever the person used to edit, even if it's proprietary - this doesn't mean it has to be preferred by other people (someone might write in assembler and therefore release the assembly language code, the fact that I might prefer to work in something higher level doesn't change that).
It would be a shame to disallow existing gpl art out there even if we'd prefer a different licence to have been used.
The heroism/debian example shows that this can be a problem in practice, not merely in principle. Disallowing gpl altogether would have meant that music never got uploaded at all - which would have saved at least one developer time, but might have been a shame. Does the egoboo game contain the source? I see that egoboo is available on Debian repositories, so why don't Debian have a problem with that?
Whilst the GPL isn't as clear as CC0, the same is true of any licence out there, free or proprietary. People have their reasons for not releasing everything they do as public domain, and we have to work with that.
"Just assume when I say 'the license compels you to distribute as CC-BY-SA' I mean 'IF you chose to distribute, the license compels you to distribute as CC-BY-SA'."
Just to clarify - I mean the situation where someone is distributing a game, and not distributing the source; just because someone chooses to do the former, the licence doesn't compel them to also distribute the source.
"I certainly agree, there seems to be plenty of grounds to suggest that source would not be covered by the SA clause. On the otherhand, I don't think I could look anybody thinking of using an CC-BY-SA asset in a closed source project in the eye and say 'Yeah that's a great idea! You should do that!'"
Well I wouldn't recommend someone using CC BY SA for a commercial project, but that's more because of the risk of CC BY SA applying to the entire released game (and in particular, the requirement that people can distribute it for free is not what most commercial game developers want). I wouldn't see any argument that they'd have to release their source code, just as I wouldn't see any argument that they'd to release things like Photoshop files, 3D source files, or any other data that was used to create the game. Even if the source code is considered "an adaption", there's nothing in the licence that says the source must be distributed with the binary.
If someone was using CC BY SA for a closed source freeware game, where they distributed the game binary as CC BY SA, I wouldn't see any risks that they'd have to release the source code too.
"I guess for the purposes of the site docs and faq, the issue can be left aside, as it's probably just enough to include a warning that a project, or parts of it, may fall under the SA clause, without delving into what those parts might be."
"It doesn't seem crystal clear that source code would never be considered part of an adaptation. "
If the source code was distributed together with a CC BY-SA asset, then yes there's the debate about whether it would be counted as part of the addaption. But obviously in that situation the point is moot as the source code is already released. In the case where source code isn't released, I don't see how it could be part of an adaption of what is released? Indeed even if it was part of the adaption, I don't see anything in the licence that compels me to distribute it? (If I modify a CC BY-SA asset but don't distribute it, even though the asset is still under CC BY-SA, I'm not required to distribute it to anyone.)
If that was the case, I feel there'd be a lot more things to worry about - e.g., if I use a paint program or music program to remix a CC BY-SA asset, and release the resultant PNG or MP3, am I also compelled to release all the associated files (e.g., whatever project files are generated by the paint or music programs I'm using)?
The GPL only works this way because the licence explicitly says the source has to be made available too.
"I certainly will move forward thinking that -SA and all GPL licenses would require that I release my source code."
Whether or not games would be covered as derivative works under CC BY SA, in neither case would CC BY SA require you to release source code.
"Overall, my 2 cents is that OGA should only recommend using -SA art in open source games"
Unfortunately it would be problematic for Open Source too, as the game would have to be released as CC BY-SA. Potentially open source authors might have more freedom to dual licence the binary; but if say I had a GPL game that used someone else's code under GPL, it would seem incompatible to relicense that under CC BY-SA (and who knows what it would mean for trying to use both GPL art and CC BY-SA...)
"Popular game distribution networks", I'd suggest just say "game distribution networks". Aside from simplicity/shortening, this is a "peacock term" that risks suggesting we're trying to argue in favour of one side. The developer or artist can judge for themselves how important a given platform or distribution site is.
"may or may not use DRM depending on how a particular game is pacakged (ex. Steam, Google Android). "
For Google Play, DRM is only enabled if the developer wants DRM. The current wording makes it sound like DRM would be enforced if you happened to package the game in a particular way, even if you didn't want it. I'm not aware that Steam is different. I'd suggest scrapping this bit completely unless someone can show DRM might be forced on developers in some cases. A more general point to say instead, for the point of view of artists wanting their art used in games, is that some commercial companies will want to use DRM (and the artist can decide for themselves whether that's what they want or not).
"but do not include entire projects or games which merely use the work in it's original form."
Whilst I would hope this is the case (if not, it makes CC BY-SA useless for most games, commercial or open source), unless we have a reference from creative commons or a legal opinion, I'm not sure this is known?
"'additional restictions' (ie. DRM)"
Possibly pedantic, should be e.g. (DRM is one form of restriction).
It might be worth mentioning that OGA-BY can be relicensed as CC-BY (this is useful for anyone worried about licence compatibility/proliferation, or sticking to more well known licences or those approved by OSI, FSF, Debian, etc).
It's a really good place for hosting projects, as well as providing support for selling, including support for "pay what you want". No upfront costs, and you can choose how much revenue cut they take.
One thing to note is that it doesn't seem to be a place that you can just put something there and get many extra views/downloads - at least mine are extremely low even compared to say my own website, I guess it's not a place that many people visit as users. But nonetheless, it provides a site and payment system for developers to make use of. Also this is something that could change as it grows more popular - and I think the recently launched itch client for people to download is a huge step forward (similar to stream, desura, etc). And I wasn't aware of the forums either, I'll check those out.
"Since mobiles don't always let users browse around the files in package a URL link in your credits or legal screen should be fine, and (hopefully) much easier to do than trying to replicate the work yourself."
This is one of the things I've wondered about. I stick the gpl.txt if required into my archive, but is this sufficient for a device where even though it's in the package, lack of root privileges means the users can't view that...?
I also typically put a link in my apps to a help page which includes the CC URLs and a link to the GPL (but not the full text), but in some cases this is an online web page - I have wondered if this is fine for CC licences at least (the help page is typically included in the archive too, but again, the user generally can't access that on a non-rooted mobile device).
The FSF's view is at https://www.gnu.org/licenses/gpl-faq.en.html#GPLOtherThanSoftware . They say it shouldn't be used if it's not clear what the source form is - but I can see cases where it is clear.
I'm not sure proprietary formats makes things fuzzy, the same could apply to any proprietary programming language. I'd say the preferred form is whatever the person used to edit, even if it's proprietary - this doesn't mean it has to be preferred by other people (someone might write in assembler and therefore release the assembly language code, the fact that I might prefer to work in something higher level doesn't change that).
It would be a shame to disallow existing gpl art out there even if we'd prefer a different licence to have been used.
The heroism/debian example shows that this can be a problem in practice, not merely in principle. Disallowing gpl altogether would have meant that music never got uploaded at all - which would have saved at least one developer time, but might have been a shame. Does the egoboo game contain the source? I see that egoboo is available on Debian repositories, so why don't Debian have a problem with that?
Whilst the GPL isn't as clear as CC0, the same is true of any licence out there, free or proprietary. People have their reasons for not releasing everything they do as public domain, and we have to work with that.
N.B., website now moved to http://gigalomania.sourceforge.net/ .
Note that all licences on here allow commercial use (CC Non-commercial isn't allowed here).
CC BY-SA would also likely (as far as I can tell) require that the resultant movie is released under the same (CC BY-SA) licence.
"Just assume when I say 'the license compels you to distribute as CC-BY-SA' I mean 'IF you chose to distribute, the license compels you to distribute as CC-BY-SA'."
Just to clarify - I mean the situation where someone is distributing a game, and not distributing the source; just because someone chooses to do the former, the licence doesn't compel them to also distribute the source.
"I certainly agree, there seems to be plenty of grounds to suggest that source would not be covered by the SA clause. On the otherhand, I don't think I could look anybody thinking of using an CC-BY-SA asset in a closed source project in the eye and say 'Yeah that's a great idea! You should do that!'"
Well I wouldn't recommend someone using CC BY SA for a commercial project, but that's more because of the risk of CC BY SA applying to the entire released game (and in particular, the requirement that people can distribute it for free is not what most commercial game developers want). I wouldn't see any argument that they'd have to release their source code, just as I wouldn't see any argument that they'd to release things like Photoshop files, 3D source files, or any other data that was used to create the game. Even if the source code is considered "an adaption", there's nothing in the licence that says the source must be distributed with the binary.
If someone was using CC BY SA for a closed source freeware game, where they distributed the game binary as CC BY SA, I wouldn't see any risks that they'd have to release the source code too.
"I guess for the purposes of the site docs and faq, the issue can be left aside, as it's probably just enough to include a warning that a project, or parts of it, may fall under the SA clause, without delving into what those parts might be."
I agree with that.
"It doesn't seem crystal clear that source code would never be considered part of an adaptation. "
If the source code was distributed together with a CC BY-SA asset, then yes there's the debate about whether it would be counted as part of the addaption. But obviously in that situation the point is moot as the source code is already released. In the case where source code isn't released, I don't see how it could be part of an adaption of what is released? Indeed even if it was part of the adaption, I don't see anything in the licence that compels me to distribute it? (If I modify a CC BY-SA asset but don't distribute it, even though the asset is still under CC BY-SA, I'm not required to distribute it to anyone.)
If that was the case, I feel there'd be a lot more things to worry about - e.g., if I use a paint program or music program to remix a CC BY-SA asset, and release the resultant PNG or MP3, am I also compelled to release all the associated files (e.g., whatever project files are generated by the paint or music programs I'm using)?
The GPL only works this way because the licence explicitly says the source has to be made available too.
"I certainly will move forward thinking that -SA and all GPL licenses would require that I release my source code."
Whether or not games would be covered as derivative works under CC BY SA, in neither case would CC BY SA require you to release source code.
"Overall, my 2 cents is that OGA should only recommend using -SA art in open source games"
Unfortunately it would be problematic for Open Source too, as the game would have to be released as CC BY-SA. Potentially open source authors might have more freedom to dual licence the binary; but if say I had a GPL game that used someone else's code under GPL, it would seem incompatible to relicense that under CC BY-SA (and who knows what it would mean for trying to use both GPL art and CC BY-SA...)
Just a few minor suggestions:
"Popular game distribution networks", I'd suggest just say "game distribution networks". Aside from simplicity/shortening, this is a "peacock term" that risks suggesting we're trying to argue in favour of one side. The developer or artist can judge for themselves how important a given platform or distribution site is.
"may or may not use DRM depending on how a particular game is pacakged (ex. Steam, Google Android). "
For Google Play, DRM is only enabled if the developer wants DRM. The current wording makes it sound like DRM would be enforced if you happened to package the game in a particular way, even if you didn't want it. I'm not aware that Steam is different. I'd suggest scrapping this bit completely unless someone can show DRM might be forced on developers in some cases. A more general point to say instead, for the point of view of artists wanting their art used in games, is that some commercial companies will want to use DRM (and the artist can decide for themselves whether that's what they want or not).
"but do not include entire projects or games which merely use the work in it's original form."
Whilst I would hope this is the case (if not, it makes CC BY-SA useless for most games, commercial or open source), unless we have a reference from creative commons or a legal opinion, I'm not sure this is known?
"'additional restictions' (ie. DRM)"
Possibly pedantic, should be e.g. (DRM is one form of restriction).
It might be worth mentioning that OGA-BY can be relicensed as CC-BY (this is useful for anyone worried about licence compatibility/proliferation, or sticking to more well known licences or those approved by OSI, FSF, Debian, etc).
I'm at http://mdwh.itch.io .
It's a really good place for hosting projects, as well as providing support for selling, including support for "pay what you want". No upfront costs, and you can choose how much revenue cut they take.
One thing to note is that it doesn't seem to be a place that you can just put something there and get many extra views/downloads - at least mine are extremely low even compared to say my own website, I guess it's not a place that many people visit as users. But nonetheless, it provides a site and payment system for developers to make use of. Also this is something that could change as it grows more popular - and I think the recently launched itch client for people to download is a huge step forward (similar to stream, desura, etc). And I wasn't aware of the forums either, I'll check those out.
"Since mobiles don't always let users browse around the files in package a URL link in your credits or legal screen should be fine, and (hopefully) much easier to do than trying to replicate the work yourself."
This is one of the things I've wondered about. I stick the gpl.txt if required into my archive, but is this sufficient for a device where even though it's in the package, lack of root privileges means the users can't view that...?
I also typically put a link in my apps to a help page which includes the CC URLs and a link to the GPL (but not the full text), but in some cases this is an online web page - I have wondered if this is fine for CC licences at least (the help page is typically included in the archive too, but again, the user generally can't access that on a non-rooted mobile device).
Also see https://musescore.org/en/handbook/soundfont for some handy links to various Soundfonts (SF2).
Pages