Re: [EMAIL PROTECTED]: Re: [sork] About license of sork modules]
On Mon, 01 May 2006, Chuck Hagenbuch wrote: > I suppose another question is, what level of contribution gives > someone enough copyright say to need to approve a license change? > Fixing a typo? A few lines of code? A whole new driver seems like > enough to me; what about tweaking CSS? I don't know if there are > rules for this. There aren't any rules for that, as it's very difficult to determine at what point you generate a work of authorship. A general rule of thumb is that any non-trivial contribution has a say in the way in which the work is licensed. This is one of the reasons why doing due dilligence in copyright assignment or licensing when you accept patches for contributors is such an important part in making a robust free software project. [Unfortunatly, it's one of the parts that almost every project sucks horribly at because it's such a thankless uninteresting task.] Don Armstrong -- "The trouble with you, Ibid" he said, "is that you think you're the biggest bloody authority on everything" -- Terry Pratchet _Pyramids_ p146 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#365194: Fwd: Re: [NONFREE-DOC] RFC1459, 2810-2813: IRC (Internet Relay Chat).
On Sat, Apr 29, 2006 at 07:41:28PM +0200, Francesco Poli wrote: > On Sat, 29 Apr 2006 01:55:55 +0200 Kurt Roeckx wrote: > > > Do I need to get the copyright holder of the documents to > > relicense it under the GPL? It seems clear to me that it > > already is covered by the GPL, but it shouldn't be a > > problem to get the copyright holder to explicitly state > > that. > > Yes, please do. > A clarification would be highly useful, IMHO. I'm not sure, but I think if they say that the rfc is covered by the gpl, that it might need to have some exception saying that the name needs to be changed, which also seems to be compliant with DFSG #4. Does the GPL allow such exceptions? Could someone please advise me on what I should ask them to say? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Free Art License
On Thu, 27 Apr 2006 17:54:53 +1000 Andrew Donnellan wrote: > There is a license called the Free Art license, I don't know if that > is DFSG-free. I believe that it is. However, it is not a very appropriate license for all-digital works. It is specifically designed to address physical artworks: the different stuff about "original work of art" and "The Original" is all about that. If you don't have a physical original, it's a cumbersome and unwieldy license. If you do, it's a great license. -- Nathanael Nerode <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MPEG-4 patent license issues - libfaad* and libx264* and other codecs.
On Sat, Apr 29, 2006 at 11:37:39PM +0100, Matthew William Solloway Bell wrote: > The packages libxine1, ffmpeg, include libfaad*, libx264* or another > codec which implement the MPEG-4 Advanced Audio Coding and Advanced > Video Coding standards. Unfortunately, these are patent encumbered in at > least the USA, and many other countries. To distribute code implementing > any of these patents, a license is required[1], assuming that the > claimed patents are valid. This license requires signing an agreement > and the payment of royalties, which hasn't been done AFAIK, and is > contrary to policy. > There is evidence of prior attempts of enforcement, specifically against > FAAD at AudioCoding.com[2]. This appears to refer to enforcement of patents covering encoding using the codecs in question. Do libxine1 and ffmpeg implement encoding of these, or just decoding? Is there a history of enforcement of patents on decoding of the codecs in question? Further, it has been brought to my attention > that a reasonable belief that patents are not valid is sufficient > condition for being able to distribute software that comes under such a > license (subject to ftp master agreement). This is the only evidence I > could find supporting such a belief[3]. It does not appear that > significant prior art exists for any/all of the MPEG-4 patents. > There has been some discussion on the lists before about this issue with > no particular conclusion[4]. The ffii.org page you point to explicitly states their opinion that the patents in question contain no substantive creative element, i.e., the patents are invalidated by prior art in the field. Why do you draw the opposite conclusion that "it does not appear that significant prior art exists", citing only the ffii.org page itself? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: MPEG-4 patent license issues - libfaad* and libx264* and other codecs.
Steve Langasek <[EMAIL PROTECTED]> writes: > On Sat, Apr 29, 2006 at 11:37:39PM +0100, Matthew William Solloway > Bell wrote: >> The packages libxine1, ffmpeg, include libfaad*, libx264* or another >> codec which implement the MPEG-4 Advanced Audio Coding and Advanced >> Video Coding standards. Unfortunately, these are patent encumbered in at >> least the USA, and many other countries. To distribute code implementing >> any of these patents, a license is required[1], assuming that the >> claimed patents are valid. This license requires signing an agreement >> and the payment of royalties, which hasn't been done AFAIK, and is >> contrary to policy. >> There is evidence of prior attempts of enforcement, specifically against >> FAAD at AudioCoding.com[2]. > > This appears to refer to enforcement of patents covering encoding using the > codecs in question. Do libxine1 and ffmpeg implement encoding of these, or > just decoding? Is there a history of enforcement of patents on decoding of > the codecs in question? FFmpeg has an AVC decoder. It does not include an AVC encoder, and it neither encodes nor decodes AAC. FFmpeg can optionally use external libraries for these tasks. I'm not familiar with libxine enough to comment on it. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Free Art License
On Mon, 1 May 2006 15:18:32 -0400 Nathanael Nerode wrote: > On Thu, 27 Apr 2006 17:54:53 +1000 Andrew Donnellan wrote: > > > There is a license called the Free Art license, I don't know if that > > is DFSG-free. > > I believe that it is. If you do, could you please reply to my analysis with an actual rebuttal? I would be much happier, should I find out that a license, which is claimed to be Free by the FSF, is *actually* Free: such an event has become unusual in these strange days, unfortunately... :-((( -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpCLzQmk4L6x.pgp Description: PGP signature
Re: Re: MPEG-4 patent license issues - libfaad* and libx264* and other codecs.
> On Sat, Apr 29, 2006 at 11:37:39PM +0100, Matthew William Solloway Bell wrote: > > The packages libxine1, ffmpeg, include libfaad*, libx264* or another > > codec which implement the MPEG-4 Advanced Audio Coding and Advanced > > Video Coding standards. Unfortunately, these are patent encumbered in at > > least the USA, and many other countries. To distribute code implementing > > any of these patents, a license is required[1], assuming that the > > claimed patents are valid. This license requires signing an agreement > > and the payment of royalties, which hasn't been done AFAIK, and is > > contrary to policy. > > There is evidence of prior attempts of enforcement, specifically against > > FAAD at AudioCoding.com[2]. > > This appears to refer to enforcement of patents covering encoding using the > codecs in question. Do libxine1 and ffmpeg implement encoding of these, or > just decoding? Is there a history of enforcement of patents on decoding of > the codecs in question? Hmmm, I think I have missed something; what makes you draw this conclusion? AudioCoding.com has removed all binaries including those related to decoding. I see no reference to encoding only in [2]. The licensing authorities in [1] have licenses that cover decoders. I did look at their patent portfolio, but is was brief and shallow. I'm having a closer look now. libxine: libfaad (AAC decoder) vlc: libfaad (AAC decoder); libx264 (AVC decoder) libavcodec0: libfaad (AAC decoder); libx264 (AVC decoder) AFAIK, libx264 is a decoder only but the decoding functions are called x264_encoder_? > Further, it has been brought to my attention > > that a reasonable belief that patents are not valid is sufficient > > condition for being able to distribute software that comes under such a > > license (subject to ftp master agreement). This is the only evidence I > > could find supporting such a belief[3]. It does not appear that > > significant prior art exists for any/all of the MPEG-4 patents. > > There has been some discussion on the lists before about this issue with > > no particular conclusion[4]. > > The ffii.org page you point to explicitly states their opinion that the > patents in question contain no substantive creative element, i.e., the > patents are invalidated by prior art in the field. Why do you draw the > opposite conclusion that "it does not appear that significant prior art > exists", citing only the ffii.org page itself? My apologies, that should read 'It does not appear to me that..." which is based on the conclusion of the previous sentence. I was rather hoping someone would be able to support or contradict this. Regarding my comments on 'prior art', I did not consider 'prior art' to be semantically identical to 'no inventive step'; however, I considered both to be sufficient condition to deem the patents invalid. Of course, I'm not a patent lawyer. Matthew W. S. Bell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: MPEG-4 patent license issues - libfaad* and libx264* and other codecs.
Oops,
My mistake libavcodec is not using libx264, but it's own AVC decoder,
and the FAA{C,D} code is an interface only.
Matthew W. S. Bell
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MPEG-4 patent license issues - libfaad* and libx264* and other codecs.
Matthew William Solloway Bell <[EMAIL PROTECTED]> writes: >> On Sat, Apr 29, 2006 at 11:37:39PM +0100, Matthew William Solloway Bell >> wrote: >> > The packages libxine1, ffmpeg, include libfaad*, libx264* or another >> > codec which implement the MPEG-4 Advanced Audio Coding and Advanced >> > Video Coding standards. Unfortunately, these are patent encumbered in at >> > least the USA, and many other countries. To distribute code implementing >> > any of these patents, a license is required[1], assuming that the >> > claimed patents are valid. This license requires signing an agreement >> > and the payment of royalties, which hasn't been done AFAIK, and is >> > contrary to policy. >> > There is evidence of prior attempts of enforcement, specifically against >> > FAAD at AudioCoding.com[2]. >> >> This appears to refer to enforcement of patents covering encoding using the >> codecs in question. Do libxine1 and ffmpeg implement encoding of these, or >> just decoding? Is there a history of enforcement of patents on decoding of >> the codecs in question? > > Hmmm, I think I have missed something; what makes you draw this > conclusion? AudioCoding.com has removed all binaries including those > related to decoding. I see no reference to encoding only in [2]. The > licensing authorities in [1] have licenses that cover decoders. I did > look at their patent portfolio, but is was brief and shallow. I'm having > a closer look now. > > libxine: libfaad (AAC decoder) > vlc: libfaad (AAC decoder); libx264 (AVC decoder) > libavcodec0: libfaad (AAC decoder); libx264 (AVC decoder) > > AFAIK, libx264 is a decoder only but the decoding functions are called > x264_encoder_? x264 is an AVC *encoder* only. libavcodec can optionally call it for AVC encoding. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: MPEG-4 patent license issues - libfaad* and libx264* and other codecs.
On Tue, May 02, 2006 at 01:13:02AM +0100, Matthew William Solloway Bell wrote: > > On Sat, Apr 29, 2006 at 11:37:39PM +0100, Matthew William Solloway Bell > > wrote: > > > The packages libxine1, ffmpeg, include libfaad*, libx264* or another > > > codec which implement the MPEG-4 Advanced Audio Coding and Advanced > > > Video Coding standards. Unfortunately, these are patent encumbered in at > > > least the USA, and many other countries. To distribute code implementing > > > any of these patents, a license is required[1], assuming that the > > > claimed patents are valid. This license requires signing an agreement > > > and the payment of royalties, which hasn't been done AFAIK, and is > > > contrary to policy. > > > There is evidence of prior attempts of enforcement, specifically against > > > FAAD at AudioCoding.com[2]. > > This appears to refer to enforcement of patents covering encoding using the > > codecs in question. Do libxine1 and ffmpeg implement encoding of these, or > > just decoding? Is there a history of enforcement of patents on decoding of > > the codecs in question? > Hmmm, I think I have missed something; what makes you draw this > conclusion? AudioCoding.com has removed all binaries including those > related to decoding. I see no reference to encoding only in [2]. The > licensing authorities in [1] have licenses that cover decoders. I did > look at their patent portfolio, but is was brief and shallow. I'm having > a closer look now. Sorry, what I mean is that the AudioCoding.com case involved a work that implemented both encoding and decoding, therefore we can't infer from it that patents which apply only to decoders are being actively enforced. > My apologies, that should read 'It does not appear to me that..." which > is based on the conclusion of the previous sentence. I was rather hoping > someone would be able to support or contradict this. Regarding my > comments on 'prior art', I did not consider 'prior art' to be > semantically identical to 'no inventive step'; however, I considered > both to be sufficient condition to deem the patents invalid. Of course, > I'm not a patent lawyer. Yeah, they're not exactly semantically identical, but a claim that there is no inventive step depends on showing that there is prior art, and the ffii page makes assertions about specific prior art in existence. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Re: MPEG-4 patent license issues - libfaad* and libx264* and other codecs.
So given my idiocy I'm going to leave that detective work to someone else. I think the general picture is slightly more clear than opaque now though. MWSBell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
