Re: Debian-approved creative/content license?
Ying-Chun Liu (PaulLiu) escribe: By ears, there's no difference between mp3 and wav It depends on the ears, certainly. It also depends on the bitrate chosen for the MP3 file and also on the audio outboard used (at 128 Kbps there's no difference with a portable player but the difference becomes obvious with top class speakers). The same thing also happens on images, like xcf/psd or png/jpg/gif or whatever. But the author should release the true source he really has. To require the author to use some listed formats for image source or audio source is impracticable. And if we define ogg/mp3 is not source, the games which have ogg/mp3 as data but cannot provide wav (may be deleted by the author by nature) will be non-free due to DFSG#2. Agreed. If the author used MPEG-4 video files as the source it makes no sense forcing him to share them in MJPEG format. Also if he remixed MP3 files, why forcing to share FLAC or WAV? There will be no gain. The author should release the true source he really has. That's the point IMHO. Cordially, Ismael -- Ismael Valladolid Torres m. +34679156321 La media hostia j. [EMAIL PROTECTED] http://lamediahostia.blogspot.com/ pgp7f2U5kc7fj.pgp Description: PGP signature
Re: Debian-approved creative/content license?
Ying-Chun Liu (PaulLiu) [EMAIL PROTECTED] writes: So, for creative works, the source is hard to be defined by format. It's the creativity of a work that allows it to be covered by copyright. Non-creative works -- e.g. a plain listing of the digits of a mathematical constant -- are generally deemed un-copyrightable. I don't see what distinction you're making there with creative works. Are you making some distinction between a software work which happens to be interpreted as a program and a software work which happens to be interpreted in some other way? I don't think that's a relevant distinction. Not like programs, we can easily know what is machine code and what is high level language code in most situations. We can only ask the author of the creative works to release their work honestly because in most situation we can't distinguish the source and binary if the author is lying. If the last format he has is wav, then he should release wav. If the last format he has is mp3, then mp3. Yes. The GPL's definition of source is a good one: the preferred form of the work for making modifications to it. We have to, as you say, make a judgement call as to whether the author of the work is being truthful about that preferred form. The same thing also happens on images, like xcf/psd or png/jpg/gif or whatever. But the author should release the true source he really has. Yes. The form that they prefer for making modifications to the work. -- \ If you do not trust the source do not use this program. -- | `\ Microsoft Vista security dialogue | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Choosing a license for Frets on Fire songs
On Tue Mar 27 20:54, Jason Spiro wrote: 2007/3/27, Don Armstrong [EMAIL PROTECTED]: On Tue, 27 Mar 2007, Jason Spiro wrote: Maybe if debian-legal or I wrote the license (I have never written a license before, but maybe I could modify the MIT license) we could get Teosto to agree on more liberal terms than we would get if Teosto wrote one? The following is what I would use if I were to license my own compositions[1] for distribution in Debian: I'm sure you realize Teosto would consider the BSD license far too liberal, and forbid it. :-) Seriously, do you think my idea of writing a license has merit? Such a licence would not get the songs in main, though. I imagine it would fail DFSG 6 and possibly 3. It would get them in non-free though which would allow the rest of the game in contrib or, if we managed to find some free songs to go with it, in main. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Choosing a license for Frets on Fire songs
* Don Armstrong: Well, it actually seems rather strange to me for an organization which is designed to protect artists disallowing artists from determining how their own works are licensed, This is common practice for organizations that collect royalties on behalf of composers. If you want to create free content, you need to steer clear of them (unless they don't require exclusive exploitation rights, which is the exception). 8-( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Choosing a license for Frets on Fire songs
On 3/28/07, Andrew Donnellan [EMAIL PROTECTED] wrote: On 3/28/07, Don Armstrong [EMAIL PROTECTED] wrote: Well, it actually seems rather strange to me for an organization which is designed to protect artists disallowing artists from determining how their own works are licensed, so I'm trying to give them the benifit of the doubt here. Do they really? That would mean that all the copyright holders would have given them exclusive licensing rights. Yes that's the contract you have to sign to be part of Teosto (which you have to do if you ever want to make a living in Finland as a musician). I haven't read the full bug log, but has anyone contacted the composers directly? Yes, we have. They are part of the upstream team and their contract forbids them from releasing _anything_ which is not under a licence Teosto agree with. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Choosing a license for Frets on Fire songs
On 3/28/07, Matthew Johnson [EMAIL PROTECTED] wrote: Yes that's the contract you have to sign to be part of Teosto (which you have to do if you ever want to make a living in Finland as a musician). Ouch. As was indicated earlier this seems standard for all performance rights organisations. -- Andrew Donnellan ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure) http://andrewdonnellan.com http://ajdlinux.wordpress.com [EMAIL PROTECTED] hkp://subkeys.pgp.net 0x5D4C0C58 http://linux.org.auhttp://debian.org Get free rewards - http://ezyrewards.com/?id=23484 Spammers only === [EMAIL PROTECTED] === -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
Francesco Poli [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Exactly, and in some cases an author/maintainer *may* prefer to modify a lossy-compressed form directly. In some other cases, he/she *may* prefer working on uncompressed data and recompress afterward... Yes, I'm really starting to question the idea of source. It seems to me that the preferred form of modification seems to depend on the desired modification. Since this is Debian, I will use the example of Toy Story. Let us say that Steve Jobs inexplicably decides he wants to release Toy Story as a open-source movie, and manages to convince the rest of the people at Disney that this was a good idea. Thinking about only the video portion, what would we call source? I can see three answers to this: 1. The model files, lighting, and animation information. This can be used to regenerate the movie. 2. The original raw frames of the rendered video. 3. The compressed final video stream. Lets take a closer look at these: First look at the first option. This is clearly the most high-level description. It may seem like this is the ideal format to call source. Certainly this would be the form one would prefer if one wanted to introduce a new character, or replace a character in the movie. Also this would likely be the preferred form for making major plot changes etc. However, the recourses required to render the movie are significant. The movie used 117 computers (87 dual-processor and 30 quad-processor SPARCstation 20s and one eight-processor SPARCserver 1000 [How 87+30+1=117 is unclear to me.])which thus totals 302 processors, and a combined performance rate of 16,000 MIPS (This is probably the value most relevant for today).It allegedly would have taken 43 years for a single processor to render the entire feature. Even with the significant speed increase in computers since 1995, it should be clear that rendering the movie would still be a significant undertaking. That to me indicates that for many types of modification this would not be the preferred form. Now lets look at the raw frames. They took up approximately 300 MB of storage each, for a total of 144000 frames. That yields a total of around 43.2 terabytes. I think we can rule this out as the preferred form for the vast majority of modifications. So how about the compressed video stream? For some types of modifications such as creating a music video by syncing clips from the movie to music (Youtube is full of examples of this), this is probably the ideal form for modification. But it is not really useful for some types of modifications which may include introducing new characters, or major plot changes. So which one(s) should be considered source? Sincerely, Tacvek Source for Toy Story Statistics: http://www.sun.com/smi/Press/sunflash/1995-11/sunflash.951130.3411.xml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Choosing a license for Frets on Fire songs
In message [EMAIL PROTECTED], Andrew Donnellan [EMAIL PROTECTED] writes On 3/28/07, Matthew Johnson [EMAIL PROTECTED] wrote: Yes that's the contract you have to sign to be part of Teosto (which you have to do if you ever want to make a living in Finland as a musician). Ouch. As was indicated earlier this seems standard for all performance rights organisations. Sounds like an easy target for a restraint of trade action. Problem is, you need a guinea-pig, who would be gambling their career on it ... Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GPL v3 Draft 3- text and comments
The entire draft can be found at the end of the message. I belive some positive changes have been made, but some changes are for the worse. Here is my analysis of the license. This is more a general analysis, but I am trying to point out any DFSG-freeness problems I find. I have no real comments on the preamble. Copyright also means copyright-like laws that apply to other kinds of works, such as semiconductor masks. (from Section 0) I like this, but I'm not sure that it is not problematic. I am aware that Nintendo's official policy on ROMs (Dumps of the data contained in the ROM chip of a cartidge based game) is that they are not lawful, even if you both own the original, and are creating the ROM file yourself. They mention some sort of exception to the rules regarding media-shifting and backup/archival copying due to the games being stored on a chip in a cartrige. I'm guessing they are trying to claim that Mask Rights apply. They may be right if a user intends to create a new ROM chip containg the data, but if a computer file is the final destination, that seems highly unlikely. I'm guessing this clause intended to cover these sorts of claims with respect to GPL'ed software. It also clarifies that if a semiconductor mask design is what is being licenced, then Mask Rights are licenced just as Copyright is. No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures. (from Section 3) Trying to remove the US specific law refernce on this clause intended to defeat the concept of DCMA-like anti-circumvention rules only makes this harder to understand, and makes its purpose less clear. When you convey a covered work, you waive any legal power to forbid circumvention of technical measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technical measures. ( from section 3) That sentence is only a little less cryptic. Sure we understand what it is intended to mean, but what about other people unfamilar with the DMCA anti-circumvention rules. What would they think is being said? Section 4 (about verbatim source code copying) looks fine to me. I see not problems with it, except perhaps that the section title may be a bit misleading as it only applies to works in source form. The work must carry prominent notices stating that you modified it, and giving a relevant date. (from section 5) This is ok, but I'm not sure about the relevant date. Would the date I first thought about making the change be sufficient? (The date the change was made or published is presumeably what was intended). Section 5d (If the work has interactive user interfaces ...) is one I've never liked. I don't like the way it is worded currently. Especially the last sentence. The way it was stated in GPLv2 seemed clearer to me than this does. Section 6b says valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, That is an interesting concept. I suppose it is good. That is not a new change so I must have missed that change when it was first made. The new stuff at the end of section 6, about consumer products and Installation infromation is the new form of the TiVo clause, and is likely a DFSG--freeness minefeild. I'm not certain of that, but it seems big and complicated and consists almost entirely of completely new wording. This is one section that is important to look closely at. Section 7 Seems better, and far less problematic. Section 8 looks ok to me, but perhaps there is some freeness problem with it that I am not seeing. Section 11 may be tricky as it is covers patents. I would not be too suprised to find freness problems associated with this section. Section 13 is far better than the equivlent that was found in the previous section 7. I'm not a fan of the licence explicitly referencing that other licence, but it prevents Affero-covered code from being considered GNU-gpled. It is basically equivlent for our purposes to an additional permission that allows linking to a proprietary library. If used the complete work as a whole is non -free, but the GNU-GPL'ed part seperated is free, but may need to be in contrib it it depends on the Affero Code. (This is all based on the assumption that the affero V2 is considered DFSG-nonfree. If it is considered DFSG-free then this is not an issue at all.). My current conclusion is that I'm not seeing any DFSG-freeness problems. Some may still exist, and iif so likely exist witith the
Re: Choosing a license for Frets on Fire songs
2007/3/28, Andrew Donnellan [EMAIL PROTECTED] wrote: On 3/28/07, Matthew Johnson [EMAIL PROTECTED] wrote: Yes that's the contract you have to sign to be part of Teosto (which you have to do if you ever want to make a living in Finland as a musician). Ouch. As was indicated earlier this seems standard for all performance rights organisations. Does that include performance rights organizations in the United States? (I'm from Canada, and most of the pop music here is from U.S. artists.) Also, how about podsafe music (music liberally-enough licensed to be included in podcasts)? Are small indie artists who haven't entered into contracts with such organizations the only ones who can release music under podsafe licensing terms such as CC-BY-SA or CC-BY-NC-SA? If so: Are there any interest groups who are run lobbying campaigns against such strict rules? Cheers, Jason Note: I am not sending a cc to [EMAIL PROTECTED] this time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On Wed, 28 Mar 2007 14:01:02 -0400 Joe Smith wrote: Francesco Poli [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Exactly, and in some cases an author/maintainer *may* prefer to modify a lossy-compressed form directly. In some other cases, he/she *may* prefer working on uncompressed data and recompress afterward... Yes, I'm really starting to question the idea of source. It seems to me that the preferred form of modification seems to depend on the desired modification. It can change form after someone makes some kind of modifications (think of someone who automatically translates a Fortran program to C++ and then goes on modifying the C++ code: in that case the source form for the modified program is really C++ code!). But, as long as you consider the original work, there is one form which is preferred above the others, maybe because other suitable forms can be generated from it (in the example of the Fortran program, the source form for the original work is Fortran code: in case you want to make the modifications that makes you prefer the C++ form, you can always generate the latter from Fortran...). Since this is Debian, I will use the example of Toy Story. Let us say that Steve Jobs inexplicably decides he wants to release Toy Story as a open-source movie, and manages to convince the rest of the people at Disney that this was a good idea. It *is* a good idea, but this is another issue... ;-) Thinking about only the video portion, what would we call source? I can see three answers to this: 1. The model files, lighting, and animation information. This can be used to regenerate the movie. 2. The original raw frames of the rendered video. 3. The compressed final video stream. [...] So which one(s) should be considered source? I would prefer having the 3D models and related stuff and I guess the original authors would use that form, should they make modifications to the movie. Of course, for simple modifications, I could decide to use the compressed video stream: in those cases the source for the *modified* work might be the compressed video... I don't see any inconsistency in that. The fact that rebuilding Toy Story from source (that is, from 3D models) requires huge resources is a problem for the original authors too, and has little to do with source definition. Have you ever rebuilt the VTK library[1] on a 400 MHz Pentium II machine? I can say (from personal experience) that it takes quite a long time, but that doesn't mean that VTK source is not C++ code... [1] http://packages.debian.org/unstable/source/vtk -- http://frx.netsons.org/doc/nanodocs/etch_workstation_install.html Need to read a Debian etch installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpthI7t7o0qm.pgp Description: PGP signature
Re: Debian-approved creative/content license?
Joe Smith [EMAIL PROTECTED] writes: It seems to me that the preferred form of modification seems to depend on the desired modification. Yes. Though I keep advocating the GPL's definition of source, I recognise the ambiguity of preferred in that definition. Since this is Debian, I will use the example of Toy Story. ... Thinking about only the video portion, what would we call source? Whatever form is preferred for making modifications to the work. I can see three answers to this: 1. The model files, lighting, and animation information. This can be used to regenerate the movie. 2. The original raw frames of the rendered video. 3. The compressed final video stream. The closer we get to the original digital information, the less lossy the representation, so that should be preferentially selected; but for the reasons you give, I think each of these forms would reasonably satisfy a need for preferred form for making modifications. That to me indicates that for many types of modification [the original digital model representation] would not be the preferred form. So long as the software tools to render it are either freely available elsewhere or included in the source, the work can at least be ported to build on other hardware if necessary. I think this would be free. Now lets look at the raw frames. They took up approximately 300 MB of storage each, for a total of 144000 frames. That yields a total of around 43.2 terabytes. I think we can rule this out as the preferred form for the vast majority of modifications. I don't think this would present an issue for preferred form of the work for making modifications to it. It would limit the set of people who *choose* to acquire such a large work. So how about the compressed video stream? ... Again, some people would prefer this, others would not. So which one(s) should be considered source? I think the issues of different preferred form software formats for a video work is qualitatively similar to the issues of different languages for a program. The main difference is that some of these forms are lossy representations of an upstream form, whereas Turing-complete programming languages could conceivably each be translated to any other. -- \The number of UNIX installations has grown to 10, with more | `\ expected. -- Unix Programmer's Manual, 2nd Ed., 12-Jun-1972 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Choosing a license for Frets on Fire songs
Matthew Johnson [EMAIL PROTECTED] wrote: Yes that's the contract you have to sign to be part of Teosto (which you have to do if you ever want to make a living in Finland as a musician). Please, ask Finland's *legislators* if the situation there is really that anti-competitive closed shop. I've heard similar things before, but as I'm not much of a musician and negiotiated a cancellation on my book publishing contract, I've not had to look at these problems for myself. I suspect it is that bad (the EU approach to copyright is a wrong-headed protectionist one at present), but anyway it would be good to make legislators aware that there are creative people who are hindered by this. Monopoly collecting societies seem long overdue a reality check and a reminder that they should work for the composers/authors and not only the legacy publishers. If Teosto has a fundamental objection to releasing music as free software and Teosto approval is an essential requirement, then we either change Teosto or we change free software. I say change Teosto. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
Joe Smith [EMAIL PROTECTED] wrote: 1. The model files, lighting, and animation information. This can be used to regenerate the movie. 2. The original raw frames of the rendered video. 3. The compressed final video stream. [...] So which one(s) should be considered source? Obviously 1, but it may be helpful to distribute 2 or 3 for some purposes. Hope that helps, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
