From novalis at fsf.org  Tue May  2 10:46:06 2006
From: novalis at fsf.org (David Turner)
Date: Tue, 02 May 2006 10:46:06 -0400
Subject: [Committee-d] Meeting today
Message-ID: <1146581166.4091.27.camel@shepard>

Sorry I've been out of town for a couple of weeks.

There's a committee D meeting today at 2200 UTC, which is 6pm EDT.

Please join us on IRC.


From novalis at fsf.org  Tue May  2 14:22:40 2006
From: novalis at fsf.org (David Turner)
Date: Tue, 02 May 2006 14:22:40 -0400
Subject: [Committee-d] Last chance to comment this round
Message-ID: <1146594160.2502.16.camel@shepard>

Please remember that the last chance this round for reports is coming up
on May 15.  Our last meeting before then is next week.  

We are waiting for reports:
Zak Greant is working on section 5c.

David Rickerby is working on non-traditional source distribution.

Don Arnstrong is working on copyright information on startup -- he has
completed other areas.

Benjamin "Mako" Hill is working on the affero compatibility clause

Jean-Baptiste Soufron is working to prepare a report on the EUCD
implications of GPLv3.  This isn't strictly an issue, but it's something
we want to see.

Steven Edwards is working on renaming the license, and on the Changelog
issue in comment 682.  He says that he will have a report in the next
few days or not at all.

James Blackwell is working on explaining how GPLv3 fights DRM, and on
physical media for source too expensive

Jesse Vincent is working on the phrase "digital restrictions
management" 

Massimo Tisi is working on "source code isn't executed" said he would
address this.  

Daniel Scales is working on gpl3.licensingpatents.p2.s1


From zak at greant.com  Tue May  2 18:40:35 2006
From: zak at greant.com (Zak Greant)
Date: Tue, 2 May 2006 15:40:35 -0700
Subject: [Committee-d] Last chance to comment this round
In-Reply-To: <1146594160.2502.16.camel@shepard>
References: <1146594160.2502.16.camel@shepard>
Message-ID: <337EA500-02CF-406A-B04D-4483025EE7CB@greant.com>


On May 2, 2006, at 11:22PDT (CA), David Turner wrote:

> Please remember that the last chance this round for reports is  
> coming up
> on May 15.  Our last meeting before then is next week.
>
> We are waiting for reports:
> Zak Greant is working on section 5c.

Still working - swamped but filled with good intentions.
--zak


From novalis at fsf.org  Tue May  2 15:41:17 2006
From: novalis at fsf.org (David Turner)
Date: Tue, 02 May 2006 15:41:17 -0400
Subject: [Committee-d] Meeting re section 7d
Message-ID: <1146598877.2502.32.camel@shepard>

Mako couldn't make today's meeting.  We had a long discussion of section
7d.  Since this is his area, I want to hear his comments.  Let's
tentatively schedule another meeting for Thursday at 2000 UTC. Mako, if
you can make that, let us know.  Else, let us know a time which would be
good for you.


From mako at debian.org  Wed May  3 23:38:05 2006
From: mako at debian.org (Benj. Mako Hill)
Date: Wed, 3 May 2006 23:38:05 -0400
Subject: [Committee-d] Meeting re section 7d
In-Reply-To: <1146598877.2502.32.camel@shepard>
References: <1146598877.2502.32.camel@shepard>
Message-ID: <20060504033805.GA7861@yukidoke.org>

Sorry. I sent the first mail from the wrong address and it was held up
by the moderator.

<quote who="David Turner" date="Tue, May 02, 2006 at 03:41:17PM -0400">
> Mako couldn't make today's meeting.  We had a long discussion of section
> 7d.  Since this is his area, I want to hear his comments.  Let's
> tentatively schedule another meeting for Thursday at 2000 UTC. Mako, if
> you can make that, let us know.  Else, let us know a time which would be
> good for you.

I think that I'm going to be on a bus to New York city then. Earlier in
the day would work out. Any time between 14 and 17 UTC would work. I
don't want to start much later than that. Or Friday on 21 or 22 UTC
would work as well.

Regards,
Mako

-- 
Benjamin Mako Hill
mako at debian.org
http://mako.cc/

From novalis at fsf.org  Thu May  4 06:58:24 2006
From: novalis at fsf.org (David Turner)
Date: Thu, 04 May 2006 06:58:24 -0400
Subject: [Committee-d] TODAY, 1700 UTC: Meeting re section 7d
In-Reply-To: <20060504003933.GC6839@yukidoke.org>
References: <1146598877.2502.32.camel@shepard>
	<20060504003933.GC6839@yukidoke.org>
Message-ID: <1146740304.8881.3.camel@shepard>

OK, 1700 UTC it is.  That's 1300 EDT.

On Wed, 2006-05-03 at 20:39 -0400, Benj. Mako Hill wrote:
> <quote who="David Turner" date="Tue, May 02, 2006 at 03:41:17PM -0400">
> > Mako couldn't make today's meeting.  We had a long discussion of section
> > 7d.  Since this is his area, I want to hear his comments.  Let's
> > tentatively schedule another meeting for Thursday at 2000 UTC. Mako, if
> > you can make that, let us know.  Else, let us know a time which would be
> > good for you.
> 
> I think that I'm going to be on a bus to New York city then. Earlier in
> the day would work out. Any time between 14 and 17 UTC would work. I
> don't want to start much later than that. Or Friday on 21 or 22 UTC
> would work as well.
> 
> Regards,
> Mako
> 


From zak at greant.com  Thu May  4 11:48:15 2006
From: zak at greant.com (Zak Greant)
Date: Thu, 4 May 2006 08:48:15 -0700
Subject: [Committee-d] TODAY, 1700 UTC: Meeting re section 7d
In-Reply-To: <1146740304.8881.3.camel@shepard>
References: <1146598877.2502.32.camel@shepard>
	<20060504003933.GC6839@yukidoke.org>
	<1146740304.8881.3.camel@shepard>
Message-ID: <73C0CC70-1C75-4786-91D5-005A25681C06@greant.com>


On May 4, 2006, at 03:58PDT (CA), David Turner wrote:

> OK, 1700 UTC it is.  That's 1300 EDT.

In a meeting then. --zak

From mako at atdot.cc  Wed May  3 20:39:33 2006
From: mako at atdot.cc (Benj. Mako Hill)
Date: Wed, 3 May 2006 20:39:33 -0400
Subject: [Committee-d] Meeting re section 7d
In-Reply-To: <1146598877.2502.32.camel@shepard>
References: <1146598877.2502.32.camel@shepard>
Message-ID: <20060504003933.GC6839@yukidoke.org>

<quote who="David Turner" date="Tue, May 02, 2006 at 03:41:17PM -0400">
> Mako couldn't make today's meeting.  We had a long discussion of section
> 7d.  Since this is his area, I want to hear his comments.  Let's
> tentatively schedule another meeting for Thursday at 2000 UTC. Mako, if
> you can make that, let us know.  Else, let us know a time which would be
> good for you.

I think that I'm going to be on a bus to New York city then. Earlier in
the day would work out. Any time between 14 and 17 UTC would work. I
don't want to start much later than that. Or Friday on 21 or 22 UTC
would work as well.

Regards,
Mako

-- 
Benjamin Mako Hill
mako at atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so
far as society is free to use the results. --RMS

From novalis at fsf.org  Tue May  9 13:10:06 2006
From: novalis at fsf.org (David Turner)
Date: Tue, 09 May 2006 13:10:06 -0400
Subject: [Committee-d] 2200 GMT: Final meeting for this draft
Message-ID: <1147194606.8974.132.camel@shepard>

There is a Committee D meeting at 220 GMT.  This meeting is our last
chance to discuss issues for this draft.  Anything we submit after May
15 will have to apply to the next draft.


From zak at greant.com  Tue May  9 17:25:46 2006
From: zak at greant.com (Zak Greant)
Date: Tue, 9 May 2006 14:25:46 -0700
Subject: [Committee-d] Draft recommendation for section 5c
Message-ID: <CA2F7A81-0FE0-45CC-A753-5E3B878760D0@greant.com>

Please beat this like a giant pi?ata - it still needs a good deal of  
redacting.

GPLv3 Section 5c
================
Protecting creators and ensuring that consumers know their rights.

Overview
++++++++
Section 5c's primary purpose is to protect and enable consumers of
GPL-licensed software. It does so by requiring notices of a specific
type on modified versions of GPL v3-licensed software. These notices
help ensure that recipients of the software know what rights they are
granted, as well as what terms and conditions apply to the software.

Additionally, section 5c notices provide important protection for
creators by helping to ensure that users know that the software is
without warranty and by disclosing the complete origin of modified
versions of the software.

These intents for section 5c is partially described in several parts of
the preamble:

"... you must show them these terms so they know their rights."
     --GPLv3 Discussion Draft 1, Preamble, Para. 4

"For the developers' and author's protection, the GPL clearly explains
that there is no warranty for this free software. If the software is
modified by someone else and passed on, the GPL ensures that recipients
are told that what they have is not the original, so that any problems
introduced by others will not reflect on the original authors'
reputations."
     --GPLv3 Discussion Draft 1, Preamble, Para. 6

Community Input
+++++++++++++++
The bulk of comments on section 5c requested additional clarity for the
section. Some small number (n) requested extensions to the clause.
Another small group of comments (n) suggested that 5c be struck. A few
comments focused on none of these things. See Appendix 3 for the
comments on the matter.

Affected Parties
----------------
When considering the affects of section 5c, it is important to consider
the various parties who are affected by the clause, including: the
original creator of the software, the copyright holder, any contributors
(including maintainers), those who modify the work, those who
redistribute modified versions of the software, those who sponsored some
or all of the work, those who study the work, those who run the work,
those who use the services (if any) provided by the work, and so on.

Additionally, it is also important to consider how many people make up
each group.  In the case of popular software, it is very likely that
those who "consume" the software, either by running it, using services
provided by the software or by studying the source code, are likely to
outnumber contributors by a factor of tens of thousands to one.

Of this larger set of groups, it also seems likely that the vast
majority of these people will not have the resources required to
investigate the license of the software that they use.

It is also important to consider the needs of users who access software
via screen readers, braille devices, etc.

Committee D Recommendations
+++++++++++++++++++++++++++

Progressive Recommendation
==========================
The current state of how the ideas behind 5c are implemented puts
additional burden on GPL software consumers, increases the complexity of
the license, and confuses software creators.

These issues can be ameliorated by:

* Making section 5c-type manditory for authors and modifiers. This will
   remove any confusion as to what the requirements are for creators, be
   they authors, contributors or modifiers. It will also ensure that
   software consumers will always be able to easily see what rights they
   have to GPL'd software.

* Clarifying the requirements of section 5c notices.

* Replacing the suggested notices portion of the "How to Apply These  
Terms
   to Your New Programs" with a notice referring to the new  
requirements.

* Modifying section 5c to refer to whatever the new section on these  
kinds
   of notices is called.

Suggested New Section
---------------------
... TDB - assuming that we don't all think this is insane.


Conservative Recommendation
===========================
Work to clarify section 5c.

* Section "How to Apply These Terms to Your New Programs" should be
   updated in regards to notices of copyright, warranty and license.

Suggested Rewording
-------------------
Modified versions of the work must display appropriate and prominent
notices of copyright, warranty and license. The license notice must
state that the modified work may be distributed under these conditions
and tell the user how to view a copy of this License together with the
central list (if any) of other terms in accord with section 7.

If the modified work has interactive user interfaces, each interface
must display these notices. If the interface presents a list of user
commands or options, such as a menu, a command to display this
information must be prominent in the list.  Otherwise, the modified work
must display this information at startup--except in the case that the
Program has such interactive modes and does not display this information
at startup. An option that allows a user choose to suppress the display
of these notices is permitted, if the option is disabled by default.

General Recommendations
=======================
Support section 5c with various utilities and forms that are designed to
help reduce the administrative load of maintaining section 5c-like
notices.

Other Effects
=============
In addition to the stated intent, there are additional effects of the
license, both (likely) intended and unintended.

Intended Consequences
'''''''''''''''''''''
* Less work for consumers of the software: by helping ensure that
   consumers clearly know their rights to the software, section 5c helps
   ensure that users ....

Unintended Consequences
'''''''''''''''''''''''
* Various software organizations who engage in proprietary relicensing
   have - in conjunction with other tactics - broadly interpreted  
section
   5c, so as to encourage users to purchase proprietary software.

Side Effects
''''''''''''
* A consequence of the section 5c is that is front-loads some work for
   the software producer; that is, some work that is likely to be
   required by the software developer at some point in the stage of the
   distribution software is required to be done before distribution, in
   order for the software to be GPL v3 compliant.

   This is a small price to pay for the much greater certainty that a
   properly implemented 5c notice provides to all consumers of the
   software, be they modifiers, redistributors, service users or end
   consumers.

   Note: The case for service consumers having an opportunity to see
   section 5c notices seems fuzzy to me. --zak


Appendix 1: Section 5c Text
+++++++++++++++++++++++++++
c) If the modified work has interactive user interfaces, each must
include a convenient feature that displays an appropriate
copyright notice, and tells the user that there is no warranty for
the program (or that you provide a warranty), that users may
redistribute the modified work under these conditions, and how to
view a copy of this License together with the central list (if any) of
other terms in accord with section 7. If the interface presents a
list of user commands or options, such as a menu, a command to
display this information must be prominent in the list.
Otherwise, the modified work must display this information at
startup--except in the case that the Program has such
interactive modes and does not display this information at
startup.

Appendix 2: Section 7 Text relevant to Section 5c
+++++++++++++++++++++++++++++++++++++++++++++++++
....
Unless the work also permits distribution under a previous version of
this License, all the other terms included in the work under this
section must be listed, together, in a central list in the work.
...

Appendix 3: Comments
+++++++++++++++++++++
See http://gplv3.fsf.org/rt/NoAuth/readsay.html?id=1061

From zak at greant.com  Tue May  9 19:18:03 2006
From: zak at greant.com (Zak Greant)
Date: Tue, 9 May 2006 16:18:03 -0700
Subject: [Committee-d] Test
Message-ID: <5DBC18B2-B0B2-4867-84BE-6CA582897C4A@greant.com>



From zak at greant.com  Tue May  9 19:19:22 2006
From: zak at greant.com (Zak Greant)
Date: Tue, 9 May 2006 16:19:22 -0700
Subject: [Committee-d] Draft recommendation for section 5c
Message-ID: <2F053889-3BF6-40D9-ADCB-1609C330B497@greant.com>

Please beat this like a giant pi?ata - it still needs a good deal of  
redacting.

GPLv3 Section 5c
================
Protecting creators and ensuring that consumers know their rights.

Overview
++++++++
Section 5c's primary purpose is to protect and enable consumers of
GPL-licensed software. It does so by requiring notices of a specific
type on modified versions of GPL v3-licensed software. These notices
help ensure that recipients of the software know what rights they are
granted, as well as what terms and conditions apply to the software.

Additionally, section 5c notices provide important protection for
creators by helping to ensure that users know that the software is
without warranty and by disclosing the complete origin of modified
versions of the software.

These intents for section 5c is partially described in several parts of
the preamble:

"... you must show them these terms so they know their rights."
     --GPLv3 Discussion Draft 1, Preamble, Para. 4

"For the developers' and author's protection, the GPL clearly explains
that there is no warranty for this free software. If the software is
modified by someone else and passed on, the GPL ensures that recipients
are told that what they have is not the original, so that any problems
introduced by others will not reflect on the original authors'
reputations."
     --GPLv3 Discussion Draft 1, Preamble, Para. 6

Community Input
+++++++++++++++
The bulk of comments on section 5c requested additional clarity for the
section. Some small number (n) requested extensions to the clause.
Another small group of comments (n) suggested that 5c be struck. A few
comments focused on none of these things. See Appendix 3 for the
comments on the matter.

Affected Parties
----------------
When considering the affects of section 5c, it is important to consider
the various parties who are affected by the clause, including: the
original creator of the software, the copyright holder, any contributors
(including maintainers), those who modify the work, those who
redistribute modified versions of the software, those who sponsored some
or all of the work, those who study the work, those who run the work,
those who use the services (if any) provided by the work, and so on.

Additionally, it is also important to consider how many people make up
each group.  In the case of popular software, it is very likely that
those who "consume" the software, either by running it, using services
provided by the software or by studying the source code, are likely to
outnumber contributors by a factor of tens of thousands to one.

Of this larger set of groups, it also seems likely that the vast
majority of these people will not have the resources required to
investigate the license of the software that they use.

It is also important to consider the needs of users who access software
via screen readers, braille devices, etc.

Committee D Recommendations
+++++++++++++++++++++++++++

Progressive Recommendation
==========================
The current state of how the ideas behind 5c are implemented puts
additional burden on GPL software consumers, increases the complexity of
the license, and confuses software creators.

These issues can be ameliorated by:

* Making section 5c-type manditory for authors and modifiers. This will
   remove any confusion as to what the requirements are for creators, be
   they authors, contributors or modifiers. It will also ensure that
   software consumers will always be able to easily see what rights they
   have to GPL'd software.

* Clarifying the requirements of section 5c notices.

* Replacing the suggested notices portion of the "How to Apply These  
Terms
   to Your New Programs" with a notice referring to the new  
requirements.

* Modifying section 5c to refer to whatever the new section on these  
kinds
   of notices is called.

Suggested New Section
---------------------
... TDB - assuming that we don't all think this is insane.


Conservative Recommendation
===========================
Work to clarify section 5c.

* Section "How to Apply These Terms to Your New Programs" should be
   updated in regards to notices of copyright, warranty and license.

Suggested Rewording
-------------------
Modified versions of the work must display appropriate and prominent
notices of copyright, warranty and license. The license notice must
state that the modified work may be distributed under these conditions
and tell the user how to view a copy of this License together with the
central list (if any) of other terms in accord with section 7.

If the modified work has interactive user interfaces, each interface
must display these notices. If the interface presents a list of user
commands or options, such as a menu, a command to display this
information must be prominent in the list.  Otherwise, the modified work
must display this information at startup--except in the case that the
Program has such interactive modes and does not display this information
at startup. An option that allows a user choose to suppress the display
of these notices is permitted, if the option is disabled by default.

General Recommendations
=======================
Support section 5c with various utilities and forms that are designed to
help reduce the administrative load of maintaining section 5c-like
notices.

Other Effects
=============
In addition to the stated intent, there are additional effects of the
license, both (likely) intended and unintended.

Intended Consequences
'''''''''''''''''''''
* Less work for consumers of the software: by helping ensure that
   consumers clearly know their rights to the software, section 5c helps
   ensure that users ....

Unintended Consequences
'''''''''''''''''''''''
* Various software organizations who engage in proprietary relicensing
   have - in conjunction with other tactics - broadly interpreted  
section
   5c, so as to encourage users to purchase proprietary software.

Side Effects
''''''''''''
* A consequence of the section 5c is that is front-loads some work for
   the software producer; that is, some work that is likely to be
   required by the software developer at some point in the stage of the
   distribution software is required to be done before distribution, in
   order for the software to be GPL v3 compliant.

   This is a small price to pay for the much greater certainty that a
   properly implemented 5c notice provides to all consumers of the
   software, be they modifiers, redistributors, service users or end
   consumers.

   Note: The case for service consumers having an opportunity to see
   section 5c notices seems fuzzy to me. --zak


Appendix 1: Section 5c Text
+++++++++++++++++++++++++++
c) If the modified work has interactive user interfaces, each must
include a convenient feature that displays an appropriate
copyright notice, and tells the user that there is no warranty for
the program (or that you provide a warranty), that users may
redistribute the modified work under these conditions, and how to
view a copy of this License together with the central list (if any) of
other terms in accord with section 7. If the interface presents a
list of user commands or options, such as a menu, a command to
display this information must be prominent in the list.
Otherwise, the modified work must display this information at
startup--except in the case that the Program has such
interactive modes and does not display this information at
startup.

Appendix 2: Section 7 Text relevant to Section 5c
+++++++++++++++++++++++++++++++++++++++++++++++++
....
Unless the work also permits distribution under a previous version of
this License, all the other terms included in the work under this
section must be listed, together, in a central list in the work.
...

Appendix 3: Comments
+++++++++++++++++++++
See http://gplv3.fsf.org/rt/NoAuth/readsay.html?id=1061

From mako at debian.org  Mon May 15 01:12:51 2006
From: mako at debian.org (Benj. Mako Hill)
Date: Mon, 15 May 2006 01:12:51 -0400
Subject: [Committee-d] Affero Clause Report
Message-ID: <20060515051251.GH5857@yukidoke.org>

Just under the wire! I hope. This should be sent to the FSF folks
later today but I would appreciate if folks could give this a read,
send any patches to the TeX, comments, or suggestions.

I'll be on IRC all day-ish tomorrow and would like to talk about this
with anyone who can take a look at it. 1600UTC is a decent time if
folks will be around.

I've made one recommendation that's I'm rather confident in and one
less fully-baked suggestion based on the critiques and concerns of
Don, Josh Triplett, and others.

I've also got some suggestions for the AGPL not in this report but
that doesn't need to be handled by this committee.

The source is based off Don's template and can be thrown into a subdir
in his issues file with a symlink to his makefile and it should work.

You can get the files here:

  http://mako.cc/outgoing/affero_exception.pdf
  http://mako.cc/outgoing/affero_exception.tex

Regards,
Mako


-- 
Benjamin Mako Hill
mako at debian.org
http://mako.cc/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://gplv3.fsf.org/pipermail/committee-d/attachments/20060515/ab76bb69/attachment.pgp

From don at donarmstrong.com  Mon May 15 01:33:17 2006
From: don at donarmstrong.com (Don Armstrong)
Date: Sun, 14 May 2006 22:33:17 -0700
Subject: [Committee-d] DRM And Authentication Issue Draft Text
Message-ID: <20060515053317.GZ16182@volo.donarmstrong.com>


I'd like to get this issue recommendation turned in before the
deadline if at all possible.

Can any final changes to the text that need to be made be suggested
before tomorrow? [The DLA comment bits will be removed as will the
comments at the end of the document.]

PDF here: http://archimedes.ucr.edu/ss/drm_allowing_authentication.pdf
Full source:
http://svn.donarmstrong.com/don/trunk/projects/gplv3/issues/drm_allowing_authentication/


Don Armstrong

-- 
The game of science is, in principle, without end. He who decides one
day that scientific statements do not call for any further test, and
that they can be regarded as finally verified, retires from the game.
 -- Sir Karl Popper _The Logic of Scientific Discovery_ ?11

http://www.donarmstrong.com              http://rzlab.ucr.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://gplv3.fsf.org/pipermail/committee-d/attachments/20060515/17724485/attachment.pgp

From schoen at loyalty.org  Mon May 15 03:01:16 2006
From: schoen at loyalty.org (Seth David Schoen)
Date: Mon, 15 May 2006 00:01:16 -0700
Subject: [Committee-d] DRM And Authentication Issue Draft Text
In-Reply-To: <20060515053317.GZ16182@volo.donarmstrong.com>
References: <20060515053317.GZ16182@volo.donarmstrong.com>
Message-ID: <20060515070111.GQ17481@frotz.zork.net>

Don Armstrong writes:

> I'd like to get this issue recommendation turned in before the
> deadline if at all possible.
> 
> Can any final changes to the text that need to be made be suggested
> before tomorrow? [The DLA comment bits will be removed as will the
> comments at the end of the document.]
> 
> PDF here: http://archimedes.ucr.edu/ss/drm_allowing_authentication.pdf
> Full source:
> http://svn.donarmstrong.com/don/trunk/projects/gplv3/issues/drm_allowing_authentication/

I still have a concern about this, but I have not proposed any new
text because I haven't been able to solve the problem to my own
satisfaction.

I refer everyone to this thread

http://lwn.net/Articles/178950/

as well as to my earlier message about a developer whose software
is used by another party in the course of a scheme that restricts
users of a device.

I'm not sure that these problems can be solved at all, although I'm
still thinking about whether I can propose a way to solve them.

There are basically two scenarios that I think are a challenge for
GPLv3's anti-DRM strategy.

One is the use of _hardware_ to restrict users, either by someone
who also publishes software or by a third party.  We can further
divide this into a couple of cases:

* The hardware might rely on its ability to verify the identity of
the software using a database that is never under the control of
the end-user.  (For example, I have been pointing out that a TCG
TPM can be used by a remote party to determine whether a user has
modified software, even if the user has the "complete corresponding
source code" in the strictest possible sense.  The remote party can
then make decisions that affect the user's ability to interact or
to receive certain data contingent upon whether the user has
actually modified the software or not.  The user might be punished
fairly severely for modifying the software; in practice, it might
not work at all for the purpose for which the user wants to use it.
The party receiving the attestation could have any number of
relationships to 

* The hardware might verify a signature or other information created
by the distributor of the software.  For example, a distributor
could sign binaries and distribute them along with the source code
used to produce them (without the signing key).  The signature could
be taken to imply that the software has certain behavior or enforces
certain policies (which might be DRM, or might be usable by someone
else to enforce DRM, or whatever).  In some cases, the "intended"
functionality of some software that is not DRM at all (like a
kernel or microkernel) could be a crucial part of the functionality
of a DRM scheme built on top of it.  This is certainly true for
Microsoft's original Palladium design, but it could be true for
any number of other designs.  If a kernel ensures interprocess
isolation, for example, a DRM developer might want to rely on that
isolation to stop users from attaching a debugger.  (This implies
a nearly classic problem about "dual-use" technologies; there are
some security technologies that can be used in the user's interest
or against the user's interest.  This could be as simple as a rule
that "the kernel can't be modified after boot" or "a process can't
read the address space of another process".)

Both of these scenarios can be used to create the supposedly
impossible "open source DRM": the user knows everything about how
the software works and has the right and ability to modify it.
But the hardware allows modifications to be detected and punished,
and prevents the user from altering the software undetectably
while it's running.

We can also add

* Non-free software written by a third party (not under the GPL)
can make use of signatures on GPL-covered binaries to use them
as part of DRM enforcement.  Basically the same consideration
as above apply.  To take a simple example, if we assume that a
GPLv3-covered driver could otherwise function as a Windows kernel
driver (I don't really want to have a debate about whether this
is inherently a GPL violation; I'm trying to construct an example
about another point), Microsoft can use the Windows driver signing
mechanism to ensure that the drivers thus loaded can't be used for
purposes that Microsoft thinks is inappropriate.

David Turner has given a defense of the "recommended or principal
context of use" and "normally implies that the user already has
it" approach.  I understand that these clauses are meant to discourage
distributors of GPLv3-covered software from having a close relationship
with someone doing something DRM-like with that software.  I have
several concerns about whether this will work.

First, I think it's clear that there are important situations in which
nobody who is distributing GPLv3-covered software will have a close
relationship with someone who is enforcing a DRM-ish policy -- yet the
policy will still get enforced and the entity enforcing it will still
get a benefit and be able to deter people from modifying the software.

Second, I'm not sure that copyright law is strong enough to make
the kinds of restrictions David described effective in general.
David Lang argues that the GPLv3 clauses can be circumvented; David
Turner suggests that doing this would be an infringement of copyright.
I worry that this represents an expansion in the scope of copyright,
and not one that we should support; I am also not at all sure that
it would work.

Third, I'm not sure that the notions of recommended context of use
or a normal implication that a user has some information are clear
enough concepts to provide useful guidance to software developers,
or to be enforced in court.  I worry that a court would be puzzled
about the definition and scope of these concepts.

Fourth, I'm not sure about the general situation in which someone
sets up a computer system to restrict someone else and exactly which
kinds of power relationships the GPLv3 does or should try to prohibit
GPL-covered software from being used in furtherance of.

It's definitely true that the intuitive concept of complete
corresponding source code as everything that was used to produce a
particular binary (in the preferred form for making modifications to
it) is simple, appealing, and difficult to attain in practice.
Signing keys are the most salient example of a problem here.  If
they have to be distributed, then people are very upset and digital
signatures on software distributions don't really mean anything
anymore.  (You can't tell whether the copy you got was from Linus,
in the presence of an attacker who wants to mislead you...)

If they _don't_ have to be distributed, then there is a property of
certain binaries that a user can't reproduce in the user's own
binaries -- the evidence of authenticity of the binaries.  If that
evidence is used by some system to restrict the user's freedom,
the user does not necessarily have a technological means to beat
the system.  If the system says "I only run Linus's kernel" (or
"I only run Mark Steffik's microkernel" or "I only run AOL Time
Warner's instance of Sun's DReaM client") then the user who makes
changes to the code can't get the system to run the resulting
thing, and can't, as Eben put it, get it to "play all the same
movies" or perform whatever other task is being restricted.  (On
a locked-down PDA, the task might not even be DRM-related at all.
It might be just "the ability to turn the machine on"!)

The current draft's strategy seems to be to provide legal recourse
against the developer of the system.  But like David Lang, I'm
concerned that this recourse may not be practical.  The developer
of the system, as I've said, may not have distributed the program
that was covered by GPLv3.  The developer may not be in a relationship
of mutual control with anyone who did, or not even in any kind of
contractual privity.  They might exchange money -- or not.  The
restrictions may end up being a result of a dual-use technology,
where portions of GPLv3-covered software were developed for a reason
that can enhance user freedom and are then applied to restrict
user freedom.  Actually suing people to stop them from doing this
could be hampered by vagueness in the current text and also by the
claim that copyright law does not (and, in general, should not) give
a copyright holder the ability to stop anyone from doing this.

Someone (perhaps on LWN or perhaps here) also mentioned the idea
that the GPLv3 could still function as a deterrent, even if it's
possible to circumvent the spirit of the anti-DRM clause.  For
example, perhaps TiVo-like companies could not themselves "distribute"
the code if they were also directly responsible for using it to
restrict users.  Since they would want to be able to distribute it,
they would encounter a disincentive.  I think there is a deterrent
effect here (assuming that the anti-DRM clause is enforceable at
all), but I'm not sure that it's very large.  Increasingly, both
computers and consumer electronics devices regularly download
their operating systems over the Internet.  The Ubuntu laptop that's
running my ssh client and the Debian server where I'm typing this
message have both probably gotten a plurality of their software
from public deb-package archives.  We've started to see embedded
systems downloading firmware upgrades over the Internet.  I think
this trend is expanding dramatically.  Internet distribution of
software may become routine.  If digital signatures are used in
certain ways, it could be entirely practical to allow embedded
systems, for example, to download updates from third parties.

Finally, David Turner suggested that free software developers don't
have a reason to actively help restrict their users, and might
choose to do the opposite.  For example, if Alice writes a program
and a company allows any version signed by Alice to run on a particular
PDA, but forbids other third-party software to run, Alice might
choose to add a feature that gives the user an interactive shell or
allows the user to download other applications and run them in her
application's address space.

I'm not sure that these incentives are stable enough to count on.
One problem is the dual-use problem -- if people are writing
"security" software, they might cause the software to enforce some
policy without investigating the question of whether that enforcement
will ever harm user freedom.  (This is my experience in talking to
some people who are DRM skeptics but working on trusted computing.
They feel that their software, which can be used for DRM and non-DRM
applications, would be less good if it contained features that
always let users violate policy.  Why this is so is a complicated
argument, but they have some reasons that seem valid to them and do
not imply that they actively want their software to be used for
DRM.)  You can certainly imagine that people who are interested in
provably correct security and formal proofs of program behavior will
not want to rely on user decisions which might result in the program
carrying out arbitrary operations.  There are people who want to
write provably-correct microkernels and interprets and they feel
that there are no properties of their software that could be proven
if the user could issue arbitrary commands resulting in arbitrary
behavior.

Another problem is that some free software developers might be
sympathetic to the use of their code in DRM applications.  This
might seem bizarre to us, but there is nonetheless the example of
the DReaM project, as well as the long term possibility that
free software based DRM will be (1) more appealing from a public
relations point of view (it benefits from the cachet and good
will of free software); (2) more procompetitive in some ways than
DRM based on proprietary software (because there is more room for
a wider variety of parties to make changes, enhancements,
suggestions, and new versions as long as they demonstrate that
they have not thereby allowed users to escape from DRM policy
enforcement); and (3) much more acceptable from a transparency
and privacy point of view, because it's easy to verify what the
DRM software actually does and to confirm that it doesn't contain
hidden spyware functionality, as a number of proprietary software
DRM systems have turned out to do.  (Users can also have more
assurance that the restrictions that will be enforced against them
are _only_ those restrictions that the publisher has revealed,
and that there is no hidden ability to make access expire or to
revoke it arbitrarily, or for the system to malfunction in a way
that nobody but the publisher could have anticipated.)

Another problem is that someone who would ordinarily want to help
users break a policy might get paid not to -- and then whoever was
the source of the funds would argue that this didn't violate
the "recommended or principal context of use" clause, or that that
clause couldn't be enforced.

-- 
Seth David Schoen <schoen at loyalty.org> | This is a new focus for the security
     http://www.loyalty.org/~schoen/   | community. The actual user of the PC
     http://vitanuova.loyalty.org/     | [...] is the enemy.
                                       |          -- David Aucsmith, IDF 1999

From mako at debian.org  Mon May 15 22:51:17 2006
From: mako at debian.org (Benj. Mako Hill)
Date: Mon, 15 May 2006 22:51:17 -0400
Subject: [Committee-d] Affero Clause Report
In-Reply-To: <20060515051251.GH5857@yukidoke.org>
References: <20060515051251.GH5857@yukidoke.org>
Message-ID: <20060516025117.GV5857@yukidoke.org>

<quote who="Benj. Mako Hill" date="Mon, May 15, 2006 at 01:12:51AM -0400">
> Just under the wire! I hope. This should be sent to the FSF folks
> later today but I would appreciate if folks could give this a read,
> send any patches to the TeX, comments, or suggestions.

It's not clear where I'm supposed to send this report.

Do these need to be in today? If so, to whom? Is that someone already
on the list? If not, it would be nice to get some feedback from others
on the committee. I haven't heard back from anyone except Don. If
we're on for a meeting tomorrow, I suppose we can go over this then.

I recieved on set of small typographical fixes and updated the version
at the URLs in my previous mail. You can simply go download the latest
version of the PDF and the LaTeX source from that location.

Regards,
Mako

-- 
Benjamin Mako Hill
mako at debian.org
http://mako.cc/

From novalis at fsf.org  Mon May 15 18:52:48 2006
From: novalis at fsf.org (David Turner)
Date: Mon, 15 May 2006 18:52:48 -0400
Subject: [Committee-d] Affero Clause Report
In-Reply-To: <20060516025117.GV5857@yukidoke.org>
References: <20060515051251.GH5857@yukidoke.org>
	<20060516025117.GV5857@yukidoke.org>
Message-ID: <1147733568.3349.212.camel@shepard>

On Mon, 2006-05-15 at 22:51 -0400, Benj. Mako Hill wrote:
> <quote who="Benj. Mako Hill" date="Mon, May 15, 2006 at 01:12:51AM -0400">
> > Just under the wire! I hope. This should be sent to the FSF folks
> > later today but I would appreciate if folks could give this a read,
> > send any patches to the TeX, comments, or suggestions.
> 
> It's not clear where I'm supposed to send this report.

Stick it in the comment system somewhere, marked as Committee D.

> Do these need to be in today? If so, to whom? Is that someone already
> on the list? If not, it would be nice to get some feedback from others
> on the committee. I haven't heard back from anyone except Don.

I think this looks fine.


From novalis at fsf.org  Mon May 15 19:21:16 2006
From: novalis at fsf.org (David Turner)
Date: Mon, 15 May 2006 19:21:16 -0400
Subject: [Committee-d] DRM And Authentication Issue Draft Text
In-Reply-To: <20060515070111.GQ17481@frotz.zork.net>
References: <20060515053317.GZ16182@volo.donarmstrong.com>
	<20060515070111.GQ17481@frotz.zork.net>
Message-ID: <1147735276.3349.237.camel@shepard>

On Mon, 2006-05-15 at 00:01 -0700, Seth David Schoen wrote:
> I refer everyone to this thread
> 
> http://lwn.net/Articles/178950/
> 
> as well as to my earlier message about a developer whose software
> is used by another party in the course of a scheme that restricts
> users of a device.

I create a device which, on start-up, downloads some software from
somewhere.  How have I not distributed that software?  This isn't even
Grokster, where the users have to specifically request what to download
-- here, I know exactly what users are going to end up with.  

> First, I think it's clear that there are important situations in which
> nobody who is distributing GPLv3-covered software will have a close
> relationship with someone who is enforcing a DRM-ish policy -- yet the
> policy will still get enforced and the entity enforcing it will still
> get a benefit and be able to deter people from modifying the software.

I don't see any where there's not secondary infringement on the part of
the drm-ist.

> Third, I'm not sure that the notions of recommended context of use
> or a normal implication that a user has some information are clear
> enough concepts to provide useful guidance to software developers,
> or to be enforced in court.  I worry that a court would be puzzled
> about the definition and scope of these concepts.

Can you think of a way to rephrase this?

> Fourth, I'm not sure about the general situation in which someone
> sets up a computer system to restrict someone else and exactly which
> kinds of power relationships the GPLv3 does or should try to prohibit
> GPL-covered software from being used in furtherance of.

Manifesto: Users of a piece of software must have the ability to modify
that software and run it on any device they own, limited only by
processing power, memory, i/o, etc.

To some extent, this is outside GPLv3's control -- there are some
devices whose manufacturers don't distribute or promote GPL software for
use on them.  

But when a manufacturer runs GPL software on a device, you should be
able to run any GPL software you like on that device.

> If [signing keys] _don't_ have to be distributed, then there is a 
> property of certain binaries that a user can't reproduce in the 
> user's own binaries -- the evidence of authenticity of the binaries.  
> If that evidence is used by some system to restrict the user's 
> freedom, the user does not necessarily have a technological means to 
> beat the system.

Any time a GPL program is distributed, everyone doing the distribution
needs a license to do it.  It's possible that more than one person could
be responsible for any given act of distribution -- that's why both the
person running the auction house and the person selling the tapes could
be liable in Cherry Auction.  So, when there's distribution of GPL
software, the GPL can place requirements.

Any device manufacturer who wants to use a GPL operating system needs to
be distributing that operating system -- either directly on the device,
or via a stript which runs on device initialization.  So, we can prevent
device manufacturers from restricting users.

Some parties don't distribute any GPL software in any way, but wish to
restrict users.  They need to know that users have a computer which will
do what they expect (that is, a "Trusted" computer).  The operating
system on this device could have only secure boot, curtained memory, and
remote attestation -- that's sufficient for a platform on which to run a
TPM-based DRM system but for the analog hole.  Each of these is
independently useful.  Still, this separates the interests of the DRM
people from the device people.  The device people can't add DRM features
because they're distributing the (GPL) operating system.  And there's a
collective action problem which makes each device manufacturer less
likely to be the first ones to put a TPM in their device -- it will cost
money, but will provide no benefit until a critical mass of people have
one.  

Also, the DRM people have to trust the operating system manufacturer.
Why can't they make a deal with them?  After all, the features they need
are not themselves DRM.  Well, "recommended or principle context of use"
probably doesn't stop this.  But there's got to be some language we can
write that prevents collusion.  If someone perverts a signature, fine --
we can't stop that.  But so long as any party can unilaterally defect at
no cost, I think the license can help fight DRM.  


From mako at debian.org  Tue May 16 00:06:16 2006
From: mako at debian.org (Benj. Mako Hill)
Date: Tue, 16 May 2006 00:06:16 -0400
Subject: [Committee-d] Affero Clause Report
In-Reply-To: <1147733568.3349.212.camel@shepard>
References: <20060515051251.GH5857@yukidoke.org>
	<20060516025117.GV5857@yukidoke.org>
	<1147733568.3349.212.camel@shepard>
Message-ID: <20060516040616.GF4780@yukidoke.org>

<quote who="David Turner" date="Mon, May 15, 2006 at 06:52:48PM -0400">
> On Mon, 2006-05-15 at 22:51 -0400, Benj. Mako Hill wrote:
> > <quote who="Benj. Mako Hill" date="Mon, May 15, 2006 at 01:12:51AM -0400">
> > > Just under the wire! I hope. This should be sent to the FSF folks
> > > later today but I would appreciate if folks could give this a read,
> > > send any patches to the TeX, comments, or suggestions.
> > 
> > It's not clear where I'm supposed to send this report.
> 
> Stick it in the comment system somewhere, marked as Committee D.

How do I put a PDF into the comments system? Can you just do it?

Regards,
Mako


-- 
Benjamin Mako Hill
mako at debian.org
http://mako.cc/

From novalis at fsf.org  Tue May 16 13:28:29 2006
From: novalis at fsf.org (David Turner)
Date: Tue, 16 May 2006 13:28:29 -0400
Subject: [Committee-d] Meeting today
Message-ID: <1147800510.3349.323.camel@shepard>

There is a meeting today at 2200 GMT, in about 30 minutes.  All of the
issues for round one should be already in (but if they're not, we'll
make sure they get listed).  If nobody has any issues to prepare for
round two, then we'll end pretty quickly.


From novalis at fsf.org  Tue May 16 13:57:07 2006
From: novalis at fsf.org (David Turner)
Date: Tue, 16 May 2006 13:57:07 -0400
Subject: [Committee-d] Affero Clause Report
In-Reply-To: <20060516040616.GF4780@yukidoke.org>
References: <20060515051251.GH5857@yukidoke.org>
	<20060516025117.GV5857@yukidoke.org>
	<1147733568.3349.212.camel@shepard>
	<20060516040616.GF4780@yukidoke.org>
Message-ID: <1147802227.3349.330.camel@shepard>

On Tue, 2006-05-16 at 00:06 -0400, Benj. Mako Hill wrote:
> <quote who="David Turner" date="Mon, May 15, 2006 at 06:52:48PM -0400">
> > On Mon, 2006-05-15 at 22:51 -0400, Benj. Mako Hill wrote:
> > > <quote who="Benj. Mako Hill" date="Mon, May 15, 2006 at 01:12:51AM -0400">
> > > > Just under the wire! I hope. This should be sent to the FSF folks
> > > > later today but I would appreciate if folks could give this a read,
> > > > send any patches to the TeX, comments, or suggestions.
> > > 
> > > It's not clear where I'm supposed to send this report.
> > 
> > Stick it in the comment system somewhere, marked as Committee D.
> 
> How do I put a PDF into the comments system? Can you just do it?

I have no idea.  I don't think it's easy, because the idea is for the
whole thing to be searchable.  Does it need to be a PDF?  Can you paste
in the text?




From novalis at fsf.org  Tue May 23 11:24:16 2006
From: novalis at fsf.org (David Turner)
Date: Tue, 23 May 2006 11:24:16 -0400
Subject: [Committee-d] Send agenda items for meeting today, 2200 UTC
Message-ID: <1148397856.2718.85.camel@shepard>

Please send some agenda items.

-- 
-David Turner
V3 Coordinator
Free Software Foundation


From novalis at fsf.org  Tue May 23 14:15:48 2006
From: novalis at fsf.org (David Turner)
Date: Tue, 23 May 2006 14:15:48 -0400
Subject: [Committee-d] Next week
Message-ID: <1148408148.2718.144.camel@shepard>

There were no new issues this week.  I understand that we're all sort of
holding our breaths for the next draft of the license, so maybe there
won't be any issues for next week.  If there are, please do make a note
on the list so we can all be prepared.

-- 
-David Turner
GPl Compliance Engineer
Free Software Foundation


From zak at greant.com  Tue May 23 18:57:38 2006
From: zak at greant.com (Zak Greant)
Date: Tue, 23 May 2006 15:57:38 -0700
Subject: [Committee-d] Send agenda items for meeting today, 2200 UTC
In-Reply-To: <1148397856.2718.85.camel@shepard>
References: <1148397856.2718.85.camel@shepard>
Message-ID: <3B62BD37-54A3-484C-B18B-FD0A83A6EC03@greant.com>


On May 23, 2006, at 08:24PDT (CA), David Turner wrote:

> Please send some agenda items.

* Discussing the next steps in the process
* Early feedback on the issues

Cheers!
--zak



From mhatta at grad.e.u-tokyo.ac.jp  Sat May 27 07:29:02 2006
From: mhatta at grad.e.u-tokyo.ac.jp (Masayuki Hatta)
Date: Sat, 27 May 2006 20:29:02 +0900
Subject: [Committee-d] On attending the 3rd GPLv3 Conference
Message-ID: <20060527112917.13CB432273B@marx.e.u-tokyo.ac.jp>

[Note: I am not sure who should be contacted.  I greatly appreciate if
you forward this mail to an appropriate person.  Thanks.]

Hi,

I found that somehow I will not be so busy between June 20 to 26, so
now I am planning to visit Barcelona and attend the 3rd GPLv3
Conference.

In case opportunity permits, I would like to make a presentation on
and discuss several points w.r.t. i18n of GPLv3 from a Japanese
perspective (input from discussion with the Emblix people).

Therefore, I would like to ask some questions:

1) Is there anyone in this committee who are going to Barcelona, too?

2) Do you think that FSF could possibly fund for my travel expenses?

Best regards,
MH

--
Masayuki Hatta
Graduate School of Economics, The University of Tokyo

From jbsoufron at gmail.com  Sat May 27 18:18:07 2006
From: jbsoufron at gmail.com (Jean-Baptiste Soufron)
Date: Sun, 28 May 2006 00:18:07 +0200
Subject: [Committee-d] On attending the 3rd GPLv3 Conference
In-Reply-To: <20060527112917.13CB432273B@marx.e.u-tokyo.ac.jp>
References: <20060527112917.13CB432273B@marx.e.u-tokyo.ac.jp>
Message-ID: <59D5E89D-68E9-45D7-A947-3A0B64218ED0@gmail.com>

Actually, I think I will be there. And I speak a little bit of  
japanese :-)

Jean-Baptiste Soufron
cersa-cnrs paris 2
http://soufron.typhon.net
+33 (0) 617 962 457


Le 27 mai 06 ? 13:29, Masayuki Hatta a ?crit :

> [Note: I am not sure who should be contacted.  I greatly appreciate if
> you forward this mail to an appropriate person.  Thanks.]
>
> Hi,
>
> I found that somehow I will not be so busy between June 20 to 26, so
> now I am planning to visit Barcelona and attend the 3rd GPLv3
> Conference.
>
> In case opportunity permits, I would like to make a presentation on
> and discuss several points w.r.t. i18n of GPLv3 from a Japanese
> perspective (input from discussion with the Emblix people).
>
> Therefore, I would like to ask some questions:
>
> 1) Is there anyone in this committee who are going to Barcelona, too?
>
> 2) Do you think that FSF could possibly fund for my travel expenses?
>
> Best regards,
> MH
>
> --
> Masayuki Hatta
> Graduate School of Economics, The University of Tokyo
> _______________________________________________
> Committee-D mailing list
> Committee-D at gplv3.fsf.org
> http://gplv3.fsf.org/mailman/listinfo/committee-d


From novalis at fsf.org  Tue May 30 13:38:34 2006
From: novalis at fsf.org (David Turner)
Date: Tue, 30 May 2006 13:38:34 -0400
Subject: [Committee-d] Meeting at 2200 GMT.
Message-ID: <1149010714.9906.473.camel@shepard>

Come to IRC in about fifteen minutes for a meeting.  It will probably be
a short one, as I haven't seen any noise on the mailing list.

-- 
-David Turner
GPL Compliance Engineer
Free Software Foundation


From mako at atdot.cc  Tue May  9 19:43:43 2006
From: mako at atdot.cc (Benj. Mako Hill)
Date: Tue, 09 May 2006 23:43:43 -0000
Subject: [Committee-d] 2200 GMT: Final meeting for this draft
In-Reply-To: <1147194606.8974.132.camel@shepard>
References: <1147194606.8974.132.camel@shepard>
Message-ID: <20060509233832.GC4176@yukidoke.org>

<quote who="David Turner" date="Tue, May 09, 2006 at 01:10:06PM -0400">
> There is a Committee D meeting at 220 GMT.  This meeting is our last
> chance to discuss issues for this draft.  Anything we submit after May
> 15 will have to apply to the next draft.

Sorry I didn't make it to the meeting. I will send something to the
email list in the next day or two. Hopefully we can discuss it here.

Regards,
Mako

-- 
Benjamin Mako Hill
mako at atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so
far as society is free to use the results. --RMS

From don at donarmstrong.com  Sat May 13 20:50:52 2006
From: don at donarmstrong.com (Don Armstrong)
Date: Sun, 14 May 2006 00:50:52 -0000
Subject: [Committee-d] DRM And Authentication Issue Draft Text
Message-ID: <20060514005016.GM16182@volo.donarmstrong.com>


I'd like to get this issue recommendation turned in before the
deadline if at all possible.

Can any final changes to the text that need to be made be suggested
before tomorrow? [The DLA comment bits will be removed as will the
comments at the end of the document.]

PDF attached, full source available at
http://svn.donarmstrong.com/don/trunk/projects/gplv3/issues/drm_allowing_authentication/


Don Armstrong

-- 
The game of science is, in principle, without end. He who decides one
day that scientific statements do not call for any further test, and
that they can be regarded as finally verified, retires from the game.
 -- Sir Karl Popper _The Logic of Scientific Discovery_ ?11

http://www.donarmstrong.com              http://rzlab.ucr.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drm_allowing_authentication.pdf
Type: application/pdf
Size: 126813 bytes
Desc: not available
Url : http://gplv3.fsf.org/pipermail/committee-d/attachments/20060513/c67f9291/drm_allowing_authentication-0001.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://gplv3.fsf.org/pipermail/committee-d/attachments/20060513/c67f9291/attachment-0001.pgp

From mako at debian.org  Mon May 15 01:06:11 2006
From: mako at debian.org (Benj. Mako Hill)
Date: Mon, 15 May 2006 05:06:11 -0000
Subject: [Committee-d] Affero Clause Report
Message-ID: <20060515050529.GE5857@yukidoke.org>

Just under the wire! I hope. This should be sent to the FSF folks
later today but I would appreciate if folks could give this a read,
send any patches to the TeX, comments, or suggestions.

I'll be on IRC all day-ish tomorrow and would like to talk about this
with anyone who can take a look at it. 1600UTC is a decent time if
folks will be around.

I've made one recommendation that's I'm rather confident in and one
less fully-baked suggestion based on the critiques and concerns of
Don, Josh Triplett, and others.

I've also got some suggestions for the AGPL not in this report but
that doesn't need to be handled by this committee.

The source is based off Don's template and can be thrown into a subdir
in his issues file with a symlink to his makefile and it should work.

Regards,
Mako


-- 
Benjamin Mako Hill
mako at debian.org
http://mako.cc/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: affero_exception.pdf
Type: application/pdf
Size: 81513 bytes
Desc: not available
Url : http://gplv3.fsf.org/pipermail/committee-d/attachments/20060515/ff1716c2/affero_exception-0001.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: affero_exception.tex
Type: text/x-tex
Size: 19543 bytes
Desc: not available
Url : http://gplv3.fsf.org/pipermail/committee-d/attachments/20060515/ff1716c2/affero_exception-0001.tex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://gplv3.fsf.org/pipermail/committee-d/attachments/20060515/ff1716c2/attachment-0001.pgp

From mako at atdot.cc  Mon May 15 01:09:47 2006
From: mako at atdot.cc (Benj. Mako Hill)
Date: Mon, 15 May 2006 05:09:47 -0000
Subject: [Committee-d] Affero Clause Report
Message-ID: <20060515050929.GF5857@yukidoke.org>

Just under the wire! I hope. This should be sent to the FSF folks
later today but I would appreciate if folks could give this a read,
send any patches to the TeX, comments, or suggestions.

I'll be on IRC all day-ish tomorrow and would like to talk about this
with anyone who can take a look at it. 1600UTC is a decent time if
folks will be around.

I've made one recommendation that's I'm rather confident in and one
less fully-baked suggestion based on the critiques and concerns of
Don, Josh Triplett, and others.

I've also got some suggestions for the AGPL not in this report but
that doesn't need to be handled by this committee.

The source is based off Don's template and can be thrown into a subdir
in his issues file with a symlink to his makefile and it should work.

Regards,
Mako


-- 
Benjamin Mako Hill
mako at atdot.cc
http://mako.cc/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: affero_exception.pdf
Type: application/pdf
Size: 81513 bytes
Desc: not available
Url : http://gplv3.fsf.org/pipermail/committee-d/attachments/20060515/6587266a/affero_exception-0001.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: affero_exception.tex
Type: text/x-tex
Size: 19543 bytes
Desc: not available
Url : http://gplv3.fsf.org/pipermail/committee-d/attachments/20060515/6587266a/affero_exception-0001.tex

From mako at debian.org  Mon May 15 01:12:06 2006
From: mako at debian.org (Benj. Mako Hill)
Date: Mon, 15 May 2006 05:12:06 -0000
Subject: [Committee-d] Affero Clause Report
Message-ID: <20060515051156.GG5857@yukidoke.org>

Just under the wire! I hope. This should be sent to the FSF folks
later today but I would appreciate if folks could give this a read,
send any patches to the TeX, comments, or suggestions.

I'll be on IRC all day-ish tomorrow and would like to talk about this
with anyone who can take a look at it. 1600UTC is a decent time if
folks will be around.

I've made one recommendation that's I'm rather confident in and one
less fully-baked suggestion based on the critiques and concerns of
Don, Josh Triplett, and others.

I've also got some suggestions for the AGPL not in this report but
that doesn't need to be handled by this committee.

The source is based off Don's template and can be thrown into a subdir
in his issues file with a symlink to his makefile and it should work.

You can get the files here:

  http://mako.cc/outgoing/affero_exception.pdf
  http://mako.cc/outgoing/affero_exception.tex

Regards,
Mako


-- 
Benjamin Mako Hill
mako at debian.org
http://mako.cc/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: affero_exception.pdf
Type: application/pdf
Size: 81513 bytes
Desc: not available
Url : http://gplv3.fsf.org/pipermail/committee-d/attachments/20060515/60473c8d/affero_exception-0001.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: affero_exception.tex
Type: text/x-tex
Size: 19543 bytes
Desc: not available
Url : http://gplv3.fsf.org/pipermail/committee-d/attachments/20060515/60473c8d/affero_exception-0001.tex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://gplv3.fsf.org/pipermail/committee-d/attachments/20060515/60473c8d/attachment-0001.pgp

From mako at atdot.cc  Mon May 15 23:47:14 2006
From: mako at atdot.cc (Benj. Mako Hill)
Date: Tue, 16 May 2006 03:47:14 -0000
Subject: [Committee-d] Affero Clause Report
In-Reply-To: <1147733568.3349.212.camel@shepard>
References: <20060515051251.GH5857@yukidoke.org>
	<20060516025117.GV5857@yukidoke.org>
	<1147733568.3349.212.camel@shepard>
Message-ID: <20060516034707.GX5857@yukidoke.org>

<quote who="David Turner" date="Mon, May 15, 2006 at 06:52:48PM -0400">
> On Mon, 2006-05-15 at 22:51 -0400, Benj. Mako Hill wrote:
> > <quote who="Benj. Mako Hill" date="Mon, May 15, 2006 at 01:12:51AM -0400">
> > > Just under the wire! I hope. This should be sent to the FSF folks
> > > later today but I would appreciate if folks could give this a read,
> > > send any patches to the TeX, comments, or suggestions.
> > 
> > It's not clear where I'm supposed to send this report.
> 
> Stick it in the comment system somewhere, marked as Committee D.

How do I put a PDF into the comments system? Can you just do it?

Regards,
Mako


-- 
Benjamin Mako Hill
mako at atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so
far as society is free to use the results. --RMS

From peterb at fsf.org  Tue May 30 12:08:19 2006
From: peterb at fsf.org (Peter Brown)
Date: Tue, 30 May 2006 16:08:19 -0000
Subject: [Committee-d] On attending the 3rd GPLv3 Conference
In-Reply-To: <20060527112917.13CB432273B@marx.e.u-tokyo.ac.jp>
References: <20060527112917.13CB432273B@marx.e.u-tokyo.ac.jp>
Message-ID: <1149005298.6853.62.camel@localhost.localdomain>

On Sat, 2006-05-27 at 20:29 +0900, Masayuki Hatta wrote:
> [Note: I am not sure who should be contacted.  I greatly appreciate if
> you forward this mail to an appropriate person.  Thanks.]
> Therefore, I would like to ask some questions:
> 
> 1) Is there anyone in this committee who are going to Barcelona, too?
> 
> 2) Do you think that FSF could possibly fund for my travel expenses?

The FSF is preparing a list of attendees who will need help to attend
the conference. We would certainly like to have a representative of each
committee attend.
-- 
Peter T. Brown
Executive Director        
Free Software Foundation  | Tel: +1-617-542-5942
51 Franklin St. 5th Floor | Cell: +1-617-319-5832
Boston, MA 02110-1301 USA | Help FSF: www.fsf.org