19:00:43 <achow101> #startmeeting 
19:00:43 <core-meetingbot> Meeting started Thu Feb 16 19:00:42 2023 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:43 <core-meetingbot> Available commands: action commands idea info link nick
19:01:01 <brunoerg> hi
19:01:06 <kanzure> hi
19:01:11 <achow101> #bitcoin -core-dev Meeting: achow101 aj amiti ariard b10c BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd
19:01:11 <achow101> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:01:14 <hebasto> hi
19:01:18 <pinheadmz> hi
19:01:22 <instagibbs_> hallo
19:01:32 <furszy> hi
19:01:34 <LarryRuane> Hi
19:01:40 <sipa> hi
19:01:41 <achow101> There are no pre-proposed meeting topics this week. Does anyone have any last minute topics?
19:01:54 <_aj_> hi
19:01:54 <sipa> (miniscript was merged, yay!)
19:02:16 <jonatack> hi
19:02:18 <instagibbs_> \o/
19:03:02 <achow101> #topic high priority for review
19:03:02 <core-meetingbot> topic: high priority for review
19:03:13 <achow101> https://github.com/orgs/bitcoin/projects/1
19:03:16 <Murch> Hey
19:03:17 <achow101> anything to add/remove/merge?
19:04:12 <pinheadmz> guess im chasing concept ack on https://github.com/bitcoin/bitcoin/pull/27101
19:05:10 <achow101> pinheadmz: added
19:07:03 <achow101> anything else to talk about?
19:07:27 <jonatack> #25325 may have been de-risked quite a bit by the fuzzing in #27011 (merged with significant cpu applied by sipa iiuc), have been running that patch for a few months, might be good to merge early enough in the release cycle once it has seen more acks
19:07:28 <gribble> https://github.com/bitcoin/bitcoin/issues/25325 | Add pool based memory resource by martinus · Pull Request #25325 · bitcoin/bitcoin · GitHub
19:07:30 <gribble> https://github.com/bitcoin/bitcoin/issues/27011 | Add simulation-based `CCoinsViewCache` fuzzer by sipa · Pull Request #27011 · bitcoin/bitcoin · GitHub
19:07:36 <_aj_> for anyone interested, inquisition's updated to 24.0 and now has PRs for op_vault and annex datacarrier open
19:07:48 <MacroFake> hi
19:08:07 <MacroFake> Can I have a topic?
19:08:14 <achow101> MacroFake: go ahead
19:08:17 <MacroFake> #proposedmeetingtopic copyright headers
19:08:30 <achow101> #topic copyright headers (MacroFake)
19:08:31 <core-meetingbot> topic: copyright headers (MacroFake)
19:08:49 <MacroFake> So currently some files have headers, and others don't. Not sure what ppl think about this and what should be done, if anything
19:09:07 <MacroFake> Most cpp files have headers, but not all
19:10:08 <sipa> See #26817 ?
19:10:10 <gribble> https://github.com/bitcoin/bitcoin/issues/26817 | doc: Remove copyright years (headers only) by MarcoFalke · Pull Request #26817 · bitcoin/bitcoin · GitHub
19:10:21 <MacroFake> sipa: No this is not about the years
19:10:28 <kanzure> do whatever maximizes the allowance for people to copy and distribute the files?
19:10:29 <MacroFake> It is about the header (at all)
19:10:32 <achow101> Is there a reason for either direction?
19:10:33 <sipa> Oh, ok.
19:11:11 <fanquake> achow101: one reason for removal could be that legally they are entirely pointless (still being debated), and just present maintenance burden
19:11:25 <sipa> I see the desire for avoiding the stupid (and apparently pointless) yearly dance of people wanting to bring the year numbers up to date.
19:11:58 <fanquake> the fact that we have never maintained any coherent policy around them also means they are likely further meaningless.  i.e files missing them, dates completely incorrect anyways etc.
19:12:11 <kanzure> "This code was written by some bitcoin developers in 2023. They still did that in 2023, even if you are in 2024!"
19:12:23 <sipa> I'm really not convinced that just dropping the years is the right thing to do legally (as I've commented in that PR). I'd be even more concerned about dropping the headers at all.
19:13:01 <fanquake> we also don't want some nonsense like, "you can't refactor a file until you figure out which dates need to get put into which files afterwards" etc
19:13:01 <MacroFake> Right, I am not sure if dropping the headers is good, but if there is value in them, shouldn't they apply to all/most files consistenly?
19:13:08 <jonatack> right. main point iiuc is whether that would de-risk (or increase it) WRT the absurd upcoming legal jurisprudence
19:13:39 <MacroFake> fanquake: Yeah, not sure what to do about the years
19:13:46 <kanzure> generally speaking, it would be good to investigate better ways to preserve the open nature of the project, and copyright headers are only one tool in that shed
19:13:58 <kanzure> further improvements will not necessarily be forthcoming in a meeting without more legal knowledge present
19:14:06 <fanquake> I'm not advocating for removing headers, only dates, given we've got at least some legal opinions sayings that's perfectly fine, as they mean nothing
19:14:19 <fanquake> no point deferring to non-lawyers software engineering opinions here
19:14:21 <sipa> I'd like to get actual legal advice about this (more than a fly-by comment from a lawyer who explicitly mentions they're not our lawyer).
19:14:32 <MacroFake> If ppl find it too risky, we can (1) de-bump the years, (2) Make the range -present, (3) or just close the pull.
19:14:38 <sipa> I can reach out to someone from BLDF?
19:14:41 <fanquake> sipa: yea, I think we can get some slilghtly more official
19:14:47 <MacroFake> I think at least for new files we can not add them?
19:15:28 <kanzure> (contributor license agreements may be more impactful, to the extent that they have any meaning, for contributors of new files)
19:15:35 <instagibbs_> things are copyrighted whether or not you claim copyright (but yes, ask for actual advice)
19:15:40 <sipa> From my understanding, we should definitely not have the copyright years for new files.
19:15:51 <MacroFake> kanzure: yeah, this is the actual topic I was trying to suggest :)
19:16:30 <MacroFake> Not sure how easy it is to set up a CLA, but I think we can approximate it with a CI check
19:16:32 <kanzure> i dunno, CLAs might have some wacky problem like CLAs not working unless there's an entity you license into
19:16:37 <achow101> I have no strong opinion, and a good lawyer could probably argue it both ways in court
19:17:24 <MacroFake> #27100 
19:17:24 <furszy> why do they present a maintenance burden if they can (all) be updated by an scripted-diff once per yer? The PR shouldn't conflict with any other PR.
19:17:25 <gribble> https://github.com/bitcoin/bitcoin/issues/27100 | ci: Add copyright header check by MarcoFalke · Pull Request #27100 · bitcoin/bitcoin · GitHub
19:18:01 <MacroFake> furszy: Yeah, I don't think the maintenance burden is an actual goal to optimize for
19:18:01 <achow101> furszy: because numerous randos make drive by prs updating the years and that's extrmemely annoying
19:19:01 <MacroFake> So back to the CLA. We already have https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#copyright
19:19:12 <sipa> I think the issue is mostly the meta-overhead of yearly discussions "do we really need these?".
19:19:14 <sipa> ;)
19:20:00 <furszy> k, then it's a layers question more than a devs topic. I guess
19:20:17 <fanquake> Also no point dancing some meaningless dance, if it's all pointless, and the existence of "copyright updating scripts" in this repo are just more random things up for pointless refactor and"improvements"
19:20:33 <fanquake> might as well nuke it all if possible
19:20:46 <MacroFake> furszy: About the years, I also raised the question, because *if* they are relevant, we wouldn't be allowed to legally bump them either?
19:21:42 <sipa> Maybe, I'm not sure.
19:22:55 <MacroFake> I think having copyright headers where possible could makes it harder for someone to violate copyright by accidentally submitting third party work as their own?
19:23:12 <instagibbs_> how does copyright lifetimes even work with multiple contributors?
19:23:21 <_aj_> get actual advice from an international copyright lawyer about whether removing the per-file notices or the years is okay, then, if it is, do it?
19:23:30 <instagibbs_> who has to die + 50 years before copyright expires :)
19:23:41 <_aj_> instagibbs_: depends which change you're copying
19:23:43 <achow101> instagibbs_: I think it works on a line by line basis
19:23:53 <achow101> probably character by character actually
19:23:59 <fanquake> probably with some garbage like the top of these files: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bioinformatics.scm?id=1b4f6286df13505cd17b3060fe4da7f03f39ba59
19:24:00 <sipa> i don't the speculation here is very useful
19:24:04 <sipa> *think
19:24:08 <instagibbs_> I was mostly joking
19:24:15 <fanquake> or at least, that's what the software engineers probably believe
19:26:41 <achow101> we should definitely consult lawyers, but even then, we probably won't know until some case involving copyright headers is actually tried in a court
19:27:12 <_aj_> even after one case, a different court can rule differently, especially if they're in a different country
19:27:22 <MacroFake> I suspect you won't find a lawyer to give you an answer to rely on
19:27:34 <kanzure> kind of interesting how tricky it is to ~give away source code
19:27:59 <MacroFake> kanzure: The giving away part is easy. The not getting sued part, not so
19:27:59 <sipa> Also note that just winning any potential disputes in court isn't the necessarily the only goal. Avoiding legal action in the first place is pretty desirable too.
19:28:12 <MacroFake> sipa: Right
19:28:20 <_aj_> also, dealing with courts and lawyers is probably much more annoying that closing random spam prs and running a script once a year...
19:29:22 <jonatack> +1 on reaching out to BLDF
19:29:53 <achow101> any other topics to discuss?
19:31:41 <achow101> #endmeeting