00:02:46 noah has joined #tagmem 00:14:35 marcosc has joined #tagmem 00:53:08 dka has joined #tagmem 01:20:45 annevk has joined #tagmem 01:57:27 dka has joined #tagmem 02:00:24 annevk_ has joined #tagmem 02:33:39 marcosc has joined #tagmem 03:00:21 marcosc has joined #tagmem 03:00:56 marcosc_ has joined #tagmem 03:27:35 marcosc has joined #tagmem 03:27:53 noah has joined #tagmem 03:43:46 annevk has joined #tagmem 04:52:43 marcosc_ has joined #tagmem 05:19:32 marcosc has joined #tagmem 07:35:33 darobin has joined #tagmem 07:58:46 marcosc has joined #tagmem 08:17:22 Zakim has left #tagmem 10:26:18 dka has joined #tagmem 10:34:46 JeniT has joined #tagmem 11:28:22 dka has joined #tagmem 11:44:11 dka has joined #tagmem 12:35:18 JeniT has joined #tagmem 12:36:53 dka has joined #tagmem 12:51:49 trackbot, this will be tag 12:51:49 Sorry, dka, I don't understand 'trackbot, this will be tag'. Please refer to for help. 12:51:54 rrsagent, this will be tag 12:51:54 I'm logging. I don't understand 'this will be tag', dka. Try /msg RRSAgent help 12:51:56 ;alkyd;alksd 12:52:06 trackbot, start meeting 12:52:08 RRSAgent, make logs public 12:52:08 Zakim has joined #tagmem 12:52:10 Zakim, this will be TAG 12:52:10 "TAG" matches TAG_f2f()8:30AM, and TAG_(AWWSW)9:00AM, trackbot 12:52:11 Meeting: Technical Architecture Group Teleconference 12:52:11 Date: 01 October 2013 12:52:25 darobin can you join us this morning? 12:56:08 twirl has joined #tagmem 12:56:54 ohai 12:57:12 dka: I can join in ~10min, for about 30-45min 12:57:53 after that I'm off to tell the lovely people of Lyon how much they'd enjoy making standards 12:59:19 I'm on my way, fyi 12:59:25 Is Alex already there? 12:59:43 not yet 12:59:52 bor anne 12:59:54 OK I am at his hotel waiting for him 12:59:57 s/bor/nor/ 13:00:00 Ok - we really need to start shortly due to Philippe's schedule. 13:00:18 Anne's here 13:00:42 Suggest you come over - maybe you can ring up to Alex's room? 13:00:59 I texted him 13:03:40 ok we have Philippe until 10:30 so we can wait a few minutes 13:04:00 zakim, what is the code? 13:04:00 sorry, dka, I don't know what conference this is 13:04:05 zakim, this is tah 13:04:05 dka, I see TAG_f2f()8:30AM in the schedule but not yet started. Perhaps you mean "this will be tah". 13:04:10 zakim, this will be tag 13:04:10 "tag" matches TAG_f2f()8:30AM, TAG_(AWWSW)9:00AM, and XML_(TAG TF)10:00AM, dka 13:04:22 zakim, start teleconference 13:04:22 I don't understand 'start teleconference', dka 13:04:34 Robin we are on 0824 13:05:05 zakim, who is on the phone? 13:05:05 has not yet started, plinss 13:05:06 On IRC I see twirl, Zakim, dka, JeniT, marcosc, darobin, dglazkov, projector, RRSAgent, Yves, plinss, slightlyoff, wycats_, bkardell, trackbot 13:05:08 plh has joined #tagmem 13:05:15 zakim, list conferences 13:05:15 I see SW_DPUB-IG()11:00AM, Team_(MEET)8:00AM, TAG_f2f()8:30AM active 13:05:16 also scheduled at this time are MM_MMI(Discovery)9:00AM, Team_(RevCadence)9:00AM, SW_SWSTR()9:00AM, TAG_(AWWSW)9:00AM, IA_Team()9:00AM, UW_WebTVIG()9:00AM 13:05:20 zakim, this is f2f 13:05:20 ok, plh; that matches TAG_f2f()8:30AM 13:05:36 zakim, aaaa is F2F_Room 13:05:36 +F2F_Room; got it 13:06:03 zakim, F2F_Room holds Dan, Peter, Tim, Serguey, Yves, Henry, plh 13:06:03 +Dan, Peter, Tim, Serguey, Yves, Henry, plh; got it 13:07:09 rrsagent, generate minutes 13:07:09 I have made the request to generate http://www.w3.org/2013/10/01-tagmem-minutes.html plh 13:07:53 Chair: Dan, Peter 13:08:24 zakim, F2F_Room also holds Anne, Yehuda 13:08:24 +Anne, Yehuda; got it 13:08:28 annevk has joined #tagmem 13:09:16 zakim, passcode? 13:09:16 the conference code is 0824 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), plh 13:09:24 +[IPcaller] 13:09:33 Zakim, [ is me 13:09:33 +darobin; got it 13:10:30 -F2F_Room 13:11:19 +F2F_Room 13:11:49 -darobin 13:11:59 +[IPcaller] 13:12:25 zakim, F2F_Room holds Dan, Peter, Tim, Serguey, Yves, Henry, plh, Anne, Yehuda 13:12:25 +Dan, Peter, Tim, Serguey, Yves, Henry, plh, Anne, Yehuda; got it 13:12:39 -darobin 13:12:44 -F2F_Room 13:12:45 TAG_f2f()8:30AM has ended 13:12:45 Attendees were +1.617.715.aaaa, Dan, Peter, Tim, Serguey, Yves, Henry, plh, Anne, Yehuda, [IPcaller], darobin 13:15:04 zakim, F2F_Room also holds Noah 13:15:04 sorry, plh, I do not recognize a party named 'F2F_Room' 13:15:52 Present: Dan, Peter, Tim, Serguey, Yves, Henry, plh, Anne, Yehuda, Noah, Robin 13:16:15 noah has joined #tagmem 13:17:52 noah has joined #tagmem 13:18:02 scribenick: noah 13:18:12 [Polyglot has an update about to be published: http://dev.w3.org/html5/html-xhtml-author-guide/] 13:18:13 topic: HTML5 13:18:35 We have Philippe le Hegaret visiting in person and Robin Berjon on the phone 13:18:50 JeniT has joined #tagmem 13:18:54 HT: Proposed topics RDFa, polyglot, authoring spec, mediat type 13:18:57 [RDFa isn't us, but Microdata is more or less in a bad state it would seem] 13:19:13 TBL: Is it appropriate to talk about proposed solution to the Web IDL problem 13:19:21 AVK: DRM? 13:19:48 HT: EME = Encrypted Media Extensions are actually going into the browsers 13:20:06 [the TAG brainstormed about DRM last time (or the time before?), did anything come of that?] 13:20:37 PLH: EME is in HTML WG pushed by Web & TV interest group. 1.5 years work in HT L wg subgroup. 13:20:46 s/HT L/HTML/ 13:21:08 PLH: Microsoft, Netflix and XXX are active and contributed editors to the specification 13:21:16 s/XXX/Google/ 13:21:23 PLH: Use case is ability to play back protected premium content 13:21:27 s/XXX/Google/ 13:22:05 PLH: Want you to be able to interact with platform's Content Distribution Management system (CDM), which provides whatever actual DRM, possibly HW or SW 13:22:31 PLH: You can also use the API for less constrainted systems, but in practice browser vendors are implementing to use underlying platform 13:22:50 PLH: Mozilla is said to be working on this but their detailed plans aren't clear to me. Henri Sivonen is involved from Mozilla 13:23:00 HT: Google means Webkit? 13:23:05 Several: No, blink 13:23:55 PLH: (scribed missed some details about MPEG Dash?) 13:24:06 HT: Is the CDM target exclusively Windows? 13:24:14 PLH: No, Apple as well 13:24:19 HT: Linux? 13:24:42 PLH: Well, if you want some content on Linux, there are providers who require DRM. 13:25:26 YK: Jeff's opinion last time, with which I disagree, is that it could run on Linux should the community wish to do it. I (Yehuda) think most agree that the necessary support won't be on Linux in practice. 13:25:49 DA: Why can't others write it for Linux 13:25:56 YK: You won't get certs 13:26:03 TBL: Too many assumptions here 13:26:20 YK: OK, I retract, but I'm betting Netflix won't publish to Linux without DRM 13:26:45 TBL: Why? 13:27:44 TBL: There are lots of possible architectures. The problem with building it this way is that it depends on support from machine manufacturer. You could imagine, for example, built into the LCD that does the decryption. You could image a band publishing music, some free some priced. 13:28:21 TBL: You could imagine a deployed infrastructure for deploying the keys. For the musician, likely preferable to having control of keys so centralized. Moving to a more open market is desirable. 13:28:44 q+ 13:28:55 YK: I'm not saying we will necessarily not have DRM on Linux, I'm skeptical that companies with content like Netflix will publish to it. 13:29:47 q+ to talk about potential reform action 13:29:59 TBL: False assumption that there is only one CPU. Phones have many e.g. I have root access on my Mac and can install open source on it. It's not easy for me to copy something downloaded using iTunes. I know/suspect the machine also has subsystems to which I don't have access. 13:30:45 ack plh 13:31:04 timbl has joined #tagmem 13:31:24 q? 13:31:41 ack da 13:31:41 darobin, you wanted to talk about potential reform action 13:31:46 PLH: Today, to watch Hulu or Netflix you need a Flash plugin. If EME works right, then no need for plugin. Now there's a burden on browsers to work with the platform, and this is especially problematic for open source systems. 13:31:49 logger, pointer 13:31:56 logger, pointer? 13:32:09 RRSAgent, pointer? 13:32:09 See http://www.w3.org/2013/10/01-tagmem-irc#T13-32-09 13:32:15 q+ to ask about the distinction between built-in EME and built-in Flash 13:32:45 RB: Media is just the tip of the iceberg. We need to anticipate requests for protection of Apps, Books, media. Wondering whether the TAG could help push on question of Web-compatible copyrights. 13:32:58 DA: Bookmark that thought 13:33:32 PLH: So, no plugin, but browser has no control over underlying DRM systems, e.g. issues like accessibility. 13:34:49 HT: The well argued >technical< objection is that it is a step toward taking control of the platform away from the owner. That's the key problem. We are making a link in that chain easier, but the deep evil (if you believe it's evil) is further down the chain 13:34:55 PLH: It's a small step 13:35:03 q? 13:35:06 q+ 13:35:06 ack wycats 13:35:07 wycats_, you wanted to ask about the distinction between built-in EME and built-in Flash 13:35:51 YK: I see benefits of standard thing with standard interface. I wouldn't like it but can see benefit. I'm not convinced EME is better than plugin. 13:36:17 PLH: You would not have to ship flash, reduces browser footprint 13:36:23 YK: Do you think that will happen 13:36:26 [with EME you push the plugin further down the stack and reduce its surface compared to Flash] 13:36:32 PLH: Yes, streaming etc would need to be addressed 13:36:32 AR: necessary but not sufficient 13:36:33 q? 13:36:53 q+ to say even small steps are symbolically significant 13:37:33 PLH: I'd guess EME will show on mobile platforms over time 13:37:48 ack anne 13:37:49 q? 13:38:27 AVK: We never standardized the plugin API, and we know plugins have problems. Now we're opening an extra hole. 13:39:12 YK: At least with Flash you could implement it yourself in principle. With EME it's not clear that you can. 13:39:15 ht has joined #tagmem 13:39:26 AVK: Standardizing this seems counter to the W3C's mission 13:40:04 q? 13:40:13 to be clear, I didn't mean that you could implement the DRM part -- what I meant was that you could implement FLASH yourself 13:40:39 TBL: That's a complex discussion 13:40:40 so the undocumented EME API is worse than the undocumented Flash API as it relates to the web content that each of them is enabling 13:41:08 AVK: I am worried about the Web depending on proprietary technologies not easily ported to other platforms. 13:41:20 Robin Berjon thanks the group but has to leave. 13:41:43 ack noah 13:41:43 noah, you wanted to say even small steps are symbolically significant 13:41:53 q- 13:41:55 For me, the nut of the issue is that new browsers will not be able to run "web content" without a non-trivial amount of non-technical work 13:42:08 +1 to wycats_ 13:42:14 thanks darobin ! 13:42:46 wycats_: that seems like a no-op vs the current state, no? 13:42:54 PLH: Regarding Web IDL: it's a metasyntax for writing specifications. Within a few years we'll use that either Web IDL or JS IDL. 13:43:02 q? 13:43:08 slightlyoff: the current state is not in a standard -- so the current content is not "web content" and we're honest about it 13:43:19 the claimed benefit of the new state is that it can be described as "web content" 13:43:26 except it's not actually 13:43:40 I accept the semantic distinction. 13:43:46 PLH: Some groups are using the full semantics of WEB IDL but older stuff doesn't support that. 13:43:50 this conversation is nuanced... we should have it in person 13:44:17 PLH: Both Geolocation and Touch Events claim to be using ECMAscript bindings, but when it gets to things like prototypes it doesn't work. 13:44:22 AVK: Browser bugs? 13:44:42 I totally disagree that these are just "browser bugs" 13:44:54 YK: Yes, but it's not that simple, even browser vendors have trouble knowing what's right. Ordinary users have no chance. 13:45:03 type conversion is also overlook 13:45:24 PLH: Leads to a situation where specifications lose credibility because don't match reality. Conformance tests fail. 13:46:05 JeniT has joined #tagmem 13:46:17 PLH: The incentive to fix isn't strong enough. 13:47:22 YK: I agree that in principle this stuff tends to be edge cases, but I have spent say 100 hours of my career burning time figuring out such mismatches between spec and reality. Getting the specs to where they are an accurate guide to practical reality is important (scribe has paraphrased) 13:47:33 q? 13:47:59 AVK: Don't follow. You want specs to say where implementations will go, not where they are. 13:48:04 TBL: Anne, delighted to hear that! 13:48:13 YK: Not making strong statement on that distinction 13:48:33 q+ 13:48:40 AVK: Mozilla uses Web IDL for geolocation 13:48:55 AR: Chrome doesn't always follow the IDL 13:49:07 AR: Is the issue that prototypes aren't be linearized? 13:49:14 YK: Part of the problem 13:49:44 AR: We in chrome never have performance regression, and have spent years figuring out how to linearize prototypes. So far, haven't found a way that performs. 13:49:47 TBL: Eventually? 13:50:11 AR: Eventually we should be able to do it except maybe for some real edge cases 13:50:55 YK: I'm on chrome going to monkey patch an event target, and on another platforms may not work 13:51:12 AVK: We've had WEB IDL based stuff since forever 13:51:19 AR: Yeah, done by hand 13:51:26 s/WEB IDL/IDL/ 13:52:00 s/done by hand/it's a pain to do it by hand/ 13:52:05 AVK: Then we moved to Web IDL and some did it piecemeal (Chrome?). We are trying for the whole thing, but across browser versions it's a huge job. Real interop will take you a long time. 13:52:27 YK: So, your view is WEB IDL documents ideal reality, and it's just taking a very long time for real reality to catch up? 13:52:31 AVK: Yes 13:52:42 q+ 13:52:45 YK: I have more optimism that it's a few years, but not decade(s) 13:53:13 queue=timbl, plh 13:53:27 YK: Some things like that some browsers require capture flag and some don't really does bother developers. We play lip service to interop 13:53:36 AVK: Pressure for new features 13:53:39 q- 13:53:48 YK: Maybe, the HTML5 parser was welcomed for improving interop 13:54:46 AR: WEB IDL is high fidelity but to the wrong ideal 13:55:04 YK: But PLH was asking is there enough info there, if so, then browser vendors please prioritize 13:55:05 q? 13:55:27 TBL: So, we have specs that are not really WEB IDL compatible but still use WEB IDL to list parameters 13:55:32 YK: Does prose tell you 13:56:27 TBL: I'm saying it's being used just for the parameter list, with no implication that there are prototypes, setters, getters etc. They are usefully using as a descriptive. 13:56:48 Several: Whoa, there are specifications saying that things like getters and setters >are< implied 13:57:20 TBL: So, let's say the don't have getters and setters, should they not use WEB IDL and instead use something else, or should they say they're using WEB IDL in limited way. 13:57:30 AR: First, do you think the API without getters/setters is good 13:57:56 TBL: Right now, they are trying to document a spec that for better or worse does not intend to have getters and setters 13:58:04 ack plh 13:58:52 PLH: So, today the protoypes are being followed by all execpt Webkit and Blink. Mozilla and Microsot are doing what they reasonably can. 13:59:11 JeniT has joined #tagmem 13:59:23 PLH: We need to make sure specs describe deployed reality even if later we hope to improve implementations 13:59:53 TBL: Is it pragmatic for them to use the WebIDL syntax? 14:00:21 AR: Two issues. A) Carries implications that to which they are not signing up, so misleading B) It's going to mislead implementors 14:00:28 q? 14:00:39 TBL: The implementations were done "without thinking" in the sense of without attending to Web IDL 14:01:14 AR: If you are attempting to describe a Javasript interface that doesn't match WEB IDL, use Javascript to describe it 14:03:23 AR: Insofar as Javascript is a poor description language, that's on TC 39 to fix. It is however to write out an interface description, e.g. with a dummy implementation, that can meet the need 14:03:43 PLH: There are a few like that, maybe Web storage 14:03:53 TBL: Or you could clone WEB IDL and rip out pieces 14:04:16 YK: People have enough problem reading/learning WebIDL. Subset version adds confusion. 14:04:40 Someone: so, the browsers are on the road to fixing the APIs 14:04:51 PLH: But doing things like adding getters is very low priority 14:05:06 YK: I can live with that. Web IDL is the desired reality, fixing bugs is low priority 14:05:37 TBL: Not OK. When bugs are likely to be open for ten years, then that's not OK because specs aren't affecting reality 14:05:39 plh: http://mxr.mozilla.org/mozilla-central/source/dom/webidl/Geolocation.webidl 14:05:46 YK: Really going to take ten years for geolocation 14:05:50 AVK: No 14:06:04 YK: So? 14:06:17 TBL: I think I'm hearing browser vendors don't want to fix some of these bugs 14:06:46 YK: I'm more optimistic that implementations are converging on the spec faster than that 14:07:45 DA: Does this fit into bucket of "TAG provides guidance to working groups"? If so, what guidance. 14:07:52 TBL: I think the deep dive here is valuable. 14:08:11 TBL: Popping back up might lose that value 14:08:25 YK: I think we can get behind saying "standards should drive interop" 14:08:40 DA: But TAG can get involved at detail level as we did with Web audio. Anything like that here? 14:09:22 AVK: The geolocation group is "run" by two people who work on Blink, so they are likely to give the corresponding answer 14:09:30 AR: If it's only geolocation, then we can fix this 14:09:50 AVK: I assume they felt that fixing this wasn't consistent with getting to REC in a timely way 14:10:18 AVK: We >want< the prototype and we want it interoperable 14:10:38 YK: Would be useful to know why blink isn't doing it. Was there a deep reason making it really hard, or just didn't push hard on it? 14:10:43 AVK: What's a long time? 14:10:51 YK: Having a spec not interoperate for multiple years 14:10:57 AVK: We have several 14:11:47 YK: We should consider avoiding publication of specs likely not be interoperable for extended periods 14:11:55 plh: do you have a pointer to the discussions about this? 14:12:21 q? 14:13:07 q+ 14:13:11 JeniT has joined #tagmem 14:13:18 hey JeniT! 14:13:52 NM: If you're going to write specs that cover ideal behavior and interim, can be useful to give them formal distinction as differently named conformance levels. 14:13:55 ack slight 14:14:15 AR: Confused. Of what substantive issue is geolocation an example. 14:14:51 http://dev.w3.org/geo/api/idl-test-suite/idlharness.html 14:15:12 PLH: Well touch events is more clearcut, but considering geolation, the specification says the XXX object must be supported on the navigator interface, but it is not. 14:15:40 AVK: Makes sense, because navigator was complex and took a long time to convert. 14:16:15 To be clear, Firefox Nightly passes that test 14:16:19 AR: When geolocation was published, WEB IDL was only a working draft. What is the core issue, that Blink isn't linearizing prototypes, or is there an issue unique to geolocation? 14:17:53 PLH: I now see that something told to the director was unduly pessimistic. We thought we heard there were not two implementations because IE passed but Firefox failed IDL compliance. We now hear that was a short term concern, bug fixed, and so we do have two implementations. 14:18:31 PLH: The touch events one was also presented to (Tim). Looked at running on both Firefox and Chrome mobile. There were pieces of a test failing (scribe isn't sure he got this right) 14:18:40 slightlyoff_ has joined #tagmem 14:18:44 TBL: Can you do touch evens with trackpad on desktop 14:18:53 PLH: In principle, but I can't check that mysefl 14:19:02 s/mysefl/myself/ 14:19:25 AVK: If someone had checked the Firefox bug database they would have seen the fix was on the way. 14:19:26 slightlyoff_ has joined #tagmem 14:19:34 PLH: We somewhat trust the WGs 14:19:56 AVK: Not clear this WG has deep insight into implementations other than Blink 14:20:25 PL: Did I hear someone concerned about need to express things beyond what WEB IDL can do? 14:20:44 YK: Well, I heard Tim speculate that if Web IDL semantics not right for all, the syntax might still be used. 14:21:18 I will note: we have talked about 3 APIs this morning - Geolocation enables access to an underlying capability of the device which may be implemented using a patent-encumbered technology (GPS); Touch events enables access to an underlying capability of the device which may be implemented using a patent-encumbered technology (multi-touch); EME enables access to an underlying capability of the device which may be implemented using a patent-encumbered technology (some 14:21:18 underlying DRM). 14:21:21 TBL: They came to me and asked about syntactic conformance (just matches Web IDL grammar). I said "no", we need syntax and semantics here 14:22:44 PLH: Touch events is a bit tricky. IE doesn't implement. 14:23:04 YK: What's the status of the patents 14:23:34 PLH: There is a PAG. 14:23:41 YK: Aren't we moving to pointer events? 14:24:03 PLH: Yes, but there is deployments of Touch Events so they want a 1.0 rec 14:24:22 YK: But not likely to get much attention in the future? Then I don't care about Web IDL so much. 14:24:33 AVK: But I care, because we do it with Web IDL 14:24:40 AR: What's the issue? 14:24:44 http://w3c-test.org/webevents/tests/touch-events-v1/submissions/Nokia/idlharness.html 14:24:55 YK: Should touch events become a REC if not describable by suitable IDL 14:25:34 YK: Given that Web IDL is part of the spec, we don't have interoperable implementations of touch events 14:26:10 DA: Is this a TAG issue? Unconvinced. 14:26:29 q? 14:26:33 YK: Broader issue is whether WEB IDL semantics are important when considering interoperable implementations? I think we agree: yes. 14:26:39 PLH: Anything else in remaining 4 minutes. 14:26:48 HT: I want to know where we are on Polyglot 14:26:55 PLH: HTML WG is publishing it. 14:27:08 HT: Henri had an objection 14:27:13 PLH: I think it's moving forward 14:27:31 PLH: As long as someone is willing to do the work it will move forward. 14:30:25 PLH: On other things: RDFa went to rec awhile ago; on microdata it's going to note 14:30:39 PLH: We're doing the same with Authoring spec 14:31:07 agenda+ auhoring spec 14:31:08 NM: We had a clear, negotiated agreement with HTML WG chairs that authoring spec goes to REC. please check the record from a couple of years ago. 14:31:13 DA: I agree with Noah 14:31:16 PLH: I will check 14:31:20 http://www.w3.org/2013/09/html-charter.html 14:32:26 http://www.w3.org/blog/news/archives/3253 14:32:39 PLH: The HTML WG got a new charter yesterday with two new things 1) new dual license which can be used for extension specifications 14:33:00 PLH: The DOM4 specification was moved into HTML WG also announced yesterday and can get cc: by license 14:33:22 s/The DOM4/2) The DOM4/ 14:34:08 AVK: I am concerned that the cc: by license is non-GPL compatible. 14:34:22 AR: I'm unhappy disucssing document licenses for software 14:34:41 Plh: an example is: Is Anne willing to edit the DOM specification in the HTML WG under the new dual license? 14:34:51 Anne: no, because it's compatible with GPL 14:35:05 s/compatible/incompatible/ 14:35:10 TBL: There are some people in this discussion who have taken the trouble to be quite pedantic about it. The notion that GPL would be incompatible with cc: by is a bit pedantic. 14:36:19 AR: You can't drill on this without asking who would sue whom and why? Who owns the rights? If these are rights granted to the Free Software Foundation, they may be litigious. I think it's less likely that W3C or Mozilla will. There are multiple potential ways to solve this. One might be a covenant not to sue. 14:36:52 PLH: We published a FAQ. Our legal people believe that in this particular case your use of cc: by is compatiable with GPL. 14:36:56 YK: How do you link a spec. 14:37:09 AVK: Given that FSF considers it incompatible... 14:37:12 http://www.w3.org/Consortium/Legal/IPR-FAQ-20000620 14:37:24 http://www.w3.org/2013/09/html-faq.html 14:37:45 http://www.w3.org/2013/09/html-faq.html#gplcompatibility 14:38:07 AR: Henri Sivonen makes an argument, of which I'm not convinced, that if you are going to automatically generate help or error text that extracts from the specification and winds up in code, the code is then potentially not GPL clean. 14:38:17 AR: I believe that a covenent should resolve that concern. 14:38:54 AR: I do understand that this doesn't in the general case resolve the question of whether cc: by leaves you GPL clean 14:39:11 TBL: Definitely not just help text. It's also generating parsers from BNF, etc. 14:39:14 NM: I agree with Tim 14:40:11 DA: The question is, FSF and Creative Commons say it's incompatible and W3C says compatible, are we getting them together. 14:40:16 PLH: Harder than that. 14:40:34 AR: FSF has their own interpretation that they can enforce with respect to the products they control 14:41:33 DA: Thank you Philippe 14:41:38 Philippe leaves 14:43:11 TBL: This about people doing things on principle. Principle is important, and important things follow from principles. Viral licenses are complicated to design and are tweaked occasionally. The fact that FSF has come to this conclusion is a failure of the GPL license. Compatibility with cc: By should be straightforward and should be a requirement for GPL. 14:43:48 AVK: Yes, some of it is principle. I would like my work to be in the public domain, much as Tim got the browser to be given away. 14:44:45 AR: CC: by is NOT public domain. Having a license and public domain is different thing. In US law, governments can put things in public domain but individuals can't. 14:45:27 SK: But laws typically say that the owner has all rights to do anything. 14:45:32 DA: Which jurisdiction? 14:45:57 SK: I guess I'm speaking of Russia, but that's based closely on Berne convention and should apply at least to most of Europe. 14:46:01 AR: ...and US 14:46:04 s/the browser/the ideas and software around the Web/ 14:46:36 s/CC: by/CC0/ 14:47:02 AR: What can the TAG do? Ask US libary of congress to let W3C put into public domain. 14:47:14 TBL: But our members don't want to put our work into the public domain. 14:48:04 TBL: I did not get the Web into public domain. I got CERN to agree not to charge license. The work I did here is MIT license and copyright MIT, similar to BSD and cc: by. 14:48:10 AR: So key was? 14:48:18 TBL: As I recall, not to charge royalties. 14:50:22 Yehuda -- yes, this is the "Authoring Spec": http://www.w3.org/TR/html5-author/ 14:50:31 "HTML5: Edition for Web Authors" 14:51:09 big deprecated warning at the top? 14:51:19 "This document has been discontinued and is only made available for historical purposes. The HTML specification includes a style switcher that will hide implementer-oriented content." 14:51:34 It's a Note, whereas Polyglot (http://www.w3.org/TR/html-polyglot/) is still on the REC track 14:52:10 slightlyoff_ has joined #tagmem 14:52:16 But the link to the Authoring spec. from the charter says "The HTML Working Group will complete work on the following existing deliverables of the group:" 14:52:19 ??? 14:52:21 timbl: http://www.w3.org/Policy.html 14:52:41 timbl: "The definition of protocols such as HTTP and data formats such as HTML are in the public domain and may be freely used by anyone. -- Tim BL" 14:53:03 wycats_ has joined #tagmem 14:53:29 wycats_ has left #tagmem 14:53:33 wycats_ has joined #tagmem 14:54:52 Anne, yes, but as AR and SK said, _saying_ that is an indication of author's intent, but it doesn't, legally, make it so IIUC: only the US gov't can 'make' something public domain wrt US law, I believe. 14:55:53 ht: this was back in Switzerland I suspect 14:56:11 ht: either way, CC0 covers the US gov case 15:06:15 RRSAgent, make logs public 15:06:17 Zakim, this will be TAG 15:06:17 ok, trackbot; I see TAG_f2f()8:30AM scheduled to start 156 minutes ago 15:06:18 Meeting: Technical Architecture Group Teleconference 15:06:18 Date: 01 October 2013 15:06:26 I have made the request to generate http://www.w3.org/2013/10/01-tagmem-minutes.html Yves 15:10:18 Regrets: Jeni 15:10:36 Here is the (relatively) famous analysis of DRM effect on Vista and chip design: http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html 15:12:15 Scribe: slightlyoff 15:13:08 Topic: API design 15:13:31