| |||||||||||||
OSBC: Life at the edge of the GPLOSBC: Life at the edge of the GPLPosted Mar 28, 2009 17:42 UTC (Sat) by BrucePerens (guest, #2510)In reply to: OSBC: Life at the edge of the GPL by HenrikH Parent article: 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.
(Log in to post comments)
OSBC: Life at the edge of the GPL Posted Mar 28, 2009 21:36 UTC (Sat) by HenrikH (guest, #31152) [Link]
But your whole example is covered in GPLv3 by this text:
>You may convey covered works to others for the sole purpose of having
So your consultant would have no where to go with that argument.
OSBC: Life at the edge of the GPL Posted Mar 29, 2009 0:48 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Majority of software is still GPLv2 and in the case of GPLv2, these situations have not been clearly stated and it is going to remain a problem and a risky situation for quite sometime. That is unfortunate.
Yes, if only... Posted Mar 29, 2009 2:22 UTC (Sun) by BrucePerens (guest, #2510) [Link] GPL3 disambiguates a lot. Not just the consultant issue, but the API issue. GPL3 makes it clear that an API that is an Open Standard can be a demarcation between GPL3 software and other software.Too bad the Linux kernel team isn't using GPL3. Essentially all of these issues are concerning the Linux kernel.
|
|||||||||||||