Next steps for BPF support in the GNU toolchain
1–10 of 27 posts
Re: Next steps for BPF support in the GNU toolchain
#2Llvm is a different licence not illegal to examine. How to manage pointer+offset address integrity/legality inside the kernel (for instance) has a proof by examples a-plenty in the other code. You don't have to invent a totally unique way of doing things unless you want to.
Re: Next steps for BPF support in the GNU toolchain
#3Llvm is a different licence not illegal to examine. How to manage pointer+offset address integrity/legality inside the kernel (for instance) has a proof by examples a-plenty in the other code. You don't have to invent a totally unique way of doing things unless you want to.
> Llvm is a different licence (sic) not illegal to examine.
FSF considers Apache 2 incompatible with the GPL2 because of its "additional conditions".
I happen to agree with you that, at the very least, we haven't fully grappled with the fact that FOSS, like the Linux, is published to the Internet, and freely available to read, by anyone. Obviously, there should be a distinction between reading and copying, just like there is a distinction between reading and copying a literary work.
The issue -- as I see it -- is that many GPL fanatics just don't see it the same way. I believe Linus has even opined that any filesystem which was developed after Linux, whose developers are aware of Linux, could be considered a "derived work". This is of course ridiculous, but the GPL, if read without due care and funneled through social media slop, can be ridiculous.
Re: Next steps for BPF support in the GNU toolchain
#4Llvm is a different licence not illegal to examine. How to manage pointer+offset address integrity/legality inside the kernel (for instance) has a proof by examples a-plenty in the other code. You don't have to invent a totally unique way of doing things unless you want to.
> Llvm is a different licence (sic) not illegal to examine. FSF considers Apache 2 incompatible with the GPL2 because of its "additional conditions". I happen to agree with you that, at the very least, we haven't fully grappled with the fact that FOSS, like the Linux, is published to the Internet, and freely available to read, by anyone. Obviously, there should be a distinction between reading and copying, just like…
It's of course not ridiculous. It's why black box reverse engineering exists and is generally legal, while white box reverse engineering is generally illegal. It doesn't matter whether it applies to proprietary or free software, copyright applies equally to both.
Re: Next steps for BPF support in the GNU toolchain
#5Earlier quoted context omitted.
> Llvm is a different licence (sic) not illegal to examine. FSF considers Apache 2 incompatible with the GPL2 because of its "additional conditions". I happen to agree with you that, at the very least, we haven't fully grappled with the fact that FOSS, like the Linux, is published to the Internet, and freely available to read, by anyone. Obviously, there should be a distinction between reading and copying, just like…
It's of course not ridiculous. It's why black box reverse engineering exists and is generally legal, while white box reverse engineering is generally illegal. It doesn't matter whether it applies to proprietary or free software, copyright applies equally to both.
Copyright applies to literal reproduction of documents; not to ideas. It is straightforwardly allowed to read some implementation of an idea, think about it, and write your own implementation of the same idea.
Re: Next steps for BPF support in the GNU toolchain
#6Earlier quoted context omitted.
> Llvm is a different licence (sic) not illegal to examine. FSF considers Apache 2 incompatible with the GPL2 because of its "additional conditions". I happen to agree with you that, at the very least, we haven't fully grappled with the fact that FOSS, like the Linux, is published to the Internet, and freely available to read, by anyone. Obviously, there should be a distinction between reading and copying, just like…
It's of course not ridiculous. It's why black box reverse engineering exists and is generally legal, while white box reverse engineering is generally illegal. It doesn't matter whether it applies to proprietary or free software, copyright applies equally to both.
So clean room the llvm analysis and work from a spec carried out of the room.
It's a really low bar to avoid, tbh. The point is that people have hobbies. And aspects of this work can look like a hobbyist "but i don't want to do it that way" view.
As a consumer of compiler products it doesn't have to matter to me, nor as a user of compilers. It's only observations reading the comments and the article which brought this to mind: llvm is proof by example and is a different kind of open source, it's not a barrier I would struggle to pierce, for my own personal view of code licences.
(I'm old enough to have read the gnu manifesto when it first published btw)
Re: Next steps for BPF support in the GNU toolchain
#7Earlier quoted context omitted.
It's of course not ridiculous. It's why black box reverse engineering exists and is generally legal, while white box reverse engineering is generally illegal. It doesn't matter whether it applies to proprietary or free software, copyright applies equally to both.
Copyright applies to literal reproduction of documents; not to ideas. It is straightforwardly allowed to read some implementation of an idea, think about it, and write your own implementation of the same idea.
IBM published its initial BIOS code in a manual bundled with the PC. Having any knowledge of it, even if you don't implement it verbatim makes you tainted, and makes you guilty in any of the subsequent cases.
This is why Black Box Reverse Engineering Exists.
Same is true for console reverse engineering. No self respecting reverse engineer reads code leaks from official console development. Otherwise they'd be in a legal hot water.
This is serious stuff and there's no blurry line in this.
Re: Next steps for BPF support in the GNU toolchain
#8Earlier quoted context omitted.
Copyright applies to literal reproduction of documents; not to ideas. It is straightforwardly allowed to read some implementation of an idea, think about it, and write your own implementation of the same idea.
IBM published its initial BIOS code in a manual bundled with the PC. Having any knowledge of it, even if you don't implement it verbatim makes you tainted , and makes you guilty in any of the subsequent cases. This is why Black Box Reverse Engineering Exists . Same is true for console reverse engineering. No self respecting reverse engineer reads code leaks from official console development. Otherwise they'd be in a…
I agree with all that (that is on actual legal basis, not personal preferences on societal structure), and it’s all the more frustrating to think about the power asymmetry in the era of LLM trained on basically every written material that can be found out there, and in that case oh yes you absolutely can go with it regardless of how verbatim some code they output can be.
Re: Next steps for BPF support in the GNU toolchain
#9Llvm is a different licence not illegal to examine. How to manage pointer+offset address integrity/legality inside the kernel (for instance) has a proof by examples a-plenty in the other code. You don't have to invent a totally unique way of doing things unless you want to.
> How to manage pointer+offset address integrity/legality inside the kernel (for instance) has a proof by examples a-plenty in the other code
Let me provide some context here. These annotations aren’t there to help the compiler/linter. They exist to aid external tooling. Kernel can load BPF programs (JIT-compiled bytecode). BPF can invoke kernel functions and also some kernel entities can be implemented or augmented with BPF.
It is paramount to ensure that types are compatible at the boundaries and that constraints such as RCU locking are respected.
Kernel build records type info in a BTF blob. Some aspects aren’t captured in the type system, such as rcu facet, this is what the annotations are used for. The verifier relies on the BTF.
Re: Next steps for BPF support in the GNU toolchain
#10Earlier quoted context omitted.
IBM published its initial BIOS code in a manual bundled with the PC. Having any knowledge of it, even if you don't implement it verbatim makes you tainted , and makes you guilty in any of the subsequent cases. This is why Black Box Reverse Engineering Exists . Same is true for console reverse engineering. No self respecting reverse engineer reads code leaks from official console development. Otherwise they'd be in a…
I agree with all that (that is on actual legal basis, not personal preferences on societal structure), and it’s all the more frustrating to think about the power asymmetry in the era of LLM trained on basically every written material that can be found out there, and in that case oh yes you absolutely can go with it regardless of how verbatim some code they output can be.
The more disturbing thing about LLMs is, it's "fair-use" to scrape everything for them, but it's a liability for the user to use the code, text, whatever.
If it emits a large block of copyrighted material, you'll be again in legal hot water.
Considering even fair-use can be abused (see what GamersNexus is going through) at-will, it looks even more bleaker than at first glance.