[09:14:22] --- ieft-wg-ipr has joined
[09:32:05] --- ieft-wg-ipr has left: Disconnected
[09:47:04] --- jjmbcom has joined
[10:08:51] --- jjmbcom has left: Disconnected
[18:21:15] --- hta has joined
[18:47:30] --- hta has left
[20:56:10] --- sbrim has joined
[20:56:13] --- Randy Gellens has joined
[20:56:29] --- Olaf has joined
[20:56:53] <Olaf> I will try to scribe here.
[20:56:59] --- jaap has joined
[20:57:15] --- petrescu has joined
[20:57:27] <Olaf> Lucy is explaining the IETF Trust.
[20:57:34] --- petrescu has left
[20:57:43] <Olaf> This will also be presented in the plenary
[20:58:10] <Olaf> IETF Trust founding document is almost been agreeed on.
[20:58:27] <Olaf> FAQ available on the "IAOC website.
[20:58:42] <Olaf> The FAQ is a living document.
[20:59:07] <Olaf> Trustees are subject to the conditions of BCP 101
[20:59:47] --- hartmans has joined
[20:59:58] <Olaf> Both ISOC and CNRI will put IETF IPR into the trust
[21:00:56] <Olaf> The explanation gets legally complicated and are now read from the slides.
[21:00:59] --- petrescu has joined
[21:01:34] <Olaf> A call for consensus will go out after the plenary. The closing date will be Nov 25th.
[21:01:53] --- hardie@jabber.psg.com has joined
[21:02:10] <Olaf> Questions:
[21:02:30] --- nov has joined
[21:02:36] <Olaf> no questions
[21:02:44] <Olaf> Anybody here has questions about the trust?
[21:02:51] --- becarpenter has joined
[21:02:55] <petrescu> Olaf is in the room.
[21:03:02] <Olaf> Next topic
[21:03:22] <Olaf> Main topic.
[21:03:36] <petrescu> slide: principles of what the IETF wants
[21:03:42] <Olaf> Harald t introduces the slides.
[21:04:35] <petrescu> slide: questions to answer.
[21:04:45] <Olaf> Core: information dissemination is good. but false representation [of IETF] is bad.
[21:05:34] <Olaf> Questions: What rights doe authors grant the IETF [incomming]
[21:05:50] <petrescu> slide: legally impossible
[21:05:50] <Olaf> What rights does the IETF grant others [outgoing]
[21:06:46] <petrescu> slide: obviously right.
[21:07:26] <Olaf> the right things: distribution of unmodified I-Ds and RFCs. Ability to use the standards.
[21:07:33] <petrescu> slide: obviously wrong.
[21:07:54] <Olaf> Wrongs: RFCs being modified. Implementations interoperable...
[21:08:11] <petrescu> slide: what can we do.
[21:08:19] <Olaf> What can we do.
[21:08:25] <Olaf> Scott Bradner is called to the stage
[21:08:50] <hartmans> To clarify, he said rfcs being modified and represented as the original. The distinction is important here
[21:09:20] <hardie@jabber.psg.com> He = harald?
[21:09:25] <Olaf> Scott explains that authors retain rights.
[21:09:59] <Olaf> authors can deny right to make derivative works.
[21:10:25] <hartmans> Ted, yes
[21:10:34] <Olaf> authors retain all rights...
[21:10:36] --- Glenn Parsons has joined
[21:10:38] <hardie@jabber.psg.com> Sam: thanks. Sorry I can't be there in person.
[21:11:01] <Olaf> Authors can turn this into any other form
[21:11:18] <Olaf> Scott explain that all RFCs deal with 'inbound' rights.
[21:11:59] <Olaf> The only place where outbound rights are dealth with are in one particular place.
[21:12:06] <Olaf> I missed where specifically
[21:12:22] <Randy Gellens> In update to legend on RFCs
[21:12:46] <Randy Gellens> which is in 2.3 of Scott's draft
[21:12:56] <Olaf> Thanks.. just did not parse the word
[21:13:25] <Olaf> Scot explains the history... starting with RFC1602
[21:14:17] --- Ed J. has joined
[21:14:20] <Randy Gellens> (But what about section 3.1 of Scott's draft? Doesn't that deal with 'outbound rights'?)
[21:15:20] <Olaf> as of 1602 there is a requirement for copyright notice.
[21:15:47] <Olaf> in 1602 the ietf is granted the right to make derivative work (inbound rights).
[21:16:05] <Olaf> RFC2026 changed this text slightly
[21:16:14] <Olaf> It added ISOC ...
[21:16:21] <Olaf> to make derivative works.
[21:16:51] <Olaf> There was discussion what 2026 did and did not permit.
[21:17:10] <Olaf> [out of scope for now]
[21:17:50] <Olaf> RFC3667 was a clarification.
[21:18:22] <Olaf> It added the _possibility_ to allow for translation (outgoing).
[21:18:51] <Olaf> RFC3667 sect 3.3 was intended to be clarification not a change
[21:19:10] <Olaf> There is a piece on outgoing rights which is only in the boilerplate.
[21:19:31] <Randy Gellens> (Ah, I understand why Scott answered my question the way he did: his section 3.1 deals with inbound rights to allow for outbound rights)
[21:20:18] <Olaf> draft-ietf-ipr-rules-update is about the right for the IETF to allow the creation of derivative works outside of standards process.
[21:20:30] <Olaf> Ack Randy
[21:20:38] <Olaf> that is what he just said, IMHO.
[21:20:41] <petrescu> Sam HArtman asks.
[21:20:52] <Olaf> [I did not get the question]
[21:21:15] <sbrim> got it?
[21:21:23] <becarpenter> is the grant transitive?
[21:21:29] <Olaf> Can we grant the right to derive work to other parties.
[21:21:39] <becarpenter> Jorge (lawyer): yes, if we want to
[21:21:50] <hardie@jabber.psg.com> If it is granted to us first, right?
[21:21:57] <becarpenter> Yes, of course
[21:22:02] <petrescu> DAvid Black: might be useful if operate in hier, it may be necessary to grant not only to IEEE, but may be to ISO, that's why need transitivity.
[21:22:15] <Olaf> The transitivity is needed to pass up grants from IEEE to ISO.. etc
[21:22:44] <petrescu> Brianm Carpenter asks:
[21:23:00] <petrescu> by removing that phrase you would allows us to choose between blanket or ...
[21:23:27] <becarpenter> or specific grants
[21:23:28] <Olaf> Questions from Scott:
[21:23:29] <hardie@jabber.psg.com> which phrase?
[21:23:41] <petrescu> don't know which phrase.
[21:23:41] <becarpenter> "case by case basis"
[21:23:53] <hardie@jabber.psg.com> thanks
[21:23:55] <sbrim> right
[21:23:59] <Olaf> Should the IETF get the right to grant the grit to make deriviative works outsind the IETF standard process.
[21:24:11] <becarpenter> grit indeed ;-)
[21:24:23] <Olaf> Should the ietf granting of this right be on a case-by-case basis or a blanket permission?
[21:24:41] <hardie@jabber.psg.com> I think it has to be a choice for the author. If we ask for it, and don't get it, we might still want to publish the RFC (as now)
[21:24:52] <Olaf> (If yes what are the criterea for these choices.)
[21:25:06] <Olaf> {Hardie do I need to proxy that comment]
[21:25:13] <hardie@jabber.psg.com> If we're humming already, I think granting the right should be case-by-case. Blanket presents serious problems, especially if blanket+derivative
[21:25:14] <becarpenter> ted: comments/discussion deferred till later
[21:25:20] <sbrim> The author would still retain the ability to choose the initial boilerplate.
[21:25:38] <petrescu> who's he speaking?
[21:25:46] <hardie@jabber.psg.com> olaf: apparently you should proxy it later...
[21:25:47] <becarpenter> randy gellens
[21:25:49] <hardie@jabber.psg.com> thanks :)
[21:26:14] <sbrim> Ted, this *allows* the IETF to grant the rights, but doesn't actually do so
[21:26:17] <becarpenter> btw ted I think you're correct,
[21:26:33] <becarpenter> best to have complete flexibilty
[21:26:49] <petrescu> Davis: is there any effect, should IETF cease to exist, will trust cease to exist?
[21:26:55] <sbrim> Ted and Brian could you be explicit so we can bring it up at the mike?
[21:26:58] <petrescu> Scott: trust is separate from IETF.
[21:27:32] <Olaf> Scott proposes a revised version without the 'case by case'
[21:27:38] <Olaf> sentence
[21:27:40] <becarpenter> Scott wants to call a question
[21:27:57] <Olaf> (plus a number of minor modifications)
[21:27:59] <becarpenter> Sorry, it's Harald's question
[21:28:16] <petrescu> Harald typed a question on the screen which is: please raise your hand for one of these alternatives:
[21:28:37] <petrescu> 1 the author shall grant the IETF the right to give others the right to prepare derivative works (outside the IETF process)
[21:28:42] <hardie@jabber.psg.com> (I can't come to the mic, as I am not in the room)
[21:28:54] <Olaf> I can proxy what you want to ask
[21:28:58] <petrescu> 2 the author shall not grant the IETF the right to give others the right ti prepare derivative works outside the IETF process
[21:29:59] <hardie@jabber.psg.com> olaf: Can I argue that it is appropriate to publish RFCs in both cases, where the author choose to grant that right where the author chooses not to.
[21:30:34] <hardie@jabber.psg.com> We can ask for this right, but in the case where we do not, the derivers need to get that right directly from the author.
[21:30:44] <hardie@jabber.psg.com> Does this make sense to others?
[21:30:48] <Olaf> i step up t the mike
[21:30:54] <hardie@jabber.psg.com> thanks olaf
[21:31:04] <petrescu> SH: we should not rule out blanket grants. And he has other agreements.
[21:31:30] <becarpenter> ted is being channeled...
[21:31:33] --- csp has joined
[21:32:22] <sbrim> the next step after this is that we will have to come up with objective criteria for granting derivative rights, or we'll be sued for some kind of discrimination
[21:32:47] <petrescu> SH: we would like be able to cut text from one std to another. complicated to manage transitivity.
[21:33:08] <hardie@jabber.psg.com> By std, do we mean IETF STD, or other SDO document?
[21:33:12] <sbrim> so the incoming rights should be standard
[21:33:31] <sbrim> they meant IETF ... other SDO ... that's interesting!
[21:33:37] <hardie@jabber.psg.com> They aren't standard now.
[21:34:02] <hardie@jabber.psg.com> There are author choices made. There isn't a full range.
[21:34:09] <hardie@jabber.psg.com> But there are multiple choices.
[21:34:14] --- csp has left
[21:34:17] <petrescu> hong li?
[21:34:19] <hardie@jabber.psg.com> Think of the documents we co-publish with ITU
[21:34:24] <sbrim> maybe link
[21:34:25] <sbrim> ling
[21:34:41] <hardie@jabber.psg.com> If we tried to grant transitive rights to those, or get these rights to those, we'd be S.O.L.
[21:34:51] <sbrim> Ted: very true. Do you want to be channeled again?
[21:34:52] <Olaf> Pekka: Can the IETF be responsible in giving out these rights?
[21:34:53] <hardie@jabber.psg.com> One size does not fit all.
[21:34:56] <hardie@jabber.psg.com> Yes, please.
[21:34:59] <petrescu> Pekka Savola: do we believe to be responsible in ... are we giving IETF too much rights, personally I don't think it's a problem.
[21:35:05] <becarpenter> Harald wants to call the question 1 v 2 v can't decide
[21:35:10] <petrescu> Scott Brim channels.
[21:35:18] <hardie@jabber.psg.com> Thanks, sbrim.
[21:35:38] <Olaf> S.O.L. (???)
[21:35:44] <sbrim> shit out of luck
[21:35:57] <petrescu> third alternative harald posts on screen: not enough information to answer.
[21:36:05] <becarpenter> sbradner thinks we never want to do that with itu again...
[21:36:14] <hardie@jabber.psg.com> "Never say never"
[21:36:23] <hardie@jabber.psg.com> I don't love these choices, friends.
[21:36:31] <sbrim> Ted: the only thing we've joint published was megaco and we've vowed never to do that again. But you're right, never say never.
[21:36:36] <hardie@jabber.psg.com> I think "Desire 1, accept 2" is a realistic alternative.
[21:36:52] <hardie@jabber.psg.com> That's not the only one I think.
[21:36:53] <Olaf> Rough consensus declared on the first suggested way forward.
[21:36:55] <becarpenter> hmm.. show of hands very stroing for requiring grant of derivative rights
[21:37:10] <sbrim> requiring *ability* to grant etc
[21:37:12] <hardie@jabber.psg.com> In the middle of two meetings, I can't dig though.
[21:37:39] <hardie@jabber.psg.com> I think Alex Zinin has brought forward others.
[21:37:42] <petrescu> slide: on copying conditions, SImon Josefsson of extundo.
[21:37:44] <becarpenter> ted: feeling that must get derivative rights for stds track
[21:37:50] <Olaf> Simon Jossefson speaks about outbound rights
[21:38:01] <petrescu> SJ implemented lots of RFCs.
[21:38:45] <Olaf> Simon disagrees on the interpretation of current RFCs.
[21:39:00] <Olaf> Simon will present examples
[21:39:31] <Olaf> Practical problems by not releasing rights to 3rd parties.
[21:39:43] <petrescu> slide: gnu/linux can't RFC because license is considered non-free.
[21:39:49] <Olaf> Debiuan would remove all expcerpts from RFCs in software.
[21:39:58] <sbrim> Debian
[21:40:06] <sbrim> as in Deb & Ian, the original creators
[21:40:20] <Olaf> (typo)
[21:40:50] <Olaf> FreeBSD 6.0 has a similar issue.
[21:41:01] <petrescu> slide: freebsd issue on dns resolver.
[21:41:05] <petrescu> SH approaching mike
[21:41:09] <Olaf> manpages such as getaddrinfo and getnameinfo are rewritten
[21:42:09] --- Glenn Parsons has left: Disconnected
[21:42:18] <Olaf> Also in openbsd the manpages are rewritten.
[21:43:09] <Olaf> Source code from RFCs should be modifiable.
[21:43:18] <Olaf> once it is implemented in open source
[21:43:36] <Olaf> LArge tables (strinbprep code points and MIME ...)
[21:44:25] <Olaf> Does the IETF want to grant rights to people in order to make such derivations.
[21:44:37] <hardie@jabber.psg.com> Modifiable for what?
[21:44:59] <petrescu> SJ: university course material.
[21:45:10] <hardie@jabber.psg.com> That's the key question--can you craft a license that grants derivative rights to modify them only in ways that support the standard (and the goal of interoperability)?
[21:45:16] <Olaf> David Black
[21:45:33] <Olaf> "Use of Field"
[21:45:33] <hardie@jabber.psg.com> without granting the right to modify them in ways that damage interoperability?
[21:45:43] <hardie@jabber.psg.com> Without a case-by-case determination?
[21:45:53] <Olaf> Proposal:
[21:45:57] <hardie@jabber.psg.com> (Could someone channel that set of statements when appropriate?)
[21:47:07] <Olaf> Sam Hartman argues that the proposed change does not work.
[21:47:17] <petrescu> SH: I"m an implementer, my code is used by lots of closed projects, this won't work for them, the reason being sometimes they have to things that first of all they need ability to fix bugs, in ours tastandrsds faster than we can.
[21:47:34] <petrescu> Sometimes market realities, fix bugs faster, sometimes does things beyond std.
[21:47:58] <petrescu> Scott: question on intent, you said change text of rfc, how do you mean? what is that you mean?
[21:48:15] <petrescu> DB: answers.
[21:48:35] <petrescu> DB: you put it out to the world with your implementation, for whatever your support purposes, documentation.
[21:48:54] <petrescu> DB: you should say "derived from".
[21:49:37] <petrescu> commenter: discussion soudned like - i implemented an rfc and write a document "here's how I implemented".
[21:49:39] --- hartmans has left
[21:50:10] --- becarpenter has left
[21:50:24] <hardie@jabber.psg.com> Many of these sound like commentary to me, as well
[21:50:41] <hardie@jabber.psg.com> (Here's where I departed from RFC XXXX, because it had a bug)
[21:50:44] --- hardie@jabber.psg.com has left
[21:51:18] --- Randy Gellens has left: Logged out
[21:51:26] <Olaf> Simon argues that 'field of use' is not complete
[21:51:43] --- nov has left
[21:51:49] <petrescu> Harald: official time is over but let's continue.
[21:52:26] <Olaf> Sam Hartman argues that anything that does not allow copying into GPL is a non-starter
[21:52:44] <Olaf> The discussion is closed because of time concerns.
[21:53:53] --- Ed J. has left
[21:54:01] --- jaap has left: Disconnected
[21:54:28] --- petrescu has left
[21:54:35] <Olaf> Brian concludes there are to many conflicting requirements.
[21:54:42] --- Olaf has left
[22:12:18] --- sbrim has left: Disconnected