Uh I think I think that's way too mean to the email. From a random web form they got some technical information, a useful CC, and offer to have a call. Not bad at all!
Also, my basic theory about hardware problems is that the problem is less that they won't share the docs, and more that even the internal docs suck. When you essentially co-evolve devices and software through many revisions of each over many years, it's easy to get a complete mess that nobody understands.
(Of course, in this specific case, DisplayLink was new, so it's maybe less of a problem.)
I think they’re upset that the library was to be released under LGPL or whatever, even though they clearly went and read from it anyway when implementing their thing.
It seems they're pretty directly admitting to referring to the LGPL library while implementing theirs under a different license.
I wonder if they'll have no issues with people directly reading their code while happening to implement the same functionality with a closed license? Or a GPL-style one?
I'm surprised they admitted to it - it's hardly "Clean Room"....
Looking at the answer, I wouldn't call it unhelpful. They were planning to release a source for the library that would essentially implement all the needed data interfaces? That's more than helpful and at least they responded.
I tried contacting Nuvoton for example about their documentation for some of their super I/O chips which lack Linux support (they do document a bunch of their chips pretty well, but for some weird reason not all).
Not only I got no details, I literally didn't even get a response from them at all. So above case is hugely better.
"<mglock> DisplayLink TM seems to be very communactive.
<mglock> asked the for specs for their DL-120/DL-160 chips, and got a detailed answer withing 4 hours."
Go through the Linux Foundation, they have a process for accessing docs for drivers that vendors normally require NDAs with established businesses for, and won't offer random people.
This is definitely not true. It’s even sometimes possible to negotiate contract and NDA terms with Large Corporations for the specific purpose of producing open source code based on NDA specs.
There are all kinds of reasons. One basic example would be if the vendor has a data sheet but does not have the right to grant anyone redistribution rights to the datasheet or may even be restricted from allowing anyone to read it without an NDA. Another might be that the vendor has a general rule that their engineers don’t talk to outside people without an NDA but has decided, as a business matter, to allow the engineers to talk to a specific developer and that they want an open source driver developed. A third might be that the vendor wants to be able to have detailed conversations about proprietary implementation details of their hardware and decide later which details are going to become public.
Yeah it depends on their stance, some vendors just want an entity that can be bound by contract and they could theoretically sue if you leak their docs, and the Linux Foundation can serve that role.
> The answer was as unhelpful as possible
Uh I think I think that's way too mean to the email. From a random web form they got some technical information, a useful CC, and offer to have a call. Not bad at all!
Also, my basic theory about hardware problems is that the problem is less that they won't share the docs, and more that even the internal docs suck. When you essentially co-evolve devices and software through many revisions of each over many years, it's easy to get a complete mess that nobody understands.
(Of course, in this specific case, DisplayLink was new, so it's maybe less of a problem.)
I think they’re upset that the library was to be released under LGPL or whatever, even though they clearly went and read from it anyway when implementing their thing.
It seems they're pretty directly admitting to referring to the LGPL library while implementing theirs under a different license.
I wonder if they'll have no issues with people directly reading their code while happening to implement the same functionality with a closed license? Or a GPL-style one?
I'm surprised they admitted to it - it's hardly "Clean Room"....
> The answer was as unhelpful as possible
Looking at the answer, I wouldn't call it unhelpful. They were planning to release a source for the library that would essentially implement all the needed data interfaces? That's more than helpful and at least they responded.
I tried contacting Nuvoton for example about their documentation for some of their super I/O chips which lack Linux support (they do document a bunch of their chips pretty well, but for some weird reason not all).
Not only I got no details, I literally didn't even get a response from them at all. So above case is hugely better.
That's what Marcus said himself, too
"<mglock> DisplayLink TM seems to be very communactive. <mglock> asked the for specs for their DL-120/DL-160 chips, and got a detailed answer withing 4 hours."
Go through the Linux Foundation, they have a process for accessing docs for drivers that vendors normally require NDAs with established businesses for, and won't offer random people.
If they require an NDA, they'll probably refuse to provide it for the purpose of Linux drivers?
Unless it's just some dumb formality. I can try Linux Foundation.
This is definitely not true. It’s even sometimes possible to negotiate contract and NDA terms with Large Corporations for the specific purpose of producing open source code based on NDA specs.
Source: been there, done that.
Why would they need an NDA then if they would be OK with open source implementation? It's good if that's possible, it just doesn't make sense.
There are all kinds of reasons. One basic example would be if the vendor has a data sheet but does not have the right to grant anyone redistribution rights to the datasheet or may even be restricted from allowing anyone to read it without an NDA. Another might be that the vendor has a general rule that their engineers don’t talk to outside people without an NDA but has decided, as a business matter, to allow the engineers to talk to a specific developer and that they want an open source driver developed. A third might be that the vendor wants to be able to have detailed conversations about proprietary implementation details of their hardware and decide later which details are going to become public.
Yeah it depends on their stance, some vendors just want an entity that can be bound by contract and they could theoretically sue if you leak their docs, and the Linux Foundation can serve that role.
More info here: https://www.linuxfoundation.org/legal/nda
Thanks for the pointer!