Just an update: I received a link to download an archive that contained several source code files, however they were for the wrong modem/router model; they were meant for the TG799vac sold by Telia (Swedish ISP) instead of for the TG789vac v2 as I requested, so they are useless to me.
The build instructions were unhelpful, too. There seems to be no main Makefile, no INSTALL file, no build script or anything similar, and the only text file included just says what dependencies are needed and what toolchain to use.
I asked them to correct the mistake as soon as possible and I told them that this is not a proper way to comply with an user's GPL request.
If anyone wants to get this source code archive anyway (for example, I see that the TG799vac is sold in Australia as the "Telstra Gateway Max") please send me a private message.
Regarding the archive, some files have a license header that states:
Unless you and Broadcom execute a separate written software license
agreement governing use of this software, this software is licensed
to you under the terms of the GNU General Public License version 2
(the "GPL"), available at http://www.broadcom.com/licenses/GPLv2.php,
with the following added to such license:
As a special exception, the copyright holders of this software give
you permission to link this software with independent modules, and
to copy and distribute the resulting executable under terms of your
choice, provided that you also meet, for each linked independent
module, the terms and conditions of the license of that module.
An independent module is a module which is not derived from this
software. The special exception does not apply to any modifications
of the software.
Not withstanding the above, under no circumstances may you combine
this software in any way with any other Broadcom software provided
under a license other than the GPL, without Broadcom's express prior
written consent.
I did not sign any NDA or other written agreement to do anything, neither with Technicolor, nor with Broadcom. Does this, therefore, mean that those files are under the GPLv2 with the above "special exception"?
Also, some files appear to mistakenly have a "this is proprietary software" header despite the fact that they are a part of Linux kernel modules that are clearly licensed as GPLv2 as a whole (they contain the MODULE_LICENSE("GPL") statement, and PDFs available on Technicolor's website state that such modules are licensed under the GPLv2;). Can I safely ignore that?
Regrettably, this is not a legal forum with specialty in copyright law.
You have stated "fact" in that you have not executed a "separate written software license" ("NDA" has nothing to do with that term of the agreement). You should be aware that linking GPL code to non-GPL code may violate the license of the non-GPL code. Distributing such an amalgam is even more challenging.
As I understand the language, and not as a licensed lawyer, "this proprietary software" means just that, unless described in the terms of a license agreement. From https://www.merriam-webster.com/dictionary/proprietary
proprietary -- something that is used, produced, or marketed under exclusive legal right of the inventor or maker; specifically : a drug (such as a patent medicine) that is protected by secrecy, patent, or copyright against free competition as to name, product, composition, or process of manufacture
In many legal agreements, it is important to identify what is considered proprietary. Doing so allows it to be referenced by other legal agreements, such as NDAs and licensing agreements. Even without a specific agreement applying to a specific bit of information, many companies make it standard practice to identify what information they consider to be "proprietary", "confidential", or the like.
Edit: Something can be considered "proprietary" and still be licensed under GPL. "It's ours, we own it, and grant you specific legal rights to it under the GPL."
Nor am I actively licensed, and what I can speak authoritatively on, is not copyright law, especially relating to software.
I can say this...about this part:
...if your device is Broadcom, that's exactly why those chips are not fully-supported with Open Source firmware projects (with the exception of DD-WRT, who is thought to have signed an NDA to provide the "proprietary" module, i.e. a full driver with things like 40+ MHz bandwidth activated).
This literally even prevents you from copying the drivers from routers with comparable CPU/Architecture/Kernel and simply pasting them into the correct locations (unless its for research, scholarship or some other excluded purpose, of course).
Licensing doubts aside, Technicolor has not yet complied with my original request.
I was told that they contribute to odhcpd, netifd and other projects linked to OpenWRT, but that still doesn't excuse their shameful behaviour.
@zen96 If/when you decide to lodge a formal complaint with the organization that manages OpenWRT licensing, I would be very clear on what you have requested from Technicolor, how they have responded, and which specific sections of the GPL and other licenses that you believe they have violated, and why.
@jeff I will surely include those details. I have already lodged a formal complaint, containing such details and even a nmap scan, with the Software Freedom Conservancy, that manages Samba and Busybox licensing, since these two softwares are being used in these devices too.
I was told that they will try to contact Technicolor to discuss the issue, but they said they have a long backlog of gpl violations and don't know when they could actually do so.
I only recently discovered that OpenWRT licensing might be managed by "Software in the public interest, inc.". I say "might" because the OpenWRT wiki is not very clear on what SPI's exact responsibilities are.
Except for the fact that the leaflet in the modem is vague (it doesn't even mention the GPL specifically) and contains wrong information on how to get the sources, the main violation is that Technicolor failed to provide the correct sources in a reasonable time (two months).
Yeah, the build "instructions" are useless, they list the dependencies needed for compilation and the name of the toolchain used, but not a single line on how to actually build anything.
The build scripts seem to be missing altogether, as there is no main Makefile or shell script or anything like that, just some Makefiles for single apps/modules, that obviously are useless on their own. The web interface seems to be missing too, despite Technicolor itself stating that it is open source.
@Ansuel Is anything else missing? I only looked at it quickly, since it was obviously not what I asked for, and so I was not particularly interested in it.
there are some file that have include (like otp.h) but the include file is not present at all...
They assembled the file wrong or they clearly omit some of them as this type of module are a bit critical and i think they are trying to hide something very very important...
Bump... I was told that the name of the archive I received is misleading, and that the code in it can actually be used to build for several different Technicolor modems, including mine.
While that is certainly possible, I still cannot verify it or build anything, since the root directory of the archive does not contain a makefile, a "build.sh" or any other similar script that generates an image to be flashed, and the build instructions are nonexistent. There are makefiles for the kernel or for single programs (dropbear etc) but they are not useful on their own. The GPLv2 says that all scripts for compilation and installation must be provided, and some crucial ones are clearly missing.
If someone else is having similar experiences with Technicolor, I encourage you to share them here.
I'm trying to see how much of a 17.2 image can be made starting from the sources you shared targeting the vant-6 board. The sources are for vant-f TG799vac from telia, which is also a MIPS board like vant-6, and the vant-6 board definitions are existing in the provided sources.
@flole While I did not upload that, I guess so. However that archive contains a main makefile, while mine doesn't.
My archive contains some modules, but not all of the ones that should have been in it according to Technicolor's own "Open Source Reports". Also, that archive is for the DGA4130 model (ARM-based) while my device is a TG789vac v2 (MIPS-based).
That archive is well explained in the related forum thread in italian.
It is an attempt to reconstruct a working buildroot starting from the canonical chaos calmer tree, patched to work with the older 3.4.11 linux kernel, and a brcm63xx-tch target reconstructed from Technicolor GPL archives released for two 63138 arm-based devices: VANT-W and VBNT-K
That buildroot has been made up with the only purpose of building arm binary-compatible versions of openwrt chaos calmer packages targeting the brcm63xx for two devices, the VBNT-K itself, and the newer VBNT-S.
Given that building chaos calmer userspace packages for mips is quite useless, since official packages available for both generic and smp subtargets of brcm63xx work fine, I'm trying to use the VANT-F source archive to do something similar. I would like to see if every GPL-derivated package they released in that archive is actually compilable with no need for a custom buildroot by Technicolor. and If this would be the case, then their release could be partially considered "valid" for your VANT-6 sources enquiry even if not compliant with the GPL terms..
For reference, here is a recap with some codenames to help you avoid confusion:
TG789vac v2
board id: VANT-6
cpu: 63268
arch: mips
TG799vac
board id: VANT-F
cpu: 63268
arch: mips
TG799vac XTREAM
board id: VANT-R
cpu: 63138
arch: arm
??
board id: VANT-W
cpu: 63138
arch: arm
TG789vac v2 XTREAM
board id: VBNT-F
cpu: 63138
arch: arm
DGA4130
board id: VBNT-K
cpu: 63138
arch: arm
also known with its italian ISP product code: AGTEF
DGA4131
board id: VBNT-O
cpu: 63138
arch: arm
DGA4132
board id: VBNT-S
cpu: 63138
arch: arm
also known with its italian ISP product code: AGTHP
@LuKePicci The tg789vac V2 has a 63168 cpu, as far as I know. That makes little difference anyway, since it's still MIPS and same clock speed. Sometimes the bootloader or other files say 63268 even if it is a 63168, because they are so similar. For example, the U-Boot Bootloader project grouped both under the 63268 name ( see this https://lists.denx.de/pipermail/u-boot/2017-April/287388.html )
I know, I used that id because it is the one which is referenced in the sources, the 63168 variant has only some differences in hardware we can safely ignore.
