Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next steps for BPF support in the GNU toolchain

lwn.net

Post reply on HN
Print view View original

11–20 of 27 posts

Re: Next steps for BPF support in the GNU toolchain

#11

Post by mustache_kimono »

jcelerier wrote: post #4
mustache_kimono wrote: post #3

Earlier 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.

> It's of course not ridiculous.

I have the feeling you're arguing against and about something I never said.

To clarify, I'll restate: "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'. [The view that any new filesystem, simply aware of, but created independent of, and after Linux, is a derived work of Linux] is of course ridiculous,..."

> It's why black box reverse engineering exists and is generally legal, while white box reverse engineering is generally illegal.

Oh, I agree a clean room implementation is generally the best legal practice. I am just not sure there are cases on point that always require a clean room implementation, because I am aware of cases which expressly don't require clean room implementations (see Sony v. Connectix and Sega Enterprises Ltd. v. Accolade, Inc). And, given the factual situation has also likely changed due to FOSS and the Internet, I am saying some of these questions are likely still open, even if you regard them as closed.

Re: Next steps for BPF support in the GNU toolchain

#12

Post by ajross »

ggm wrote: post #2

Llvm 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 not illegal to examine.

As others are pointing out, rigorous application of copyright precedent argues in the other direction.

But I agree that it's really sad to see this is where we are in the community. The Apache license isn't some crazy monstrosity, it's literally free software per the FSF! It's "additional requirements" that the GPLv2 bumps into are things like the patent grant that we all agree are good things. And it's not incompatible with GPLv3!

Yet no one can work together. GPLv2 projects won't relicense to Apache or GPLv3, GPLv3 proponents won't link to GPLv2, corporate sponsors have refused to use GPLv3 at all. Everyone looks at these historical warts and incompatibilities as fortress walls around their own worlds and has forgotten that the only reason these licenses exist in the first place is that we all agree (or used to) that software is better when we can all share it.

But apparently it's not, because Everybody Else wants to share it in the Wrong Way.

I feel very old sometimes.

Re: Next steps for BPF support in the GNU toolchain

#14

Post by tremon »

inoffensivename wrote: post #13

I wish these articles would have a one sentence description of what BPF stands for. It would help passers-by.

Alternatively, the use of BPF without explanation signals that the article is a deep-dive and not intended for random passers-by. I don't support the position that every article should be written to cater to the lowest common denominator.

The first line of the article:

> Support for BPF in the kernel has been tied to the LLVM toolchain since the advent of extended BPF.

Should the article also explain which kernel they're referring to, what LLVM is and stands for, and highlight the differences between BPF and extended BPF? Or are they allowed to expect a motivated reader to do a cursory web search to fill in the gaps in their knowledge?

Re: Next steps for BPF support in the GNU toolchain

#15

Post by spaceywilly »

inoffensivename wrote: post #13

I wish these articles would have a one sentence description of what BPF stands for. It would help passers-by.

A nice practice that I try to follow it to always spell out what any Three Letter Acronyms (TLAs) the first time they are used. Then from that point onwards the simple TLA can be used.

In this case, BPF (shorthand for eBPF), stands for Extended Berkley Packet Filter. It’s a relatively new feature in the kernel that allows attaching small programs at certain “hook points” in the kernel (for example, when some syscall is called). These programs can pass information into userspace (like who is calling the syscall), and make decisions (whether to allow the call to proceed).

More info here https://ebpf.io/what-is-ebpf/

Re: Next steps for BPF support in the GNU toolchain

#16

Post by LegionMammal978 »

mustache_kimono wrote: post #11
jcelerier wrote: post #4

Earlier 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.

> It's of course not ridiculous. I have the feeling you're arguing against and about something I never said. To clarify, I'll restate: "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'. [The view that any new filesystem, simply aware of, but created independent of , and after Linux, is a derived work of Linux…

I agree, some of the Linux people have a very broad notion of what counts as a derived work, but I haven't seen much in the way of actual case law to support the conclusion that "white box reverse engineering is generally illegal".

Software generally receives wide protection for its 'non-literal elements', but it's not the case that every possible iota of its function falls under its protectable expression. Indeed, plenty of U.S. courts have subscribed to the "abstraction-filtration-comparison test" which explicitly describes how some characteristics of a program can be outside the scope of its protection.

But in practice, many of the big software copyright cases have been about literal byte-for-byte copying of some part of a program or data structure, so that the issue comes down to either contract law or fair-use law (which Sega v. Accolade and Google v. Oracle both fall under). The scope of fine-grained protection for 'non-literal elements' seems relatively unexplored, and the maximalist interpretation has seemingly proliferated from people wanting to avoid any risk of legal trouble.

Re: Next steps for BPF support in the GNU toolchain

#17

Post by bawolff »

loeg wrote: post #5
jcelerier wrote: post #4

Earlier 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.

You're correct that copyright does not apply to ideas only implementations. However if you take an existing implementation and base yours on it, generally the original work's copyright applies (there are a whole lot of details this is skimming over).

As an example, if you take a painting someone else made, and try and make your own version using the original as a reference, that is probably subject to the original author's copyright. On the other hand if you both happen to paint the same sunset its all ok.

I think you're more stating how you would like copyright to work, not how it actually does.

Re: Next steps for BPF support in the GNU toolchain

#18

Post by bawolff »

bayindirh wrote: post #10
psychoslave wrote: post #8

Earlier quoted context omitted.

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.

That seems totally reasonable to me. A large part of fair use is about the purpose of the use. It seems like a reasonable compromise that what is fair use in one context might not be in another. I can't think of any alternative to fair use that would make more sense.

I think the only unreasonable part is llm companies are implicitly or sometimes explicitly advertizing their products output as being fit for use in other projects. I think that is a false advertising problem.

Re: Next steps for BPF support in the GNU toolchain

#19

Post by corbet »

spaceywilly wrote: post #15
inoffensivename wrote: post #13

I wish these articles would have a one sentence description of what BPF stands for. It would help passers-by.

A nice practice that I try to follow it to always spell out what any Three Letter Acronyms (TLAs) the first time they are used. Then from that point onwards the simple TLA can be used. In this case, BPF (shorthand for eBPF), stands for Extended Berkley Packet Filter. It’s a relatively new feature in the kernel that allows attaching small programs at certain “hook points” in the kernel (for example, when some syscall…

We do try to spell things out and/or link them in LWN articles to make the context available, but some things we just have to assume.

Additionally, spelling out "Berkeley Packet Filter" is not going to help any readers here; BPF is far removed from the days when its sole job was filtering packets, and that name will not tell readers anything about why BPF is important in the Linux kernel.

Post reply on HN