AAC and Debian | Hacker News Reader

AAC and Debian

tookmund.com

51 pointstookmund22 comments

From the article:

    "This is a slightly unusual situation, as the fdk-aac library is licensed under what even the GNU project acknowledges is a free software license. However, this license explicitly does not grant any patent rights."

Here, in the US at the very least, this would seem to be less of a problem given De Forest Radio, 273 U.S. 236 (1927):

    "Any language used by the owner of the patent, or any conduct on his part exhibited to another from which that other may properly infer that the owner consents to his use of the patent in making or using it, or selling it, upon which the other acts, constitutes a license and a defense to an action for a tort."

And logically this case makes sense. If I've granted you all these copyrights (MIT and BSD), just to surprise you/someone with a patent suit, that seems not equitable. Large companies are more comfortable with Apache 2 given it's explicit patent grant, but I wouldn't be surprised if users of certain Rust software (which is often MIT + Apache 2 licensed) had more expansive patent rights under the MIT license, given how narrow the rights granted by the Apache 2 are.

However, here, the facts are not as stated in the article. The FDK license does not just "explicitly not grant", as the article notes, it puts you on notice that you must obtain a patent license. That is not like the MIT license. The MIT license is silent re: a patent license.

Franhoufer is not the owner of the patents in question, most of them are likely owned by the usual gang . They cannot license it to you even if they wanted to.

> Franhoufer is not the owner of the patents in question, most of them are likely owned by the usual gang . They cannot license it to you even if they wanted to.

The point remains, if you license your software permissively (MIT), and you were aware of it being patent encumbered, and someone uses your software in a patent infringing way, the problem would likely be licensor's, not yours.

Here, you may be correct, that is less certain because the license explicitly mentions needing to obtain a patent license.

That's absurd. By your broken rationale, if someone uses my free "AshamedSSL" library in a enterprisey security product and _their_ customers are hacked to no end, I'm liable. Citation needed.

Calm down. I note: "Here, you may be correct, that is less certain because the (FDK) license explicitly mentions needing to obtain a patent license."

> By your broken rationale, if someone uses my free "AshamedSSL" library in a enterprisey security product and _their_ customers are hacked to no end, I'm liable. Citation needed.

I'm not sure how this follows. How did they use your software? If licensed re: the MIT, you disclaimed liability already?

What if your argument was closer to the facts: You license your software as MIT, you are aware of patent claims but are simply silent on the matter, and a user uses the software and is sued for patent infringement. If I were the licensee's attorney, I'd join you in the lawsuit arguing the good faith licensee relied on your apparent authority to convey the patent rights, and you induced my client to commit infringement by not disclosing patent claims which you were aware of.

You edited your post after I finished mine and added the "knowingly" and the stuff about the FDK license.

But anyway even with your constrained example this is not yet enough to claim inducement to commit infringement. You still need _intent_. None of the jurisprudence you quoted refers to a case where licensee != patent holder, much less one where licensee would not stand to benefit from your infringement, so I'm not even sure how are you going to build a case.

You would be opening yet another Pandora's Box since so far no one in the free software community would consider free/gratis redistribution of software-that-we-know-could-potentially-be-infringing (i.e. everything) as "induction to commit infringement". (Note that _selling_ such software has always been another story, with contributory infringement at least being on the table, and the reason RedHat, etc. have traditionally been so afraid of patents).

> You still need _intent_.

My goodness, and circumstantial evidence can establish intent. Knowledge plus actions in promoting an infringing product (like publishing MIT licensed source code without a notice) could be enough to establish intent. See, for example, DSU Medical Corp. v. JMS Co., 471 F.3d 1293 (Fed. Cir. 2006).

> You would be opening yet another Pandora's Box

I'm not saying everything is potentially infringing. I'm saying with knowledge and actions which induce, yes, it possibly is. Most FOSS would lack actual knowledge.

This is all hypothetical anyway. Franhoufer does in fact license their software without a patent grant which puts us all on notice that we need to obtain a patent license.

You keep quoting a case where licensor was one of the patent holders, but this is hardly relevant. It would be much harder (euphemism for "impossible") to prove that there was intent when there is no possible revenue stream for the licensor. Knowledge is much easier to prove (most projects openly discuss the risk).

Huh I didn’t know about Dr Forest Radio that’s interesting! I’ll correct the “explicitly not grant” language, to me that seemed the same as it telling you to get a license, but I can see how that’s not the same.

This kind of thing is why I’ve only ever used Debian as a server distro until the Raspberry Pi started “fixing” various aspects of it… My Linux laptops ran Ubuntu for a solid decade until Fedora 36 turned me around (and I’ve been happy since).

But the key thing is that Debian tends to lag on user amenites (hardware, drivers, codecs, etc.) to a point where one wonders if they actually use the distro on modern hardware...

The trick with Debian is to use Debian testing. Despite the name it's thoroughly stable enough for desktop use. Debian stable is for when you're needing an OS for a nuclear power plant or something.

This could be advertised better.

> Bluetooth headphones that require the AAC codec cannot be used

Isn't SBC support mandatory for Bluetooth audio devices?

Looks like it should be mandatory:

https://en.wikipedia.org/wiki/SBC_%28codec%29

As of A2DP version 1.3, the Low Complexity Subband Coding remains the default codec and its implementation is mandatory for devices supporting that profile, but vendors are free to add their own codecs to match their needs.

It should be, but I’ve never gotten it to work with any Apple Bluetooth headphones. Only static unless I switch to AAC.

Interesting. Could FFmpeg’s AAC en/decoder not be used? There’s an explicit flag necessary to include libfdk-aac when compiling FFmpeg and it makes the resulting binary not able to be shared.

However, without that flag, FFmpeg still has (their own? VideoLAN’s?) an AAC en/decoder that works fine.

The issue, I believe, is more around the AAC patents and less around the actual library.

Any reason they didn't use the debian apt source repositories instead of git? I tend to try and use deb-src whenever possible, to stay as close to Debian truth as possible.

They cloned the Debian git repo, https://salsa.debian.org/multimedia-team/fdk-aac , and used apt source directly for pipewire. Not sure why the split approach, but it does look like they are relying on a Debian source of truth.

The split approach is because the free version of the library is not yet in Debian. There’s probably some way to pull it from the new queue directly but cloning the git repo is easier.

If you run "apt source" for the package you'll see it - like lots of other packages - point you to the git repository when the packaging is maintained in a public git repository. The Vcs-Tag field in the package lists is the magic that triggers that message.

Is there any reason why we cannot put a pipewire-with-aac build in the nonfree repository that replaces the default pipewire build using the Alternatives system?

Or perhaps pipewire could ldopen() libfaac as required.

Edit: the issue is social, not technical—it’s not desirable to have an easy way to “slot in” a nonfree aac because of patent disputes

The problem is with spectral band replication in aac-he and parametric stereo in aac-he-v2 both of which are impressive but not transparent and should only be used if you are trying save bandwidth

Reply on news.ycombinator.com