GPL'ed Drivers Can't Be Logo'ed OR Attestation Signed??

Live and learn.

In this comment, @CaptainFlint (a relative newcomer to NTDEV but not to Windows drivers, clearly) brought to my attention something that had somehow managed to escape my attention for years.

According to the Windows Compatibility Program and Driver Quality Attestment Testing Agreement V2.0 drivers that are GPL’ed cannot be logo’ed or Attestation Signed by MSFT.

As did Captain Flint in the previous thread, I refer you to Section 7(g) which reads:

(g) Drivers and BIOSes are not, and when delivered to Microsoft will not be, in whole or in part, governed by
an Excluded License. An “Excluded License” is any license that requires, as a condition of use, modification and/or
distribution of software subject to the Excluded License, that such software and/or other software combined and/or
distributed with such software be (i) disclosed or distributed in source code form; (ii) licensed for the purpose of
making derivative works; or (iii) redistributable at no charge.

The reason, apparently, is that once a driver is signed by MSFT, MSFT can’t prevent the driver from being distributed via Windows Update. And this distribution would (apparently) make them liable for providing the source code for that driver (which they do not have).

Now, I’m no fan of GPL licenses (and that’s putting it mildly). You want to make your source code available? There are MIT and Apache licenses for that. But, whatever… This isn’t the place to argue that.

FYI, if you violate the agreement “some or all of the Company Products may be removed from the Microsoft Lists” (according to clause 2(g) of the Agreement. So that means you risk losing your Attestation Signing or Logo for potentially all of your products.

The point is… Wow. I never knew this.

Peter

And now I re-remembered that I knew that.

The reason, apparently, is that once a driver is signed by MSFT, MSFT can’t prevent the driver from being distributed via Windows Update. > And this distribution would (apparently) make them liable for providing the source code for that driver (which they do not have).

Well, as my entire posting history to this NG strongly suggests, I am, probably, the very last person on thus planet whom you would suspect of being a “MSFT sympathizer”. However, in this particular case I would defend their decision. Look what GNU itself says on the subject

https://www.gnu.org/licenses/quick-guide-gplv3.html

[begin quote]

GPLv2 talks about “distribution” a lot—when you share the program with someone else, you’re distributing it. The license never says what distribution is, because the term was borrowed from United States copyright law. We expected that judges would look there for the definition. However, we later found out that copyright laws in other countries use the same word, but give it different meanings. Because of this, a judge in such a country might analyze GPLv2 differently than a judge in the United States.

GPLv3 uses a new term, “convey,” and provides a definition for that term. “Convey” has the same meaning we intended for “distribute,” but now that this is explained directly in the license, it should be easy for people everywhere to understand what we meant.

[end quote]

Now let’s look at their definition of the “convey” term

https://www.gnu.org/licenses/gpl-3.0.en.html

[begin quote]

To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

[end quote]

As it clearly follows from the above quotations, the very fact of providing GPLed driver’s binary file automatically makes MSFT responsible for providing its source as well, although the said driver may be, in actuality, produced by some third party. Why on Earth would MSFT need some extra pain in the neck (or, probably, a couple of feet lower) that taking care of the third-party’s sources implies???

Now, I’m no fan of GPL licenses (and that’s putting it mildly).

Well, they unquestionably have very strong points. For example, it may be claimed that the copyleft provided by the GPL was crucial to the success of the Linux kernel and of the OSes that were based upon it. This argument becomes particularly convincing if you take the vast technical and architectural superiority of BSD-based OSes over LInux in its early days, into the account. However, in some cases it simply shoots itself in the foot, and this thread is just an example of it. Its interactions with CDDL, which makes the inclusion of ZFS in the main LInux kernel plainly impossible even in theory, is another example…

Anton Bassov

@anton_bassov Oh, for sure… MSFT has a legit issue here.

Another reason GPL sucks, IMHO. They could soooo easily safe-harbor this type of distribution. But, no. Arrrgh… one more time: We are not going to debate anything about the GPL here.

Again, my point isn’t that MSFT are evil because of this. MY point is “I never knew this” – now, maybe I’m the only one, but I bet a lot of other folks didn’t know it either.

Peter

To be fair, MSFT could have avoided that easily by adding a requirement, that submitted GPL drivers must include full source code. They already require debug symbols to be supplied, and HCK/HLK packages can include arbitrary set of supplemental files, so it’s not such big a change. I suspect, they just chose the path of the least resistance…

But I have a comment on the starting post of this topic. First, @“Peter_Viscarola_(OSR)” , you posted a link to your locally stored PDF document. The link should be:
https://docs.microsoft.com/en-us/legal/windows/hardware/windows-hardware-compatibility-program-test-agreement-v2-0-rev-dec-2016

Second, I’m not sure about the argument covering the attestation program. I always thought, that MS published only the WHQL signed drivers, not the Attestation signed ones. Was I wrong?

I always thought. that MS published only the WHQL signed drivers …

Yes, Peter is reading between the lines a bit here. He may be right, I just don’t know. Very few of my clients have ever cared whether their drivers got into the Windows driver library. It’s not clear what other recourse Microsoft would have.

you posted a link to your locally stored PDF document

DID I? How embarrassing. Thanks for the headsd-up, I fixed it to point to the HTML link you provided.

I’m not sure about the argument covering the attestation program

Hmmmm… If you read the Agreement that’s linked, you’ll see it applies to Attestation Signed drivers. Now, I’m not a lawyer, so whatever I think doesn’t count. But, 7(g) is part of the Representations and Warranties section, which doesn’t say anything restricting that section to Logo’ed drivers only. So, in my mind, that means it applies. The whole agreement looks like it was rather hastily edited to allow it to cover Attestation Signing.

Now, I did write in the OP that “you risk losing your Attestation Signing or Logo for potentially all of your products” – And THAT is clearly an interpretation, and I appreciate Mr. Roberts bringing that to my attention. You clearly risk losing your Logo… what they could do to your Attestation Signing, I really don’t know.

Peter

@“Peter_Viscarola_(OSR)” No, no, I didn’t mean that the agreement wasn’t saying about it; to me it also does look like it puts both WHQL and Attestation under the same conditions (although, I’m not a lawyer either, so I cannot be sure). I just said, that the explanation about the reasons, why they might have forbidden GPL drivers, does not apply to Attestation signing, because these drivers are not published in the MS catalog, so MS does not need to bother about not having the source code. (Unless I’m wrong, and they are published.)

To be fair, MSFT could have avoided that easily by adding a requirement, that submitted GPL drivers must include full source code.
They already require debug symbols to be supplied, and HCK/HLK packages can include arbitrary set of supplemental files,
so it’s not such big a change. I suspect, they just chose the path of the least resistance…

Try to put yourself in the software vendor’s shoes…

For example, GPL requires the distributor of a binary to provide the sources that the said binary was produced from, but no additional conditions upon the way the said binary is used are imposed. So far, so good.

Now imagine someone releasing their drivers under some imaginary ABCDL license that prohibits the use of their driver binaries in the commercial products (I.e. the ones that you are required to pay for, regardless of the source availability) of any description. Then someone decides to soften their requirements a bit, and introduces a modified ABCDLv2 license that allows the use of their drivers in the commercial products that are released under GPL- compatible licenses. Then Mr.Kyler decides to release " the only proper spinlock implementation in existence" under “Dan Kyler’s Anti-Genocide License” that prohibits the use of his “masterpiece” by anyone named like soviet_bloke, chinese_lad, nazi_geezer et al. The list goes on and on, and is limited only by the one’s imagination.

To make things more “exciting”, the terminology that these licenses use is not guaranteed to be uniform. For example, the terms like “distribution”, “derived work” et al may have slightly different meanings under the different licenses, which adds more to the confusion.
If it is still not enough, some licenses may be simply incompatible with one another. For example, if you link CDDLed code against GPLed one you are going to violate the terms of both licenses in one go. If a software vendor requires the source code to be provided with the third-party drivers, there is a good chance that they may be potentially held liable for these violations.

I hope by now you already “appreciate” the legal mess that you may be potentially heading to. Why would you need something like that??? Would not it be better(and easier) for you simply to refuse distributing ANY third-party software that presents ANY additional requirements to the software vendors and/or end users, with your product???

Anton Bassov

@anton_bassov
Of course, there will always be legal issues with various licences. But it is in both driver developers’ and Microsoft’s interest to fit as many drivers as possible into the Agreement. Especially, because in a few months all the users will completely lose the ability to load any new driver which is not Attestation/WHQL-signed (apart from testsigning mode, of course). I cannot stress enough, what an extremely harsh blow that is! I would expect Microsoft to be willing to soften it in all the ways possible.

So, with this premise in mind, what I was saying was: if the only reason they excluded GPL from the Agreement was their inability to provide source code, then that particular issue could be solved very easily, and all the GPL-licensed drivers would not have to be lost forever for the Windows eco-system.

I admit, that it may not be the only reason (but then I would like to know what the others are); and I admit that it will not solve all the problems for all the licences. But GPL is not just any arbitrary licence, it’s quite common, and there are quite a few drivers distributed under it. So even if MS solves the issue only for the GPL, it will benefit significantly to everyone.

if the only reason they excluded GPL from the Agreement was their inability to provide source code, then that particular
issue could be solved very easily,

…but only from the technical standpoint. However, if you look at the whole thing from the legal one (and this is what the software licenses are meant to be for, in the first place), things don’t necessarily look THAT simple. More on it below

I admit that it will not solve all the problems for all the licences. But GPL is not just any arbitrary licence, it’s quite common,
and there are quite a few drivers distributed under it.

The problem is that GPLed code may incorporate some other one that has been released under some open-source license other than GPL, and this license may be incompatible with GPL (like, for example, CDDL). In more extreme cases, GPLed code may be even claimed to be “stolen” by someone. If you need some practical real-life examples of it, just the NTDEV archives for “Filedisk”( or whatever it is called). Another potential problem lies with patents. For example, consider the scenario when GPLed code is claimed to infringe some patent.

If software vendors decide to distribute the code that they did not write, there is a good chance that they may be potentially held liable
(at least in some jurisdictions) for the issues that have absolutely nothing to do with them whatsoever. Why would they want something like that???

Anton Bassov

@anton_bassov
I understand what you are saying, and I agree that legal matters can be very tricky sometimes. But all those issues you are describing are not uniquely inherent in GPL. All the same issues may arise when any other licence is used. People and companies can steal code, no matter what it’s licensed under; or they can combine code which comes under incompatible licences; or infringe patents while writing non-GPL code… Not having GPL does not save you from all those issues automatically. Microsoft already has to take all those risks into account, and deal with them. For example, 7.d explicitly requires that any 3rd-party intellectual property rights are not infringed - no matter what licence is used. Adding GPL into the equation changes absolutely nothing in this respect.

I admit, that it’s possible that GPL contains some points which make it very hard or even impossible for MS to deal with this licence. But up until now I’ve not seen such points either in the discussion here, or in the MS Agreement. The only valid point I’ve seen so far was, that MS didn’t have source code to provide, as required by GPL (or any other “Excluded License”). But this particular point can be solved very easily; it’s a technical aspect, so it does not bring any legal difficulties by itself. Are there any actual legal issues attached to this aspect? Or are there any specific legal issues, which Microsoft does not have to deal with right now, but which will be introduced, if they allow GPL into the program? (In the assumption, that the Agreement would be amended to require from the companies, that they must attach the full source code for such drivers.)

But all those issues you are describing are not uniquely inherent in GPL. All the same issues may arise
when any other licence is used. People and companies can steal code, no matter what it’s licensed under;
or they can combine code which comes under incompatible licences; or infringe patents while writing non-GPL code…

Sure. The “only” question left is whether these disputes are going to get resolved between the interested parties only, or whether they may potentially involve those who,in actuality,have no relation to them whatsoever. Certainly, once I am not a lawyer, I cannot express any more or less qualified opinion on the subject ( and the laws vary across jurisdictions anyway), but the very definition of the term “conveying” given by GPLv3 strongly suggests that the latter scenario may potentially become a real issue as far as software vendors are concerned, at least in some jurisdictions.

Not having GPL does not save you from all those issues automatically.

True. However (again, judging from the definition of the term “conveying” given by GPLv3), it may significantly decrease the probability
of having to deal with them at some point for someone with no actual relation to them whatsoever. More on it below

Microsoft already has to take all those risks into account, and deal with them.

The problem is that the very fact of becoming a source code provider may potentially take these risks not only to the basically different level but literally to the totally different legal dimension, at least in some cases in some jurisdictions. For example, consider the scenario of some malfunctioning medical equipment or industrial machinery causing multiple deaths, injuries and/or ecological disaster, and the subsequent investigation establishing that the malfunction was, in actuality, caused by the improperly-written driver for the device in question. Again, I am not a lawyer, but something tells me that you would not really want to be among those who have had an access, even indirectly and only RO one, to the said driver’s sources.

Adding GPL into the equation changes absolutely nothing in this respect.

Do you still think so?

Anton Bassov

@anton_bassov said:
For example, consider the scenario of some malfunctioning medical equipment or industrial machinery causing multiple deaths, injuries and/or ecological disaster, and the subsequent investigation establishing that the malfunction was, in actuality, caused by the improperly-written driver for the device in question. Again, I am not a lawyer, but something tells me that you would not really want to be among those who have had an access, even indirectly and only RO one, to the said driver’s sources.

Considering the driver was GPL in the first place, it’s highly improbable that MS and the driver’s developers were the only one to have had access to the code. If the source was publicly available on the Internet, then, by that logic, you’d have to involve half the Internet - everybody who could have seen the source. Or at least everybody, who forked it. I fail to imagine a jurisdiction which would act like that.

In my opinion, when Microsoft takes a third-party binary driver and digitally signs it with their own signature (by which action they undeliably identify themselves as the official source of the driver), they take an immensely higher risk of being involved, than if they re-distribute some bunch of source code, which has no relation to Microsoft whatsoever, and even more, which has the real authors’ contacts written all over the source files. If MS managed to do the first, and survive for that long, undoubtedly they can handle the second without breaking a sweat.

Adding GPL into the equation changes absolutely nothing in this respect.

Do you still think so?

I would say so, yes. Of course, as I’m not a lawyer either, I can easily miss some possible legal implications. But as of now, I’ve not seen any convincing examples, sorry.

I would say, for this discussion to continue productively, it needs someone from the Microsoft legal department, who could explain the real legal implications (or confirm the lack of those, who knows). For now, it’s all mostly guesswork, and it needs solid information. So I would suggest we finish this discussion for now. Thank you for the dialog; it was interesting to see your point of view (even if I could not fully agree with it).

Considering the driver was GPL in the first place, it’s highly improbable that MS and the driver’s developers were the only
one to have had access to the code. If the source was publicly available on the Internet, then, by that logic, you’d have to
involve half the Internet - everybody who could have seen the source. Or at least everybody, who forked it. I fail to
imagine a jurisdiction which would act like that.

AFAIK, when it comes to liability, it normally applies only to those who have actually provided the “problematic” product. Therefore,
as you may have guessed, in this context my statement may apply only to those who may potentially be considered to be “distributing” (in terms of US law and GPLv2) or “conveying” (in terms of GPLv3) the product in question. The most interesting thing is that those who have actually authored its code and/or contributed to it don’t seem to be among them.

In my opinion, when Microsoft takes a third-party binary driver and digitally signs it with their own signature
(by which action they undeliably identify themselves as the official source of the driver), they take an immensely higher
risk of being involved, than if they re-distribute some bunch of source code, which has no relation to Microsoft whatsoever,
and even more, which has the real authors’ contacts written all over the source files.

Well, this is most definitely the area that only the lawyers are qualified to speak about. The maximum that I can do here is to comment on the whole thing solely from the technical point of view.

Objectively, as long as you have no access to the program’s sources you just cannot verify its correctness, simply because you are unaware of the theory of its operations. The only thing that you may potentially verify is its proper use of the resources, i.e. to test if it causes memory leaks, attempts to access the memory it has not allocated, etc. This is the absolute maximum. Objectively, you cannot test if the results of its computations are correct, simply because you are not in a position to decide upon the “correctness” criteria. If you are unaware of the theory of the program’s operations you simply have no way of knowing the expected “correct” output that should correspond to a given input, especially if we recall that the correspondence between these two may depend on the program’s state (at least as long as it has been written in an imperative language).

Therefore, as long as you have no access to the sources, you seem to be immune (at least in my layman’s view) to the claims concerning the correctness of the program’s operations. However, if the “distributors” or “conveyors” of the program have an access to its sources, this fact alone may, probably, have a potential for opening the entire window of the"exciting new opportunities" to the lawyers, at least in some jurisdictions.

But as of now, I’ve not seen any convincing examples, sorry.

Well, I have to admit that, once I am not a lawyer, all my statements on the subject are, in actuality, nothing more than just FUD and speculation. My point is that, as a software vendor, you would, apparently, try your best to minimise your exposure to the potential claims, even if they eventually turn out to be unfounded. After all, all this nonsense is guaranteed to be costly in terms of both money and time.

Anton Bassov