Attribution requirements in a free software setting should be viewed as a symmetric property: however you treat incorporated contributions should be a guide (upper bound) for how your own attribution is handled. Symmetry among contributors is a founding principle of Debian licensing requirements, and with respect to legal notices, also seen in the Apache 2.0 (via NOTICE clause) license.
The Free Software Foundation sometimes went further than the Apache Foundation with their About dialog or textual notices for end users, so they would learn about their affirmative rights. The purpose of this "prominent but reasonable" preservation requirement is to retain this end user advocacy. Specifically, the GPL copyright contains a prologue which the FSF wished to broadly distribute. This badgeware stuff is a decade old abuse of this end user advocacy strategy.
An otherwise permissive license with a prominent but symmetric end user notification might be a helpful addition to OSI license options, but care is needed so it is compatible with GPLv3, reasonable to textual or embedded environments, and precludes stupid badgeware nonsense. Standard approaches and bill of materials could improve the state of the art.
This factoring of a market to enable competition by centralizing minimal infrastructure seems the bedrock of best governmental practice. Are there other examples to lean on? How do we turn this into common knowledge?
Why do these open source foundations (like Mozilla) have direct products anyway? Why not a certification? Who should the users be and why? Who are the collaborators and competitors? These are hard questions.
At least with free software licenses we can separate the copyrights from the trademarks, and exercise the right to fork if a trademark owner is captured and misbehaves.
For IL residents the policy requires collection and retention of your biomarkers. Presumably there is a law enforcement exclusion implicitly or explicitly, eg search via administrative warrant.
I liked that you picked a service that has a relatively low barrier to entry. The real asset are local
operators and referrals. Making them more efficient without being controlled by a big company would be a boon for everyone involved.
Consider being a platform coop with regional operators as members. See https://platform.coop/
Yes, the barrier here is the desire to study and pass the exam. If willing, you are up and running relatively quickly - but only as a technician under someone else's operating license. To get the operator license (eg to be a full on pest control company) requires 2+ year documented experience and another set of exams.
The operating license holder is also on the hook for legal action if (when) things go wrong.
"Control" is interesting and I have found in all trades that people value their freedom. The good companies don't monitor employees too tightly, and are rewarded with loyalty and longer tenures generally. Of course you have to run a good recruitment and referral process to find the good people!
I’ve never heard of platform Co-ops. Cool! Lots of people predicted that a beloved local coffee shop was doomed to fail when the workers got a loan and bought it to run as a completely flat cooperative. It’s been a few years and they are absolutely killing it. I’d love to see the tech version of that.
I agree a lightweight franchise would be attractive, though I don't like most franchising options due to the fees and lack of equity build up for the operator.
Some franchising platforms (window cleaning is a good example) don't offer much beyond sales and marketing support and some nicely designed uniforms. There's not much to window cleaning other than basic equipment, so a person's route can easily be disrupted by a new entrant who doesn't have the franchise rake to contend with.
There's a model between employment, ownership and franchising that will probably emerge as sales, marketing, ops gets easier technically.
The business model is simple: Sell nice hardware at a premium, then sponsor and upstream improvements to OpenWRT.
If the software is an important differentiator (arguably, it is for things like Ubiquiti, but clearly it is not for most consumer routers), then release the patches under the Business Source License with a 3-5 year sunset back to BSD / Apache / GPL.
Open to audits doesn't mean free software, it just means visible source. The business model for selling routers with auditable firmware is selling routers.
And the public doesn't have to audit it. The govt already audits/inspects/validates plenty of sensitive physical products, typically through 3rd party industry associations. You don't get to peek inside, but people signing NDAs do.
Even if this wasn't done, at the very least they must publish their software testing procedures, the way UL, ETL, and CSA require to certify devices for the US power grid. (https://www.komaspec.com/about-us/blog/ul-etl-csa-certificat...) They can also do black box testing.
But ideally they would actually inspect the software to ensure its design is correct. Otherwise vibe-coded apps with swiss cheese code will be running critical infrastructure and nobody will know until it's too late.
There's also Turris from cz.nic [1]. Technically they use a fork of OpenWRT with some convenience features like auto-updates, although it looks like you can run OpenWRT on (some of their routers?) if you wanted to [2].
There's a whole interesting physiology behind learned helplessness (of which this is a minor variation).
In its defense, there's some practicality to it; we wouldn't say that a "get out of debt" plan that involved spending all available money on lottery tickets is worthwhile because "its not gonna happen". But defeatism is just a shortcut to say "I don't want to talk/think about it" in many cases.
And in this one, if the US Gov't required that all routers purchased by any agency they could influence had the ability to run open source code it would certainly shake up the market.
Why? You'd need to get someone electorally useful involved. That, unfortunately, elimiates a lot of the nihilistic, holier-than-thou tech types. But that's pretty doable nowadays. You just need an electorally-relevant group of people on your side.
Open firmware for your own devices is commercially viable. That is why hardware vendors create FOSS drivers. not all do, but it is a viable business model.
I'm no fan of imaginary property, but you're going to have to lay out your reasoning here. Firmware security is such crap precisely because most hardware manufacturers see it as nothing but a cost center they wish they could avoid.
The difficulty of installing OpenWRT or Linux in general on hardware comes from that hardware not being documented, or not having straightforward APIs like BIOS/EFI.
Or for some devices, community distributions that dubiously remix manufacturer-supplied binaries are available. But we generally see that as soon as the manufacturer stops their updates, the community versions start lagging behind as well.
What are you referring to? Would you not say there is a difference between OpenWRT having to make a list of supported whole systems, whereas an amd64 Linux distribution making a list of chipsets? I can go buy an off the shelf laptop, stick a generic "Linux install" USB in it, and be reasonably certain most things are going to work. Whereas OpenWrt I have to look at their list of supported machines, and buy exactly that one, even down to the hardware rev. Some of this is due to embedded constraints, but a good chunk is also due to the lack of hardware discoverability.
>> community distributions that dubiously remix manufacturer-supplied binaries are available
> The reason OpenWrt abandoned most routers was
I didn't mean things like OpenWrt, which I'd say is a general Linux distribution that does contortions to fit on specific devices. Rather I was talking about things like Valetudo which are closer to rooting the stock distribution with some tweaks, or the countless "custom ROMs" you see (saw?) in the phone world which are effectively remixing the manufacturer images. I thought DD-WRT was in that camp, especially for many devices (eg where do these "older kernels" come from?), but I'm hazy on that.
(personally I gave on up OpenWrt some 10 years back, and just use generic Linux (NixOS) on amd64. A VM on my server for the router, and lower-power amd64 boards for the additional APs (most of which double as Kodi terminals))
> I can go buy an off the shelf laptop, stick a generic "Linux install" USB in it, and be reasonably certain most things are going to work
Oh, God, I have to repeat it again.
That's because of x86 standards for APICs, keyboard controllers, USB controllers, framebuffer addresses, PnP buses, storage controllers, etc. It has nothing to do with the BIOS, and has even less to do with UEFI, since it removed standard BIOS real mode interrupts (UEFI CSM).
ARM's only standard is CPU instructions. Each chip has different peripherals and each one needs a different driver. ARMv7 didn't even have a standardized timer! How can you expect to run anything without knowing where's the timer? UEFI and ACPI tries to patch it up with software, but the device tree is a better alternative because it can be updated, bug fixed and extended by the end users.
Let me give you a real example, something I did last week:
I have a Radxa Rock 5 ITX. The M.2 E-key slot has PCIe lines but no separate line for eSATA (the E-key doesn't have those). But the CPU has a mux that can switch those PCIe lines into SATA lines. It's in the device tree. Radxa makes a passive SATA adapter for the E-key slot (I bought it), but it doesn't switch the mux by itself.
Rockchip uses device tree. The mux is in there. Radxa didn't write an overlay for the device tree to switch the mux into SATA mode. I wrote that myself. It's a simple PCIe status="disabled" / SATA status="okay".
If Rockchip used UEFI instead of device tree, there would be absolutely nothing I could do if Radxa didn't explicitly add a setting for this mode change. And if they didn't write an overlay as simple as that, I very much doubt they would implement in UEFI.
I couldn't make sense of the second portion of your reply. What are you saying? That is preferable to be able to update a crap OEM distro instead of completely replacing it with something that is derived from mainline Linux kernel and ordinary Linux userspace?
OpenWrt only does "contortions" because routers have various ethernet and wifi configurations. Some have an oboard switch, some don't, some have WAN / LAN ethernet ports, some only have WAN and wifi. They're going very much towards standardization, not "contortions".
DD-WRT doesn't take anything from the original firmware, well... maybe some blobs. AFAIK (I didn't use it much), the old kernels are official Linux kernels. They're just older versions that still work with drivers and blobs that were abandoned and no longer updated by the OEM.
The referenced policy says "We will unleash the private sector by creating incentives to identify and disrupt adversary networks and scale our national capabilities."
It can. Go to the code tab, choose your repo, and have it write an image file to disk. If you tell it to read it, it should show in the chat. It works on the web version so hopefully it works on ios.
The Free Software Foundation sometimes went further than the Apache Foundation with their About dialog or textual notices for end users, so they would learn about their affirmative rights. The purpose of this "prominent but reasonable" preservation requirement is to retain this end user advocacy. Specifically, the GPL copyright contains a prologue which the FSF wished to broadly distribute. This badgeware stuff is a decade old abuse of this end user advocacy strategy.
An otherwise permissive license with a prominent but symmetric end user notification might be a helpful addition to OSI license options, but care is needed so it is compatible with GPLv3, reasonable to textual or embedded environments, and precludes stupid badgeware nonsense. Standard approaches and bill of materials could improve the state of the art.
reply