> > With the carl9170 driver, the GPL firmware was required to be put
> > as buildable source code into the linux-firmware tree.
> An SDK that can be used to build QSR10G firmware is a ~240MB file in
> compressed archive format, it includes GPL code as well as
> proprietary components.
> Our legal team included following clause in licence file coming with
> firmware:
> Information regarding the Open Source Components included with the
> Software is available upon request to [email protected]
> So the idea is that GPL components used in firmware can be provided
> on request.
I understand, and I understand that you/they are actually providing it
when asked.
However, the carl9170 project has its (entirely GPL) source tree out in
the open, making it much *easier* and that was *still* thought to not
be sufficient; I don't recall the discussions but I'm guessing that's
because of something like redistributors having to make sure source is
available, and guaranteeing that for a long time, etc.
johannes
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
>>> <[email protected]> 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 [email protected]. 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.
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.
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
>>>>> <[email protected]> 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 [email protected]. 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.
>
>
On 11/29/2016 12:34 PM, Arend Van Spriel wrote:
>
> On 29-11-2016 10:10, IgorMitsyanko wrote:
>> 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:
> [...]
>
>>>> 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.
> Why? The linux wireless subsystem supports both models, ie.
> cfg80211-based drivers and mac80211-based drivers, so there is no
> technical reason for making the effort. There are clearly benefits in
> using a generic and freely available 802.11 stack like mac80211.
There is definitely a benefit if starting a new product development,
however with existing products its not that simple due to highly
conservative approach:
- for many years development was based on old MadWiFi driver and older
kernel. Over time it was modified and rewritten to fit internal needs,
and integrating it into mac80211 (to preserve the same behavior) would
require significant effort.
- it takes a lot of resources to validate that system works as expected.
Quantenna itself is doing QA testing and certification + engineering has
to be sure there is no performance/feature regression + end product
manufacturers has to do their own QA. Each change means a lot of time
and money spend on validation, new potential bugs to fix etc
With FullMAC driver on the other hand, device firmware is a "black box"
for external system and firmware changes can be kept to a minimum.
I'd like to clarify that I think that moving to mac80211 is inevitable
in any case and will happen in the future.
>
> Regards,
> Arend
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 [email protected]. 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.
On 11/11/2016 02:35 PM, Johannes Berg wrote:
> Adding linux-firmware people to Cc, since presumably they don't
> necessarily read linux-wireless...
>
>> Johannes, from that perspective, who are the "redistributors"?
>> Specifically, is linux-firmware git repository considered a
>> redistributor or its just hosting files? I mean, at what moment
>> someone else other then Quantenna will start to be legally obliged to
>> make GPL code used in firmware available for others?
> Look, I don't know. I'd assume people who ship it, like any regular
> distro, would be (re)distributors thereof. "Normal" (non-GPL) firmware
> images come with a redistribution license, but that obviously can't
> work here.
>
> There's some info from Ben here regarding the carl9170 case:
> http://lkml.iu.edu/hypermail/linux/kernel/1605.3/01176.html
>
>> Personally I still hope that linux-firmware itself is not legally
>> concerned with what is the content of firmware its hosting, but looks
>> like there already was a precedent case with carl9170 driver and
>> we have to somehow deal with it.
> That's really all I wanted to bring up. I'm not involved with the
> linux-firmware git tree.
>
>> There still may be a difference though: Quantenna is semiconductor
>> company only, software
>> used on actual products based on Quantenna chipsets is released by
>> other
>> companies.
>> I just want to present our legal team with a clear case (and position
>> of
>> Linux maintainers) so that they can
>> work with it and make decision on how to proceed.
>>
>> From technical perspective, as I mentioned, SDK is quite huge and
>> include a lot of opensource
>> components including full Linux, I don't think its reasonable to have
>> it
>> inside linux-firmware tree.
>> What are the options to share it other then providing it on request
>> basis:
>> - git repository
>> - store tarball somewhere on official website
> Clearly that wasn't deemed appropriate for carl9170, so I don't see why
> it'd be different here.
>
> johannes
On Tue, Nov 22, 2016 at 9:44 AM, IgorMitsyanko
<[email protected]> 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 th=
is
> clause in license file is enough:
> +Open Source Software. The Software may include components that are licen=
sed
> +pursuant to open source software (=E2=80=9COpen Source Components=E2=80=
=9D). Information
> +regarding the Open Source Components included with the Software is
> available
> +upon request to [email protected]. To the extent such Open Source
> +Components are required to be licensed to you under the terms of a separ=
ate
> +license (such as an open source license) then such other terms shall app=
ly,
> and
> +nothing herein shall be deemed or interpreted to limit any rights you ma=
y
> 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
> On 11/11/2016 02:35 PM, Johannes Berg wrote:
>>
>> Adding linux-firmware people to Cc, since presumably they don't
>> necessarily read linux-wireless...
>>
>>> Johannes, from that perspective, who are the "redistributors"?
>>> Specifically, is linux-firmware git repository considered a
>>> redistributor or its just hosting files? I mean, at what moment
>>> someone else other then Quantenna will start to be legally obliged to
>>> make GPL code used in firmware available for others?
>>
>> Look, I don't know. I'd assume people who ship it, like any regular
>> distro, would be (re)distributors thereof. "Normal" (non-GPL) firmware
>> images come with a redistribution license, but that obviously can't
>> work here.
>>
>> There's some info from Ben here regarding the carl9170 case:
>> http://lkml.iu.edu/hypermail/linux/kernel/1605.3/01176.html
>>
>>> Personally I still hope that linux-firmware itself is not legally
>>> concerned with what is the content of firmware its hosting, but looks
>>> like there already was a precedent case with carl9170 driver and
>>> we have to somehow deal with it.
>>
>> That's really all I wanted to bring up. I'm not involved with the
>> linux-firmware git tree.
>>
>>> There still may be a difference though: Quantenna is semiconductor
>>> company only, software
>>> used on actual products based on Quantenna chipsets is released by
>>> other
>>> companies.
>>> I just want to present our legal team with a clear case (and position
>>> of
>>> Linux maintainers) so that they can
>>> work with it and make decision on how to proceed.
>>>
>>> From technical perspective, as I mentioned, SDK is quite huge and
>>> include a lot of opensource
>>> components including full Linux, I don't think its reasonable to have
>>> it
>>> inside linux-firmware tree.
>>> What are the options to share it other then providing it on request
>>> basis:
>>> - git repository
>>> - store tarball somewhere on official website
>>
>> Clearly that wasn't deemed appropriate for carl9170, so I don't see why
>> it'd be different here.
>>
>> johannes
>
>
On 11/28/2016 07:34 PM, Kyle McMartin wrote:
> On Tue, Nov 22, 2016 at 9:44 AM, IgorMitsyanko
> <[email protected]> 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 [email protected]. 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?
It does include Linux environment with userspace tools, toolchain and
some other components that are not actually needed, you're right.
Maybe its possible to skip providing entire build environment, but
simply provide GPL code and patches to 3-d party opensource components?
Just state which version the patch is based on: for example, patch to
apply on top of Linux 3.14 sources, but no sources themselves. In this
case, it won't be possible to build firmware manually, but GPL code
modifications will be available.
>
> regards,
> --Kyle
>
>> On 11/11/2016 02:35 PM, Johannes Berg wrote:
>>> Adding linux-firmware people to Cc, since presumably they don't
>>> necessarily read linux-wireless...
>>>
>>>> Johannes, from that perspective, who are the "redistributors"?
>>>> Specifically, is linux-firmware git repository considered a
>>>> redistributor or its just hosting files? I mean, at what moment
>>>> someone else other then Quantenna will start to be legally obliged to
>>>> make GPL code used in firmware available for others?
>>> Look, I don't know. I'd assume people who ship it, like any regular
>>> distro, would be (re)distributors thereof. "Normal" (non-GPL) firmware
>>> images come with a redistribution license, but that obviously can't
>>> work here.
>>>
>>> There's some info from Ben here regarding the carl9170 case:
>>> http://lkml.iu.edu/hypermail/linux/kernel/1605.3/01176.html
>>>
>>>> Personally I still hope that linux-firmware itself is not legally
>>>> concerned with what is the content of firmware its hosting, but looks
>>>> like there already was a precedent case with carl9170 driver and
>>>> we have to somehow deal with it.
>>> That's really all I wanted to bring up. I'm not involved with the
>>> linux-firmware git tree.
>>>
>>>> There still may be a difference though: Quantenna is semiconductor
>>>> company only, software
>>>> used on actual products based on Quantenna chipsets is released by
>>>> other
>>>> companies.
>>>> I just want to present our legal team with a clear case (and position
>>>> of
>>>> Linux maintainers) so that they can
>>>> work with it and make decision on how to proceed.
>>>>
>>>> From technical perspective, as I mentioned, SDK is quite huge and
>>>> include a lot of opensource
>>>> components including full Linux, I don't think its reasonable to have
>>>> it
>>>> inside linux-firmware tree.
>>>> What are the options to share it other then providing it on request
>>>> basis:
>>>> - git repository
>>>> - store tarball somewhere on official website
>>> Clearly that wasn't deemed appropriate for carl9170, so I don't see why
>>> it'd be different here.
>>>
>>> johannes
>>
Am 28.11.2016 um 17:34 schrieb Kyle McMartin:
> On Tue, Nov 22, 2016 at 9:44 AM, IgorMitsyanko
> <[email protected]> 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 [email protected]. 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?
--
Regards,
Oleksij
On 11/10/2016 12:05 AM, Johannes Berg wrote:
> I understand, and I understand that you/they are actually providing it
> when asked.
>
> However, the carl9170 project has its (entirely GPL) source tree out in
> the open, making it much *easier* and that was *still* thought to not
> be sufficient; I don't recall the discussions but I'm guessing that's
> because of something like redistributors having to make sure source is
> available, and guaranteeing that for a long time, etc.
>
> johannes
Johannes, from that perspective, who are the "redistributors"?
Specifically, is linux-firmware git
repository considered a redistributor or its just hosting files? I mean,
at what moment
someone else other then Quantenna will start to be legally obliged to
make GPL code
used in firmware available for others?
Personally I still hope that linux-firmware itself is not legally
concerned with what is the content of
firmware its hosting, but looks like there already was a precedent case
with carl9170 driver and
we have to somehow deal with it.
There still may be a difference though: Quantenna is semiconductor
company only, software
used on actual products based on Quantenna chipsets is released by other
companies.
I just want to present our legal team with a clear case (and position of
Linux maintainers) so that they can
work with it and make decision on how to proceed.
From technical perspective, as I mentioned, SDK is quite huge and
include a lot of opensource
components including full Linux, I don't think its reasonable to have it
inside linux-firmware tree.
What are the options to share it other then providing it on request basis:
- git repository
- store tarball somewhere on official website
Thanks!
Adding linux-firmware people to Cc, since presumably they don't
necessarily read linux-wireless...
> Johannes, from that perspective, who are the "redistributors"?
> Specifically, is linux-firmware git repository considered a
> redistributor or its just hosting files? I mean, at what moment
> someone else other then Quantenna will start to be legally obliged to
> make GPL code used in firmware available for others?
Look, I don't know. I'd assume people who ship it, like any regular
distro, would be (re)distributors thereof. "Normal" (non-GPL) firmware
images come with a redistribution license, but that obviously can't
work here.
There's some info from Ben here regarding the carl9170 case:
http://lkml.iu.edu/hypermail/linux/kernel/1605.3/01176.html
> Personally I still hope that linux-firmware itself is not legally
> concerned with what is the content of firmware its hosting, but looks
> like there already was a precedent case with carl9170 driver and
> we have to somehow deal with it.
That's really all I wanted to bring up. I'm not involved with the
linux-firmware git tree.
> There still may be a difference though: Quantenna is semiconductor
> company only, software
> used on actual products based on Quantenna chipsets is released by
> other
> companies.
> I just want to present our legal team with a clear case (and position
> of
> Linux maintainers) so that they can
> work with it and make decision on how to proceed.
>
> From technical perspective, as I mentioned, SDK is quite huge and
> include a lot of opensource
> components including full Linux, I don't think its reasonable to have
> it
> inside linux-firmware tree.
> What are the options to share it other then providing it on request
> basis:
> - git repository
> - store tarball somewhere on official website
Clearly that wasn't deemed appropriate for carl9170, so I don't see why
it'd be different here.
johannes
On 29-11-2016 10:10, IgorMitsyanko wrote:
> 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:
[...]
>>> 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.
Why? The linux wireless subsystem supports both models, ie.
cfg80211-based drivers and mac80211-based drivers, so there is no
technical reason for making the effort. There are clearly benefits in
using a generic and freely available 802.11 stack like mac80211.
Regards,
Arend
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
>> <[email protected]> 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 [email protected]. 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.
--
Regards,
Oleksij
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
>>>> <[email protected]> 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 [email protected]. 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?
> 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 :)
--
Regards,
Oleksij