GPL Distribution Clauses?

I noticed something which can cause confusion about the gpl distribution
and would need to be clarified. This is also important for device
resellers (In particular those who deal with android).

I'll start off with stating that all android devices include a list of
open gpl notices in the device. Although, sometimes this is outdated
because the device manufacturer adds other components that are under the
gpl... A short list of what is frequently used, but not included in the
open source notices are Busybox ( /system/bin/busybox), gdbserver
(/system/bin/gdbserver), and u-boot. There's frequent cases where anyone
can download the firmware without any qualms. This here is where the
problem starts.

1) If i download the firmware from their site, am i automatically
entitled to the gpl source release? I know that for GPL v2 it's a bit
tough to figure out, and as for GPL V3 it's as long as i have the
binary.

2) If said firmware includes a full copy of the GPL license, can that be
viewed as an valid Source offer in it's self. (Linux kernel should
always be  in the legal notices).

3) Is the source of the distribution in violation of the GPL for
refusing a request for the source after one downloads the firmware.

On a side note, there's a lot of places which have this particular
problem. Most of the time the problem has it's origin being with a
Chinese based company. I'll also make note that a few good examples of
this are Zenithink, Witstech, and Smart devices.

Re: GPL Distribution Clauses?

(IANAL, but hopefully someone who is will correct me where I am wrong.)

On Thu, 2010-12-02 at 18:51 -0600, Kenney Phillis wrote:
> I noticed something which can cause confusion about the gpl
> distribution and would need to be clarified. 

I think all of your questions can be understood by reading GPLv2 section
3 & 3b. Section 3b says:

        b) Accompany it with a written offer, valid for at least three
        years, to give any third party, for a charge no more than your
        cost of physically performing source distribution, a complete
        machine-readable copy of the corresponding source code, to be
        distributed under the terms of Sections 1 and 2 above on a
        medium customarily used for software interchange; or,

On Thu, 2010-12-02 at 18:51 -0600, Kenney Phillis wrote:
> 1) If i download the firmware from their site, am i automatically
> entitled to the gpl source release? I know that for GPL v2 it's a bit
> tough to figure out, and as for GPL V3 it's as long as i have the
> binary.

I would say that making the firmware available for download constitutes
"copying and distributing the Program (or a work based on it, under
Section 2) in object code or executable form" as per section 3. So that
section would apply.

However, I would _not_ say that therefore you are "automatically
entitled to the gpl source release". What does happen is that the
distributor is bound by the license so they have to choose one of GPL

Re: GPL Distribution Clauses?

On Fri, 2010-12-03 at 13:22 +1100, Angus Gratton wrote:               
> I would say that making the firmware available for download constitutes
> "copying and distributing the Program (or a work based on it, under
> Section 2) in object code or executable form" as per section 3. So that
> section would apply.
> 
> However, I would _not_ say that therefore you are "automatically
> entitled to the gpl source release". What does happen is that the
> distributor is bound by the license so they have to choose one of GPL
> section 3 a, b or c and apply it in order to comply.

Since you mention section 3, it'll be important to point out what is not
followed....

Section 3a states that a complete machine-readable source be made
available, and the example companies do not include this.

Section 3b is about written offer for the source be included with the
binaries and this is not followed. 

Section 3c is invalid for corporations, because they are for profit.
however, it still might apply in an off-chance if the binaries used are
not modified and they relay people to the originating project site.

> > 3) Is the source of the distribution in violation of the GPL for
> > refusing a request for the source after one downloads the firmware.
> 
> GPLv2 doesn't say anything about refusing requests or not. It only says
> you have to make the offer, which then presumably becomes legally

Panda Security GPL violation

Re: Panda Security GPL violation

On Thu, Dec 2, 2010 at 9:49 PM, Michael Shepard <joelisester <at> gmail.com> wrote:
> I have contacted Panda Security about a GPL violation with their Rescue CD
> technology. Previously it utilized ISOLINUX and an ncurses program. Recently
> they switched to using Debian, so that they could provide a user-friendly
> interface to their customers. The only problem is that they do not provide
> the source code for Debian. I have searched their website with no success.
>
> I have contacted them about this issue, indicating that it opens them up to
> lawsuits (since this usually gets people's attention). I have not received a
> response.
>
> I thought it would be better for someone more closely related to the project
> to get in contact with these people, so I contacted the Debian Legal mailing
> list. The person who replied said that it would be better to get into
> contact with the copyright holders of the software on this CD, which sounds
> like a monumental task I cannot handle.

You only need one of the copyright holders of the content in Debian to
press the issue, so just start with one.

> My question is, where do I go from here? I'm on a mission and want to see
> this situation turned around, because what Panda is doing, intentional or
> no, is wrong.

Debian includes GNU Coreutils, right? My first though would be to
start with the FSF -- they have the experience and the manpower to
address the issue, and all the copyright on the coreutils is belong to
them (he said, grinning), so they can act as a single complainant.

--R

P.S. I'm not on debian-legal anymore, but I'm surprised that the stock
answer was "go talk to the copyright holders." I understand that
Debian sometimes acts like a thin seive, filtering out the cruft and
non-Free programs, and holding together builds of umpteen programs
(and darn are they good at it) but I wish that they were able to
provide more generalized support to protect Debian as a FOSS OS. At
the very least, I would've hoped that they would have specifically
pointed you at copyright holders who are interested in protecting the
copyrights on their software, such as the FSF.

To put it another way, I hope that Debian would regard any credible
report of license non-compliance as something worth passing along to
upstream projects.

ARM endorsing GPL violation by one of its Licensees (Telechips) - TCC8900

i'm sure that ARM are aware of this, but i wanted to double-check and
also alert them, so that i know that they're definitely aware of the
issue.

the issue is very simple.  see the following page:

http://www.malideveloper.com/developer-resources/development-boards/telechips-tcc8900-development-platform.php?tab=ORDER%20INFO

it states that an NDA is required.

upon signing the NDA, a Board Support Package is received, comprising
Linux Kernel Source Code, amongst other things.

(a copy of the TCC8900 Linux Kernel Source code was extracted from a
BSP and uploaded here:
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=arm-netbook/arm-netbook.git;a=shortlog;h=refs/heads/tcc8900/v2.6.28/chipper)

forcing people to sign NDAs to receive GPL source code is in direct
violation of the GPL license.

the problem for ARM is that they are responsible for
malideveloper.com.  a whois for malideveloper.com shows:

   NS2.ARM.COM                  217.140.98.10
   NS1.ARM.COM                  217.140.108.113
   NS4.ARM.COM                  217.140.98.25
   NS3.ARM.COM                  217.140.104.130

therefore, it can be concluded that ARM endorses GPL violation.

i would like to know what ARM is going to be doing about this situation.

l.

Re: ARM endorsing GPL violation by one of its Licensees (Telechips) - TCC8900

Luke,

Whilst I'm sure you have good intentions, the tone of your post could
well be considered unhelpful and intentionally inflammatory.

It's not clear to me that ARM are already aware of a problem, and aside
from that the text on their site does not appear to point to a GPL
violation.

To quote verbatim:

"For ordering info and how to get access to the TCC8900 development
board and BSP, please email TCCSM <at> telechips.com with as much of the
information below filled as you can. Please be aware that upon approval
of your request for a TCC8900 board, you will be aksed to enter an NDA
agreement with Telechips."

I see no problem in that text - there is no implication at all that the
NDA will prevent distribution of the GPL code. The NDA *could* just
cover the board and other parts of the BSP that are not GPL.

Depending on how Telechips decided to comply with the GPL, there may
also not be a requirement that they supply the GPL source to you other
than if you've bought a board and signed an NDA (assuming you've not
managed to acquire binaries of the kernel).

In both cases they can't prevent you distributing the GPL code once you
have it, of course.

As a further aside, you've not even supplied enough information here to
prove that Telechips are violating the GPL, as there's no commentary as
to what the NDA allows and disallows or how it is possible to get binaries.

Also, if you (or whoever put the source code up on the Debian machine)
have signed an NDA that prevents you disclosing the GPL source, then
disclosing that source leaves that person open to litigation. (We can
argue about how unlikely litigation is, but my statement remains true.)

Joseph

On 03/12/10 18:37, Luke Kenneth Casson Leighton wrote:
> i'm sure that ARM are aware of this, but i wanted to double-check and
> also alert them, so that i know that they're definitely aware of the
> issue.
> 
> the issue is very simple.  see the following page:
> 
> http://www.malideveloper.com/developer-resources/development-boards/telechips-tcc8900-development-platform.php?tab=ORDER%20INFO
> 
> it states that an NDA is required.
> 
> upon signing the NDA, a Board Support Package is received, comprising
> Linux Kernel Source Code, amongst other things.
> 
> (a copy of the TCC8900 Linux Kernel Source code was extracted from a
> BSP and uploaded here:
> https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=arm-netbook/arm-netbook.git;a=shortlog;h=refs/heads/tcc8900/v2.6.28/chipper)
> 
> forcing people to sign NDAs to receive GPL source code is in direct
> violation of the GPL license.
> 
> the problem for ARM is that they are responsible for
> malideveloper.com.  a whois for malideveloper.com shows:
> 
>    NS2.ARM.COM                  217.140.98.10
>    NS1.ARM.COM                  217.140.108.113
>    NS4.ARM.COM                  217.140.98.25
>    NS3.ARM.COM                  217.140.104.130
> 
> therefore, it can be concluded that ARM endorses GPL violation.
> 
> i would like to know what ARM is going to be doing about this situation.
> 
> l.
> 

Re: ARM endorsing GPL violation by one of its Licensees (Telechips) - TCC8900

On Fri, Dec 3, 2010 at 9:22 PM, Joseph Heenan <joseph <at> heenan.me.uk> wrote:
> As a further aside, you've not even supplied enough information here to
> prove that Telechips are violating the GPL, as there's no commentary as
> to what the NDA allows and disallows or how it is possible to get binaries.

 those people who have signed the NDA have violated that NDA by making
available the BSP that they obtained under NDA on various download /
file-sharing web sites.  the locations and names of the files to
search for were discussed here on legal <at> lists.gpl-violations.org
approximately three weeks ago.  analysing one such BSP download it was
found to contain binary object files that one is expected to link into
the linux kernel, GPL source code for the linux kernel, non-GPL-source
code which one is expected to compile and link into a GPL linux
kernel, and other GPL applications as well as some android
applications and libraries.

l.

Re: ARM endorsing GPL violation by one of its Licensees (Telechips) - TCC8900

On Fri, Dec 3, 2010 at 9:22 PM, Joseph Heenan <joseph <at> heenan.me.uk> wrote:
> Luke,
>
> Whilst I'm sure you have good intentions, the tone of your post could
> well be considered unhelpful

 that's a matter of opinion.  i'm pissed at ARM for being so stupid.
right now they need someone to give them a swift kick in the goolies,
otherwise they'll simply say stupid things like "well none of our
licenseeeees have complaaaained" well of course they fucking well
haven't because the licenseees are taking the piss.

> and intentionally inflammatory.

 yyyep.  if there's any way in which i can be more inflammatory and
also factually accurate, to cause as much hell for ARM as possible,
leaving the "wise" discussion to "cooler heads", please do advise.

 remember: i can get away with stirring up shit so that _you_ don't
have to do it.  bad cop, good cop.

 l.

Re: GPL Distribution Clauses?

fre 2010-12-03 klockan 13:22 +1100 skrev Angus Gratton:

> However, I would _not_ say that therefore you are "automatically
> entitled to the gpl source release". What does happen is that the
> distributor is bound by the license so they have to choose one of GPL
> section 3 a, b or c and apply it in order to comply.

For 3b to possibly apply it needs to be prominently noticed at the
download location, or clearly visibly included together with the
firmware download itself.

3b is really intended for physical distribution, not online
distribution. Trying to apply it to online distribution gets very
awkward. This is clarified beyond any doubt in GPLv3.

3c can not apply as already noticed (applies to non-commercial
distribution only)

Worth noting is that 3a applies cleanly on online distribution, and is
further detailed at the end of section 3.

> Reproducing the license text is not a written offer from the entity
> distributing the software (as per 3(b).) So I think that's a no.

Indeed.

> As I understand it, if About->Legal also has the written offer visible
> there then that may be different.[1] The SFLC has a good boilerplate
> example of an offer in their "Practical Guide to GPL Compliance",
> section 4.1.2.[2]

I would argue that hiding the written offer there is not valid in terms
of "Accompany it with a written offer" as it requires actually running
the firmware to be able to view it. Firmware files for download are
often both compressed and sometimes encrypted making it very hard for
the receiver to get that notice without running the firmware. But ianal
and it's possible there is someone with convincing arguments on the
opposite.

> However, it seems that a "device reseller" is not always the same as a
> 'distributor' as per the GPL terms. I do not know exactly what the
> distinction is for any given jurisdiction. However, people have
> suggested to me that it exists.

I think it boils down to the contractual terms regarding warranty
responsibility etc in the distribution chain. In GPL terms it is
ultimately the responsibility of the reseller, but the above contracts
may delegate the responsibility further up the chain protecting the
resellers. The boundaries for this responsibility wrt GPL compliance has
not been explored in depth as these boundaries only come in light of
when the original vendor refuses to act as the GPL source distributor on
behalf of their complete distribution chain. It is it is commonly
regarded as sufficient for compliance if the original vendor acts as the
GPL source distributor worldwide from a single location.

But distributors need to be maed aware that the written offer
obligations is far longer than most warranty obligations and similar and
may require special attention, something I think is often overlooked
completely today in the distribution chain.

Regards
Henrik