On 11/29/2016 06:49 AM, Oleksij Rempel wrote:
Am 28.11.2016 um 20:01 schrieb IgorMitsyanko:
On 11/28/2016 08:33 PM, Oleksij Rempel wrote:
Am 28.11.2016 um 18:10 schrieb Oleksij Rempel:
Am 28.11.2016 um 17:34 schrieb Kyle McMartin:
On Tue, Nov 22, 2016 at 9:44 AM, IgorMitsyanko
<igor.mitsyanko.os@xxxxxxxxxxxxx> wrote:
Hi Ben, Kyle,
could you please share what is the position of linux-firmware
regarding
firmware binaries that include GPL components? Does it require
entire GPL
components codebase be present in linux-firmware tree, or maybe
having this
clause in license file is enough:
+Open Source Software. The Software may include components that are
licensed
+pursuant to open source software (“Open Source Components”).
Information
+regarding the Open Source Components included with the Software is
available
+upon request to oslegal@xxxxxxxxxxxxx. To the extent such Open Source
+Components are required to be licensed to you under the terms of a
separate
+license (such as an open source license) then such other terms
shall apply,
and
+nothing herein shall be deemed or interpreted to limit any rights
you may
have
+under any such applicable license.
From technical perspective, size of the codebase used to build
Quantenna
firmware is a few hundred MBs, it seems too much to include into
linux-firmware tree.
I don't have strong feelings one way or another. I'd prefer not having
several hundred
MB of source that's unlikely to change included in the linux-firmware
git tree. I'm also not
a lawyer, so I can't help you decide what would satisfy the
distribution clause of the GPLv2.
We already have one GPL firmware (carl9170fw) which includes the
source, but just references
a seperate toolchain for downloading, so it's only approximately 1MB
in size in the tree.
Is your firmware source really that large, or is it just including the
entire build toolchain with it?
regards,
--Kyle
We also have open BSD licensed open-ath9k-htc-firmware. Which is locate
out of source too.
https://github.com/qca/open-ath9k-htc-firmware
and here is location of carl firmware:
https://github.com/chunkeey/carl9170fw
So, what is actual problem with Quantenna QSR10G FW?
I would be really interesting to take a look on it. Is it somewhere
available? Are there some devices to get hand on?
After seeing specs of this device i have strong feeling that "some open
source part" is actual linux kernel.
Oleksij, yes, that's correct, it includes entire Linux environment; the
reasoning is that it allows to hide all WiFi-related logic inside device
itself, and emulate simple Ethernet device for external system
(therefore, freeing external system resources).
This approach was working really well for us until recently, but now
that company is expanding, we want to have more flexible and standardize
interface available for external system to manage wireless connection,
and FullMAC driver seems to be the best solution here.
you mean, this driver will not use mac80211 framework provided by kernel?
Yes, this driver is FullMAC - converting Quantenna drivers codebase to
mac80211 framework will require significant effort from developers and
QA, but I think in the future it will have to be done anyway.
For the availability of FW sources, QSR10G-based products are still
under development at this moment (not in the market yet), but many
products based on previous generation chipset QSR1000 are available. For
example, Asus has a retail design with QSR1000 chipset, and has all GPL
sourcecode available on their website (including what Quantenna has
provided):
http://www.asus.com/Networking/RTAC87U/HelpDesk_Download/
Quantenna provided code is in, for example, "GPL of ASUS RT-AC87U for
firmware 3.0.0.4.378.7410" archive.
It's basically the same as used for QSR10G.
Will Quantenna provide documentation for at least old chipsats? Playing
fair with OSS developer community has some advantages :)
Will forward the request.
I agree with this, though this is more about protecting from other wifi
vendors on a highly competitive market rather than hiding something from
community) QSR1000 chipset that I mentioned is actually "current"
chipset while QSR10G can be considered future chipset.
