S3TC patent violation in multiple packages?
Hi, the S3TC texture compression scheme is covered by an US patent, as described in http://lists.freedesktop.org/archives/nouveau/2010-March/005439.html The following Debian packages in main seem to contain S3TC decompression code: - imagemagick: $ convert -list format | grep DDS DDS* DDS r-- Microsoft DirectDraw Surface it decodes DXT1, DXT3, DXT5 inside DDS files, which is S3TC. - ffmpeg (contains dxt1 functions in its source code) - gimp-dds (obviously, the whole purpose of this plugin is to encode/decode S3TC compressed textures) Shouldn't this be an issue for Debian? Especially in case of ImageMagick, this can lead to people unknowingly using patent encumbered code e.g. on commercial web servers. Even if they just use ImageMagick to convert from e.g. BMP to JPG, wouldn't they then still have to pay license costs for the S3TC decompression algorithm as it is in ImageMagick, as they use software implementing the patent? The other two are maybe a different matter, as one can't use ffmpeg or gimp-dds at all without violating patent claims anyway, so any user of these maybe can be assumed to be aware of that (ignoring the fact that one can use and compile ffmpeg with only purely free codecs like Theora, as face it, nobody does that anyway, which is also why Debian includes e.g. MPEG-4 support). Additionally, there is an idea... I think it is possible to do low-quality decoding of S3TC without actually implementing the patent. All patent claims that cover decoding talk about an analog curve, which refers to linear interpolation between two palette colors in each 4x4 block of the format. I am wondering if taking just the average of the two palette colors of each 4x4 block, and not considering any palette indexes or interpolation inside, is a way to evade the patent (at a high quality loss, though). Of course, the average of the two colors is not guaranteed to be the average of the 4x4 block, but it seems to come close in experimentation. One issue however may be that even the act of averaging the two colors MAY be construed as an analog curve; however, if you do that, note that each 4x4 block is decompressed to a single pixel, so the blocks are out. Also, obviously no curve selection module would exist in that. Similarily, for encoding, one could write an encoder that encodes each 4x4 block using an optimum 2-color palette, ignoring the two interpolated colors S3TC allows to use. This would also get rid of the analog curve, and thus should evade the patent properly - again at a noticeable quality loss, though. Best regards, Rudolf Polzer -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101225125809.ga1...@div0.qc.to
Re: MS-PL LGPL
On Mon, Dec 20, 2010 at 08:31:24AM +0100, Jan Brennenstuhl wrote: Hi, My name is Jan, I'm from Berlin (Germany) and currently programming a desktop tool as a part of my Bachelor thesis. My lecturer recommended me to write you because of one of my problems with software licenses: I would like to use two dll-libraries in my tool. The problem is that one is licensed under LGPL and the other under MS-PL. I read a lot about both licenses but I'm still not sure whether I could use both in my tool and under which license my tool has to be licensed in the end. I just wanted to know whether you have any idea or suggestion. Would be great if you could help. First of all, this is off-topic on this list, as we talk mainly about DFSG compliance, and about legal issues with packages in Debian. However, the combination you are talking about is perfectly fine. The MS-PL does not restrict the license of your program, or of other software components. Neither does the LGPL (as opposed to the GPL). So you should be fine. Best regards, Rudolf Polzer -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101220092628.ga20...@div0.qc.to
Re: Plugins for non-free software in orig.tar.gz
On Tue, Jul 13, 2010 at 11:14:11PM -0500, Christofer C. Bell wrote: On Tue, Jul 13, 2010 at 12:38 AM, Rudolf Polzer divver...@alientrap.org wrote: Do I then get into trouble with the GPL, as the source tarball contains code that links to non-GPL compatible code? You can't get in trouble for anything you do with your own code to which you own the copyright. You only run into issues when you do something with code someone else holds copyright to. In this case, you're free to link OpenSSL against your own software, that belongs to you, to which you own the copyright. Sure, _I_ cannot get into trouble for it. I meant to ask whether the source tarball actually fulfills the source code requirement of the GPL. This BTW affects the FreeBSD project too The FreeBSD Foundation is free to do whatever they like with code they own the copyright to. They must adhere to any licenses for code they include in FreeBSD for which they do not own the copyright. Right, the FreeBSD foundation is not affected by this. A vendor using the FreeBSD kernel might, though. Assume a vendor uses a FreeBSD kernel with integrated ext2fs file system. Then he has to release the full kernel source, as the GPL applies to the combined work. An easy way for such a vendor would be to just make a tarball of the exact /usr/src/sys directory he build the kernel in. However, this also contains sources that are distributed under the CDDL. Does the vendor then have to identify and take out these sources, or can he release the tarball as is, and it is enough that these sources are not compiled by the vendor's configuration? (Why I am asking this in the same thread, is that my main question is actually pretty much similar - it is about non-free sources included in the .orig.tar.gz which are not compiled into the binary). Best regards, Rudolf Polzer -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714063332.ga22...@div0.qc.to
Re: Plugins for non-free software in orig.tar.gz
On Mon, Jul 12, 2010 at 11:15:59PM +0200, Francesco Poli wrote: I think that probably the safest course of action is summarizing the issues to upstream copyright holders, without directly involving them in debian-legal discussions. I have another such case where I would be upstream. I currently have a library that I am the only copyright holder of, that is currently under the LGPL and uses libgmp for big number arithmetics. However, if anyone wants to use the library commercially, he'd sure prefer a version of it that uses OpenSSL instead, as that gets rid of the requirement to have infrastructure to distribute the source code of the libraries in use, while personally I prefer the libgmp variant as it is about 10% faster in my use cases. The library uses libgmp, as the main intended use for my purposes is use as part of a program under the GPL. Now assume I do this: library.c - main code bignum-gmp.c - libgmp bignum wrapper bignum-openssl.c - openssl bignum wrapper and I change the license of library.c to a BSD-style license. Also, the library would by default compile against libgmp, and would have to explicitly told so in configure to use bignum-openssl.c instead. Do I then get into trouble with the GPL, as the source tarball contains code that links to non-GPL compatible code? Would GPL users have to split up my tarball (remove bignum-openssl.c from it) to comply with the GPL? Or can they safely distribute my source in full, because bignum-openssl.c is not compiled into the final binary? This BTW affects the FreeBSD project too - you can compile a GPL contaminated kernel by including the ext2fs driver, but the source tree also contains files under the CDDL that are not compiled in by default. Would a distributor of a GPL contaminated kernel have to roll his own GPL-compatible source archive, removing the CDDL files and the references to them, or can he just tar up everything (including kernel config) and the CDDL source files do no harm as they are not part of the configuration? Best regards, Rudolf Polzer -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100713053850.ga8...@div0.qc.to
Re: Distribution of media content together with GPLv2 code in one package?
On Tue, Apr 20, 2010 at 12:34:29PM +1000, Ben Finney wrote: It might help to realise that there are multiple “works” to which copyright applies: * The digitally-encoded audio recorded from sounds performed at a particular time. * The words, presumably written down in some form. * The musical arrangement, possibly also written down in some form. * Likely many other copyrighted works involved in the production of some audio. Any of these can become software, in that they can be encoded as digital information. As such, they are something that could be stored in a computer and distributed with a copyright license, at which point it becomes interesting to ask about the DFSG-conformance of each of those works. That license may or may not allow modification, derived works, redistribution under the same license terms, and so on. There can also, of course, be entirely different license terms for each of the above works. If I understand Francesco right, he is pointing out that the work most likely to be distributed is the very first one mentioned above: the digitally-encoded audio. Sure, but once another of these is considered source form for the digitally-encoded audio, their license terms suddenly become relevant too. The big question is WHETHER these shall be considered source. That work can be modified by editing the digital audio data in an appropriate program, which thus creates a derived work of the existing digital audio. Sure. Re-creating the audio recording from scratch, as Rudolf describes, would be a new copyright work, and I agree that it's disingenuous to describe this as “editing”. It would be a derived work of the copyrighted words, musical arrangement, etc.; but it is less clear what its copyright relationship to the previous digital audio data would be. In case of the voice synthesis application, is it recreating or editing when you re-render the voice using different words, and then perform editing on the resulting file (typically: reverb, EQ, dynamics compression)? The direct output of the voice synthesis application is not automatically transformable to the final result. Just like taking a second photograph of a given subject is not modifying the photograph, but recreating it from scratch in a different way. The potentially confusing aspect here is that, unlike photography, re-creating an audio recording will often be based on some other copyright work: the scripted words, the arranged musical notes, etc. But I think you're right to say that these are *not* the “source form” of the digital audio; the digital audio itself is the source form of that software work. By that interpretation, to provide source for a finished piece of music needs to only include the music track in a good quality editable form (in doubt, this is FLAC/WAV) - basically, whatever the producer would ALSO use to continue working on THAT part, ignoring the path to it. But, this would include none of the words, the musical notes (i.e. project file of the music application creating the input for the final mastering process), the instrument samples, etc., but ONLY digital audio which e.g. can be used as a basis for remixes. Rudolf Polzer -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100420064551.ga22...@rm.endoftheinternet.org
Re: Distribution of media content together with GPLv2 code in one package?
On Tue, Apr 20, 2010 at 11:51:43PM +1000, Ben Finney wrote: Rudolf Polzer divver...@alientrap.org writes: In case of the voice synthesis application, is it recreating or editing when you re-render the voice using different words, and then perform editing on the resulting file (typically: reverb, EQ, dynamics compression)? It's important to recognise that the only answer which matters here is that which would be given by a judge if it were ever to be a case in court. So there's only so far that hair-splitting like this can take us before it becomes moot. You have the opinion of several non-lawyers on this matter. At this point I advise you to form a provisional opinion on that basis, until you seek the advice of your own professional legal advisor. I am pretty confident that nobody will dare to sue in that grey area of the GPL. Also, the people (id software) whose work is being used under the GPL, and causes the result to be under the GPL too are themselves of the opinion that GPL stuff can be freely combined with non-GPL as long as no static linking is being done, and also have not sued projects who possibly might be in violation depending on interpretation (like Warsow). However, my goal is to get the game in _Debian_ and other Linux distributions. And for that it is required to adhere to DFSG and similar standards, and interpretation of these regarding non-code seems to be quite open. Basically, as far as I understood it, for inclusion in Debian, two conditions are required: - DFSG - Debian must be under the impression that the package is properly licensed Debian for example won't accept a package that is under the GPL and statically links against a library that is under the CDDL (did I hear anyone saying J**g Schng, by the way?), even though both licensed are assumed to be DFSG-free. So basically, my question is: Would Debian accept a game into main that, itself, is released under the GPL, and contains music tracks for which only a high-quality OggVorbis file and the project file in the music notation application is provided, even if the software used to create the music is commercial software, or the music even might use commercially provided (or CC-BY) samples, assuming these commercial software or sample files do not restrict the licensing of the resulting file? I know some projects which actually do that (or even provide no source at all other than the ogg file itself), by the way, and which are in main, two of which I mentioned in the original post but won't name here again. I do not want these games to get into trouble with Debian, and also am not convinced - even less after this thread, as the opinions on this seem to vary a lot even inside the Debian project - that these actually are DFSG violations, and thus worth reporting a bug. Best regards, Rudolf Polzer -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100420154945.ga2...@rm.endoftheinternet.org
Re: Distribution of media content together with GPLv2 code in one package?
to generate identical output without access to the compiler, which may be commercial too - but that GPL and a commercial compiler don't conflict has been accepted for long). Nothing prevents you from performing it in a real orchestra, or using your own samples in place of the missing ones - just like nothing prevents you from reading out the same lines of text with YOUR voice, and recording that. Rudolf Polzer -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100418173455.ga22...@rm.endoftheinternet.org
Re: Distribution of media content together with GPLv2 code in one package?
On Fri, Apr 16, 2010 at 10:20:12PM +0200, Francesco Poli wrote: On Fri, 16 Apr 2010 09:45:42 +0200 Rudolf Polzer wrote: [...] Simply because the only part of the author that goes in is his thought, [...] It is indeed the author's thought that is goes in: something that is quite unique, I would say... Yes, but they are all transparently written down in the source code, in a form anyone can (learn to) read. Something that is simply impossible for many kinds of music or other media. In summary, I think you are oversimplifying the art of programming. Not really. You can perfectly replicate a program by copying its source code. You cannot replicate the sound of spoken words by speaking the same words. If you want to define source code as whatever is needed for replicating the output, in a form that can be edited, then spoken voice has no such thing. Rudolf Polzer -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100417211022.ga1...@rm.endoftheinternet.org
Re: Distribution of media content together with GPLv2 code in one package?
On Mon, Apr 05, 2010 at 06:20:43PM +0200, Bernhard R. Link wrote: * Rudolf Polzer divver...@alientrap.org [100404 12:16]: One argument against supplying full source code commonly raised by artists, is that a 3MB large music piece can depend on several gigabytes of source data, if applying the source requirement recursively. That is not much different with classical computer programs. When considering everything source that was somehow involved in creating it, including all the whole source of every project written by me from which I copied some lines, including all the specs and notes scanned in from the little pieces of paper I sometimes wrote them and so on, including all the core dumps of the editors when writing it and so on reaches gigabytes and beyond very fast. The only difference with programs is that there is some form we call source code and that we usually recognize as source (unless someone did something arbitrarily evil, like obfuscating it). In case of music/sound, it gets way more difficult once there are actually recorded parts on it. Although a recorded voice sample of the author's voice very obviously can be DFSG-free, it cannot really be edited. If you have a collection of such samples, you cannot easily add one more sample in the same style - as it is pretty hard to imitate the original author's voice. In fact, in one case related to the Nexuiz project, we found out the hard way that not even the original author managed to record a new voice sample that matched the previous ones. Because of this, the tutorial now sounds a bit odd at one part, which is the part where the rerecorded voice sample is - one can clearly hear how the speaker apparently was in a different mood for that sample. On the other hand, samples created even by commercial speech synthesis are WAY more editable, simply because they are editable at all (you can make the speaker say something else). How can THESE be nonfree or contrib then, while the recorded sample - which often NOBODY, not even the original speaker, can recreate - should be free and eligible for main? You can edit the synthesized sample in the very same ways as the recorded sample - by using waveform editing - but also in more ways (by rerendering it with e.g. different words). What the preferred form of modifiation is hard to decide - though it still is the best definition. But taking it too far never helped. Otherwise I've seen more than one perl script where the preferred form of modification would then have been the author and the stuff they must have smoked when writing this. (Though we usually accept the perl script unless it is consciously obfuscated). Indeed. For code, the definition of source is quite simple. Code typically consists of a string of characters. Anyone could have typed in these characters - someone else would be able to type in the very same program. Anyone can change a line in the program, and there is no reason why that line of the program should NOT be in the spirit of the original program. Simply because the only part of the author that goes in is his thought, but none of his bodily properties like race, form of the head, sex, length of vocal cords, etc - in fact, the length of the fingers has absolutely no influence over the code the author wrote, other than perhaps over variable naming. Even better - what counts for a program is not the style of the code, but how it functions. So the author-specific parts of the code DO NOT EVEN GO INTO THE BINARY! This is why another author can change part of someone else's program and it still feels like one single whole - because the differences in style do not end up in the binary, while e.g. for recorded voice, they are crucial. Also, in code, there is no such ambiguity about what is generated from what. The closest to a recorded vs synthesized voice sample you can get is e.g. writing a parser either manually or using a parser generator. If the author of the code then does major changes on the result created by the parser generator, and therefore just used the parser generator to create a prototype for him to work with, then this is very much like voice samples generated by speech synthesis are typically used. And in such cases, where there is no automated transform from the parser generator-written code to the code the software uses, it is generally accepted to just supply the finalized code. In fact, I would bet that many Debian projects in main indeed use hand-modified generated code without providing the input to the code generator. For example, quite some GUI code was initially created by some GUI designer software, and then edited and filled with functionality by hand - and in many such cases, the project file of the GUI designer - if any - is not even provided. Which there is nothing wrong with, IMHO, given that even the original author then would do further modification/reshuffling of dialog elements in the source code, instead of generating
Re: Distribution of media content together with GPLv2 code in one package?
On Mon, Apr 05, 2010 at 09:49:36AM +0100, Matthew Johnson wrote: I think it's pretty clear that you can distribute data alongside a GPL work without it being covered by the GPL. The reason why program objects which link the GPL work need to be distributed under the GPL is that the result constitutes a derivative work. If it did not, then copyright law cannot cover said aggregation. Whether linking constitutes a derivative work is something which has not been tested in court, but since that is the FSF's position, that's what most people go with. There's never been any suggestion that data which is processed by the application is covered: otherwise you couldn't choose the licence of documents you created with a GPL word processor. More importantly, however, the GPL contains a clause permitting 'mere aggregation'. The question rather is: what exactly is mere aggregation? Is the game not ONE new product, and thus one single item? After all, users don't download an engine and data for it, but they download a game. Also, the data typically is packed into somewhat opaque file containers. In the specific case, these are renamed zip files. To perform a separation, an idea would be using multiple of these files, one for files of each license. But would that be separated well enough? Also... as the game will not run without that data - can it even be called mere aggregation? Best regards, Rudolf -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100405115323.ga9...@rm.endoftheinternet.org
Re: Distribution of media content together with GPLv2 code in one package?
On Sun, Apr 04, 2010 at 03:43:32PM +0800, Paul Wise wrote: Firstly, the Debian Games team would very much welcome new games in Debian and even better would be new people willing to help the team with existing and new games in Debian. Regarding licenses, even if the license doesn't require source code distribution, Debian does, see DFSG #2. Some Debian members don't agree about whether or not that applies to fonts, images, documentation and other non-program software though. Really, what is the source code is extremely dependent on the exact situation. The best way to determine this is to think about the different kinds of modifications other people might want to do and whether or not they could achieve that using the source code you have sent them. One argument against supplying full source code commonly raised by artists, is that a 3MB large music piece can depend on several gigabytes of source data, if applying the source requirement recursively. BTW: is it DFSG and GPL compliant to compose music using CC-BY released samples? CC-BY does not require anything about the license of derived works (only CC-BY-SA does). And can't the source requirement of the GPL be fulfilled by providing the original samples and the info how to combine the work from these samples (project file) - which however then are under CC-BY? Regarding music, I have been thinking about how to switch from pre-rendered audio to using csound, STK or similar to create dynamically generated music. This would completely sidestep the source code issue. In addition, it would reduce required disk space and probably provide better and or more interesting music. The other, simpler alternative is to remove all music and let the user play music from their music collection. There are free sound fonts in Debian, it might be possible to build-depend on them and create audio files at build time from them. This stuff probably applies to sound effects too. Sorry, but I have NEVER heared any good sounding dynamically generated music, or procedurally generated sounds. Sounds often are mixed from hundreds of recorded samples from the same event (e.g. throwing a can on the ground). Artists then tend to delete the single recordings, and do further improvement based on the mixed recording. Also, the available free soundfonts (like freepats) are VERY poor quality. Regarding textures, procedural generation has been done before and might be a good way to go. So basically you say - kick out all artists, and make a coder-only game? Nobody would want to LOOK at that. Regarding fonts, it is always best to load fonts at runtime and render text using them. This also enables i18n and l10n, which are both unfortunately rare in games. For Debian, it is best if those fonts are standard system fonts or are packaged separately to the game since fonts are useful outside of games. Regarding places to get DFSG-free game assets, you probably know about this: http://www.freedesktop.org/wiki/Games/Resources Well, because of the source requirement, CC probably is not DFSG-free then? Destructive editing is a huge problem in games that is a hinderance to collaborative development, which I very much think needs to be avoided as much as is possible. It might be worth looking at Blender's YoFrankie! game for ideas on how to do that properly. Dynamically generated content is probably one of the ways forward here. One can clearly see that in the poor quality of the game screenshots. BTW, I notice the nexuiz website works with free Flash, nice! I'd personally prefer using web standards like HTML and JavaScript though. The jquery framework could probably enable the kind of effects you are using there. The website also works just fine without Flash - the video is provided as an OggTheora download link too. In case you mean the site http://www.nexuiz.com/ - this deal was made without consent of any of the developers and caused the developers to leave Alientrap. But that is another issue. Best regards, Rudolf Polzer -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100404101551.ga30...@rm.endoftheinternet.org
Re: Distribution of media content together with GPLv2 code in one package?
[I had accidentally sent this message to Paul Wise's address first. Resending] On Sun, Apr 04, 2010 at 06:35:59PM +0800, Paul Wise wrote: On Sun, Apr 4, 2010 at 6:15 PM, Rudolf Polzer divver...@alientrap.org wrote: BTW: is it DFSG and GPL compliant to compose music using CC-BY released samples? CC-BY does not require anything about the license of derived works (only CC-BY-SA does). And can't the source requirement of the GPL be fulfilled by providing the original samples and the info how to combine the work from these samples (project file) - which however then are under CC-BY? The GPL wouldn't have anything to do with that situation AFAICT. I can't see why the result wouldn't be DFSG-compliant since you're providing the original samples and a build script. Well, can it then still be one single download package? Can the game consist on multiple differently licensed parts? Can these then be provided as one download (and with an included text file defining the licenses of the parts)? The thing is - does the GPL even allow combining with non-GPL data in such a way? Also: most music applications do not support build scripts. The project file would still need manual actions to process to the finished file. Thus, the source package would then contain BOTH the resulting, edited, ogg file AND the project file for the application. Also, the available free soundfonts (like freepats) are VERY poor quality. Does that also apply to the fluid soundfont? http://packages.debian.org/search?keywords=fluid-soundfont Yes, although that one is already some progress. Well, because of the source requirement, CC probably is not DFSG-free then? Not requiring source distribution doesn't mean a license is not DFSG-free, for example BSD-licensed software is DFSG-free. However, DFSG require source distribution. BSD licensed software can be binary-only, but is not DFSG-free then. Best regards, Rudolf Polzer -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100404150423.ga2...@rm.endoftheinternet.org
Re: Distribution of media content together with GPLv2 code in one package?
On Sun, Apr 04, 2010 at 07:25:58PM +0800, Paul Wise wrote: On Sun, 2010-04-04 at 13:09 +0200, Rudolf Polzer wrote: Well, can it then still be one single download package? Can the game consist on multiple differently licensed parts? Can these then be provided as one download (and with an included text file defining the licenses of the parts)? The thing is - does the GPL even allow combining with non-GPL data in such a way? No way to know until it goes to court. The test is that if distributing the game executable alongside its data creates a derivative work or not. I would guess that it does not, but who knows what a court would decide. Ah, so better not go there yet... and instead wait if anything will happen to other games doing the same (like Warsow, Tremulous). On a related note - does the GPL-2 even require that the source code release be under the GPL-2 too? The wording seems to indicate that a GPL-2 conforming source release is not even required: | 3. You may copy and distribute the Program (or a work based on it, | under Section 2) in object code or executable form under the terms of | Sections 1 and 2 above provided that you also do one of the following: | | a) Accompany it with the complete corresponding machine-readable | source code, which must be distributed under the terms of Sections | 1 and 2 above on a medium customarily used for software interchange; or, So, only Sections 1 and 2 have to be fulfilled for the source code release! This basically means: the source release does not have to be covered by the full GPL, but only two clauses of it - one of which does not even apply to an unmodified source code release. Therefore, one might think about releasing e.g. a .mmpz project file (from LMMS) together with audio samples which are licensed under CC-BY v3.0. Or does this violate a term of the GPL elsewhere? This kind of looks like a small loop-hole in the GPL, which seems fixed in the GPL-3, which changed the source requirement to: | You may convey a covered work in object code form under the terms | of sections 4 and 5, provided that you also convey the | machine-readable Corresponding Source under the terms of this License, | in one of these ways: It clearly says under the terms of this license, and no longer under the terms of Sections 1 and 2. However, I cannot imagine how this could be exploited in the world of software. Well, because of the source requirement, CC probably is not DFSG-free then? Not requiring source distribution doesn't mean a license is not DFSG-free, for example BSD-licensed software is DFSG-free. However, DFSG require source distribution. BSD licensed software can be binary-only, but is not DFSG-free then. Right. That is a problem with any software though, BSD, GPL or whatever. Nothing ensures that upstream authors are sane about releasing code. Well, the GPL at least requires a source release in some way from the author. PS: not sure why you moved this off-list? An accidental user error, nothing more. Best regards, Rudolf Polzer -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100404153311.gb2...@rm.endoftheinternet.org
Distribution of media content together with GPLv2 code in one package?
Hello, speaking for a new game that will aim to be included in Debian, I wonder how certain media content can be legally distributed together with GPLv2 in one package. The main problem is that applying the GPL to certain types of media seems quite unclear, especially because of the question What exactly is source code? E.g.: Textures usually are edited destructively, in applications like GIMP. Typically further editing is done based on the last saved finished version. However, sometimes they may even be based on screenshots from a (free) game and possibly custom content for it, which afterwards is edited in various ways. Also, a typical manual destructive editing steps is retouching. Music is typically done using a large range of applications, also using destructive editing steps. A typical pipeline might be: 1. handwritten musical score on paper 2. playing that on a MIDI keyboard into a notation application (e.g. Rosegarden) 3. quantizing and edits in that notation application 4. export to MIDI format from the notation application 5. rendering to an audio file by MIDI synthesizer applications, or even external hardware devices 6. editing that audio file with a wave editing application (e.g. Audacity) What is to be considered the source code here? Is it allowed to use a commercially bought MIDI synthesizer application and samples, or a physical device (like an electronically controlled piano) for the recording? Basically, in both cases the big problem is destructive editing steps. Just changing a note of the music is simply not possible without repeating all the editing steps after it. Which is something the author would not even remember, and most likely do a different way next time. So, as the GPL raises a big uncertainty on what exactly constitutes source for non-code assets, I wonder whether it would be wiser to instead choose a different license for these assets. Because of the source code requirement of the GPL, there cannot be any GPL compliant license fulfilling this. On the other hand, many games that have been accepted in Debian main contain music and textures without accompanying source code for these assets. For example, a similar case can be found in Frozen Bubble - the directory snd/ of the source distributiion contains multiple opaque (source-less) audio files, including introzik.ogg and frozen-mainzig-1p.ogg. Yet still, the game is licensed under the GPLv2. Furthermore, Enigma is released under GPLv2 or later, and contains, in the directory data/ of the source distribution, a file models-2d.lua that references DejaVuSansCondensed.ttf, which actually is provided in the data/fonts/ directory. The Deja Vu fonts come with a license restriction that is not GPL compatible: The Font Software may be sold as part of a larger software package but no copy of one or more of the Font Software typefaces may be sold by itself. Also, for none of the graphics any more than a PNG file is provided. So, apparently these games - and many others - release source-less media content under the GPL, in case of Enigma even with clearly non-GPL-compatible origin. Therefore, I am asking - how can a game contain GPL code, but still use more artist friendly assets (especially because the source code requirement is NOT clear, as often there IS, because of manual destructive editing steps, no such thing as complete corresponding machine-readable source code source as the GPL demands)? Best regards, Rudolf Polzer -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100403122842.ga3...@rm.endoftheinternet.org
Re: Distribution of media content together with GPLv2 code in one package?
(as I was not subscribed, I manually wrote the In-Reply-To header - I hope the thread is properly connected. I am subscribed now.) Francesco Poli wrote:: On Sat, 3 Apr 2010 14:28:43 +0200 Rudolf Polzer wrote: speaking for a new game that will aim to be included in Debian, I wonder how certain media content can be legally distributed together with GPLv2 in one package. In various ways, I would say: some of them are the Right Thing To Do™, some other ones should be avoided. There are probably also ways that lie somewhere in between these two extremes... The whole reason why this seems to be so problematic, is that there are not many artists who want to share all the data they make. Thus, to be ABLE to get good quality art, the only way seems to be to use non-free art, or CC-BY/CC-BY-SA licensed artwork (CC-BY-SA v3.0, and thus CC-BY v3.0, is accepted as DFSG compliant, and has no source requirement). However, this would require packaging CC-BY(-SA) content together with GPL code, which again seems like it may not be legally possible. The code does not link to the content using a dynamic linker - but can e.g. just loading a texture file for displaying it, with the code referencing it by the file name, constitute linking? Can a single download - e.g. a zip file containing the whole game - even HAVE different licenses on different parts of it? In Debian packaging, this sort of can be circumvented by splitting into two packages, one with the GPL content and one with the CC-BY(-SA) content. But even then, the question would remain for non-Debian-using end users, who of course should only be presented one single download and not two separate ones. Warning! This is a somewhat flammable topic, you will probably find very different opinions, depending on who you ask to. I will try to explain my own personal opinion on the subject, but there does not seem to be strong consensus on every point. Sure - a lack of consensus in our own game team is the very reason why I am asking. Music is typically done using a large range of applications, also using destructive editing steps. A typical pipeline might be: 1. handwritten musical score on paper 2. playing that on a MIDI keyboard into a notation application (e.g. Rosegarden) 3. quantizing and edits in that notation application 4. export to MIDI format from the notation application 5. rendering to an audio file by MIDI synthesizer applications, or even external hardware devices 6. editing that audio file with a wave editing application (e.g. Audacity) What is to be considered the source code here? As always, the preferred form for making modifications to it. Whoever has made the last modifications to the work, should ask himself/herself: if I have to make further modifications, where would I start from? The answer is basically the source code form. Would he/she start from the file saved by Rosegarden? That is the source, then. Would he/she use the file saved by Audacity? That is the source, then. And so forth... Depending on the edit, you would either use the one form or the other. If you e.g. want to change how the fade-out at the end is done, you'd do that from Audacity. If you want to change a note, you need the Rosegarden project. For yet another kind of edits, you don't need either of the two projects, but simply work on the finished (uncompressed) wav file. For that reason, many artists don't even save the Audacity project, as it doesn't provide much more information than the finished wav file if all that is being done is single-track audio editing. Which is then the source form? The finished file (as you can do, e.g., perform equalizer and reverb effects on it)? The Rosegarden file, which then - when it is to be used - requires quite a lot of manual steps in audacity repeated to get the same result? The aggregate of both of them? If you just need the non-free MIDI application in order to create the initial version of the music file and then any further modification/compilation may be made with DFSG-free tools (in Debian main), then your music may go in Debian main, as long as it is DFSG-free and complies with the other requirements for Debian main. and samples, Using non-free samples may be problematic. They become part of the resulting work, as far as I can tell. Hence, the resulting work becomes non-free, I would say. But so does the sound of the physical piano become part of the work. Yet still, that thing is then typically seen as the compiler, and thus exempt from the source code requirement. Why should the following situations differ at all, legally: a) actual physical piano (possibly encumbered by patents) b) electronic piano (used as black box, internally performing FM synthesis using non-user-modifiable parameter sets) c) electronic piano (used as black box, internally performing wavetable synthesis using non-user-modifiable commercial sample banks) d) electronic
Bro check out this awesome new product
Now, it's finally possible for you to enlarge your penis http://www.legahe.com/ss/ Wanna be more man? Check this dude -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
