search

jameshilliard / WECB-VZ-GPL

6 stars 14 forks source link

Proprietary code in repo... #3

Open nick77 opened 1 month ago

nick77 commented 1 month ago

Hi,

Looking at the repo, it looks like Actiontec had accidently released as GPL some proprietary code from Silicon Labs. If you look under rtl819x/linux-2.6.30/rtk_voip-sdk/voip_drivers/proslic_api-v5.0.3/si3217x_intf.h it states the code is proprietary and not to be released unless under written permission. Similarly version proslic_api-v5.6.4 code seems to be mostly proprietary. I used to work at Silicon Labs and they never give permission to give out this code as GPL. Also, I noticed the sourceforge tarball from the same original source has the same issue.

Most of the code (not all!) has:

/*
** Copyright (c) 2009 by Silicon Laboratories
**
** $Id: proslic_version.c 512 2009-03-20 15:21:29Z cdp@SILABS.COM $
**
** proslic_version.c
** ProSLIC API Version
**
** Author(s): 
** cdp
**
** Distributed by: 
** Silicon Laboratories, Inc
**
** This file contains proprietary information.   
** No dissemination allowed without prior written permission from
** Silicon Laboratories, Inc.

I suggest removing these proprietary files under these two directories.

jameshilliard commented 1 month ago

Looking at the repo, it looks like Actiontec had accidently released as GPL some proprietary code from Silicon Labs.

There appears to be similar sdk code in many other projects, how could a vendor legally ship a product based on this code without releasing this sdk code under a GPL compatible license?

If you look under rtl819x/linux-2.6.30/rtk_voip-sdk/voip_drivers/proslic_api-v5.0.3/si3217x_intf.h it states the code is proprietary and not to be released unless under written permission.

This appears to be part of a Linux kernel source tree that is GPLv2 Licensed, my interpretation is that this license file is effectively written permission to distribute this Silicon Labs driver code under the terms of the GPLv2 as it has been integrated into that project.

I used to work at Silicon Labs and they never give permission to give out this code as GPL.

If this code has been integrated into a Linux kernel source tree then it is my understanding that if the corresponding binary is publicly distributed(i.e. as part of embedded Linux device firmware) then the code in the corresponding kernel source tree would need to be provided under the GPLv2(or compatible) license.

nick77 commented 1 month ago

Hi James,

Thanks for responding quickly to this. Silicon Labs had in their software license preventing GPL'ing the ProSLIC API code. My guess is they (the integrators) may not notice this or they could of made it a kernel module separate from the kernel proper - I haven't dug through the makefiles to see if they did or did not. Some companies would release proprietary binary kernel modules to avoid the GPL. I do agree if it was built into the kernel, it should be GPL'd but, the license agreed to by the integrator from Silicon Labs would prevent this.

jameshilliard commented 1 month ago

Silicon Labs had in their software license preventing GPL'ing the ProSLIC API code.

Is this license published somewhere?

My guess is they (the integrators) may not notice this or they could of made it a kernel module separate from the kernel proper - I haven't dug through the makefiles to see if they did or did not.

In this case it literally has been integrated directly into the kernel source tree so it would be pretty hard IMO to argue that it's not a derivative work of the kernel at that point and would thus be subject to the kernel GPLv2 licensing requirements.

Some companies would release proprietary binary kernel modules to avoid the GPL.

I should note that distributing proprietary binary only kernel modules is generally not considered to be legal as the Linux kernel is GPLv2 licensed, this might be allowed if the kernel were say LGPL or similarly licensed but that is not the case.

I do agree if it was built into the kernel, it should be GPL'd but, the license agreed to by the integrator from Silicon Labs would prevent this.

Kernel modules not built into the kernel are still generally considered to be subject to the same GPLv2 requirements as built in drivers AFAIU.

nick77 commented 1 month ago

Hi James, Either case, based upon the directory structure file names. It seems that maybe RealTek didn't consider the software license for the ProSLIC API being proprietary and integrating it into a GPL environment. This from what I understand (IANAL), is not a valid combination and should be removed.

The case of proprietary kernel binaries - that is still up in the air. Some companies in the past released proprietary kernel binaries - yes there's some grumbling but, it was accepted.

jameshilliard commented 1 month ago

It seems that maybe RealTek didn't consider the software license for the ProSLIC API being proprietary and integrating it into a GPL environment. This from what I understand (IANAL), is not a valid combination and should be removed.

I mean, if the module was intended for being used on Linux systems then IMO it was designed for a GPL environment since the Linux kernel is GPL. If a company like Silicon Labs is providing their vendors with code that can not be legally used for the intended use case then I think it should be on them to fix their licensing agreements with their vendors.

The case of proprietary kernel binaries - that is still up in the air. Some companies in the past released proprietary kernel binaries - yes there's some grumbling but, it was accepted.

AFAIU most of those companies distribute an open source glue layer of some sort(usually dual licensed GPLv2 and some BSD style license) along with a binary object file that the end user is expected to compile and link against the kernel themselves.

From my understanding they design their drivers it this way since the GPLv2 requirements only trigger on distribution(you can mix proprietary and GPLv2 code if you don't distribute the compiled binary). Note the GPLv2 incompatible CDDL licensed zfs kernel modules for Linux are typically provided in source form for roughly the same reason.

Presumably those companies assume that by distributing a binary object that has not yet been linked to the kernel and by letting the end user link it to the kernel themselves using dual licensed glue code they can avoid triggering the GPLv2 by avoiding distribution of a binary that has been prelinked to the kernel. It's unclear if this is actually a legal way of avoiding the GPLv2 requirements. As that technique is effectively impossible for embedded systems like this code is used for(due effectively requiring a functional compiler/toolchain on the device) I don't think this would be applicable here.

nick77 commented 1 month ago

Hi James,

The driver code provided from Silicon Labs is OS agnostic - meaning it can be run on barebones MCUs to an RTOS to a general purpose OS like Linux or even environments such as MSYS or Cygwin. It has been known to run in all the forementioned environments. It wasn't designed specifically for Linux - so they designed a "systems services layer" that the end producer of the product is to implement. So your argument that saying the license is broken because it's meant to run on only Linux is faulty.

In either case, the repo you have HAS proprietary code in it and should those files should removed. Unless you are arguing that you have written permission from Silicon Labs to distribute the code.

It seems that Realtek (I'm assuming they did the work) didn't consider their software architecture/license environment when developing their code. I've seen setups where the code runs in userspace - which would avoid the GPL - as long as they pick the correct libraries to dynamically link against. Too bad whoever did the integration didn't think of this.

jameshilliard commented 1 month ago

It wasn't designed specifically for Linux - so they designed a "systems services layer" that the end producer of the product is to implement. So your argument that saying the license is broken because it's meant to run on only Linux is faulty.

I mean if it was designed to run in the Linux kernel at all(not only Linux neccesarially) by Silicon Labs then it would appear to me that if Silicon Labs were to impose some no combining with GPLv2 code restriction on vendors then that restriction would mean the code can not be legally used in the way as advertised by Silicon Labs.

I see here it states the following:

The ProSLIC API incudes example Linux® kernel and userspace device driver examples to further reduce development time.

So it seems pretty clear to me that vendors using a "ProSLIC API" Linux kernel driver is an intended use case by Silicon Labs and as such they should have been aware that a Linux kernel driver would be subject the code to GPLv2 requirements.

In either case, the repo you have HAS proprietary code in it and should those files should removed. Unless you are arguing that you have written permission from Silicon Labs to distribute the code.

I'm arguing that Silicon Labs appears to have knowingly distributed a "ProSLIC API" Linux kernel driver example to their vendors that they should have known would be subject to GPLv2 requirements. By distributing these Linux kernel driver examples to their vendors Silicon Labs may have automatically given their vendors the right to redistribute any binaries and source code under the GPLv2.

It seems that Realtek (I'm assuming they did the work) didn't consider their software architecture/license environment when developing their code. I've seen setups where the code runs in userspace - which would avoid the GPL - as long as they pick the correct libraries to dynamically link against. Too bad whoever did the integration didn't think of this.

Considering Silicon Labs does actually advertise a "ProSLIC API" Linux kernel driver, I think it would be difficult to argue that this is a case of a vendor simply violating their licensing agreement with Silicon Labs.

nick77 commented 1 month ago

The Linux kernel driver provided by Silicon Labs architecture is completely different from what you have in your repo. It had followed what other proprietary drivers have done.

jameshilliard commented 1 month ago

The Linux kernel driver provided by Silicon Labs architecture

So this code is licensed differently by Silicon Labs?

nick77 commented 1 month ago

Hi James,

The systems services layer is GPL/MPL - it has things like the timer delay, SPI read/write functions, and reset. The rest, which your repo is in non-compliance is proprietary. BTW, the code that I'm guessing Realtek did for Linux is theirs. PLEASE TAKE THIS DOWN THE PROPRIETARY CODE NOW.

Nick

jameshilliard commented 1 month ago

The rest, which your repo is in non-compliance is proprietary.

Which files are these specifically?

nick77 commented 1 month ago

Hi James,

Under: rtl819x/linux-2.6.30/rtk_voip-sdk/voip_drivers/proslic_api-v5.0.3/ and rtl819x/linux-2.6.30/rtk_voip-sdk/voip_drivers/proslic_api-v5.6.4L/:

I did notice some files were modified - for example si3217x_intf.c has a comment "added by Joshua" - I would of put it in a header file and keep the original file "clean". Also I saw some header files were added - like linux/slab.h and others - that isn't one in the "clean" version - since below is a #ifdef WIN32 - which wouldn't work for Windows if someone added linux/slab.h to the C file.

I think the above is the complete list. I did try to go over items I wasn't 100% certain on. I mainly reviewed the 5.03 versions and spot checked the 5.4.6L versions.

Nick

jameshilliard commented 1 month ago

  • custom directory - everything except the Makefile

  • inc directory - everything except sys_driv_type.h, si3226_userdef.h

  • src - everything except Makefile, proslic_ctrl_spi.c, proslic_timer_linux.c, si3217x_userdef.c and si3226_userdef.c (although these two files has Silicon Labs copyright, it's really Realtek's code based upon Silicon Labs application notes and example code).

Hmm, these seem to have functions that are imported by other parts of the code, so it would seem removing them would break the build and thus would make the GPL release non-compliant(as it would need to be the complete corresponding source code for the binaries being distributed by vendors).

I used to work at Silicon Labs and they never give permission to give out this code as GPL.

By the way your email at silabs was nizajerk@SILABS.COM right? I'm curious what your current interest in this code is if you no longer work there. As there are numerous other copies of this code that have been published publicly it's unclear why this version specifically is problematic and the others aren't.

nick77 commented 1 month ago

Hi James,

So the implementor, IMHO, didn't do their job correctly. It should of not been available until the compliance issue was fixed, IMHO. Possibly a proprietary kernel module refactoring.

Yes, that was my email address back at Silicon Labs. So, I do work for the company that bought the division that makes the ProSLIC product line now. I occasionally see if some of the files are findable via some of the search engines out there. Typically a DMCA takedown notice is sent out to the offending party. You mentioned a few other places have the code - at least a few have been already been contacted - it's a whack a mole problem.

One thing to be careful of - so for example si3050.c I sometimes see - that is part of an open source project based upon application notes of that part and is whatever license the project used. I also see si3210/si3215 also part of an open source project.

jameshilliard commented 1 month ago

So the implementor, IMHO, didn't do their job correctly. It should of not been available until the compliance issue was fixed, IMHO. Possibly a proprietary kernel module refactoring.

If I purchase a product containing GPL code I essentially need to GPL request the complete corresponding firmware source code in order to resell the product down the line as reselling the product would itself be redistribution of the firmware binary and thus would have GPL compliance requirements. Going around effectively killing GPL source releases is thus highly problematic as you then make it then impossible to resell the product legally. I don't think violating the rights of consumers would be an appropriate response to a vendor violating their licensing agreement with a supplier.

Typically a DMCA takedown notice is sent out to the offending party.

What about binary vendor firmware downloads containing the GPLv2 license violating code? I've sent copyright violation take-downs myself to companies like amazon that often distribute random products which contain GPL violating firmware to try and force compliance(I'm a contributor to many GPL licensed projects including the Linux kernel and a top contributor to the well known buildroot embedded Linux project so many of these products violate my copyright as well). Are these companies you've worked for just recommending vendors to ship illegal firmware binaries by telling them not to comply with the GPL and to stop distributing GPL releases or are they actually taking concrete steps to ensure their firmware is legal?

You mentioned a few other places have the code - at least a few have been already been contacted - it's a whack a mole problem.

So what's the point of not allowing this code to be used under GPLv2 terms? I mean it's clearly not some super closely held trade secret if a ton of different vendors have access to it and are publishing it publicly. It's also likely very hardware specific(so not very useful to competition). Suppliers playing licensing games with driver source code to scare vendors into not complying with the GPL is a huge issue IMO. What do these companies you work for actually do to ensure their vendors aren't violating GPL licenses when building firmware based on your code?