This software contains multiple cases of blatant trademark infringement, as well as what I suspect to be straight up copyright infringement (copying of sprites from other games). Specifically: Akuma, Blanka, - Street Fighter/Capcom Donatello - Kevin Eastman & Peter Laird/Konami Goku - Akira Toriyama/Bird Studio/Shueisha Kagetsura - Sengoku 3 - Noise Factory/SNK Kula - King of Fighters - SNK Michael Jackson - Moonwalker - Sega Ryu - Street Fighter/Capcom Terry B. - Fatal Fury/King Of Fighters/SNK Venom - Marvel vs Capcom/Capcom/DISNEY Wolverine - Marvel vs Capcom/Capcom/DISNEY I strongly suspect the other characters are similarly infringing (Mandy. Max), but I can't identify them. I'm asking Release Engineering to remove this package from the active repositories and block it from koji. In order to lift this block, you need to remove all the content from this package which is infringing upon the legal rights of others, and replace it with useful content without restrictions on distribution (ideally under a Free license). I believe that this codebase comes with tooling to create original characters and content, so this task is possible.
I'm really sorry about this lack. I hope to be able to exclude all legally restricted characters in order to leave Paintown available from Fedora. A new review is mandatory at this point.
I strongly suggest that you also communicate with the upstream here, and document the origins and licensing for all artwork included in the code base. If upstream was willing to split the data into "free" and "non-free", that would help us out in packaging for Fedora.
I'm in contact with upstream by web-chat. I'm optimistic because Paintown seems to be playable with totally free content.
See also https://bugzilla.redhat.com/show_bug.cgi?id=1150637
(In reply to Tom "spot" Callaway from comment #2) > I strongly suggest that you also communicate with the upstream here, and > document the origins and licensing for all artwork included in the code base. > > If upstream was willing to split the data into "free" and "non-free", that > would help us out in packaging for Fedora. Latest change of Paintown propose a "clean" commit of source code without non-free code [1]. This entails that we can package a totally free Paintown's rpm [2] but not playable game because of missing data files. The data (non-free) source archive can be separately downloaded and indicated for running correctly the game by user. Is this a reasonable choice? [1] https://github.com/kazzmir/paintown/issues/23#issuecomment-380565698 [2] http://copr-fe.cloud.fedoraproject.org/coprs/sagitter/ForTesting/build/755947/
I've given this a lot of thought, and the answer is no. This is complicated, but as it is right now, the only way to use Paintown is to download material which is clearly (and obviously) pirated/stolen. It is not just that this game data is non-free, but rather, that the copyright and trademark holders for these files have not given permission for it to be used or distributed. When I suggested that the upstream splitting the data into "Free" and "Non-free" would be helpful, I meant the splitting up the "data". Not simply marking all of the game art/level art as "Non-Free" and leaving the software as "Free". This action strongly implies that none of the game art/data is legally distributable. If Fedora were to include Paintown without any data, it would have the following problems: 1. It would not be useful on its own. 2. The only way to make it useful would be to direct users in some fashion to material that is obviously stolen. In cases of other games in Fedora, where the game data has been under a non-free license, the data has been distributed either by the rights holder or with the explicit permission of the rights holder. This is not the case with Paintown. Unless the rights holders give explicit and documented permission for Paintown to distribute these game data files (and I think I have a far better chance of winning the Powerball lottery), it would be extremely inappropriate for Fedora to point users to them. ***** So. What could Paintown do? 1. Get rid of these stolen assets before lawyers show up and make them. Again, I feel strongly that the upstream knows these assets are stolen/misappropriated. 2. Create new art/game data files which do not infringe upon the copyrights or trademarks of others. The Tux mascot is available under an extremely permissive license, and would be a good first "character". The natural world and all the living things in it provide any number of clever ideas for a talented artist to create a new fighter and a new landscape to do battle. I am not saying that "Sonyc the Hedgedog" would be acceptable, but a ferocious boxing kangaroo named Ricardo who fights ninja squirrels in a post-apocalyptic wasteland is new ground and does not infringe upon anything that I am aware of. (Should paintown wish to implement Ricardo, I waive any and all rights on that idea, as long as it is implemented under Free licensing.) If Paintown does 1 & 2, then there is no longer any legal issue. If they just do #2, then we can consider adding paintown back to Fedora with just the non-infringing content/game data. We could not (and would not) refer users to the infringing content/game data in any way, and if the game did, it would either have to be patched out or kept out of Fedora.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I'm certain this ticket is still valid. There were almost no changes for the package since 2018-03.