Live data from Hacker News

An Open Letter to Intel

cs.vu.nl

321–330 of 379 posts

Re: An Open Letter to Intel

#321
post #284
post #268

Earlier quoted context omitted.

The strict meaning of "Redistributions" in that clause means that Intel would have to be distributing the OS itself as a product in binary form. Deploying it in an embedded system, and selling that embedded system, particularly in a form where the user does not have access to the OS as a product, does not meet that definition. Tanenbaum himself concedes this point in this letter.

This is quite debatable, not something I'd bet a court case on. One of my libraries with BSD 3-clause license was used in a U.S. government project. It did require particular hardware and couldn't really be deployed by any random user but they honored the mention clause without any prodding on my part. My Bosch kitchen appliances came with a whole bunch of software licenses for embedded subsystems, even GPL ones. So…

>So it seems actual lawyers in a huge international corporation decided it constitutes distribution.

I mean, they could also just assume that shipping three sheets of paper with each washer is just cheaper than finding out.

Re: An Open Letter to Intel

#322
post #89

> this bit of news reaffirms my view that the Berkeley license provides the maximum amount of freedom to potential users I'm sorry, but I don't feel free because of that. What I see is that I have proprietary code I never saw, never vetted and which I don't (and shouldn't) trust that's running on all my computers (not all, but you can get it) and that I don't have the freedom to remove, examine, modify or replace. Th…

If you are worried about this un-vetted blob, it means you don't trust Intel; if you don't trust Intel, why does it matter that they have this blob running in 'god' mode? They ARE the CPU, so they aren't just god 'mode' they are god itself.

You are trusting the CPU to do what you ask it to do. If intel were to do something shady, they wouldn't need a un-vetted blob of code to do it, they could do it directy in the CPU itself.

I guess my point is that you have to trust the CPU manufacturer, whether they have this code or not.

Re: An Open Letter to Intel

#323
post #307

Earlier quoted context omitted.

>That is not true. What are you basing this on? Personal experience? Speculation? Other? >If a company does not follow the GPL and is called out, they can simply do what the GPL tells them to do and the case is done. Ask Cisco if the lawsuit from the FSF was fictional. I was involved with the GPL license a few years back when I was consulting on an embedded hardware device product. We wrote to the developer and reque…

So you wanted to write proprietary software on top of someone's GPL code, the developer couldn't be swayed by money, so now you are bitter about it? Talk about entitlement.

>So you wanted to write proprietary software on top of someone's GPL code,

Incorrect.

> the developer couldn't be swayed by money,

Incorrect. We made the request on the basis of legal advice to avoid licensing trouble. These are real things that happened on a real project. The idea that lawyers are never involved when using GPL'd code is a fantasy.

In any case, the reason the developer refused is because there were multiple contributors on the project, and it would have created a headache for them.

>so now you are bitter about it?

Incorrect.

>Talk about entitlement.

So rude. Wow..

Re: An Open Letter to Intel

#324
post #67

Earlier quoted context omitted.

> (...) computer operating system (...) I guess that by "computer" he means "desktop".

He doesn't know what he means. Linux is deployed on more than 1/cpu through VMs.

> He doesn't know what he means.

I'm pretty sure he does.

Re: An Open Letter to Intel

#325

All Dr. Tanenbaum is saying is that it would have been the classy thing to let him know, nothing more. Professor Tanenbaum is one of the most respected computer scientists alive, and for Intel to include Minix in their chip and not let him know is kind of unprofessional and not very nice to say the least. That is his only (and quite fair) point.

The licensee we're talking about here is a corporation, not a human who feels emotions like gratitude and respect. If he wanted them to be "classy" or "nice," he should have included that as a clause in the software licenses.

Re: An Open Letter to Intel

#326
post #89

> this bit of news reaffirms my view that the Berkeley license provides the maximum amount of freedom to potential users I'm sorry, but I don't feel free because of that. What I see is that I have proprietary code I never saw, never vetted and which I don't (and shouldn't) trust that's running on all my computers (not all, but you can get it) and that I don't have the freedom to remove, examine, modify or replace. Th…

If you are worried about this un-vetted blob, it means you don't trust Intel; if you don't trust Intel, why does it matter that they have this blob running in 'god' mode? They ARE the CPU, so they aren't just god 'mode' they are god itself. You are trusting the CPU to do what you ask it to do. If intel were to do something shady, they wouldn't need a un-vetted blob of code to do it, they could do it directy in the CP…

You are partly correct, but I think you're overlooking some things. I agree that we realistically have to trust Intel that their CPUs will do what the code tells them to. However, in this case they're actually telling us that the ME chip has overriding control over the system, that we can't tell the chip what to do, and that they won't tell us exactly what it's doing at any time or allow inspect the code its running. That isn't the case for their CPUs. This also opens up the possibility of a third party either finding a vulnerability in the code that we don't have access too, or simply gaining access to Intel's code signing keys, and using it to attack our computers. That's possible if the code works as designed, whereas that does not apply to CPUs.

Re: An Open Letter to Intel

#327
post #103

Earlier quoted context omitted.

> and for Intel to include Minix in their chip and not let him know is kind of unprofessional and not very nice to say the least. I guess Minix' license, which allows this kind of behaviour, is the very reason Intel chose Minix in the first place. I imagine it would be very complicated to get management approval for informing Dr. Tannenbaum about the usage in Intel's ME. IMHO if he has a problem with the way things w…

He did cover those points in the letter: > I guess Minix' license, which allows this kind of behaviour, is the very reason Intel chose Minix in the first place. I imagine it would be very complicated to get management approval for informing Dr. Tannenbaum about the usage in Intel's ME. Tanenbaum: Some people have pointed out online that if MINIX had a GPL license, Intel might not have used it since then it would have…

> partly an exercise in self promotion

if so i don't begrudge that, as it's not like intel was saying much about it. :P

Re: An Open Letter to Intel

#328
post #125
post #36

Earlier quoted context omitted.

Won what? - Being the kernel of ChromeOS and Android, not accessible to majority of userspace and easily replaceable by anything else (e.g. Fuchsia). - Lost to macOS and Windows on the desktop It only won on the server room, and now it runs under Minix supervision.

> and easily replaceable by anything else (e.g. Fuchsia). If it's so easy, why hasn't it happen yet?

if it's "easy" does that imply it must "happen yet"?

Re: An Open Letter to Intel

#329

From the Network World report: > If you have a modern Intel CPU (released in the last few years) with Intel’s Management Engine built in, you’ve got another complete operating system running that you might not have had any clue was in there: MINIX. That's different from Mr. Tannenbaum's claim: > Thanks for putting a version of MINIX 3 inside the ME-11 management engine chip used on almost all recent desktop and lapto…

what about them? i'm not sure what you're question is getting at.

Re: An Open Letter to Intel

#330

Earlier quoted context omitted.

If you are worried about this un-vetted blob, it means you don't trust Intel; if you don't trust Intel, why does it matter that they have this blob running in 'god' mode? They ARE the CPU, so they aren't just god 'mode' they are god itself. You are trusting the CPU to do what you ask it to do. If intel were to do something shady, they wouldn't need a un-vetted blob of code to do it, they could do it directy in the CP…

You are partly correct, but I think you're overlooking some things. I agree that we realistically have to trust Intel that their CPUs will do what the code tells them to. However, in this case they're actually telling us that the ME chip has overriding control over the system, that we can't tell the chip what to do, and that they won't tell us exactly what it's doing at any time or allow inspect the code its running.…

Yeah, I guess my comments was assuming the trust was of the type 'trust not to do something nefarious' rather than 'trust not to have a vulnerability'. You make a good point about the latter being a more serious concern in this case.
Post reply on HN