diff options
authorWilliam Hubbs <>2020-02-09 15:41:21 -0600
committerWilliam Hubbs <>2020-02-09 15:43:02 -0600
commita981ae8b2e89107084fff4f16b9c528e6e23ae6d (patch)
parentAdd README file about licensing. (diff)
add meeting log for 2020-02-09
Signed-off-by: William Hubbs <>
2 files changed, 238 insertions, 0 deletions
diff --git a/meeting-logs/20200209.txt b/meeting-logs/20200209.txt
new file mode 100644
index 0000000..bf6ba82
--- /dev/null
+++ b/meeting-logs/20200209.txt
@@ -0,0 +1,222 @@
+13:00 <@WilliamH> Ok folks, let's get started...
+13:00 <@WilliamH> the agenda:
+13:00 * gyakovlev here
+13:01 * ulm here
+13:01 <@WilliamH> roll call:
+13:01 * slyfox here
+13:01 * dilfridge here
+13:01 * bonsaikitten here
+13:01 * WilliamH here
+13:01 * Whissi here
+13:02 <@WilliamH> next point: licensing ebuilds as gpl2+
+13:02 <@WilliamH> there were 3 questions submitted for votes:
+13:02 <@WilliamH> Let's address the first one.
+13:03 <@dilfridge> ok so, fundamental question, do we consider the "+" as desirable?
+13:03 <@WilliamH> Can developers individually decide to license their ebuilds as gpl2+ if they meet the licensing requirements?
+13:03 <@ulm> dilfridge: I do, but I'm still a but sceptical if it will work in practice
+13:03 <@dilfridge> (in our context)
+13:04 <@bonsaikitten> imo not desirable: I don't understand gpl3, I can't predict what gpl4 will be, so I don't like agreeing to terms I don't understand
+13:04 <@ulm> OTOH, the decision would be easy to revert, going from GPL-2+ to GPL-2 is trivial
+13:04 <@gyakovlev> dilfridge: I think it's not, I personally dislike + clause in any license
+13:04 <@dilfridge> not once someone has committed gpl3+
+13:04 <@slyfox> says "We will release our contributions to Gentoo as free software, metadata or documentation, under the GNU General Public License version 2 (or later, at our discretion) or the Creative Commons - Attribution / Share Alike version 2 (or later, at our discretion)."
+13:04 <@ulm> dilfridge: we won't allow GPL-3+
+13:05 <@dilfridge> ulm: that allows for a big mess
+13:05 <@dilfridge> becaus,
+13:05 <@dilfridge> imagine someone starts up an overlay, and uses tree ebuilds as basis, but bumps all to gpl3+
+13:05 <@dilfridge> then we can't merge back anymore
+13:05 <@bonsaikitten> dilfridge: is that a valid action?
+13:06 <@bonsaikitten> ... so much confusion, I'd prefer just not doing that
+13:06 <@gyakovlev> ^
+13:06 <@ulm> dilfridge: same as if someone would add an overlay with all ebuilds written from scratch and licensed under CDDL
+13:06 <@ulm> so not really anything new
+13:07 <@dilfridge> bonsaikitten: if I edit something, I have copyright on my contributions, and if I decide gpl3+ on my contributions, the combination of the previous part and my contributions will also be gpl3+
+13:07 <@dilfridge> "written from scratch" is the difference
+13:07 <@WilliamH> ulm: hrm I don't know about the cddl example because ebuilds are source.
+13:07 <@bonsaikitten> dilfridge: but the existing bits aren't, so it's not, and I'm getting a headache
+13:08 <@ulm> linux seems to get along well with their mixed license model
+13:09 <@ulm> but yeah, chances that we would get the whole tree relicensed to + are slim
+13:09 <@ulm> and it's not clear with what our ebuilds need to be license-compatible
+13:09 <@WilliamH> dilfridge: But, your example of an ebuild coming from an overlay that is gpl3+ is a possible concern.
+13:10 <@WilliamH> ulm: is linux mixed license? I thought it was gpl2 only
+13:10 <@gyakovlev> some parts are dual-licensed, like most of DRM (graphical) stack is GPL-2/MIT
+13:10 <@WilliamH> I always heard Linus doesn't like gpl3
+13:10 <@slyfox> it has a lot of dual GPL/BSD code and other flavours
+13:10 <@ulm> there are files under GPL-2+
+13:11 <@slyfox> you can frep for SPDX tags
+13:11 <@WilliamH> Oh ok, I didn't know about the dual licensing.
+13:12 <@ulm> see LICENSES/other/ in the kernel tree
+13:12 <@gyakovlev> but do we really want more licensing variations? what's the benefit here?
+13:13 <@gyakovlev> I'm not sarcastic, can someone explain in simple terms?
+13:13 <@WilliamH> gyakovlev: I'm not sure of the benefit either, but I don't really have a strong opinion either way.
+13:13 <@WilliamH> This all started because we have an eclass that is gpl 2+
+13:14 <@ulm> the only benefit I can see is improved compatibility between GPL-3 and CC-BY-SA-4.0
+13:14 <@ulm> but it's one-way only
+13:15 <@ulm> so you cannot take GPL licensed examples and include them e.g. in the devmanual
+13:15 <@WilliamH> Are we ready to vote?
+13:15 <@ulm> I am
+13:15 <@WilliamH> ok I'll hang out a minute I didn't see your msg ulm until after I asked.
+13:15 <@WilliamH> ok.
+13:16 <@WilliamH> Let's vote. can developers license their ebuilds under gpl2+?
+13:16 * slyfox yes
+13:17 <@Whissi> WAIT. You dropped 'individually', not?
+13:17 <@WilliamH> Whissi: same thing, the word individually is sort of redundant
+13:17 <@ulm> we should vote on the exact wording of a.
+13:17 <@WilliamH> ok
+13:17 <@WilliamH> one sec.
+13:17 <@ulm> "provided that they fulfill relicensing requirements" is also important
+13:18 <@WilliamH> a. Can developers individually decide to license their ebuilds as GPL-2+
+13:18 <@WilliamH> rather than 'GPL-2 only' (provided that they fulfill relicensing
+13:18 <@WilliamH> requirements)?
+13:18 <@WilliamH> vote:
+13:18 * slyfox yes
+13:19 * dilfridge no
+13:19 * gyakovlev no
+13:19 * bonsaikitten no
+13:19 * Whissi no
+13:19 * ulm yes
+13:19 * WilliamH abstain
+13:19 <@WilliamH> the motion doesn't carry.
+13:20 <@WilliamH> The next question:
+13:20 <@ulm> hm, what do we do about that one existing eclass that is under GPL-2+
+13:20 <@ulm> ?
+13:20 <@ulm> can it stay unchanged?
+13:20 <@gyakovlev> contact author and ask for re-license?
+13:21 <@WilliamH> agreed
+13:21 <@WilliamH> gyakovlev++
+13:21 <@slyfox> which ebuild is that by the way? does it have many users?
+13:21 <@ulm> ant-tasks.eclass
+13:21 <@slyfox> s/ebuild/eclass/
+13:21 <@gyakovlev> it should be easy to go back like ulm said.
+13:21 <@WilliamH> Do we need to vote on the other two points or are they by default no?
+13:21 <@WilliamH> I'll post the first one:
+13:22 <@WilliamH> b. Should developers be encouraged to use GPL-2+ for new ebuilds
+13:22 <@WilliamH> (whenever possible)?
+13:22 <@dilfridge> well that's kind of an obvious no now
+13:22 <@WilliamH> vote:
+13:22 <@WilliamH> yes.
+13:22 <@WilliamH> I agree.
+13:22 <@ulm> we could only produce a contratiction if we would on it
+13:22 <@WilliamH> the next one is as well:
+13:22 <@ulm> *contradiction
+13:22 <@WilliamH> I'll post it here for the record:
+13:23 <@WilliamH> c. Should we start collecting permissions from contributors to relicense
+13:23 <@WilliamH> their GPL-2 work as GPL-2+? This will be helpful both to 1. and 2.
+13:23 <@WilliamH> another no.
+13:23 <@slyfox> *nod*
+13:24 <@WilliamH> moving on.
+13:24 <@WilliamH> open bugs with council participation.
+13:24 <@WilliamH> bug 662982
+13:24 <+willikins> WilliamH: "[TRACKER] New default locations for the Gentoo repository, distfiles, and binary packages"; Gentoo Linux, Current packages; CONF; zmedico:dev-portage
+13:24 <@WilliamH> Are the snapshots fixed?
+13:25 <@gyakovlev> they are, but last time there was something left to be done for delta users.
+13:25 <@ulm> that would be bug 574752
+13:25 <+willikins> ulm: "Rename portage-YYYYMMDD.tar* snapshots with gentoo-YYYYMMDD.tar*"; Gentoo Infrastructure, Other; IN_P; mgorny:infra-bugs
+13:26 <@ulm> wait, the name of the top-level dir includes the date now?
+13:26 <@Whissi> No.
+13:27 <@Whissi> toplevel was changed from portage to gentoo
+13:27 <@gyakovlev> yes, it hinders delta computation
+13:27 <@ulm> Whissi: ?
+13:27 <@gyakovlev> date was added
+13:27 < veremitz> date is indeed addeed/included
+13:27 <@ulm> which breaks delta
+13:27 < veremitz> iirc robbat2 was doing testing with deltas?
+13:28 < veremitz> new algo?
+13:28 <@ulm> why must the tld name include the date?
+13:28 < veremitz> ¯\_(ツ)_/¯
+13:28 <@ulm> seems it has worked before without it?
+13:28 <@Whissi> Sorry, I don't see timestamp in tarball
+13:28 <@Whissi>
+13:29 < veremitz> Whissi: top level folder
+13:29 <@gyakovlev> robbat2 mentioned that xz compression on deltas makes them almost like the old ones, but I don't remember clearly.
+13:29 <@Whissi> There's just one single portage folder
+13:29 <@Whissi> of course I picked the old portage one
+13:29 <@Whissi> :[
+13:29 < veremitz> gentoo-YYYYMMDD iirc :p
+13:29 < veremitz> not even THHMMSSZ :P
+13:29 <@gyakovlev> Whissi: gentoo-20191224/metadata/md5-cache/dev-db/postgis-9999
+13:30 <@gyakovlev> looking into new one
+13:30 <@Whissi> yeah, gentoo-latest.tar.xz has it :/
+13:30 <@slyfox> i suggest leaving it to the bug owners to sort the details out
+13:30 <@WilliamH> So the question still holds, why does it need the date in the name of the folder?
+13:30 <@WilliamH> But yeah we aren't going to fix it here.
+13:31 <@dilfridge> who came up with it?
+13:31 <@ulm> mgorny, it seems
+13:31 <@ulm> rationale, "to match tarball name"
+13:32 <@dilfridge> awesoem
+13:32 <@WilliamH> not a good rationale
+13:32 <@Whissi> Well, the version I tested in January worked and didn't have that changes.
+13:32 <@Whissi> So nice that this was changed "lately"
+13:32 <@WilliamH> mgorny: ^^
+13:32 <@WilliamH> please fix the folder to just be gentoo
+13:32 <+mgorny> WilliamH: so a better solution is when tarballs extract to random unpredictable directories and when you want to compare two snapshots, they just happen to overwrite one another?
+13:33 < veremitz> mgorny: wasn't a problem with portage-YYYYMMDD ?
+13:33 <@Whissi> mgorny: No, user is supposed to use -x.
+13:33 < veremitz> or was it?
+13:33 <@WilliamH> If you really want to compare move the old snapshot to anothe name
+13:33 <@WilliamH> another :p
+13:33 <@Whissi> If you extract tarball you should notice that. We don't need to hold hands all the time.
+13:33 <+mgorny> WilliamH: yes, because gentoo is special and users should use custom hacks to workaround it
+13:34 <@dilfridge> you break it you fix it :P
+13:34 <@Whissi> It's same like stage tarballs. From the beginning we are using -C ... are you going to propose adding a top folder in case someone wants to extract somewhere and compare...?
+13:35 < veremitz> fwiw .. the tar --transform option is really useful ;)
+13:35 <@slyfox> i suggest to move on
+13:36 <+mgorny> Whissi: so it all boils down to 'someone was stupid back in the day so we must not ever fix it'
+13:36 <+mgorny> we have new tarballs, it's an opportunity to fix it
+13:36 < veremitz> also WRT deltas.
+13:36 <+mgorny> if you want the old way, you have to come with a better argument than 'oh no, it broke my workflow'
+13:37 <@dilfridge> well, it *did* break something
+13:37 <+mgorny> or the more precise gentoo argument 'my eyes don't like it, so it must be changed to fit my preferences'
+13:37 <@WilliamH> mgorny: the same thing could be said about your argument.
+13:37 <@Whissi> mgorny: But if you introduce such a 'late fix' which is causing 'regressions'... we can't fix world in one step. So let's do the new tarball first if we don't come up will a solution which addresses everything and find a solution for that problem later.
+13:37 <@ulm> can we move on please? I think we don't want to micro-manage things at that level
+13:38 <@Whissi> *with
+13:38 <@slyfox> +1
+13:38 <+mgorny> Whissi: so you're asking to revert stuff, break portage AGAIN...
+13:38 < veremitz> and emaint sync!
+13:38 <@Whissi> mgorny: Let's talk about this later. We will have 4 more weeks until this will come up again ;)
+13:38 <@WilliamH> ok
+13:38 <@WilliamH> moving on.
+13:39 <@WilliamH> bug 700364
+13:39 <+willikins> WilliamH: "License council summaries under CC-BY-SA-4.0"; Gentoo Council, unspecified; IN_P; ulm:council
+13:40 <@ulm> proposed README file is here:
+13:40 <@ulm> also sent to council@g.o on 2020-01-20 (same text, except for two typo fixes)
+13:40 <@ulm> do you want to vote on it, or can I simply commit it?
+13:40 <@dilfridge> do it
+13:41 <@WilliamH> go for it.
+13:41 <@Whissi> +1 for the fixed README :)
+13:41 <@slyfox> no need to vote
+13:41 <@ulm> ok :)
+13:41 <@gyakovlev> vote yes by no voting =)
+13:41 <@WilliamH> moving on....
+13:41 <@ulm> apart from that, should I reassign the bug to myself?
+13:41 <@WilliamH> heh
+13:41 <@ulm> still waiting for 4 approvals, which can tak a long time
+13:42 <@ulm> *take
+13:42 * WilliamH is indifferent about that
+13:43 <@WilliamH> If it is assigned to council it will come up in the meetings...
+13:43 <@ulm> exactly, I can leave it alone for now, but then it will show up again
+13:44 <@Whissi> ulm: You also sent private mails, didn't you? Any bounces or can we expect that former council member at least received the mail?
+13:44 <@WilliamH> What does everyone else think?
+13:44 <@ulm> Whissi: no bounces, but no answer either
+13:44 <@Whissi> OK :/
+13:44 <@dilfridge> did vapier reply?
+13:44 <@ulm> I've sent private e-mail twice
+13:45 <@ulm> dilfridge: :)
+13:45 <@dilfridge> oh wow, that's like a flying pink elephant
+13:46 <@WilliamH> He replied so I guess he is ok with it.
+13:47 <@ulm> well, I suggest to leave the bug alone, and reassign next month if it's still open then
+13:47 <@WilliamH> ok fwm
+13:47 <@Whissi> Mh. Wasn't the CC list used as indiciator who still needs to ack? Only calchan left... who are the 4 missing?
+13:47 <@slyfox> sounds good. worth adding explicit comment to the bug?
+13:47 <@WilliamH> slyfox++
+13:48 <@ulm> Whissi: calchan, dberkholz, scarabeus, tanderson/gentoofan23
+13:48 <@ulm> slyfox: will do, when I reassign
+13:49 <@slyfox> thank you!
+13:49 <@WilliamH> ok, moving on...
+13:49 <@WilliamH> open floor
+13:49 * WilliamH listens
+13:49 * veremitz falls over some saucepans.
+13:50 < veremitz> oops, sorry.
+13:51 * WilliamH bangs the gavel
+13:51 <@WilliamH> meeting closed
diff --git a/meeting-logs/20200209.txt.asc b/meeting-logs/20200209.txt.asc
new file mode 100644
index 0000000..785d447
--- /dev/null
+++ b/meeting-logs/20200209.txt.asc
@@ -0,0 +1,16 @@