This development is great news for automotive, since modern coreutils can't be used there because of the anti-tivoisation clause conflicting with government regulations, which forces vendors to use old unsupported versions.
This is a sad state of affairs. The world does not become a better place by rewriting working copylefted code into permissive licenses. Especially when the main goal of the rewrite is to ease corporate "theft" of these codes. We are walking several steps backwards with these rewrites (as much as I love the concept of rewriting common tools in a safer language).
EDIT: I'm actually outraged by this. I want to love the rust rewrite of coreutils, but I don't understand why they had to taint this beautiful work with stupid license politics.
Are you also outraged by the existence of clang, as it has a permissive license and competes with GCC?
From where I'm standing it looks like you are the one introducing the stupid license politics. The Rust Coreutils developers have chosen a license that they like, and you are the one making arguments about how terrible this is for the world and how they are tainting the GNU Coreutils.
Maybe you should be outraged by GCC's deliberate sandbagging and less deliberate stagnation that allowed LLVM to swoop in and be a legitimately more useful (if not "better") compiler.
Stallman himself was largely responsible for GCC not exposing intermediate representation for analysis.
There is a world in which rustc might have been built on gcc instead - a world where GCC was interested in being a platfom rather than a Maginot line trying to prevent any possible theoretical use by proprietary software even if it means preventing free software from doing the same.
> that allowed LLVM to swoop in and be a legitimately more useful (if not "better") compiler.
Interestingly enough, if Stallman didn't miss the email[1], LLVM was intended by Latner to be given to the FSF[2]. So yes RMS did commit a management mistake, but it's not the one you think.
> The patch I'm working on is GPL licensed and copyright will be assigned to the FSF under the standard Apple copyright assignment. Initially, I intend to link the LLVM libraries in from the existing LLVM distribution, mainly to simplify my work. This code is licensed under a BSD-like license [8], and LLVM itself will not initially be assigned to the FSF. If people are seriously in favor of LLVM being a long-term part of GCC, I personally believe that the LLVM community would agree to assign the copyright of LLVM itself to the FSF and we can work through these details.
> Stallman himself was largely responsible for GCC not exposing intermediate representation for analysis.
This is wildly offtopic for this thread, but it is not clear that Stallman's stance on this issue was an error. The wide existence of LLVM-based compilers for proprietary architectures is, for many of us, a tragedy that Stallman correctly anticipated. His insightful and courageous steering of the GCC development was a crucial step in avoiding this problem for GCC.
I definitely believe that for the first N years of gcc the policy was absolutely necessary to drag vendors into actually contributing back.
Whether that's still true in terms of the trade-offs being worth it to maintain the policy in the current day, and if it's no longer true what value of N accurately describes when that changed, is something that I think people can reasonably disagree about.
(my extremely boring take being "there's so many counterfactuals here I'm really not sure")
Isn't it also precluding several non proprietary compilers as well though? In turn making LLVM more popular and making it even more appealing to propriety compiler authors.
GCC is a great C compiler and most of us are happy to keep it that way. The constant drumbeat of 'different different different' is not something I'm interested in. That I can compile C code written before I was born is more than I can ask for. In the same period a dozen safe languages have come and gone with no one even thinking about them any more.
It's disappointing but it's not worth assuming any malice or continuing flamewars. There's been some discussion on the project's GitHub page in the past about licensing.
What's worthwhile is to share and talk about why the license selection may result in proprietary and bloated applications built upon the stack, and the resulting inefficiencies and security issues that could occur years in the future as a result. Perhaps it'd even be possible to speculate about what incentives create and support the conditions for those.
If enough people agree and understand the situation, perhaps we'll see change. If they don't, we'll continue on for a number of years and maybe those hypothetical problems will occur, or maybe they won't and the concerns will have been unjustified.
Coreutils is mostly UNIX/POSIX standard utilities which have been implemented under many closed and open source licenses for decades now. This is not where you build the GNU/Moat.
But GNU coreutils are ahead of all proprietary alternatives in both speed and features, are they not? I've personally not had the opportunity to work on AIX, or Solaris, or whatever (there are no machines like that where I live), but that's what I always read: "we got a new AIX/HP-UX/Solaris/whatever server and the first thing I did was to build GNU coreutils and replace the stock crap with it".
How do you know if the platform tools are faster\slower more featureful or less if the first thing you did is replace them?
GNU coreutils won on portability of knowledge, no need to learn how the platform's tools work when I can just roll with GNU. Which is great when you are dealing with multiple different varieties of Unix that are all slightly different. In general the base os tools where like all software that competes in the same space, it did somethings better and somethings worse.
People know that GNU tools were faster simply because the GNU versions' developers had famously optimized the hell out of them (many research papers written about this back in the day), while preexisting Unix tools didn't have that much optimization.
>I don't understand why they had to taint this beautiful work with stupid license politics
It's pretty simple reasoning: Rust evangelists want to maximize Rust usage. Period. Replacing GPL-licensed tools with alternatives written in Rust is an easy way to bootstrap this. Compare with: paperclip maximizer (https://www.lesswrong.com/tag/paperclip-maximizer)
I have to deal with government regulated certification in a different industry. In our case there's a hard requirement to make it impossible for the end-user, which is some business, to run modified software on the devices. Reason being, the devices carry out financial transactions and the possibility of running modified software on them would potentially enable fraud. Basically, the whole point of certification in this case is to verify that the software doesn't have provisions for doing anything fraudulent and then making sure it stays that way. So GPLv3 anti-tivoization requirements and the certification requirements are mutually exclusive. I imagine it's similar in the automotive industry for safety reasons.
> make it impossible for the end-user, which is some business, to run modified software on the devices.
Looks like that device might not be covered by the tiviozation close since it might not be an user product as defined in the GPL
> A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling.
If you sell to business, that should be alright.
Also, it is fine to make it impossible to modify, if you also don't have this possibility:
> this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product
Service technicians can and do update the firmware on automobiles to fix issues, and normally these are digitally signed by the manufacturer, so random people can't use this path to disable the emission controls on their car, for example. So the anti-DRM language is an issue.
> In our case there's a hard requirement to make it impossible for the end-user, which is some business, to run modified software on the devices.
I guess you're working on credit card terminals?
Anyway: why not have a secure hardware element / TPM that has a GPIO with a pull-up resistor that can be queried by the device? Then, have the bootloader check as part of the boot if the TPM attests with a digital signature that the GPIO is still high, and the application also regularly checking the TPM? Or an e-fuse similar to Samsung's Knox Guard?
That way, a user can remove the pullup resistor (and thus, as it's a hardware modification, has to break the seal of the device) to "unlock" custom firmware loading to fulfill the GPL requirement, but at the same time your application can be reasonably certain at run-time the device hasn't been tampered with.
In our case tampering with the sealed parts of the hardware by the user would be illegal. I'm not sure if providing an illegal method to load the firmware fulfills the GPLv3 requirements.
EDIT: So, I don't think this is actually a technical question. It's a legal question that boils down to the fact that a premise and its inverse can not both be true at the same time.
the hard part when enabling self-tinkering is the forensics and the burden of proof for accidents, especially lethal accidents.
how do you ensure beyond doubt that the vehicle was not "tampered with" by an "unauthorized unqualified third party"?
would I want to own a car where the oem can turn around burden of proof and can easily claim I have modified the vehicle software, and thus broke vehicle behaviour?
oem: you've patched coreutils, that's what killed your wife, your fault!
me: no. that's technically impossible. the drm disables third party modifications.
now if you provide means to do it anyhow, you'd need to make forensics crystal clear.
so you as a customer want the physical modification to be dead obvious even on a burnt vehicle. especially on a burnt vehicle. so you as a customer can show that you did in fact not unlock software modification.
and state regulations for that reason require drm from car makers, to make it impossible to evade responsibility with flakey claims of third party modifications.
Is it a hard requirement or is it about vendors being overzealous because it also fit their interest?
I know that the law requires some radio equipment to make it hard for users to modify so that they can't mess with some parts of the spectrum.
But for cars, the responsibility is typically of the user, that is, if you modify your car in a way that is not what the manufacturer certified, you can but you have to do by the rules or face the consequences, the manufacturer is not responsible.
But by locking down software hard, it is a way for manufacturers to make sure that they can't be held responsible and the side effect of locking down features is a nice bonus.
I understand your point of view, but it's important to remember the end outcome:
Users will be forced to use outdated, buggy software, or vendors will write minimal closed implementations covering only what they need, without the benefit of the accumulated good work in foss (bugs, lack of features, etc)
I find it a bit strange that the rewrite is licensed under MIT. Are they doing a clean room reimplement or are they rewriting the core utils by looking at the source code?
In my experience looking at the source code of programs written in a different language is rarely helpful. It's only useful to glean some general ideas or algorithms. But rewriting with one eye on some C code? Rarely helpful and usually counterproductive.
Not necessarily. The non-GPL utilities the GNU coreutils are based on are presumably licensed as MIT, ISC, Public Domain, or similar. If that is the case, those licensing regimes don't forbid adding extra restrictions, so adding the restrictions of GPL would be permitted, and the new derived (again, assuming interfaces are copyrightable) work would operate as being essentially GPL licensed. Things get murky as there are proprietary utilities too that coreutils are probably based on, but then there are also specifications of behavior (SUS, Posix) which might or might not sever the "derivation path" of the work, or might introduce further licensing constraints.
Do you view APIs as something other than an interface? A ruling from the Supreme Court may not reach the ultimate issue, but if it does, what assumptions would you make concerning the difference between an API and a program’s interface with the user?
Wouldn't busybox (GPLv2) or toybox (BSD) be a better choice than an very incomplete Rust rewrite?
To start, both of them were write with embedded applications in mind, busybox is feature complete since distros like Alpine and OpenWRT use it (not sure about Toybox, but I know Android ships it).
BTW, both of them cover way more tooling than coreutils too. Busybox for example have a primitive init system and a vi/vim clone. You can also of course disable them during build time.
One motivation for using Rust is to eliminate whole classes of bugs. Certainly busybox is great for embedded applications; one executable serves so many functions. But the more you add to it, the more attack surface you have.
I am sure that a project that is 21 years old has much less bugs than a new project that had its first release one year ago, independently of the language.
Huh? Plenty of CVEs found in C/C++ codebases were introduced decades before they were discovered. In fact, it seems to me that the older a C/C++ codebase is (especially C++), the more bugs is has, simply because improved coding practices and "modern C++" features have a far greater impact than amount of user feedback and experience. But best practices and modern C++ features are just a poor man's (semi-effective) borrow checker. ;-)
More seriously. I agree that you can't call rust-coreutils mature yet. But over time maintenance on it will probably be considerably easier and if it ever gets popular enough to be thoroughly battle-tested, it almost certainly will be more reliable and secure. In addition, odds are that even if still immature, it already has fewer serious bugs. Especially memory safety, but also in things like string-handling since C++ -- and especially C -- string handling is notoriously difficult to get right. Then again, maybe not, since coreutils and presumably also rust-coreutils take the stupid approach that strings are just streams of bytes and there's relatively little the Rust std and compiler can do to fix that mess. Oh, wait! Actually it can help a bit by allowing you to be "flexible" in your interface but also parse and validate at the interface, then use better abstractions internally.
Case in point: OpenSSH vs rustls: OpenSSH is a lot older than rustls, has been extensively battle-tested by a very expert community, has been audited, fuzzed, etc to a significant degree, and we're still now starting to see security experts advising using rustls in stead of openssh, or projects deciding to switch to rustls because rustls is likely (and according to a growing body of real-world experience and evidence) less buggy and more secure than openssh. (And as a bonus it's also faster.) Not all of openssh's issues are due to the language, and neither is rustls's choice of language the only reason for its reliability. But in both cases the implementation language does play a crucial role in their security and reliability.
Some governments require that one cannot install one's own software on automotives for safety reasons?
That is quite interesting, but since one can modify one's car to begin with to make it unsafe, it is also rather futile.
Rather, a sensible system would be that after such modifications, a car would have to pass inspection again to be deemed road-worthy. — one may change the software, but one must pay to have it certified again ere it be allowed on public roads, and if that not be an option, one can always simply drive it on private property only.
> That is quite interesting, but since one can modify one's car to begin with to make it unsafe, it is also rather futile.
In France, if you want to modify your car (in a significant way, not specified by the car manufacturer) you need to send your car to a specific administration were engineer will inspect your vehicle before you can get it a plate number. This is called [Passage aux Mines](«https://fr.wikipedia.org/wiki/Passage_aux_Mines»). You typically have to do it when you decide to repurpose a cargo van as a camping van.
That would shock me if you had to do the same after updating the embedded software of your car.
In Germany, it's called a TüV-Inspektion by the Technische Überwachungsverein. Even unmodified cars have to get certified in regular intervals to ensure they're still street-worthy. Of course you may still tinker with your car, and do all you want with it on private land, and you can get quite a few modifications certified, but flashing some firmware image from Github on safety-critical systems definitely wouldn't get through.
Then the car/vehicle is no longer road-worthy/road-safe and has to be repaired before going on public roads again. If the airbag isn't e.g. discovered in a repair shop, during an inspection or any other place where the car can be fixed without rejoining the public roads it has to be safely towed/transported to a place where it CAN be fixed.
And incidentally it's not a problem of "muh car == muh freedom".
If you want to drive a vehicle not safe by the standards everyone has to adhere to you're free to do that on private property.
If you want to drive a vehicle on public roads where probably nobody knows about anything stupid you've done to the vehicle, i.e. a 1-2+ tonne lump of metal, glass and plastic probably with some sharp points/edges moving at a significant speed quite close to other people without any protection whatsoever. It's just horrifying accidents waiting to happen.
Let's take the example of someone fucking around with the airbags in the car. If they're not known good, they might as well go off at any moment during the drive, possibly incapacitating the driver while the car is moving at normal road speeds, making the car veer around wildly and generally being an extreme hazard. There is a reason cars have to certified and adhere to standards of road-safety/road-worthiness.
P.S. When a topic like this comes up I always have to think back to my father when e.g. a commercial/TV-programm about super-/hyper-cars came on. He almost always said "Dafür bräuchte man eigentlich einen Waffenschein." ("One SHOULD need a weapons license for that thing.") in the sense that in our country (Germany) prospective gun owners need a license which IIRC requires amongst other things a psychological examination/certificate to ensure that no irresponsible, no mentally-ill, no mentally-challenged etc. people get the license to own guns. MEANING driving around on public roads with something that's essentially a road-going mix of a missile and a door wedge should probably something like an idiot-test. I mean it's already standard practice to deny RENTALS of cars above a certain power threshold to people under something like 23 or 25.
Sure, on the front PASSENGER seat and not permanently. Screwing around with software control etc. of airbags and other security features is (I hope) very much illegal and a reason for taking away the operating license of that particular car.
But it's documented because you might need to, for example carrying babies on the passengers' seat or if the airbag is malfunctioning and you need to go to the repairing shop it might makes sense to disable it.
> for taking away the operating license of that particular car.
why not the death penalty then? :)
The airbag arguably only saves the driver's life, disabling it has the same effect of smoking cigarettes, except cigarettes are vastly more dangerous.
They don't take away your license for smocking (I guess)
I agree with your view, but as I mentioned in another thread, bringing the change is very difficult, especially when you're not in a position with sufficient power.
You should finish that thought: and the manufacturers won't invest their money to certify something that's open source and can be used by everyone, including their competitors.
If there was a will to do something about it, GPL3 wouldn't be in the way.
No, GPLv3 requires you let users replace the software -- in some cases there are safety checks in the software which could be turned off if the user installed an alternative they built themselves.
That isn't allowed -- you fail verification if you give users a documented way to disable required safety features.
No, manufacturers want to use free software, but they are forced to avoid GPLv3 for this reason alone.
Unfortunately, challenging the status quo is difficult when your customers are not the final users, but other companies: if you don't deliver them a free software firmware without GPLv3 components, someone else will, or someone else will deliver something that's completely proprietary.
Manufacturers want to use free as beer software, but want to avoid expenses required to upkeep free software, or share these expenses with competitors.
As developer of free software, I don't care about those, who don't care about me.
I think you are both wrong. The purpose of a certification is to mitigate risk. If the licensor of the software has no money, there is no one to sue, and the risk is not mitigated. I’m not advocating this mentality.
> No, manufacturers want to use free software, but they are forced to avoid GPLv3 for this reason alone.
good.
It means that GPLv3 works as intended.
EDIT: as intended by the software authors, that chose freely GPLv3 as license, they were not forced to.
I'm quite sure they knew what they were doing.
If car manufacturers want to use GPLv3 software, they simply need to respect the license the author released their software under or rewrite the software.
What's the point of wishing for existing FOSS artifacts (supposedly) "being more widely used" if it stops giving the foundational freedoms to the user?
Free and open source software is not all about "best utility for users". It's about freedoms being valued extremely highly; people self-select for being or not being the consumers of it.
What is a "freedom" is highly subjective. For example the GPL doesn't enable the "freedom" to create proprietary derivative products or tivoized products. Why is that better than the "freedom" to flash their firmware? It is just a matter of opinion.
> If by that you mean preventing free software from being more widely used
That's false.
It simply prevents the Tivoization.
GPLv3 was created exactly with the purpose of preventing free software from becoming a commodity.
There's a cost involved when you use free software:
- the software must stay free
- if you include software licensed under a FOSS license, you have to adhere to the license terms
simple as that.
If the authors of software X or Y chose the GPLv3 as license I imagine they were completely aware and agreed to the terms of the license they used, including the limitations it enforces.
> If the authors of software X or Y chose the GPLv3 as license I imagine they were completely aware and agreed to the terms of the license they used, including the limitations it enforces.
That is certainly not universally true. It is common, but not universally true.
And we should assume that the authors were NOT aware of real ecosystem implications of licenses - because nobody understands these in detail. I've been trying to understand them since the mid 1990s when I started contributing in a BSD environment, and I won't say that I properly understand them. I understand parts of them, but I don't understand all of them.
And then the user loses the certification, as you said in another reply[1] the “user” you're talking about are other companies, so I don't see why they would decide to break the certification they got from their supplier just for fun.
Edit since the parent was in fact speaking about the end-user, which I misunderstood: I don't see the problem either. The manufacturer has no obligation to prevent the end user from updating his car's software. There is no locks that prevents the car owner to just disable his airbag[2], or remove the safety belt. It's illegal to do so in most countries, and if the user do do and injure himself or somebody else because of that modification, they are on their own. I don't think it should be any different for software actually.
[1]: https://news.ycombinator.com/item?id=26397176
[2] Edit: in fact, this is a bad example, because you need to be able to disable the airbag to put an infant car seat next to the driver.
No, the user that matters for GPL is the car owner. The point in the linked comment is that given how the market works, there is little incentive to work towards changing regulation (or even just interpretation of or belief about the regulation, I have clue if there are actually countries where this is impossible, but know for sure it's a widespread belief in the industry), because the company applying for certification is not the one getting annoyed by having to avoid GPLv3.
The chain of software delivery often looks like this:
Small subcontractor delivers parts of system→ big company provides ready to use solution → hardware vendor uses the solution and gets their devices certified → end user uses the final product
In this case, the hardware vendor is mostly interested in having their devices work as intended. Everyone up the delivery chain has to meet their requirements in some way to basically get paid. That's not a position where it's easy to make demands regarding certifications, since the hardware vendor may just go to someone else.
if your car kills your kid, eg the airbag misfired, or the lane assist went into oncoming traffic, then the car vendor will look for any opportunity to evade and refute responsibility. including claims of self tampering with the car. now in the burnt wreck, forensics need to show beyond doubt that it was, indeed, the car vendors shipment that killed the kid. how do you show as DA, that indeed the software was untampered with?
drm.
ps: airbags not working is less of a software problem than airbags misfiring.
GPLv3 says that manufacturers have to release all the information needed to run modified software on the device, it doesn't mean that there is one (and one only) certified version that can legally run on the device for safety reasons.
GPLv3 in this case would force manufacturers to release the information so that the owner of the car could run modified software, but legally if you do it, you, the user, not the manufacturer, are violating the law.
It's the same thing that happens with electronic blueprints, you can modify the HW, it will void the warranty if you do it.
--------------------------------------------
Protecting Your Right to Tinker
Tivoization is a dangerous attempt to curtail users' freedom: the right to modify your software will become meaningless if none of your computers let you do it. GPLv3 stops tivoization by requiring the distributor to provide you with whatever information or data is necessary to install modified software on the device. This may be as simple as a set of instructions, or it may include special data such as cryptographic keys or information about how to bypass an integrity check in the hardware. It will depend on how the hardware was designed—but no matter what information you need, you must be able to get it.
This requirement is limited in scope. Distributors are still allowed to use cryptographic keys for any purpose, and they'll only be required to disclose a key if you need it to modify GPLed software on the device they gave you. The GNU Project itself uses GnuPG to prove the integrity of all the software on its FTP site, and measures like that are beneficial to users. GPLv3 does not stop people from using cryptography; we wouldn't want it to. It only stops people from taking away the rights that the license provides you—whether through patent law, technology, or any other means.
The key point is if certification is possible for a device that allows arbitrary software to be run or not. If it is, we have your scenario. If it isn't, it's not possible. I don't know if the former case is true for all countries, I certainly know that the market overall believes it's not, or not worth the hassle of arguing it with other companies and regulators.
As I understand it the manufacturers need to release only the information, nowhere GPLv3 says that the manufacturer should make the process of running custom software easy or economically viable, just that the information should be available.
But as I've said I'm no law expert and I wouldn't put my hand on fire about it.
I'm sympathetic to Stallman's goals, but for some applications this presents a huge problem: if anyone can modify their car's auto emissions software, everyone can play Volkswagen and make their car high-performance and dirty as hell. Or people can extend the range of their WiFi by exceeding the legal power levels for unlicensed bands and making a frequency band unusable by their whole neighborhood. Or, modify someone's medical device's software to provide a very sneaky way of killing them. Now, there may be a way to solve these problems, but it would probably involve adding some unchangeable mechanism to limit the behavior of the device to keep it safe. But that's very difficult to do. Certifying that a fixed program has certain safety properties is difficult but possible; certifying that a new kind of design that allows users more freedom to tinker, but not too much, is much harder.
GPLv3 banned tivoization, — a practice whereby hardware certificates are used to prohibit the installation of modified software on hardware.
Some governments require that automotive manufacturers implement these kinds of certificates to prohibit the installation of custom software in automotive applications for safety reasons, as they do not wish that users could install their own, potentially buggy software, at the potential cost of human lives.
Older coreutils were licensed under GPLv2, which has no such restriction.
I'm confused. Surely you can install the modified software? It's just that now the local jurisdiction may not allow you to use your car on public roads. That's a bummer, but a political problem that exists between the user and his government, not a software problem between the user and the car manufacturer?
If the firmware is burned into ROMs at the manufacturing plant, how do you propose the car owner installs their modified version? Do we need to force all parts manufacturers to put ROM burners hardware and (replacable) firmware into every part, and OEMS to provide consolidated hardware interfaces to allow that, and car manufacturers to dedicate all the infrastructure required to allow access to all the OEMS who allow access to all the parts for all the various firmware updates?
Sure. Starting price for a car would be several years salary but at least you could abide by GPLv3 licensing should any part manufacturer choose to use it.
Very little outside of the in-dash infotainment system runs on Linux in a car.
I deal with manufacturers and OEMs putting software in cars for a living. I am not speculating, I am just reporting the reasons they tell me they will not accept any GPLv3 software for anything that gets loaded into their target devices.
1. They are lying, and spreading FUD about regulations and licenses as an excuse to hide the real reason why they don't want to let user install their software. (Eg, because options costs extra and if it was free software one could install it for free)
2. Or, they are mistaken and don't understand the license. Maybe the cost to use alternative is less than the cost of figuring out.
3. They are right and that is a sad reality that the government give more power to companies than power to end users for things they owe.
Since you mentioned something about the ROM which was clearly false, that could very well be option 1 or 2.
I mean, why would the gouvernement want to restrict users to update the GPS software or the media player?
I think that's a problem of interpretation more than a hard obstacle.
In many projects there is the requirement of a fixed release for 3rd party dependencies, versions for which all tests have been checked to pass (this is what is done in NodeJS with packages.json). There is even a requirement of reproducible build sometimes (like with the ongoing project to reach full reproducibility in Debian builds).
Wouldn't these fit the same thinking pattern as the requirements of certification of software for the industry?
I'd love to hear RMS on this subject, maybe he would, too, say that the solution exists inside of GPL3 rather than outside of it.
I'm sure there are ways to solve it, but they probably require both lawyering and developing technical solutions, which unfortunately the industry isn't much interested in doing, partly because there isn't enough pressure directed at them to change the course of things. Such pressure, in my understanding has to come from the regulators, but for that to happen they need to be convinced this is the right thing to do, and that isn't an easy task.
