You are viewing joshua_

Joshua's weblog - HTC's ongoing GPL violations
December 27th, 2010
06:04 am

[Link]

Previous Entry Add to Memories Share Next Entry
HTC's ongoing GPL violations
Over the past months, HTC has caused the Incredible and EVO communities a fair bit of grief by their failure to follow through on their obligations under the GPL; they have been continually releasing new binary versions of kernels for these two phones, but have failed to publish source at their Developer Center web site. Reportedly, when asked by e-mail, HTC has responded indicating that they were unwilling to release source; I'm waiting to hear back from them on this iteration, but last time I asked for an earlier version of the kernel, their support staff was incapable of producing source. I mentioned this in response to a post by mjg59, and he suggested that I write up details of their lack of compliance.

So, in this post, I intend to provide some specific examples of deltas from the latest source that are actively harming the community. The latest source drop available from HTC is available in supersonic-2.6.32.15-g746f4f0.tar.gz; my version of it has md5sum 8a22a3e6151fd181de93921ce42fde8a. My phone, which is running software version 3.70.651.1, is running kernel version 2.6.32.17-gee557fd.

I'll first take a look at the routine supersonic_panel_unblank, found in arch/arm/mach-msm/board-supersonic-panel.c. In this update (well, a few updates ago, but still later than this kernel), HTC added support to run the LCD panel at a higher clock rate; this allows the EVO to break the previous frame rate cap (around 30FPS) cap, and move closer to 55FPS. These changes occurred in the unblank mechanism, and also in the initialization sequence; before HTC did, toastcfh and netarchy made these changes, proving that it was possible. (Right now, it doesn't look like their code was copied.)

On to the meat of it, then. In the released kernel, the unblank routine looks like this:

static int
supersonic_panel_unblank(struct msm_mddi_bridge_platform_data *bridge_data,
                        struct msm_mddi_client_data *client_data)
{
        B(KERN_DEBUG "%s\n", __func__);
        if (panel_type == PANEL_AUO) {
                suc_backlight_switch(LED_FULL);
                client_data->remote_write(client_data, 0x00, 0x2900);
                msleep(100);
                client_data->remote_write(client_data, 0x24, 0x5300);
        } else {
                suc_backlight_switch(LED_FULL);
                client_data->remote_write(client_data, 0x4000, 0x0600);
                msleep(10);
                qspi_send_9bit(0x0, 0x29);
                client_data->remote_write(client_data, 0x7000, 0x0324);
                client_data->remote_write(client_data, 0x4000, 0x0600);
        }

        backlight_control(1);
        return 0;
}

However, a (cleaned up) decompilation of the unblank routine in the binary looks like this: (edit: differing parts are bolded)
  if ( vC047A86C == 1 )
  {
    suc_backlight_switch(255);
    (client_data->remote_write)(client_data, 0x1u, 0xB101u);
    (client_data->remote_write)(client_data, 0x82u, 0xB102u);
    (client_data->remote_write)(client_data, 0x5Au, 45319);
    (client_data->remote_write)(client_data, 0, 17408);
    (client_data->remote_write)(client_data, 0xC8u, 0x4401u);
    (client_data->remote_write)(client_data, 0, 0x2900u);
    msleep(100);
    _client_data = client_data;
    nextaddr = 0x24u;
    nextdata = 0x5300u;
  }
  else
  {
    suc_backlight_switch(255);
    (client_data->remote_write)(client_data, 0x3043u, 0x20u);
    (client_data->remote_write)(client_data, 0x10C8u, 0x404u);
    (client_data->remote_write)(client_data, 0x4000u, 0x600u);
    msleep(10);
    qspi_send_9bit(0, 0x29u);
    (client_data->remote_write)(client_data, 0x7000u, 0x324u);
    _client_data = client_data;
    nextaddr = 0x4000u;
    nextdata = 0x600u;
  }
  (client_data->remote_write)(_client_data, nextaddr, nextdata);
  backlight_control(1);

There are substantial changes here (although not the same as those that toast and netarchy originally wrote); the released binary is obviously not the same as the released source.

There are also claims that HTC has made changes to the erase-block size probing algorithm in newer kernels; although I haven't been able to confirm this by disassembly yet, this would explain the beliefs that recovery images based off of old kernel source running on new hardware destroys the private keys stored in the WiMAX partition. So, in that case, it seems that HTC's failure to comply with their licensing obligations has directly caused harm to users. (I'm told that some of the CyanogenMod kernels have support for these new eraseblock sizes; if anyone could point me to a specific patch, I will update this post.)

Newer revisions of the Supersonic (EVO) hardware also have different cameras than the HW0002 version; as a result, the released source is unable to drive the camera on HW0004 Supersonics. This is reflected in the deltas from the source to the binary. On HW0002, the cameras are based on 'ov8810' and 'ov9665' sensors, and in the old kernel, the clocks for these are enabled with the supersonic_ov8810_clk_switch and supersonic_ov9665_clk_switch routines; in the new kernel, these routines simply do not exist. Similarly, the cameras are defined by struct platform_devices named msm_camera_sensor_foo -- on the old kernel, there existed msm_camera_ov8810 and msm_camera_ov9665, but on the new kernel there is a mysterious msm_camera_s5k6aafx. The routines driving this appear to be named things along the lines of s5k6aafx_sensor_probe, et al.; grepping for that string in the released source turns up nothing at all. This makes the old source unusable on HW0004 phones.

HTC, this isn't good enough. This is not a one-off; HTC has knowingly and repeatedly remained in violation of the licenses that the software they distribute comes with. It's time to shape up.

edit: HTC support responded to my e-mail, as follows:
Dear Joshua Wise,

I understand how important it is to have the most up to date kernal for your Sprint EVO 4G. HTC will typically publish on http://developer.htc.com the Kernel open source code for recently released devices as soon as possible. HTC will normally publish this within 90 to 120 days. This time frame is within the requirements of the open source community.

Sincerely,
Elizabeth
HTC

Funny, that. I wonder which community they are talking about for which "sometime later, maybe" is acceptable?


edit, edit: HTC also responded with the following two responses as I responded again -- their web site did not copy me on the messages I sent, so I don't have an easy way to reference them.

Our kernel is not an original kernal, it is a motification of an existing kernel. Because of this, the requirements for releasing the kernel are different under the GPL. HTC is working as quickly as possible in order to provide this kernel. Once it is available, it will be released on http://developer.htc.com.

I wonder why the requirements are different? I asked, and they pointed me to section 6, subpart D (and quoted it), concluding:
This basically means that we may make the kernel accessable by offering it through a website for download. It clearly does not indicate a timeframe for this access. It merely states that we must offer it. The 90-120 days is to allow us sufficient time to upload the information to our server and prepare the server for access. Once again, once the kernel is available, you may find it at http://developer.htc.com.

I'll leave you to make your own decisions based on that; my reading of 6(d) allows no such window...

(hello. I have 10 potato cannonses | buy PVC)

Comments
 
[User Picture]
From:mjg59
Date:December 27th, 2010 02:12 pm (UTC)
(Link)
There seems to be s5k6aafx code in some of the other HTC kernel releases, so it's probably possible to hack something together - on the other hand, this does look pretty strongly like a violation and I'll look into it further.
[User Picture]
From:joshua_
Date:December 27th, 2010 09:20 pm (UTC)
(Link)
Right. I'm told that the CyanogenMod folks have tried to glue that code in from the Desire HD source, but that things are subtly different on Supersonic, such that all images captured with that driver have a fixed green hue. I updated with their response; I'm pretty sure that the previous OTA (not this one) was more than 90 days ago, and certainly no source since.
[User Picture]
From:mjg59
Date:December 27th, 2010 09:30 pm (UTC)
(Link)
Should be pretty easy to pull the build string out of the kernel image - that'd give a minimum timeframe.
[User Picture]
From:joshua_
Date:December 28th, 2010 02:00 am (UTC)
(Link)
The old kernel was: Linux version 2.6.32.15-ge2fb08e (htc-kernel@and18-2) (gcc version 4.4.0 (GCC) ) #11 PREEMPT Wed Sep 1 15:08:40 CST 2010. So, we are over 90, and pushing 120.
[User Picture]
From:bubblingbeebles
Date:December 27th, 2010 10:50 pm (UTC)
(Link)
the most up to date kernal
[User Picture]
From:rincebrain
Date:December 28th, 2010 06:10 am (UTC)
(Link)
oh god why does their kernel use Motif
[User Picture]
From:joshua_
Date:December 30th, 2010 02:35 am (UTC)
(Link)
Here's more thread. To avoid spamming friends pages, I'll just stuff it in a comment thread.

In response to a message mentioning that 6(d) only exists in GPLv3 (under which the kernel is not licensed), and that not including a timeframe does not mean that an arbitrary itmeframe can be assumed, I got this:

Dear Joshua Wise,

I do apologize, I have located the GPL version 2 here: http://www.gnu.org/licenses/gpl-2.0.html

What I beleive that you are refferencing is Section 3, Subpart A of the Terms and Conditions of the GPL version 2 license. This states that one of the options when distributing a Program is to include a copy of the Source code. I.E. to include a copy of the source code with "the complete corresponding machine-readable source code" e.g. phone.

HTC has chosen instead to go with option (Subpart) B of Section 3. This states that we can "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." This again, does not include any terms or conditions that require us to immediately release the source code. It clearly indicates the that the offer must be valid for up to three years and that we must "give" a copy to "any third party." It does not say that the source code must be given immediately upon request from said third party.

Section 3 of the Terms and Condtions also states that "If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. "

This is again the method that we are chosing to supply the source code in. This part of the license clearly states that this distribution can be "made." HTC is currently in the process of making said distribution; that is to say writing and formating the source code (kernal) in such a way as to make it readily and easily (as is a requirement of the license) accessible from our developer website. We are not choosing to not supply you with the source code. We are simply unable to provide it to you at this time as it is not currently in an easily accessible format.

If you beleive that the GPL entitles you to receive the source code immediately upon request, as opposed to the first available oportunity at the best of our abilities, please provide a quotation of the actual license that states that the source code must be provided immediately upon request and not just "given."

To send a reply to this message or let me know I have successfully answered your question log in to our ContactUs site using your email address and your ticket number foo.

Sincerely,

Elizabeth

HTC
[User Picture]
From:joshua_
Date:December 30th, 2010 02:36 am (UTC)
(Link)
I then responded with this, after consulting the FSF:

Elizabeth,

I contacted the Free Software Foundation (authors of the GPL) about this (as well as some other folks I know that have a better legal background than I), and I compiled the following information for you.

Brett Smith at the Free Software Foundation said, in response to your recent claims that the GPL provides for a delay: "HTC's reading is outrageous -- we honestly thought no respectable company would have the gall to publicly make this argument. A delay of 90-120 days is not reasonable, considering that they must already have the source code.". Clearly, then, the authors of the GPL did not intend for any provision for a delay to be present.

Other legally-trained acquaintances commented that allowing a delay there would easily lead to reductio ad absurdum -- i.e., if an arbitrary delay could be inserted in this contract (which HTC agreed to upon releasing the binary), then that would imply that an arbitrary delay could be inserted in any contract. In most legal cases, it has been shown that if something can be read as either being absurd or not being absurd, the not-absurd reading is the one legally taken.

You mentioned 3(b) of the GPL, which begins that you must "accompany [the binary distribution] with a written offer, valid for at least three years [...] a complete machine-readable copy of the corresponding source code", and it seems that the second clause there -- "valid for at least three years" is the crux of it. Currently, the distribution does come with an offer, but the offer is not valid -- when I asked for the source code, HTC was unable to provide it for me, claiming instead that it would be given to me at an unspecified point in the future. This is not acceptable.

I note also that legal interpretations of a work tend to consider not just the strictly written details, but the intent; when details are in dispute, the overall intent is then referred to. The goal of the GNU GPL is to enhance the freedoms of anyone who receives the software, and to force one who might modify the software and distribute it for their own purposes to publish their changes back to the community. The GNU GPL does not have any provisions for temporarily withholding source for competitive or other reasons; the agreement that one must make when one distributes a binary is that one must also distribute source. Not doing so at the same time would be a violation, not just of the letter, but of the spirit of the contract; the goal of the GNU GPL is to enrich the freedoms of the commons through which software is distributed.

Given these four points -- the FSF's reading, the reductio ad absurdum, the letter of section 3(b) of the GPL, and the spirit of the GPL as a whole -- it is clear that the GPL requires that HTC release the source for the kernel at the same time or earlier than the binary. To that end, I request that you, within 24 hours, provide me with a link to the source for kernel version 2.6.32.17-gee557fd that is distributed with HTC EVO software update 3.70.651.1.

Thank you,
Joshua Wise
[User Picture]
From:mjg59
Date:December 30th, 2010 01:42 pm (UTC)
(Link)
Do they actually include a written offer with the device and the firmware update?
[User Picture]
From:joshua_
Date:December 30th, 2010 07:20 pm (UTC)
(Link)
Yes. From the home screen, press menu, settings, about phone, legal information, HTC Legal, and start scrolling. In part 4, it reads:
Until the date that is three years after you acquired the Software, you may obtain a copy of the source code corresponding to the binaries for GPL-licensed file by sending a request to HTC customer service at www.htc.com, and HTC will send you a link to such source code.
My Website Powered by LiveJournal.com