OSBC: Life at the edge of the GPL

Posted Mar 28, 2009 10:49 UTC (Sat) by HenrikH (subscriber, #31152)
Parent article: OSBC: Life at the edge of the GPL

>However, distribution could happen in a lot of ways. Does depositing source
> code in escrow count as distribution? How about an acquisition that's
>structured as a sale of assets from one company to another? "Relying on no
>distribution is very dangerous. There are a lot of situations where
>distribution can happen but you wouldn't think of it as distribution,"
>Norman said.

Perhaps he should read the license itself?

>You may make, run and propagate covered works that you do not convey,
>without conditions so long as your license otherwise remains in force.
>You may convey covered works to others for the sole purpose of having
>them make modifications exclusively for you, or provide you with
>facilities for running those works, provided that you comply with the
>terms of this License in conveying all material for which you do not
>control copyright. Those thus making or running the covered works for you
>must do so exclusively on your behalf, under your direction and control,
>on terms that prohibit them from making any copies of your copyrighted
>material outside their relationship with you.

So no I do not think that it's easy to distribute without knowing that you distribute.

OSBC: Life at the edge of the GPL

Posted Mar 28, 2009 17:42 UTC (Sat) by BrucePerens (guest, #2510) [Link] (3 responses)

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.

OSBC: Life at the edge of the GPL

Posted Mar 28, 2009 21:36 UTC (Sat) by HenrikH (subscriber, #31152) [Link] (2 responses)

But your whole example is covered in GPLv3 by this text:

>You may convey covered works to others for the sole purpose of having
>them make modifications exclusively for you, or provide you with
>facilities for running those works, provided that you comply with the
>terms of this License in conveying all material for which you do not
>control copyright.

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.