[Committee-d] Today's meeting

[Brett Smith]

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.