[LEDE-DEV] NETSHe mac80211 GPL sources

Sat Feb 4 22:51:49 PST 2017

Hi Daniel,

Please find my comments below.

On 04.02.2017 22:35, Daniel Golle wrote:
> Hi Stas,
>
> On Fri, Feb 03, 2017 at 03:58:15PM +0300, Stanislav V. Korsakov wrote:
>> Hi Daniel,
>>
>> Why do you think that all our TDMA-related modifications must be under
>> GPL license?
> As you are using cfg80211 and mac80211 I just guessed that chances are
> high that you'd also use ath9k and modified it.
>
>> We use cfg80211, mac80211, ath5k and ath9k with very small modifications
>> to support new type of interface and to handle some new netlink commands.
>> We call own dual licensed module from mac80211 to handle new type of
>> interface. Some code to provide new functionality is placed in our
>> proprietary licensed driver. This driver does not use any GPL exported
>> calls/symbols from the kernel and other drivers. Code from this module
>> is used from our dual licensed module only. This module taints kernel.
>>
>> In our mind, we do not breach GPL v2 with this architecture.
>> Thus, we have two parts of source code:
>> 1. GPLed and dual-licensed. We provide this source code to our
>> customers. Any customer can open GPLed part if he wish to do it. Why
>> should we provide it for everyone (not customers)? Please point me to
>> GPL v2 license term which has this requirements. Not your interpretation.
>> 2. Closed source for our proprietary module.
> Ok, thanks a lot for the clarifications. That's indeed a clean solution
> as far as I can judge.
>
>
>> We do not share our binaries for everyone since v3.2. All GPLed code
>> (including patches) is available in a free access for v3.2.
> Is that the code on sourceforge.net?
We did not upload any files to sourceforge around five years.
I checked now and found that we closed access to build environment and
patchset sources between versions 2.1 and 3.2. So, I am wrong. Will fix it.
>
>> At least, we try to keep copyrights and software licenses and I do not
>> see license breaches now. You can find what we build our firmware, what
>> we used and how. E.g. how we use OpenWRT and what is the difference. We
>> do not hide it.
>> If you found breaches - inform me to cancel.
> That's not the road I'm going for ;) I'm just interested in code, I am
> not an expert on legal/license things.
>
>> About idealistic...
>> I did not see long time and effective working just for fun only...
>> Programmers want to eat...
> Of course, same here. From a labour perspective FOSS can also be seen
> as quite a nightmare -- not long ago, companies needed to hire people
> and then educate them while paying them. Today, you're expected to be
> self-educated and nobody cares how people are feeding themselves while
> studying free software code...
>
>> Open source is very good and helpful thing. Let discuss how we can help
>> but keep in mind that we need to earn money too.
> Imho this conversation can already be seen as a contribution.
> To avoid confusion in future, it'd be great if you made sure that the
> GPL'ed part of the sources can be found right next to the binaries as
> well as on webpages linking to those binaries.
>
> Another good concept could be to make sure stuff goes public once you
> longer have commercial interest in it. That will allow e.g. securiy
> audits of outdated gear in the field and also help future generations
> to understand history and evolution of software. CodeWeavers and the
> wine folks get's that right, imho, but it's a rare thing. Most of the
> time, stuff just disappears and future researchers are left in the
> dark when the try to figure out what happened 10 years ago.
>
>> Excuse me my bad English. Hope, I explained our point of view...
> No worries, your English is good and I didn't have any problems
> understanding what you were writing.
> Thank you for your time and for explaining things!
>
>> Now about implementation details if it still interesting...
>>
>> Our implementation is completely different from Ubiquiti or FreeBSD's.
>> In my mind, first uses PCF mode variation. Second is original but i do
>> not impress how it works in noisy environment.
>> For our implementation, closest mode is AdHoc with own scheduler.
>> Scheduler is implemented in software completely.
>> Our implementation is well for narrow channels and not big mesh networks
>> (and we do own mesh implementation above TDMA) but lost efficiency with
>> wide channels. We can not utilize HT/VHT  and have bigger delay by design.
> That's indeed quite different from what I expected. But surely makes
> sense for long-distance links where QoS and reliability is a most, I
> imagine that VoIP should work very well using your solution.
> However, for the purpose I had in mind (wireless community ISP in urban
> areas) I'd rather have MiMo and more throughput as links are rather
> short compared to what you are doing. Nevertheless, I'm impressed by
> your report of 30km+ stable links!
We plan to design new TDMA-like implementation for infrastructure in
this year to close our gap in delay and efficiency for wide channels and
802.11ac.
The main issue for us is that we can not implant A-MPDU in real TDMA
design.... We can not predict (or get) A-MPDU tx time exactly.

For now, we do not have clear and exact understanding of result design
but plan to use next things:
1. event driven synchronization between nodes;
2. MSDU aggregation;
3. individual (may be group) acknowledgements with data frames (like CF
Ack) or special unicast frames.

If it is interesting, we can discuss possible cooperation. At least, we
can share some our ideas and experience (may be not so right) for any
open source initiative in this area.

Regards, Stas

PS. I am in a trip this week and can not reply quickly.

>
>
> Cheers
>
>
> Daniel
>
>
>
>> Regards, Stas
>>
>>
>> On 03.02.2017 13:40, Daniel Golle wrote:
>>> Hi Stas,
>>>
>>> thanks for the quick reply!
>>>
>>> I'm looking for a good way to replace ubiquiti's proprietary TDMA
>>> implementation with something which could be vendor-independent and
>>> interoperable -- and ideally Free Open Source Software.
>>> As TDMA has been implemented for ath9k in FreeBSD, I was wondering if
>>> a similar extension to mac80211 has been made -- and found NETSHe's
>>> wireless stack. As ath9k, mac80211 and the Linux kernel are under the
>>> GPL license, I was assuming that NETSHe's modifications to support
>>> TDMA thus must be available under the GPL licensed as well.
>>>
>>> So from what I understand you are using your own proprietary driver
>>> instead of ath9k? Yet, cfg80211 and mac80211 seem to be involved
>>> according to what I found in TDMA_brief_en.pdf, as TDMA interfaces
>>> are added obviously added through nl80211. Earlier today I also
>>> realised that this has previously been discussed on this mailing
>>> list, see
>>> https://lists.openwrt.org/pipermail/openwrt-devel/2015-July/034374.html
>>>
>>> As you are offering a binary version of the firmware for download,
>>> according to the GPL you are oblidged to also share the portion of
>>> the source code which is under GPL (ie. at least the Linux kernel,
>>> GPL'ed wireless drivers like ath9k, libnl, the 'iw' userspace, ...)
>>> as well as all modifications you've made to that GPL licensed code.
>>>
>>> Obviously you could easily avoid that legal requirement by just not
>>> offering a free download of the binaries, so don't get me wrong, I
>>> do appreciate your openness! Yet, it'd be great if we had a shared
>>> codebase for TDMA instead of a growing number of competing
>>> implementations (ubnt, mikrotik, Deliberant's iPoll, NETSHe, ...) each
>>> being developed behind closed doors. As your implementation is built
>>> upon GPL'ed code and you offer binaries for download, please also
>>> share the patches for iw, libnl, cfg80211, mac80211 and ath*k.
>>> By the end of the day, you are using 99% code which other people have
>>> written and published under the assumption that everyone is granted
>>> the freedom to run, study, share and modify the software.
>>> "The GPL is a copyleft license, which means that derivative work can
>>> only be distributed under the same license terms." [1]
>>> However, I'm not a lawyer and I have simply no idea if the GPL can
>>> actually be enforced in the judicative domain NETSHe is located in or
>>> whether we are talking about a purely idealistic/moralic issue here.
>>>
>>> Anywa, my interest is to use and improve that code! Friends of mine
>>> have started a non-profit collaborative ISP project [2] and we are
>>> having a heated debate whether to use OpenWrt/LEDE from source or
>>> ubnt's proprietary firmware on ubnt and other ath9k-based hardware.
>>> Even though Wifi performance on ath9k recently improved a lot, a TDMA
>>> implementation under a free license (ie. GPL) would be great thing to
>>> have, also for use in Wireless Community Mesh Networks.
>>>
>>> A good compromise could be to publish the code without the userspace
>>> tools allowing AES crypto -- in that way, free community networks
>>> can use that implementation and commercial entities would need to
>>> license the crypto bits if they want link-level crypto.
>>>
>>>
>>>
>>> Cheers
>>>
>>>
>>> Daniel
>>>
>>> [1]: https://en.wikipedia.org/wiki/GNU_General_Public_License
>>> [2]: https://www.reudnetz.org/
>>>
>>>
>>> On Fri, Feb 03, 2017 at 09:35:30AM +0300, Stanislav V. Korsakov wrote:
>>>> Hi Daniel,
>>>>
>>>> Please check this article http://netshe.ru/wirelessstack to understand
>>>> layering of our modifications in Linux wireless stack. You can see that
>>>> we add proprietary licensed and dual licensed drivers in wireless stack.
>>>> We provide our GPLed and dual licensed source codes to our customer only.
>>>> Not our source code is available at http://gw.stasoft.net/dl/
>>>>
>>>> Can you tell me what is your real interest?
>>>>
>>>> Regards, Stas
>>>>
>>>>
>>>> On 03.02.2017 03:43, Daniel Golle wrote:
>>>>> Hi!
>>>>>
>>>>> NETSHe offers a modified version of ath9k, mac80211 and cfg80211 which
>>>>> offers support for TDMA, see:
>>>>> http://netshe.ru/files/doc/en/TDMA_brief_en.pdf
>>>>>
>>>>> Where to download the sourcecode of mac80211 and the modified drivers?
>>>>>
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> Daniel
>>>> _______________________________________________
>>>> Lede-dev mailing list
>>>> Lede-dev at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/lede-dev