<bitcoin-git>
[bitcoin] fanquake closed pull request #25523: build: Fail early and show actionable messages if autogen deps are missing (master...autogen-assert-deps) https://github.com/bitcoin/bitcoin/pull/25523
Guyver2 has left #bitcoin-core-dev [Closing Window]
<achow101>
MacroFake: do you have a doc somewhere that contains all of your canned responses?
Norrin has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] achow101 opened pull request #27113: rpc: Use a FlatSigningProvider in decodescript to allow inferring descriptors for scripts larger than 520 bytes (master...decodescript-flatsigningprovider) https://github.com/bitcoin/bitcoin/pull/27113
lowhope_ is now known as lowhope
nanotube has joined #bitcoin-core-dev
sudoforge has quit [Ping timeout: 246 seconds]
Guest22 has joined #bitcoin-core-dev
Guest22 has quit [Client Quit]
Norrin has quit [Remote host closed the connection]
Norrin has joined #bitcoin-core-dev
jonatack1 has quit [Quit: WeeChat 3.8]
jonatack has joined #bitcoin-core-dev
dviola has joined #bitcoin-core-dev
_andrewtoth_ has quit [Remote host closed the connection]
<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
<kanzure>
do whatever maximizes the allowance for people to copy and distribute the files?
<MacroFake>
It is about the header (at all)
<achow101>
Is there a reason for either direction?
<sipa>
Oh, ok.
<fanquake>
achow101: one reason for removal could be that legally they are entirely pointless (still being debated), and just present maintenance burden
<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.
<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.
<kanzure>
"This code was written by some bitcoin developers in 2023. They still did that in 2023, even if you are in 2024!"
<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.
<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
<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?
<jonatack>
right. main point iiuc is whether that would de-risk (or increase it) WRT the absurd upcoming legal jurisprudence
<MacroFake>
fanquake: Yeah, not sure what to do about the years
<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
<kanzure>
further improvements will not necessarily be forthcoming in a meeting without more legal knowledge present
<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
<fanquake>
no point deferring to non-lawyers software engineering opinions here
<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).
<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.
<sipa>
I can reach out to someone from BLDF?
<fanquake>
sipa: yea, I think we can get some slilghtly more official
<MacroFake>
I think at least for new files we can not add them?
<kanzure>
(contributor license agreements may be more impactful, to the extent that they have any meaning, for contributors of new files)
<instagibbs_>
things are copyrighted whether or not you claim copyright (but yes, ask for actual advice)
<sipa>
From my understanding, we should definitely not have the copyright years for new files.
<MacroFake>
kanzure: yeah, this is the actual topic I was trying to suggest :)
<MacroFake>
Not sure how easy it is to set up a CLA, but I think we can approximate it with a CI check
<kanzure>
i dunno, CLAs might have some wacky problem like CLAs not working unless there's an entity you license into
<achow101>
I have no strong opinion, and a good lawyer could probably argue it both ways in court
<MacroFake>
#27100
<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.
<sipa>
I think the issue is mostly the meta-overhead of yearly discussions "do we really need these?".
<sipa>
;)
<furszy>
k, then it's a layers question more than a devs topic. I guess
<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"
<fanquake>
might as well nuke it all if possible
<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?
<sipa>
Maybe, I'm not sure.
<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?
<instagibbs_>
how does copyright lifetimes even work with multiple contributors?
<_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?
<instagibbs_>
who has to die + 50 years before copyright expires :)
<_aj_>
instagibbs_: depends which change you're copying
<achow101>
instagibbs_: I think it works on a line by line basis
<achow101>
probably character by character actually
<sipa>
i don't the speculation here is very useful
<sipa>
*think
<instagibbs_>
I was mostly joking
<fanquake>
or at least, that's what the software engineers probably believe
<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
<_aj_>
even after one case, a different court can rule differently, especially if they're in a different country
dviola has quit [Ping timeout: 255 seconds]
<MacroFake>
I suspect you won't find a lawyer to give you an answer to rely on
<kanzure>
kind of interesting how tricky it is to ~give away source code
<MacroFake>
kanzure: The giving away part is easy. The not getting sued part, not so
<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.
<MacroFake>
sipa: Right
<_aj_>
also, dealing with courts and lawyers is probably much more annoying that closing random spam prs and running a script once a year...
darosior has quit [Remote host closed the connection]
<achow101>
also, I'm cleaning up the meeting pings list. If you're not on it and want to be, let me know. likewise if you're on it and don't want to be.
<pinheadmz>
<- not on it, want to be
<pinheadmz>
<3
<brunoerg>
achow101: wanna be as well
darosior has joined #bitcoin-core-dev
<kanzure>
where did MarcoFalke go
<_aj_>
he got faked by a macro
<sipa>
:D
<kanzure>
guess it's ok even if Marco != Macro
<jonatack>
_aj_: congrats on bitcoin inquisition 24 and its op_vault and annex datacarrier PRs
darosior has quit [Ping timeout: 255 seconds]
realies has joined #bitcoin-core-dev
sudoforge has quit [Quit: 404]
AaronvanW has joined #bitcoin-core-dev
<ariard_>
sorry for missing the meeting today, busy - would be good to land #25725 at some point