Code of (still) uncertain origin [LWN.net]

In last week's episode, we looked at the story of the new Thinkpad embedded controller driver and its author "Shem Multinymous." The situation had been put on hold after Pavel Machek had offered to sign off on the code, and the discussion died down for a bit. Not for long, though.

Robert Love, the author of the accelerometer driver which (among other things) is replaced by this code, reviewed it, noting "I am glad someone has apparently better access to hardware specs than I did" That brought Andrew Morton back in, saying:

This situation is still a concern. From where did this additional register information come? [...]

We're setting precedent here and we need Linus around to resolve this. Perhaps we can ask "Shem" to reveal his true identity to Linus (and maybe me) privately and then we proceed on that basis. The rule could be "each of the Signed-off-by:ers should know the identity of the others".

That is not good enough for Greg Kroah-Hartman, however:

For what it's worth, I'm not going to be handling these patches at all (normally the hwmon patches go to Linus through Jean and then through me.) If the original developer does not want to work in the open like the rest of us, I can respect that, but unfortunately I can't accept the risk of accepting their code.

Jean Delvare has also declined to look at the code, saying that the legal uncertainty is too strong. Shem Multinymous, on the other hand, seems willing to come clean to Linus and Andrew if that is what it takes to get the code into the kernel. So it is conceivable that things could happen that way, with the code bypassing the maintainers who would normally handle (and review) it. Some residual concern could remain, however, perhaps to the point that distributors would consider removing the code from the kernels they ship.

"Shem" has also posted two separate messages on the provenance of the information used in this driver. The story, it seems, starts with a reverse-engineered Windows driver. Then, a real spec for the embedded controller chip was found. After that, it was mostly a matter of putting the pieces together. Or so it is said.

If this story holds together, then the new code probably is something which can be merged into the mainline without worry; it should be at least as legitimate as the original driver which it replaces. But, even if it gets in, this code will have set a precedent of sorts: anonymous submissions (at least, those submitted under an obvious pseudonym) are going to have a hard time getting through the process. Nobody wants to be the person who guided bad code into the kernel.

(Log in to post comments)

Code of (still) uncertain origin

Posted Aug 17, 2006 13:47 UTC (Thu) by pointwood (guest, #2814) [Link]

That is what I'm wondering about as well. IBM claims they are huge open source and especially Linux supporters, why can't they provide the specs for this? I don't see why it would be a huge asset to hide that information.

Code of (still) uncertain origin

Posted Aug 17, 2006 17:16 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

If the contributor reveals himself/herself to Linus, and Linus is satisfied that there isn't a legal problem, I see no reason why it couldn't go in.

However, Linus should find out the reason why the person wants to be anonymous, and if the reason is that the person's employer would object, this is a major red flag. In the US at least, many employment contracts pretty much give the employer ownership rights, or at least right of first refusal, on any code that the employee produces that is in any way work-relevant.

So it's not just a matter of trade secrets. The risk that an employer could take legal action against a free software project based on an employee contribution is why the FSF requires employer disclaimers for contributions to software that it owns.

But if the contributor is a self-employed person who can convince Linus that s/he didn't base the driver on stolen trade secrets, then the contribution should be allowed.

Code of (still) uncertain origin

Posted Aug 17, 2006 22:12 UTC (Thu) by jsarets (guest, #39560) [Link]

I think that the kernel community should reach out to IBM and/or Lenovo and ask them what they think of the code. Tell them we got this from an unknown contributor that has signed-off that the code was developed using legitimate procedures, but we want to double-check with them, just to make sure.

One can only speculate as to why Mr. "Multinymous" is operating under a pseudonym, but regardless, we can't mess this up. This could very well be a test or a malicious attempt to torpedo the kernel. If that's the case, we need to be sure that we exercised due diligence in verifying the legitimacy of the code.

The tricky thing with software patents is that it's not easy to tell whether you're infringing on someone's patent. There's only so much we can do, but engaging IBM/Lenovo in this matter is a good step. Does anyone disagree?

Code of (still) uncertain origin

Posted Aug 17, 2006 18:01 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]

If the knowledge required to program those registers is a trade secret covered under NDA, you could run afoul of trade secret laws if you disclose that information publicly.

Also, if the methods of controlling the hardware correctly are covered by patent protection, then you could run afoul of patent law. This isn't precisely a software patent issue, either. The "preferred embodiment" of an invention may be a combination of hardware and software together, where the software is doing something very specific with respect to the hardware.

(Patent aside: For instance, you can interpret the cams, gears, and clockwork that drive complex machines as the "program" for that machine, if by changing those cams, gears and other clockwork you can make the machine do something else useful. The entire machine, if novel, is patentable. If you replace one of the mechanical control pieces with a microcontroller and some software, you haven't really changed the character of the whole. I would argue the software based implementation is equally patentable without allowing so-called "software patents." The phrase "software patent" refers to pure-software, not intertwined hardware-software systems like this.)

The driver could also run afoul of any reverse engineering restrictions that the original driver had within its license. Whether or not those are enforceable is an open question. Nonetheless, do you really want to tangle with that?

And, as someone else pointed out, the code could be encumbered simply by the nature of the author's employment. His employment agreement may say they get first right of refusal to any code he writes on or off the clock in the fields of interest to his employer. (Or worse, that they own that code by default.)

Code of (still) uncertain origin

Posted Aug 17, 2006 17:49 UTC (Thu) by AJWM (guest, #15888) [Link]

Looking at the links in Shem's explanations, I can believe the provenance of the technical details needed for the improved driver. Opening up a box, looking at the chip labels, and trawling the internet for manufacturers' documentation on same is pretty common practise, and I've had to do it a few times myself. (Sometimes the info turns up in surprising places -- FCC's website based on the manufacturer's FCC product registration number, for example.)

Shem also raises an interesting point -- how many other drivers, etc, have been required to document the provenance of their technical info? Yes, some of them do provide some references in code comments, but it would be nice if more of this were available, perhaps as URLs in the driver code. (A centralized location for copies of device specs would be nice too, if the manufacturers are willing to go along with it. URLs change, after all.)

If someone wants to bugfix or enhance a driver, having a ready link to this stuff saves all kinds of time.

Code of (still) uncertain origin

Posted Aug 17, 2006 23:56 UTC (Thu) by bronson (subscriber, #4806) [Link]

I totally agree. I wonder if a technical documentation repository would be another good application for archive.org...?

Tech docs archive?

Posted Aug 22, 2006 17:01 UTC (Tue) by tim_small (guest, #35401) [Link]

Amen.

An archive of technical data would definitely be nice - I gave up on creating an EDAC driver for the Via Apollo Pro 133 memory controller as I can't find the datasheet anywhere (Via say that they can't find it either)!

I know that the datasheet used to be available as there is other free code knocking about that must have used it!

Tim.

Code of (still) uncertain origin

Posted Aug 20, 2006 14:59 UTC (Sun) by erich (subscriber, #7127) [Link]

Well, it all depends on the reasons...
Let's say this "Shem" is a Microsoft (*) employee. Not involved with any Thinkpad driver there (which are likely done by IBM, not Microsoft), so there is little doubt that he used the documents he posted in his mails.

While not having violated any NDA, he might still get into trouble by his employer for contributing to the Linux kernel.

In that situation, I guess it would be okay if someone else "adopted" the patch. What if the author of the original driver reads through it and adopts it, where are the problems then?

(*) Microsoft was chosen as being the "biggest enemy" of Linux, I have no indication whatsoever to believe that this is true. In fact all I've read about this issue was here on lwn.net