| ▲ | aroman 2 days ago |
| > Some time ago, we were made aware of multiple attempts to exploit our permissive licensing to hijack our work, with a direct view to replacing the project and aggressively monetising Linux on Apple Silicon. Is this referring to Omarchy? Anyone have context? TBH I'm surprised their work was ever MIT-licensed instead of GPL. |
|
| ▲ | porphyra 2 days ago | parent | next [-] |
| The whole reason why people are trying to replace them is because they have stubbornly refused to use AI, which has directly impeded progress in getting M3/M4/M5/M6 working. It's fine of course for them to continue pursuing their hobby of doing everything manually, and honestly it is insanely impressive. But most people just want stuff to work, so it's odd to complain about it when others do manage to get it to work using AI to build on top of their prior permissively-licensed work. |
| |
| ▲ | nsbdhciebsbdhc 2 days ago | parent | next [-] | | Wanting stuff to work is a valid reason to not use AI for more sophisticated development projects. Having a computer that kernel panics once every three days is useless to me, even if it works for you. | | |
| ▲ | Kwpolska 2 days ago | parent | next [-] | | A kernel panic is the least of your worries with this hardware. Asahi had to introduce a custom daemon to avoid frying speakers. Apple doesn't need to care about making the hardware interfaces safe if they control the entire stack, so they don't, and expose dangerous capabilities to the OS. | | |
| ▲ | jasonvorhe a day ago | parent | next [-] | | Has anyone blown out some component of their Apple Silicon Macs over the years, whether via traditional or AI-run RE? Haven't encountered any reports about it yet. | |
| ▲ | Wowfunhappy 2 days ago | parent | prev | next [-] | | Does this generalize to basically anything outside of speakers though? I think a pretty easy solution is to not use AI for that specifically. | | |
| ▲ | orangea 2 days ago | parent [-] | | thermal management is the first thing that comes to mind. and battery management | | |
| ▲ | getcrunk a day ago | parent [-] | | You would hope both those systems have built in hw failsafes | | |
| ▲ | kortilla a day ago | parent | next [-] | | A blown fuse is a failsafe but that’s not helpful for users. | |
| ▲ | Kwpolska a day ago | parent | prev [-] | | If they removed the hardware failsafes from speakers to save a cent per device, I wouldn't be so sure. | | |
| ▲ | Wowfunhappy a day ago | parent [-] | | In the case of speakers, though, what would a hardware failsafe even look like? It would probably be some sort of secondary chip; Apple's design is to just move that to the main processor, the same way they don't have separate SSD controllers. Monitoring the CPU temperature feels very different to me. I'm pretty sure the CPU can't cook itself. This is probably documented somewhere so we don't need to speculate, but I can't research right now... |
|
|
|
| |
| ▲ | LoganDark 2 days ago | parent | prev | next [-] | | There was a fun period of time where Boot Camp still existed, but Windows could fry the speakers because it didn't have any of macOS's thermal protection. I think this was after the 2016 redesigns, as I had a mid-2015 with no such issue. | |
| ▲ | perching_aix a day ago | parent | prev [-] | | Good thing they only ever write correct code which consistently obeys every invariant in that entire stack ever. Excellent design, meet perfect engineering. |
| |
| ▲ | gloxkiqcza 2 days ago | parent | prev | next [-] | | Linux kernel itself is AI development friendly. | | |
| ▲ | tonyedgecombe 2 days ago | parent | next [-] | | Some of us think that is a mistake. | | |
| ▲ | aeonik 2 days ago | parent | next [-] | | Hmm very vague. "Some of us". Do the massive amount of vulnerabilities not make you think twice? At this point, I trust human code less than llm code. Design and architecture of the code still greatly benefit from a good human touch, but I'm not sure how long that will remain true. https://www.phoronix.com/news/OpenAI-948-Linux-LPE-Bugs | | |
| ▲ | nsbdhciebsbdhc 2 days ago | parent | next [-] | | So validate with an llm and humans. People committing code they haven't read - which will inevitability happen - is dangerous and hard to remotely verify. | | |
| ▲ | zdragnar a day ago | parent | next [-] | | People using LLMs put up much larger changes, and much faster. Depending on the LLM used the quality is often much lower. A lot of projects just stopped accepting any outside contributions rather than deal with the tidal wave of slop they were getting. Choosing to not accept LLM code is IMHO a better compromise. | |
| ▲ | rowanG077 2 days ago | parent | prev [-] | | In the end there is always a separate reviewer. Even if the producer is adversial and not even looking at the code then this process exists to catch it. This is not at all different from people attempting to get backdoors into Linux. |
| |
| ▲ | codedokode 2 days ago | parent | prev [-] | | LLMs will introduce new vulnerabilities. What Linux should have done is stop using non-standard C, or better, stop using C completely in favor of Rust, support code analysers. | | |
| ▲ | palata 2 days ago | parent [-] | | And humans can introduce new vulnerabilities, too. Linux maintainers accept patches from random people over the internet. They already have to just the patch on its technical merit, not on who submitted it. For them I don't think it makes a difference (technically) if the patch was written with the help of an AI. I believe that there may be valid reasons to refuse anything that was touched by an AI, but that's not about security. It's more about the non-technical problems coming from AI (centralising power, increasing inequalities, carbon footprint, ...). |
|
| |
| ▲ | jasonvorhe 2 days ago | parent | prev [-] | | Some people will always disagree with something. That's what's great about free software. There will probably be some Luddite anti AI Linux fork at some point. |
| |
| ▲ | cromka 2 days ago | parent | prev [-] | | That's not what they meant. It's AI friendly, not slop-friendly. There's a reason no Omarchy patch of any kind has made it to the kernel list yet. I did personally look into some of their code and it is certified, hacked-togeter slop. | | |
| ▲ | ffemac 2 days ago | parent | next [-] | | Exactly. As an example, read that Gravity Linux guy's responses here. I will never ever trust him. I will stay away from his code as far as possible. Asahi team: I have my trust in you. | |
| ▲ | ChocolateGod 2 days ago | parent | prev [-] | | How do you define the difference between ai friendly and ai slop? | | |
| ▲ | dj_morocco 2 days ago | parent | next [-] | | I'm pretty sure Asahi devs experiment with LLM tools, but not to Omarchy's extent. LLM ban is purely a filtration filter, so that they wouldn't be spending time overbearingly exhausting number of patches generated with AI, and not someone who cares about this than a shiny tool. Everyone understands that LLM is a mean to an end, but it's clear that Omarchy got two confused and it's showing. | | | |
| ▲ | inejge 2 days ago | parent | prev | next [-] | | My definition, FWIW. AI-friendly: you can use the LLMs however you wish, but you must thoroughly understand every part of submitted code. Slop-friendly: understanding anything is optional. | | |
| ▲ | ChocolateGod 2 days ago | parent [-] | | I also agree with that definition. But for example if I get an LLM to generate 95% of a program, but I understand and have read every line of code, is it still slop? Some would say yes unfortunately. | | |
| ▲ | palata 2 days ago | parent | next [-] | | Not the OP, but I wanted to share my 2 cents: As an open source maintainer, when someone opens a PR, I don't know who they are. But I don't really care. I care about the PR: is it a "good" PR (there are multiple dimensions: is it understandable, does it add maintainable code, was it tested, etc) or not? I think "AI-friendly" says "I don't care if it's written with an AI or not: I want good quality PRs". I would think that "slop-friendly" is the kind of projects where the maintainers don't read the code. Maybe they try the feature (maybe not even?). I think the Omarchy guy was explaining somewhere that he does not read the code anymore, he just lets his AI write Rust. This is slop-friendly IMO. If you are not AI-friendly, it means that you refuse to accept a good PR even if you cannot tell that an AI was involved. The mere fact that an AI was involved disqualifies the PR. | |
| ▲ | shwaj a day ago | parent | prev [-] | | Are you one-shotting then reading/understanding? Then probably slop. Are you iterating to help you understand, prompting to rename/restructure/document until you would have been able to easily understand without AI? Then probably not slop. |
|
| |
| ▲ | flykespice 2 days ago | parent | prev | next [-] | | Ai friendly patch: * Author posts patch with a manageable number of lines so maintainer doesn't gets burned out reviewing it. * Tries to outline on the body what the patch is about and his rationale for the design decisions on the code. * Promptly answers any maintaners questions about the line changes. * Discloses which AI model he used to assist on the patch and how was it used. AI slop patch: * Submits patch with huge lines of code without explanation. * The body is written in a self-patronizing tone with superfluous formatting that helps nothing but annoys who is looking for the actual substance of patch * When questioned by maintainer about some line changes either goes radio silent or reply with the usual AI tone of marketin salesman. * rarely if ever discloses AI usage. | | |
| ▲ | mrheosuper 8 hours ago | parent [-] | | >* Discloses which AI model he used to assist on I don't see why this is necessary ? Does it provide any useful info, or just noise. |
| |
| ▲ | tkel 2 days ago | parent | prev [-] | | experience |
|
|
| |
| ▲ | BluSyn a day ago | parent | prev | next [-] | | Human slop is far worse than then AI slop. | |
| ▲ | orangecat 2 days ago | parent | prev | next [-] | | It's amusing that people still default to "human-written code is solid and AI code sucks" after the enormous quantity of bugs that AIs are finding in human-written code. | | |
| ▲ | sashank_1509 18 hours ago | parent | next [-] | | Honestly aesthetically, good human code is always >> Opus 5.5. For example, recently Opus 5.5, in some multithreaded app I was working on at work, used complex timing analysis with hardcoded time values 1.2, 0.95 etc to ensure that some activities only happen in a sequence (A->B->C). I had to tell it to just serialize these activities by putting them in a buffer. Both versions passed all tests (I’m sure it wasted a lot of time tuning the first set of numbers to pass the tests, but no human would do that nonsense). Increasingly, you feel it’s thinking diverging from humans more and more as the labs lean into RL. | |
| ▲ | bigstrat2003 2 days ago | parent | prev [-] | | Nobody has ever said human code is perfect. But it is empirically the case that code written by LLMs is on average lower quality than code written by humans. | | |
| ▲ | habitue a day ago | parent | next [-] | | That's not really true, and it's only even potentially true if we talk about the absolute cream of the crop developers. Most human written code is quite bad actually | | |
| ▲ | saagarjha a day ago | parent [-] | | > absolute cream of the crop developers You’re reading their blog |
| |
| ▲ | BluSyn a day ago | parent | prev [-] | | This has not been true for 6 months. Update your priors. |
|
| |
| ▲ | kcb 2 days ago | parent | prev | next [-] | | Having a computer where half the features don't work isn't particularly great either... | |
| ▲ | nickysielicki 2 days ago | parent | prev [-] | | [flagged] |
| |
| ▲ | pmdr a day ago | parent | prev | next [-] | | > they have stubbornly refused to use AI And by the looks of it, they're very intent on gatekeeping. Deep down I don't like AI either, it has taken away a lot of what I love about coding. But it's here to stay. What if we can use it to wrestle hardware control away from Apple and other authoritarian vendors? Hell yes, we should. The likely problem with the Asahi team is that they (by not accepting AI) feel that control is being wrestled away from them, and instead of adapting they choose to swallow the poison pill of GPL. We might not like it, coding as it was pre-LLM is done for. No one is going to come groveling at the feet of those who stubbornly insist on not using it. | | |
| ▲ | marsmaps a day ago | parent | next [-] | | > the poison pill of GPL not sure that concept makes any sense at all. the entirety of LLMs' capability to perform software design and development tasks, such as it is, comes from the massive resource of copyleft projects, including those using GPL, that the AI companies have ingested | | |
| ▲ | pmdr a day ago | parent [-] | | Well, it's a more restrictive license than MIT. A lot of popular projects nowadays are under the MIT license. AI labs still don't give a damn about how the code their LLMs ingest is licensed anyway, and GPL'd code won't stop them one bit. If their code had been used in proprietary ways, then yes, GPL would've been the way to go. AFAIK Omarchy is MIT-licensed, which still requires preserving the copyright notice of other MIT-licensed code it's based on. So I'm not sure what damage has been done to Asahi itself. |
| |
| ▲ | NooneAtAll5 a day ago | parent | prev | next [-] | | > the poison pill of GPL ???? | |
| ▲ | skywhopper a day ago | parent | prev [-] | | You realize that Linux itself is GPL-licensed? How is it a poison pill precisely? | | |
| ▲ | pmdr a day ago | parent [-] | | Linux itself has always been GPL licensed. It's the license switch that I have a problem with, not GPL itself. Switching from a permissive license to one less so, just so others would stop using it in their MIT-licensed projects. |
|
| |
| ▲ | Copenjin a day ago | parent | prev | next [-] | | There is no "stubbornly", the project is theirs and they do the f they want, their reasoning is sound. Permissive license does not mean that you cannot speak out about what people are doing with your software. Do you think there would have been something working on mac if omarchy didn't start from the solid foundation of Asahi? Please don't make me laugh too hard. | |
| ▲ | codedokode 2 days ago | parent | prev [-] | | So why those people using AI do not write the code from scratch without breaking the license and without vibe-copying existing code? | | |
| ▲ | habitue a day ago | parent | next [-] | | What is vibe-copying? The code was permissively licensed specifically so other people could do what they want with it. I'm so confused what people think permissive licensing is | |
| ▲ | happymellon a day ago | parent | prev | next [-] | | The code was MIT, I don't get why people write code use the most permissive licences and then get grumpy that folks use it as offered. It's literally why GPL was invented. | |
| ▲ | Danox a day ago | parent | prev [-] | | No talent. no skills is why? |
|
|
|
| ▲ | WhyNotHugo 2 days ago | parent | prev | next [-] |
| > I'm surprised their work was ever MIT-licensed instead of GPL. The intent was for their work to be usable on non-GPL distributions and OSs (including the BSDs). The new licence is pretty restrictive — proprietary platforms will just regurgitate it with LLMs, but other open ecosystems will have to re-invent things from scratch. |
| |
|
| ▲ | tommica 2 days ago | parent | prev | next [-] |
| Its the monetizing part that makes me think its not Omarchy - they have no monetizing things. |
| |
| ▲ | ADevWithAnIdea 2 days ago | parent | next [-] | | They're referring to Omarchy, it's very clear on their IRC | | |
| ▲ | kombine 2 days ago | parent [-] | | I saw that's there is an Omarchy for Mac "team" consisting mostly of one guy who is active on Twitter (and quickly amassed many followers) and seems to have no prior experience of working on Linux kernel. They do not mention Asahi anywhere which isn't surprising to me given the reputation of DHH and Omarchy. This hijacking of open source by bad faith actors is very concerning. | | |
| ▲ | jasonvorhe 2 days ago | parent | next [-] | | Nonsense. > Omarchy on...
> Apple M1/M2 chips#
> Asahi Alarm is a version of Arch for Apple M1/M2 computers built on top of Asahi Linux. You can get Omarchy running on top of that with some effort. See the user-driven guide. Source: https://omarchy.org/manual/omarchy-on/ > [...] You finished what Asahi started, and you’re already pushing on to M4, M5, and M6. Thank you! Source: https://omarchy.org/news/2026/11/marcelo-alcantara-and-birk-... | |
| ▲ | saagarjha a day ago | parent | prev | next [-] | | It’s a little more complicated than this (but not better IMO) | |
| ▲ | cromka 2 days ago | parent | prev [-] | | Yeah, on their GitHub for example, in their m1n1 fork they tend to refer to "upstream" as... the main branch of their fork. Very interesting choice of words, but again, all their work including all issues and docs are LLM-generated. |
|
| |
| ▲ | petterroea 2 days ago | parent | prev | next [-] | | Omarchy has gotten somewhat of a reputation for getting a lot of sponsorship money from commercial actors. If by monetize you mean "Get people to pay us" omarchy are definitely monetizing. Not much different to Asahi themselves of course, but is it right/moral to fork another active projects code and use it in order to gain your own patrons? I don't hold the answers. But no they aren't selling anything. edit: worth noting this example, where DigitalOcean started cutting OSS support only to pledge millions of dollars to Omarchy. No wonder people consider the project a leech to the OSS community, but also consider correlation != causation: https://itsfoss.com/news/digitalocean-open-source-credits-en... | | |
| ▲ | SXX 2 days ago | parent | next [-] | | DigitalOcean obviously cut their OSS support because they gave it as credits for a year and it required constant human review and interaction. At the same time it was mostly to small OSS projects that dont have formal non-profits so no tax exemption benefits to DigitalOcean. | | |
| ▲ | petterroea 2 days ago | parent [-] | | It is worth noting the same article's discussion of nodejs reads as "DO shut down a program, possibly planning a v2 of said program, but failed to communicate it to its dependents and didn't realize until they started planning to leave". Or they were just fighting the fires caused by a github issue named "Transition off of Digital Ocean" caused \o/ | | |
| ▲ | SXX 13 hours ago | parent [-] | | Project I was involved in was one of dependants and there was nothing in email mentioning any "v2": Hello,
We’re reaching out to share an important update regarding the DigitalOcean Open Source Credits Program.
DigitalOcean has decided to sunset the Open Source Credits Program. As part of this change, we are no longer accepting new credit applications or approving credit renewals, extensions, or additional credit requests.
If you currently have Open Source Credits that have already been granted, those credits will continue to be honored according to their existing terms and conditions. No action is required for your existing credit allocation.
Additionally, the dedicated inbox for the Open Source Credits Program will stop being monitored as part of this transition. For any further questions or assistance, please submit your inquiries through our standard support channel: https://www.digitalocean.com/company/contact/support
We appreciate your participation in the DigitalOcean Open Source Credits Program and the work you do to support the open source community. Thank you for being part of the program.
Best wishes,
Redacted
|
|
| |
| ▲ | wannabe44 a day ago | parent | prev [-] | | Yes. But how is GPL going to prevent that? |
| |
| ▲ | burgerone 2 days ago | parent | prev [-] | | They do have large entities donating to them |
|
|
| ▲ | throwaway13337 2 days ago | parent | prev | next [-] |
| Is Omarchy trying to monetize Linux? I mean, I get the poisoning the well of open source thing that some companies do. I didn't think Omarchy was trying to do that. With how good LLMs are at reverse engineering, I've been looking forward to being able to ditch MacOS and still have decent hardware soonish. Taking back the ownership of our devices to run our software is the positive future LLMs are giving us. We need only to take action. |
| |
| ▲ | pmdr a day ago | parent | next [-] | | Omarchy is itself MIT licensed, with no restrictions that I'm aware of. If they later decide to make a paid version or something, the license wouldn't stop them, I think. But GPL would. All in all, I think it's a dumb move from Asahi because their GPL'd code will soon be eaten up LLMs that don't give a damn about licensing anyway. | |
| ▲ | lionkor 2 days ago | parent | prev [-] | | The same LLMs you have to rent from the very richest people on earth? I would be careful to call that freedom | | |
| ▲ | jasonvorhe 2 days ago | parent | next [-] | | There's people running close to frontier model grade local AI on consumer and prosumer hardware, let's not act as if it was impossible to skip having to rent from OpenAI or Anthropic. | | |
| ▲ | lionkor a day ago | parent [-] | | Have you seen hardware prices? They are so high that it's not even affordable for upper middle class in most of the world. |
| |
| ▲ | papyrus9244 2 days ago | parent | prev [-] | | You know you can run LLMs on your own computer, right? | | |
| ▲ | palata 2 days ago | parent [-] | | If you can afford a computer that can run LLMs, sure. | | |
| ▲ | flossly a day ago | parent [-] | | "afford" in this case has to be compared to the cost of renting. | | |
| ▲ | palata a day ago | parent [-] | | Of course. Someone who pays 150$ a year for Claude Pro would need years to get to a 4k machine. | | |
| ▲ | flossly a day ago | parent [-] | | 150$/month, for year... I've seen businesses that made the infrastructure to share a 100k machine. They needed it "on premise", but the setup did not look too hard and the results were outstanding compared to Claude Opus. | | |
| ▲ | palata 20 hours ago | parent [-] | | > 150$/month, for year... Claude Pro is 15$/month. Not everybody can afford 150$/month. |
|
|
|
|
|
|
|
|
| ▲ | vasco 2 days ago | parent | prev | next [-] |
| I really don't get why people even start with permissive licenses if they have people they don't like to use their software or if they're just going to go "not like that" at the first real use. It seems like many times it's open source but "just to look". |
| |
| ▲ | palata 2 days ago | parent | next [-] | | They say: > In some extreme cases, in-development feature code was being lifted straight out of our personal forks and published without attribution or lazily rewritten with LLM assistance to obfuscate its origin. Permissive licences require attribution. It's okay to complain when people publish your permissively-licenced work without attribution, and hence without honouring the licence. | | |
| ▲ | bredren a day ago | parent [-] | | There are legal remedies to this that can be taken before changing the license entirely. These remedies would still be needed to actively police misuse of the new license. | | |
| ▲ | marsmaps a day ago | parent [-] | | changing the licence is much cheaper than pursuing legal action, and sends an immediate and very public signal of disapproval. given that legal remedies would be required either way, and are extremely time-consuming and expensive, it makes sense to send the signal first |
|
| |
| ▲ | nextaccountic 2 days ago | parent | prev | next [-] | | They explain that they expected that MIT licensed code would encourage contributions from BSD OSes I agree it was a poor choice of license and that GPL helps build a better community, I'm glad they mad ethe license choice | |
| ▲ | bentley 2 days ago | parent | prev [-] | | Because permissive licensing, and free software in general, rightfully comes with a certain cachet, and it turns out some people want the benefits of that reputation, but don’t actually believe in the freedom “to use, copy, modify, and distribute this software for any purpose.” Hence the treadmill from permissive licensing to copyleft, and then later from copyleft to “source available”… “But software which OpenBSD uses and redistributes must be free to all (be they people or companies), for any purpose they wish to use it, including modification, use, peeing on, or even integration into baby mulching machines or atomic bombs to be dropped on Australia.” —Theo de Raadt (2001) | | |
| ▲ | SXX 2 days ago | parent [-] | | That'a weird how you placed copyleft next to source available side of spectrum. That's opposite because copyleft is ultimately about user freedom not developers freedom. GPL wont help Asahi team for a bit. | | |
| ▲ | nextaccountic 2 days ago | parent | next [-] | | > That's opposite because copyleft is ultimately about user freedom not developers freedom. Yeah, the whole idea of GPL is to restrict developers from doing certain things, because it would be harmful to users | | |
| ▲ | avadodin 2 days ago | parent [-] | | [flagged] | | |
| ▲ | nextaccountic 2 days ago | parent | next [-] | | > The moment you produce anything of value, it is taken from you Nobody is forced to license their software using GPL though | | |
| ▲ | avadodin 2 days ago | parent [-] | | Nobody. Just the workers who want to add to the project the yoke of which they have been forced to live under. I don't feel like arguing with FSF/Iron Curtain types, anyways. If somebody has a non-exploitative Liberty-based argument for the GPL, I will hear it. | | |
| ▲ | DaSHacka 2 days ago | parent [-] | | No one is being forced to use or contribute back to the project though. In fact, you can even use GPL licensed software, and so long as everyone with the binaries doesn't ever request the source, you do not have to publish it at all. |
|
| |
| ▲ | Y_Y 2 days ago | parent | prev [-] | | Fresh argument, you should take it to usenet |
|
| |
| ▲ | jwrallie a day ago | parent | prev [-] | | Yeah, the whole point of GPL is that people can fork it and improve it as long as they share the code back. If Asahi is rejecting LLM produced code, then they will get the modified source but will be unable to use it because of their own rules. |
|
|
|
|
| ▲ | mythz a day ago | parent | prev | next [-] |
| > exploit our permissive licensing to hijack our work You cannot exploit permissive licensing when its entire purpose is to encourage others to use it. |
| |
| ▲ | guax a day ago | parent [-] | | Of course you can, its like putting candy for Halloween on the expectation that one kid is not going to get the whole bowl at once. The way you can exploit an open license is to grab the code, invest massive amounts of resources in it and close the platform. Embrace, extend, and extinguish. |
|
|
| ▲ | dingi 2 days ago | parent | prev | next [-] |
| I don't get this complain. MIT does not forbid commercial use. So what's the fuss about? |
| |
| ▲ | aroman 2 days ago | parent | next [-] | | From TFA: > Some time ago, we were made aware of multiple attempts to exploit our permissive licensing to hijack our work, with a direct view to replacing the project and aggressively monetising Linux on Apple Silicon. In some extreme cases, in-development feature code was being lifted straight out of our personal forks and published without attribution or lazily rewritten with LLM assistance to obfuscate its origin. The MIT licence explicitly allows this, and has no carveouts to protect against bad faith actors. | | |
| ▲ | geerlingguy 2 days ago | parent | next [-] | | It's one reason I've favored GPL of late, after many years using MIT. Not that many people these days would explicitly follow the terms of any license. | | | |
| ▲ | saghm 2 days ago | parent | prev [-] | | There are licenses that require attribution without being copyleft though. I'm not saying the Asahi developers are wrong to use copyleft, but it's weird to me to mention "without attribution" as a sticking point when there are fairly standard permissive licenses that require attribution like Apache and BSD. | | |
| ▲ | tredre3 2 days ago | parent [-] | | MIT isn't copyleft and it does require attribution, it's basically the only requirement of it. I guess they just don't like that attribution means "put the license snippet deep in a secondary readme file hidden somewhere, along with 50 other licensees used in the project". I think it's clear that they don't want people to use their code and close the door behind them. They also clearly want clearer attribution. I'm sorry but if those are things you desire, then deliberately choosing MIT because of a GPL hate-boner was plain stupid. |
|
| |
| ▲ | hparadiz 2 days ago | parent | prev | next [-] | | They are mad that vibecoders are building on top of their work, making real progress, then re-releasing it as "look it works" while containing a bunch of their work. Which is sort of fair but I don't get how that works in practice because in reality anyone can read the code which is open source and do whatever they want. Licensing won't stop them. | | |
| ▲ | robbiep 2 days ago | parent [-] | | Sort of fair? Or actually fair because attribution for work is… fair? | | |
| ▲ | hparadiz 2 days ago | parent [-] | | Your credit is your first commit. After that people copy/paste patches back and forth as they will. It happened before AI. I've run patches in prod that were basically someone's random RAID controller patch posted to the Gentoo forum. If it works, it works. |
|
| |
| ▲ | theptip 2 days ago | parent | prev [-] | | Right, this seems deeply confused. If you care about how your code is used, don’t use MIT. Especially, if you care about monetization, probably use GPL or AGPL. |
|
|
| ▲ | simondotau 2 days ago | parent | prev [-] |
| [dead] |