Discussion Committee B

Minutes for the meeting on morning of 17 January 2006

SysAdmins describe infrastructure workflow facilitation tools

- Justin Baugh <sysadmin@gnu.org>
- Tech support <tech@gplv3.fsf.org>
- mailing lists, archived to subscribers only
- committee pages for subscribers only
- conference phone with non-monitored 800 numbers
- shared Wiki space? Perhaps
- mailman list: committee-b@gplv3.fsf.org

Everyone will need to individually apply for an FSF account

Schedule for the eight upcoming 2h conf calls

- Tue 31 Jan 2006
- Thu 16 Feb 2006
- Tue 28 Feb 2006
- Thu 16 Mar 2006

- Tue 28 Mar 2006
- Tue 11 Apr 2006
- Thu 27 Apr 2006
- Tue 9 May 2006

- Mtg time: At the time in the attendee list

(8am-10am PST -- 18:00-20:00 EET)

New members of the committee

- Eben has mentioned SAP, Siemens, Apple, Cisco
- these shall be accepted
- the size shall be kept limited; the efficiency of the group will
otherwise drop
- We picked a date by which we accept no new committee members:
First mtg 31 Jan 2006

The theme of Committee B

- participants involved in businesses that depend on the propagation of Free / Open Source Software
- we should give our respective viewpoints on the license
The large-scale patent portfolio holders are also here

Today's agenda

- Building a list of issues that we can organise our thoughts around
- Enumerate items
- Come to understanding on the topics, given our time
- Get a well-defined issues list
- FSF will later provide us with the comments (collected elsewhere) that fits our issues list

How the issues list will interact with the rest

- 200 comments the first night
- likely 1000 comments the first week
- there will be a lot of comment routing to the discussion committees
- Committee A (technical) has identified "six buffer overruns"
- they will get a lot of early comments
- Committees will be routed to *individual* committees at least to begin with (not duplicating work)
- Aggregated issues, not individual committees, will then later be replicated to several committees
- The comment base will be purged when we go from Draft 1 to Draft 2; only issues will survive
- Issues will close when FSF issues formal opinions (mr Fontana, mr Moglen draft)
- Eben will have line numbers added to the GPLv3 draft

Confidentiality

- Individual comments are non-public
- emails sent during the discussions can be shared within the companies represented in the committee, but not quoted publicly
- think about what you say since the emails might leak anyway
- Minutes are public
- what we say in the minutes is intended to be quoted

The fate of LGPL?

- "The process document says..." FSF will release a first
draft on LGPLv3 later on, when GPLv3 draft 2 is out
- LGPL is in need of more fixing than GPL
- DRM is very significant in LGPL
- "Similar philosophy and intent as in GPLv3 might be
reflected in LGPLv3"
- LGPLv3 will likely be a complete standalone document

Deliverables

- Comments / issues
- Full list of arguments, "complete landscape"
- Will constitute input for other committees
- Not: "A view", "a consensus committee view"
- be specific on both sides, don't find the least
common denominator

When can scholars go through the materials of this process, i.e. the email flow?

- 6 months after promulgation, i.e. when GPLv3 was released

Considerations for committee processing of issues:

- Ownership (if nobody wishes to own it, then it can self-die)
- Anchor (Paragraph in the draft that it fits)
- Short description
- Long description
- Arguments
- Counterargument

Brainstorming material from which issues can be identified:

(don't flesh out the issues below; do it in the separate Issues/GroupBIssues document)

C1: Before Preamble, second sentence: Translation ("changing it") is not allowed?
there has never been given a formal permission for the translation of GPL

C2: 1: Is it possible to build a GPLv3 app on a non-free OS?

C3: 1: If I GPL a Java app, is JVM a general purpose tool or an interpreter? Does the JVM have to come with the operating system, or is it OK to have to download it separately? And what if you execute it on another machine?

C4: 1: General item: A better definition of linking

C5: 1: Scope of non-source disclosure obligations ("all information that might be necessary")
- how far does your disclosure obligation reach?
- interaction of GPLv3 with the semiconductor
- easy resolution, for some: we could say "copyright or equivalent"
- silicon masks of a chip, how to optimise for a chip

C6: 1: What does "understand" mean? I need to see all kernels in order to port glibc

C7: 1: what does it mean to "require" a patent license
- structure: does this apply just to the previous phrase,
or also earlier parts of the text (English language composition)

C8: 1, 3: Protected boot

C9: 1, 6, 12: How does one "know" what is covered by a patent, unless a court order has not told you so

C10: 2: what does propagation mean *within* a company (intra-institutional distribution)
- are the companies immune to propagation?
- is the US govt one single entity?
- example: classified software within US govt
- GPLv2 was thus very liberal when it comes to the size of an entity
- FSF does not want to be US dependent
- are contractors within a company or not?
- what about subsidiaries? acquired companies?
- what happens if a company breaks up?
- there is an answer in the US, but GPLv3 should answer globally
- there is a tension between entities developing SW and entities using SW in this issue
- business models relying on dual licensing benefit from
stricter interpretations of what constitutes propagation
- and they expand the world of GPL SW!

C11: 2, 7e: Covenant not to sue
- Audit provision? Feedback mechanism for use of GPL SW?
- in practice: this clause is an invitation to conduct a witch hunt for traces of GPL SW during discovery of a patent lawsuit
- defensive use (counterclaims) should be allowable, perhaps?
- scope question: have we done something we didn't intend
- have we intended the right thing

C12: 3§1: appears to be legally a no-op. there is no legal statement in it. Does it need to be there?
- except it changes the right of who can sue
- all other issues deal with copyright, licensing software
- this one is about privacy, and it has nothing to do with copyright & licensing
- it seems like a pet peeve!
- it's not enforcible by the person whose privacy was invaded
- pls take it out!

C13: 5: Compliance with the source code of disclosure obligations (source availability)

C14: 5: Contradictory language -- shipping together vs separate, §1 and
§2 vs §5 -- mere inclusion in an aggregate does *not* constitute aggregation

C15: 5 (Complicated) last three §: When you distribute --
- what is "in combination with"?
- Is there a conflict with aggregation?
- what is "collective work"
- the meaning of these three needs to be clear
- is there a distinction between modifications and extensions?

C16: 6c: What constitutes "occasional", "non-commercial"?

C17: 7: the "central list" concept: what does it mean? (about box etc.)
-- messy at the source level
- machine interpretation would be great (practical issue)
- why necessary to require additional grants?
- 802.11g frequency range, power frozen (so rest can be open)
- exception for wireless drivers? regulators?
- strategic obscurity

C18: 7: Danger that the different versions can be incompatile with each other (can we make two GPLv3 programs that cannot be combined?)

C19: 7e: Compatibility with other OSI licenses (Apache? Mozilla?)

C20: 8: The language around cure periods for breaches is laudable but could stand some improvement

C21: 9: "Is this not a contract?"

C22: 11: "patent license", does it also include other forms of agreeing not to sue, even if it is not technically a license
- what if you own the patent yourself?

C23: 11: Is distribution the right trigger for the patent license?

C24: 11§1: Scope of express patent license

C25: 11§2: Patent protection clause for downstream consumers

C26: 12: Cross licensing agreements

C27: 12: Type approval (in USA: FCC, governmental regulation in other countries too)

C28: 13: Geography restrictions should be deleted
- US export requirements on encryption exports was the reason to have it
- it is unclear against which geographies 13 might be used

C29: 16, 17: Effectivess of warranty DISCLAIMER

C30: 18, last sentence: Is benign, but it might be misinterpreted. The warranty says the same.
- 7b: adding other disclaimers is OK anyway, so it's redundant
- but at least US should have a single set of disclaimers

C31: throughout: probably ok -- consistency in the use of propagation vs distribution?