OSBC: Life at the edge of the GPL

OSBC: Life at the edge of the GPL

It's easy to distribute inadvertently. The key is that distribution is a transfer between any two legal entities. So, if you have a consultant working in your company and you give him the software, that's distribution. If said consultant later becomes upset with your company, he can try to assert his GPL rights. His NDA doesn't matter, because the GPL does not allow the addition of terms such as those found in an NDA.

The same applies to a partially-owned subsidiary, etc.

So, in general, your GPL compliance strategy should never rely on avoidance of distribution. It's too difficult to maintain.

I don't advise my customers to comply through shimming alone. That's too risky, too. I want to see some physical separation of programs - user to kernel, or separate CPU.

He makes a good point about "intimate" communication. The API used between the kernel and your software shouldn't be anything but its usual exported API or something that is well known and general like the Hayes modem protocol used to communicate with the GSM stack in cell phones. If you go messing around kernel internals, it's going to be very difficult to say something is not a derivative work.