Experiences of Huawei providing source-code?

[TJ]

On 28th October I requested from Huawei the source-code for the VMG8324-B10A and VMG8924-B10A, BCM63168-based VDSL/ADSL integrated access devices released in May 2013 with Linux 2.6.30, Busybox, and
other major FL/OSS GPL/LGPL applications installed.

Detailed information on the devices is being assembled in my wiki at http://tjworld.net/wiki/Zyxel/VDSL_IAD

I received a response on 29th October asking which firmware version the devices had which I replied to immediately.

On 30th October I received a response:

"We will provide package(V1.00(AAKL.0)C0) to you on 11/18/2013
Please wait patiently. Thank you."

Today - 19th November - I received another email:

"Sorry, since this package has some issue we need fix it, we will provide package on 11/28
Sorry for any inconvenience."

What are other's experiences in getting the correct, buildable, source-code packages from Huawei?

[Anto Cvitić]

They are also stalling on providing sources for a LTE router. In the emails
they sounded both ignorant and nice and told me the sources will be
availabe after consultation with their technical team. Its been over a
month now with nothing.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 28th October I requested from Huawei the source-code for the
VMG8324-B10A and VMG8924-B10A, BCM63168-based VDSL/ADSL integrated access
devices released in May 2013 with Linux 2.6.30, Busybox, and
other major FL/OSS GPL/LGPL applications installed.
Detailed information on the devices is being assembled in my wiki at
http://tjworld.net/wiki/Zyxel/VDSL_IAD
I received a response on 29th October asking which firmware version the
devices had which I replied to immediately.
"We will provide package(V1.00(AAKL.0)C0) to you on 11/18/2013
Please wait patiently. Thank you."
"Sorry, since this package has some issue we need fix it, we will provide package on 11/28
Sorry for any inconvenience."
What are other's experiences in getting the correct, buildable,
source-code packages from Huawei?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKLRRcACgkQ7+w3pCnNYIDzcwCg4XO6J/DKHHOiFwA3tE5i5XAM
5tQAn1UAh2q5QNhqR1Hqw4e0eODeLXoN
=gRYG
-----END PGP SIGNATURE-----

[Shenfen (Navia)]

Hi,

I am sorry to hear that.

Please be noted that there is an internal procedure for disclosing any kind of source code in Huawei. That is why the procedure will be a little longer. Anyway, the source code has been prepared for disclosure as per user's request.

I will ask Huawei to release the code as soon as possible. And we will contact you soon.

Any further questions, please contact me directly.

Navia from Huawei.

-----邮件原件-----
发件人: TJ [mailto:gpl-***@iam.tj]
发送时间: 2013年11月19日 19:02
收件人: GPL
主题: Experiences of Huawei providing source-code?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28th October I requested from Huawei the source-code for the VMG8324-B10A and VMG8924-B10A, BCM63168-based VDSL/ADSL integrated access devices released in May 2013 with Linux 2.6.30, Busybox, and other major FL/OSS GPL/LGPL applications installed.

Detailed information on the devices is being assembled in my wiki at http://tjworld.net/wiki/Zyxel/VDSL_IAD

I received a response on 29th October asking which firmware version the devices had which I replied to immediately.

On 30th October I received a response:

"We will provide package(V1.00(AAKL.0)C0) to you on 11/18/2013 Please wait patiently. Thank you."

Today - 19th November - I received another email:

"Sorry, since this package has some issue we need fix it, we will provide package on 11/28 Sorry for any inconvenience."

What are other's experiences in getting the correct, buildable, source-code packages from Huawei?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKLRRcACgkQ7+w3pCnNYIDzcwCg4XO6J/DKHHOiFwA3tE5i5XAM
5tQAn1UAh2q5QNhqR1Hqw4e0eODeLXoN
=gRYG
-----END

[TJ]

On 21/11/13 00:44, Shenfen (Navia) wrote:

Thank-you for replying.

Post by Shenfen (Navia)
Please be noted that there is an internal procedure for disclosing any kind of source code in Huawei. That is why the procedure will be a little longer. Anyway, the source code has been prepared
for disclosure as per user's request.

That is good to hear.

However, would it not be a better practice to maintain the FL/OSS parts in an internal repository as an integral part of the device development process, tag each firmware release, and simply push
that to a public (git) repository or produce a tar-ball?

That way there would be zero extra effort to comply with the copyright obligations and an added benefit that end-users can be assured that the source-code they work with matches precisely the
firmware version in the device.

[Shenfen (Navia)]

Thank you for your suggestion. It is quite useful.

We are improving.

-----邮件原件-----
发件人: TJ [mailto:gpl-***@iam.tj]
发送时间: 2013年11月21日 9:05
收件人: GPL
主题: Re: 答复: Experiences of Huawei providing source-code?

On 21/11/13 00:44, Shenfen (Navia) wrote:

Thank-you for replying.

Post by Shenfen (Navia)
Please be noted that there is an internal procedure for disclosing any
kind of source code in Huawei. That is why the procedure will be a little longer. Anyway, the source code has been prepared for disclosure as per user's request.

That is good to hear.

However, would it not be a better practice to maintain the FL/OSS parts in an internal repository as an integral part of the device development process, tag each firmware release, and simply push that to a public (git) repository or produce a tar-ball?

That way there would be zero extra effort to comply with the copyright obligations and an added benefit that end-users can be assured that the source-code they work with matches precisely the firmware version in the de

[Jonathan Wilson]

Post by TJ
However, would it not be a better practice to maintain the FL/OSS parts

in an internal repository as an integral part of the device development
process, tag each firmware release, and simply push

Post by TJ
that to a public (git) repository or produce a tar-ball?

It would be impossible to expect that every change to a FOSS package
(kernel, busybox, whatever else) be vetted to make sure its legally clean
and releasable before it was pushed to the internal tree. (speaking from my
own experience working at a company doing embedded devices, it would have
been impossible to get anything done if your team's part of the software
was FOSS and you had to get every change signed off by
legal/copyright/licensing people before pushing it)

And its not just code that the manufacturer has licensed from a 3rd party
and has to be careful about how they release it. Licenses and NDAs for
hardware chips and such contain rules about how much information the
company using the chip is allowed to disclose. Licenses for software
technology and patents (e.g. proprietary file systems) might contain
restrictions on distributing that information. Regulatory reasons might
make sharing the source code hard. (e.g. restrictions on power and
frequency for various radio standards where opening the source might make
it possible to change those beyond the allowed limits) Carriers and ISPs
might not want the source distributed because it could be used to enable
features those carriers and ISPs dont want on their networks or because
people messing with the software could cause harm to the devices or to the
networks those devices talk to.

Getting all the legal things right to make sure that the source code is in
compliance with the FOSS licenses it is releases under AND with all the
other licenses, NDAs, contracts and agreements the manufacturer may have
signed that pertain to the device (or might pertain to the device) is hard
and takes time.

[TJ]

Post by TJ

Post by TJ
However, would it not be a better practice to maintain the FL/OSS parts

in an internal repository as an integral part of the device development process, tag each firmware release, and simply push

Post by TJ
that to a public (git) repository or produce a tar-ball?

It would be impossible to expect that every change to a FOSS package (kernel, busybox, whatever else) be vetted to make sure its legally clean and releasable before it was pushed to the internal
tree.

I disagree completely - in fact it makes the process much easier for both developers and legal bodies to review.

In the case of projects based on the Linux kernel the cleanest work-flow is to use git as the DVCS, and in particular its submodule abilities, where the master repository is for the device, and the
submodules are for the components that make up the entire project - FL/OS and proprietary, e.g.:

mkdir our_device_01 && cd our_device_01
git init
mkdir legal
git add legal
git commit -s -S$MY_GPG_KEYID -m 'Keep all legal correspondence here'
git remote add public ssh://***@www.myco.com:~/git/our_device_01.git
git submodule add git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux
git submodule init linux
git submodule add git://busybox.net/busybox.git busybox
git submodule init busybox
...
git submodule foreach git remote add public ssh://***@www.myco.com:~/git/$name
...
cat >open_source_submodules.list <<EOT
linux
busybox
EOT

git add open_source_submodules.list
git commit -s -S$MY_GPG_KEYID -m 'list of Open Source submodules to be publicly released'
...
git submodule add file://path/to/internal/closed-source/project_1 proprietary_project_1
git submodule init proprietary_project_1
...
git branch -b new-feature-01
...
git add .
git commit -s -S$MY_GPG_KEYID -m 'Integrate new feature 01'
...
mailx -c ***@myco.com -s "Please review branch new-feature-01 of project our_device_01" ***@myco.com
...
# read email
mailx
O 1 legal@@myco.com Thu Nov 21 16:01 31/545 "Release Approved"
# approval received
type 1
save +legal
exit
git add legal/*
git commit -s -S$MY_GPG_KEYID -m 'Release Approved'
git checkout master
git merge new_feature_01
git tag -s -m "Add new feature 01"
...
for module in open_source_submodules.list; do
pushd $module
git push public master
popd
done

This allows per-commit traceability in the device project and all its constituent parts, with clean and obvious separation between the FL/OS and closed-source parts.

When the firmware is ready for release it is straight-forward to review the commits to the FL/OS parts before signing it off with a signed tag in the master repo which also binds the state of the
submodules. The FL/OS parts can then be pushed to a public repository or tar-balled.

[Solomon Peachy]

Post by TJ
I disagree completely - in fact it makes the process much easier for
both developers and legal bodies to review.

I concur, but I'd go a little further.

A lifetime ago, I worked for a company that supplied Linux BSPs for
folks building wireless routers. Our build system cleanly separated
everyting based on license -- GPL and GPL-like (ie requiring source
code), other F/OSS (eg Apache or BSD licensed), and proprietary (eg
custom UI elements). At build time, it would create a set of images for
the target, and a corresponding tarball of all GPL'd source code used in
that build. Completely automatically.

What's sad is how few actually managed to get source tarballs published.

- Solomon

[Jonathan Wilson]

Post by TJ
I disagree completely - in fact it makes the process much easier for

both developers and legal bodies to review.
Yeah it is possible to keep the GPL bits separate from the non-GPL bits but
whats not possible is to eliminate the lengthy process that has to be
undertaken to make sure that whats in the "GPL" or "open source" parts of
the tree IS in fact releasable (i.e. the delays many companies seem to have
after releasing new firmware before they release the source code)

[Solomon Peachy]

Post by Jonathan Wilson
It would be impossible to expect that every change to a FOSS package
(kernel, busybox, whatever else) be vetted to make sure its legally
clean and releasable before it was pushed to the internal tree.

That has nothing to do with F/OSS in particular, they need to perform
this diligance before incorporating *any* code in their product.

Post by Jonathan Wilson
devices, it would have been impossible to get anything done if your
team's part of the software was FOSS and you had to get every change
signed off by legal/copyright/licensing people before pushing it)

Frankly if that is the case, they have no business using F/OSS. They
know *in advance* they are required to release the corresponding source
code to the binaries. That's the price they pay for not having to write
everything from scratch.

Ten years ago they may have been able to plead ignorance, but today?
Come on.

Post by Jonathan Wilson
And its not just code that the manufacturer has licensed from a 3rd
party and has to be careful about how they release it. Licenses and
NDAs for hardware chips and such contain rules about how much
information the company using the chip is allowed to disclose.

....Then they can write their whole system from scratch, and not
freeload off of others' hard work.

Post by Jonathan Wilson
Licenses for software technology and patents (e.g. proprietary file
systems) might contain restrictions on distributing that
information. Regulatory reasons might make sharing the source code
hard.

The GPL's requirements are clear. If you don't grant downstream users
the same rights as you were given, then you're not allowed to
re-distribute that GPL software. It really is that simple.

Post by Jonathan Wilson
Getting all the legal things right to make sure that the source code
is in compliance with the FOSS licenses it is releases under AND
with all the other licenses, NDAs, contracts and agreements the
manufacturer may have signed that pertain to the device (or might
pertain to the device) is hard and takes time.

I don't disagree, but I should point out that the time to do this is
*before* you start shipping product, not months afterwards!

- Solomon

[Robinson Tryon]

Post by Jonathan Wilson

Post by TJ
However, would it not be a better practice to maintain the FL/OSS parts in
an internal repository as an integral part of the device development
process,

...
It would be impossible to expect that every change to a FOSS package
(kernel, busybox, whatever else) be vetted to make sure its legally clean
and releasable before it was pushed to the internal tree

Having a lawyer-filter on a git repo would kill productivity, but the
vetting process has to happen before a product ships. If you're on a
tight release schedule, you've got to budget the appropriate amount of
time for review, whether that's a little time each week or a big chunk
of time at the end of the project.

Post by Jonathan Wilson
... Getting all the legal things right to make sure that the source code is in
compliance with the FOSS licenses..[and etc].. is hard
and takes time.

Indeed it can. But if you only take this step after shipping a
product, there's no way to revert code that can't legally be released.

Or to put it another way, if you clean your car each week, it will
stay relatively tidy. If you wait for only once a year, you might find
a stain on the carpet that has set and will never come out.

--R

[TJ]

Post by TJ
On 28th October I requested from Huawei the source-code for the VMG8324-B10A and VMG8924-B10A, BCM63168-based VDSL/ADSL integrated access devices released in May 2013 with Linux 2.6.30, Busybox,
and other major FL/OSS GPL/LGPL applications installed.

Thanks to Shenfen (Navia), lawyer at Huawei, who wrote pointing out that Huawei don't make these devices - ZYXEL do! I realised I'd transposed the ZYXEL name to HUAWEI in the email. So, apologies to
Huawei for incorrectly attributing the devices and communications to them.

I'm currently reverse-engineering devices from several manufacturers; including devices from Huawei and these devices from *ZYXEL*. I believe when I wrote this thread I was working on emails about
both manufacturer's devices simultaneously and accidentally transposed the manufacturer's name.

The emails I sent, and replies received, were to/from *ZYXEL* and the title of this thread should be "Experiences of ZYXEL providing source-code" - everything else written remains correct and accurate.

Sorry Huawei (although attempting to build binary equivalent Linux kernels for many of your devices from the provided source-code frequently doesn't happen as it should)!

[TJ]

Post by TJ
On 28th October I requested from Huawei the source-code for the VMG8324-B10A and VMG8924-B10A, BCM63168-based VDSL/ADSL integrated access devices released in May 2013 with Linux 2.6.30, Busybox,
and other major FL/OSS GPL/LGPL applications installed.
Detailed information on the devices is being assembled in my wiki at http://tjworld.net/wiki/Zyxel/VDSL_IAD
I received a response on 29th October asking which firmware version the devices had which I replied to immediately.
"We will provide package(V1.00(AAKL.0)C0) to you on 11/18/2013 Please wait patiently. Thank you."
"Sorry, since this package has some issue we need fix it, we will provide package on 11/28 Sorry for any inconvenience."
What are other's experiences in getting the correct, buildable, source-code packages from Huawei?

Today, 29th November I received a further email saying they (ZYXEL) cannot provide the source:

"I am very sorry, we can't on time to release this package, since we are still working on solving some problem of this package, and would release it to you as soon as we complete it."