And when they need a doctor and dentist because bread and jam are not particularly good choices for a staple diet (if you have another option), those with money will cluck about how it's their own fault for making such a poor nutritional choice.
Government services are supplied through the internet now. Many schools post homework on the internet and require students to use it. The kids DO have a right to public education. You might recall a spot of trouble we had in 2020 where internet based teleconferencing became the only way to attend school, for example. You can argue all you want about how effective that was, but since it was the only option at the time, it would be hard to argue that it wasn't better than nothing. Are you prepared to fund the schools and other government agencies going back to 100% paper?
Welcome to the 21st century. We've been waiting for you.
For me, the last time was when temperatures were dipping below freezing and a rain/snow mix was starting to fall. I needed to know about driving conditions. Real time observations from the traffic copter were quite useful.
Because AM radio is a key part of the emergency broadcast system and also plays an important role in disseminating information for more localized emergencies. By including an AM radio in every car, they make sure that pretty much everybody will be able to get information in an emergency.
They manage OK in an ICE vehicle with it's spark gaps, alternator, electric radiator fans, etc.. Add in a buck converter or 2 for the in-dash display and the USB jack, power door locks, power window motors. Then there's the computer for the in-dash display.
NAH, they just wanted to cheap out and lat the marketing department claim a slightly larger usable trunk space.
An ICE vehicle has between 4 and 8 spark gaps under the hood. Note that spark gaps used to be used as a central element of an AM transmitter.
If someone is that concerned about it, they can get that small bit of range back by peeing before they get in the car.
You're assuming that they need to actually control the noise.
True. The text of the bill says nothing about harmful interference. However, there is the implication that the receivers being mandated might actually work, and not just for the vehicle operator, but for the vehicle in the next lane as well.
The vehicles in the next lane can always slow down or speed up or change lanes to move away from your car if your car makes its radio too noisy, so that's likely to be a non-issue. I haven't measured the field strength from an EV to see if it exceeds those limits, though, so I could be wrong.
Note that the FCC allows AM transmitters up to 1705 kHz under section 15.219 without a license as long as the ERP is below 100 milliwatts and the antenna is no more than 10 feet tall. There's no transmitting antenna in an EV, so as long as the ERP is below 100 mW, presumably that qualifies. For frequencies above that limit, section 15.223(a) gives you a field strength exception, and given that we're talking about wideband noise, presumably no stricter narrowband limit should apply, so the limit is likely 100 microvolts/meter at a distance of 30 meters, which is, I think, in the neighborhood of 200 mW ERP. The stricter limits under section 15.209 presumably do not apply because it is not an intentional radiator.
That said, there may be additional rules that I don't know about, so take that with a grain of salt.
AM Radio is absolutely nothing in terms of vaults, because you can literally run one off of a AA battery for hours.
This has nothing to do with saving money. Because when they build these things en-masse and buy them from a supplier that's already making them, they're probably already cheaper than they could build themselves And it wouldn't even add a dollar or so to the cost of the car.
I wouldn't say the cost is quite that low. Modern head units are all digital, so you have to take into account the cost of adc circuitry and integrating it with the software stack. Between that and antenna considerations, it does carry an additional (though negligible) engineering burden.
Either the FM radio in the car is analog or it is doing some sort of software-defined radio thing, but either way, analog-to-digital conversion is still effectively occurring in the radio circuitry already, which means that could be done for AM just as easily. So that part of the cost should be quite close to zero beyond the cost of the AM receiver circuit itself (and for SDR, it would probably be exactly zero).
The real question is whether an AM tuner can usefully function with that much environmental noise, or whether you need to come up with something significantly more complex in terms of the antenna(s), demodulator(s), etc. It's the frequency and the modulation that make it problematic, not the analog nature of the signal, because notwithstanding the existence of HD Radio, a large percentage of FM is analog, too.
Yeah saying it would affect ev range is hilarious straight up lying.
No, they're not.
Controlling RF noise is hard. Especially when you're switching enough current to accelerate your four ton electric tank from 0-60 in 4-something seconds while you're saving the planet or whatever.
You're assuming that they need to actually control the noise. Strictly speaking, I'm not sure that's a safe assumption. The only absolute requirement is that the radio must reject enough of the noise go get a usable signal. Whether that happens by the car having more shielding, by putting the antenna farther away from the source of noise, or through the radio being more capable of rejecting outside interference is an implementation decision.
Some other approaches might include:
How effective any of those approaches would be is anybody's guess. I'm thinking the last one is probably overkill (and probably wouldn't work anyway), but beyond that...
You misunderstand me. Most of the companies that use or make money off of open source don't employ people to actually work on that code at all. They simply use it and integrate it. For them, the fork is viable if it does what they need it to do.
If the fork does not see any development then it is pointless. And if the original does get updated unlike the fork, then the fork is non-viable as well.
Nonsense. There's plenty of software out there that is basically mature. Why would you think that this software suddenly becomes non-viable merely because it isn't getting changed?
Suppose, for example, that NGINX or Apache decided to switch to this sort of license. Both are mature products that are entirely usable right now. And apart from security fixes (which tend to be straightforward, and could very easily be replicated in a fork based on the original license, and almost certainly would be replicated in every fork if forks existed), there's no requirement that development continue to be ongoing for it to be useful.
The only way a fork will be viable is if it's being developed, and who will be developing on it for free when they could be paid working on the original?
Employees working for the companies that own the 4.6 million servers currently running NGINX or the 3.2 servers running Apache. After all, arguably most of them are part of a commercial product, in a manner of speaking.
Not sure what any of that has to do with how much 1% of their revenue would be.
1% when the the total OSS budget is 1% of revenue is certainly a lot (100% increase). But 1% when the budget is 50% of revenues, that much less (2% increase), and could be within the normal budget variation year-over-year.
But the total OSS budget for software licensed under this license always starts at zero. That's the whole point. This organization doesn't exist yet, and has no software licensed under its code. Therefore every company is starting at zero. Apart from companies that already *produce* open source software *and* have the right to relicense it under this sort of license (which is probably a very, very small number of companies), it really doesn't matter if the company is paying people to work on open source software already, because none of those expenses will go away under this regime. The only thing that matters is that the second they add one piece of software under this license, they give up 1% of their revenue.
None less, realistically. Companies employ people to improve the things that they want improved. Relying on outside parties to do the improvements means waiting for it to be somebody else's highest priority.
True to some extent. But the big reason it is like this in the first place is because the developers have limited time to spent on what is generally a pet project. Big or niche features will still need direct funding by corporation indeed, but bug fixes and general maintenance could be done by the developers instead of the employees.
While that's true to some extent, big features that corporation A wants still aren't going to be a priority for corporation B unless they have a contract with corporation B that says that they will provide that feature, and even then, only to the extent that the contract requires. In the grand scheme of things, it will still always be way faster to just hire people to do the work no matter how big the existing team working on the tool/library is.
In fact, I'd argue that the amount of time it takes to get interesting features added actually gets longer the more people are working on it, so if corporation A wants a feature added, it would likely take longer to get corporation B to add it than it would if that product were maintained by a solo developer. And that's triply true if corporation A could just hire that solo developer, as is often done.
The fastest way for a company to get things done in an open source project is to hire the lead developer. The second fastest way is to hire a team to do work on the project and contribute it back upstream. The third fastest way is to hire a team to do work on the project and fork it because the upstream maintainers are intransigent or unresponsive. The fourth fastest way is to hire a team of outside contractors. The fifth fastest way is to enter into a contract with the corporation that owns the project. And the absolute slowest is to just ask the corporation that owns the project.
the people licensing that code did so under permissive licenses with the understanding that this would happen
There is difference between understanding/accepting and liking. Currently their choices are limited: free/OSS or proprietary/custom license. And to be paid, they would have to deal with each and every licensee separately, which is time consuming and unappealing.
There's actually a third choice: dual licensing under the user's choice of a paid commercial license or GPL/AGPL, with copyright assignment requirements for all external submissions. People/companies that can live with the terms of the GPL or AGPL get it for free, and those who don't can pay a licensing fee for a less restrictive license that is negotiated on a case-by-case basis with the company that owns all of the rights.
The proof of their interest in a Post-Open like system is the popularity of Patreon.
From what I've seen, Patreon is more a way to turn software into a continuous income stream, mostly paid for by individual users who aren't making money with it. It's kind of the exact opposite of this.
The problem is that the incremental cost of going from zero covered software to a single piece of covered software is 1% of your revenue
It depends a lot of what that "single piece of software" is. A 1% increase because of a fast memcpy library is certainly too much to ask. A 1% increase just for the use the Linux kernel is certainly a steal.
Only if there are no other usable open source kernels out there. If the Linux kernel switched to this license, you'd see every commercial user of Linux suddenly switch to FreeBSD, NetBSD, or OpenBSD, and depending on how loosely "included as part of a paid product" is interpreted, that could even include all the companies that build single-board computers like Raspberry Pi, at which point Linux development would basically dry up overnight.
I mean if it is just 1% of the products that include that software, *maybe* some existing companies might just keep doing it because of momentum initially, but for any new companies entering the picture, they'll have to decide if the difference between Linux and *BSD is worth 1% of their revenue, and most will likely conclude that it isn't. And those new companies will undercut the companies that are still using Linux, which will likely force them to switch to a cheaper kernel just to compete.
"If I add this one piece of software that would cost me X engineer hours to rewrite, it will cost me 1% of my revenue,"
That quite a bit of an oversimplification and hopefully the companies won't fall into that trap. This is basically the same cost as those falling into the NIH syndrome, which is always way more expensive than one thinks.
Oh, but that is exactly how big companies see software development, or at least that's how every big company I've ever worked at has seen it. And you're right that it's not a good idea, but it is still the way MBAs think. I've never worked at a non-startup company that didn't behave that way.
IMO, it is likely to be much easier to convince companies to pay a specific fixed amount per licensed inclusion than a flat fee per unit, because a lot of those products won't derive 1% of their value from licensed inclusions, and all of those products' manufacturers will actively seek out cheaper or free alternatives, and won't end up paying anything into this fund, whereas if you made the fee be per licensed inclusion, then each individual included work (library, etc.) could set a reasonable price for that specific work, and those companies would see a reasonable price per product and therefore most of them would pay money into the fund. Thus, the free market would end up finding some sort of market equilibrium pretty quickly in a way that it just can't with a simple flat rate per product sold.
And even for companies where the cost just happens to end up being the same 1%, they'll still likely favor the per-product licensing approach, because that avoids unnecessary lock-in risk. Consider that from their perspective, a year from now, the fees could double or triple or quadruple. If they're paying on a per-tool/library basis, they could then consider each licensed product individually and decide whether they can cut some of them out to save money. But if they would keep paying the exact same fee until the licensed work count reaches zero, then it becomes an all-or-nothing deal, which is way riskier from a future budgeting perspective.
So whether you're looking at it from the perspective of human nature, corporate behavior, or market dynamics, every analysis favors a fixed cost per included work per sold product or service, rather than a flat fixed cost per sold product or service.
You're assuming that the companies are actually paying employees to work on it at all. Most of the time, that likely isn't the case.
If the company is not paying the employee to work on that code, then the employee is a hobbyist with regard to that software, and the company can't force said employee to work on the fork instead of the original without violating some laws. And if the re-licensing happened in the first place, it probably means that the company doesn't have the influence necessary to make the fork more viable than the original either.
You misunderstand me. Most of the companies that use or make money off of open source don't employ people to actually work on that code at all. They simply use it and integrate it. For them, the fork is viable if it does what they need it to do.
To use an extreme example, Google brought in $305.63 Billion in revenue in 2023. 1% of that would be over $3 billion dollars.
Yes, and that doesn't mean anything without knowing how much of those $305.63 Billion goes into paying for OSS software already in some form or another (via funding/sponsoring, via paying employees to work on OSS).
Not sure what any of that has to do with how much 1% of their revenue would be.
Then there is the question of much less they would need to pay once Post-Open software can fund themselves and have their own full-time developers instead of relying on Google and others' employees.
None less, realistically. Companies employ people to improve the things that they want improved. Relying on outside parties to do the improvements means waiting for it to be somebody else's highest priority.
Then there is the question of much Post-Open would pay Google for working on Post-Open software.
That's a fair point, but only if its software were licensed under that license, which is likely impossible. WebKit and Chromium (which is based on WebKit) are both based on WebCore, and short of replacing all of that code outright, it can't be licensed under a non-LGPL-V2-compatible license. Similar licensing hurdles exist for Android, Clang/LLVM, etc., though perhaps not to the same extent. Either way, relicensing most of their contributions would likely be infeasible. And that's true for a lot of other companies that contribute code to the open source world.
And that goes double for companies that derive very little of their revenue from software, for whom 1% of their revenue would be completely outrageous.
Indeed. But it is as outrageous for companies to make tons of money without giving back to the community, which is happening **today**.
In theory, sure. In practice, the people licensing that code did so under permissive licenses with the understanding that this would happen. If they had wanted their code to never get used by anyone, they could have licensed it under GPLv3.
Moreover, you're assuming that 1% is a final deal, which it isn't yet and is only an early proposal. Maybe they will offer a tier based system where the percentage decreases as revenues grows (like Unreal/Unity licensing) and/or based on the product categories so that the percentage is roughly based on how critical the software is.
The problem is not whether it is a reasonable number or not for a company earning lots of money off of open source software. The problem is that the incremental cost of going from zero covered software to a single piece of covered software is 1% of your revenue, so no one will even take that first step. And that's a problem no matter what number you choose, whether it is 1% or
Anything that isn't based on how much licensed software is used is a non-starter right off the bat, IMO. The only companies that would be willing to sign on to such a license are the ones who believe that they're getting off cheap by doing so, which is to say companies that plan to use an incredible amount of covered software. Everybody else will take one look at it and say, "If I add this one piece of software that would cost me X engineer hours to rewrite, it will cost me 1% of my revenue," and immediately walk away from the table.
I haven't had any problems with windows since I applied those stickers that keep the birds from slamming into them.
If MS straps just one more JATO to that pig, they'll have to hold a BBQ in the parking lot.
"Sometimes insanity is the only alternative" -- button at a Science Fiction convention.
