[License-discuss] Intimacy in open source

Lawrence Rosen lrosen at rosenlaw.com
Mon Jan 14 17:40:14 UTC 2019


Scott Peterson wrote:

> “Intimate” is the most useful term we know to describe the kind of convoluted interaction and deep knowledge that suggests that one part is specifically designed to require another part.

 

What is the relevance of "convoluted interaction" and "deep knowledge," and why should open source licenses care about independent implementations regardless of their design for utility? The attempt of the GPLv3 committee to create the term "corresponding source" to identify nothing specific (except perhaps "intimacy") was the worst mistake of GPLv3 drafting. "Intimate" means "a very close friend." Where is that concept in copyright law? When used in AGPL, it scares all the big companies away! I don't blame them.

 

/Larry

 

 

From: License-discuss <license-discuss-bounces at lists.opensource.org> On Behalf Of Scott Peterson
Sent: Monday, January 14, 2019 7:31 AM
To: Gil Yehuda <gyehuda at oath.com>
Cc: license-discuss at lists.opensource.org
Subject: Re: [License-discuss] Intimacy in open source

 

On Thu, Jan 10, 2019 at 11:43 AM Gil Yehuda via License-discuss <license-discuss at lists.opensource.org <mailto:license-discuss at lists.opensource.org> > wrote:

First time posting to this group. I hope the subject line got you to read further. I'm not asking for legal advise, but posing a question about a phrase used in AGPL/GPL v3.0 and hoping to get insight on how to interpret it properly. The phrase is "intimate data communication" as found here:

For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

When I read this, I interpret intimate data communication as the relationship between a database driver and a database. That's the role of a driver -- to have intimate communications with the DB so that your calling application can bind to the driver, not the DB. I'm asking this group: is my interpretation sound? 

 

In case you have not already looked at these, here are two references you might consider:

 

Rationale documents that were published as a part of development of GPLv3. In particular, see footnote 21 in the third rationale document:

21 We have made minor clarifications to this definition. Our restoration of “intimate” in place of the Draft 2 substitution “complex” followed from further public discussion of the Corresponding Source definition, in which it became clear that “complex” in the context of data communication suggested interpretations quite different from what we had intended.

“Intimate” is the most useful term we know to describe the kind of convoluted interaction and deep knowledge that suggests that one part is specifically designed to require another part.

http://gplv3.fsf.org/gpl3-dd3-rationale.pdf

 

GPL FAQs published by the FSF. In particular:

https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation

https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins

 

-- Scott

Scott K Peterson

Senior Commercial Counsel

Red Hat, Inc.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190114/2a886e8e/attachment.html>


More information about the License-discuss mailing list