[arch-general] Drop non-free ?! (Was: Commit in ffmpeg/trunk)
Ionut Biru wrote:
drop nonfree stuff, fix headers
Modified: PKGBUILD =================================================================== --- PKGBUILD 2011-05-07 11:29:11 UTC (rev 122937) +++ PKGBUILD 2011-05-07 11:51:04 UTC (rev 122938) @@ -5,26 +5,28 @@
-depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'faac' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') +depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') - --enable-libfaac \ - --enable-nonfree \
Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons? Greg -- () against html e-mail | usenet & email communication netiquette /\ www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
Ionut Biru wrote:
drop nonfree stuff, fix headers
Modified: PKGBUILD =================================================================== --- PKGBUILD 2011-05-07 11:29:11 UTC (rev 122937) +++ PKGBUILD 2011-05-07 11:51:04 UTC (rev 122938) @@ -5,26 +5,28 @@
-depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'faac' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') +depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') - --enable-libfaac \ - --enable-nonfree \
Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons?
Greg
licensing. if you need faac you should use abs to recompile it -- Ionuț
On Sat 07 May 2011 18:32 +0300, Ionut Biru wrote:
On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
Ionut Biru wrote:
drop nonfree stuff, fix headers
Modified: PKGBUILD =================================================================== --- PKGBUILD 2011-05-07 11:29:11 UTC (rev 122937) +++ PKGBUILD 2011-05-07 11:51:04 UTC (rev 122938) @@ -5,26 +5,28 @@
-depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'faac' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') +depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') - --enable-libfaac \ - --enable-nonfree \
Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons?
licensing. if you need faac you should use abs to recompile it
Gah. All this licensing stuff is starting to get really annoying. Did Arch receive a patent license violation notice or something? What is Arch's official policies when it comes to patents? It could have some widespread implications for the distro. Or the distro could purchase or otherwise aquire licenses to all claimed patents... ha... ha...
On 07-05-2011 17:05, Loui Chang wrote:
Or the distro could purchase or otherwise aquire licenses to all claimed patents... ha... ha...
... and then you fall out of bed and wake up. Either that or someone with very very very deep pockets needs to finance that. I agree that all this software patent stuff is getting ridiculous but it's what we have now. As far as I know most if not all distros (and upstream) are leaving the choice of using patented stuff up to the end user. -- Mauro Santos
On 05/07/2011 11:17 AM, Mauro Santos wrote:
On 07-05-2011 17:05, Loui Chang wrote:
Or the distro could purchase or otherwise aquire licenses to all claimed patents... ha... ha...
... and then you fall out of bed and wake up. Either that or someone with very very very deep pockets needs to finance that.
I agree that all this software patent stuff is getting ridiculous but it's what we have now. As far as I know most if not all distros (and upstream) are leaving the choice of using patented stuff up to the end user.
Before we run around thinking that the sky is falling, we must first answer the question "is the patent we are concerned with VALID?", "Who owns it?", and "Who has the right to complain about its use?" If someone isn't checking before disabling useful components of packages, then that is something we should think about doing. The UPSTO has on-line access to lookup and verify. It will list the owner, etc.. Intentionally crippling software base upon questionable patents is nuts. As I've mentioned before, the damages available for infringement are "profits received from the use of IP" Why OS distros with roughly $0 profits (total) are so paranoid about possible violation from a compiled in library that represents 1/100,000 of the distros' offering is a bit bewildering. Over the next few weeks, I'll take a look at the latest CLE papers I have on the topic and see if I can put together a little checklist that can help make sure we are only crippling the software legally that necessary. As for faad2/faac - ffmpeg doesn't have a clue if patents are involved: http://www.ffmpeg.org/legal.html <quote> ...Also we have never read patents to implement any part of FFmpeg. ... What we do know is that various standards FFmpeg supports contain vague hints that any conforming implementation might be subject to some patent rights in some jurisdictions... </quote> What information or supporting docs are we relying on in removing faac & --non-free? Just curious really from a legal standpoint. -- David C. Rankin, J.D.,P.E.
On Sat, 7 May 2011 12:05:21 -0400, Loui Chang wrote:
On Sat 07 May 2011 18:32 +0300, Ionut Biru wrote:
On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
Ionut Biru wrote:
drop nonfree stuff, fix headers
Modified: PKGBUILD =================================================================== --- PKGBUILD 2011-05-07 11:29:11 UTC (rev 122937) +++ PKGBUILD 2011-05-07 11:51:04 UTC (rev 122938) @@ -5,26 +5,28 @@
-depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'faac' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') +depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') - --enable-libfaac \ - --enable-nonfree \
Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons?
licensing. if you need faac you should use abs to recompile it
Gah. All this licensing stuff is starting to get really annoying. Did Arch receive a patent license violation notice or something?
What is Arch's official policies when it comes to patents? It could have some widespread implications for the distro.
Or the distro could purchase or otherwise aquire licenses to all claimed patents... ha... ha...
Licenses and patents are different things. Some stuff cannot legally distributed and we respect that. This is usually proprietary/non-free software or packages like the Microsoft fonts. (Wasn't there also some mplayer codec pack that included some Windows dlls?) On the other hand there are software patents valid in some countries which apply also to a completely free implementation. This means there are a bunch of packages which you are not allowed to use in the US for example even though they are licensed under e.g. the GPL. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Sat, May 7, 2011 at 11:18 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
On Sat, 7 May 2011 12:05:21 -0400, Loui Chang wrote:
On Sat 07 May 2011 18:32 +0300, Ionut Biru wrote:
On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons?
licensing. if you need faac you should use abs to recompile it
Gah. All this licensing stuff is starting to get really annoying. Did Arch receive a patent license violation notice or something?
What is Arch's official policies when it comes to patents? It could have some widespread implications for the distro.
Or the distro could purchase or otherwise aquire licenses to all claimed patents... ha... ha...
Licenses and patents are different things. Some stuff cannot legally distributed and we respect that. This is usually proprietary/non-free software or packages like the Microsoft fonts. (Wasn't there also some mplayer codec pack that included some Windows dlls?)
On the other hand there are software patents valid in some countries which apply also to a completely free implementation. This means there are a bunch of packages which you are not allowed to use in the US for example even though they are licensed under e.g. the GPL.
a bit of a divergence ... but as i think about next-gen packaging quite a bit i've often considered if a most advanced distribution system would negate issues like this ... for example, what if a nonfree package _knew_ it was nonfree, and therefore would only be distributed from servers in countries that do not deem it an issue? when user went to to sync it, their IP would be geolocated (or just a setting, eg. RESIDENT) and if need be the user would be warned that the package they are synced may have unknown legal implications. would something like that work? C Anthony
On Sat 07 May 2011 11:24 -0500, C Anthony Risinger wrote:
a bit of a divergence ... but as i think about next-gen packaging quite a bit i've often considered if a most advanced distribution system would negate issues like this ... for example, what if a nonfree package _knew_ it was nonfree, and therefore would only be distributed from servers in countries that do not deem it an issue? when user went to to sync it, their IP would be geolocated (or just a setting, eg. RESIDENT) and if need be the user would be warned that the package they are synced may have unknown legal implications.
would something like that work?
Maybe not completely. At least it would relieve mirrors of possible infringement which is good for them. Arch might still be found guilty though.
Excerpts from C Anthony Risinger's message of 2011-05-07 18:24:38 +0200:
On Sat, May 7, 2011 at 11:18 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
On Sat, 7 May 2011 12:05:21 -0400, Loui Chang wrote:
On Sat 07 May 2011 18:32 +0300, Ionut Biru wrote:
On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons?
licensing. if you need faac you should use abs to recompile it
Gah. All this licensing stuff is starting to get really annoying. Did Arch receive a patent license violation notice or something?
What is Arch's official policies when it comes to patents? It could have some widespread implications for the distro.
Or the distro could purchase or otherwise aquire licenses to all claimed patents... ha... ha...
Licenses and patents are different things. Some stuff cannot legally distributed and we respect that. This is usually proprietary/non-free software or packages like the Microsoft fonts. (Wasn't there also some mplayer codec pack that included some Windows dlls?)
On the other hand there are software patents valid in some countries which apply also to a completely free implementation. This means there are a bunch of packages which you are not allowed to use in the US for example even though they are licensed under e.g. the GPL.
a bit of a divergence ... but as i think about next-gen packaging quite a bit i've often considered if a most advanced distribution system would negate issues like this ... for example, what if a nonfree package _knew_ it was nonfree, and therefore would only be distributed from servers in countries that do not deem it an issue? when user went to to sync it, their IP would be geolocated (or just a setting, eg. RESIDENT) and if need be the user would be warned that the package they are synced may have unknown legal implications.
would something like that work?
C Anthony
Too complicated, error prone and not really adding anything.
On Saturday, May 07, 2011 12:26:54 Philipp Überbacher wrote:
Excerpts from C Anthony Risinger's message of 2011-05-07 18:24:38 +0200:
On Sat, May 7, 2011 at 11:18 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
On Sat, 7 May 2011 12:05:21 -0400, Loui Chang wrote:
On Sat 07 May 2011 18:32 +0300, Ionut Biru wrote:
On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons?
licensing. if you need faac you should use abs to recompile it
Gah. All this licensing stuff is starting to get really annoying. Did Arch receive a patent license violation notice or something?
What is Arch's official policies when it comes to patents? It could have some widespread implications for the distro.
Or the distro could purchase or otherwise aquire licenses to all claimed patents... ha... ha...
Licenses and patents are different things. Some stuff cannot legally distributed and we respect that. This is usually proprietary/non-free software or packages like the Microsoft fonts. (Wasn't there also some mplayer codec pack that included some Windows dlls?)
On the other hand there are software patents valid in some countries which apply also to a completely free implementation. This means there are a bunch of packages which you are not allowed to use in the US for example even though they are licensed under e.g. the GPL.
a bit of a divergence ... but as i think about next-gen packaging quite a bit i've often considered if a most advanced distribution system would negate issues like this ... for example, what if a nonfree package _knew_ it was nonfree, and therefore would only be distributed from servers in countries that do not deem it an issue? when user went to to sync it, their IP would be geolocated (or just a setting, eg. RESIDENT) and if need be the user would be warned that the package they are synced may have unknown legal implications.
would something like that work?
C Anthony
Too complicated, error prone and not really adding anything.
In my not so humble opinion, I don't think we should waste time kowtowing to the annoying politics of what's free or not when it comes to actual implementation of something. Keep the nonfree stuff there. No one is forcing users to have them, and most Linux users don't give a damn if something is "nonfree."
On 05/07/2011 12:33 PM, Yaro Kasear wrote:
and most Linux users don't give a damn if something is "nonfree."
That's precisely part of the problem. You are walking blindly into patent traps and the destruction of a mutually beneficial community just for the sake of convenience. Have fun with that. Jonathan
On Saturday, May 07, 2011 22:46:29 Jonathan Beatty wrote:
On 05/07/2011 12:33 PM, Yaro Kasear wrote:
and most Linux users don't give a damn if something is "nonfree."
That's precisely part of the problem. You are walking blindly into patent traps and the destruction of a mutually beneficial community just for the sake of convenience.
Have fun with that.
Jonathan
Well, don't mistake "patented" for "patent poisoned." I haven't seen much of a case for ffmpeg being in "patent trap" territory. I personally believe software patents are evil, but I'm hardly going to let Stallmanist politics stop me from getting a functional desktop. It's your kind of thinking that motivates the GPLv3, and it's your kind of thinking that's the reason the GPLv3 is so unpopular. That said, I do tend to avoid things like Mono which are much closer to "patent trap" territory than ffmpeg. I also favor things like Ogg over MP3 or AVI. Largely also because I find things made in Mono are tripe and that Ogg Vorbis sounds better than MP3 and Theora is more fantastic than AVI. A little common sense is required here. Even in the unlikely event anyone's actually ever going to sue over faac, it's not even going to target end users. Such lawsuits rarely do. Secondly, if it does, all it results in is a fork that removes the patented parts. That's the "magic" of FOSS. Patents can't really kill it. Knowing this, I'd rather we don't drop a well-supported feature of ffmpeg just because some people think there *might* be a patent problem. 99.9% of patents that encompass FOSS projects are ignored by the patent holders, even if they know that the patents are "infringed." Largely because the patent holders know we're not exploiting their patents for our gain. That remaining 0.1% are the kind of entities that want to see things like Linux dead and buried because it threatens their bottom line. It's not about royalties so much as it's about bullying the competition. I'm serious, though. If we worry about "questionable patents" like you are we may as well chuck the majority of the packages in [core], [extra], and [community] into the AUR, because I promise they will ALL touch in some way on some patent somewhere, largely because patents, especially in the US, are handed out like candy. So, rather than succumb to fear of patents and making the majority of the packages in Arch useless, leave them how they are and let the vocal minority who honestly thinks we'd get sued over faac use the abs to build a custom ffmpeg package that has no faac support. In a nutshell: Quit crippling my distribution just because you're scared of patents just because Richard Stallman told you to be.
On Sat 07 May 2011 18:18 +0200, Pierre Schmitz wrote:
On Sat, 7 May 2011 12:05:21 -0400, Loui Chang wrote:
On Sat 07 May 2011 18:32 +0300, Ionut Biru wrote:
On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons?
licensing. if you need faac you should use abs to recompile it
Gah. All this licensing stuff is starting to get really annoying. Did Arch receive a patent license violation notice or something?
What is Arch's official policies when it comes to patents? It could have some widespread implications for the distro.
Or the distro could purchase or otherwise aquire licenses to all claimed patents... ha... ha...
Licenses and patents are different things. Some stuff cannot legally distributed and we respect that. This is usually proprietary/non-free software or packages like the Microsoft fonts. (Wasn't there also some mplayer codec pack that included some Windows dlls?)
On the other hand there are software patents valid in some countries which apply also to a completely free implementation. This means there are a bunch of packages which you are not allowed to use in the US for example even though they are licensed under e.g. the GPL.
Ah yeah I'm making some assumptions. It would be nice to understand the exact reasons that the support was removed. I'm assuming that faac support was removed because of patent issues, and that ffmpeg does conform to the MPEG-2 NBC/MPEG-4 Audio standards. The license of the code itself [1] would not seem to necessarily forbid binary distribution. The reason that it is incompatible with LGPL is because the original license allows free license only to products which conform to the MPEG-2 NBC/MPEG-4 Audio standards. Relicensing all of the code as LGPL would nullify that requirement which is not allowed. [1] http://faac.cvs.sourceforge.net/viewvc/faac/faac/README?revision=1.7
Loui Chang wrote:
On Sat 07 May 2011 18:32 +0300, Ionut Biru wrote:
On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
Ionut Biru wrote:
Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons?
licensing. if you need faac you should use abs to recompile it
<...> What is Arch's official policies when it comes to patents? It could have some widespread implications for the distro.
Seems theres a heated topic on the forum about this [0]. I hadn't noticed it before, i had seen [1] though. Oh well, the forum isn't the suitable place for heated discussions anyway :) [0]: https://bbs.archlinux.org/viewtopic.php?id=117855 [1]: https://bbs.archlinux.org/viewtopic.php?id=116994 -- () against html e-mail | usenet & email communication netiquette /\ www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
On 05/07/2011 12:32 PM, Ionut Biru wrote:
On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
Ionut Biru wrote:
drop nonfree stuff, fix headers
Modified: PKGBUILD =================================================================== --- PKGBUILD 2011-05-07 11:29:11 UTC (rev 122937) +++ PKGBUILD 2011-05-07 11:51:04 UTC (rev 122938) @@ -5,26 +5,28 @@
-depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'faac' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') +depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') - --enable-libfaac \ - --enable-nonfree \
Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons?
Greg
licensing. if you need faac you should use abs to recompile it
Will be also unlinked from mplayer? -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On 05/07/2011 08:41 PM, Gerardo Exequiel Pozzi wrote:
On 05/07/2011 12:32 PM, Ionut Biru wrote:
On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
Ionut Biru wrote:
drop nonfree stuff, fix headers
Modified: PKGBUILD =================================================================== --- PKGBUILD 2011-05-07 11:29:11 UTC (rev 122937) +++ PKGBUILD 2011-05-07 11:51:04 UTC (rev 122938) @@ -5,26 +5,28 @@
-depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'faac' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') +depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') - --enable-libfaac \ - --enable-nonfree \
Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons?
Greg
licensing. if you need faac you should use abs to recompile it
Will be also unlinked from mplayer?
mplayer doesn't use system ffmpg -- Ionuț
On 8 May 2011 02:07, Ionut Biru <ibiru@archlinux.org> wrote:
On 05/07/2011 08:41 PM, Gerardo Exequiel Pozzi wrote:
On 05/07/2011 12:32 PM, Ionut Biru wrote:
On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
Ionut Biru wrote:
drop nonfree stuff, fix headers
Modified: PKGBUILD =================================================================== --- PKGBUILD 2011-05-07 11:29:11 UTC (rev 122937) +++ PKGBUILD 2011-05-07 11:51:04 UTC (rev 122938) @@ -5,26 +5,28 @@
-depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'faac' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') +depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') - --enable-libfaac \ - --enable-nonfree \
Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons?
Greg
licensing. if you need faac you should use abs to recompile it
Will be also unlinked from mplayer?
mplayer doesn't use system ffmpg
The question was aimed at the fact thatt mplayer too has faac as depends... As an opinion: I'd rather not want to recompile mplayer every time there's an update, been there before because of other reason, it's not much fun. Using mencoder to convert avis to mp4 to use on Android: those _do_ require faac, as much as I can tell.... Greg
On 05/07/2011 09:21 PM, Gergely Imreh wrote:
Will be also unlinked from mplayer?
mplayer doesn't use system ffmpg
The question was aimed at the fact thatt mplayer too has faac as depends...
As an opinion: I'd rather not want to recompile mplayer every time there's an update, been there before because of other reason, it's not much fun. Using mencoder to convert avis to mp4 to use on Android: those _do_ require faac, as much as I can tell....
Greg
now i understand the question. It won't be removed. I did it for ffmpeg because it has a big warning after ./configure License: nonfree and unredistributable maybe mplayer does it right and doesn't link to incompatible licence -- Ionuț
On 05/07/2011 03:43 PM, Ionut Biru wrote:
On 05/07/2011 09:21 PM, Gergely Imreh wrote:
Will be also unlinked from mplayer?
mplayer doesn't use system ffmpg
The question was aimed at the fact thatt mplayer too has faac as depends...
As an opinion: I'd rather not want to recompile mplayer every time there's an update, been there before because of other reason, it's not much fun. Using mencoder to convert avis to mp4 to use on Android: those _do_ require faac, as much as I can tell....
Greg
now i understand the question. It won't be removed. I did it for ffmpeg because it has a big warning after ./configure
License: nonfree and unredistributable
maybe mplayer does it right and doesn't link to incompatible licence
Many packages in Arch Linux are considered "non-free" in other distros this is what I much like about Arch Linux :) -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On 8 May 2011 02:43, Ionut Biru <ibiru@archlinux.org> wrote:
now i understand the question. It won't be removed. I did it for ffmpeg because it has a big warning after ./configure
License: nonfree and unredistributable
How are we keeping FAAC/FAAD2 in [extra] then? If we redistribute FAAC/FAAD2 (which are redistributed in source form via sourceforge), then we shouldn't have problems building other stuff with them. There are questionable patent infringements and possibilities, but all upstream (in this case) does is remain on the safe side by not providing any binaries themselves, since they would be liable first. FFMPEG follows suit by displaying warnings, which is useful to distributors who have strict packaging policies (like Ubuntu with their multiverse repository). -- GPG/PGP ID: 8AADBB10
On 05/07/2011 09:21 PM, Gergely Imreh wrote:
On 8 May 2011 02:07, Ionut Biru<ibiru@archlinux.org> wrote:
On 05/07/2011 08:41 PM, Gerardo Exequiel Pozzi wrote:
On 05/07/2011 12:32 PM, Ionut Biru wrote:
On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
Ionut Biru wrote:
drop nonfree stuff, fix headers
Modified: PKGBUILD =================================================================== --- PKGBUILD 2011-05-07 11:29:11 UTC (rev 122937) +++ PKGBUILD 2011-05-07 11:51:04 UTC (rev 122938) @@ -5,26 +5,28 @@
-depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'faac' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') +depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') - --enable-libfaac \ - --enable-nonfree \
Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons?
Greg
licensing. if you need faac you should use abs to recompile it
Will be also unlinked from mplayer?
mplayer doesn't use system ffmpg
The question was aimed at the fact thatt mplayer too has faac as depends...
As an opinion: I'd rather not want to recompile mplayer every time there's an update, been there before because of other reason, it's not much fun. Using mencoder to convert avis to mp4 to use on Android: those _do_ require faac, as much as I can tell....
Greg You don't _have_ to use faac. You can process the audio separately with nero's aac encoder[1].
[1] https://aur.archlinux.org/packages.php?ID=15897 -- cantabile "Jayne is a girl's name." -- River
On Sat, May 7, 2011 at 11:32 AM, Ionut Biru <ibiru@archlinux.org> wrote:
On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
Ionut Biru wrote:
drop nonfree stuff, fix headers
Modified: PKGBUILD =================================================================== --- PKGBUILD 2011-05-07 11:29:11 UTC (rev 122937) +++ PKGBUILD 2011-05-07 11:51:04 UTC (rev 122938) @@ -5,26 +5,28 @@
-depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'faac' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') +depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'xvidcore' 'zlib' 'x264' 'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 'libvpx' 'libva' 'openjpeg') - --enable-libfaac \ - --enable-nonfree \
Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons?
Greg
licensing. if you need faac you should use abs to recompile it
Before we get too far down the licensing / patents / legality / etc discussion, it's worth noting that faac is basically redundant in ffmpeg these days anyway, as libavcodec contains ffmpeg's own reimplementation of both an encoder and a decoder of AAC, just called "aac" in the output of "ffmpeg -codecs".
participants (15)
-
C Anthony Risinger
-
cantabile
-
David C. Rankin
-
Gerardo Exequiel Pozzi
-
Gergely Imreh
-
Grigorios Bouzakis
-
Ionut Biru
-
Jonathan Beatty
-
Loui Chang
-
Mauro Santos
-
Philipp Überbacher
-
Pierre Schmitz
-
Ray Kohler
-
Ray Rashif
-
Yaro Kasear