From brett at fsf.org  Mon Oct  2 10:44:03 2006
From: brett at fsf.org (Brett Smith)
Date: Mon, 2 Oct 2006 10:44:03 -0400
Subject: [Committee-d] Meeting tomorrow?/rallying cry
Message-ID: <20061002144403.GO29960@fencepost>

It's been a while since we've had any kind of good discussion about the
remaining GPLv3 issues people are interested in.  Time is running pretty
tight now for the next and likely final draft, so if you want your
suggestions for improvements to be heard, we need to start talking about
them now so they can be written up and escalated in time.  Can people meet
at the usual time (6 PM USA Eastern) tomorrow?  If not, name some times
that would work for you, and we'll see if we can arrange something else.

I'd really like to see some good stuff come out of this committee, because
I've seen the great ideas you all have, and it'd be a shame for RMS and
Eben not to hear about them because it seems like we all collectively got
tied up in other commitments around this time.  I'm not criticizing
anybody; I haven't been especially helpful myself, and I know how hard it
is to volunteer time and effort for something like this.  But as Fontana
pointed out recently, the committees who have made the most suggestions are
the ones who have had the most influence on the draft so far.

The other committees are talking about things like how there should be a
patent license rather than a covenant not to sue, because the latter causes
patent exhaustion.  Patent exhaustion is a topic so obscure, you can't even
look it up on Wikipedia.  One of the other committees wants to scrap
section 7 entirely and replace it with a list of compatible licenses, a la
MySQL's GPL exception -- and they don't want the Affero GPL on that list.
These are the kinds of things RMS and Eben are going to be hearing as they
work on the final draft.  I'd feel better about that if I knew they were
hearing from you all, too.

Here are the issues that I know are open in some way:

* System libraries exception
  (http://gplv3.fsf.org/pipermail/committee-d/2006-August/000129.html): I
  already passed this along to RMS because it came up in another context.
  But both of us would be very interested in feedback on the specific
  language, and suggestions for how to improve it.

* The Affero compatibility clause, section 7b4: Last I heard, Mako was
  going to discuss the underlying goals and philosophy behind the Affero
  GPL with Henri Poole, to see what kinds of changes might be possible for
  GPLv3.  Has this happened yet?  If not, it might be a good idea to just
  make whatever suggestions we want, and assume that there's a chance the
  Affero GPL can be updated accordingly.  RMS has already made statements
  suggesting that this will have to be the case, so I don't think it will
  be a problem.  But I've lost track of what changes we wanted to make
  here....

* DRM: Hm, we never did do Seth's thought experiments.  Does anybody think
  there are cases caught by the current language that shouldn't be?  Or
  cases that aren't caught that should be?  Does anybody have any general
  ideas for improving the language, or idea behind it?

If there's anything else, now would be the time to bring it up.  No need to
wait for the meeting; just send it to the list.  We're mostly hacker types,
after all, so we shouldn't be afraid of some mailing list organizing.  :)

Thanks everyone,

-- 
Brett Smith
Licensing Compliance Engineer, Free Software Foundation

From mako at atdot.cc  Mon Oct  2 13:11:13 2006
From: mako at atdot.cc (Benj. Mako Hill)
Date: Mon, 2 Oct 2006 13:11:13 -0400
Subject: [Committee-d] Meeting tomorrow?/rallying cry
In-Reply-To: <20061002144403.GO29960@fencepost>
References: <20061002144403.GO29960@fencepost>
Message-ID: <20061002171113.GY24691@yukidoke.org>

<quote who="Brett Smith" date="Mon, Oct 02, 2006 at 10:44:03AM -0400">
> * The Affero compatibility clause, section 7b4: Last I heard, Mako was
>   going to discuss the underlying goals and philosophy behind the Affero
>   GPL with Henri Poole, to see what kinds of changes might be possible for
>   GPLv3.  Has this happened yet?

I've emailed Henri at least once about talking in more depth (e.g., on
the phone) and have not heard back from him one way or another.

>   If not, it might be a good idea to just make whatever suggestions
>   we want, and assume that there's a chance the Affero GPL can be
>   updated accordingly.  RMS has already made statements suggesting
>   that this will have to be the case, so I don't think it will be a
>   problem.  But I've lost track of what changes we wanted to make
>   here....

I think we know what we'd like it to say in the ideal sense. I'm just
not sure if it's compatible with what the AGPL is trying to do (or
rather, with how it's trying to 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 zak at greant.com  Mon Oct  2 14:19:01 2006
From: zak at greant.com (Zak Greant)
Date: Mon, 2 Oct 2006 11:19:01 -0700
Subject: [Committee-d] Meeting tomorrow?/rallying cry
In-Reply-To: <20061002144403.GO29960@fencepost>
References: <20061002144403.GO29960@fencepost>
Message-ID: <50363233-642B-4FC0-A062-D41E899340A7@greant.com>

On Oct 2, 2006, at 07:44PDT (CA), Brett Smith wrote:
...
> If there's anything else, now would be the time to bring it up.  No  
> need to
> wait for the meeting; just send it to the list.  We're mostly  
> hacker types,
> after all, so we shouldn't be afraid of some mailing list  
> organizing.  :)

Perhaps we should also think about the recent comments from Linus and  
crew?

-- 
Cheers!
--zak



From brett at fsf.org  Mon Oct  2 20:09:11 2006
From: brett at fsf.org (Brett Smith)
Date: Mon, 2 Oct 2006 20:09:11 -0400
Subject: [Committee-d] Meeting tomorrow?/rallying cry
In-Reply-To: <20061002171113.GY24691@yukidoke.org>
References: <20061002144403.GO29960@fencepost>
	<20061002171113.GY24691@yukidoke.org>
Message-ID: <20061003000911.GZ29960@fencepost>

On Mon, Oct 02, 2006 at 01:11:13PM -0400, Benj. Mako Hill wrote:
> I've emailed Henri at least once about talking in more depth (e.g., on
> the phone) and have not heard back from him one way or another.

Hmm, now that I think about it, he might be tied up with Day Against DRM
stuff.  Which fortunately is tomorrow.  :)  I can maybe try to work some
backchannels to get his attention on Wednesday.

> I think we know what we'd like it to say in the ideal sense. I'm just
> not sure if it's compatible with what the AGPL is trying to do (or
> rather, with how it's trying to do it).

If we can't get a hold of Henri, would it be possible for you to write
something up along the lines of "We suggest you do FOO, but if you don't
want AGPL to do that, we suggest you at least do BAR?"  Or is that too
complicated to be reasonable?

Thanks,

-- 
Brett Smith
Licensing Compliance Engineer, Free Software Foundation

From brett at fsf.org  Mon Oct  2 20:11:17 2006
From: brett at fsf.org (Brett Smith)
Date: Mon, 2 Oct 2006 20:11:17 -0400
Subject: [Committee-d] Meeting tomorrow?/rallying cry
In-Reply-To: <50363233-642B-4FC0-A062-D41E899340A7@greant.com>
References: <20061002144403.GO29960@fencepost>
	<50363233-642B-4FC0-A062-D41E899340A7@greant.com>
Message-ID: <20061003001117.GA29960@fencepost>

On Mon, Oct 02, 2006 at 11:19:01AM -0700, Zak Greant wrote:
> Perhaps we should also think about the recent comments from Linus and  
> crew?

By all means, go ahead.  I think I'm a little too close to the subject to
be the one who starts that conversation, but it's certainly a worthwhile
discussion for the committee to have, if you all want.

-- 
Brett Smith
Licensing Compliance Engineer, Free Software Foundation

From zak at greant.com  Tue Oct  3 10:58:11 2006
From: zak at greant.com (Zak Greant)
Date: Tue, 3 Oct 2006 07:58:11 -0700
Subject: [Committee-d] Late messages (was Re: DRM And Authentication Issue
	Draft Text)
In-Reply-To: <20060514005016.GM16182@volo.donarmstrong.com>
References: <20060514005016.GM16182@volo.donarmstrong.com>
Message-ID: <423D3EFC-D8C6-44D9-8C31-5FE6BD867A85@greant.com>

Did anyone else just receive a set of very late (circa May) messages  
from Don, Mako and Peter?

Cheers!
--zak

From brett at fsf.org  Tue Oct  3 11:14:28 2006
From: brett at fsf.org (Brett Smith)
Date: Tue, 3 Oct 2006 11:14:28 -0400
Subject: [Committee-d] Late messages (was Re: DRM And Authentication
	Issue Draft Text)
In-Reply-To: <423D3EFC-D8C6-44D9-8C31-5FE6BD867A85@greant.com>
References: <20060514005016.GM16182@volo.donarmstrong.com>
	<423D3EFC-D8C6-44D9-8C31-5FE6BD867A85@greant.com>
Message-ID: <20061003151428.GE29960@fencepost>

On Tue, Oct 03, 2006 at 07:58:11AM -0700, Zak Greant wrote:
> Did anyone else just receive a set of very late (circa May) messages  
> from Don, Mako and Peter?

Yeah, I have no idea what that was about.

-- 
Brett Smith
Licensing Compliance Engineer, Free Software Foundation

From mako at atdot.cc  Tue Oct  3 11:45:46 2006
From: mako at atdot.cc (Benj. Mako Hill)
Date: Tue, 3 Oct 2006 11:45:46 -0400
Subject: [Committee-d] Late messages (was Re: DRM And Authentication
	Issue Draft Text)
In-Reply-To: <20061003151428.GE29960@fencepost>
References: <20060514005016.GM16182@volo.donarmstrong.com>
	<423D3EFC-D8C6-44D9-8C31-5FE6BD867A85@greant.com>
	<20061003151428.GE29960@fencepost>
Message-ID: <20061003154546.GB24691@yukidoke.org>

<quote who="Brett Smith" date="Tue, Oct 03, 2006 at 11:14:28AM -0400">
> On Tue, Oct 03, 2006 at 07:58:11AM -0700, Zak Greant wrote:
> > Did anyone else just receive a set of very late (circa May) messages  
> > from Don, Mako and Peter?
> 
> Yeah, I have no idea what that was about.

It seems that someone moderated the list. Perhaps the first time ever.

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 brett at fsf.org  Tue Oct  3 18:54:30 2006
From: brett at fsf.org (Brett Smith)
Date: Tue, 3 Oct 2006 18:54:30 -0400
Subject: [Committee-d] Tonight's meeting
Message-ID: <20061003225429.GG29960@fencepost>

Attached is the log for tonight's meeting.  Particularly noteworthy:

* Brett will go over the comments and find ones that seem to correspond to
  what the kernel developers advocated in their recent statements.  Zak
  will then take those and try to get the kernel developers interested in
  the process, using them as a base.  He'll also create comments for any
  issues apparently not addressed.

* The timeline for the draft 3 release is a little unclear at this point.
  Richard Fontana thinks there should be more time for comments, and that a
  November 1 release may not be possible.  If people have strong opinions
  about this, we might want to discuss the issue here and then let RMS and
  Eben know what we think.  You can also contact them directly if you
  want.

Thanks,

-- 
Brett Smith
Licensing Compliance Engineer, Free Software Foundation
-------------- next part --------------
--> You are now talking on #committeed
--- Topic for #committeed is GPLv3 Committee D channel | Meetings on Tuesdays at 2200UTC | Gobby server (when meetings are on) archimedes.ucr.edu:6522
--- Topic for #committeed set by dondelelcaro at Tue Aug  8 18:01:33
--> ZakGreant (n=zag at mail.ezsystemsnorthamerica.com) has joined #committeed
<bcs> Hi Zak.
<ZakGreant> Aloha Brett!
* ZakGreant is still in a Mozilla Foundation board member interview ... should be finished soon.
<bcs> No worries, I don't think anybody else has quite gotten in yet either.
<ZakGreant> Seems like it.
<ZakGreant> BBIAM
<ZakGreant> Back
* ZakGreant watches the digital tumbleweeds blow through the channel
<bcs> Yeah....
--> Rickerby (n=drickerb at 38.112.155.93) has joined #committeed
<bcs> Hi David.
<Rickerby> sorry I'm late
<bcs> Well, there's only three of us so far, so....
<ZakGreant> ... you are practically early. ;)
<Rickerby> ahhh
<Rickerby> everyone else is out protesting DRM?
<ZakGreant> *snort*
<bcs> Hey, what was that for?  I spent a couple hours on it, we got out a lot of flyers and stickers.
<ZakGreant> Sorry - no offense meant. It was a funny quip. :)
<Rickerby> I was actually kind of serious. I'm here as a slave to my corporate masters, but that doesn't mean everyone is. ;-)
<ZakGreant> Ah.. the fantastic subtleties of IRC. All the nuance that ANSI-coloured text can offer.
<bcs> :)
<bcs> So do either of you have anything you'd like to bring up or discuss?
<ZakGreant> So... here is what is rumbling around my head right now.
<ZakGreant> The Linux kernel hackers have finally raised some issues
<ZakGreant> I will try to filter through them and correlate them to existing comments; or
<ZakGreant> I will create new comments, in the slight chance that they are needed
--> fontana (n=fontana at thurgood-marshall.sflc.info) has joined #committeed
<ZakGreant> Then I am thinking that I try to get the kernel hackers to pay attention to said comments.
<ZakGreant> Simultaneously, if no one has picked up the issue (I think that most of them are being discussed), then we turn the relevant comments into an issue.
<bcs> What do you mean by "pay attention" exactly?
<ZakGreant> By we, I mean me and any brave volunteers not already burdened with issues.
<ZakGreant> By "pay attention", I mean that I want them to be aware of the discussion around the issue and hopefully, convince them to participate in the discussion.
<ZakGreant> I would prefer to do this in a more public way to help ensure that more people can be in the loop.
<dondelelcaro> it'd also be nice if they'd actually address specificially the language that they have problems with and suggest reasonable corrections for them
<ZakGreant> dondelelcaro: That would be nice...
<dondelelcaro> (of course, in the end, it's doubtfull that they'll ever be able to move beyond going v2 or later for some portions of the code)
<bcs> ZakGreant: If you want to do that, I'd encourage you to go for it, but only if you're actually willing to advocate for the issues they raise.
<ZakGreant> dondelelcaro: Agreed. However, it is still important to take the step of trying to get them more engaged - not just for the sake of Linux, but for the entire GPL v3 process.
<dondelelcaro> ZakGreant: true
<ZakGreant> I'll have a clearer idea of how much work that will be once I correlate the issues they raise to existing discussions. I bet that most of their concerns are being covered already - they just haven't looked.
<ZakGreant> Any other comments or cautions?
<dondelelcaro> not that I can see
<bcs> Not from me.
<ZakGreant> Ok. I will undertake this task this week.
<bcs> Okay.  Do you have anything else, Zak?
<ZakGreant> Nope.
<bcs> Okay.  So what's on other people's minds?
<bcs> ... really, nothing?  :)
<bcs> So, OOC, does this mean that people are cool with draft 2, except for the issues already discussed?
<ZakGreant> Heh. I would suspect it indicates draft fatigue.
<fontana> I thought Draft 2 was perfect when it came out :)
<ZakGreant> Heh. I stand corrected.
<bcs> That's what I told Dave Turner, too.  :)  Yeah, I won't deny that this is getting to be a long process for everyone.
<bcs> Has this committee done any review of the comments for draft 2?
<dondelelcaro> yeah... I just keep putting off going through it completely like I did for draft one...
<dondelelcaro> I've been a bit too busy lately
<ZakGreant> I am in the same state - life has been rather hectic.
<bcs> Actually, fontana, do you know if any committee's done that?  It seemed to be the thing to do for draft 1 and now not so much.
<bcs> It's like people are stuck on their pet issues.
<fontana> bcs: no one has really been doing it for Draft 2.
<bcs> Hmm.
<ZakGreant> When is our deadline again?
<bcs> In a couple of weeks-ish.
<bcs> Last I heard.  Any news on that front, fontana?
<bcs> ZakGreant: How would you feel if I went through the comments, and pointed out to you the ones that seemed to reflect the kernel developers' positions?
<ZakGreant> I will also try to review all comments on the draft - it fits in well with the other work I have. I can take a day off of work to get it done, if need be.
<fontana> bcs:  unclear... I suspect it will not be out by November 1st
<fontana> but there might be a push to get it out by that date
<ZakGreant> bcs: That would be lovely!
<bcs> ZakGreant: Okay, I will do that.  I'll probably send the results to the list, just for whoever else is interested.
<bcs> Hopefully by the end of the week.
<ZakGreant> Cool. I will focus on getting kernel hacker attention. :)
<bcs> fontana: I'm going to take that to mean we should still figure our deadline is in a couple of weeks from now, until we hear otherwise.  :)
<fontana> bcs: I'm not sure what to advise on that. I myself think we need some more time.
<fontana> and I am not sure it really will be possible to get the 3rd draft out by then
<bcs> Does anybody else have any opinions on a timeline for the next draft?
<fontana> If anyone feels strongly that more time and deliberation is needed over the current draft, I'd suggest letting RMS know. :)
<ZakGreant> bcs: I value completeness of review over timeliness.
<Rickerby> Seems to me that you create the coalition before you issue a draft. At least if you want it adopted... But that's just the way I do things. :)
<ZakGreant> I have to catch up with someone before they leave the office BBI5M
<bcs> Well, I think if nobody has anything else, we're done for now.
<Rickerby> BCS - send me one or two of those stickers and pins!
<bcs> Heh.  We don't have pins here, but I'll see what I can do about the stickers.
<ZakGreant> back
<ZakGreant> Thanks all! Thanks Brett!
<bcs> No problems, thank you.

From brett at fsf.org  Wed Oct  4 18:01:27 2006
From: brett at fsf.org (Brett Smith)
Date: Wed, 4 Oct 2006 18:01:27 -0400
Subject: [Committee-d] First round of comments
Message-ID: <20061004220126.GO29960@fencepost>

I got through about 100 comments today.  I broke them down into rough
categories that I thought might be useful, and made notes on other
interesting ones as well.  (Where "interesting" is not at all well-defined,
especially for people who aren't me.  :) )

Zak, I at least found some comments that seem to reflect what various
kernel developers said in the position statement, so I expect you can use
this as a starting point, even though I'm not nearly all the way through
things yet.  I figured I'd send this along to the list, though, in case
people are interested in reviewing it, and maybe taking up the cause of any
comments I've highlighted.

Comments coming out against TiVo protection:
1956
1955
1917 (?? - definitely a new spin on it, at least)
1913 (suggests allowing TPMs but making sure it's legal to circumvent them)
1833 (suggests this is bad for people making medical devices, etc.)
1765 ("Focusing on a particular way to make software read-only is wrong")

Comments against all additional restrictions:
1782 ("way too vague")

Comments against the patent covenant not to sue:
1870
1691

Comments saying GPLv3 abuses developers' trust in FSF:
1875
1834
1766

Comments on 7b4:
1952 (suggests allowing any usual source distribution mechanism)
1927 (says it encourages dual licensing)

Comments about "this is not a TPM":
1926 (fine line, be careful)
1931 (reference to US code is bad)
1903 (ditto)

Comments suggesting that it's still not clear who/what the covenant covers:
1704
another one that came after 1704
1703

Other interesting comments:
1902 suggests people are required to distribute too much source and offers
an alternative.
1883 questions what tools aren't required in source.
1832 asks "If a GPLed program uses plugins, and warns users about unsigned
plugins, but otherwise runs them fine, do the plugin authors have to
provide keys as part of the source?"
1831 asks about how the license interacts with European moral rights.
1813/1812 asks "Can you make an argument that DRM-encumbered distribution
is propagation, since it doesn't allow users to copy the software?"
1800 suggests covenant should include conveying.
1762 asks whether the covenant extends to modified works, which is
interesting since I thought it very clearly did in draft 1, and I think
it's less clear now.
1759 wants automatic termination back.
1756 thinks termination needs to explicitly cover failure to provide
covenant, etc.
1744 points out that keys may not be all that's necessary to run modified
versions on the same hardware.
1736 asks about nagware screen being protected by 7b0.
1734 says prohibiting "requirements regarding changes to the name of the
work" is too broad.
1712 has an interesting twist on symmetric upgrade.

-- 
Brett Smith
Licensing Compliance Engineer, Free Software Foundation

From brett at fsf.org  Mon Oct  9 15:21:33 2006
From: brett at fsf.org (Brett Smith)
Date: Mon, 9 Oct 2006 15:21:33 -0400
Subject: [Committee-d] Comments summary
Message-ID: <20061009192133.GH18318@fencepost>

Below is a guide to all the interesting comments I found on the current
GPLv3 draft.  This is basically the second version of what I sent out last
week, so the same rules still apply: I was singling out the things Zak
wanted, everything else is basically completely arbitrary, etc.  But this
covers the rest of the comments, and has a bit more categorization, which
shows some interesting patterns.

I'm thinking we could discuss at our meeting tomorrow which of these issues
we'd like to take up (of those we haven't already); does that sound good to
people?

Thanks,

---------------------------------------------------------------------------
Comments coming out against TiVo protection:
1956
1955
1917 (?? - definitely a new spin on it, at least)
1913 (suggests allowing TPMs but making sure it's legal to circumvent them)
1833 (suggests this is bad for people making medical devices, etc.)
1765 ("Focusing on a particular way to make software read-only is wrong")
1604 ("To accommodate Linus, make this optional")
1525
1520 (about the requirement that modified versions need not report)

Other comments about TiVo protection:
1832 asks "If a GPLed program uses plugins, and warns users about unsigned
plugins, but otherwise runs them fine, do the plugin authors have to
provide keys as part of the source?"
1813/1812 asks "Can you make an argument that DRM-encumbered distribution
is propagation, since it doesn't allow users to copy the software?"
1744 points out that keys may not be all that's necessary to run modified
versions on the same hardware.
1712 has an interesting twist on symmetric upgrade: require
signatures/remote attestation from an "independent" third party.  I'm not
sure this would really work in the real world, but it's good food for
thought.
1644 suggests that the anti-TiVoization clause should require that the
hardware accept other signing keys, rather than requiring that the accepted
key be distributed.
1609 says that anti-TiVoization should cover propagation.

Comments against all additional restrictions:
1782 ("way too vague")
1667 and 1661 (says it kills copyleft)
1579 (different twist: "If it's good enough for GPL, put it in GPL")

Comments against the patent covenant not to sue:
1870
1691 (actually about section 7 rather than 11)

Other comments about the covenant:
1800 suggests covenant should include conveying.
1762 asks whether the covenant extends to modified works, which is
interesting since I thought it very clearly did in draft 1, and I think
it's less clear now.
1581 considers weaknesses in the covenant when patents/copyrights change
hands.

Comments saying GPLv3 abuses developers' trust in FSF:
1875
1834
1766
1564 (kind of -- says license should have a new name)
1661

Comments on 7b4:
1952 (suggests allowing any usual source distribution mechanism)
1927 (says it encourages dual licensing)
1683 ("over a computer network" is actually a loophole)
1608 ("same network session" is too specific)
1569 (wants to require publication of source in other circumstances)
1427 (opposed)
1498 (like 1569)

Comments about "this is not a TPM":
1926 (fine line, be careful)
1931 (reference to US code is bad)
1903 (ditto)
1655 (ditto)

Comments suggesting that it's still not clear who/what the covenant covers:
1704
another one that came after 1704
1703

Comments on the system libraries exception:
1583 suggests widening the standard libraries exception, which I think is
already covered in my language.
1516 suggests the libraries exception doesn't allow easy porting to
non-free platforms.
1431 suggests library exception isn't enough for non-free OSes.

Comments on the definition of source:
1902 suggests people are required to distribute too much source and offers
an alternative.
1883 questions what tools aren't required in source.
1573 points out amibguity in use of the word "free."

Comments about termination:
1759 wants automatic termination back; there was at least one other comment
along these lines, too.
1756 thinks termination needs to explicitly cover failure to provide
covenant, etc.

Comments about the scope of 7b0:
1736 asks about nagware screen being protected by 7b0.
1678 is worried about ads from 7b0.

Other interesting comments:
1831 asks about how the license interacts with European moral rights.
1734 says prohibiting "requirements regarding changes to the name of the
work" is too broad.
1638 wants 7b5 to allow FS-friendly companies to proactively sue with their
patents.  I don't think I agree (too hard to define, and I don't think this
we should encourage this kind of use of software patents), but interesting
anyway.
1636 asks about renting, as commonly happens in Europe.  Is this covered by
our definitions of propagate and convey?
1611 proposes allowing choice of law; mhatta marked this for discussion.
1598 brings up the language problem that Committee C had.
1593: Change "Verbatim Copying" to "Conveying Verbatim"
1592: Change "the Program" to "the Work"
1563 points out, in a roundabout way, that use on a local machine appears
to be conveying.  I don't like the proposed solution, though.
1535 asks if distributing binary patches is allowed.
1531 notes 6b1 does not require a written offer valid for any third party.
1469 suggests there's a possible loophole in allowing source distribution
from the same place as the binary.

-- 
Brett Smith
Licensing Compliance Engineer, Free Software Foundation

From zak at greant.com  Tue Oct 10 17:48:53 2006
From: zak at greant.com (Zak Greant)
Date: Tue, 10 Oct 2006 14:48:53 -0700
Subject: [Committee-d] Won't be at meeting today
Message-ID: <B3A411F7-713A-40DA-93F1-F75D01CA8F1F@greant.com>

Greetings All,

I won't be at the meeting today.

I will be working on the project to get the Linux kernel hackers more  
involved in the GPL v3 process.

Cheers!
--zak

From brett at fsf.org  Tue Oct 10 19:04:55 2006
From: brett at fsf.org (Brett Smith)
Date: Tue, 10 Oct 2006 19:04:55 -0400
Subject: [Committee-d] Today's meeting
Message-ID: <20061010230455.GG3716@fencepost>

Attached are the logs for today's meeting.  The highlights:

* We have proposed wording for the Affero compatibility clause that would
  keep it from requiring a specific method of source distribution.  Mako's
  also still interested in proposing changes to make it less
  technology-specific; we're still trying to get a hold of Henri to see how
  well that might fly.

* RMS accepted our proposal for the system libraries exception with some
  minor clean-ups.  Fontana showed us what's in the working draft and it
  looks good to me and Mako.  Don, Mako said you especially should review
  this and give it your stamp of approval.

* Some meta-discussion about the comment in stet about allowing choice of
  law clauses for Japan.

* It would be cool if people reviewed the comments summary and pointed out
  things they thought were important.  Suggestions for improvements to the
  license would be even cooler.  :)

Thanks,

-- 
Brett Smith
Licensing Compliance Engineer, Free Software Foundation
-------------- next part --------------
<bcs> Is there anything people are particularly interested in talking about?
<fontana> mako: did you ever get a chance to contact Henri Poole?
<mako> fontana: i've been trying
<mako> fontana: he hasn't answered any of mails, and bcs is chasing things up with him
<fontana> I was thinking of sending him an email myself ... hmm.
<mako> so, some sort of resolution to the affero bit is my first priority
<mako> i can grab the last text we had
<mako> well there's this:
<mako> "terms that require, if a modified version of the material they
<mako> 15:13 < mako>                  cover is a work designed to interact with users through a computer
<mako> 15:13 < mako>                  network, that the Corresponding Source be conveyed to a user who
<mako> 15:13 < mako>                  requests it through one of the means specified in section 6, without
<mako> 15:13 < mako>                  mandating the particular means"
<mako> wait, that's a mess
<mako> terms that require, if a modified version of the material they cover is a work designed to interact with users through a computer network, that the Corresponding Source be conveyed to a user who requests it through one of the means specified in section 6, without mandating the particular means
<mako> fontana: that was your suggestion i think
<bcs> That's the big issue you're trying to address?  Allowing various different means of distributing source?
<fontana> mako: yes
<mako> bcs: this is the ideal solution
<fontana> bcs:  I think it boils down to that...
<bcs> Yeah, that's cool, just checking.  I had kind of lost track of what we were looking to improve with the clause in general, sorry.
<mako> bcs: to get away from language that allows compatibility with licenses that require a particular type of interaction
<mako> basically, there's a fear that the allowance for a restriction on modification may allow for people to use it to create restrictions on modification that are much broader than what we'd like to be compatible with
<mako> the only major problem with that, or with language like that, is that it will very obviously break compatibility with the AGPL as written
<bcs> Okay, yeah, I remember discussing this now.
<mako> so it basically depends on how married the AGPL folks are to their currently strategy
<mako> of hooking into a prohibition on a type of private modification
<mako> in my position paper on draft 1`
<bcs> I'm not sure, but I think this would be a relatively uncontroversial suggestion.  Like I said, RMS has already said that Henri understands that he'll have to tweak AGPL, and is willing to do so.
<mako> i speculated on why i thought they had chose the mechanism they did
<mako> bcs: this is more than a tweak
<bcs> No, I don't know exactly what tweaks would be necessary, but this doesn't seem like it would be a big one.
<mako> it's a completely different tactic
<fontana> bcs: this seems to be the crux of the problem... there is concern that Henri Poole is wedded to the precise formulation in the existing AGPL, and I don't know if that's based on fact
<mako> the spirit and effect should be the same
<bcs> fontana: Oh, hmm.
<bcs> Can I ask who has those concerns, at least?
<mako> i've speculated that it came down to the "this is not a contract" bit
<mako> in that private modification is part of the statutory right of the copyright holder
<mako> but requiring section 6 bits for users would be outside of that
<fontana> bcs:  basically me :)
<mako> that's note a huge issue for a compat clause
<bcs> fontana: That's fair.  :)
<mako> the private modification prohibition is very clever
<mako> limitation rather
<bcs> Okay.  So maybe it's not uncontroversial, but even then, if we can't get a hold of Henri, I think going forward with the proposal is a good idea.
<mako> the differences between draft 1 and 2 seemed to take into the concern that it would be compatible with other licenses by making it more narrowly focused on the precise wording of the AGPL
<mako> bcs: basically, i have two different suggestions
<mako> the one i'd like to make which involves rethinking the AGPL in a more major way
<mako> and a second which requires less changes
<bcs> mako: I think the changes did have that effect, but it's not clear to me that that was the intent.  I wasn't around for that, but the changes seemed to actually try to protect freedom, so that the clause didn't let a license screw you over by requiring that you provide source even if you turn the software into a standard desktop application where the normal source distribution is fine.
<bcs> mako: For that first suggestion, you're talking about broadening the scope, so that it's closer to the ideal of "You can get the source for all the software you use" right?
<mako> bcs: yes, but that's rather orthogonal to the argument i made for draft 1
<mako> well, not completely
<mako> i don't think the answer is to make things more technology specific
<bcs> I agree.
<mako> unanticipated technological change is the reason we have this clause in the first place
<mako> :)
<mako> ok.. so i'd like to submit fontana's text, or something similar
<mako> unless that's completely unacceptable
<mako> in which case, i'd like to submit something else
<mako> so here's my question
<mako> for henri or whoever
<mako> "If the point of the AGPL is to bring the freedoms protected by Section 6 to the users of the software, why didn't you just say that but instead phrase it in terms of restrictions on technological changes?"
<mako> and "What would need to change for you to reevalate that tactic?"
<bcs> We could possibly ask RMS and/or Eben about that, too; as I understand it they were involved in the drafting of AGPL.
<bcs> They're busy too but I can attest that they still answer e-mail.  :)
<fontana> mako: have you mailed RMS about any of this?
<mako> fontana: i can't recall, perhaps briefly
<mako> fontana: but i think he told me to talk to henri
<fontana> :)
<bcs> Man, I'm just full of bad ideas tonight.  :)
<mako> well ok
<mako> that's the first issue
<mako> the only thing i've worked on at all is the system lib exception
<mako> bcs: do you have the last options we came up with?
<bcs> Hold on a sec, let me dig up the URL.
<bcs> http://gplv3.fsf.org/pipermail/committee-d/2006-August/000129.html
<bcs> RMS and I started talking about the system libraries exception in another context, so I passed that along to him, and he indicated he adopted it with some minor wording tweaks.
<fontana> I can give you our working draft language ... just a sec
<fontana>  A "Standard Interface" means an interface that either is an official
<fontana> standard defined by a recognized standards body or is used by a
<fontana> majority of developers working in a particular programming language.
<fontana> And then the system libraries definition just refers to "Standard Interface"
<fontana> "or to implement a Standard Interface for which an
<fontana> implementation is available to the public in source code form.
<fontana> "
<mako> ok, that looks pretty close to what we suggested
<bcs> Yeah.  It's slightly cleaner, IMO, because it makes it clearer that standard interfaces always have to have source available, whereas my language maybe let you think the source was only available for "majority of programmers" cases.
<bcs> "recognized standards body" is still, you know, maybe not watertight, but I'm comfortable with it personally.
<mako> right, that closes the issue we came up with last time
<fontana> We thought that "recognized standards body" was good enough, didn't require more specificity
<mako> ok
<bcs> If it's good enough for the lawyers it's good enough for me.  :)
<mako> do we care about the example we gave a few weeks ago with the person or company taht makes their own language
<mako> to get around this?
<bcs> The requirement that source be available takes care of that problem.
<mako> ah, here:
<mako> 18:37 < fontana> "or to implement a Standard Interface for which an
<mako> 18:37 < fontana> implementation is available to the public in source code form.
<bcs> Yes.
<mako> ok
<mako> that addresses my only issue
<mako> if that's in the draft, i'm happy with it
<mako> dondelelcaro should ok it too
<bcs> I'll mail tonight's logs to the list, and point that out.  :)
<bcs> Anything else?
<mako> ummm
<mako> not from me personally unless there's something y'all want my opinion
<mako> i've personally tried to focus on a few issues that were important to me
<bcs> Yeah.  I wrote up that summary of comments and some of them were interesting but I haven't really been able to evaluate which are the things that I think *need* addressing.
<fontana> I will mail Henri Poole about the AGPL
<bcs> Once I do I'll probably point them out to the committee specifically and ask for other people's thoughts.
<mako> bcs: i can take a look though that list quickly now if you want
<bcs> mako: I don't think you need to do it right now, but I definitely would appreciate if you -- and everybody else -- reviewed it and chimed in if they thought there was stuff seriously worth pursuing and not already addressed.
<bcs> mhatta marked for discussion (in stet) a comment advocating that we allow a choice of law clause, which I'd definietly love to hear more from him about, but...
<fontana> that's an interesting suggestion...
<bcs> fontana: The comment came from someone suggesting it's all but necessary in Japan, and since mhatta marked it I assume there's something to it.
<mako> bcs: i haven't thought too much about choice of law clauses, but i know people in debian have taken issue with some of those in the past
<mako> at least some of them, rather
<bcs> Yeah, there are good arguments to be made against them and I agree with those arguments.
<fontana> I doubt it's *necessary*
<fontana> I don't share Eben and RMS's strong dislike of them... they do sort of imply the existence of a contract
<bcs> But if people do believe it would help free software in Japan, I would at least like to hear those arguments as well.
<fontana> I'll take a look at the stet comment
<mako> i'm initially skeptical, but would like to hear the arguments in favor concerning japan as well
<bcs> fontana: Thanks.
<bcs> mako: Yeah, it's possible that there's not as much to it as the comment makes out.  But I would rather put in a little effort and find out it's not a big deal than vice versa.  :)
* mako nods
<bcs> Like I said, I'll chew a little more about what in there I'd especially like to see addressed and then mail about it, and if other people did too that would be great.

From mhatta at grad.e.u-tokyo.ac.jp  Thu Oct 19 21:44:26 2006
From: mhatta at grad.e.u-tokyo.ac.jp (Masayuki Hatta)
Date: Fri, 20 Oct 2006 10:44:26 +0900
Subject: [Committee-d] Choice of law, forum and venue (Re:  Today's meeting)
In-Reply-To: <20061010230455.GG3716@fencepost>
References: <20061010230455.GG3716@fencepost>
Message-ID: <20061020014432.B89DE72171E@marx.e.u-tokyo.ac.jp>

Hi,

>>>>> In <20061010230455.GG3716 at fencepost> 
>>>>>	Brett Smith <brett at fsf.org> wrote:

> * Some meta-discussion about the comment in stet about allowing
>   choice of law clauses for Japan.

Yes, Comment #1611.  I am still not sure how to handle this issue.  I
am afraid that the deadline for Final Call might be past, but I
appreciate your comments.

The problem is simple -- in Japan, a contract has stronger effect than
mere declaration of one's intent.  For example, I might not able (or
actually, have no way) to demand a GPL-violator to release the source
code if the court thinks GPL is my declaration, not a contract between
us.  In this case, GPLv3 is much weaker than GPLv2.  GPLv3 DD2 is much
better than DD1, since the "Not a Contract" phrase had gone in Cl.9,
but there is still room to dispute.

How do you think?

Best regards,
MH

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

From fontana at softwarefreedom.org  Fri Oct 20 07:45:59 2006
From: fontana at softwarefreedom.org (Richard Fontana)
Date: Fri, 20 Oct 2006 07:45:59 -0400
Subject: [Committee-d] Choice of law,
	forum and venue (Re:  Today's meeting)
In-Reply-To: <20061020014432.B89DE72171E@marx.e.u-tokyo.ac.jp>
References: <20061010230455.GG3716@fencepost>
	<20061020014432.B89DE72171E@marx.e.u-tokyo.ac.jp>
Message-ID: <4538B6F7.1090904@softwarefreedom.org>

Masayuki Hatta wrote:
>>>>>> In <20061010230455.GG3716 at fencepost> 
>>>>>> 	Brett Smith <brett at fsf.org> wrote:
> 
>> * Some meta-discussion about the comment in stet about allowing
>>   choice of law clauses for Japan.

> The problem is simple -- in Japan, a contract has stronger effect than
> mere declaration of one's intent.  For example, I might not able (or
> actually, have no way) to demand a GPL-violator to release the source
> code if the court thinks GPL is my declaration, not a contract between
> us.  In this case, GPLv3 is much weaker than GPLv2.  GPLv3 DD2 is much
> better than DD1, since the "Not a Contract" phrase had gone in Cl.9,
> but there is still room to dispute.

There seem to be a few separate issues here:
1) Is there anything in *both* GPLv2 and GPLv3 that raise issues of
enforceability under Japanese law?
2) Is there anything in GPLv3 that makes it less likely to be
enforceable under Japanese law than GPLv2?
3) Should GPLv3 contain a choice of law or forum clause (and what would
it say)?
4) Should GPLv3 be incompatible with other licenses merely because those
other licenses contain choice of law or forum clauses?  I.e., should
such clauses be treated as impermissible "additional restrictions"?

I suspect that the answer to 2) is "no" (you seem to be suggesting
otherwise in saying "GPLv3 is much weaker than GPLv2", but I don't
understand the reason).

As far as I can tell, the comment seems to be implying that "GPLv3
should contain a choice of law clause, because that will turn it into an
enforceable contract under Japanese law", which doesn't really make any
sense; it seems to be a non sequitur. There are many reasons why we
don't have a choice of law (or forum) clause in either version of the
GPL, and all that is orthogonal to the issue of enforceability in
general, or of how the GPL would be interpreted in a particular
jurisdiction (as a copyright license, a contract, etc.).

Regarding 4), which is what the actual referenced part of the draft is
concerned with, I think there's something to be said for removing that
laundry list of examples of "all other additional requirements" from
that paragraph of section 7 (if only to make the license a little
shorter), although it accurately presents historical FSF policy on
license compatibility issues. There are good policy reasons for
discouraging free software licenses from having choice of law or forum
clauses, but one can imagine situations where they don't actually
operate to impose an "additional restriction" on downstream licensees.



From mako at atdot.cc  Sun Oct 22 19:11:47 2006
From: mako at atdot.cc (Benj. Mako Hill)
Date: Sun, 22 Oct 2006 19:11:47 -0400
Subject: [Committee-d] AGPL Text
Message-ID: <20061022231147.GE9803@yukidoke.org>

Sorry for the delay in the reply. Here's the position statement for
Draft 1:

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

Here's the text we're suggestion a compatibility clause that reads like
this (or something in the spirit):

  terms that require, if a modified version of the material they cover
  is a work designed to interact with users through a computer network,
  that the Corresponding Source be conveyed to a user who requests it
  through one of the means specified in section 6, without mandating the
  particular means

Yom can imagine the change to the AGPL that would need to happen. It
would be in the same spirit but would employ a different legal.

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 mhatta at grad.e.u-tokyo.ac.jp  Sun Oct 22 20:05:09 2006
From: mhatta at grad.e.u-tokyo.ac.jp (Masayuki Hatta)
Date: Mon, 23 Oct 2006 09:05:09 +0900
Subject: [Committee-d] Choice of law,
	forum and venue (Re:  Today's meeting)
In-Reply-To: <4538B6F7.1090904@softwarefreedom.org>
References: <20061010230455.GG3716@fencepost>
	<20061020014432.B89DE72171E@marx.e.u-tokyo.ac.jp>
	<4538B6F7.1090904@softwarefreedom.org>
Message-ID: <20061023000512.3E357722BB9@marx.e.u-tokyo.ac.jp>

Hi fontana,

>>>>> In <4538B6F7.1090904 at softwarefreedom.org> 
>>>>>	Richard Fontana <fontana at softwarefreedom.org> wrote:

> There seem to be a few separate issues here:

> 1) Is there anything in *both* GPLv2 and GPLv3 that raise issues of
> enforceability under Japanese law?

Basically yes, but maybe not really the problem "in" GPLv{2|3}.  Since
Moglen once asserted decisively that GPL is and has been not a
contract or agreement in the early stage of the GPLv3 revision process
(e.g. The title of DD1 Cl.9), I (and some Japanese legal professionals
I got advice) am concerned the risk that the Japanese court regards
GPL is not a contract has been considerably raised.

In other words, GPL might have been not a contract since its very
inception, but it was quite vague, and we "could" regard it as a
contract, at least in Japan.  It somehow contributed us favorably by
accident.  However, those happy days are gone now.

> 2) Is there anything in GPLv3 that makes it less likely to be
> enforceable under Japanese law than GPLv2?

So the answer is "no".  But the surrounding situation was changed, so
it might be good to put some antidote in GPLv3.

> 3) Should GPLv3 contain a choice of law or forum clause (and what
> would it say)?

I guess something like:

9' In jurisdictions that the manifest of intent makes contracts
established, conveying the Program by you shall indicate the
establishment of a contract.

might work, but I am not sure if there is any drawbacks.  IANAL, so
the wording should be polished.

> 4) Should GPLv3 be incompatible with other licenses merely because
> those other licenses contain choice of law or forum clauses?  I.e.,
> should such clauses be treated as impermissible "additional
> restrictions"?

I am not sure about it.

> I suspect that the answer to 2) is "no" (you seem to be suggesting
> otherwise in saying "GPLv3 is much weaker than GPLv2", but I don't
> understand the reason).

Well, you are right.  I should have said that "The legal state of Both
GPLv2 and GPLv3 became unstable in Japan, but not really because of
GPLv3 itself".

Best regards,
MH

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

From fontana at softwarefreedom.org  Sun Oct 22 21:52:18 2006
From: fontana at softwarefreedom.org (Richard Fontana)
Date: Sun, 22 Oct 2006 21:52:18 -0400
Subject: [Committee-d] Choice of law,
	forum and venue (Re:  Today's meeting)
In-Reply-To: <20061023000512.3E357722BB9@marx.e.u-tokyo.ac.jp>
References: <20061010230455.GG3716@fencepost>	<20061020014432.B89DE72171E@marx.e.u-tokyo.ac.jp>	<4538B6F7.1090904@softwarefreedom.org>
	<20061023000512.3E357722BB9@marx.e.u-tokyo.ac.jp>
Message-ID: <453C2052.5020205@softwarefreedom.org>

Masayuki Hatta wrote:
>> 1) Is there anything in *both* GPLv2 and GPLv3 that raise issues of
>> enforceability under Japanese law?
> 
> Basically yes, but maybe not really the problem "in" GPLv{2|3}.  Since
> Moglen once asserted decisively that GPL is and has been not a
> contract or agreement in the early stage of the GPLv3 revision process
> (e.g. The title of DD1 Cl.9), I (and some Japanese legal professionals
> I got advice) am concerned the risk that the Japanese court regards
> GPL is not a contract has been considerably raised.

I think Eben's statements on the subject (and the significance of that
original section heading) may have been misunderstood; after all, that
is why we changed the heading.

The references to acceptance (a concept that I think only makes sense
under contract law, in the US or anywhere else) acknowledge implicitly
that questions of contract formation will sometimes be relevant in some
legal systems. The basic point of this section (at least as I read it)
is that there is pure, unlimited permission to run the program as you
receive it, a permission which ought to exist outside of any notion of
contract.  If your local legal system insists on treating the GPL as a
contract, the GPL still does not start out as a contract (and indeed for
most users it never becomes a contract). If you force the licensee to
manifest contractual assent to the GPL in order to receive or run the
program, as some free software licenses do, you have added an additional
restriction in violation of section 10. All of the conditions on
permission that the GPL places on licensees apply only once you modify
or propagate (copy, distribute, etc.) code.

I forget whether I said this in my previous message, but we have some
German legal experts on Committee C who have discussed these issues with
us.  In their view, under German law, the GPL is a contract, but "mere
use" (including running the unmodified program) exists outside of the
GPL.  My understanding is that Japanese contract law was originally
modeled on German contract law, so perhaps similar interpretations would
apply under Japanese law.

>> 3) Should GPLv3 contain a choice of law or forum clause (and what
>> would it say)?
> 
> I guess something like:
> 
> 9' In jurisdictions that the manifest of intent makes contracts
> established, conveying the Program by you shall indicate the
> establishment of a contract.
> 
> might work, but I am not sure if there is any drawbacks.  IANAL, so
> the wording should be polished.

I actually think this is already there, in different words, in section
9, because it says that "by ... propagating the Program (or any covered
work), you indicate your acceptance of this License to do so".
Acceptance is a contract law concept - for a contract to be established,
there must be acceptance.  (It may be that we should have "conveying"
there instead of the broader "propagating", as some Japanese lawyers
recently pointed out to us -- GPLv2 section 5 says that distribution
indicates acceptance, but not mere copying, and non-conveying
propagation is permitted without limitation under GPLv3.)

-- 
Richard E. Fontana
Counsel
Software Freedom Law Center
tel. 212-461-1909
fax  212-580-0898


From brett at fsf.org  Tue Oct 24 09:57:02 2006
From: brett at fsf.org (Brett Smith)
Date: Tue, 24 Oct 2006 09:57:02 -0400
Subject: [Committee-d] Meeting today at 22:00 UTC
Message-ID: <20061024135702.GL30473@fencepost>

You know the drill.  This is probably the last good opportunity to bring
anything up for the final call draft.

-- 
Brett Smith
Licensing Compliance Engineer, Free Software Foundation

From schoen at loyalty.org  Tue Oct 24 10:33:03 2006
From: schoen at loyalty.org (Seth David Schoen)
Date: Tue, 24 Oct 2006 07:33:03 -0700
Subject: [Committee-d] Meeting today at 22:00 UTC
In-Reply-To: <20061024135702.GL30473@fencepost>
References: <20061024135702.GL30473@fencepost>
Message-ID: <20061024143303.GB1001@frotz.zork.net>

Brett Smith writes:

> You know the drill.  This is probably the last good opportunity to bring
> anything up for the final call draft.

I'm not going to be able to make this -- I've been up all night on a
conference call (about DRM) with people in Europe -- but I've been
working on some written comments about DRM issues, and I'll feel a
new sense of urgency to get them done.

-- 
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 pde at eff.org  Wed Oct 25 22:08:20 2006
From: pde at eff.org (Peter Eckersley)
Date: Wed, 25 Oct 2006 19:08:20 -0700
Subject: [Committee-d] Last minute comments on GPLv3-draft2
Message-ID: <1161828500.4219.68.camel@localhost>

Dear GPLv3 people,

there have been regular discussions about GPLv3 here at EFF over the
past weeks.  Seth Schoen and I have really been meaning to send some
notes on these to the FSF, but it hasn't happened until now.  I hope
these are still potentially useful despite the late point in the
schedule:

---------------------------------------------------------------------

On "No Denying Users' Rights through Technical Measures", the clause
formerly known as the DRM clause.

You really should replace the reference to 17 USC 1201 with a reference
to Article 11 of the 1996 WIPO Copyright Treaty and related national and
international law.  Effective technological measures are defined in
similar terms in many nations' laws; it does not make sense for this to
be U.S.-specific.

Gwen Hinze suggested the following language:

"No covered work constitutes part of an effective technological
protection measure under any national implementation of Article 11 of
the WIPO Copyright Treaty or any international agreement enforcing
similar obligations under, or in accordance with, any national
implementation of the WCT."

I would be tempted to change the lead-in to that sentence to something
like:

"Because the ordinary course of operation of a piece of GPL-licensed
software involves regular modification by users, no covered work..."

This should increase the clause's enforceability by providing a theory
for the clause to operate under, as opposed to its simply being an
assertion which a court might hold to be contrary to fact.

----------------------------------------------------------------------

On the definition of "Corresponding Source" to require key-sharing
(CSKS) clause:

This clause remains somewhat troublesome.  There are difficulties both
in terms of ambiguity of the text, about what it should try to achieve,
and about aspects of its enforceability.  

I am not going to address CSKS enforceability in this document; I think
Seth Schoen is sending some observations on this subject (including c. 

With regards to the clause's ambitions, there are certain activities
which are widely regarded as objectionable: TIVO's use of hardware
authentication to prevent the use of modified code on their devices, or
the construction of DRM systems on GNU/linux platforms using ``trusted''
computing and remote attestation.  Clearly, GPLv3-draft2 is trying to
prevent software from being used in these ways. 

Unless the language of the CSKS clause is changed to specifically call
out DRM, a range of other hypothetical uses of GPLv3 code in combination
with with trusted computing hardware for remote attestation will also be
forbidden:

* cheat-resistant network gaming servers

* remote attestation of online voting clients

* remote attestation of the code in ATMs

* remote attestation of the code in networked slot machines

* remote reporting of assurances that a machine has not been infected by
  trojans, viruses, rootkits, or other malware (in theory, computers
  with Trusted Platform Modules should be able to perform such tests
  locally, but currently deployed machines of this type -- such as many 
  recent Thinkpads -- lack any physical user interface suitable for  
  presenting such local assurances)

* remote attestation of the fact that a car engine has not been re-tuned
  to increase its power and push its emissions above legal limits
  
* attestation of the code in an Anti-Lock Braking system

* onion routing and p2p networks that use remote attestation to enforce
  non-surveillance policies on participating nodes

* any of the trusted computing applications above, where the 
  functionality is provided by more specialised, non-reprogrammable 
  hardware (rather than a "Trusted Platform Module").

Views on the importance of these applications will vary.  Some of them
may be quite productive, others may be undesirable.  It may be that none
of them are important enough that it's disastrous if GPLv3 code cannot
be used (there are, after all, large free software systems like *BSD,
and many smaller options, that could be deployed in such situations).

In any case, it should be clear to the developers and users of GPLv3
code, which of these things is and isn't allowed.

In our discussion we came across at least four ways that the ambiguity
surrounding CSKS could be reduced:

1.  Clarify the existing language: 

The scope of the language about key disclosure needs elaboration.  We
suggest the following words: "If such keys do not exist, you need not
provide them. But if they exist and you do not have them, you may not
propagate the Program".

In particular, this language is necessary to be clear that it is
permitted to distribute a device with the Program embedded in ROM. 

We are also a little concerned about the meaning of "the princpal or
recommended context of use".  Obviously, this is a concept of unclear
scope, and perhaps that is necessary.  At the very least we would
suggest changing it to _a_ "principal or recommended context of use".

In any case, the EFF would really really encourage the FSF to publish a
clarificatory list of activities (including cheat-resistant network
gaming, infiltration-resistant P2P file sharing networks, remote
attestation of rootkit scans, etc) that might be affected by the CSKS
clause, and whether GPLv3 code may be used in them.

2. Try to make the existing CSKS language more DRM-specific:

This is hard to do.  Some form of wording that makes the key sharing
requirement operate only "if a measure acts contrary to the legitimate
interests of the user, including interoperability and fair use".

3. Switch to an explicit prohibition on DRM:

Something like, "[if you propagate the Program as part of a system to
limit the decryption or reproduction of copyrighted works,] you must
give users all of the information necessary to make their own judgements
about which activities are ethical and likely to be permitted by
copyright law, and to modify the Program to allow those activities."

4.  Give up on the key sharing requirement.

This would probably reduce political disputes surrounding GPLv3, but it
is not clear that it would be a good way to proceed.

Anyway, I hope these ideas are of some non-zero usefulness, and good
luck with the final drafting!

-- 
Peter Eckersley                            pde at eff.org
Staff Technologist                Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://gplv3.fsf.org/pipermail/committee-d/attachments/20061025/e6b69164/attachment.pgp

From moglen at softwarefreedom.org  Thu Oct 26 09:04:36 2006
From: moglen at softwarefreedom.org (Eben Moglen)
Date: Thu, 26 Oct 2006 09:04:36 -0400
Subject: [Committee-d] Last minute comments on GPLv3-draft2
In-Reply-To: Peter Eckersley's message of Wed, 25 Oct 2006 19:08:20 -0700
	<1161828500.4219.68.camel@localhost>
References: <1161828500.4219.68.camel@localhost>
Message-ID: <17728.45668.621962.33922@new.law.columbia.edu>

Thanks, Peter,

I appreciate the comments very much. I think the WIPO reference might
indeed be a superior approach in section 3: I am currently reviewing
the opinions of counsel around the world we commissioned in order to
understand what form of statutory repulsion would work best.  

On the "keys as source" approach, I think we have all agreed it
probably should go, either for analytical or for political reasons.
We are now concentrating attention on adoption into GPL of a principle
that has a long history in the LGPL: a possible requirement on
non-source distribution that any GPL'd code in a functional
combination be user-replaceable to fix bugs or install a later
version, in any system in which the vendor retains or conveys to third
parties the power of after-sale modification.  Vendors want
knowledgeable corporate purchasers to be able to waive this right, but
influential vendors have conceded that this might be a good rule for
"consumer" devices.  RMS doesn't want to take the approach of
distinguishing consumer from non-consumer devices.  I'm not sure what
the last days of draft2 discussion will develop.

Best regards,
Eben

From brett at fsf.org  Tue Oct 31 09:14:23 2006
From: brett at fsf.org (Brett Smith)
Date: Tue, 31 Oct 2006 09:14:23 -0500
Subject: [Committee-d] Meeting today?
Message-ID: <20061031141423.GA14220@fencepost>

Is there anything people want to talk about?

-- 
Brett Smith
Licensing Compliance Engineer, Free Software Foundation