Still if you're the lawyer on the side of the lawsuit claiming that the code is copyrightable, you really don't want that copilot attribution in the commit message muddying the waters.
AI nutters always use this argument that bots are merely doing what people are doing: "a person learning from 100 books is just the same as an LLM learning from 100 million books".
If you own an apple tree, and (as is common in some countries) a child leans over your fence to grab an apple, you don't lose sleepless nights over it. But if a corporation comes over and leans over with its 10 meter long robotic arm and takes all your apples then it's a disaster.
Scale matters. People don't care for small "losses" because we want other people to prosper. But AI steals from everyone and brings prosperity only to Amodei and Altman.
Setting aside Flock, the "ownership" situation is not as clear as you say above.
What you own is the image copyright. But the right to copy is only one of the rights at issue.
Under various state laws (California in particular), you might not be entitled to do all the things with that picture that you could do of one that doesn't have my likeness. Privacy laws like the CCPA are one possible carve-out. A "right of publicity" is another.
There's an old saying about property law that "property is a bundle of sticks". The bundle can be subdivided.
I like the future that the ATProto evangelists are painting. I would love for it to happen. But I am skeptical that a protocol is going to solve an incentive problem.
In the beginning Twitter was very free and open with API access. There were plenty of alternative apps. Of course, that changed when they got serious about monetizing.
Would it really be any harder for Bluesky to switch from ATProto to a proprietary API than it was for Twitter to close their API? How many users are realistically going to download their archives and upload them to some other provider? If most people are using the website or official app, that's where the stickiness is. There would be a blog post with a title like "Supporting the Bluesky Community for the Next Century" and how it's better to have a centralized site that can feed its employees than an idealistic decentralized one that disappears. Things would seem OK at first. But enough years of chasing quarterly KPIs would put them in the same spot as Twitter and Facebook.
The Bluesky API's are much more open than the Twitter API's ever were. There are people building alternate implementations of the entire stack. The alternatives don't have many users (maybe a few hundred to a few thousand), but the infrastructure is pretty far along.
There are plenty of public interest limitations on free speech. Food labels, cigarette warnings, deceptive ad laws. Regulating addictive social media isn't really an outlier here.
The parent comment set up a false choice and then had to adapt to the response calling their bluff.
The issue isn’t with reading or consuming content, as was set up in the challenge above.
The issue is with designing feeds and surfacing content in ways that take advantage of our brains.
As an analogy, loot boxes in video games, and slot machines come to mind. Both are designed to leverage behavioral psychology, and this design choice directly results in compulsive behavior amongst users.
The fact that these exist does not mean that they're immune from legal challenge. If the original creators wanted to sue, there are all kinds of claims that would have a decent shot in court (e.g. trademark, trade dress, design patents) besides "you copied our copyrighted source code." The clones exist more because people are being cool about it, and because there's not a strong economic incentive to challenge them. Those things can change at any time.
Out of the two claims, the only one that made it to appeals court was about whether it was fair use for Bleem to use screenshots of PS1 games to advertise its emulator (which was compatible with those games). The Ninth Circuit decided it was. But that's not relevant here.
The other claim was more relevant, as it was an unfair competition claim that apparently had something to do with Bleem's reimplementation of the PS1 BIOS. But the district court's record of the case doesn't seem to be available online, and the information I was able to find online was vague, so I don't know what exactly the facts or legal arguments were on that claim. Without an appeal it also doesn't set precedent.
If there were a lawsuit over OpenTTD, it would probably be for copyright infringement rather than unfair competition, and it would probably focus more on fair use and copyrightability. For fair use, it matters how much something is functional versus creative. The PS1 BIOS is relatively functional, but a game design and implementation are highly creative. On the other hand, despite being creative, game mechanics by themselves are not copyrightable. So it might come down to the extent to which OpenTTD's code was based on the reverse-engineered original code, as opposed to being a truly from-scratch reimplementation of the same mechanics. Visual appearance would also be relevant. Oracle v. Google would be an important precedent.
FreeBSD, NetBSD and OpenBSD at first when every BSD OS was just part of 386BSD it used to have AT&T code. That code was rewritten replacing every propietary part and after that (and noticing BSD 4.4 was incomplete) we got clean FreeBSD, NetBSD and OpenBSD from a NetBSD fork.
Another similar case with exact grounds was GNU which with Linux it completed an OS albeit in a hacky way, because the original OS would have been GNU+Hurd, but both are reimplementing Unix. Same SH derived shell, but extended. Kinda like OpenTTD. We have GNU Coreutils, Findutils, GNU AWK reimplementing and extending AWK (even when AWK was propietary), GNU Zip, Tar... the list goes on and on.
Oh, another one: Lesstif vs Motif. Same UI, if not very, very close to Motif 1.2 in order to be interoperable. Today it doesn't matter because nearly a decade a go Motif was relicensed into the GPL, but tons of libre software depending on propietary Motif was just seamlessly running with LessTIF libraries except for some rough edges/bugs. One of the most known example was DDD, a GUI for GDB.
You can get some good guesses from the comment itself.
> I assumed the writer was a journalist or author with a non-technical background trying to explore a more "utopian" vision of where trends could go.
If you assume you're reading something from a person with intention and a perspective, who you could connect with or influence in some way, then that affects the experience of reading. It's not just the words on the page.
This reminds me of having the reverse experience with the 2017 New Yorker viral "Cat Person" story [0] which a (usually trustworthy) friend forwarded and enthusiastically told me to read: waste of time shaggy-dog story, intentional engagement-trolling aimed at the intersection of the hot-button topics of its target readership *. But why are we culturally expected to allow more slack to a human author, even a meretricious one? Both are comparably bad. The LLM-authored one needs a disclaimer at the top to set its readers' expectations right, then readers can make an informed choice.
(* "Cat Person" honestly felt like the literary equivalent of Rickrolling; I would have stopped reading it after the first page if not for my friend's glowing endorsement.)
It had a very similar quality to the AI'd article from this thread. A sort of attempt at Being Literary but never really ever getting to the point of saying anything. It has the same feeling of wallowing, of over indulging in its shtick.
> If source code can now be generated from a specification, the specification is where the essential intellectual content of a GPL project resides. Blanchard's own claim—that he worked only from the test suite and API without reading the source—is, paradoxically, an argument for protecting that test suite and API specification under copyleft terms.
This is an interesting reversal in itself. If you make the specification protected under copyright, then the whole practice of clean room implementations is invalid.
reply