Re: Debian-approved creative/content license?
On Wed, 2 May 2007 19:19:12 +0200 Michelle Konzack wrote: Am 2007-04-28 01:02:01, schrieb Francesco Poli: That is to say, IIUC, among project members only compressed videos are distributed. Yes, since how do you want to transfer several 100 Mbytes or some GBytes? per day and $MEMBER? To work on it the Uncompressed Videos are not neccesary for testing the Game and such. We include it at the end of a partial production. Hence, IIUC, the full modification of videos is the monopoly of a single person, even among the project members. This, IMHO, is an issue, independently of the free or proprietary nature of the project. In other words, it would be an issue even if the intent were writing a proprietary game. The desire to make the game DFSG-free (which is praiseworthy!) only makes the issue more visible, since many more people are legally entitled to make modifications to the work, and thus would like to get the source. [...] Should I contact the FSF about this special problem? I don't think the FSF feels strongly about the freeness of anything that is not a program. Quite the opposite, unfortunately (grinnn). :-/ ...but the Videos are parts of the program/game. Obviously enough, I agree that videos should *not* be held to different freeness standards than code, just because they are videos. But, unfortunately, the FSF leaders feel differently: I'm afraid that, if you contact the FSF, they will start an artistic works are not functional works line of reasoning, making contorted distinctions I disagree with (and hence I am not really qualified to describe in detail...). -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpYMS7zKjlCZ.pgp Description: PGP signature
Re: Debian-approved creative/content license?
Am 2007-04-28 01:02:01, schrieb Francesco Poli: That is to say, IIUC, among project members only compressed videos are distributed. Yes, since how do you want to transfer several 100 Mbytes or some GBytes? per day and $MEMBER? To work on it the Uncompressed Videos are not neccesary for testing the Game and such. We include it at the end of a partial production. And the source (uncompressed and uncut) videos are kept on a single machine by a single person (with backups I hope). :-) We have several Backups, Older HP-DAT with 24/48 GByte, DVD9 and now since some weeks 1 TByte HDD's. And no one else has a copy of the source videos?!? No redundancy, at all?!? We keep the Videos arround between members but since the whole (source) game is stored on this machine, it is better for working. Should I contact the FSF about this special problem? I don't think the FSF feels strongly about the freeness of anything that is not a program. Quite the opposite, unfortunately (grinnn). :-/ ...but the Videos are parts of the program/game. Note: I have seen, there will be an equivalent commercial game out there and now it is realy weird situation, since the commercial one is realy eauivalent and if we make our GNU/Game public, they could tell us we have stolen there Idea... But this can not be, since the game is mostly my ancien live @LEF. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Debian-approved creative/content license?
Sorry if you get this Message twice, but my Previously messages does not appear in the archives and it seems to be lost... Am 2007-04-11 00:24:19, schrieb Francesco Poli: So, IIUC, ready-to-use videos are created by extracting and compressing appropriate sequences of the original uncompressed videos. The original uncompressed form is kept in case some modifications are needed. This really seems to mean that the original uncompressed form is actually the source form. This is right. The extraction/compression process is automated via Makefiles: this is good and really helpful. Since some Video seauences are overlaping, distributing each singel Video alone wold increase the size... So, you seem to have a problem with big sources. The problem lies in the technical difficulties that arise when you want to distribute the complete source of the game (that includes the big uncompressed videos). Right, However, I suppose the problem is not only in *public* distribution. How do you handle the problem when you want to perform distribution of video source *inside* the project? The (my) server is in Offenburg/Germany and it has 7.2 TByte availlable. (30 x SCSI 300 GByte) and sitting only on a E1 (1.92 MBit). I mean: I hope those source videos are kept by *more* than one single project member! Otherwise your game project has a really low bus number (equal to 1, as far as videos are concerned!). How do you copy a big uncompressed video to other project members? The whole bunch of videos exist in 1/4 size and with 90% compression. So if someone need a new Video-Sequence they take the compressed one as template and then the real one will be generated... This works directly like a buildd (you send the config directly to the buildd) which put the resulting video (produced from) the original as high compressed one in the $HOME of the user. He/She can review it and then send a command to make the Real-Video. This is unfortunate, as it poses downstream recipients in a position of disadvantage with respect to upstream maintainers. Should I contact the FSF about this special problem? Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Debian-approved creative/content license?
On Fri, 27 Apr 2007 19:15:51 +0200 Michelle Konzack wrote: Sorry if you get this Message twice, but my Previously messages does not appear in the archives and it seems to be lost... No problem, actually I've never received any other response... Am 2007-04-11 00:24:19, schrieb Francesco Poli: [...] I mean: I hope those source videos are kept by *more* than one single project member! Otherwise your game project has a really low bus number (equal to 1, as far as videos are concerned!). How do you copy a big uncompressed video to other project members? The whole bunch of videos exist in 1/4 size and with 90% compression. So if someone need a new Video-Sequence they take the compressed one as template and then the real one will be generated... This works directly like a buildd (you send the config directly to the buildd) which put the resulting video (produced from) the original as high compressed one in the $HOME of the user. He/She can review it and then send a command to make the Real-Video. That is to say, IIUC, among project members only compressed videos are distributed. And the source (uncompressed and uncut) videos are kept on a single machine by a single person (with backups I hope). And no one else has a copy of the source videos?!? No redundancy, at all?!? This is unfortunate, as it poses downstream recipients in a position of disadvantage with respect to upstream maintainers. Should I contact the FSF about this special problem? I don't think the FSF feels strongly about the freeness of anything that is not a program. Quite the opposite, unfortunately (grinnn). -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpAWnrbQ8m24.pgp Description: PGP signature
Re: Debian-approved creative/content license?
Am 2007-04-04 22:30:45, schrieb Francesco Poli: On Wed, 4 Apr 2007 20:01:02 +0200 Michelle Konzack wrote: [...] And currently I create some new weapons but the source of sunburn for example is around 70 MBytes including the sound effects plus a real Video of 480 MByte as source which will be converted to a OGM to around 30 MByte. I'm not sure I quite understand what you mean: are you referring to the game project you're currently contributing to? What's that 30 Mbyte quantity? Could you explain a little more clearly? The sources of the Videos are all around 300-600 MByte and the end products binary are only environement 30 MByte ogm files. We keep the original Videos in case, we need new scenes or such which can create/extracted from the original video sources. The OGM's are create while building the End-Procuct from the make files. Extracting and resizing only sniplets from original, which mean, each Source-Video is several times used. Since I have asked, I have gotten a handfull E-Mails from peoples/enterprises having the same problem... IN CLEAR: For us, hobby or professional (high auality) game programmer the sources are in high quality for reusage since resizing does not match our needs and compressing brings to high losses. It seems, nobody was realy thinking about distributing the sources of Action/Stratigiggames which includes Video-Sequences under GPL. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Debian-approved creative/content license?
On Tue, 10 Apr 2007 17:48:52 +0200 Michelle Konzack wrote: Am 2007-04-04 22:30:45, schrieb Francesco Poli: [...] I'm not sure I quite understand what you mean: are you referring to the game project you're currently contributing to? What's that 30 Mbyte quantity? Could you explain a little more clearly? The sources of the Videos are all around 300-600 MByte and the end products binary are only environement 30 MByte ogm files. We keep the original Videos in case, we need new scenes or such which can create/extracted from the original video sources. So, IIUC, ready-to-use videos are created by extracting and compressing appropriate sequences of the original uncompressed videos. The original uncompressed form is kept in case some modifications are needed. This really seems to mean that the original uncompressed form is actually the source form. The OGM's are create while building the End-Procuct from the make files. Extracting and resizing only sniplets from original, which mean, each Source-Video is several times used. The extraction/compression process is automated via Makefiles: this is good and really helpful. Since I have asked, I have gotten a handfull E-Mails from peoples/enterprises having the same problem... So, you seem to have a problem with big sources. The problem lies in the technical difficulties that arise when you want to distribute the complete source of the game (that includes the big uncompressed videos). However, I suppose the problem is not only in *public* distribution. How do you handle the problem when you want to perform distribution of video source *inside* the project? I mean: I hope those source videos are kept by *more* than one single project member! Otherwise your game project has a really low bus number (equal to 1, as far as videos are concerned!). How do you copy a big uncompressed video to other project members? IN CLEAR: For us, hobby or professional (high auality) game programmer the sources are in high quality for reusage since resizing does not match our needs and compressing brings to high losses. It seems, nobody was realy thinking about distributing the sources of Action/Stratigiggames which includes Video-Sequences under GPL. This is unfortunate, as it poses downstream recipients in a position of disadvantage with respect to upstream maintainers. -- 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 pgpyTCYmAWuOR.pgp Description: PGP signature
Re: Debian-approved creative/content license?
Am 2007-03-28 01:18:32, schrieb Ying-Chun Liu (PaulLiu): Lossless and lossy compression format don't mean anything on preferred form for modification. Some recorders do record mp3/ogg directly. And some audio editors do edit mp3/ogg directly. And many of the authors of the audio works don't know the difference between mp3 and wav and flac. By ears, there's no difference between mp3 and wav, thus they may create I do not know, what ears you have but IF I edit a mp3 of 128kBit directly with the same methods I edit a shn file, I can hear the difference. (I know many peoples from LAD/LAU which can hear it) I think, all peoples with feeling for classic can it. My prefered ones are wav but distributing aound 2 hours of sound sources will fill 1 1/2 CD's, maybe one since wav can be good compressed. So, for creative works, the source is hard to be defined by format. 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. 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. OK, but will be Debian be willing, to distribute a 100% GPL 2.0 Game of (I think)currently 78 binaries of 500 MByte in summary plus over 3 GByte of sources? Which mean, this game need a CD for its own and a DVD to distribute the Source... And currently I create some new weapons but the source of sunburn for example is around 70 MBytes including the sound effects plus a real Video of 480 MByte as source which will be converted to a OGM to around 30 MByte. I have already managed that the DEMO videos of the Weapons are in seperated Debian-Packages... so no one must download 800 MByte extras. Note: It is a action/strategic game like Fleet Command with real existing weapons and conflicts... I do not know, when it will be ready, since we have performance problems and to many bugs and crashes. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Debian-approved creative/content license?
Am 2007-03-28 01:00:13, schrieb Francesco Poli: On Wed, 28 Mar 2007 01:18:32 +0800 Ying-Chun Liu (PaulLiu) wrote: To require the author to use some listed formats for image source or audio source is impracticable. Indeed! Because what is source for a work, can be a compiled form for another one, and so forth... But since we want to create a fully GPL 2.0 compliant game which can be 100% distributed, we (the creators; I am military adviser for weapons in this project) should care about the distribution of the source code which mean, DEBIAN is our mesurement! IF Debian tell us, a source of at least 3 GByte (increasing) is not distributable because resource limits, then we should change something in our work... Otherwise, IF Debian say: OK, we can distribute it, but we put the BINARIES on 1-2 seperated CD's and the SOURCE on a seperated DVD.; then it would be OK to leave it as it is! Please advise me. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Debian-approved creative/content license?
On Wed, 4 Apr 2007 20:01:02 +0200 Michelle Konzack wrote: [...] And currently I create some new weapons but the source of sunburn for example is around 70 MBytes including the sound effects plus a real Video of 480 MByte as source which will be converted to a OGM to around 30 MByte. I'm not sure I quite understand what you mean: are you referring to the game project you're currently contributing to? What's that 30 Mbyte quantity? Could you explain a little more clearly? -- 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 pgpH5xoZpERTh.pgp Description: PGP signature
Re: Debian-approved creative/content license?
Terry Hancock [EMAIL PROTECTED] writes: The true distinction is between aesthetic works, meaning works which are valued for themselves (i.e. you sensually appreciate the work in one form or another) and utilitarian works, meaning works whose principle value is in how they are used. That's a disctinction which may be interesting (certainly it's more interesting than creative/non-creative). However, it's a distionction which can only apply to the combination of a work *and* a person appreciating it *and* the time at which they are appreciating. If any of those change, the distinction can also change. So it's not valid to make the distinction depend *solely* on the work. Since a free license applies *only* to a work (i.e. it does not distinguish based on who is receiving the work nor when they do so), it's not a useful distinction to make between the types of licensing required for different works. -- \ Some forms of reality are so horrible we refuse to face them, | `\ unless we are trapped into it by comedy. To label any subject | _o__) unsuitable for comedy is to admit defeat. -- Peter Sellers | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
Ben Finney wrote: 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. The true distinction is between aesthetic works, meaning works which are valued for themselves (i.e. you sensually appreciate the work in one form or another) and utilitarian works, meaning works whose principle value is in how they are used. If the principle value of gcc were its aesthetic appeal (e.g. you like to wallpaper your room with the printout), then it's the same as an aesthetic work like a movie or a song. However, almost no one views gcc that way. It's principle value is *use*: i.e. you compile programs with it. By contrast, there are almost no such uses of a movie or a song. They are meant to be rendered to the human senses and appreciated for their own content. This is a real distinction. In licensing terms, the difference is important, because it strongly effects the model of how the software will be created and also how it affects the consumer/user of it. Furthermore, the potential for and value of reuse is quite different. For aesthetic works, re-use is always non-essential, but individual instances are irreplaceable. A parody of Mickey Mouse, for example, has no meaning if it can only exist as a parody of Rudy Rat (some off-brand character created to avoid infringing on Disney's trademarks and copyrights on Mickey). Restricting the parody of the original therefore is directly muzzling freedom of expression. This is distinct from the case of compilers, for example: any compiler than can compile C source code is roughly exchangeable with any other (yes I know there are some incompatibilities -- but the point is that they can always be fixed if there is a desire to do so). The existence of a non-free compiler does not prevent the creation of a free one to replace it. Yet, it can be argued that you do not *need* that parody in the same way that you might need a compiler (not having the aesthetic work does not restrict your abilities to act). So, you can always choose to live without aesthetic works, without being materially damaged, but you are always culturally damaged by that choice, whereas the inability to access utilitarian works only implies the need to create free ones, and has little or no cultural consequences. It's a small step from there to realizing that freedom means something different for aesthetic versus utilitarian works. In fact, free licensing is an adequate solution for utilitarian works, but in the end, only better copyright law can fully resolve the problem for aesthetic works. Nevertheless, the needs of licenses for aesthetic works are necessarily different than those for utilitarian works. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On Thu, 29 Mar 2007, Terry Hancock wrote: The true distinction is between aesthetic works, meaning works which are valued for themselves (i.e. you sensually appreciate the work in one form or another) and utilitarian works, meaning works whose principle value is in how they are used. If the principle value of gcc were its aesthetic appeal (e.g. you like to wallpaper your room with the printout), then it's the same as an aesthetic work like a movie or a song. By contrast, there are almost no such uses of a movie or a song. They are meant to be rendered to the human senses and appreciated for their own content. This is a real distinction. Except that it's not. There is no hard delineation between utilitarian works and aesthetic works. If I have no use for gcc's utilitarian role, and find it aesthetically pleasing for whatever reason, that's as valid as your purely utilitarian role for it. Likewise there are many utilitarian uses for movies or songs. I know of many movies that I've watched and songs which I have listened to which have altered the way I think or feel about specific subjects. They were designed in no small part to have exactly that effect upon people. You are traversing the same argument as litigation on pornography versus art has traversed, which ultimately terminates in the handwaving I know it when I see it or the even less penetrable what the artist says it is. When is a urinal not a urinal? the inability to access utilitarian works only implies the need to create free ones, and has little or no cultural consequences. I would think that Debian itself not existing would be a profound cultural consequence to most of us participating on this list. In fact, free licensing is an adequate solution for utilitarian works, but in the end, only better copyright law can fully resolve the problem for aesthetic works. Why? More importantly, what does this have to do with the works that we distribute within Debian? If a work is actually being distributed within Debian, then I submit that it must fill some sort of utilitarian role. Something must use it in order to produce some functionality or appearance. If it doesn't, then it has no business bloating the archive and being distributed by our mirror network. If that's the case, then we must be able to take the work, modify it, and redistribute it in order to enable our users to do what they need to do. If the copyright holder is withholding information that could be theoretically distributed by us which is necessary to modify the work, then we are not able to execute the tenets of our social contract. Don Armstrong -- Dropping non-free would set us back at least, what, 300 packages? It'd take MONTHS to make up the difference, and meanwhile Debian users will be fleeing to SLACKWARE. And what about SHAREHOLDER VALUE? -- Matt Zimmerman in [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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: 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: 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: 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]
Re: Debian-approved creative/content license?
Am 2007-03-11 12:14:09, schrieb Francesco Poli: On Sun, 11 Mar 2007 15:01:30 +1100 Ben Finney wrote: Even the GPL terms could be used, so long as it's clear what the preferred form of the work for making modifications to it means for that work. Agreed, with the addition that, IMHO, the preferred form of the work for making modifications to it is always well-defined (even though sometimes it may be non-trivial to determine). Hence, I would recommend the GNU GPL (v2) whenever one wants a copyleft. I personaly consider mp3/mp4 and ogg (vorbis, theora, ...) NOT as the preferred form of the work for making modifications to it. I asume, that there are nore then one person on the list aggree with me. So whats the prefered form of source. For mp3 and ogg-vorbis it can be wav, flac or shn but what about videos? I have a Video splited in singel bitmaps, which mena 25 images per second and I do not know, whether this can be the desired form of distribution since a short video of ONE second (512x384/24) would be 14 MByte as bitmaps which is by a little bit larger videos undesirable since it exceed any logical distribution limits. Please note, that I am talking about some embedded Videos in games and equivalent stuff... since I know, that there is a game (GPL v2) which can fill without any problems an entired DVD (4.2 GByte) with it sourcecode if distributed as bitmaps... otherwise 1-2 CD's. The Game without the Videos is definitivly useless. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Debian-approved creative/content license?
Michelle Konzack wrote: Am 2007-03-11 12:14:09, schrieb Francesco Poli: On Sun, 11 Mar 2007 15:01:30 +1100 Ben Finney wrote: Even the GPL terms could be used, so long as it's clear what the preferred form of the work for making modifications to it means for that work. Agreed, with the addition that, IMHO, the preferred form of the work for making modifications to it is always well-defined (even though sometimes it may be non-trivial to determine). Hence, I would recommend the GNU GPL (v2) whenever one wants a copyleft. I personaly consider mp3/mp4 and ogg (vorbis, theora, ...) NOT as the preferred form of the work for making modifications to it. I asume, that there are nore then one person on the list aggree with me. So whats the prefered form of source. For mp3 and ogg-vorbis it can be wav, flac or shn but what about videos? Lossless and lossy compression format don't mean anything on preferred form for modification. Some recorders do record mp3/ogg directly. And some audio editors do edit mp3/ogg directly. And many of the authors of the audio works don't know the difference between mp3 and wav and flac. By ears, there's no difference between mp3 and wav, thus they may create mp3 directly, or convert the wav to mp3 like put something into zip file and then delete the useless wav. So, for creative works, the source is hard to be defined by format. 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. 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. Regards, Ying-Chun Liu -- PaulLiu(Ying-Chun Liu) E-mail address: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: Debian-approved creative/content license?
On Wed, 28 Mar 2007 01:18:32 +0800 Ying-Chun Liu (PaulLiu) wrote: Michelle Konzack wrote: [...] I personaly consider mp3/mp4 and ogg (vorbis, theora, ...) NOT as the preferred form of the work for making modifications to it. I asume, that there are nore then one person on the list aggree with me. I do not agree. In some cases an OGG file may be the preferred form for making modifications to a work (and hence, by definition, its source form). In other cases, it won't. There's no general rule that states which formats are source and which ones are not. It's not a matter of formats: it's a case-by-case choice. So whats the prefered form of source. It depends. I cannot answer *in general*. For mp3 and ogg-vorbis it can be wav, flac or shn but what about videos? Lossless and lossy compression format don't mean anything on preferred form for modification. Some recorders do record mp3/ogg directly. And some audio editors do edit mp3/ogg directly. 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... [...] So, for creative works, Be careful: every copyrighted work is a creative work (just because, roughly speaking, copyright covers the expressions of creativity). Hence programs are creative works, as well, while you seem to think otherwise... the source is hard to be defined by format. Not like programs, we can easily know what is machine code and what is high level language code in most situations. Source code for programs is not always so easily determined as you argue: for instance, imagine a programmer who modifies Perl code, but strips out *all the comments* before distributing the code. The commented Perl code is clearly his/her preferred form for modifications, and hence source code; what gets distributed is instead obfuscated code, which is *not* source. And we could never really know, if he/she publicly claims to modify the uncommented code, while he/she instead modifies the commented code and keeps it secret... In some cases, a programmer may modify machine code by hand. Then, machine code is source code for that work. Of course, more often, machine code is compiled from some higher level language... 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. That is true for programs too. Oh well, programs are creative works, hence you already acknowledged this... ;-) If the last format he has is wav, then he should release wav. If the last format he has is mp3, then mp3. I'm not sure what you mean by last format. The point is the preferred form for modifications, and it can be a WAV file or an MP3, or something else, depending on the work we are talking about. As I stated, there's no general rule. [...] To require the author to use some listed formats for image source or audio source is impracticable. Indeed! Because what is source for a work, can be a compiled form for another one, and so forth... -- 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 pgpTT5o4o0RK1.pgp Description: PGP signature
Re: Debian-approved creative/content license?
Francesco Poli escribe: P.S.: Please do not reply to me, Cc:ing the list, as I didn't asked you to do so. I am a debian-legal subscriber and would rather avoid receiving the same message twice. Reply to the list only (as long as you want to send a public response). See http://www.debian.org/MailingLists/#codeofconduct I know about the code of conduct, I am deeply sorry. I am looking for a mutt config that works the same on 1.5 running on Linux and on 1.4 running over Cygwin on Windows. Sometimes keystrokes don't do what they're expected to. :) Sorry again. And again. Cordially, Ismael -- Ismael Valladolid Torres m. +34679156321 La media hostia j. [EMAIL PROTECTED] http://lamediahostia.blogspot.com/ signature.asc Description: Digital signature
Re: Debian-approved creative/content license?
* Ismael Valladolid Torres [EMAIL PROTECTED] [070313 10:55]: In the case of artistic creation it also happens that one can't tell where source ends. Take as an example a photography. The source of the photography involves the place where it was taken. But not only, it also involves the daylight the picture was taken with, the people passing by, why not also the inspiration of the photographer. That does not differ that much from programing. The actual code is seldom the ultimate origin (to avoid the term source here) of it. Though noone wants the napkin with the design written on it, or the editor contributing the formating by autoindenting to be distributed as part of the source. Nor the documents and standards (or even the reference book descriping your language and interfaces) read while writing it. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On Thu, 15 Mar 2007 10:22:14 +0100 Ismael Valladolid Torres wrote: Francesco Poli escribe: P.S.: Please do not reply to me, Cc:ing the list, as I didn't asked you to do so. I am a debian-legal subscriber and would rather avoid receiving the same message twice. Reply to the list only (as long as you want to send a public response). See http://www.debian.org/MailingLists/#codeofconduct I know about the code of conduct, I am deeply sorry. That's OK, do not worry. :-) I am looking for a mutt config that works the same on 1.5 running on Linux and on 1.4 running over Cygwin on Windows. Sometimes keystrokes don't do what they're expected to. :) Unfortunately I'm not a Mutt guru, so I cannot help (and anyway not on this list, as it would be really off topic... try and ask for suggestions on some technical list!) Sorry again. And again. Apologies accepted, no problems! -- 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 pgpjHolqiuDfl.pgp Description: PGP signature
Re: Debian-approved creative/content license?
Francesco Poli escribe: The preferred form for making modifications does *not* imply that there's no other form (more or less) suitable for modifying the work. It just means that the source is the *preferred* one... People may and do modify compiled programs using hex editors and/or disassemblers or decompilers, without having access to source code (think about the so-called warez dudes that strip anti-copy mechanisms from proprietary programs, for instance). That *doesn't* mean that the compiled form is (always) the preferred form for modifications: in most cases, those people would rather have access to C code (for programs written in C), instead of being forced to edit the compiled binary! It's perfectly clear, thanks! signature.asc Description: Digital signature
Re: Debian-approved creative/content license?
MJ Ray escribe: Both of the situations are biased - each person will probably think their preferred occupation is more creative or worthwhile. If they thought otherwise, they'd probably be doing the other task. Why is this news to anyone? With the difference that the programmer needs what he's programming to *work* according to a suite of specs. Meanwhile the artist doesn't need anything to *work* in any physical way. So yes programming is more or less creative but creativity in programming has clear limits. Cordially, Ismael -- Ismael Valladolid Torres m. +34679156321 La media hostia j. [EMAIL PROTECTED] http://lamediahostia.blogspot.com/ signature.asc Description: Digital signature
Re: Debian-approved creative/content license?
On Wed, 14 Mar 2007, Ismael Valladolid Torres wrote: MJ Ray escribe: Both of the situations are biased - each person will probably think their preferred occupation is more creative or worthwhile. If they thought otherwise, they'd probably be doing the other task. Why is this news to anyone? With the difference that the programmer needs what he's programming to *work* according to a suite of specs. Specifications are not an intrinsic part of programming any more than they are in painting. I suggest reading _The Tao of Programming_. Don Armstrong -- I shall require that [a scientific system's] logical form shall be such that it can be singled out, by means of emperical tests, in a negative sense: it must be possible for an emperical scientific system to be refuted by experience. -- Sir Karl Popper _Logic of Scientific Discovery_ §6 http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Debian-approved creative/content license?
Ismael Valladolid Torres [EMAIL PROTECTED] wrote: With the difference that the programmer needs what he's programming to *work* according to a suite of specs. Meanwhile the artist doesn't need anything to *work* in any physical way. So yes programming is more or less creative but creativity in programming has clear limits. That is true for some programmers working to spec, but it is true for some photographers working to spec, or copywriters working to spec (such as, the client requires a particular type of image or text for an ad campaign). Other times, programmers and photographers are just making it up without any limits. If one's working to spec, creativity has clear limits. This isn't massively different across occupations. Regards, -- 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?
On 3/13/07, Marco d'Itri [EMAIL PROTECTED] wrote: Actually I understand that the ftpmasters have approved content licensed under CC 3.0 I assume you mean that CC-licensed content has been accepted into main. Could you please give some examples of packages where this is the case? Cheers, -- Andrew Saunders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On Wed, 14 Mar 2007 11:03:52 +0100 Ismael Valladolid Torres wrote: Francesco Poli escribe: The preferred form for making modifications does *not* imply that there's no other form (more or less) suitable for modifying the work. It just means that the source is the *preferred* one... [...] It's perfectly clear, thanks! You're welcome.:-) P.S.: Please do not reply to me, Cc:ing the list, as I didn't asked you to do so. I am a debian-legal subscriber and would rather avoid receiving the same message twice. Reply to the list only (as long as you want to send a public response). See http://www.debian.org/MailingLists/#codeofconduct -- 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 pgpPFPYxJUoce.pgp Description: PGP signature
Re: Debian-approved creative/content license?
On Mon, 12 Mar 2007, Francesco Poli wrote: Anyway, whenever some form of a work is the preferred one for modifications (i.e.: source form), but, at the same time, is inconvenient to distribute, well, the work is inconvenient to distribute in a Free manner! This is an unfortunate technical obstacle to freeing works and should be removed by technology improvements: we should not surrender and lower our freeness standards in order to accept sourceless works as if they were Free. That's not a technical obstacle, that's a we're stupid to recommend that the author do something horribly inconvenient obstacle. If the work is inconvenient to distribute free, then we should be telling the author distributing it free is probably not what you want to do. Besides, the DFSG don't define source code as the preferred form for modification. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
Ken Arromdee escribe: This means that there are many content creators who don't want to release source, not because they want to restrict their users, but because they don't think the hassle is worth it--it's a much greater hassle for a much smaller benefit, than releasing the source of a program. Indeed, it's much more likely the author might not even realize that the GPL requires his raw video or audio files. In the case of artistic creation it also happens that one can't tell where source ends. Take as an example a photography. The source of the photography involves the place where it was taken. But not only, it also involves the daylight the picture was taken with, the people passing by, why not also the inspiration of the photographer. I insist, artistic creations can't use the same licenses as documentation or software. The effort must focus on make artistic licenses and other ones as compatible as posible. This seems obvious to me. Cordially, Ismael -- Ismael Valladolid Torres m. +34679156321 La media hostia j. [EMAIL PROTECTED] http://lamediahostia.blogspot.com/ signature.asc Description: Digital signature
Re: Debian-approved creative/content license?
Ismael Valladolid Torres [EMAIL PROTECTED] writes: In the case of artistic creation Careful. This doesn't distinguish programs from other intellectual creations; there is a huge amount of artistry in programming. it also happens that one can't tell where source ends. Which is why the GPL's definition is useful: the preferred form of the work for making modifications to it. That's not binding upon interpretations of the DFSG, nor is it immune to conflicting interpretations, but it's pretty good. Take as an example a photography. The source of the photography involves the place where it was taken. But not only, it also involves the daylight the picture was taken with, the people passing by, why not also the inspiration of the photographer. Sure, if we refuse to define source then ipso facto we can't tell what it applies to. If, instead, we *define* the source of the work so that it's as the GPL defines it, then all these impossible-to-provide environmental factors you cite are not required. All that's required to meet source is the preferred form of the work for making modifications. I insist, artistic creations can't use the same licenses as documentation or software. Programs, documentation, data, audio and images do not have clear dividing lines. They can all be represented digitally, they can all be interpreted in different categories depending on the need. What they all share is that they can all be covered by copyright, and thus licensed. I recommend that such a license not be restricted to a particular field of endeavour. I insist that if we believe freedoms are required in digitally-stored information (i.e. software), it doesn't matter what ephemeral interpretation is placed upon that information: the same freedoms should apply to all recipients of that work, for any purpose, or the work is not licensed under free terms. The effort must focus on make artistic licenses and other ones as compatible as posible. This seems obvious to me. Here we agree. I think all free licenses should be compatible, to allow maximum freedom of creativity and sharing in the work. -- \ I was married by a judge. I should have asked for a jury. -- | `\ Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
Ben Finney escribe: Careful. This doesn't distinguish programs from other intellectual creations; there is a huge amount of artistry in programming. Sure from a programmer's point of view, but just ask an artist who knows something about programming which amount or artistry is there in each one of the activities. Sure, if we refuse to define source then ipso facto we can't tell what it applies to. I agree with this. If, instead, we *define* the source of the work so that it's as the GPL defines it, then all these impossible-to-provide environmental factors you cite are not required. All that's required to meet source is the preferred form of the work for making modifications. Again I agree but there exists sampling which is a way for making modifications of existing material without the need of source. Just think about collage... Programs, documentation, data, audio and images do not have clear dividing lines. They can all be represented digitally, they can all be interpreted in different categories depending on the need. But artistry can't be represented digitally so that's the bleeding edge where efforts should stop. What they all share is that they can all be covered by copyright, and thus licensed. I recommend that such a license not be restricted to a particular field of endeavour. Again more or less I agree. Here we agree. I think all free licenses should be compatible, to allow maximum freedom of creativity and sharing in the work. Cordially, Ismael -- Ismael Valladolid Torres m. +34679156321 La media hostia j. [EMAIL PROTECTED] http://lamediahostia.blogspot.com/ signature.asc Description: Digital signature
Re: Debian-approved creative/content license?
On Tue, 13 Mar 2007 10:54:33 +0100 Ismael Valladolid Torres wrote: [...] In the case of artistic creation it also happens that one can't tell where source ends. Take as an example a photography. The source of the photography involves the place where it was taken. But not only, it also involves the daylight the picture was taken with, the people passing by, why not also the inspiration of the photographer. You're talking about the *means and objects* preferred for *retaking* the photo from scratch. The source is instead the preferred *form* (of the photo) for making *modifications* to it. The place where a photo was taken is *not* a form of the photo! Nor are the people passing by! In most cases, source for a photo is the form in which it is downloaded from the digital camera; or some other format, if one prefers using that format in order to modify the image... The key word is modify, not recreate from scratch. I insist, artistic creations can't use the same licenses as documentation or software. [...] I disagree: any software work[1] can be released under the terms of well-drafted licenses (such as the GNU GPL v2, the Expat/MIT license, ...). [1] I use the term software in its broadest meaning, see http://frx.netsons.org/essays/softfrdm/whatissoftware.html -- 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 pgpsRHnqvgsze.pgp Description: PGP signature
Re: Debian-approved creative/content license?
On Tue, 13 Mar 2007 13:50:16 +0100 Ismael Valladolid Torres wrote: Ben Finney escribe: [...] If, instead, we *define* the source of the work so that it's as the GPL defines it, then all these impossible-to-provide environmental factors you cite are not required. All that's required to meet source is the preferred form of the work for making modifications. Again I agree but there exists sampling which is a way for making modifications of existing material without the need of source. Just think about collage... The preferred form for making modifications does *not* imply that there's no other form (more or less) suitable for modifying the work. It just means that the source is the *preferred* one... People may and do modify compiled programs using hex editors and/or disassemblers or decompilers, without having access to source code (think about the so-called warez dudes that strip anti-copy mechanisms from proprietary programs, for instance). That *doesn't* mean that the compiled form is (always) the preferred form for modifications: in most cases, those people would rather have access to C code (for programs written in C), instead of being forced to edit the compiled binary! -- 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 pgpdHl2jYnNXZ.pgp Description: PGP signature
Re: Debian-approved creative/content license?
On Tue, 13 Mar 2007 00:51:55 -0700 (PDT) Ken Arromdee wrote: On Mon, 12 Mar 2007, Francesco Poli wrote: Anyway, whenever some form of a work is the preferred one for modifications (i.e.: source form), but, at the same time, is inconvenient to distribute, well, the work is inconvenient to distribute in a Free manner! This is an unfortunate technical obstacle to freeing works and should be removed by technology improvements: we should not surrender and lower our freeness standards in order to accept sourceless works as if they were Free. That's not a technical obstacle, that's a we're stupid to recommend that the author do something horribly inconvenient obstacle. Maybe we are stupid to promote Free Software, then... I prefer being a stupid Free Software supporter, than being a smart proprietary software advocate. If the work is inconvenient to distribute free, then we should be telling the author distributing it free is probably not what you want to do. I don't think the Debian Project (or debian-legal contributors) should promote non-free software. Besides, the DFSG don't define source code as the preferred form for modification. I am not aware of any better and more widely accepted definition. -- 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 pgpnyAHeeplGg.pgp Description: PGP signature
Re: Debian-approved creative/content license?
On Tue, 13 Mar 2007, Francesco Poli wrote: If the work is inconvenient to distribute free, then we should be telling the author distributing it free is probably not what you want to do. I don't think the Debian Project (or debian-legal contributors) should promote non-free software. On the other hand, I think even Debian should try to be truthful. If Free for audio and video is so awkward that an author who asks for a free license probably doesn't want one, then we should tell the author this is what it means; you probably don't want one. Not saying that when you know very well it's true be lying by omission. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
Please don't send copies of list messages to me via email, I didn't ask for them and it's annoying to receive them. Please follow URL:http://www.debian.org/MailingLists/#codeofconduct. Ismael Valladolid Torres [EMAIL PROTECTED] writes: Ben Finney escribe: Careful. This doesn't distinguish programs from other intellectual creations; there is a huge amount of artistry in programming. Sure from a programmer's point of view, but just ask an artist who knows something about programming which amount or artistry is there in each one of the activities. Then, since you agree there is artistry in programming, and I didn't make any comparison of which has more artistry, I ask you to stop presenting artistic as if it's a property that doesn't apply, or applies only insignificantly, to programs. All that's required to meet source [for a non-program work] is the preferred form of the work for making modifications. Again I agree but there exists sampling which is a way for making modifications of existing material without the need of source. Just think about collage... I don't see your point here. Such activity would also be permitted under a free license, but the freedom to make *only* those types of changes would not be sufficient to call the license free. Programs, documentation, data, audio and images do not have clear dividing lines. They can all be represented digitally, they can all be interpreted in different categories depending on the need. But artistry can't be represented digitally so that's the bleeding edge where efforts should stop. No one is attempting to encode artistry digitally and distribute it in Debian. Artistic software works, however, have *always* been distributed by Debian. Some of them are programs, some are documentation, some are data; some are several categories simultaneously, or at different times. All of them need to be licensed freely to be included in Debian. -- \ I was born by Caesarian section. But not so you'd notice. It's | `\just that when I leave a house, I go out through the window. | _o__) -- Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
[EMAIL PROTECTED] wrote: I've read up and found the Creative Commons and GFDL licenses are specifically disallowed by Debian (well GFDL with non-invariant Actually I understand that the ftpmasters have approved content licensed under CC 3.0, which is widely considered to be free (one of the obviously free licenses, not a -NC one), and this defines what is considered free software by Debian. sections seems ok, but does that make sense for creative/audio content?). Looking further, I could not find any Debian-approved licenses for creative (non-software) works [2], [3]. Is the Debian approach to just use a software license like GPL or BSD for creative content? Debian as an organization has no official position about this, but you will find that many regular debian-legal@ contributors share this opinion. (But then, the opinion of these people are rarely considered balanced.) Anyway, what recommendation should I make that will satisfy the DFSG? Use CC. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On Sun, 11 Mar 2007, Don Armstrong wrote: If the original author puts a video under GPL and doesn't release the source, you can't demand it. He's not bound by the GPL since he can't violate the copyright on his own work, so he has no obligation to give you anything. This is the same problem that exists for any work under the GPL; there's nothing special about recordings here. The difference with recordings is that it's much more plausible that the author would do this. Video source is more awkward than program source, and video binaries are more useful than program binaries. This means that there are many content creators who don't want to release source, not because they want to restrict their users, but because they don't think the hassle is worth it--it's a much greater hassle for a much smaller benefit, than releasing the source of a program. Indeed, it's much more likely the author might not even realize that the GPL requires his raw video or audio files. So yes, the same problem *can* exist for any work, but the special circumstances of media files make it much more likely. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On Sun, 11 Mar 2007 21:02:30 -0700 (PDT) Ken Arromdee wrote: On Sun, 11 Mar 2007, Francesco Poli wrote: In order to release the audio/video recording in a DFSG-free manner, they should release the source as well, as defined in the GNU GPL v2. Wonderful! That is a feature of the GPL, not a bug! Recipients should not be in a position of disadvantage with respect to original authors, or otherwise it's not really Free Software. It's a bug. If the original author puts a video under GPL and doesn't release the source, you can't demand it. Of course I cannot. The same holds for programs, and for any other work of authorship, though. He's not bound by the GPL since he can't violate the copyright on his own work, so he has no obligation to give you anything. This is *not* a bug in the license. If you really want to see it as a bug, it's a bug in copyright laws (one of the maaanyy bugs!). So the result is that you can't demand source and can't distribute the work either. That doesn't give free software the least bit of benefit. It makes the work undistributable, when one (other than the copyright holder(s)) attempts to distribute it in a non-free way. That's one of the key elements of copyleft. On the other hand, if the copyright holder does not disclose source, well, the work is not Free Software in the first place, regardless of the chosen license (GPL or otherwise). The problem with source for audio or video files is that the source is much larger and much more awkward to distribute than the final result. It's plausible that the author doesn't care what you do with his work, but doesn't want to give you these files simply because it's a lot of trouble. That's nothing new: releasing a work in a DFSG-free manner always requires more care than simply putting it online in an All Rights Reserved way (which, unfortunately, is the default status of a work of authorship with current copyright laws). When the uncompressed form is really huge, maybe even the upstream maintainer thinks it's inconvenient to work with. In that case, he/she may prefer to modify the compressed form directly: hence, the source code is really the compressed form! If he then puts his work under GPL, he may not even realize that he's given you no permission to redistribute at all. That's an education problem, not a license issue. Many people even think that posting stuff to a newsgroup means dedicating it to the public domain... It's utterly false, but it's a common misconception anyway. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html Need to refresh your keyring in a piecewise fashion? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpiN5Qhx2IRG.pgp Description: PGP signature
Re: Debian-approved creative/content license?
On Mon, 12 Mar 2007 00:19:17 -0400 Benjamin Seidenberg wrote: [...] Also, it's very possible that stuff no longer exists. I know that when I do an audio project (quite infrequently), once I'm satisfied with the result, I toss away all the intermediate stuff (audacity project files and the like) and only keep the finished (wav/mp3/whatever). In that case, you clearly show that your preferred form for further modifications is the finished format. Hence, that finished form is really source for you. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html Need to refresh your keyring in a piecewise fashion? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgphXNl01nCQ1.pgp Description: PGP signature
Re: Debian-approved creative/content license?
On Sun, 11 Mar 2007 23:06:48 -0700 Don Armstrong wrote: [...] If you as an author do not want to distribute the source (or more importantly, require others who modify your source to do so) then you should pick a license like MIT or expat. Wait, wait! If someone releases a work under the Expat license *without* providing its source, the work is *not* Free Software, as it lacks source! Hence, I would say: If you as an author do not want to require others (who modify and/or redistribute your work) to distribute source, then you should pick a non-copyleft license, such as the Expat/MIT license. You should distribute the source for your work anyway, *if* you want the work to be Free Software. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html Need to refresh your keyring in a piecewise fashion? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp9Tj4mOhctQ.pgp Description: PGP signature
Re: Debian-approved creative/content license?
On Mon, 12 Mar 2007, Francesco Poli wrote: When the uncompressed form is really huge, maybe even the upstream maintainer thinks it's inconvenient to work with. In that case, he/she may prefer to modify the compressed form directly: hence, the source code is really the compressed form! That doesn't follow. The uncompressed form may be inconvenient because it's dozens of times the size of the video and he has limited bandwidth. Or because he's releasing 40 videos but he only edits them one at a time, and has enough disk space for an edit (since he edits them one at a time), but not for all 40 at once. Or because the uncompressed form fits on 15 DVDs and the compressed form fits on one and copying 15 extra DVDs is too much work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On Sun, 11 Mar 2007 15:01:30 +1100 Ben Finney wrote: Michael Gilbert [EMAIL PROTECTED] writes: Looking further, I could not find any Debian-approved licenses for creative (non-software) works [2], [3]. Is the Debian approach to just use a software license like GPL or BSD for creative content? Those licenses can apply to any software, not just programs. So, if the software is an audio work or picture, a software license like GPL or Expat can apply to it. Indeed. Anyway, what recommendation should I make that will satisfy the DFSG? Thank you for your constructive thoughts. If the work is accompanying a program, it makes sense to license it under the same software license. This is always a good recommendation. In the case of a software work that has no programs, a license like Expat should be fine. Agreed. Even the GPL terms could be used, so long as it's clear what the preferred form of the work for making modifications to it means for that work. Agreed, with the addition that, IMHO, the preferred form of the work for making modifications to it is always well-defined (even though sometimes it may be non-trivial to determine). Hence, I would recommend the GNU GPL (v2) whenever one wants a copyleft. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html Need to refresh your keyring in a piecewise fashion? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpM9nmvjD0lR.pgp Description: PGP signature
Re: Debian-approved creative/content license?
On Sun, 11 Mar 2007 14:11:10 +1100 Andrew Donnellan wrote: On 3/11/07, Michael Gilbert [EMAIL PROTECTED] wrote: [...] Is the Debian approach to just use a software license like GPL or BSD for creative content? Anyway, what recommendation should I make that will satisfy the DFSG? Thank you for your constructive thoughts. I'd recommend just using the GPL or Expat licenses, they are tried and tested and don't contain anything too specific to software. Agreed. P.S.: I would have said don't contain anything too specific to programs, since I use the term software in its broadest meaning: see http://frx.netsons.org/essays/softfrdm/whatissoftware.html for further details. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html Need to refresh your keyring in a piecewise fashion? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpB00M26BPFY.pgp Description: PGP signature
Re: Debian-approved creative/content license?
On Sun, 11 Mar 2007, Ben Finney wrote: Those licenses can apply to any software, not just programs. So, if the software is an audio work or picture, a software license like GPL or Expat can apply to it. Actually, there's one big problem. The GPL's preferred form for modification clause. Unless the creators of the podcast directly edit the MP3--which is rather unlikely--the MP3 is not the preferred form for modification and putting the MP3 under GPL without releasing the raw audio files grants no rights at all. GPLing video has a similar problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
Ken Arromdee [EMAIL PROTECTED] writes: On Sun, 11 Mar 2007, Ben Finney wrote: Those licenses can apply to any software, not just programs. So, if the software is an audio work or picture, a software license like GPL or Expat can apply to it. Actually, there's one big problem. The GPL's preferred form for modification clause. Unless the creators of the podcast directly edit the MP3--which is rather unlikely--the MP3 is not the preferred form for modification and putting the MP3 under GPL without releasing the raw audio files grants no rights at all. GPLing video has a similar problem. The preferred form for modification for a film director is often a reshoot of the scene. I guess this means that a GPL video would have to ship with (a copy of) Tom Cruise if he happens to be one of the actors in the film. Sounds difficult to fulfill. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On Sun, 11 Mar 2007 11:04:33 -0700 (PDT) Ken Arromdee wrote: On Sun, 11 Mar 2007, Ben Finney wrote: Those licenses can apply to any software, not just programs. So, if the software is an audio work or picture, a software license like GPL or Expat can apply to it. Actually, there's one big problem. The GPL's preferred form for modification clause. Unless the creators of the podcast directly edit the MP3--which is rather unlikely--the MP3 is not the preferred form for modification and putting the MP3 under GPL without releasing the raw audio files grants no rights at all. GPLing video has a similar problem. In order to release the audio/video recording in a DFSG-free manner, they should release the source as well, as defined in the GNU GPL v2. Wonderful! That is a feature of the GPL, not a bug! Recipients should not be in a position of disadvantage with respect to original authors, or otherwise it's not really Free Software. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html Need to refresh your keyring in a piecewise fashion? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpMEIxdZ76jp.pgp Description: PGP signature
Re: Debian-approved creative/content license?
On Sun, 11 Mar 2007 19:04:57 + Måns Rullgård wrote: Ken Arromdee [EMAIL PROTECTED] writes: On Sun, 11 Mar 2007, Ben Finney wrote: Those licenses can apply to any software, not just programs. So, if the software is an audio work or picture, a software license like GPL or Expat can apply to it. Actually, there's one big problem. The GPL's preferred form for modification clause. [...] The preferred form for modification for a film director is often a reshoot of the scene. I guess this means that a GPL video would have to ship with (a copy of) Tom Cruise if he happens to be one of the actors in the film. Sounds difficult to fulfill. No, that is the preferred form for recreating the film from scratch! The preferred form for *modifying* the film is the video recording in some format that is, well, preferred for, well, making modifications (adding special effects, postproduction, editing, and so forth: think about the so-called special editions of old movies, scenes are not shot again with the original actors, but they may be modified in various ways). -- http://frx.netsons.org/progs/scripts/refresh-pubring.html Need to refresh your keyring in a piecewise fashion? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpJy5BU2EUHv.pgp Description: PGP signature
Re: Debian-approved creative/content license?
On Sun, 11 Mar 2007, Francesco Poli wrote: In order to release the audio/video recording in a DFSG-free manner, they should release the source as well, as defined in the GNU GPL v2. Wonderful! That is a feature of the GPL, not a bug! Recipients should not be in a position of disadvantage with respect to original authors, or otherwise it's not really Free Software. It's a bug. If the original author puts a video under GPL and doesn't release the source, you can't demand it. He's not bound by the GPL since he can't violate the copyright on his own work, so he has no obligation to give you anything. So the result is that you can't demand source and can't distribute the work either. That doesn't give free software the least bit of benefit. The problem with source for audio or video files is that the source is much larger and much more awkward to distribute than the final result. It's plausible that the author doesn't care what you do with his work, but doesn't want to give you these files simply because it's a lot of trouble. If he then puts his work under GPL, he may not even realize that he's given you no permission to redistribute at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
Ken Arromdee wrote: On Sun, 11 Mar 2007, Francesco Poli wrote: In order to release the audio/video recording in a DFSG-free manner, they should release the source as well, as defined in the GNU GPL v2. Wonderful! That is a feature of the GPL, not a bug! Recipients should not be in a position of disadvantage with respect to original authors, or otherwise it's not really Free Software. It's a bug. If the original author puts a video under GPL and doesn't release the source, you can't demand it. He's not bound by the GPL since he can't violate the copyright on his own work, so he has no obligation to give you anything. So the result is that you can't demand source and can't distribute the work either. That doesn't give free software the least bit of benefit. The problem with source for audio or video files is that the source is much larger and much more awkward to distribute than the final result. It's plausible that the author doesn't care what you do with his work, but doesn't want to give you these files simply because it's a lot of trouble. If he then puts his work under GPL, he may not even realize that he's given you no permission to redistribute at all. Also, it's very possible that stuff no longer exists. I know that when I do an audio project (quite infrequently), once I'm satisfied with the result, I toss away all the intermediate stuff (audacity project files and the like) and only keep the finished (wav/mp3/whatever). signature.asc Description: OpenPGP digital signature
Re: Debian-approved creative/content license?
On Sun, 11 Mar 2007, Ken Arromdee wrote: If the original author puts a video under GPL and doesn't release the source, you can't demand it. He's not bound by the GPL since he can't violate the copyright on his own work, so he has no obligation to give you anything. This is the same problem that exists for any work under the GPL; there's nothing special about recordings here. The problem with source for audio or video files is that the source is much larger and much more awkward to distribute than the final result. It's plausible that the author doesn't care what you do with his work, but doesn't want to give you these files simply because it's a lot of trouble. If you as an author do not want to distribute the source (or more importantly, require others who modify your source to do so) then you should pick a license like MIT or expat. The licensing line is fairly simple: Do you want copyleft? Yes: GPL (Maybe LGPL in some cases) No: MIT/Expat Don Armstrong -- An elephant: A mouse built to government specifications. -- Robert Heinlein _Time Enough For Love_ p244 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
On 3/11/07, Michael Gilbert [EMAIL PROTECTED] wrote: I've read up and found the Creative Commons and GFDL licenses are specifically disallowed by Debian (well GFDL with non-invariant sections seems ok, but does that make sense for creative/audio content?). Looking further, I could not find any Debian-approved licenses for creative (non-software) works [2], [3]. Is the Debian approach to just use a software license like GPL or BSD for creative content? Anyway, what recommendation should I make that will satisfy the DFSG? Thank you for your constructive thoughts. I'd recommend just using the GPL or Expat licenses, they are tried and tested and don't contain anything too specific to software. -- 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?
Michael Gilbert [EMAIL PROTECTED] writes: Looking further, I could not find any Debian-approved licenses for creative (non-software) works [2], [3]. Is the Debian approach to just use a software license like GPL or BSD for creative content? Those licenses can apply to any software, not just programs. So, if the software is an audio work or picture, a software license like GPL or Expat can apply to it. Anyway, what recommendation should I make that will satisfy the DFSG? Thank you for your constructive thoughts. If the work is accompanying a program, it makes sense to license it under the same software license. In the case of a software work that has no programs, a license like Expat should be fine. Even the GPL terms could be used, so long as it's clear what the preferred form of the work for making modifications to it means for that work. -- \ Smoking cures weight problems. Eventually. -- Steven Wright | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
