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
11–20 of 25 posts
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
> Bluetooth headphones that require the AAC codec cannot be used Isn't SBC support mandatory for Bluetooth audio devices?
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.
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…
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.
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
> 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…
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.
> 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.
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.
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.
> 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.
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.
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…