On Mon, 05 May 2008 05:11:34 +0800 James 'Ender' Brown wrote: > Hi all,
Hi and thanks for jumping into the discussion! ;-) [...] > Francesco: > > > Moreover, an interesting discussion about another beneath-a-steel-sky > > DFSG-freeness issue is currently ongoing on debian-legal: > > http://lists.debian.org/debian-legal/2008/05/msg00001.html > > Mmm. The trademark problem has been around for ages - I guess the > Firefox/Iceweasel > thing has brought it to the front again. This issue has been debated a > billion > times in Debian - Although the logo image is 'technically' free under the > terms > of the license, it is not 'functionally' free under various countries > trademark laws. Are you sure we are actually allowed to modify the logo image, from a copyright point of view? I mean: does the copyright license for beneath-a-steel-sky cover those couple of logo images as well? The original concern of Gonéri Le Bouder was that those logo images are probably not covered by the license of the game data (lure-of-the-temptress in his case): http://lists.debian.org/debian-devel-games/2008/05/msg00003.html > > I can say Revolution wouldn't hold anyone actionable, but cannot extend that > to cover > any companies in the Virgin group. There are many many instances in main > where a > 'TM' somewhere in a image or logo will override any included license terms on > a product, > although I guess generally the onus is on the user to be aware of his/her > local trademark > restrictions. Trademarks trump Copyright :( Things are not that simple, unfortunately. Trademarks and copyrights are distinct branches of laws. In order to avoid doing illegal actions, one has to comply with both laws at the same time. Hence, for a work (the logo image) which is copyrighted and at the same time represents a trademark, some restrictions may come from copyright laws (taking the copyright license into account), and some may come from trademark laws (taking a possible trademark license into account). What is important, from a DFSG-freeness point of view, is whether those restrictions meet or fail the DFSG... > > Someone let me know how this turns out - if it comes down to removal, I would > prefer > to ask Revolution for a 'free' logo to redistribute. The ScummVM team has a > great > relationship with these game studios, and want to maintain that where > possible :) Help from ScummVM team would be greatly appreciated, I think. _Both_ on the relationship with Revolution Software front _and_ on the modification tool front... > > > On the other hand, my doubts about the DFSG-freeness of > > beneath-a-steel-sky are not due to its license, but instead to the > > actual availability of its source code. I raised these doubts in > > http://bugs.debian.org/322620#67 > > BASS, Lure and Flight of the Amazon Queen are an interesting application > of the source code (aka 'Preferred source of modification') issue. There > are several points with regards to BASS: > * Most of the 'source data' and original tools are long lost, thus the > included datafiles have become the preferable source of modification. It > is the sole material the ScummVM team has, and we ourselves use it as a > base. OK, since the ScummVM team is effectively the current upstream maintainer of beneath-a-steel-sky and uses that form to make modifications to it, then that form is indeed source code. I think this is clarified once and for all. Thanks for the explanation. > > * Although its an extreme case of the 'Desert Island' scenario, I > don't think a lack of tools allowing modification means it should fail > our of principle - some tools do exist, but have not been released or > are single-purpose only (eg, compressors in scummvm-tools). After some thought about this issue, I've come to the conclusion that the lack of "good" editors is not a DFSG-freeness issue. It's impossible to mandate that modification tools are "easy" and "comfortable" enough, because that's subjective. _Some_ modification tools are always available: at worst, you could always use a text editor or a hexadecimal editor to modify the data. It could be overly difficult for many people, but, if upstream maintainers do not have any better tool, I think it's acceptable, even though sub-optimal... > > * Trivia: THe _original_ game was written in AMOS for the Amiga, and > thus the original source files were AMOS resource banks with IFF images > and AMAL animation. The PC datafiles are a ugly ugly conversion of the > original files. The irony is if the source material was released, they > might be editable, but nothing could recompile them into a _playable_ > form :) Then we can say that the original source is no longer the source for the current game data. Just as in the case of a COBOL program which is translated into Python and then further modified. The source for the modified version is indeed Python code, not the original COBOL code, since you would really prefer starting from Python code in order to make _further_ modifications. So, my conclusions are: * we have actual (though ugly) source code for the game data * we need to clarify which restrictions apply to the logo images (beyond the ones that come from the combination of the copyright license with copyright laws) * if those logo images come with non-free restrictions, we need to remove the logos from the game data (no tricks with the interpreter, please!) * developing an editor for the game data format would be _really_ useful and appreciated (ScummVM developers are probably the most qualified people to do that, since their interpreter is at least capable of _reading_ those data [1]) [1] would it be hard to develop a tool that is able to read and extract images, sounds, and human-readable game-logic description (a sort of disassembler) and a tool capable of re-archiving (possibly modified) images, sounds, and human-readable game-logic description in the right format (a sort of assembler)? My usual disclaimers: IANAL, TINLA, IANADD, TINASOTODP. -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
pgpCAAVZcUPvo.pgp
Description: PGP signature
