<novalis_dt> Welcome.  We'll give everyone a couple of minutes to show up, then we'll start.
<dondelelcaro> if anyone wants to take a look at where I currently am with the drm/allowing authentication stuff, see http://svn.donarmstrong.com/don/trunk/projects/gplv3/issues/drm_allowing_authentication/drm_allowing_authentication.tex
<dondelelcaro> (there are some parts where comments may be ideal
<dondelelcaro> I've started the gobby server too

<novalis_dt> Wow, that's a long one.
<dondelelcaro> most of the tail end is just the comments that I'm going to discard
<dondelelcaro> http://archimedes.ucr.edu/ss/drm_allowing_authentication.pdf is the pdf if people don't like reading .tx
<dondelelcaro> s/tx/tex/
<novalis_dt> s/comment thread/common thread/
<novalis_dt> OK, let's get started.
<novalis_dt> First, we'll do a roll call, then we'll elect a coordinator.  I volunteer to coordinate again.
<novalis_dt> David Turner, FSF
<sedwards> Steven Edwards, Wine Project
<ZakGreant> Zak Greant, Foo Associates
<MarkDoliner> Mark Doliner, Gaim
<jblack> James Blackwell, Bazaar-NG
<fontana> Richard Fontana, Software Freedom Law Center
<massimotisi> Massimo Tisi, Politecnico di Milano, Italy
<dondelelcaro> Don Armstrong
<novalis_dt> I do see another few clients online, but they don't seem to have humans behind them.  Humans, when you go live, please let us know your name so we know that you're alive.
<novalis_dt> Great. Anyone else have a burning desire to coordinate?
<novalis_dt> OK, any objections to me coordinating?
<jblack> I don't object
<novalis_dt> Passed by consensus.
<novalis_dt> OK, first order of business: approve minutes from the meeting two weeks ago.
<novalis_dt> http://gplv3.fsf.org/discussion-committees/D/minutes/minutes_20060131
<novalis_dt> Er, that's not right
<novalis_dt> http://gplv3.fsf.org/discussion-committees/D/minutes/minutes_20060207
<novalis_dt> Anyone object, or are these approved?
<dondelelcaro> seconded
<novalis_dt> OK, approved by consensus
<novalis_dt> Next, everyone should take a look at Don's document.
<novalis_dt> Let's have a chat about that.
<fontana> A question:  Was there no committee meeting last week?
<dondelelcaro> http://svn.donarmstrong.com/don/trunk/projects/gplv3/issues/drm_allowing_authentication/drm_allowing_authentication.tex and http://archimedes.ucr.edu/ss/drm_allowing_authentication.pdf is the pdf if people don't like reading .tex
<novalis_dt> fontana: Correct.
<fontana> Okay.

>sourfron< we are contemplating Don's work on DRM:  http://svn.donarmstrong.com/don/trunk/projects/gplv3/issues/drm_allowing_authentication/drm_allowing_authentication.tex and http://archimedes.ucr.edu/ss/drm_allowing_authentication.pdf is the pdf if people don't like reading .tex
<novalis_dt> dondelelcaro: I must admit I hadn't thought of the API key issue.  And I'm rather on the fence about it.
<tomislav_medak> hello everyone, here's tomislav medak, Multimedia Institute
<tomislav_medak> late
<novalis_dt> welcome, tomislav_medak
<novalis_dt> One one hand, it can be used to control access to things which are rightly private (user databases, for instance).
<novalis_dt> The GPLv3 comment system does that.
<novalis_dt> On the other hand, it could also cut off significant functionality.
<mick_home> the whole DRM section worries me, because there are a lot of "legit" reasons to use DRM-ish applications
* soufron is a legal cake
<novalis_dt> mick_home: That depends on what you mean by DRM-ish.
<novalis_dt> mick_home: Can you give some examples here?
<dondelelcaro> novalis_dt: right, that's exactly the concern that I had as well, and one of the reasons why I hadn't yet been able to come up with a reasonable rewording of those sections
<mick_home> well, as it was brought up before - isn't using gpg to varify a binary DRM-ish
<mick_home> to disallow it from being installed
<novalis_dt> mick_home: I don't think so, because it's not trying to restrict what you can do.  You're the one who chooses whether or not to trust the unsigned binary.
<mick_home> if is altered in any way
<dondelelcaro> mick_home: yeah, that's pretty much what we're talking about here; but primarily in the context of user-overrideable verificiation
<novalis_dt> mick_home: I would describe that as using encryption and signing technology, but not as DRM.
<mick_home> ok
<jblack> The key point to me seems to be whether or not running software is disallowed if the signature isn't accepted. gpg signing things doesn't make that statement.
<mick_home> but in the case of nethack, that would be DRM - or not?
<novalis_dt> mick_home: Do you mean nettrek?
<mick_home> err, ya
<novalis_dt> dondelelcaro: Then, of course there are things in the middle -- credit card processing involves both software and databases of private data.
<dondelelcaro> novalis_dt: right
<dondelelcaro> novalis_dt: there's some difference between keys which a user would be expected to have their own individual one, and keys which would be required to deploy a modified version that wouldn't be required to deploy a non-modified one.
<novalis_dt> mick_home: I personally am unworried by nettrek-style authentication, because it's trivially circumventable.
<novalis_dt> dondelelcaro: Right.  And where the user is expected to have their own, I think the last sentence or so covers that.
<jblack> Imagine if Ubuntu only allowed the installation of signed packages.
<novalis_dt> "Notwithstanding this, a code need not be included in cases where use of the work normally implies the user already has it.
<novalis_dt> "
<novalis_dt> Can we take the API key issue first?
<dondelelcaro> sure
<novalis_dt> I think it is the hardest issue, and thus the most interesting.
<novalis_dt> fontana: Do you have thoughts on this?  I hadn't considered it, but perhaps you had?
<fontana> I hadn't considered it till now.
<mako> greetings
<novalis_dt> hi mako
<novalis_dt> So, one problem with trying to capture API keys in source code is that it gives API key makers an easy way to exclude GPL software from an API.
<MarkDoliner> It doesn't seem like an API key really restricts you from "installing and/or executing the source" or keeps you from "accessing or unsealing the work's output"
<MarkDoliner> If you had the program but not an API key, you can still run the program, or modify it, or redistribute it
<MarkDoliner> It's just a lot less useful
<novalis_dt> I would say it keeps you from executing the program ... such that its functioning in all circumstances is identical to that of the work...
<MarkDoliner> Hmm, yeah
<mick_home_> regarding DRM, i think it is similar to the p2p "problem" - that the MPAA has... yes there are legit reasons... but should we ban a technology/method and possibly prevent legit uses? Am I the only one who still doesn't see the difference between "using using encryption and signing technology" vs a DRM system. If I have a GPL system that allows for users to download apps, but they must be a...
<mick_home_> ...specific signed binary or it will refuse to install - this would be DRM?
 mick_home mick_home_
<novalis_dt> mick_home: It's a question of control -- who is ultimately in charge.  (Also, this is a bit off-topic for this second, since we're  presently discussing just API keys).
<mick_home_> sorry for the OT comment
<novalis_dt> No worries.  We'll get back to it soon enough.
<jblack> Ok. so an API key is an authentication agent for a remote service. Is there more to it?
<novalis_dt> jblack: Not really.
<mick_home_> k
<jblack> To which?
<novalis_dt> jblack: There's not really more to it that I can see.
<MarkDoliner> That's an interesting way to say it.  When you say it that way it sounds like it's basically a password
<dondelelcaro> jblack: I think that's one useage of it; there's a possibility that it also could apply to a local service as well, but I think that's getting into more of a dongle issue.
<dondelelcaro> (in which case the data on the dongle should be provided)
<novalis_dt> A dongle seems closer to traditional DRM.
<novalis_dt> Unless it also has useful functionality.
<jblack> I suppose one usage for an API key would certainly be software rentals and such.
<dondelelcaro> a dongle, just in case that's some wierd slang, I mean to refer to a hardware key used to unlock the functioning of a piece of software
<novalis_dt> But I don't think we're claiming that you have to provide source code to your scanner firmware just because you built your scanner driver on GPL software.
<novalis_dt> jblack: For remote software.
<MarkDoliner> It seems like the issue is, does the sentence "Notwithstanding this, a code need not be included in cases where use of the work normally implies the user already has it." cover API keys?
<dondelelcaro> MarkDoliner: I think you're getting at a good point there.
<novalis_dt> MarkDoliner: For zero-cost publicly available APIs, I would say that it could.
<dondelelcaro> perhaps just clarifying that last sentence would resolve the whole API key issue.
<novalis_dt> Just as an email client implies that a user has the password for their IMAP account.
<jblack> That seems to me to just shift the line a little bit.
<dondelelcaro> (honestly, the effect of that entire sentence had escaped me initially)
<novalis_dt> jblack: I agree.  I don't think we're cutting off Google here.
<novalis_dt> dondelelcaro: Which entire sentence?
<novalis_dt> the "implies that the user already has it" bit?
<dondelelcaro> novalis_dt: the "Notwithstanding this..." right.
<jblack> Hmmm. The trick to the API key is whether or not one is online. right? If the software can run offline...
<dondelelcaro> (sorry, have to grab some test tubes, back in a second)
<novalis_dt> dondelelcaro: We wrote that originally to handle Seth Schoen's Owner Override proposal, in the unlikely event that it was implemented.
<novalis_dt> dondelelcaro: But I see now that it is generally useful.
<novalis_dt> jblack: I think that at least right now the online case is the important one.
<jblack> Well, here's my thinking. There's this grey line about where the software is actually at.
<novalis_dt> jblack: The intent of that section was not to subtly extend copyleft over the web by effectively prohibiting people from charging money for web services where the clients for said services were GPL (or, alternately, preventing GPL software from using web services which have cost).
<jblack> If in part of doing key transaction with some remote api, I download to memory some core part of the code... Thats hard to deal with.
<novalis_dt> jblack: That actually seems straightforward to me.
<jblack> thats what I meant about the line just getting shifted.
<mick_home_> novalis_dt: so, an open source application couldn't use a web service that is closed source?
<novalis_dt> jblack: The source code to the bit you download will clearly count as source code for GPL software.
 mick_home mick_home_
<novalis_dt> mick_home: Well, the present language is quite unclear on this matter.
 mick_home mick_home_
<mick_home_> or specifically, at cost
<novalis_dt> mick_home: Well more specifically, with any sort of authenticator which must be kept private.
<mick_home_> since the google api is used extensively (as well as many other services) by open source apps
<novalis_dt> I suppose one could have a zero-cost system which requires authentication with a social security number :)
 mick_home mick_home_
<mick_home_> the google api has private "keys" - for example
<novalis_dt> mick_home_: That's what we're worried about.
<mick_home_> ok
<novalis_dt> OK, wait a second here.
<novalis_dt> What people who want to use the google API might do is build a local API proxy.
<mick_home_> ok
<novalis_dt> Then the GPL software has no authentication stuff in it.
<novalis_dt> It just makes requests to your local proxy.  And the local proxy is non-GPL (say it's simple permissive), and contains your keys.
<massimotisi> seems like cheating to me
<novalis_dt> massimotisi: Yes.
<novalis_dt> massimotisi:  But FSF has always said that a separate executable is a separate work.
<novalis_dt> At least in most cases.
<novalis_dt> And in this case, the API proxy could be quite generic.
<novalis_dt> At least, if SOAP authentication is standardized.
<novalis_dt> And this actually makes a good deal of technical sense -- it's not mere circumvention.
<novalis_dt> Because you *don't* want every crappy little app you download to have your passwords, because they will inevitably get broken into.
<novalis_dt> Instead, build a really good basket.
<mick_home_> i think what I am missing is, where is the borderline exactly as to what is/isn't allowed in this manner
 mick_home mick_home_

<novalis_dt> mick_home: In the case of separate executables?
<novalis_dt> mick_home_: It's defined by copyright law.  We've got theories about what that law is, but there's not a lot of case law in that area.
<dondelelcaro> pretty much anyone who tells you point blank what is or isn't a deriviative work is lying. ;-)
<mick_home_> i see
<novalis_dt> mick_home_: So, we're glad to tell you the theories, but I don't think it necessarily helps in this case to try to get that line brighter.
<mick_home_> heh
<novalis_dt> Since this is about API keys...
<mick_home_> yes, if you don't mind - I will sit back while you guys discuss this matter further
<mick_home_> as I don't want to hinder the discussion in any way
<novalis_dt> mick_home_: Sorry to keep cutting you off here.  Did you read the comment Don's document pointed to?
<novalis_dt> 370
<mick_home_> i'm mid-article
<massimotisi> novalis_dt: I don't like thinking that for distributing my free app I have to build a non-free server
<novalis_dt> massimotisi: No one said anything about non-free.
<novalis_dt> massimotisi: The proxy could well be free-but-not-GPL.
<novalis_dt> Or.
<novalis_dt> In the case of a generic proxy, the Notwithstanding clause applies.
<mick_home_> i have server issues in my project (failing hdd) - I'll idle here a bit, but I need to fix this asap (thanks for listening, and helping me understand the problems at hand)
<novalis_dt> I am hesitant to recommend this, of course.
<novalis_dt> (this -> the proxy solution).
<novalis_dt> But at least that does seem to clearly separate the proprietary-web-services case from the DRM case fairly cleanly.
<ZakGreant> Sorry to be away - bank robbery going on just a block from my house.
<novalis_dt> Actually, on reflection, every GPL program that uses the Google Web Services API will ask the use for their API key somehow.
<novalis_dt> ZakGreant: Lucky you!  A few months ago, we had one right next door.
<novalis_dt> So, I think that the Google API, at least, falls under Notwithstanding.
<dondelelcaro> right... so actually using the software will make it clear that the user has to actually have the key
<novalis_dt> dondelelcaro: Right.
<novalis_dt> Now, why is that not a loophole for, say, media keys?
<novalis_dt> That is, DRM-Player-1.0 (based on Xine), requires a media key, which can be purchased for $1 at participating Walmarts.
<dondelelcaro> yeah, that's a more difficult question
<novalis_dt> dondelelcaro: Of course, that's no problem if you can effectively modify DRM-Player-1.0.
<novalis_dt> (and continue to use the key)
<MarkDoliner> Indeed.  It's almost like linking a GPL program with a closed-source DLL
<novalis_dt> MarkDoliner: I don't think it's quite the same, since with the DLL, we think it's clear that a derivative work is being created.  In that case, we definitely want the source code.
<massimotisi> MarkDoliner: I haven't yet understood the difference, too
<jblack> I'd say its closer to using a GPL program to work with content you don't own.
<dondelelcaro> I think the critical question is whether or not the key is just a passphrase or is actually a functional part of the work
<novalis_dt> The difference between a Google API key and a DLL is that the API key enables access to something which is clearly a separate work under copyright law, while a DLL is, in our opinion, part of the same work.
<dondelelcaro> if it's just a passphrase, then it should always be possible to create a modified work that uses the key...
<novalis_dt> dondelelcaro: And if it's just a passphrase, what is it a passphrase to?  The program itself, some data processed by the program, or some external service used by the program?
<dondelelcaro> novalis_dt: I'd think it must be some external service used by the program, or used by the program to unlock some data...
<novalis_dt> dondelelcaro: excluding Remote Attestation, right?
<MarkDoliner> novalis_dt: Should those things you listed be allowed by the GPL?
<dondelelcaro> novalis_dt: you mean the "physical proximity" DRM thingie, right?
<novalis_dt> dondelelcaro: Er, no.
<dondelelcaro> sorry, I'm not fully up on the DRM lingo. ;-)
<novalis_dt> dondelelcaro: I mean the thing where a remote computer can ask your computer what software it is running.  It can refuse to ansewr, but it can't lie.
<novalis_dt> It's part of the Trusted Computing Group's specs.
<dondelelcaro> ah
<jblack> It would seem likely to me that if one is using free software, that the trusted computing's specs are likely already disabled, no?
<novalis_dt> The idea is that each machine has a certified implementation of the TPM, which signs the first-stage bootloader, which signs the 2nd-stage bootloader, which signs the OS, which signs applications.  Changing any one of these means that the signed data will end up different.
<novalis_dt> jblack: No.
<dondelelcaro> yeah, having the key do that (if that's what was meant) appears to make the key far more than just a passphrase; it means blocking modified versions by virtue of having a special key
<novalis_dt> dondelelcaro: The thing is that the key could just grant access to an ordinary remote service; the Remote Attestation bit happens at a different level.  The service refuses to run if (a) the keyi s wrong or (b) the software which is running has been modified.
<novalis_dt> MarkDoliner: I think we do want to allow access to remote services, even if those services are not in any way free.  But we don't want to open a loophole which allows GPL software to be made non-free using things like Remote Attestation.
<novalis_dt> Nobody's figured out how to solve the Remote Attestation issue.
<dondelelcaro> novalis_dt: right, but they key is then tied to a particular version of the software, instead of being a constant value...
<dondelelcaro> s/they/the/
<novalis_dt> dondelelcaro: No, the key being independent of the version.
<novalis_dt> Er.
<novalis_dt> I mean that there may be two keys, in essense.
<novalis_dt> One is not a key in the traditional sense, but the attestation that your computer is running the correct software.
<dondelelcaro> ok...
<dondelelcaro> I think if possible, we should clarify it to allow the key (as in the case of the google API) but dissallow keys that restrict the user's ability to modify the software
<novalis_dt> dondelelcaro: So, we don't much mind DRM, so long as it's guaranteed to be ineffective by virtue of not having a secret in hardware?
<novalis_dt> (A position I am inclined to support)
<dondelelcaro> novalis_dt: or at least be in a position of whoever has the passphrase can access the data, yes.
<novalis_dt> Right.
<MarkDoliner> dondelelcaro: My brain is only wrapped around 3/4ths of that, but it sounds like a good idea
<dondelelcaro> ok... now the question is how to modify the GPL (if it needs to be modified) to accomidate that
<dondelelcaro> my first inclination is to approach it from the angle of things the user must be able to do, as opposed to requiring that certain things be provided...
<novalis_dt> What if we add a 2nd Notwithstanding-type clause to say that keys which are used to give access to remote resources need not be included, so long as those remote resources do not affect the running of the remainder of the software?
<dondelelcaro> that's another possibility too
<dondelelcaro> I always have a hard time parsing notwithsanding clauses, but it could probably work.
<novalis_dt> dondelelcaro: They are sort of a double negative, yeah.
<novalis_dt> Perhaps we need a graphical map.
<dondelelcaro> heh
<dondelelcaro> that would be a first for a license. if you are in this section of the venn diagram, you're bad!
<novalis_dt> dondelelcaro: It would not be a bad idea to provide this separately, in the explanatory text. 
<MarkDoliner> You could color code it with green for good and red for bad, then you wouldn't have to worry about translating to other languages
<novalis_dt> We could even generate the text from the diagram...
<dondelelcaro> novalis_dt: yes... a good idea.
<dondelelcaro> and since graphviz is actually free now... we can use that (or dia).
<novalis_dt> I was thinking Inkscape, since it's so polished.
<dondelelcaro> ah... haven't used that recently
<novalis_dt> dondelelcaro: I am deeply in love with it.  But perhaps it just fits my brain well.
<dondelelcaro> novalis_dt: heh. cool.
<novalis_dt> OK, so Don, do you want to take on the task of drawing up the red and green lists, which we can discuss at a future meeting?  Once we have red and green lists, we can start generalizing and grouping, and then build language out of that.  Does this seem like a sensible course of action?
<dondelelcaro> sounds ok to me...
<novalis_dt> Great.
<jblack> If I may...
<novalis_dt> jblack: May what?
<dondelelcaro> it would be nice to if people could initially propose some suggested wording to those clauses on the mailing list too
<jblack> I just went over the draft real quick. I don't see where the contententious part is that prevents google api sorts of things.
<novalis_dt> dondelelcaro: I think it would help to lay out all of the scenarios before language gets written.
<dondelelcaro> novalis_dt: ok
<novalis_dt> jblack: "such that its functioning in all circumstances is identical to that of the work"
<jblack> I can see where code is protected, I can see where reverse engineering attempts are protected.
<dondelelcaro> jblack: basically, it's that part of 1. and the first bit of 3.
<jblack> I still don't see where that creates an obligation upon a third party.
<dondelelcaro> jblack: it's not the third party; it's an obligation on the distributor
<dondelelcaro> (or at least, it appears to be an obligation on the distributor)
<MarkDoliner> Because with the API key, the person who receives the program is not able to run it such that it functions identically
<MarkDoliner> Er, WITHOUT the API key
<novalis_dt> OK, any objections to moving on within Don's document?  I have a minor comment on the "execute the source code" bit.
<novalis_dt> Right, moving on.
<novalis_dt> I think that "execute the source code" is a distinct and separate issue from the rest of DRM.
<novalis_dt> Would it make sense to brief it separately, so that, in the event that the rest of the DRM suggestions aren't implemented, it doesn't get thrown out with the bathwater?  Or is it related in some way that I'm missing?
<dondelelcaro> novalis_dt: heh. yeah, I ran across that while drafting
<dondelelcaro> novalis_dt: yes, I agree that it should be separated out
* dondelelcaro just made a notation about it so he wouldn't forget about it... then proceeded to forget about it
<novalis_dt> OK, let's do that then.
<dondelelcaro> does someone want to take that? I think it should be pretty straightforard
<novalis_dt> Someone should take it now -- otherwise, we'll assign it to you :)
<dondelelcaro> (please take it, I beg you)
<novalis_dt> OK, I move that we assign it to massimotisi (determined by a random number generator).  Any objections?
<dondelelcaro> seconded
<dondelelcaro> (is anyone else alive?)
<massimotisi> ok
<novalis_dt> massimotisi: THank you.
<dondelelcaro> massimotisi: thanks!
<novalis_dt> OK, does anyone else have any comments on other areas of Don's document?
<novalis_dt> mick_home wanted to address the issue of keys generally. 
<novalis_dt> That is, section 2.1
<novalis_dt> Are we certain that the current text in fact excludes digital signatures?
<dondelelcaro> I can come up with interpretations of the text that include or exclude it... so...
<novalis_dt> dondelelcaro: Do you think it's an easy fix to make sure that it excludes it?
<dondelelcaro> novalis_dt: I haven't thought of a good way to make it obvious that user overrideable (or better, user replaceable) keys are ok; but I think that's all that it would take.
<novalis_dt> dondelelcaro: So, you think that the central question is whether the code is overrideable, rather than that it is used merely for authentication?
<dondelelcaro> yeah
<novalis_dt> I think that's probably correct.  In other words, we mean to draw a line between DRM and authentication based on whether the user is legally able to circumvent it and it is technically trivial to do so.
<dondelelcaro> FE, I don't really see a problem with encrypted transit mechanisms, so long as the user can implement their own transit mechanisms...
<novalis_dt> Right.
<novalis_dt> OK, so that's a subissue that at least we know what to do with (even if we haven't figured out quite how).
<dondelelcaro> (I think clarifying this would also deal with the initial reaction of Linus (and Linus apologists) too; but that's not really something I'm too owrried about)
<novalis_dt> I agree -- but I think that Linus has a deeper issue; his recent statements seem to be saying that code is law and that's OK with him because he's a great coder.
<dondelelcaro> heh.
<dondelelcaro> yeah, I'm personally not so sure if Linus really knows what he's going to do on this issue yet... it's not like he hasn't been bitten by this sort of thing before
<dondelelcaro> anyway; wildly OT there. ;-)
<novalis_dt> dondelelcaro: A bit.
<novalis_dt> OK, 2.3.  Do we think that the present draft in fact forbids GPG?
<dondelelcaro> I don't think so personally...
<dondelelcaro> but since I did see a bunch of comments on the issue, I felt it was something that should at least be adddressed, even if only in clarification/FAQ/rationale...
<novalis_dt> I agree that it ought to be addressed.
<novalis_dt> This is the line in question, I think: "It also includes any decryption codes necessary to access or unseal the work's output."
<dondelelcaro> right
<novalis_dt> For symmetric crypto, the Notwithstanding clause handles this.
<MarkDoliner> Hmm, maybe the whole DRM clause good be rewritten to say, "The 'Complete Corresponding Source Code' includes everything needed to allow the user to modify a work and to distribute/install/execute the work equally as if they were using the unmodified work."
<MarkDoliner> s/good/could/   (I'm a moron)
<novalis_dt> MarkDoliner: Wouldn't that mean that the source code of the unmodified work qualifies as source for the modified one?
<MarkDoliner> I don't know
<novalis_dt> dondelelcaro: Could we include asymmetric encryption by adding, "where such codes are not chosen by the user"?
<jblack> I think it does.
<dondelelcaro> novalis_dt: or perhaps where the user has not specifically requested the encoded output?
<dondelelcaro> (ie, the user should be able to get unencoded output if they want it)
<novalis_dt> dondelelcaro: Good idea, but not the ideal wording, I think.
<dondelelcaro> novalis_dt: yeah...
<novalis_dt> So, perhaps "unless the work also provides equivalent unencrypted output"
<dondelelcaro> or can be instructed to provide
<novalis_dt> Sure.
<dondelelcaro> I think that would cover that one... should we spin that one out into its own issue?
<novalis_dt> OK, so let's use that language for now, and we'll give it a final spit and polish once we see a later draft of the document.
<dondelelcaro> ok.
<dondelelcaro> (since it's related to the original issue, but not strictly so)
<novalis_dt> dondelelcaro: Right.
<novalis_dt> I think it resolves the issue, tho.
<dondelelcaro> since it's basically ready, I've no problem stewarding that one if we split it out
<dondelelcaro> novalis_dt: right.
<novalis_dt> dondelelcaro: It doesn't matter to me if it is split out.
<dondelelcaro> I guess the question is whether it matters to RMS. ;-)
* dondelelcaro doesn't care either way either.
<novalis_dt> dondelelcaro: I think it might make sense to combine it, since it ultimately favors his position.
<dondelelcaro> ok
<novalis_dt> dondelelcaro: So, it will act as ballast to anything which has to be toughened.
<dondelelcaro> cool; i'll clean that up.
<novalis_dt> This is likely not to matter much, but it's worth considering anyway.
<novalis_dt> OK, so let's adjourn this meeting, unless anyone has any last items?
<jblack> I've got mine
<novalis_dt> jblack: Which?
<jblack> let me pull it off the page
<jblack> The DRM is confusing issue
<novalis_dt> Oh, since that's on topic with don's stuff, let's consider that now, assuming everyone has the time?
<novalis_dt> (we'll break at 2400 GMT, in 20 minutes).
<dondelelcaro> I'm ok
<novalis_dt> OK, great.
<novalis_dt> jblack: Do you have some docs, or comments here?
<jblack> I've sorted out and parented the comments. It doesn't look good. Just as we thought, section 3 isn't understood.
<jblack> Thats in the "We don't get this!" sense, and not in the misunderstood sense.
<novalis_dt> jblack: Do you think that additional explanitory text external to the license would solve this?  Or are license text changes needed?
<fontana> jblack: Particular parts of section 3, or the whole thing?
<jblack> the whole thing.
<jblack> I think that a FAQ would do a lot of good in that direction, yes.
<jblack> I'm not sure that a FAQ address the issue completely though, as I imagine people expect to be able to come up with a sane interpretation
<novalis_dt> jblack: Do you have suggestions on how to reword it?
<jblack> I could work up a rewording for it, provided a lawyer goes over it.
<novalis_dt> jblack: Well, of course, all of this wording will be debated and redebated before it goes live.
<jblack> I suspect that its sentence length that does it.
<novalis_dt> jblack: I agree that RMS writes sentences that are longer than most people are used to.  I attribute this to his career as a lisp programmer.
<fontana> Section 3 is primarily Eben's work, I believe.
<dondelelcaro> heh. it's a good thing that I wasn't writing the license. I've been known to be quite horrific myself...
<jblack> Eben might have lost track of the average reading level of Americans.
<novalis_dt> Eben has no excuse -- a few years ago he said that his favorite programming language was Perl... because it reminded him of APL.
<jblack> Heh.
<fontana> Hey, this license isn't just for Americans. :)
<jblack> fontana: True enough, but we do want a sufficiently low common denominator.
<novalis_dt> Ok, so jblack will rewrite section 3 using words of no more than one syllable and sentences of no more than fifteen words.
<jblack> I'd like to avoid a decade of what 2b really means arguments
<dondelelcaro> novalis_dt: dunno; perl's got all the cool postfix operators like do_this_really_crazy_thing and this_other_thing or die "a flaming death" unless the_sun_is_red and g_is_greater_than_five;
<jblack> I don't think I can stick to one syllable words. I can minimize the usage of three and four syllable words.
<novalis_dt> If you need help, Seth Schoen is said to be quite good at "words of one beat".
<novalis_dt> dondelelcaro: True.
<novalis_dt> jblack: Great.  Let us know if you get stuck.
<dondelelcaro> novalis_dt: that's because he isn't automatically disqualified by virtue of his last name. ;-)
<jblack> I think we beat break time.
<novalis_dt> Don of the Strong Arm, that is not a hard task :)
<novalis_dt> (I once started translating T.S Eliot's The Waste-land into words of one beat.  I was doing fine until I hit "lacqueria", then I had to give up.)
<novalis_dt> OK, same time next week.  We'll discuss jblack's rewording.
<dondelelcaro> cool
<novalis_dt> Thanks, and a good evening to all.
<jblack> I suppose that if I substitute deal for license... makes up for constitutes...   :)
<fontana> deal suggests a contract :)
<novalis_dt> What about "grant" for license?
<fontana> grant is okay.
<tomislav_medak> bye everyone, i was just sitting there, trying to keep up with the lingo and issues
<jblack> I was actually trying to be silly...
<tomislav_medak> sorry, not the greatest contributor :-(
<novalis_dt> tomislav_medak: Would it be easier for you to follow on a mailing list?
<dondelelcaro> we probably should consider doing more on the mailing list, since I can see that non-native speakers may have a problem following in realtime at speed...
<dondelelcaro> esp. when there are more than one of us who can type faster than they can actually think...
<massimotisi> novalis_dt: about my issue, have I to deal only with the wording problem: "source code isn't executed" ?
<novalis_dt> massimotisi: Right. 
<tomislav_medak> no, i don't think so,'ll just have to do a more detailed preparation. some technical aspects are new to me...
<novalis_dt> massimotisi: It presently says "source code is executed".
<novalis_dt> massimotisi: But in most systems, *object* code is executed.
<novalis_dt> "Complete Corresponding Source Code also includes any encryption or authorization codes necessary to install and/or execute the source code of the work" ...
<novalis_dt> In section 1.
<novalis_dt> I think there may be a related comment...
<massimotisi> novalis_dt: of course, I see that commeettee A has put all the wording problems of that section to a single issue (881)
<novalis_dt> 837
<novalis_dt> massimotisi: Ah, yes.
<novalis_dt> massimotisi: We can subdivide things however we like.
<novalis_dt> And our subdivision can be different from Committee A.
<massimotisi> novalis_dt: ok
<novalis_dt> But since you are taking 837, you should upgrade it to an issue yourselfg.
<novalis_dt> massimotisi: Does that make sense?
<massimotisi> sure, I hope that Idra doesn't get too angry
<novalis_dt> massimotisi: Idra is from another committee.  It is expected that different committees will divide things up differently.
<novalis_dt> Since every committee has a different perspective, everyone's comments are valuable.
<massimotisi> novalis_dt: now it's clear. Another question, what about the voting for the new members ?
<novalis_dt> massimotisi: Oh, that completely slipped my mind.
<novalis_dt> The two proposed members are listed online.
<novalis_dt> I'll close those tomorrow and send a note to the list.
<massimotisi> ok
<dondelelcaro> is there anything else or can we motion to adjourn?
<massimotisi> adjourn
<ZakGreant> second
<tomislav_medak> bye
<novalis_dt> passed by consensus