GPL is not a patent. It covers the work and _derivatives_; it does not cover ideas or general knowledge. The chip in question has docs.

I fully expect that Claude wrote code that does not resemble that of the driver in the Linux tree. TFA is taking on some liability if it turns out that the code Claude wrote does largely resemble GPL'ed code, but if TFA is not comfortable with the code written by Claude not resembling existing GPL'ed code then they can just post their prompts and everyone who needs this driver can go through the process of getting Claude to code it.

In court TFA would be a defendant, so TFA needs to be sure enough that the code in question does not resemble GPL'ed code. Here in the court of public opinion I'd say that claims of GPL violation need to be backed up by a serious similarity analysis.

Prompts cannot possibly be considered derivatives of the GPL'ed code that Claude might mimic.

▲ shakna 8 hours ago | parent | next [-]

From the file headers:

SPDX-License-Identifier: ISC

Based on the Linux brcmfmac driver.

I'm going to ahead and say there are copyright law nightmares, right here.

▲ throwaway2037 6 hours ago | parent [-]

That headers looks pretty reasonable to me. I don't see anything misleading or ambiguous about it. Whenever I am heavily modifying some licensed code, I always make sure to include a similar header.

    > I'm going to ahead and say there are copyright law nightmares, right here.

I am confused. My first thought was maybe the original Linux driver was GPL'd, but it is not. It is ISC'd. Look here: https://github.com/torvalds/linux/blob/master/drivers/net/wi...

    // SPDX-License-Identifier: ISC
    /*
     * Copyright (c) 2010 Broadcom Corporation
     */

	▲	shakna 4 hours ago \| parent [-]
		It adds a contributor. To add a contributor, you need "significant" _human_ input. The output of models has so far not been deemed copyrightable. As it acknowledges the original source, it needs to show the human effort that allows it to be bound to the new contributors.

▲ ssl-3 8 hours ago | parent | prev [-]

Except...

In this case, they didn't really work from the chip's published documentation. They instead ultimately used a sorta-kinda open-book clean-room method, wherein they generated documentation using the source code of the GPL'd Linux driver and worked from that.

That said: I don't have a dog in this race. I don't really have an opinion of whether this is quite fine or very-much not OK. I don't know if this is something worthy of intense scrutiny, or if it should instead be accepted as progress.

(It is interesting to think about, though.)

	▲	throwaway2037 6 hours ago \| parent [-]
		As I mentioned in another comment, the original referenced source code from the Linux kernel is ISC'd, not GPL'd. See here: https://github.com/torvalds/linux/blob/master/drivers/net/wi... I don't work on the Linux kernel, but I do poke around the sources from time to time. I was genuinely surprised to see that some hardware drivers are not GPL'd. That is news to me, but makes commercial sense to when I think deeper about it. When these manufacturers donate a driver to Linux, I don't think GPL is a priority to them. In the case of Broadcom, they probably want their WiFi hardware to more compatible with SBCs to drive sales (of future SBCs that use their WiFi hardware and run Linux). If anything, choosing a more liberal license (ISC) increases the likelihood that their Linux driver will be ported to other operating systems. From Broadcom's commercial view, that is a win to sell more SBCs (free labour from BSDers!). Also, if the original driver was GPL'd, I am pretty sure it is fair game (from US copyright and software license perspective) to use one LLM to first reverse engineer the GPL'd driver to write a spec. Then use a different LLM to implement a new driver for FreeBSD that is ISC'd. You can certainly do that with human engineers, and I see no reason to believe that US courts would object to separate LLMs being used in the two necessary steps above. Of course, this assumes good faith on the part of the org doing the re-write. (Any commercial org doing this would very carefully document the process, expecting a legal challenge.) I do think this blog post introduces a genuinely (to me!) novel way to use LLMs. My favourite part of that blog post was talking about all of the attempts that did not work, and new approaches that were required. That sounds pretty similar to my experience as a software engineer. You start with preconceived notions that frequently shattered after you walk down a long and arduous path to discovering your mistakes. Then you stop, re-think things, and move in a new intellectual (design) direction. His final solution of asking LLMs to write a spec, then asking other LLMs to proof-read it is highly ingenious. I am really impressed. Please don't view that "really impressed" as my thinking that the whole world will move to vibe coding; rather I think this is a real achievement that deserves some study by us human engineers.