1. Roll call.  Present:

Eben Moglen, SFLC

Richard Fontana, SFLC

Helene Plotka Workman, Apple Computer

Joyce Chow, Apple Computer

Kevin Perkins, EMC

Paul Madick, Hewlett Packard

Phil Robb, Hewlett Packard

Satoshi Oshima, Hitachi

Mitsunori Satomi, Hitachi

Mark Brown, IBM

Craig Cook, IBM

Terry Ilardi, IBM

Andrew Wilson, Intel         

McCoy Smith, Intel

Dietmar Tallroth, Nokia

Greg Jones, Novell

Patrick McBride, Novell

Kevin Cheatham, QUALCOMM

Damien Eastwood, Sun Microsystems

David Marr, Sun Microsystems

Paul O. Tvete, Trolltech

Others also joined the call after roll was called

2. Approve the minutes from the meeting 11 Apr 2006.

http://gplv3.fsf.org/discussion-committees/B/Minutes/bminutes060411

 The minutes were approved.

3. Continue discussion of issues relating to complete corresponding source code/scope/derivative works:  C2, C3, C4, C6, C14, C15

Eben indicated that preparation of the second draft will commence in early May, with an anticipated release of the second draft to the public in mid-June to early-July (July 1^st is likely release date).  All committee members should be working on posting proposed language revisions within the next three weeks (some proposals have already been posted on some of the comments discussed in today’s meeting), before the redrafting process begins, so that any such suggestions are considered by FSF & SFLC while preparing next draft.

C2: GPLv3 applications on a non-free OS

Suggestion was made that the term “understand” ought to be removed from the list of verbs requiring providing complete corresponding source code, as it causes too many questions about scope of source code obligations (such as C2, whether GPLv3 apps can run on non-free OS).

In general, Eben indicated that GPLv3 obligations are not intended to make impossible the creation of GPLv3 apps running on a non-free OS – the “complete corresponding source code obligations do not extend down to obligate the creator of the GPLv3 app to make available source code for a non-free OS the creator does not distribute.

To the extent that creation of a GPLv3 app for a non-free OS involves dynamically linking to proprietary (non-free) scripts & libraries, the distributor of the GPLv3 app need not provide source if those scripts or libraries are normally provided with the OS.  This is the intention and meaning of the “system library” exception. 

Eben did discuss the extent to which the “system library” exception is applicable.  The library itself must be offered as part of the OS and not as a separate component independent of the OS.  If the library is freely available (for example, for download) but is not part of OS on which the GPLv3 app runs, that does not fall within the “system library” exception and should be released under GPL – but only if that library is not a separate and independent work.  The members of Committee B should consider whether to propose specific language changes that should be made to make clear that separately available libraries that are independent works and which are not distributed with the GPLv3 app or with the OS either are not required to be GPLv3.

There was some discussion of lines 119-129 and the way the system library exception is expressed.  Could part (a) be more encompassing/less restrictive and section (b) less encompassing/more restrictive?  Eben is concerned that this exception not allow people to make fee-charged OS add-ons.  There was some discussion about whether in section (b) “only” is necessary, or should it be written negatively –- i.e., does not apply to a subunit that is designed to “embrace or extend”?  One suggestion was to broaden up (or define more precisely) what is an “incidental extensions”?  Eben indicated that an incidental extension is the minimum use of the library, as opposed to someone who makes non-free with enhancement of the API.

C3: Virtual Machines and Runtimes

This issue has already been answered in prior discussions.  A JVM acts very much like an interpreter in function and "connectedness" to an application written to use it, which Eben has agreed.  Some clauses were submitted and reworked in other comments.  Language changes will be adopted to addressed this in next draft, but any suggestions to make sure that VMs and RT are address should be put in the various suggestions on improved language that have been put in the draft proposals already on the site.

C4: A better definition of linking

Linking is a technical term used by programmers and the intent of the term "linking" in the GPLv3 is that technical definition.  Eben stated that when the linking occurs, be it statically or dynamically does not matter as far as the copyright/copyleft derivative work issue was concerned.  They are the same.

Scripts, fonts, macros, etc. that are GPL, do they cause works using those to be GPL?  Fonts are data, per Eben.  Distinction here is that the “output” is not forced to be GPL just because GPL things are used to generate the output.  Macro is that same concept – that’s nothing more than what user could have typed him or herself.

Plug-ins:  when releasing a plug-in GPL -– user in doing this is indicating that it can only be plugged-in to GPL (because the result is the whole must be GPL).  If the intent is not for the plug-in to cause everything to be GPL, then the release should be under LGPL.

“Arms-length” vs. “intimate” (to the extent that those are understood via redraft, FAQ or other mechanisms) are the important dividing line between what need not be GPL and that which must.  There was some suggestion that there be some better clarity, either in the license draft itself, the “legislative history” or the FAQs explaining the distinction between “arms-length” and “intimate” so that there was better precision around when one must GPL and when one needn’t.

The term "intimate" is intended to mean "an absence of publicity".  That is to say that when two pieces of code are operateing at "arms length" using standard and well-defined interfaces that are used by multiple other programs, then those two pieces of code are clearly not the same work.

“Designed to require” is nothing more than strong copyleft, not intended to do anything different or an expansion.  Best example is delocalized proprietary kernel modules.  “Designed to require” is actually a limitation on the “dynamicallly linked” requirement, narrowing it to make clear that dynamically linked things that aren’t designed to require GPL code (because they are generic, and can be used equally with non-GPL code) don’t have to be GPL.  This also is intended to prevent GPL shims used to link to proprietary code.

The assymetry is intentional here.  If the GPL doesn’t require something proprietary, no need to GPL the proprietary.

C6: "Understanding" a work

See Patrick McBride’s proposal and make any suggested comments or proposed changes.  That language can also be proposed to modifications for other comment other than C6.

C14: Mere aggregation & C15: combinations, collectives, and aggregates

This issue was addressed at the end of the call and it was agreed that it needed more discussion at next meeting.  Example Eben gave for this language is with a “munger” that takes GPL driver, translates it into binary code for a different OS (for example, Solaris), and the OS vendor gives the OS and the “munger” to the user and tells them to download the GPL driver and run it through the “munger” so that it will run on the OS.  Eben saw this as induced infringement (per Grokster) and therefore something that GPL could say is improper (or at least, that the OS vendor would be required to allow the user to get the source code for the binaries created by the munger).  Others on the call seemed to see this as an expansion from GPLv2 and therefore wanted to discuss this issue in more depth next time. 

 4. DRM - C6a

 http://gplv3.fsf.org/discussion-committees/B/Issues/C6A/

 This issue was not discussed during the meeting, and is deferred to next meeting.

5. Plan for next meeting: 9 May 2006

 Agreed-to topics were C14 & C15 (aggregation & combination;  “induced infringement”) and C6a (DRM).

 Everyone should also review minutes from April 27 meeting and start working on specific language revisions or proposals on how to revise current draft for next draft.