[19:01:31] Meeting started by prometheanfire [19:01:47] Meeting chairs are: dabbott, robbat2, swift, antarus, prometheanfire, [19:02:01] .topic roll call [19:02:11] Current subject: roll call, (set by prometheanfire) [19:02:32] robbat2: SwifT dabbott antarus ping [19:02:36] pong [19:02:39] here [19:02:41] here [19:02:42] here [19:03:02] cool, all here [19:03:21] dabbott: logging the meeting? [19:03:28] yes [19:03:41] next activity tracker task is in july [19:04:08] Current subject: how are we doing on the mailing address change?, (set by prometheanfire) [19:04:19] LINK: https://bugs.gentoo.org/show_bug.cgi?id=613950 [613950 – Change of Mailing Address: tracker bug] [19:04:30] about halfway on the list of bugs [19:04:49] a bunch of them need bank records to show a paper trail [19:04:56] ah [19:05:09] since we have no other bills that come in [19:05:44] ok, next [19:05:55] no update on irs, waiting on bank [19:05:59] paypal may be a problem, I'm afraid to do anything there, they have my name and address I think [19:06:18] we need bank statements for the paypal one anyway [19:06:18] speaking of bank [19:06:37] Current subject: getting control of the bank, (set by prometheanfire) [19:06:53] dabbott: mind updating the others on your progress? [19:07:15] When I talked to them on friday they just need to do the change afaik [19:07:37] which is amazing to me :D [19:07:43] so hopefully end of week there [19:07:44] did not say there was any problem, no one has looked at the documents as yet [19:08:23] they know who I am summers had added me to the account just not followed through setting it up [19:09:01] i could have sent them a sig and been approved if he would have done it [19:09:01] cool, next? [19:09:46] Current subject: insurance updates, (set by prometheanfire) [19:09:54] LINK: https://bugs.gentoo.org/show_bug.cgi?id=592198 [592198 – D&O insurance] [19:10:17] I've sent out one of the two proposals (the other is in underwriting) [19:10:53] the one we have to review is not for D&O though [19:11:05] the D&O one is in underwriting [19:11:41] anyone review it? [19:12:31] personaly I could care less, if the rest of the board wants it its fine by me [19:13:03] I'm kinda in the same place on this one, it could be a nice to have, but I'm not sure if we should pursue it [19:13:18] same here [19:13:28] yeah, i want to wait for the D&O response [19:13:34] to figure out where it stands on the budget line [19:13:57] k [19:14:00] most of it is irrelevant to us [19:14:06] tabling it for now then [19:14:29] sounds good [19:14:30] alicef: pre-ping [19:14:35] Current subject: Do we need date of birth in developer apps, (set by prometheanfire) [19:14:55] I sent out my proposed email and got slaped down [19:15:15] so, if anyone wants to try again... [19:16:35] can we side-step it entirely then, and just have some statement: [19:16:52] by joining, you agree you are able to enter into contractual agreements [19:17:15] that sounds good to me [19:17:30] Thats too simple. Vhat abaut minors? [19:18:21] can you think of a simple way to include them in the above, without complicating it? [19:18:51] No. [19:20:12] ok, next? [19:20:21] or action? [19:20:43] ok, does leaving out minors really matter for this? [19:21:11] if they are a minor, and assert yes to the above, are we in the clear ourselves? [19:21:11] It would have excluded several devs. [19:21:20] just keep doing it the way we have been unless someone comes up with a better solution, if its not broke don't fix kind of thing [19:21:23] it isn't about having a simple statement imo; we need to inform developers (and aspiring developers) why we need some kind of information. As long as that isn't clear, the statements will be under continuous debate [19:21:36] if we have the statement, we can drop the DOB need [19:23:04] let's move on for the moment [19:23:07] k [19:23:08] alicef: reping [19:23:24] in the mean time [19:23:27] Current subject: open bugs, (set by prometheanfire) [19:23:35] LINK: https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=VERIFIED&email2=trustees&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&known_name=TrusteesOpenBugs&list_id=3290194&order=Last%20Changed&query_based_on=TrusteesOpenBugs&query_format=advanced&resolution=--- [Bug List: TrusteesOpenBugs] [19:24:35] there are a couple of updates [19:24:41] LINK: https://bugs.gentoo.org/show_bug.cgi?id=605336 [Bug Access Denied] [19:24:49] i see 3 things there to do: dilfridge filed his invoices, so I can reimburse him now [19:24:52] the invoices are submitted [19:25:26] ok, so robbat2 will do that [19:25:30] the other two? [19:25:32] bug 318841 is a license question, with implications of breaking the install media [19:25:35] robbat2: https://bugs.gentoo.org/318841 "sys-kernel/linux-firmware incomplete LICENSE"; Gentoo Linux, New packages; IN_P; ulm:licenses [19:26:00] mostly that we are taking a stricter stance than upstream or debian on some firmware [19:26:41] when we put RESTRICT=bindist, the firmware will no longer be on the install media [19:27:23] should trustees override licenses team on this, based on what upstream does? [19:27:24] ya, not sure that's workable [19:28:43] (bug 531540 we can ignore, it only shows updated because of a change in the tracker bug) [19:28:46] robbat2: https://bugs.gentoo.org/531540 "dev-libs/openssl: revise inclusion of elliptic curves with bindist USE flag"; Gentoo Linux, Current packages; CONF; aballier:base-system [19:29:24] ah, k [19:29:30] hi [19:29:31] i just asked ulm to join re 318841 [19:29:37] hm? [19:29:38] ah [19:29:53] per 318841, originally you were going to add just a license statement [19:30:00] but your recent comment said add RESTRICT=bindist too [19:30:09] why doesn't upstream care? [19:30:13] would that not break any install media using the firmware [19:30:21] RESTRICT=mirror too [19:30:25] aren't they also distributin? [19:30:35] because catalyst wouldn't have it on the media? [19:30:45] upstream is distributing the firmware yes [19:31:25] robbat2: some of the firmware blobs seem to come without any license at all [19:31:27] why do we care when they don't? [19:31:47] because without a license we cannot redistribute them [19:31:55] (not saying we are wrong, but more so looking for their rationale) [19:32:04] why does our redistribution differ from upstream redistribution? [19:32:07] what do they know that we don't :) [19:32:33] then there are others that alledgedly are GPL licensed but their source is not available [19:32:52] which has the same consequence, namely that it's not distributable [19:33:21] can we get a USE="proper-licensing" that fetches a different tarball which contains validated firmware? [19:33:33] ulm: if upstream redistributes it, and we also redistribute it; surely we have a lower risk profile than upstream? [19:33:58] robbat2: upstream owns copyright so they can do what they want [19:34:14] upstream is the linux-firmware.git repo owner [19:34:17] not the creator of the firmware [19:34:27] https://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git [19:34:52] yes, exactly [19:35:09] so if the linux-firmware repo owner violates copyright, it follows that we're allowed to violate it too? [19:35:16] no [19:35:33] I want to understand if its by accident, on purpose, or if they have some other circumstance [19:35:38] have we reported the licensing problems to the linux-firmware.git project owner? if not, it might be a good idea to do so, perhaps they have more info on these things? [19:35:48] SwifT: yes we have [19:35:53] response? [19:36:04] SwifT: yes, that's covered in the bug, gregkh took it very far up in the linux foundation, to no real resolution [19:36:12] let me look up the history [19:36:27] wasn't that in the bug? [19:36:37] if our main concern right now is to not break the installation media, is the only alternative (beyond ignoring the issue) to break up and only pull the correctly licensed firmware ? [19:36:43] I don't see it in the bug [19:37:10] give me a minute [19:38:00] ok, it was reported upstream in Feb. 2013 [19:38:31] in the spirit of pragmatic solutions, keep the ' According to upstream, all of them should be redistributable.' statement, augment it to say that we disagree, but will continue to redistribute it for working install media [19:38:35] and it went up to the Technical Advisory board of the Linux Foundation [19:38:50] who tasked GregKH with it [19:39:03] according to a mail from him in March 2013 [19:39:14] then we sent a reminder in May 2013 [19:39:30] and since then nothing seems to have happened [19:39:31] I mean I see two arguments here, an ethical argument about following the law [19:39:38] and an argument about legal exposure [19:40:08] robbat2: I don't think we have a statement from upstream that all are distributable [19:40:59] "This repository contains all these firmware images which have been [19:41:00] extracted from older drivers, as well various new firmware images which [19:41:00] we were never permitted to include in a GPL'd work, but which we _have_ [19:41:01] been permitted to redistribute under separate cover." [19:41:15] the wording in the last version of that note is "Most likely, some of the images are not redistributable." and I believe that it accurately describes the situation [19:41:58] https://packages.debian.org/sid/firmware-misc-nonfree is that a stripped down version of the same? [19:42:00] antarus: who is the "we" in "we have been permitted"? [19:42:35] ulm: their statement is implicit in that they are redistributing them [19:43:08] I think my point is that from a legal perspective the risk of action seems low [19:43:11] and the benefit high [19:43:54] I'm less convinced on the social contract angle (does it allow us to take this sort of action?) [19:45:02] as an example of breakage, the firmware that we decided was not redistributable includes really common stuff like e100 [19:46:37] is it really breakage as long as it is installable? [19:46:51] network makes it un-fetchable [19:47:03] you need to include the firmware on the install media to start up the network :-) [19:47:05] bootstraping problem [19:47:27] then sort it out with the copyright holder? [19:49:00] wasn't our discussion from 2013 that attempt already, to no avail? [19:49:30] yes, no progress because linux upstream didn't do their homework [19:50:10] prod them again? [19:50:12] so we're faced with the choice of: break install media || ethically follow law [19:50:22] prometheanfire: seems like a possible action [19:50:37] prometheanfire: in particular if there are outstanding output from last discussion [19:50:44] yep [19:50:53] robbat2: we should at least add a license notice as suggested in bug 318841 [19:50:55] https://bugs.gentoo.org/318841 "sys-kernel/linux-firmware incomplete LICENSE"; Gentoo Linux, New packages; IN_P; ulm:licenses [19:50:59] it seems like the original question was never resolved [19:51:07] I would rather see the ebuild reflect the actual state, and if necessary override it when building media (if that is the course that would be suggested) [19:51:09] yes, definetly add the notice, but no RESTRICT [19:51:09] even if that wouldn't go along with any RESTRICT [19:51:15] yep :) [19:51:33] yep, add notice, no restrict, prod upstream again [19:52:06] ulm: where was the gregkh / LF TAB piece, so we can link to it from the text? [19:52:15] prometheanfire: wouldn't it make more sense that catalyst overrides it, but let the ebuild reflect it as suggested by the bug? [19:52:48] robbat2: e-mail to licenses@ [19:52:57] Mon, 25 Mar 2013 06:30:26 -0700 [19:53:00] i'd have to double-check, but I think catalyst can't override RESTRICT=bindist [19:53:12] for a single package [19:54:01] can we say "Most likely, some of the images are not redistributable"? [19:54:12] or choose a weaker wording, saying that we don't know or aren't sure? [19:54:52] It is likely, instead of most likely? [19:55:23] "Possibly"? [19:55:37] I'd rather say that we don't know (something akin to "Although the firmware is distributed through the linux-firmware project, some of the firmware is not accompanied by a proper license attribution, making it difficult for us to know if the files are redistributable or not." [19:55:40] "Most likely, upstream redistribution of some firmware images may conflict with the licenses or lack thereof on the images" [19:56:14] wfm [19:56:23] k [19:56:35] so, we good? [19:56:36] sgtm [19:56:39] +1 [19:56:44] +1 [19:56:49] thanks for being available on short notice ulm [19:57:04] is it on the statement that robbat2 made? (just to be certain) [19:57:36] so, full text of the notice will be: [19:57:37] "Linux firmware images are distributed under a variety of licenses, many of them being non-free. Most likely, upstream redistribution of some firmware images may conflict with the licenses or lack thereof on the images. You will need to check the WHENCE and LICEN[CS]E.* files in the package for specific licensing terms." [19:58:25] and no RESTRICT [19:58:30] k [19:58:33] +1 [19:58:35] ok [19:58:40] 2+1 [19:58:43] ok [19:59:12] do we have time to talk about bitcoin? [20:01:15] LINK: https://bugs.gentoo.org/show_bug.cgi?id=476718 [476718 – Request for bitcoin donation support] [20:01:17] bug 476718 [20:01:20] prometheanfire: https://bugs.gentoo.org/476718 "Request for bitcoin donation support"; Gentoo Foundation, Proposals; CONF; rich0:trustees [20:01:29] as treasurer, I will re-assert what the bug noted before: i'm only comfortable if we accept it in a manner that immediately converts it to another currency [20:01:39] and not carry a balance in it [20:01:40] the idea is to accept bitcoin donations and immediatly cash out [20:01:50] yep, I think that's for the best [20:02:03] yup agree to that... accountancy with multiple currencies is a nightmare [20:02:23] it's more that bitcoin has special tax implications since it's not entirely a currency [20:02:40] multi-currency accounting itself is not a problem [20:02:51] just more painful than single-currency accounting [20:03:22] (and for the record, i'm not anti-bitcoin, i personally have a diverse investment portfolio that does include bitcoin) [20:03:26] the cashing out is more to avoid the volatility [20:03:51] i'd say it's to avoid the capital gain/loss side effects of the volatility [20:04:00] whatever the reason, I think we all agree to it ;) [20:04:11] yep [20:04:12] +1 [20:04:19] +2 [20:04:26] signing up for some of the providers needs us to fix the bank accounts first [20:04:36] don't we need to like, yeah have accounts people can donate to? [20:05:11] this can depend on the bank then [20:06:10] next? [20:06:43] robbat2: might be an idea to look into services that converts bitcoin to currency at time of donation, we do that for some other organisations [20:07:01] the github ToS issue on bug 611376 had some followup questions [20:07:03] robbat2: https://bugs.gentoo.org/611376 "New GitHub Terms of Service"; Gentoo Foundation, Proposals; CONF; ulm:trustees [20:07:34] specifically, that we distribute some patches in the tree, and the patches have licenses that are violated by the GitHub TOS [20:07:57] i think just moving those patches to distfiles would suffice [20:08:28] with the exeption of licenses/GPL-2 itself [20:09:28] that sounds ok [20:09:33] (other than the above, I have no further business) [20:09:42] it's rather licenses/* (but it doesn't change the argument of course) [20:10:48] GPL-2 is a useful example, because the FSF wants it included in every package that's GPL-2, and they themselves said the GH TOS are ok [20:13:19] for the moment then, RESO:talk-to-FSF-again [20:13:39] ya [20:13:44] ok [20:13:54] ulm: ok if I draft and email and run it by you before sending it to licensing@fsf? [20:14:00] sure [20:15:06] prometheanfire: any other business? [20:15:48] nope, just picking the next meeting [20:16:08] may 21? [20:16:35] Current subject: Date of Next Meeting - Sun May 21 2017 19:00 UTC, (set by dabbott) [20:16:44] fine here [20:16:44] still good with me [20:17:13] antarus: SwifT ? [20:17:24] ok [20:17:31] had to check my calendar, sorry for the delay [20:18:23] ok, going for that then [20:18:43] think that's it, unless someone has something else? [20:19:10] k, ending [20:19:13] Meeting ended by prometheanfire, total meeting length 4661 seconds