Unlurker|Replay|About
Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy (gitlab.redox-os.org)
•
What would constitute "clearly llm generated" though
•
They will sooner or later change that policy or get very slow in keeping up.
•
While I am more on the AI-hater side, I don't consider this to be a good idea: "any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed" For example: - What if a non-native English speaker uses the help of an AI model in the formulation of some issue/task? - What about having a plugin in your IDE that rather gives syntax and small code fragment suggestions ("autocomplete on steroids")? Does this policy mean that the programmers are also restricted on the IDE and plugins that they are allowed to have installed if they want to contribute?
While I appreciate the morality and ethics of this choice, the current trend means projects going in this direction are making themselves irrelevant (don't bother quipping at how relevant redox is today, thanks). E.g. top security researches are now using LLMs to find new RCEs and local privilege escalations; no reason why the models couldn't fix these, too - and it's only the security surface. IOW I think this stance is ethically good, but technically irresponsible.
•
Even if we assume that LLMs become good enough for this to be true (some might feel that is the case already - I disagree, but that is beside the point), there is no reason why OSS maintainers should accept such outside contributions that they would need to carefully review, as it comes from an untrusted source, when they could just use the tools themselves directly. Low effort drive-by PRs is a burden with no upside.
Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense. What makes sense if that of course any LLM-generated code must be reviewed by a good programmer and must be correct and well written, and the AI usage must be precisely disclosed. What they should ban is people posting AI-generated code without mentioning it or replying "I don't know, the AI did it like that" to questions.
•
what a retarded view. All OSes you use today were developed without AI
There are only 4 successful general purpose production OSes (GNU/Linux, Android/Linux, Windows, OS X/iOS) and only one of those made by the open source community (GNU/Linux). And a new OS needs to be significantly better than those to overcome the switching costs.
•
> There are only 4 successful general purpose production OSes Feel like you are using a very narrow definition of "success" here. Is BSD not successful? It is deployed on 10s of millions of routers/firewalls/etc in addition to being the ancestor of both modern MacOS and PlaystationOS...
•
None of this counters the argument I made above :-)
•
Just because they have been made before LLMs doesn't mean it can be done again, since there was just one success (GNU/Linux) and that success makes it much harder for new OSes since they need to better then it
•
Well, by this logic there have been 0 successful OSes made with LLMs so far...
> Because it takes a massive amount of developer work You know what else takes "a massive amount of developer work"? "any LLM-generated code must be reviewed by a good programmer" And this is the crux of the matter with using LLMs to generate code for everything but really simple greenfield projects: They don't really speed things up, because everything they produce HAS TO be verified by someone, and that someone HAS TO have the necessary skill to write such code themselves. LLMs save time on the typing part of programming. Incidentially that part is the least time consuming.
•
The submitter is supposed to be the good programmer; if not, then maintainers may or may not review it themselves depending on the importance of the feature.
> any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed Note the word "clearly". Weirdly, as a native English speaker this term makes the policy less strict. What about submarine LLM submissions? I have no beef with Redox OS. I wish them well. This feels like the newest form of OSS virtue signaling.
•
Don't ask don't tell looks like a reasonable policy. If no one can tell that your code was written by an LLM and you claim authorship, then whether you have actually written it is a matter of your conscience.
I think this is a reasonable decision (although maybe increasingly insufficient). It doesn't really matter what your stance on AI is, the problem is the increased review burden on OSS maintainers. In the past, the code itself was a sort of proof of effort - you would need to invest some time and effort on your PRs, otherwise they would be easily dismissed at a glance. That is no longer the case, as LLMs can quickly generate PRs that might look superficially correct. Effort can still have been out into those PRs, but there is no way to tell without spending time reviewing in more detail. Policies like this help decrease that review burden, by outright rejecting what can be identified as LLM-generated code at a glance. That is probably a fair bit today, but it might get harder over time, though, so I suspect eventually we will see a shift towards more trust-based models, where you cannot submit PRs if you haven't been approved in advance somehow. Even if we assume LLMs would consistently generate good enough quality code, code submitted by someone untrusted would still need detailed review for many reasons - so even in that case it would like be faster for the maintainers to just use the tools themselves, rather than reviewing someone else's use of the same tools.
•
For well-intended open source contributions using GenAI, my current rules of thumb are: * Prefer an issue over a PR (after iteration on the issue, either you or the maintainer can use it as a prompt) * Only open a PR if the review effort is less than the implementation effort. Whether the latter is feasible depends on the project, but in one of the project I'm involved in it's fairly obvious: it's a package manager where the work is typically verifying dependencies and constraints; links to upstream commits etc are a great shortcut for reviewers.
•
> Even if we assume LLMs would consistently generate good enough quality code, code submitted by someone untrusted would still need detailed review for many reasons - so even in that case it would like be faster for the maintainers to just use the tools themselves, rather than reviewing someone else's use of the same tools. Wouldn't an agent run by a maintainer require the same scrutiny? An agent is imo "someone else" and not a trusted maintainer.
•
Yes, I agree. It was just me playing with a hypothetical (but in my view not imminent) future where vibe-coding without review would somehow be good enough.
Project maintainers will always have the right to decide how to maintain their projects, and "owe" nothing to no one. That being said, to outright ban a technology in 2026 on pure "vibes" is not something I'd say is reasonable. Others have already commented that it's likely unenforceable, but I'd also say it's unreasonable for the sake of utility. It leaves stuff on the table in a time where they really shouldn't. Things like documentation tracking, regression tracking, security, feature parity, etc. can all be enhanced with carefully orchestrated assistance. To simply ban this is ... a choice, I guess. But it's not reasonable, in my book. It's like saying we won't use ci/cd, because it's automated stuff, we're purely manual here. I think a lot of projects will find ways to adapt. Create good guidelines, help the community to use the best tools for the best tasks, and use automation wherever it makes sense. At the end of the day slop is slop. You can always refuse to even look at something if you don't like the presentation. Or if the code is a mess. Or if it doesn't follow conventions. Or if a PR is +203323 lines, and so on. But attaching "LLMs aka AI" to the reasoning only invites drama, if anything it makes the effort of distinguishing good content from good looking content even harder, and so on. In the long run it won't be viable. If there's a good way to optimise a piece of code, it won't matter where that optimisation came from, as long as it can be proved it's good. tl;dr; focus on better verification instead of better identification; prove that a change is good instead of focusing where it came from; test, learn and adapt. Dogma was never good.
•
At the moment verification at scale is an unsolved problem, though. As mentioned, I think this will act as a rough filter for now, but probably not work forever - and denying contributions from non-vetted contributors will likely end up being the new default. Once outside contributions are rejected by default, the maintainers can of course choose whether or not to use LLMs or not. I do think that it is a misconception that OSS software needs to "viable". OSS maintainers can have many motivations to build something, and just shipping a product might not be at the top of that list at all, and they certainly don't have that obligation. Personally, I use OSS as a way to build and design software with a level of gold plating that is not possible in most work settings, for the feeling that _I_ built something, and the pure joy of coding - using LLMs to write code would work directly against those goals. Whether LLMs are essential in more competitive environments is also something that there are mixed opinions on, but in those cases being dogmatic is certainly more risky.
•
Your analogy with CI/CD is flawed because while not all were convinced of the merits of CI/CD, it's also not technology built on vast energy use and copyright violation at a scale unseen in all of history, which has upended the hardware market, shaken the idea of job security for developers to its very foundation and done it while offering no really obvious benefits to groups wishing to produce really solid software. Maybe that comes eventually, but not at this level of maturity. But you're right it's probably unenforceable. They will probably end up accepting PRs which were written with LLM assistance, but if they do it will be because it's well-written code that the contributor can explain in a way that doesn't sound to the maintainers like an LLM is answering their questions. And maybe at that point the community as a whole would have less to worry about - if we're still assuming that we're not setting ourselves up for horrible licence violation problems in the future when it turns out an LLM spat out something verbatim from a GPLed project.
•
> Or if the code is a mess. Or if it doesn't follow conventions. In my experience these things are very easily fixable by ai, I just ask it to follow the patterns found and conventions used in the code and it does that pretty well.
Isn't the obvious solution to not accept drive by changes?
•
That's eliminating of an important part of open source culture.
•
I don't think it really is - drive-by changes have been a net burden on maintainers long before LLMs started writing code. Someone who wants to put in the work to become a repeat contributor to a project is a different story.
•
How to differentiate between a drive-by contribution and a first contribution from a potentially long-time contrubutor. And I would say especially for operating systems if it gets any adoption irregular contributions are pretty legit. E.g. when someone wants just one specific piece of hardware supported that no one else has or needs without being employed by the vendor.
•
Sure - and I suspect we will see that soon enough. But it has downsides too, and finding the right way to vet potential contributors is tricky.
I feel like the pattern here is donate compute, not code. If agents are writing most of the software anyway, why deal with the overhead of reviewing other people's PRs? You're basically reviewing someone else's agent output when you could just run your own. Maintainers could just accept feature requests, point their own agents at them using donated compute, and skip the whole review dance. You get code that actually matches the project's style and conventions, and nobody has to spend time cleaning up after a stranger's slightly-off take on how things should work.
•
So your proposed solution to AI slop PRs is to "donate" compute, so the maintainers can waste their time by generating the AI slop themselves?
•
The point isn't that agent output is magically better; it's that reviewing your own agent's output is way cheaper (intellectually) than reviewing a stranger's, because you've written the plan by yourself. And 'slop' is mostly what you get when you don't have a clear plan to verify against. Maintainers writing detailed specs for their own agents is a very different thing from someone vibe coding a feature request
•
Who reviews the correctness of the second agents' review?
Well, it's not quite that easy because someone still has to test the agent's output and make sure it works as expected, which it often doesn't. In many cases, they still need to read the code and make sure that it does what it's supposed to do. Or they may need to spend time coming up with an effective prompt, which can be harder than it sounds for complicated projects where models will fail if you ask them to implement a feature without giving them detailed guidance on how to do so.
•
Definitely, but that's kind of my point: the maintainers are still going to be way better at all of that than some random contributor who just wants a feature, vibe codes it, and barely tests it. The maintainers already know the codebase, they understand the implications of changes, and they can write much better plans for the agent to follow, which they can verify against. Having a great plan written down that you can verify against drastically lowers the risk of LLM-generated code
Hm, wondering how to enforce this rule. Rules without any means to enforce them can put the honest people into a disadvantage.
•
> This policy is not open to discussion, any content submitted that is clearly labelled as LLM-generated (including issues, merge requests, and merge request descriptions) will be immediately closed, and any attempt to bypass this policy will result in a ban from the project. It sounds serious and strict, but it applies to content that's 'clearly labelled as LLM-generated'. So what about content that isn't as clear? I don't know what to make of it. My guess is that the serious tone is to avoid any possible legal issues that may arise from the inadvertent inclusion of AI-generated code. But the general motivation might be to avoid wasting the maintainers' time on reviewing confusing and sloppy submissions that are made using the lazy use of AI (as opposed finely guided and well reviewed AI code).
> As an aside, I've noticed a huge drop off in license literacy amongst developers What do you mean by this? I always assumed this was the case anyway; MIT is, if I'm not mistaken, one of the mostly used licenses. I typically had a "fuck it" attitude when it came to the license, and I assume quite a lot of other people shared that sentiment. The code is the fun bit.
•
> I always assumed this was the case anyway; MIT is, if I'm not mistaken, one of the mostly used licenses No, it wasn't that way in the 2000s, e.g., on platforms like SourceForge, where OSS devs would go out of their way to learn the terms and conditions of the popular licenses and made sure to respect each other's license choices, and usually defaulted to GPL (or LGPL), unless there was a compelling reason not to: https://web.archive.org/web/20160326002305/https://redmonk.com/sogrady/2014/11/14/open-source-licenses/ Now the corporate-backed "MIT-EVERYTHING" mindvirus has ruined all of that: https://opensource.org/blog/top-open-source-licenses-in-2025
If you're going to set a firm "no AI" policy, then my inclination would be to treat that kind of PR in the same way the US legal system does evidence obtained illegally: you say "sorry, no, we told you the rules and so you've wasted effort -- we will not take this even if it is good and perhaps the only sensible implementation". Perhaps somebody else will eventually re-implement it later without looking at the AI PR.
•
How funny would it be if the path to actually implement that thing is then cut off because of a PR that was submitted with the exact same patch. I'm honestly sitting here grinning at the absurdity demonstrated here. Some things can only be done a certain way. Especially when you're working with 3rd party libraries and APIs. The name of the function is the name of the function. There's no walking around it.
•
That's why I said "somebody else, without looking at it". Clean-room reimplementation, if you like. The functionality is not forever unimplementable, it is only not implementable by merging this AI-generated PR. It's similar to how I can't implement a feature by copying-and-pasting the obvious code from some commercially licensed project. But somebody else could write basically the same thing independently without knowing about the proprietary-license code, and that would be fine.
↙ time adjusted for second-chance
The Gervais Principle, or the Office According to "The Office" (ribbonfarm.com)
•
Focusing only on the second and top layer of the diagram, I usually call them “the increments and the excrements”.
•
The MacLeod Life Cycle reminds me on the 5 seasons of the illuminati calendar: Verwirrung Season of Chaos January 1-March 14 Zweitracht Season of Discord March 15-May 26 Unordnung Season of Confusion May 27-August 7 Beamtenherrschaft Season of Bureaucracy August 8-October 19 Grummet Season of Aftermath October 20-December 31 From the book Illuminatus!
•
Anyone else can't scroll on this site?
↙ time adjusted for second-chance
macOS Tahoe windows have different corner radiuses (lapcatsoftware.com)
•
I dislike Tahoe too, but this particular thing is not new. I just did an image search for "classic macos" and one of the first hits was from https://www.versionmuseum.com/history-of/classic-mac-os . Look at those System 1 screenshots, from 42(!) years ago -- round corners on Puzzle and Calculator, square corners on Note Pad and Control Panel! No consistency at all, isn't it infuriating?
•
“Well actually” in Sysyem 1 and later Classic macOS the puzzle and the calculator are ”Desk Accessories” that is applications that can run simultaneously as other apps, even though the operating system does not support multitasking. The rounded corners are there to distinguish them from the current running application.
•
Yep, I'm aware. Just like Tahoe, it's intentional and there's a rationale behind it. It may or may not be immediately obvious depending on the user, and people may or may not like the way it looks.
•
Puzzle and Calculator were Desk Accessories (DAs), a special kind of app. Some cool details here: https://en.wikipedia.org/wiki/Desk_accessory Like Tahoe, it was deliberate and there's an explanation for the difference. But I do wonder if people at the time felt the same way.
•
Finally, the update we've all been waiting for
•
Apple is no longer about Jobs' "simplicity as the ultimate sophistication". It feels like a bunch of kids with no proper design education competing for the security of their salaries. Apple is dead without Steve. The company has no focal point. They're running solely on the inertia from Mac OS X and the first generations of the iPhone.
•
That's a pretty extreme take. I've been using the Mac since about 2001. I like Tahoe and a well designed Tahoe app can look really nice on the platform. There are bugs, inconsistencies and other issues, but it doesn't feel that different than many previous macOS / OS X releases
Wow, you’re leaving a lot of great features like Spotlight shortcut calling, Spotlight clipboard history, and LLM shortcuts on the table because of a couple UI inconsistencies. “Design is how it works.”
•
Design is much more than that. Also, it’s almost as if you can’t imagine that other users might have needs and preferences different from yours.
•
Why are you shilling so hard for these features?
•
Because they’re significant improvements to the way macOS works for power users
Mac OS's UX design has been in free fall the last 5-10 years (ever since the "iOS-ify everything" zeitgeist took root). Sincerely hope that they one day revert back, because the current UX is just godawful for any usecase I can imagine.
•
> ever since the "iOS-ify everything" zeitgeist took root That started in 2010, a bit more than 5-10 years.
Because Spotlight now rarely finds your applications in search so you can't just quick launch anything.... from a launcher widget
•
They finally managed to get feature parity with the Windows start menu :) For around a decade typing "word"+return into the windows start menu search box usually opened Edge with a search result of "ord". Recently it opens Word most of the time.
I wish too but they can't just back up, that would be a very bad sign for investors.
•
They'll just come up with round displays. Like on PDP-1.
It's by design. This isn't a bug or a skipped test case. https://developer.apple.com/videos/play/wwdc2025/310/?time=442 > Each element is designed with a curvature that sits neatly within the corner radius of its container, in this case the window itself. And this relationship goes both ways. In the new design system, windows now have a softer, more generous corner radius, which varies based on the style of window. Windows with toolbars now use a larger radius, which is designed to wrap concentrically around the glass toolbar elements, scaling to match the size of the toolbar. Titlebar-only windows retain a smaller corner radius, wrapping compactly around the window controls. These larger corners provide a softer feel and elegant concentricity to the window but they can also clip content that sits close to the edge of the window.
•
Design for the sake of design. That entire paragraph reads like a post-hoc justification for a design decision they never thought through
What if they randomized the radius on every launch? A fresh, modern experience every time!
•
Don't give them ideas
for the life of my I can't understand why y'all care so much about this. This is what bad software is? The corner radii are slightly off? Doesn't that seem a bit... particular?
•
It's like getting invited to dinner at a friend's house and you notice that half of the knifes and forks they put on the table are a bit dirty. If they have managed to fumble something so basic then one can't help but extrapolate what the state of the rest is.
There is so much of that in modern apple. Clear issues caused by a seemingly bright idea, but the idea still pushed forward no matter what. One example that I hate on iOS: the notification/lockscreen curtain is supposed to cover the content as it slides down. That’s what a curtain does, this has been the language for years. Now the curtain is transparent, so it can’t cover the content behind. How does the content disappear then, as you slide the curtain down? … it doesn’t. Icons do a buggy looking animation crashing toward the user and through the screen, and if it’s an app there is just no transition. You can check by sliding the curtain down slowly and then letting go.
•
This one has always confused me. And then, to be even more confusing, if you start sliding up slowly, the background does not disappear. It stays this time around. Pull down slowly, no background, just the glass effect. Pull up slowly, still have the background, no glass effect. I guess I don't necessarily hate it, it's more of a neutral thing, but who is deciding these strange things??
> seemingly bright idea i disagree about that one. im not a UX expert by any means but my first impression at WWDC seeing liquid glass was "holy shit, they pulled that off? i know apple would never compromise on legibility, so... how? there are so many situations where this won't work, and they can't exactly control the content that the buttons are overlaid on top of" cue my confusion when it was exactly that: an obviously problematic idea implemented with all the obvious flaws showing up they have largely fixed it now, half a year later, but the liquid glass isn't very liquid anymore. it's frosted. which is fine, but obviously not the original idea they were going for contrasty backgrounds are fundamentally incompatible with legibility
•
>im not a UX expert by any means but my first impression at WWDC seeing liquid glass was "holy shit, they pulled that off? i know apple would never compromise on legibility, so... how? there are so many situations where this won't work, and they can't exactly control the content that the buttons are overlaid on top of" That's what I mean, even if worded badly. Someone probably managed the glass distortion effects as an experiment, or demoed a transparent redesign of a small portion of the UI, and it looked awesome. I think it's cool that they can green light weird ideas, otherwise there's stagnation. But it is obvious that there were fundamental unresolved issues, and yet something in the process pushed the idea forward anyway. It signals something very wrong in company structure. If you can't trust the process to drop what doesn't work, then trying new things is risky. And as you say, it's an experiment that feels so unlike apple, to disregard polish and accessibility that way.
•
> i disagree about that one. Why ? I'm sick of square windows. I want disc windows. And instead of scrolling them, i want to rotate them. /s Fixing bugs is hard. Better focus on the aesthetics.
If AR/VR took off then something along the lines of liquid glass would be the only option for the entire design space. Early on there's going to be a lot of embedding of app context into the AR/VR setting to get a jump-start on content. But if people are going to be walking around with rectangular panes around their head, it's better that part of the app chrome is transparent. Is this compromising readability? Yes, but now there's another kind of perception problem, and it's whether you can see what's literally in front of your eyes in physical space.
•
The AR push is also an issue in itself. There are very fundamental issues that remain unresolved, and I would say untackled even. VR setups make you isolated and vulnerable. Any VR device is really awkward to use in public (read: in your living room or in an office). In turn, AR setups that let the world through reduce image quality by virtue of being transparent, and it is unclear that they provide advantages. You get a slightly more immediate access to notifications in return for permanently pointing a camera towards anything you look at, which is understandably not well received. And that's just for content consumption. When you introduce work, input is still significantly worse unless you're sitting in front of a keyboard and mouse, in which case you might as well have a full laptop.
Beautiful, it’s nice, but the polished user experience was the ultimate argument. - Raising the lid of the laptop and the base wouldn’t stick and fall off on the desk, - A single-button click, - A Cmd+C to copy and Ctrl+C for the interruption 7 in the terminal, But now you have to configure that, yes, activate the right-click; yes, activate the three-finger click (wtf, 3 fingers); yes, activate the swipe-across-desktops on the magic mouse, all those items were selling points, so they should have studied the best behavior and implemented it by default on all deployments. But that requires studies, aesthetics, and a taste that only Steeve Jobs had, otherwise everything becomes an option. That’s right, I’m going to paraphrase Jobs’ argument against the 1990ies Microsoft: The problem with Apple is they have no taste.
•
> - A Cmd+C to copy and Ctrl+C for the interruption 7 in the terminal, I really miss that in Linux. That said, some terminals implement smart Ctrl+C which will interrupt if there's no text selected and copy otherwise. But terminal I use (Gnome Console) does not, so I have to press Ctrl+Shift+C to copy text and then I press that in browser and everything exploded because it opens developer tools. So annoying.
Just a bunch of words that raised no red flags, maybe sounded like a decent idea even, but when you see it how is your reaction not “oh, that’s bad” I feel like this is the design process. You have ideas, they sound ok, you try them out, and then immediately you revert a lot of them. The ideas without the taste to know when not to do something is becoming the new Apple way
•
I think what they're saying is that larger radii are for 'real windows' that have toolbars and such but there are 'mini windows' and those get smaller radii. It doesn't seem well enough baked for them to release it like it is but there are other UI problems that I've been annoyed about for a long time (in particular shadows around window boundaries so you can never get a truly flat tiled experience).
To align the window corner radius to the window close/minimize/resize buttons distance from the edge of the window.
•
Except it kind of fails at that too. The window corners seem to be either based on those squircle things or some kind of other varying radii curve which eases out into sides much more gradually than proper circles. The window buttons (close, minimize) the round toolbar buttons anchored to top right corner are based on proper circles. Attempting to center circle in a varying curvature corner results in varying spacing between the circle and corner, which defeats the whole point of why different windows have different corner size (not calling it radius because they are not circles). When the top right corner contains a search field instead of rounded button, that also seems to use varying curvature instead of capsule with proper circles at the ends. Still results in varying spacing between window corner and the toolbar content. And that's just the 2 top corners. Attempts to align top corners result in even bigger mismatch with the rest of the window content. For example calculator -> it has a grid of round buttons. While the window corners might match top bar (as good as they can due to different shapes) the main calculation buttons don't match the corners at all. Similar problem affects many of the popups which have something like confirmation button anchored to bottom right corner. Rounded scrollbar handle - not aligned with bottom left corner size, instead it awkwardly gets cut of by different amount in each program. Menus also have this disease. The non circular corner curve of overall menu shape extends way past the corner of item highlight resulting in varying spacing and making it feel almost like whole menu has bulged out instead of flat sides.
Learnings from paying artists royalties for AI-generated art (kapwing.com)
•
I mean there's no point; everyone still gets super mad even in the cases where models where trained only on content that a company owns or has paid for. I wish artists would stop with the "it stole our work bullshit" and just be more honest about the "it can do what we do and we're terrified and scare for our future" part. Because that I can 100% understand, and contrary to previous jobs just disappearing, we do live in "the future" and things like UBI or free cross-training should be available for this sort of thing.
Ok mr sceptic, where are your numbers showing consumers buy more of a thing after it becomes more expensive?
•
Was merely commenting on the observed preference vs stated preference issue (aka "the Say/Do Gap"), not the underlying point about raising prices.
The tech doesn't sound that interesting at all. Every AI Degen thread on 4chan and similar has included model fine tuning instructions for a few years now, for the express purpose of cloning an existing artists style. I also find it interesting that they included a quote from an artist pointing out the hypocrisy of using an existing model, trained on unlicensed material, but never actually discussed that particular issue in the article.
•
I think you mean LORAs more than a fine tune. Yes, plus there are plenty of online resources to train a LORA as well, CivitAI you can just give it a bunch of images + labels and it just does it for you, the bar is pretty low.
> Surveys consistently showed that consumers believed artists deserved payment when AI generated content in their style. It's interesting that "consumers" are generally for the expansion of IP laws. At at the moment, I'm fairly certain that "style" is not something protected by Copyright. I personally do not want this, and I'm sure there are likely many like me. Poorly thought out IP laws lead to chilling-effects, DRM, stupid and unnecessary litigation, and ultimately a loss of digital freedoms. > What 325 Cold Emails to Artists Taught Us I'm surprised 1% didn't respond with "EAT HOT FLAMING DEATH SPAMMER" for sending them unsolicited commercial email. ;)
•
Yeah as a furry (exposed to commission scene a lot) the number of commissions available for "Disney" or "Pixar" or whatever style art even before the whole AI era really tells you that they're hypocrites.
By the same 'transformative' standards that allow satire, reaction and commentary videos to exist. And those take 100% from the source and add context, whereas good generated AI images that aren't wholesale copying take like less than 10% from the original source. In addition, the idea that you need to pay rent on *your observation* of someone else's work is absurd. No one pays Newton's descendants for making lifts or hosting bungee jump sport activities.
•
Is it transformative if I take all the pages in Hanya Yanagiharas A Little Life and use a thesaurus to change every second word? Or a more realistic scenario: what if I translate it to Spanish without license from the author? That's not allowed, and yet I have "transformed" the work in the same way that an LLM does.
 Top