The attackers exfil'd 3TB of data, which obviously included PII, from AWS servers. They should've had DLP, active monitoring, countermeasures, using a security vendor (you can set this up for AWS services using CloudTrail, CloudWatch Logs, etc). You're supposed to have that for sensitive government or military work, and it should have (at least) caught that much traffic going to a rando external IP, blocked and flagged.
If they did have it set up, then somebody wasn't doing their job. If they didn't have it set up, they didn't comply (which is also not doing their job). I see this all the time. The security analysts send tickets to people when they see major issues and nobody is held accountable for inaction. Management asleep at the wheel (which is also their cover, can't be blamed for what you made sure you never knew about).
Maybe not replaced exactly but they won't be manually typing out lines of code anymore. I haven't written a line of code in like 6 months. I review PRs, write prompts and tickets, check CI output, and get frustrated when the magical code machine stops working or I run over token budget
A lot of us out there don't make Open Source for rewards. We just like sharing things. I have about 10 users for one of my projects. If I had 10,000 it would be the same. I'm just glad anybody found it useful. And I like using other projects because at the end of the day I don't want to sit here writing code (even AI code), I just want a solution to my problem.
Maybe there will be fewer Open Source contributors. But maybe there will be even more of them with AI making the labor and maintenance easier. Either way I will still be publishing my dinky project, because it works for me, so maybe it'll work for someone else.
Nobody listens to the system engineer until exactly the thing he warned about happens. They still don't listen to him after it happens but at least he can feel smug for a day
None of them are bad. It's like saying a bike vs a scooter vs a car is bad. Use them correctly and for what they're intended and they work fine. Use them improperly for the wrong things and suddenly people think the tools suck, when it's the humans who misused them that suck.
It may seem useful at first, but eventually you'll hit a wall where this doesn't work, and you have to add another memory technique. Eventually you end up with a complex multi-layered system, because what people want by "memory" is actually 10 different things which all need their own solution.
Agreed. Attackers use any means (inc. abliteration, fine-tuned security models, etc) to find exploits and only have to be successful once. Defenders don't have the same time and motivation, so neutered models put defenders at a disadvantage.
Somebody's got a case of Chesterton's Fence. They doesn't understand what MCP's for or how it's used, but they find it mildly irritating or unhelpful, so they demand it be removed.
MCP is an abstraction for remote tool calls with a standard interface. More specifically it's for when a local CLI will not do, and you want determinism and standardization. It also avoids all of the potential errors and guesswork involved with a model trying to "figure out" how to do something; you simply make one standard call, and the remote side "figures it out" for you, without failure.
If you can do what you need to do without MCP, then don't use MCP. When you eventually get sick of AIs playing guessing games with local tools/data, or spending lots of time to get functionality somebody already published as an MCP, or you need isolated control over the execution, maybe check it out again.
> Somebody's got a case of Chesterton's Fence. They doesn't understand what MCP's for or how it's used, but they find it mildly irritating or unhelpful, so they demand it be removed.
Yeah that's me. Idk what MCP is really, just that there's always some auth issue with it and I've never actually needed it. Is it dead yet?
Think of MCP as a universal CLI tool for anything you can imagine running on a server (remote!). Even if you wanted to use a local CLI tool to call some remote server command, local CLI tools have different input/output formats, different commands/options, and those tools change over time. MCP doesn't change, it always tells the AI exactly how to call it, the calls always use the same format, it includes a standard, quite secure method of authentication, and it's all done in an AI-friendly way. And because of all of this, it uses less tokens, and has a much higher likelihood of success (e.g. AI tools failing to call CLI tools properly and looping trying to figure out the right arguments/input/output).
Now, if you don't care about authentication, don't care about wasted tokens, don't care about the AI screwing up CLI tool calls or needing to be trained on every one, and if you don't need to call something on a server, then MCP is useless to you.
In that case, you can use a skill calling an HTTP+JSON endpoint. Or if you mean it's literally a remote CLI, so it needs bidi streaming, that's what websockets is for (or gRPC but ehh). Those are well-established. MCP sounds like one of those "we need yet another a new standard, this time to rule them all" things.
Yeah that still fails a ton. A skill will mess up the call, not know how to handle errors correctly, not flag an error as an error (false positive), hallucinate, require custom input/output formats, require custom code to validate, won't handle authentication the same way, you'll need a unique skill for each endpoint, you need to version the skill, and of course there needs to be an endpoint, as well as all of the tools needed on the client machine to process everything, hoping of course that they're the right version.
Compare that to MCP. One standard tool call. Works on every agent. Everything built in. Determinism. Reliability. Simplicity. It just works.
Skills are non-deterministic balls of mud. MCP are deterministic standard tool calls. MCP solves all the problems. A skill can't do what MCP does.
In terms of "using standards" to solve the problems, tell me 3 different APIs (from different companies) that have identical input format, identical output format, identical request URI format, identical headers, identical methods, identical auth. You won't find them, because everyone implements their API differently. You can use 50 different standards 50 different ways, and still not solve the problems mentioned above. MCP is one standard that works one way and actually solves all the problems.
And this is just addressing the client-side problems. There's a whole world of server side (logging, tracing, auth, execution, etc) that's not standard either, unless you use MCP.
Honestly, the privilege and entitlement of some people. You made a thing, you did a lot of work, you gave it away for free. Nobody stole it from you. Nobody even asked you to make it. You created this situation yourself. And now you're upset that nobody paid you for the thing you make for free?
"But but but... companies are making money... off the thing... that I gave them for free!! How dare they!! There is no way I could have seen this coming!!" - Either you were ignorant and didn't realize people would sell the thing you gave away, or you knew about it and are now pretending to be outraged at the thing you knew was going to happen.
"But but but... they should pay me anyway, because they're profiting off my labor! It's what's fair!!" - What's fair is for someone to take you at your (and your software license's) word, to do exactly what you told them they could do (profit off it). What's not fair is to turn around after they're hooked on your free thing, and try to force them to pay you for it, after the fact.
The point of open source is only to open up the source code, allow people to contribute, collaborate, and share. If you want to get paid for it too, don't put an open source license on it. It's that simple. Add whatever terms you want. But don't make FOSS and then later say it's unfair for people to do exactly what your license said they could do.
Despite the submission title, I don't think I would call this proposal a way to force companies to pay for free software. They could choose not to pay if they don't want to use the software. If they've already downloaded the software, then they wouldn't need to pay unless they want to download it again, but they are free to make as many copies as they want so re-downloading is mostly going to be a matter of convenience I think.
I believe free software is better than proprietary software, so I think it's good to better incentivize the production and maintenance of free software.
Using nicer language doesn't change the argument. You're still suggesting that corporations be required to pay for the software, which is a reversal of the terms of the license.
Let's ignore for the moment that this is manipulative behavior (switching from free to paid after the fact, the same thing users complain about corporations doing). This is likely also illegal. The software license is a contract. Permissive FOSS licenses grant the use of the software in current and future forms without payment. To withhold the source code until receiving payment would be a violation of the contract terms. All of the copyright holders would have to agree to change the license to no longer be Open Source, and even then a judge may well find it illegal.
It's also a bad idea because it would split the community. I find this action so unethical that I would no longer contribute to or use any FOSS that required payment. I didn't get into this community to shake companies down for cash. If you want to make money off software, go do that somewhere else, or do it with services and support.
You don't need to change the license at all in order to do this. Withholding source code while providing an executable would violate some free licenses, but all free licenses allow withholding both an executable and corresponding source code simultaneously.
An action like this could split the community, but I don't think it would be very visible to people contributing to the software, since I imagine the source code would still be available on a public git repository with the same license, for the purpose of development. Do people complain about Krita being on Steam [1]? It's not exactly the same situation, since Krita never was on Steam before, but do you think the situation would be so different if Krita had been free-to-download on Steam and then they changed it?
FOSS licenses don't allow requiring payment for source code. Even if they did, they would have to do it for all users and not just corporate users, or they'd be violating their own terms against discrimination on fields of endeavor. What they can do is charge for binaries of the software, which is completely different. And they can't stop anyone else from redistributing it for free. So the first person who pays for it can just give it to corporations for free, and the copyright holder can't do squat about it. These are all features of the licenses, to prevent nasty developers from putting up roadblocks and gates to prevent the collaboration and sharing of the source code.
A corporation is a user too. Imagine if instead of corporate users, we were talking about rich users. Or imagine if 99% of the public used the code, and none of them paid, so people started talking about forcing the public to pay for the code.
Nobody asked the developers to make this code. Nobody asked them to put a FOSS license on it. Nobody ever promised payment. But now that they see dollar signs, the developers want theirs. It's greed, pure and simple.
FOSS was not created to give volunteer developers a living. It was created to give people freedom. No more, no less.
Free licenses all allow requiring payment. A license that disallows charging for the software as a whole would be a nonfree license. An example of a license condition that does this is the "Commons Clause" [1]. See the FAQ question on that page which says "Is this “Open Source”?" (short answer: "No.").
If someone decides to charge businesses more than individuals, that is arguably discrimination based on fields of endeavor, but if the discrimination isn't written into the license, the software could still be free. Corporations are still free to use free software however they wish, but they can't force software repositories to choose to distribute software to them directly.
It's true that someone could set up a different software repository that offers largely the same software to corporations at no charge, so the proposal only works if companies would prefer to pay the fee rather than set up a different repository. It sounds like companies already pay to use an intermediary repository, if I'm correctly understanding what Artifactory is, so maybe the proposal wouldn't actually work.
If 99% of the public used a piece of software, there's a good chance people really would be forced to pay for it through taxes. This apparently already happens with some proprietary software (though I didn't look into it); see "Public Money, Public Code" [2]. Taxes are a different situation though.
Software freedom can't exist without free software. The better funded free software is, the more free software will be able to compete with proprietary software, and the more free the world will be, with regards to software freedom. The proposed system of charging corporations could conceivably be better even from the perspective of the corporations, if it leads to free software becoming more reliable.
I know you don't mean "nobody" literally, but I actually have asked people to write free software and to license existing nonfree code with a free license. It might be true that you didn't ask for people to make free software, but would you prefer a world in which they didn't?
If they did have it set up, then somebody wasn't doing their job. If they didn't have it set up, they didn't comply (which is also not doing their job). I see this all the time. The security analysts send tickets to people when they see major issues and nobody is held accountable for inaction. Management asleep at the wheel (which is also their cover, can't be blamed for what you made sure you never knew about).
reply