XSF logo XSF Discussion - 2020-01-09


  1. mukt2 has left
  2. krauq has left
  3. stpeter has left
  4. krauq has joined
  5. beta has left
  6. beta has joined
  7. mukt2 has joined
  8. pdurbin has joined
  9. pdurbin has left
  10. murabito has joined
  11. lskdjf has left
  12. mukt2 has left
  13. stpeter has joined
  14. mukt2 has joined
  15. Lance has left
  16. Lance has joined
  17. mukt2 has left
  18. debacle has left
  19. mukt2 has joined
  20. emus has left
  21. emus has joined
  22. beta has left
  23. beta has joined
  24. beta has left
  25. mukt2 has left
  26. mukt2 has joined
  27. mukt2 has left
  28. krauq has left
  29. beta has joined
  30. waqas has left
  31. Shell has left
  32. waqas has joined
  33. pdurbin has joined
  34. adiaholic has joined
  35. Shell has joined
  36. waqas has left
  37. waqas has joined
  38. waqas has left
  39. waqas has joined
  40. krauq has joined
  41. waqas has left
  42. waqas has joined
  43. neshtaxmpp has left
  44. neshtaxmpp has joined
  45. waqas has left
  46. waqas has joined
  47. stpeter has left
  48. waqas has left
  49. waqas has joined
  50. waqas has left
  51. waqas has joined
  52. waqas has left
  53. waqas has joined
  54. beta has left
  55. beta has joined
  56. waqas has left
  57. waqas has joined
  58. mukt2 has joined
  59. waqas has left
  60. waqas has joined
  61. Shell has left
  62. mukt2 has left
  63. waqas has left
  64. waqas has joined
  65. mukt2 has joined
  66. waqas has left
  67. waqas has joined
  68. waqas has left
  69. waqas has joined
  70. mukt2 has left
  71. waqas has left
  72. waqas has joined
  73. waqas has left
  74. waqas has joined
  75. waqas has left
  76. waqas has joined
  77. mukt2 has joined
  78. waqas has left
  79. waqas has joined
  80. waqas has left
  81. waqas has joined
  82. waqas has left
  83. waqas has joined
  84. waqas has left
  85. waqas has joined
  86. mukt2 has left
  87. waqas has left
  88. waqas has joined
  89. waqas has left
  90. waqas has joined
  91. waqas has left
  92. waqas has joined
  93. mr.fister has left
  94. mukt2 has joined
  95. mukt2 has left
  96. mukt2 has joined
  97. andy has joined
  98. beta has left
  99. beta has joined
  100. mukt2 has left
  101. adiaholic has left
  102. adiaholic has joined
  103. Nekit has joined
  104. Yagiza has joined
  105. Yagiza has left
  106. beta has left
  107. mukt2 has joined
  108. Yagiza has joined
  109. Zash has joined
  110. adiaholic has left
  111. beta has joined
  112. adiaholic has joined
  113. beta has left
  114. mukt2 has left
  115. beta has joined
  116. mukt2 has joined
  117. Lance has left
  118. mukt2 has left
  119. Tobias has joined
  120. mukt2 has joined
  121. lovetox has joined
  122. Douglas Terabyte has left
  123. lovetox has left
  124. adiaholic has left
  125. adiaholic has joined
  126. lorddavidiii has joined
  127. mukt2 has left
  128. paul has joined
  129. mukt2 has joined
  130. Douglas Terabyte has joined
  131. Douglas Terabyte has left
  132. mukt2 has left
  133. wurstsalat has joined
  134. mukt2 has joined
  135. beta has left
  136. sonny has left
  137. Daniel has left
  138. sonny has joined
  139. adiaholic has left
  140. adiaholic has joined
  141. Daniel has joined
  142. Arc has left
  143. Lance has joined
  144. adiaholic has left
  145. adiaholic has joined
  146. madhur.garg has left
  147. mukt2 has left
  148. Daniel has left
  149. mukt2 has joined
  150. Daniel has joined
  151. sonny has left
  152. flow 21:32:39 Zash> What came first, the spec or the implementation? IMHO spec and implementation are ideally developed together
  153. mimi89999 has left
  154. sonny has joined
  155. mimi89999 has joined
  156. mukt2 has left
  157. Lance has left
  158. eevvoor has joined
  159. mukt2 has joined
  160. beta has joined
  161. mathijs has left
  162. mathijs has joined
  163. sonny has left
  164. sonny has joined
  165. Lance has joined
  166. sonny has left
  167. karoshi has joined
  168. sonny has joined
  169. mathijs has left
  170. mathijs has joined
  171. UṣL has joined
  172. sonny has left
  173. mathijs has left
  174. mathijs has joined
  175. mukt2 has left
  176. mukt2 has joined
  177. COM8 has joined
  178. sonny has joined
  179. Lance has left
  180. waqas has left
  181. mukt2 has left
  182. mukt2 has joined
  183. Lance has joined
  184. derdaniel has joined
  185. mukt2 has left
  186. mukt2 has joined
  187. adiaholic has left
  188. adiaholic has joined
  189. Daniel has left
  190. Daniel has joined
  191. sonny has left
  192. derdaniel has left
  193. Lance has left
  194. Max has left
  195. Max has joined
  196. mukt2 has left
  197. pep. "dwd> moparisthebest, I've implemented MIX twice." are these implementations published anywhere? I'm sure that would help the "situation" a bit.
  198. Zash has left
  199. dwd One sort of is, but has "problems" - it's for Openfire, but essentially used a different database approach to the mainstream (I didn't write that bit). Genuinely can't recall if it's at all salvageable. The other was private and bespoke to specific needs, which MIX met considerably better than MUC.
  200. dwd Currently, I'm using MUC Light for work - I inherited it, but still, as I said before it works well, it's just a dead-end in terms of standardisation.
  201. sonny has joined
  202. mukt2 has joined
  203. goffi has joined
  204. edhelas damn I'm tired of asking my contacts to disable OMEMO to talk with me
  205. karoshi has left
  206. karoshi has joined
  207. dwd ?OTRv?
  208. mukt2 has left
  209. COM8 has left
  210. COM8 has joined
  211. Steve Kille has left
  212. eevvoor has left
  213. mukt2 has joined
  214. pdurbin has left
  215. sonny has left
  216. COM8 has left
  217. eevvoor has joined
  218. flow edhelas, if ppl send you omemo encrypted messages, doesn't that mean that you have omemo pep nodes that you may want to purge?
  219. COM8 has joined
  220. Zash has joined
  221. eevvoor I thought you cannot purge them? flow
  222. dwd You certainly *can*, I mean according to the PEP protocol. Whether your client lets you is a different matter.
  223. mukt2 has left
  224. mukt2 has joined
  225. jonas’ and whether your client silently re-uploads your keys when you did that is yet another question
  226. jonas’ #Conversations
  227. pep. yeah.. you do need something server-side for that.
  228. debacle has joined
  229. Steve Kille has joined
  230. sonny has joined
  231. Zash It takes week(s?) for clients to forget keys after you remove them
  232. pep. I guess seeing bundles removed could be a sign indeed. Generally clients only check the devicelist though, and getting off the devicelist is "easy"
  233. sonny has left
  234. pep. (only check the devicelist, *and download missing bundles)
  235. jonas’ pep., but evil servers!
  236. pep. Yep, lots of people don't care about that (which goes clearly against "I don't trust the server so I use e2ee", and "I don't verify fingerprints"), and to a point it's fine..
  237. pep. We're not talking about this now :)
  238. pep. Well I wasn't
  239. jonas’ pep., to be fair, sometimes people are "I use e2ee because I don’t trust that other guy’s server"
  240. flow So the leason here is probably that every xmpp e2ee scheme should have an easy and reliable way out
  241. pep. Yeah that works
  242. sonny has joined
  243. jonas’ flow, that’s not possible without: - having to use the E2EE scheme, or - trusting servers
  244. COM8 has left
  245. jonas’ flow, that’s not possible without: - having to use the E2EE scheme, or - trusting servers, or - accepting downgrade attacks
  246. flow ahh right
  247. jonas’ for example, one could post a signed "I don’t want to use OMEMO" thing in the PEP node, but if it’s unsigned, that can clealy be spoofed by the server. If it’s signed, you need to partake in OMEMO key verification madness.
  248. dwd You could, though, have your E2EE-aware clients make the stipulation in a secure method.
  249. flow that potentially
  250. pep. which works only when you have an e2ee-aware client
  251. pep. for this mechanism
  252. jonas’ dwd, true
  253. jonas’ pep., but then you only need one of them. If Conversations supported that type of statement, I’d be happier.
  254. jonas’ I’d publish that once and be done with it
  255. pep. That might be something I can support in poezio :x
  256. dwd pep., Right, but if you have none, you have no keying material.
  257. jonas’ though such a statement needs to have a time limit, otherwise a sevrer can use it against you forever
  258. dwd jonas’, Indeed, timestamped, expiry, a bit like a certificate.
  259. dwd suggests X.509 Attribute Certificates.
  260. jonas’ (revocation is not enough, because a server could decide not to publish the revocation of that statement)
  261. dwd jonas’, Sure, but with X.509 AC you can have OCSP.
  262. jonas’ sorry, that’s over my head
  263. dwd Attribute Certificates are like normal certs, but without a public key.
  264. Dele (Mobile) has joined
  265. pep. dwd, I also don't understand OCSP very much, but that requires a third-party to say if your cert is expired or not right?
  266. Zash Oh, OCSP over XMPP?
  267. dwd pep., It requires, in this case, the attribute authority to indicate the current status. But the attribute authority could be you, of course.
  268. dwd Zash, Yeah, why not?
  269. pep. dwd, "you" as in, the client?
  270. dwd I should probably stress now that I'm only half-serious at best.
  271. pep. So that means my server could lie for it just as much as revocation?
  272. dwd pep., No, you as in you, and it'd be signed statements by your personal key.
  273. dwd pep., Or one you delegate, since OCSP and CRLs support that too.
  274. jonas’ generic reminder that there is no "personal" key in OMEMO, only device kyes.
  275. jonas’ generic reminder that there is no "personal" key in OMEMO, only device keys.
  276. dwd jonas’, Indeed.
  277. dwd cries quietly.
  278. Ge0rG can't we just do S/MIME and dump everything into CT?
  279. pep. dwd, but then it's "the same thing" right? (again I'm missing knowledge of OCSP). You'd sign a statement that says "It expires on the XXXX"? Might as well avoid this indirection then no(?)
  280. sonny has left
  281. dwd pep., Only if you like reinventing wheels, basically.
  282. jonas’ pep., OCSP is directly with the CA, in this case, your client. You wouldn’t publish that in PEP, you’d have an IQ or something
  283. jonas’ and the IQ would have a signed statement in it
  284. jonas’ if there’s no signed statement in that IQ, tampering is obvious
  285. pep. So we're introducing "another" third-party
  286. dwd jonas’, OCSP is transport independent and is itself signed, so you'd be OK there.
  287. jonas’ no, my interpretation would be that such IQs would be replied to e.g. by Conversations
  288. jonas’ but, uh, why are we talking about this?
  289. pep. jonas’, so that you can be free of "I sent you an OMEMO message" messages :)
  290. pep. and edhelas as well
  291. dwd jonas’, Because I like to get people discussing the intricacies of X.509 for my personal amusement.
  292. jonas’ pep., 1w expiry interval is probably ok
  293. jonas’ I need to put Conversations online once per week either way so that it takes just an hour to sync, not multiple hours.
  294. jonas’ dwd, you’re a sadist
  295. pep. jonas’, I'd set it slightly longer, like 2-3 weeks. Holidays are a thing :p
  296. pep. Then if you really want to use OMEMO again you can publish devicelist/bundle and the other would fetch them
  297. jonas’ pep., wfm too
  298. jonas’ no, the server would just swallow that ;)
  299. jonas’ (evil server!)
  300. pep. hmm.
  301. pep. Then you might want to leave your server
  302. jonas’ sure, and then you can also drop e2ee and make my life easier :)
  303. dwd In general, it's possble to trust your server to work honestly, but also not trust it with the content of your messages.
  304. pep. don't ask me :p
  305. jonas’ dwd, true
  306. dwd But also, it's possible for a service provider to manage risk by enforcing E2EE, which is what WhatsApp et al are doing it for.
  307. jonas’ that ... makes sense
  308. jonas’ so much
  309. pep. As a provider I'd be happy to encourage (any kind of) e2ee. Not just OMEMO
  310. dwd The problem for users is that this pushes the archive onto their device, and radically alters their risk profile.
  311. dwd Not that, of course, they're aware of this in any real sense.
  312. dwd But I';ve been in rooms with FB and other "secure" IM service providers and they've cheerfully discussed holding keying material in the cloud "because unless it's written to disk we can't be subpeoned", so I've a pretty reasonable conclusion to what their threat model actually is.
  313. Ge0rG so cloud is now non-persistently backed persistent storage?
  314. jonas’ goes and subpoenes them for their swapfiles
  315. dwd I mean, they explicitly keep user keys unencrypted in RAM on their servers. Or were discussing it, anyway.
  316. Ge0rG redundant array of inexpensive DRAMs
  317. Ge0rG dwd: that reminds me that we need an xmpp server that will use asymmetric crypto to encrypt all of a user's (meta)data on disk and only unlock the decryption key on a user login / during sessions
  318. pep. dwd, fwiw I had no doubt that their interest wasn't with their users
  319. Ge0rG I'm pretty confident that we can encrypt most of the roster, and maybe have some kind of JID hashing for presence probing purposes
  320. Ge0rG also could easily encrypt all of MAM
  321. dwd Ge0rG, Well, in my case, I need that metadata, and moreover so do the NHS trusts we hold the data for. Indeed, they need the content too for audit cases.
  322. Zash Uh, where did this discussion go?
  323. Ge0rG dwd: the compliance use case is at least orthogonal to the public-server use case, but more probably it's even the opposite
  324. dwd Ge0rG, But yes, in other cases you could use [H]PKE when writing to the archive I think. To some degree.
  325. dwd Zash, Around and around. Where it stops, nobody knows.
  326. Zash HWHAT
  327. Ge0rG I presume it's Hybrid Public Key Encryption
  328. dwd Indeed.
  329. Ge0rG Zash: that ugly RSA based PoC you once wrote for me, that I was too scared to deploy
  330. Zash MAM can be encrypted yes, I did some such experiment once.
  331. Ge0rG roster groups and names can be encrypted as well
  332. Ge0rG PEP obviously can't
  333. dwd HPKE is a public key crypto system based around a Key Encaspulation Mechanism and a symmetric cipher.
  334. Zash Private RSA key encrypted with some stuff extracted out of SCRAM and only available during login
  335. dwd Ge0rG, PEP can't be encrypted unilaterally, at least.
  336. Ge0rG roster JIDs can be encrypted as well if you ensure some additional one-way-hashed-JIDs store for authentication purposes
  337. dwd Zash, You might enjoy HPKE with 25519, that uses a 32-byte integer as the private key with is nicely derivable from almost anything using a SHA-2.
  338. jonas’ s/SHA-2/hash function/
  339. jonas’ let’s maybe not get too excited about any specific one ;)
  340. dwd jonas’, Potentially.
  341. Ge0rG dwd: I'm in absolute love with 25519 after I used sodium in a Bluetooth LE mobile payment system
  342. jonas’ s/hash function/cryptographic hash function/
  343. jonas’ (where cryptographic implies obviously >= 32 bits)
  344. jonas’ ohh, I read bits instead of bytes
  345. jonas’ that makes it much less confusing
  346. jonas’ and scary
  347. Zash Well a key that unlocked another asymetric key that was used to decrypt MAM
  348. jonas’ dwd, also, is every 32 byte integer a valid 25519 private key?
  349. Ge0rG jonas’: https://libsodium.gitbook.io/doc/key_derivation#key-derivation-with-libsodium-greater-than-1-0-12
  350. dwd jonas’, I can't remember if all 0's is.
  351. dwd jonas’, But otherwise, yes.
  352. jonas’ neat
  353. jonas’ no more gambling with primes, eh?
  354. dwd Though I Am Not A Cryptographer.
  355. jonas’ IANAC :)
  356. dwd Ooooh... One of the OpenVPN devs is considering a multicast/broadcast VPN using MLS as the key agreement protocol. Nifty idea!
  357. dwd Means that the VPN server itself can't decrypt the packets.
  358. Lance has joined
  359. aj has joined
  360. sonny has joined
  361. adiaholic has left
  362. adiaholic has joined
  363. Lance has left
  364. sonny has left
  365. Wojtek has joined
  366. dwd has left
  367. adiaholic has left
  368. adiaholic has joined
  369. sonny has joined
  370. sonny has left
  371. debacle has left
  372. sonny has joined
  373. eevvoor has left
  374. mukt2 has left
  375. lskdjf has joined
  376. vanitasvitae has left
  377. vanitasvitae has joined
  378. pdurbin has joined
  379. tao has joined
  380. Kev Check I'm reading things properly, does anyone have a different understanding for cert checking than that you convert the reference identifier (what you want to find) into punycode and expect what's in the certificate to also be punycoded already (and then do a case insensitive match)?
  381. Zash That doesn't sound right
  382. Zash But maybe it is
  383. kifterz has joined
  384. sonny has left
  385. sonny has joined
  386. kifterz has left
  387. flow Kev, are you asking if the x509 cert SAN is in punnycode?
  388. Kev Yep. That's how it reads to me.
  389. flow (punnycode/ACE)
  390. adiaholic has left
  391. Ge0rG looks like that in my real-life LE cert... X509v3 Subject Alternative Name: DNS:xn--bdk.op-co.de
  392. flow Kev, Smack currently does this https://github.com/igniterealtime/Smack/blob/9d626bf787dc3e0e0a4399cef429285b22744d73/smack-tcp/src/main/java/org/jivesoftware/smack/tcp/XMPPTCPConnection.java#L719
  393. Kev Ge0rG: Fab, ta.
  394. Kev flow: Thanks.
  395. pep. hmm, I also have punnycode in my cert, but then I did ask for punnycode when generating my cert
  396. pep. Unsure if I can ask for proper unicode
  397. adiaholic has joined
  398. mukt2 has joined
  399. flow Kev, besides that, proper verificaiton is more than just a "case insensitive match": https://github.com/igniterealtime/Smack/blob/9d626bf787dc3e0e0a4399cef429285b22744d73/smack-java7/src/main/java/org/jivesoftware/smack/java7/XmppHostnameVerifier.java#L135
  400. sonny has left
  401. flow (I do not guarantee that the code is complete nor correct)
  402. pdurbin has left
  403. pdurbin has joined
  404. dwd has joined
  405. MattJ dwd, looks like I lost s2s with you, and received unsubscribe/d - are we still friends?
  406. Ge0rG MattJ: you are not the only one
  407. Ge0rG maybe it's a change of the XMPP domain?
  408. MattJ He's joined from the same JID here though
  409. pep. Quick we need a crypto identity to make sure it's him
  410. dwd I've just reinstalled Openfire, and did a thorough roster clean - but I don't *think* I deleted you. OTOH, I've not seen either you or Ge0rG online in my roster for some time, and various other things have been broken, so maybe this is things catching up.
  411. Ge0rG MattJ: my s2s still works
  412. MattJ I'll check logs
  413. pdurbin has left
  414. Ge0rG > 12:05:17 Roster> dwd does not want to receive your status anymore. > 12:05:17 Roster> dwd does not want you to receive their/its status anymore.
  415. MattJ Oh, may be an IPv6 thing
  416. MattJ My outgoing IPv6 appears to be broken, and Prosody doesn't know. Pretty sure it used to work...
  417. dwd Interestingly, I seem to have lost everyone running Prosody.
  418. MattJ Oh, maybe it's not my issue
  419. MattJ Is your inbound IPv6 working?
  420. Holger dwd: You also unsubscribed from me. No Prosody involved :-)
  421. dwd I firewalled the S2S ports briefly, reinstalled the server from scratch, and reimported my user (with lots of cruft removed from the roster). You're still there with subscription=both at my end...
  422. pep. Isn't that prosody not doing happy eyeballs?
  423. dwd Oh!
  424. dwd No, this *is* IPv6. I forgot to firewall that...
  425. pep. "There's an IPv6 record. IPv6 is not actually working. Prosody confused"?
  426. Ge0rG MattJ: so when are you going to fix v6 in prosody?
  427. dwd So yeah, everything that connected to me over IPv6 saw the point in time when my user didn't exist.
  428. beta has left
  429. dwd I wonder how I can fix this...
  430. Holger My server doesn't do v6 ...
  431. debacle has joined
  432. sonny has joined
  433. beta has joined
  434. MattJ This is why IPv6 is terrible
  435. Shell has joined
  436. MattJ hides from Zash
  437. Zash gets out the pitchfork
  438. Zash I've got machines only reachable over IPv6
  439. beta has left
  440. mukt2 has left
  441. beta has joined
  442. jonas’ me too. I always get reminded when I try to wget something off github.com
  443. jonas’ "Network unreachable"
  444. dwd has left
  445. Vaulor has left
  446. Vaulor has joined
  447. mathijs has left
  448. mathijs has joined
  449. dwd has joined
  450. beta has left
  451. dwd MattJ, If you resubscribe to me, does that work?
  452. MattJ s2s is still timing out
  453. dwd Timing out? Over IPv6 or IPv4?
  454. dwd Ah, IPv6 not routed on that machine for some reason.
  455. dwd Fixed that, at least.
  456. sonny has left
  457. ralphm ik.nu doesn't seem to be able to connect either
  458. ralphm dwd: so :-(
  459. ralphm dwd: you could script to send resubscribes for all your contacts?
  460. dwd Probably have to, yes.
  461. dwd But I need things to connect first. :-/
  462. ralphm of course
  463. MattJ Still not connecting for me
  464. mathijs has left
  465. mathijs has joined
  466. ralphm I tried manually, but indeed, I cannot establish a TCP connection to peirce.dave.cridland.net (2a02:8010:800b::2).
  467. adiaholic has left
  468. adiaholic has joined
  469. Zash has left
  470. dwd Might work now.
  471. Zash has joined
  472. ralphm Sent a ping
  473. ralphm There we go!
  474. dwd Well, that works now.
  475. dwd Lovely. So people are more than welcome to re-add me (or just add me) at dwd@dave.cridland.net
  476. ralphm Tried that too.
  477. dwd And I'll have to write a script, I suppose.
  478. dwd ralphm, Seems to have worked.
  479. ralphm Not seeing your presence, yet.
  480. dwd Probably because OF think it's sent it already.
  481. Kev flow: I meant to say that each entry check is a case insensitive ascii match. I realise there are several checks involved, but yes, thanks :)
  482. Lance has joined
  483. beta has joined
  484. intosi has left
  485. ralphm has left
  486. beta has left
  487. sonny has joined
  488. intosi has joined
  489. tao has left
  490. ralphm has joined
  491. Lance has left
  492. beta has joined
  493. dwd Well, that helped a bit.
  494. beta has left
  495. mukt2 has joined
  496. ralphm As a follow-up on yesterday's screenshot of Slack reactions: that message eventually got 45 different reactions, by 804 people. The largest count for one reaction was 106.
  497. ralphm It also turns out there's a cap on how many different reactions a single person can react with: 23.
  498. ralphm https://upload.ik.nu/upload/1SjqYFQc3mADqO3N/reactions_cap.png
  499. ralphm I should say: 804 counts, not people.
  500. Alex has left
  501. Alex has joined
  502. mukt2 has left
  503. mukt2 has joined
  504. Douglas Terabyte has joined
  505. mukt2 has left
  506. mukt2 has joined
  507. pdurbin has joined
  508. eevvoor has joined
  509. jonas’ > reacji
  510. pep. reac字? :)
  511. Zash Please tell me that's a typo
  512. pep. Zash, it come from emo字(絵文字) or bakemo字(バケ文字) etc..
  513. pep. probably
  514. jonas’ pep., I doubt it
  515. pdurbin has left
  516. calvin has joined
  517. calvin has left
  518. calvin has joined
  519. calvin has left
  520. calvin has joined
  521. paul has left
  522. paul has joined
  523. calvin has left
  524. Lance has joined
  525. dwd Anyone any ideas on the best way to test a websocket connection?
  526. sonny has left
  527. mathijs has left
  528. mathijs has joined
  529. Zash Test what, exactly?
  530. dwd Ideally, XMPP connectivity.
  531. Zash has left
  532. dwd But even just a websocket CLI tool would be handy.
  533. Guus reconfigure your favorite web client to use it?
  534. ralphm Zash: I am sure they call it reacji internally and slipped out this way.
  535. dwd I was hoping for something slightly less intensive...
  536. edhelas ralphm "reacji" so there's a name for those things 🤔
  537. ralphm But see also https://indieweb.org/reacji
  538. Lance has left
  539. Nekit has left
  540. nyco can you react to reactions? reactionception
  541. stpeter has joined
  542. Nekit has joined
  543. Wojtek has left
  544. edhelas reacjiji
  545. ralphm bangs gavel
  546. pep. heh
  547. pep. !
  548. ralphm 0. Welcome
  549. MattJ I'm unfortunately probably going to be 80% not here :/
  550. stpeter has left
  551. MattJ Had an emergency work meeting come up at the last minute
  552. nyco so that's 20% here
  553. MattJ If it ends early, I'll hop in though
  554. ralphm MattJ, surely 20% of your brain capacity is sufficient :-D
  555. emus has left
  556. ralphm Who else do we have
  557. MattJ I wouldn't be so sure :)
  558. pep. Guus was here a few minutes ago
  559. pep. Seve ?
  560. adiaholic has left
  561. adiaholic has joined
  562. Guus I"m here
  563. Guus talking to a customer, but will lurk
  564. ralphm Ok, so maybe we have quorum :/
  565. Guus I'm brushing off the customer 🙂
  566. Guus well, no
  567. Guus but that conversation is at an end.
  568. ralphm heh
  569. ralphm 1. Minute taker
  570. nyco https://mensuel.framapad.org/p/9ece-xsf-board-weekly-meeting-2020-01-09 please contribute!
  571. ralphm Yay
  572. ralphm 2. GSoC 2020
  573. nyco (I've just slightly covered that on the newsletter)
  574. ralphm I saw some movement on this. Anything Board can / needs to do here?
  575. nyco knight Flow once again?
  576. pep. We have volunteers to admin, I think we're good
  577. ralphm FWIW I like how pep refers to himself in the 3rd person in Trello.
  578. dwd I think blessing what flow is doing would be sensible.
  579. Guus Can we commit?
  580. pep. Thanks flow, and larma as backup
  581. pep. ralphm, I'm happy to take in comments, I'm not a native :p
  582. pep. And I copied that from a description (where it wasn't especially obvious that I was the author of the text)
  583. ralphm ah!
  584. ralphm Guus: I think we can.
  585. Guus I'd like that.
  586. ralphm There's still some time to expand the projects
  587. dwd By the above, I mean that technically, flow ought to have formal go-ahead from the Board, since he's probably entering into agreements with Google's GSoC organisation.
  588. neshtaxmpp has left
  589. pep. Unsure if poezio is going to participate this year, maybe. In any case we already have 3 projects interested
  590. ralphm dwd: that's a good point
  591. dwd pep., Four, I think - Prosody, Smack, Dino, Openfire.
  592. neshtaxmpp has joined
  593. Kev I don't think Flow can reasonably go ahead without Board appointing him.
  594. Kev Right, what Dave says.
  595. ralphm moves that Florian Schmaus can go ahead to apply for GSoC 2020 and be the XSF's admin to that end.
  596. ralphm +1
  597. Guus motions that board approve... scratch that, +1
  598. pep. +1
  599. Kev (He also needs co-admins)
  600. mukt2 has left
  601. pep. larma volunteered, as mentioned above
  602. ralphm Kev: I know this, but do we also have to appoint them, as Board?
  603. Kev In the past it's usually been someone on Board, so haven't needed to.
  604. ralphm ah
  605. ralphm amends his motion to include Marvin Wissfeld as co-admin.
  606. ralphm +1
  607. Guus +1
  608. mukt2 has joined
  609. pep. +1
  610. ralphm Motion (including amendment) carries.
  611. ralphm Yay
  612. nyco (hey MattJ if you want to vote, do that before I send the minutes)
  613. ralphm 3. OMEMO
  614. ralphm I would like to briefly touch upon this discussion in Council and here.
  615. ralphm In short the discussion is about whether or not XEP-384 can move ahead in our process, as in its current state implementing it depends on libsignal.
  616. MattJ +1 to Marvin as co-admin
  617. UṣL has left
  618. nyco MattJ : +1 for both motions?
  619. pep. ralphm, I'd like to note that the author hasn't asked to move it.
  620. ralphm One of the things raised yesterday, is that the XSF might be liable for incorporating the signal protocol, if it is determined that the way we got to the protocol description is deemed a derivative of libsignal.
  621. jonas’ ralphm, or, to take that edge off, it is highly unclear if it can be implemented without using libsignal or a derivate of it
  622. ralphm pep., I am aware, please be patient.
  623. ralphm The above concerns me, as Board runs the XSF, and me personally as part of (and only member of) the Executive Committee.
  624. ralphm I wanted to make note of this, and why I am arguing against any action that might cause this to be the case.
  625. Guus Is there something that you'd explicitly want board to discuss on this now?
  626. Kev (I note that Council voted against accepting OMEMO if it depended on libsignal, with these issues)
  627. Kev (There was something of a bait-and-switch in order to get the libsignal dependency in there)
  628. Guus > (I note that Council voted against accepting OMEMO if it depended on libsignal, with these issues) Then I don't understand the issue.
  629. Kev Guus: OMEMO was proposed with libsignal. Council vetod. OMEMO was proposed again in a different form. Council accepted. OMEMO was then reverted to the state Council rejected.
  630. Kev Roughly.
  631. Guus Ah, Dave's mail of a while ago.
  632. Kev It's all much more complicated than a one-line summary will give credit to, but that's the headline.
  633. Daniel OMEMO was then reverted to the state Council rejected with approval of council
  634. Guus so council contradicted itself?
  635. ralphm Well, I'd love some response. I also don't think we want to be in a position where we need to find out how a description of the protocol came to be and if it would indeed be considered a derivative work. My preferred outcomes are 1) The Signal Foundation releases a spec and we can depend on it, 2) we advice Council to reject the specification, 3) this XEP stops depending on libsignal or its protocol.
  636. MattJ nyco, +1 to both, yes
  637. nyco thx
  638. Daniel it's not like i snug into the server overnight and pushed the current xep
  639. Kev Guus: As I say, more complicated. Council was persuaded that the new form didn't need libsignal.
  640. MattJ My meeting is over now, I'll try to pretend I was always paying attention
  641. Guus right, we're not going to conclude a discussion on how this XEP came to be now. Fact is, that it is there in its current form now.
  642. Kev Daniel: Well, indeed, although that does sound exciting.
  643. Daniel not that i'm super happy with how that all went; and i'm sorry
  644. ralphm This is not about pointing fingers, of course.
  645. Guus ralphm as a 4th option: discuss this with the people behind libsignal, and have them put to paper that we can either release specifications, or not?
  646. jonas’ Guus, unlikely to happen
  647. Kev Guus: That's Ralph's (1) isn't it?
  648. ralphm Guus: well, if we're going to have a discussion with them, then the outcome should be 1)
  649. beta has joined
  650. sonny has joined
  651. ralphm I don't want to be in the business of chasing their changes.
  652. ralphm pep. also raised a point:
  653. Guus I'm unsure if 4 == 1. Could be some middle ground in us defining a spec that refers to theirs, keeping their provisions on implementations in place?
  654. ralphm He says we might send a bad signal when we reject OMEMO.
  655. ralphm I've thought about this and came to the following:
  656. MattJ bad signal...
  657. ralphm If we (the XSF, Board, Council or both) decide to reject OMEMO, we should write a blog post pointing out why, and combine that other efforts.
  658. pep. MattJ, ! :)
  659. ralphm Like the formation of an E2EE SIG, and maybe work individuals are doing within / in collaboration with MLS WG at IETF>
  660. MattJ I would prefer not to reject OMEMO until we have exhausted possibilities for saving it
  661. Zash has joined
  662. ralphm MattJ: I am open to suggestions. OMEMO hasn't moved for a while, and I don't think it would be wise to /not/ do something.
  663. Guus You're slowly turning into Kev there...
  664. jonas’ MattJ, in my eyes, the only way to make OMEMO acceptable is to provably cleanroom-reverse-engineer the signal protocol and publish that.
  665. Kev High praise.
  666. MattJ For me that means at least reaching out to the libsignal folks (officially, as the XSF) and asking for a more permissive license
  667. ralphm Kev: :-)
  668. MattJ or clean-room, but I personally feel less like I understand the legal basis of such an approach
  669. jonas’ MattJ, we can do that, but I doubt this is going to happen, given the money Moxie likely makes off commercial licenses for libsignal.
  670. ralphm jonas’, and I don't think we have the capacity to verify that something was indeed reverse engineered in a cleanroom fashion.
  671. dwd MattJ, Is it a permissive license we need, or a clear specification?
  672. MattJ A clean room implementation is still open to a challenge, whereas an explicit "it's ok to do what you're doing" is less likely to end that way
  673. ralphm I wouldn't want to burn my fingers on it, anyway.
  674. Guus I agree with MattJ that we should at least try to work with Signal, before abandoning the XEP, if it comes to that.
  675. pep. ralphm, but you can blame that on people who claim it's be done that way.
  676. jonas’ ralphm, with provably I mean with a legal advisor overseeing the process.
  677. MattJ dwd, whatever
  678. Kev I think it needs both, doesn't it?
  679. MattJ We basically have everything we need apart from some magic values, right?
  680. ralphm pep., I don't want to blame anybody, and don't want to be involved in that legal mess
  681. jonas’ in any case, if Board wants to go ahead contacting libsignal, then please motion that and do that, because Council has motioned to tihnk about how to reject OMEMO in the next session.
  682. Guus I'm concerned that going down the clean room solution would still open us up for a costly challenge (even if we'd win it). I'd like to avoid that.
  683. dwd MattJ, I don't think there's a specification for the wire protocol (message formats etc) or the constants in use.
  684. MattJ Guus, same
  685. Kev Guus: I think we both need to be able to clean room *and* it to be clear that it's acceptable to do so. If you can't clean room, the spec doesn't work.
  686. pep. I guess board can officially ask implementors what exactly is covered by GPL that would need to be reversed engineer. So we stop speculating
  687. pep. engineered*
  688. jonas’ pep., Syndace has it
  689. Guus Kev which basically means: work together with Signal on this, right?
  690. pep. jonas’, I know, I was thinking about him
  691. ralphm But this is not a technical challenge, it is a legal one.
  692. jonas’ specifically this part: https://github.com/Syndace/python-omemo-backend-signal
  693. pep. Now you just spoiled everybody who wanted to do clean-room :P
  694. jonas’ that link was here a week ago
  695. pep. (jk)
  696. Guus If they make it clear that they don't like others to provide implementations, then I wonder if we should continue to work on the XEP in this form.
  697. dwd The original reason for moving to "Olm" was that Olm had everything fully specified - but they had to use different constants under pressure from Moxie.
  698. ralphm pep., you kid, but this is actually a problem indeed
  699. nyco (I fail to understand this OMEMO discussion here, I'll need your input for the minutes) (and I'll have to go soon)
  700. MattJ and so does what we're discussing also apply to Olm?
  701. MattJ Thanks nyco!
  702. dwd MattJ, As I understand it, no, but an Olm-based OMEMO would not be compatible with the current spec because the constants differ.
  703. pep. MattJ, I would assume so tbh. "We don't know as long as it hasn't passed a judge" (in every single jurisdiction? :x)
  704. dwd That said, Olm is only in use by Matrix, and Matrix are themselves starting to work on moving to MLS.
  705. pep. Also re Matrix, https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom/ this says they did ask
  706. pep. (iirc)
  707. larma dwd, do you know of documentation which constants have been changed?
  708. ralphm So hey, Matrix is in the same boat as we. I don't see why we couldn't make a statement like this.
  709. Guus I've skimmed the article
  710. Guus What I read is that they asked for federation
  711. mukt2 has left
  712. Guus that's different than asking if it's permissible to use the signal double-ratched protocol as part of their protocol
  713. pep. Guus, hmm, correct
  714. Guus (although I might simply not have read that bit yet)
  715. ralphm Well, I'd be happy to discuss this with Matthew at FOSDEM.
  716. Guus We should talk to Moxie et. al.
  717. ralphm I think there's a reason why Matrix does not use libsignal
  718. Guus it'd be super silly if we now chose to abandon OMEMO because of this, only for them to go : "ah, you didn't have to do that"
  719. Guus Sure, but a) we're not sure, and b) time has passed.
  720. dwd Talking with Matthew at FOSDEM does sound snesible.
  721. MattJ Indeed
  722. pep. And reaching out Moxie, as Guus says.
  723. Guus I think the XSF should first decide if we want to move forward with OMEMO, or not (I've heard talk of a replacement, which makes this discussion pointless)
  724. Guus if we do, let's try to work together with Signal.
  725. pep. And reaching out to Moxie, as Guus says.
  726. Guus Well, I'm always happy to talk to Matthew - but he can't speak for Signal
  727. Guus he can only tell us what Signal at some point in the past told Matrix (or how he understood their remarks).
  728. pep. I am sure Moxie is well aware of the OMEMO situation in XMPP, and he would have probably poked us if there were obvious issues
  729. Guus So Matthew can have useful information, but if we want to go ahead with OMEMO, we'll have to talk to Signal eventually - also if we want to abandon it only for the reason of Singals licence seemingly incompatible with ours.
  730. ralphm Well, my point of view on standards development in the XSF has always been to look ahead. In that sense, I'd rather put efforts in MLS than somehow trying to save OMEMO out the legal unclarity.
  731. MattJ Can't be assumed, I'm sure he's pretty busy with other things to focus on
  732. dwd pep., But everyone's implementing using libsignal, so those issues don't exist.
  733. Guus So Matthew can have useful information, but if we want to go ahead with OMEMO, we'll have to talk to Signal eventually - also if we want to abandon it only for the reason of Singals licence seemingly incompatible with our goals.
  734. pep. dwd, just to say that asking him stuff certainly won't trigger a "hey you can't do what you're currently doing! I'm going to sue your ass!"
  735. sonny has left
  736. Guus Let's bring this meeting to an end
  737. pep. Any action to take away from this then?
  738. calvin has joined
  739. nyco (I'm gone, sorry, please finish https://mensuel.framapad.org/p/9ece-xsf-board-weekly-meeting-2020-01-09 )
  740. ralphm nyco: thanks
  741. pep. Also, I'd like to mention that this could happen for lots of other things, and we're mostly worried about what us EU/US can see. Are XEPs ever legally reviewed at all?
  742. sonny has joined
  743. pep. Re "Objective 4"
  744. ralphm pep., most of our protocols don't depend on other protocols like this
  745. pep. Our protocols may include patents only active in some legislations
  746. pep. Do we even know
  747. ralphm There might be patent issues always, but I think that's different from the current topic
  748. Guus Let's finish the topic at hand first, before addressing new topics please.
  749. Guus also: i need to go.
  750. pep. So no action?
  751. MattJ Same here, new meeting
  752. ralphm Ok. We can carry this forward to next week.
  753. pep. Ok
  754. ralphm Council can still make a decision from their perspective.
  755. Guus I'd first like to know if the XSF moving ahead hinges on Signals implicit approval.
  756. pdurbin has joined
  757. flow > but if we want to go ahead with OMEMO, we'll have to talk to Signal eventually I do not think this is strictly true: if we want to go ahead with OMEMO depending on libsignal, then yes. But the doubleratched and x3dh are open standards on which OMEMO could depend on. It is important in this discussion to differentiate between libsignal (the implementation) and doubleratched/x3dh (the specification). The issue we have with OMEMO is that it depends on libsignal, i.e. an (GPLed) implementation, when it should depend on an open standard
  758. mukt2 has joined
  759. rion has left
  760. Guus if that's that's the case, I think we should obtain explicit approval from Signal.
  761. ralphm Feel free to discuss further after the meeting
  762. ralphm 4. AOB
  763. ralphm ?
  764. Guus if we dont get it, we should consider burying the XEP>
  765. Guus no AOB.
  766. ralphm 5. Date of Next
  767. ralphm +1W
  768. ralphm 6. Close
  769. ralphm Thanks all!
  770. ralphm bangs gavel
  771. pep. +1 wfm. Thanks
  772. Guus wfm
  773. Guus Thanks
  774. jonas’ flow, I think for the simplicity of discussion, we should assume that the term OMEMO means OMEMO-as-currently-written-in-XEP-0384
  775. jonas’ and anything beyond that isn’t OMEMO but OMEMO’
  776. jonas’ suggesting that we don’t have to bury OMEMO because we could transform it to an incompatible OMEMO’ isn’t helpful and only distracting
  777. ralphm Right, OMEMO-right-now is what's been implemented.
  778. jonas’ the discussion is complex and confusing enough already
  779. ralphm Changing the spec to be incompatible with that is fine, in principle, but confusing.
  780. pep. To come back to objective 4, I'm really curious if anybody ever thought outside of their own jurisdiction. I'm sure at least one of our XEP (that isn't OMEMO) is infriging patents somewhere in some jurisdiction. Does Objective 4 care for this?
  781. larma jonas’, it's still up for discussion if OMEMO’ is necessarily incompatible to OMEMO
  782. pep. At least, I guess the answer currently is "we don't know"
  783. jonas’ also, I today realised that I should probably attend Board meetings more regularly as Council chair, but the time slot won’t work for me in the general case. Just FYI.
  784. ralphm pep., https://xmpp.org/about/xsf/ipr-policy
  785. ralphm we don't knowingly accept XEPs with such problems
  786. jonas’ larma, it necessarily is, if we go by the assumption that the wire format is copyrighted (which is what all this discussion is about)
  787. ralphm pep., and if there's a current spec with IPR issues, that'd be good to know. I think the only appropriate action is to Reject and/or Obsolete it.
  788. ralphm (depending on what state it currently has)
  789. jonas’ I think if the spec has IPR issues, it needs to be removed altogether (akin to Retraction)
  790. larma jonas’, the wire format is protobuf, the specification of protobuf is under CC-BY (from Google)
  791. Kev We have actually removed some XEPs (ok, JEPs) from existence in the past, as much as possible.
  792. Kev Haven't we?
  793. jonas’ larma, but the protobuf files may be under GPL
  794. flow guess it is really sensible to simplly ask OWS if they would put the libsignal wireformat also in the public domain
  795. jonas’ larma, but the .proto files may be under GPL
  796. Kev Although I don't think that would be helpful here.
  797. ralphm Kev: at least one, yes. But I don't remember why.
  798. larma jonas’, the .proto files are not needed to read protobuf
  799. dwd jonas’, Based on past discussions with Matthew@Matrix, it was the constants that were the problem. The wire format can be reverse engineered in principle, but the cnstants can only be obtained from th source code and are in principle copyrightable.
  800. larma .proto files are like xml schemas
  801. jonas’ dwd, awful.
  802. larma you can perfectly work without a schema
  803. dwd jonas’, Well, it's their call, of course.
  804. rion has joined
  805. lorddavidiii has left
  806. dwd But, FWIW, see the info value for the HKDF here: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/olm.md
  807. jonas’ larma, then replace "wire format" with "constants which influence the output" in my statement
  808. eevvoor a constant can stand under copyright? interesting.
  809. ralphm Kev: XEP-0028
  810. Kev ralphm: Indeed.
  811. dwd eevvoor, My understanding is that court action has been threatened on that basis, at least.
  812. beta has left
  813. pdurbin has left
  814. pep. I guess "a constant can stand under copyright" is provided by the Game Boy and Nintendo.
  815. pep. I guess "a constant can stand under copyright" is proved by the Game Boy and Nintendo.
  816. eevvoor I see, dwd.
  817. dwd eevvoor, I'm not convinced I agree, but that's somewhat moot unless I have a shitload of money and some very good lawyers.
  818. pep. I don't know if there is any such case though yes (Nintendo)
  819. stpeter has joined
  820. lorddavidiii has joined
  821. eevvoor open source lawyers would be fine ...
  822. ralphm WIthout the history of the actions of Moxie and/or OWS, I would make such a fuss about it.
  823. eevvoor plus libre of course
  824. ralphm would not
  825. ralphm Now, I'm not that willing to take a guess.
  826. mimi89999 has left
  827. mukt2 has left
  828. eevvoor Unfortunately courts are often unlocial expecially concerning topics were you need some expertise in, like SW.
  829. eevvoor Unfortunately courts are often unlocial especially concerning topics were you need some expertise in, like SW.
  830. beta has joined
  831. mukt2 has joined
  832. adiaholic has left
  833. jonas’ bonus if you’re in juryland
  834. mimi89999 has joined
  835. adiaholic has joined
  836. tao has joined
  837. stpeter has left
  838. emus has joined
  839. adiaholic has left
  840. sonny has left
  841. sonny has joined
  842. Yagiza has left
  843. Lance has joined
  844. mukt2 has left
  845. lorddavidiii has left
  846. mathijs has left
  847. mathijs has joined
  848. lorddavidiii has joined
  849. Alex has left
  850. eevvoor has left
  851. Lance has left
  852. adiaholic has joined
  853. mukt2 has joined
  854. tao has left
  855. tao has joined
  856. tao has left
  857. tao has joined
  858. Alex has joined
  859. mathijs has left
  860. mathijs has joined
  861. sonny has left
  862. mukt2 has left
  863. sonny has joined
  864. mathijs has left
  865. mathijs has joined
  866. calvin has left
  867. larma So the question that remains regarding OMEMO is, if we are allowed to use the 4 strings that are used as info bytes in the HKDF function and just write those strings in our specification?
  868. mukt2 has joined
  869. Steve Kille has left
  870. moparisthebest > No Extension shall be approved by the XSF or its constituent committees if there are Claims to the Extension itself, or any Claims that would prevent perpetual, unrestricted, royalty-free use of the Extension in a compliant Implementation or Deployment by any interested party.
  871. moparisthebest I still think that's utterly meaningless without defining a jurisdiction
  872. dwd larma, Well, we'd need to actually specify the protobuf stuff at some point too, but yes.
  873. pep. moparisthebest, Delaware by default I assume?
  874. pep. I'd also be interested to know the answer though
  875. moparisthebest doesn't look like that document says that
  876. larma dwd, but we can easily derive protobuf from the wire, so that's nothing we need to handle (yes, it's not in the XEP, but it's also not under GPL)
  877. andrey.g has left
  878. larma *handle from legal perspective
  879. dwd larma, Yes.
  880. moparisthebest re: the copyright-ability of strings https://dacut.blogspot.com/2008/03/oracle-poetry.html though I don't think this specifically has been tested in court
  881. jonas’ moparisthebest, delawere is where the XSF is constituted
  882. jonas’ moparisthebest, delaware is where the XSF is constituted
  883. moparisthebest jonas’, sure but that says "by any interested party" not "by any interested party in delaware"
  884. pep. Which might also mean that the XSF only cares about stuff that's legal in the US, as for elsewhere "it depends" (if members have incentives to push for it?)
  885. pep. Which might also mean that the XSF only cares about stuff that's legal in the Delaware, as for elsewhere "it depends" (if members have incentives to push for it?)
  886. pep. Which might also mean that the XSF only cares about stuff that's legal in Delaware, as for elsewhere "it depends" (if members have incentives to push for it?)
  887. moparisthebest and the lawyer on staff that tries to interpret this stuff is who exactly?
  888. eevvoor has joined
  889. jonas’ there isn’t any on staff, but I guess the Board would consult one if they wanted to be sure
  890. jonas’ in this case I think that the ambiguity alone is reason enough to see it as a problem
  891. Nekit has left
  892. pdurbin has joined
  893. moparisthebest this kind of thing is always ambiguous, which is why I don't think the XSF should even attempt it
  894. moparisthebest any serious company is going to have to do their own leg work here anyway, they can't trust the XSF has vetted all IPR and everything else
  895. larma Assuming I publish a document with those constants under the public domain, can the XSF use those constants referencing my document as a source?
  896. moparisthebest re protobufs and functionality in EU at least https://en.wikipedia.org/wiki/SAS_Institute_Inc_v_World_Programming_Ltd > The EU Court of Justice ruled that copyright protection does not extend to the software functionality, the programming language used and the format of the data files used by the program. It stated that there is no copyright infringement when a company which does not have access to the source code of a program studies, observes and tests that program to create another program with the same functionality.
  897. mukt2 has left
  898. larma moparisthebest, there even is a law in the EU that explicitly allows reverse engineering
  899. sonny has left
  900. jonas’ larma, maybe, but you will be liable if those constants are in fact under GPL and you republished them in the public domain.
  901. jonas’ if they cannot be reasonably found via reverse engineering, for example because they’re not part of what’s on the wire and they would have to be brute forced
  902. mukt2 has joined
  903. serge90 has left
  904. pdurbin has left
  905. Steve Kille has joined
  906. larma jonas’, yeah I was considering to get legal confirmation (because I am certain there are ways to extract those constants not directly from the source code). But obviously any legal advice I may get won't cover the whole world, so that's why I would just do it myself and put it under public domain so that it doesn't matter what place in the world others are situated in.
  907. debacle has left
  908. serge90 has joined
  909. moparisthebest he wouldn't be legally liable, the person that used them would
  910. larma moparisthebest, you sure? How can the person know that I don't have license to publish them?
  911. moparisthebest exactly
  912. larma well that would be the case for everything then
  913. moparisthebest consider a recent real world example, how many of you use nginx ? are you legally allowed to?
  914. moparisthebest russian govt claims you are not
  915. larma I think they claim the author was not allowed to relicense it
  916. moparisthebest they claim no one was ever legally allowed to use it from the beginning
  917. sonny has joined
  918. waqas has joined
  919. calvin has joined
  920. andrey.g has joined
  921. eevvoor has left
  922. Wojtek has joined
  923. lovetox has joined
  924. tao has left
  925. mathijs has left
  926. mathijs has joined
  927. eevvoor has joined
  928. Lance has joined
  929. mathijs has left
  930. mathijs has joined
  931. emus has left
  932. eevvoor has left
  933. Lance has left
  934. mathijs has left
  935. mathijs has joined
  936. mathijs has left
  937. mathijs has joined
  938. lovetox has left
  939. larma moparisthebest, that might be technically correct, the question is who is liable for that
  940. sonny has left
  941. Maranda has left
  942. Maranda has joined
  943. larma I haven't heard of any case where microsoft would try to sue the end user that bought an illegal license. They just get blocked from using that license in the future. Those that sell the license are sued
  944. sonny has joined
  945. emus has joined
  946. lovetox has joined
  947. tao has joined
  948. debacle has joined
  949. moparisthebest if you do something illegal, you can't get out of it by saying "well that guy over there told me to"
  950. moparisthebest you are liable, and then maybe you can sue that guy over there for your damages, maybe
  951. mathijs has left
  952. mathijs has joined
  953. calvin has left
  954. calvin has joined
  955. lovetox has left
  956. pdurbin has joined
  957. jonas’ moparisthebest, I’m not so sure about that.
  958. jonas’ moparisthebest, if you buy a wifi access point in a store, and that access point is misconfigured by the vendor in a way which violates radio regulation, you wouldn’t be liable for that.
  959. jonas’ likewise I’d say if someone explicitly publishes some work under a given license, it is fair to assume that you may use that work under that license. If they are lying or incorrect about their assumption that they have the rights to publish it under that license, that’s not your fault, and you should not be liable for that
  960. jonas’ I’d assume that you need to immediately rectify your misusage of the work as soon as it is brought to your attention though
  961. APach has left
  962. APach has joined
  963. pdurbin has left
  964. Nekit has joined
  965. Daniel has left
  966. Daniel has joined
  967. calvin has left
  968. calvin has joined
  969. Nekit has left
  970. Nekit has joined
  971. mukt2 has left
  972. Lance has joined
  973. sonny has left
  974. mukt2 has joined
  975. sonny has joined
  976. j.r has joined
  977. larma and you can probably sue that person that was lying for damage
  978. larma like if your businnes relies on the fact that it was under that license but it isn't
  979. moparisthebest probably would have needed to pay him for it in that case, otherwise you don't have a business relationship or contract
  980. moparisthebest bottom line it's always on the person/business actually distributing the code, the XSF shouldn't even be trying to interepret/enforce anything imho
  981. j.r has left
  982. j.r has joined
  983. andy has left
  984. mukt2 has left
  985. j.r has left
  986. andy has joined
  987. sonny has left
  988. Lance has left
  989. mukt2 has joined
  990. Wojtek has left
  991. mukt2 has left
  992. tao has left
  993. Nekit has left
  994. sonny has joined
  995. !XSF_Martin has left
  996. sonny has left
  997. Steve Kille has left
  998. pdurbin has joined
  999. lovetox has joined
  1000. !XSF_Martin has joined
  1001. pdurbin has left
  1002. sonny has joined
  1003. Steve Kille has joined
  1004. j.r has joined
  1005. lorddavidiii has left
  1006. sonny has left
  1007. lorddavidiii has joined
  1008. sonny has joined
  1009. moparisthebest has left
  1010. neshtaxmpp has left
  1011. goffi has left
  1012. Tobias has left
  1013. Steve Kille has left
  1014. moparisthebest has joined
  1015. sonny has left
  1016. Steve Kille has joined
  1017. wurstsalat has left
  1018. lorddavidiii has left
  1019. karoshi has left
  1020. mukt2 has joined
  1021. sonny has joined
  1022. neshtaxmpp has joined
  1023. mukt2 has left
  1024. lovetox has left
  1025. j.r has left
  1026. j.r has joined
  1027. Dele (Mobile) has left
  1028. mr.fister has joined
  1029. calvin has left
  1030. waqas has left
  1031. paul has left
  1032. mr.fister has left
  1033. sonny has left
  1034. sonny has joined
  1035. emus has left