[HN Gopher] When should we require that firmware be free?
___________________________________________________________________
When should we require that firmware be free?
Author : AndrewDucker
Score : 105 points
Date : 2024-12-17 09:49 UTC (13 hours ago)
(HTM) web link (mjg59.dreamwidth.org)
(TXT) w3m dump (mjg59.dreamwidth.org)
| palata wrote:
| I think it's a very interesting question!
|
| Sometimes it feels like it makes sense to keep _some_ software
| proprietary (e.g. the algorithms running in a Garmin watch have a
| lot of value, customers don 't just buy the hardware).
|
| Other times it feels like it really doesn't. I often give the
| example of Marshall smart speakers: the software seems to be very
| bad, it's never updated but it's connected to the internet, and
| the UX is not pleasing me. But initially I bought it for the
| hardware: it looks nice, and the sound is nice.
|
| In my opinion, when I buy hardware as a customer, I should have
| the right (and be given the tools) to interface with that
| hardware. So there should be _some_ open source firmware that
| gives me _reasonable_ access to the hardware I bought. In other
| words I should be able, legally and without impossible reverse
| engineering, to write my own system for hardware I buy.
|
| If I managed to write software that competed with Garmin on their
| own watches, so be it. That's fair competition (and that's
| probably super hard to do). The fact that Marshall can push me
| towards throwing away my perfectly fine hardware because they
| abandoned the bad software they once pushed on it is not fine.
| And it encourages companies to invent subscription models where
| my perfectly fine hardware becomes unusable if I stop paying them
| even though I don't want or need their updates.
|
| So somehow I think there is a middle ground that would help
| making products better and hardware more sustainable, and we are
| not there yet.
| stego-tech wrote:
| This is the same sort of middle-ground I increasingly find
| myself advocating for, with one caveat: once something is no
| longer being manufactured (hardware) or sold and supported
| (software), it should be entirely open sourced by law. After
| all, why shouldn't (as a random example) the iPhone 4 be FOSS
| hardware and software in 2024? It's perfectly usable if a bit
| sluggish by modern standards, could reduce eWaste (albeit by a
| small amount), and gives customers control over what they
| purchase. There's also the additional disincentive to companies
| in the yearly release cadence or ending support too early just
| to drive sales.
|
| I look back at the mounds of perfectly functional hardware
| amassed over my life, hobbled or bricked solely by software a
| vendor refuses to fix or otherwise allow end users to repair
| themselves. A Wii U with bad flash, an Xbox with a corrupted
| bootloader, a smart TV with a bad OS that crashes the display,
| a universal remote no longer supported by its manufacturer with
| new codes or firmware. All of these should've been unshackled
| the moment their manufacturers abandoned them, so that their
| owners can fix and support them indefinitely if they so choose.
| hansvm wrote:
| My initial counterargument was going to bring up that Garmin
| example GP added, since largely the same valuable code is
| likely shared across many devices.
|
| Reflecting further though, the harm of a manufacturer
| crippling a physical device does seem worth guarding against
| regardless, and if the code is really that valuable then such
| a law might encourage longer support lifetimes (or, at the
| very least, not crippling a perfectly good piece of
| hardware).
| juicypt wrote:
| I think there's a reasonable middle ground here. I would
| think it's fine for them to keep their algorithms closed-
| source, but be required to opensource the minimum amount of
| firmware to allow access to all of the hardware:
| bootloader, CPU, storage, memory, display, and sensors.
|
| No need to reveal any trade secrets at all. The above stuff
| is not the secret sauce that makes people buy their watches
| anyway: they use some of the most basic hardware in the
| market at their price point.
| palata wrote:
| This is exactly what I meant. I don't want Garmin to give
| me access to their algorithms. I want to have a way to
| flash a minimal system on it if I want to play with it.
|
| For something like Marshall smart speakers, it may end up
| making those products actually good: I could totally
| imagine an open source system for smart speakers. And
| that would be infinitely better than the crap Marshall
| put on the one I own.
|
| It works well for routers: on many routers you can
| install openwrt or opnsense.
| kube-system wrote:
| > once something is no longer being manufactured (hardware)
| or sold and supported (software), it should be entirely open
| sourced by law.
|
| There are a lot of practical barriers to this being that
| simple. A couple of common examples:
|
| 1. Third-party dependencies are a thing. Many pieces of
| hardware or software contain pieces of other hardware and
| software from other organizations, and the end vendor may
| frequently _not even have the right themselves_ to open
| source them.
|
| 2. Many products are abandoned when businesses fail, in which
| case, there may be no staff to open-source them.
| AnthonyMouse wrote:
| > Third-party dependencies are a thing. Many pieces of
| hardware or software contain pieces of other hardware and
| software from other organizations, and the end vendor may
| frequently _not even have the right themselves_ to open
| source them.
|
| That wouldn't be an issue if it was a legal requirement
| because then they would all be subject to the same rule or
| be unable to market their software because it doesn't
| satisfy the requirement.
|
| > Many products are abandoned when businesses fail, in
| which case, there may be no staff to open-source them.
|
| Which is why they should be open source to begin with. But
| what excuse does this provide to the companies that still
| exist?
| kube-system wrote:
| > That wouldn't be an issue if it was a legal requirement
| because then they would all be subject to the same rule
|
| Just because a product is discontinued doesn't mean every
| component inside of it is also discontinued. Nor does it
| mean the restrictions on those are based in copyright.
| They may be restricted by _other_ legal mechanisms other
| than copyright.
|
| > or be unable to market their software because it
| doesn't satisfy the requirement.
|
| > Which is why they should be open source to begin with.
|
| If you want to propose making closed source hardware or
| software illegal, just propose that.
|
| What you're effectively arguing for here, is that people
| own the rights to everything in their entire development
| stack, which is pretty unreasonable for any modern
| commercial software/hardware development. Even many
| prominent and celebrated open source hardware projects
| would not comply with this. For example: every open-
| source phone project. Not a single one could even
| possibly comply with this law because open-source
| baseband firmware does not exist, and cannot exist due to
| spectrum licensing requirements.
| AnthonyMouse wrote:
| > Just because a product is discontinued doesn't mean
| every component inside of it is also discontinued.
|
| You're assuming the code doesn't have to be released as
| long as there exists something using it that isn't
| discontinued, but it can be the other way. As soon as you
| discontinue something, everything in it has to be
| released.
|
| > Nor does it mean the restrictions on those are based in
| copyright. They may be restricted by _other_ legal
| mechanisms other than copyright.
|
| The proposal is a consumer protection law that requires
| source code to be published when a product goes out of
| support. If the law requires it to be released, you
| release it or you're in violation of the law.
|
| > If you want to propose making closed source hardware or
| software illegal, just propose that.
|
| https://news.ycombinator.com/item?id=42443042
| kube-system wrote:
| > You're assuming the code doesn't have to be released as
| long as there exists something using it that isn't
| discontinued, but it can be the other way. As soon as you
| discontinue something, everything in it has to be
| released.
|
| No, I'm interpreting this the way you're suggesting. And
| I'm saying it's _insane_. If company A sells a component
| to company B, and uses it in their product, and company B
| stops supporting it or goes out of business, now it needs
| to be open sourced? Every vendor has customers that have
| gone out of business or discontinued a product, so this
| is effectively a ban of all B2B closed source hardware or
| software components.
|
| > If the law requires it to be released, you release it
| or you're in violation of the law.
|
| So, to comply with your proposed law, companies can no
| longer sign NDAs with their vendors. They can no longer
| license patented hardware or software. They can no longer
| create products which have components with source
| restricted by trade law or product regulatory law. They
| can no longer license any closed-source hardware or
| software from any vendor. Do you realize this is a ban on
| approximately all commercially available computers, and a
| ban on many types of radio devices, including cellphones?
|
| > https://news.ycombinator.com/item?id=42443042
|
| That's a lot more reasonable argument, although it is
| unprecedented and unfounded. Copyright doesn't require
| any other authors of other works to release any
| foundational sources, and it never has. Authors don't
| have to release drafts or outlines of their books.
| Musicians don't have to release the constituent tracks of
| their final recordings. Artists and photographers don't
| have to release their PSD files. Patent protection works
| this way, but copyright never has.
| AnthonyMouse wrote:
| > Every vendor has customers that have gone out of
| business or discontinued a product, so this is
| effectively a ban of all B2B closed source hardware or
| software components.
|
| Not exactly. If you don't have to release it until
| support ends then you could require the licensee to
| provide support for a specific number of years and carry
| bankruptcy insurance that would pay for support to
| continue for that period of time, if you wanted to.
|
| It would tend to cause the source code to be released
| after ten or twenty years, but what are you really
| protecting at that point? The source code for Windows XP
| and 3G cellular radios?
|
| > Do you realize this is a ban on approximately all
| commercially available computers, and a ban on many types
| of radio devices, including cellphones?
|
| It seems pretty likely that the vendors would choose to
| license the code under terms that would allow the source
| code to be published in that circumstance, since
| otherwise they have no customers.
|
| > Copyright doesn't require any other authors of other
| works to release any foundational sources, and it never
| has.
|
| Other media is distributed in a human-readable form
| rather than compiled into an opaque binary. If you want
| to make a derivative of Alice in Wonderland you can
| easily do it from a copy of the book as published without
| needing any of Lewis Carroll's notes. If you want to fix
| a firmware bug, doing it without the source code is
| commonly infeasible.
| kube-system wrote:
| > bankruptcy insurance that would pay for support to
| continue
|
| 1. That isn't a thing
|
| 2. If your company doesn't exist, it doesn't really
| matter if you comply with the law anymore.
|
| 3. Insurance writes checks, it doesn't conduct business
| operations
|
| > It seems pretty likely that the vendors would choose to
| license the code under terms that would allow the source
| code to be published in that circumstance, since
| otherwise they have no customers.
|
| Except for all of the hardware and software that already
| exists, all of the patents that already exist, all of the
| different laws for hardware and software in every other
| country where closed-source software/hardware exists, and
| all of the laws here and everywhere else that restrict
| hardware or software for other reasons. I think it is
| much more likely that companies will comply with all of
| the rest of the operational and legal obligations they
| currently have, and instead, avoid legal nexus in your
| jurisdiction.
|
| > 3G cellular radios?
|
| It's not legal to open source a baseband radio in many
| countries because of the licensing requirements to use
| the spectrum. If you make this a requirement, and
| companies want to sell cellphones in other countries
| (they do) you have banned the manufacture of these
| devices in your country.
|
| > It seems pretty likely that the vendors would choose to
| license the code under terms that would allow the source
| code to be published in that circumstance, since
| otherwise they have no customers.
|
| It's more likely they will conduct operations outside of
| your jurisdiction, and continue their business as they
| currently do.
|
| > Other media is distributed in a human-readable form
| rather than compiled into an opaque binary.
|
| You don't "read" a piece of software the same way you
| don't "read" a song on the radio. Software runs on a
| computer, and songs play on a radio.
|
| But even if we do interpret this your way -- copyright
| doesn't require _anything at all_ to be published. You
| can create something, put it in a locked safe, and
| copyright still applies. You can 't create a derivative
| work of my nudes on my phone, because I won't give them
| to you. They're still protected by copyright, though.
|
| Your presumption that it is predicated on sharing is
| simply not factually correct. Copyright is and has only
| ever been about protecting creators rights. _Only patent
| law_ is predicated on sharing.
| seba_dos1 wrote:
| > It's not legal to open source a baseband radio in many
| countries because of the licensing requirements to use
| the spectrum.
|
| If anything, it may not be legal to operate modified
| firmware/hardware on public networks. It's perfectly fine
| to open source this stuff, and you can operate it in a
| lab given that you don't transmit anything outside of it.
| kube-system wrote:
| But the _certification_ of baseband radios in multiple
| countries requires the devices to be restricted to
| operating within the parameters permitted under the
| regulatory requirements for the use of spectrum in those
| respective countries. These parameters are enforced in
| the firmware on the device. The manufacturer has to
| ensure that the device complies in order to obtain
| certification for use in a consumer product, and they do
| this by locking the firmware.
|
| If it's unlock-able, it may be perfectly legal as an
| uncertified device for use in a lab environment, but it
| isn't as a consumer device.
| numpad0 wrote:
| So you make a laptop, sell it, discontinue it, now
| Microsoft is legally required to open source Windows 12.
| That makes sense, right?
| Aurornis wrote:
| > If I managed to write software that competed with Garmin on
| their own watches, so be it. That's fair competition
|
| I worked on a line of products that allowed user modifications
| of the software. We didn't explicitly endorse it, but we also
| had instructions on the website for how to get into the
| hardware and we designed it so users could modify things and
| persist their changes.
|
| It was fun to see what people did with the hardware, but the
| volume of support requests was also out of control after a
| while.
|
| Companies wouldn't actually care if you created alternate
| software for something like a watch if there was no downside to
| them. It would sell more hardware to people who wanted to
| customize.
|
| The problem comes later, when many people casually modify their
| devices and then expect original customer service to get it
| back to the original state. You can try to place rules on
| customer support, but customers will lie through their teeth to
| customer support if they think it will get them what they want.
| We would get people demanding RMA replacements because their
| device "mysteriously" stopped working, then when engineering
| did random sampling of RMAs we would find that they had
| modified the software and didn't know they could hard reset it.
|
| It's a real problem. HN imagines the average person who
| modifies hardware to be highly knowledgeable and self
| sufficient. In the real world it's usually someone following an
| outdated guide online where they copy and paste different
| commands until something works. Those same people are the first
| to try to return the product or request customer support when
| it doesn't work perfectly.
|
| Prusa (IIRC) had an interesting solution where you had to break
| off a physical piece to void your warranty in order to try
| different firmware. People were up in arms about it, but I
| think it was the smartest way to handle this conundrum.
| brk wrote:
| This is very accurate. Most of the time the motivation behind
| restrictions and not releasing code is rooted in support
| costs. People can and will break things inadvertently, but
| they won't like that and will then go the route of requesting
| support, RMAs, etc. Additionally in some cases those people
| that developed random customizations will release them, and
| now other users will install or use them, and if an issue
| crops up, the support costs are now exponentially worse.
| AnthonyMouse wrote:
| > the support costs are now exponentially worse.
|
| Is there any evidence that this actually happens? The
| percentage of customers who install custom firmware would
| be low to begin with, much less the percentage of those who
| then have problems with it and try to get the company to
| support it instead of the community that developed it. The
| idea that this type of support request is going to dominate
| support costs seems pretty farfetched.
| Zak wrote:
| > _Prusa (IIRC) had an interesting solution where you had to
| break off a physical piece to void your warranty in order to
| try different firmware._
|
| I'm not sure this would hold up to a legal challenge in the
| USA. "Warranty void if removed" stickers are illegal, for
| example: https://www.ftc.gov/news-events/news/press-
| releases/2024/07/...
| AnthonyMouse wrote:
| > The problem comes later, when many people casually modify
| their devices and then expect original customer service to
| get it back to the original state.
|
| So design the hardware to make that (i.e. factory reset) easy
| and have the customer try it before any RMA.
|
| > Prusa (IIRC) had an interesting solution where you had to
| break off a physical piece to void your warranty in order to
| try different firmware. People were up in arms about it, but
| I think it was the smartest way to handle this conundrum.
|
| Sort of. What the customer is reasonably going to want is to
| have a separate warranty for the hardware and the software
| and void the software warranty. If someone replaces their
| firmware to fix a software bug and then their screen
| independently develops bad pixels, the customer is rightfully
| going to be upset that the company is using it as an excuse
| to deny a warranty replacement of their faulty hardware.
|
| This is also how you get customers lying to you about
| replacing the firmware. If you try to deny unrelated warranty
| claims over that they feel like they're being ripped off.
|
| But if the alternatives are "warranty void if firmware
| replaced" and "closed firmware" the first one is clearly
| better.
| joshuaissac wrote:
| One approach might be to see if the software can be replaced
| with an open-source alternative that allows an equivalent level
| of access to the hardware functionality, with official support
| for performing such a replacement (though not necessarily for
| the replacement software itself). If so, then the manufacturer
| need not provide the source code. Whereas if there is no
| supported way of replacing the software with an open-source
| alternative, then compel the manufacturer to make the software
| available.
|
| Under this system, Garmin could keep their software closed-
| source as long as they provide a way to replace the firmware
| and software with an open-source alternative that can use all
| of the hardware features, while not necessarily having the
| software features.
| palata wrote:
| Yes, that's exactly what I meant!
|
| Also I don't really care about having the source code of the
| firmware if I have an API to access it. If I own Qualcomm
| hardware, I should not need a damn NDA to flash something on
| it.
| AnthonyMouse wrote:
| > Sometimes it feels like it makes sense to keep some software
| proprietary (e.g. the algorithms running in a Garmin watch have
| a lot of value, customers don't just buy the hardware).
|
| The trouble with this is that it doesn't really work. A normal
| user of the watch is probably not going to reverse engineer the
| binary but a competitor will, so concealing the source code is
| hurting the customers more than the competition.
|
| Not only that, it hurts _you_ more than it hurts competitors.
| If you publish the source code then customers make improvements
| to it and fix bugs. But it 's still firmware, i.e. specific to
| the device, so you get the benefit of that rather than
| competitors. Customers contribute fixes so you need fewer
| developers yourself or your developers can spend more time
| adding features that make sales.
| necovek wrote:
| Any larger competitor would surely discourage disassembling a
| competitor's code because mere exposure to it might make you
| liable to lawsuits if you develop similar features (and you
| can't trust that the fact you did it won't leak out).
| kuschku wrote:
| > the algorithms running in a Garmin watch have a lot of value,
| customers don't just buy the hardware
|
| Algorithms are not subject to copyright. The law has already
| made a decision on this.
| jazzyjackson wrote:
| Good reason to keep them a secret then
| bombcar wrote:
| You can remove some of that by making the "open platform"
| happen after a certain date (e.g, when the warranty has already
| expired).
| axus wrote:
| Manufacturers should not be mandated to spend extra money to
| support our hacking, but spending money/effort/lawyers to
| prevent that hacking could be prohibited.
| jmclnx wrote:
| IMO, If you buy hardware, you should get firmware src too allow
| porting to whatever OS you want to run
| Cumpiler69 wrote:
| If you buy SW should you also get the source code to port it to
| the HW you want or to make mods for it?
| ongy wrote:
| Yes.
| DowsingSpoon wrote:
| Obviously, if we'd like to require programmers to release
| software in source code form then we're going to need some
| rules. If programmers are made to release software in some
| source code form then what languages should we require?
| Clearly, Brainfuck is out of the question, for example.
| Though, it would do no good to legislate the programming
| community into a religious war over FP or OOP. My proposal,
| however modest, is that the law require software be
| released in some kind of well-specified, portable language.
| Something succinct and powerful. Something symbolic,
| abstract, and much higher-level than the underlying
| hardware. Hm. How about x86_64 machine code?
| bryanlarsen wrote:
| That's generally handled with a "preferred form" clause
| -- it must be released in the form it was written in. If
| you originally wrote the firmware in Brainfuck, it's fine
| to release in Brainfuck. But you can't transpile to
| Brainfuck and release that.
| j16sdiz wrote:
| > Clearly, Brainfuck is out of the question, for example.
|
| Ugh? Are you trying to make selling software written in
| brianfuck illegal?
|
| > portable language
|
| So all assembly bootstrap code are outlawed?
| ongy wrote:
| While this looks hard, the FSF has long ago provided us
| with a solution.
|
| The preferred form to make modifications on.
| AnthonyMouse wrote:
| There is a pretty good argument that this should be
| required for copyright protection. The point of copyright
| is supposed to be to ultimately get works for the public
| domain, when the copyright expires. If the source code has
| never been released then it's failing at its purpose. Once
| a work is in the public domain the public is supposed to be
| able to make derivatives etc. So to have copyright
| protection for software you should have to release the
| source code.
| jandrese wrote:
| A noble idea, but it should be pointed out that of all of
| the software ever written on planet Earth, only Ada
| Lovelace's somewhat notional code for a non-existent
| machine would be in the public domain in the year 2024.
| The earliest you would expect to see "modern" code
| entering the public domain is sometime in the 2060s, and
| that would be written in Plankalkul.
| close04 wrote:
| Not sure if we can go that far but I'd be happy is the
| manufacturers would be forced to put on the label how many
| years they'll support the product and at what level.
|
| And perhaps when the product is fully out of support, all the
| related resources should be published so it can be repaired and
| supported further on a best effort basis by the community now
| that the manufacturer no longer loses any money on it.
| _blk wrote:
| IMHO, optimally there should be no force (regulation)
| necessary at all. It'd be much more beneficial if
| manufacturers saw the benefits because consumers choose
| according to the benefits they see. Sometimes we have to ask
| to make a need known - esp. if we're willing to pay a premium
| for it. So I see the ball in our park. If there's demand but
| no supply, we found a niche.
| drdaeman wrote:
| If a vendor wants their software proprietary and secret, I can
| respect that and would be perfectly fine with full hardware
| schematics and documentation. Since that's something I
| physically own anyway.
|
| In the ancient times, providing schematics (and even repair
| manuals) for things like TVs or cars was the norm. Obviously,
| that's not happening, but as a fantasy wish - I would love to
| see this becoming a thing again.
| mschuster91 wrote:
| From the comments:
|
| > My primary use of non-free firmware is to stop free riding by
| hardware cloners. It really sucks to put a lot of effort into a
| hardware and software design, then have your product get cloned
| using your own firmware.
|
| That's a massive problem indeed. In ham circles, the tinySA
| spectrum analyzer is one prime example... there's tons of clones
| of them floating around despite the hardware actually being
| closed source, but the firmware being FOSS. And people turn up in
| ham forums asking why their "tinySA" doesn't work, only to find
| out they have been shipped counterfeits with sub-par components.
| immibis wrote:
| Trademark law is for that. They can clone the product but they
| can't call it tinySA.
| flyingcircus3 wrote:
| Perhaps that would prevent people from selling clones as if
| they were authentic, but the stated problem is that clones
| are undercutting the original creators devices. Changing the
| name puts an increased burden on the cloners to get their
| name out there, but in a hobbyist market surrounding a
| technical subject, that seems pretty small compared to the
| burden of developing hw/fw that users are willing to pay for.
| mschuster91 wrote:
| Good luck enforcing that against dropshippers and in China.
| Even the largest brands on this rock struggle with IP theft,
| fakes and trademark abuse.
| AnthonyMouse wrote:
| But that was the original problem. People bought the device
| thinking it was authentic when it wasn't. If they're still
| selling crap with your name on it then how does it help you
| that it's subpar hardware running subpar firmware instead
| of subpar hardware running better firmware?
| rollcat wrote:
| > When should we require that firmware be free?
|
| Same as with any other requirement: _when you can afford it_.
|
| Slack's desktop client shouldn't require Electron (making it
| unusable on low-end devices), but it does. They can get away with
| that requirement, because there's hardly any alternative client
| worth your effort/attention.
|
| I was sceptical about BitWarden (versus 1Password), because their
| UX was quite far behind - but they're slowly catching up, and I
| might have to reconsider my choice there.
|
| If I wasn't "required" to run a dozen different proprietary/non-
| portable apps, I'd be using OpenBSD instead of macOS.
|
| I do not "require" X to be free, but given all other things being
| equal, it's my preferred choice. Unfortunately, a lot of the
| time, we do not have the luxury of being picky.
| 2OEH8eoCRo0 wrote:
| For the amount that these services cost, where the fuck is my
| native desktop client? I don't want electron and I don't want
| to use a web browser.
|
| They're phoning it in with this trash because there isn't
| competition. They want to make their own lives easier rather
| than the customer's.
| bigstrat2003 wrote:
| > They want to make their own lives easier rather than the
| customer's.
|
| This right here is the crux of the matter and why I have no
| sympathy for the defenses of Electron. I don't care at all
| how easy it is for the company's developers to make
| something. I care that the software I get is high quality,
| and I'm not willing to sacrifice that so that the company can
| cut corners on their costs.
| rrr_oh_man wrote:
| You are clearly not a manager
|
| (That is not an insult)
| rendaw wrote:
| There's no alternative client worth attention because Slack
| makes it against the TOS and threatens to ban you if you use an
| alternative client, right?
| m463 wrote:
| Your examples are not firmware, and they do not pertain to
| physical devices.
|
| "require" means something different in the hardware context,
| and other concepts come into play.
| lcfcjs6 wrote:
| Odd that you're examples have nothing to do with firmware.
| nelsoch wrote:
| free? definitely when partially(however minute) funded by
| taxpayers
| _blk wrote:
| Agreed but then it's not free. Someone already paid for it [we
| the people.]
| tremon wrote:
| There's a difference between production cost and sale price.
| The latter is the one being referred to by the GP. The
| article itself is about neither: it talks about software
| freedom, not monetary cost.
| Findecanor wrote:
| I think software and firmware should be free if critical
| functionality depends on an Internet-based service.
|
| Or, it should at least be free whenever that service gets
| discontinued.
|
| I've been thinking that perhaps to be able to market a product
| where critical functionality depends on commercial software
| connected services, a company should be required by law to
| provide their source code to a government agency that holds it in
| escrow. Then when the company goes out of business or just
| decides to discontinue the product then that agency will publish
| the source code under an open source license.
|
| This shouldn't just apply to firmware in connected devices, but
| to all commercial connected software. There are countless games
| that can't be played any more only because a company behind it
| has discontinued its DRM servers.
|
| Of course there are details that need to be worked out with how
| this will work in practice. The publisher will have to prove to
| some degree that the provided source code is sufficient. You'd
| have to prevent the publisher from circumventing the solution in
| a future software update. And the publisher would have to pay a
| free for the privilege, to be able to fund the agency.
| crazygringo wrote:
| I am sympathetic toward the idea. However:
|
| > _a company should be required by law to provide their source
| code to a government agency that holds it in escrow_
|
| The reality is that a lot of code can be licensed from third
| parties, and there's no moral principle by which it would be
| right to expose and open-source _their_ code.
|
| So I'm really not sure how workable or useful this would
| actually be.
| hoherd wrote:
| When the end of Spotify Car Thing was announced this is what
| I expected. I thought these perfectly good devices had been
| built on license encumbered libraries that would prohibit
| open sourcing the code, and that all those hardware devices
| would go to waste. Thankfully that was not the case, but most
| of the time it is. It's amazing how much licensing controls
| how software is used, and thus how much systems and software
| designers should consider the license of the libraries and
| frameworks they choose.
| sowbug wrote:
| Wouldn't the third parties be subject to the requirement as
| well?
| thfuran wrote:
| What if they're in a different jurisdiction?
| AnthonyMouse wrote:
| How does that apply when you're releasing the source code
| in the jurisdiction where the law requires it? If they
| sue you there, the law there says they lose. If you're
| also in the other jurisdiction your subsidiary there
| doesn't have to release it so they don't. This is like,
| what happens when a work is in the public domain in one
| jurisdiction but not another? The answer is different
| things happen in different places.
|
| Also, obviously companies would then just not license
| software under terms that would cause legal trouble for
| them.
| thfuran wrote:
| >How does that apply when you're releasing the source
| code in the jurisdiction where the law requires it?
|
| That would depend on what exactly the requirement is and
| what exactly the third-party code is and is used for.
| Without the specifics, I'd say it seems plausible that
| the third party itself is not subject to the requirement
| but the firmware using the third-party code may be
| subject for both first- and third-party code.
| stonemetal12 wrote:
| Either they follow the law or it is illegal to sell in
| the covered jurisdiction.
|
| There are already US laws that work in that way. Consider
| DDT, if fruit was grown with DDT you can't sell it in the
| US. It doesn't matter that DDT is legal in the grower's
| country.
| thfuran wrote:
| Taken as given the statement in the parent that "there's
| no moral principle by which it would be right to expose
| and open-source their code.", then that sort of
| transitive requirement ought not be imposed. Though I
| don't agree with that statement.
| giantrobot wrote:
| Identifying all of the owners of licensed code is a
| difficult problem all by itself. It's not always clear that
| third party code is even used in a product as any
| identification or licensing information is lost at compile-
| time. Some licensed code is only delivered as pre-compiled
| libraries so a licensee couldn't even comply with a law
| requiring all source code submitted for escrow.
| PittleyDunkin wrote:
| That's surely a detail for the producer to figure out.
| Don't sell software if it's not legal to sell!
| rrr_oh_man wrote:
| Easier said than done with deadlines, managers, and
| incentives
| throwaway494932 wrote:
| > The reality is that a lot of code can be licensed from
| third parties, and there's no moral principle by which it
| would be right to expose and open-source their code.
|
| This doesn't mean that they would have to expose somebody
| else's code, they would just have to use something else (or
| write their own)
| Zak wrote:
| This objection only applies to _past_ products. If the law in
| a big enough market required that sort of code escrow and
| eventual release, companies wouldn 't build future products
| covered by that law on top of code they couldn't release.
| bombcar wrote:
| You'd have to have some practical "ramp up" times, but
| anything that has been written can be written again.
|
| It could eventually result in the third-party libraries being
| fully replaced (good value) or them adapting so that they
| update their libraries yearly - sure you can get the 3 year
| old one open-source, but do you want to?
|
| id ran into this with the sound code for Doom, and Carmack
| regrets it (though I'm not sure they had many other practical
| options, they could have at least contracted for a
| distribution license which wouldn't need to be open source).
| rs999gti wrote:
| > I think software and firmware should be free if critical
| functionality depends on an Internet-based service.
|
| Anything that requires the effort or labor of another person
| should not be free regardless of criticality. Get a private or
| public entity to pay the providing person or group.
| Spivak wrote:
| That's fine, people deserve to be paid. Is it fine to be
| compelled to keep selling the service under the original
| terms as long as your customers still have your device?
|
| I mean we're talking about hardware that becomes trash the
| moment the servers stop working. I think there's a legitimate
| interest in keeping functional products out of landfills.
| Almondsetat wrote:
| Free as in freedom
| Zak wrote:
| Perhaps they should have the option of publishing any
| specifications, APIs, and keys necessary for a third party to
| build equivalent functionality rather than source code. This
| stuff usually isn't rocket science, but it's often locked
| behind some sort of DRM, or requires exponentially more time
| without simple docs.
| thfuran wrote:
| >There are countless games that can't be played any more only
| because a company behind it has discontinued its DRM servers.
|
| I want those companies (and especially connected device
| manufacturers in similar positions) to be liable for damages.
| It's basically destruction of property.
| jandrese wrote:
| Except software isn't property. You don't even own it. It's
| all some "limited license to execute the code on your own
| hardware", because the one thing software companies will
| never abide is the doctrine of first sale[1].
|
| [1] https://en.wikipedia.org/wiki/First-sale_doctrine
| mindslight wrote:
| > _The maximalist position is not to compromise at all - all
| software on a system, whether it 's running at boot or during
| runtime, and whether it's running on the primary CPU or any other
| component on the board, should be free._
|
| As stated, I don't think this actually makes for a consistent
| position. The author throws out the terms "system" and "board"
| and hopefully assumes they define a good boundary, but they
| actually don't. PCIe expansion cards and hard drives are both not
| "on the board" but still part of the "system". Peripherals and
| other support devices (keyboard/usb switch/UPS/serial server) are
| not "on the system" or perhaps not even part of "the system" at
| all, yet significantly [ae]ffect the system.
|
| Defining that bound is important, because without it you end up
| with a wishy-washy escape hatch like " _within which software
| installation is not intended after the user obtains the product_
| ", making the definition completely fail at being a maximalist
| position. (and then when taken as a maximalist/hardline position
| ends up causing strife...)
|
| The original FSF position was based on the copyright license
| status of what they shipped on distribution media. This is neatly
| consistent, but completely outmoded in today's globally networked
| software-pervasive environment. The spirit of this lives on in
| things like linux-libre.
|
| I'd say that any modern definition of software freedom _must_
| pull in a larger scope that focuses on effective individual
| freedom in the face of pervasive global networking. A mouse, a
| video card, and an IoT device can all have proprietary updateable
| firmware, but _drastically_ different affects on your individual
| freedom - I 've never wanted to change my mouse firmware, if/when
| video card firmware is updated is (almost) completely under your
| control and the card lacks easy backhaul, whereas a a proprietary
| IoT device is essentially a rogue agent on your network.
|
| My own definition involves something like a much more fine-
| grained definition of _device_ , analyzing how easy it is to
| modify/inspect code on each _device_ , as well as analyzing
| trust/security relationships between devices. This ends up being
| independent from maximalism, as you can choose how important it
| is for any given device to be libre or not, and see how any
| compromise specifically affects your freedom.
|
| For example I recognize that my hard drives themselves are
| completely and utterly non-free. But also my desire for libre
| hard drives is pretty low as well. The libre device/system those
| drives store data for protects itself by the use of full disk
| encryption, and the drives are unlikely to become active
| attackers due to lacking any network connections besides SATA/SAS
| to the libre system. Meanwhile the system they're attached to is
| a KGPE-D16 running libreboot, which has nearly zero proprietary
| code running in its main CPU domain. I compromise on CPU
| microcode because the small binary size means low complexity, I
| choose if/when to update, and it's similar trust to the
| unavoidable shipped silicon. But no javascript (I run web
| browsing on another machine with virt-viewer =). I'd say this is
| a much healthier way of analyzing software freedom, whereas the
| traditional way kind of lumps many things together and then finds
| reasons to ignore inconvenient details.
| necovek wrote:
| Modern drives are directly connected to the PCIe bus (over
| NVMe) and even have DMA access IIRC, which potentially enables
| them to do much more than just store bits of data.
|
| FWIW, even external drives connected through TB have similar
| level of access.
| mindslight wrote:
| That's a great point - modern drives are actual PCIe devices
| themselves, not the more restricted SATA protocol.
|
| The librebooted machine that I was talking about has a
| properly situated IOMMU that should protect it against rogue
| PCIe devices (otherwise this same point applies to things
| like network card firmware). But it's important to keep in
| mind that many motherboards do not.
| sowbug wrote:
| As a purchaser of hardware, I want full control over the stuff I
| own, including the right to modify firmware. But I'm also
| sympathetic to hardware manufacturers, especially in this day and
| age where information travels so fast.
|
| A hardware company can say your warranty is void if you modify
| your purchase's firmware. But it can't stop you from flashing
| back the original firmware, saying it was broken when you
| received it, and still making a bogus warranty claim. Nor can it
| stop you from writing a terrible Amazon review about how
| complicated the product is, when all your complaints are self-
| inflicted from modified firmware you found online that the
| company didn't even write.
|
| Companies are responsible for the entire relationship between
| their products and their customers. So I can see why they want to
| define hard boundaries around it.
| boredatoms wrote:
| The percentage of people motivated to be modifying firmware
| would be vanishingly small. It wouldn't meaningfully impact
| return rates
| oliwarner wrote:
| I get why they want control over this stuff (simplification,
| segmentation and obsolescence) but the very second they lose
| interest, stop supporting it, _owners of the hardware_ should
| have access and a licence to the source and build instructions.
|
| Not even necessarily open source. Just something better than
| automatic ewaste.
| vollmond wrote:
| How do you reliably (eg legally-definable) differentiate
| between "stopped supporting" and "haven't released an update in
| a while because it works fine and there are no major bugs"?
| tremon wrote:
| When the manufacturer no longer offers at-cost repairs and/or
| support.
| samatman wrote:
| No one should be under an obligation to offer services at
| cost. It's not even a meaningful concept: if I say the cost
| of an hour of my time is $N dollars, well, then it is.
| oliwarner wrote:
| An obligation isn't the suggestion. The suggestion is
| giving manufacturers the choice between supporting or
| letting people support themselves.
| XorNot wrote:
| You don't: firmware should always be available. I have too
| many repairable devices which are actually dead because I
| can't replace a blown microcontroller since the firmware
| isn't available.
| atoav wrote:
| On idea I have heard is that you have to pay $AMOUNT yearly
| to some registrar to be not subjected to that rule and with
| that payment you thereby agree to support the product for
| another year. Stopping to pay means you stop to support it
| and are therefore required to release the plans. Going
| bancrupt/out of business does the same.
| gpm wrote:
| When a consumer can point to a major bug or security
| vulnerability that the manufacturer has not fixed within a
| reasonable period of time.
|
| That said - I think the above proposal is "release it
| immediately for the eventuality where they stop supporting
| it", not "require it be released when they stop supporting
| it".
| chrisandchris wrote:
| I think even defining "major" here is going to be hard.
| E.g. a lot of CVSS are 8 to 10, because of the _impact_ and
| now the _exploitability_.
|
| So a very annoying bug that does not have any impact is
| major, or not major? Like my internet radio sometimes has
| connectivity issues. It resolves itself, but takes maybe
| 10-15s. After that, it works fine for a couple of hours of
| even a day. I wouldn't consider that major, because the
| product is usable in its intented way, it's just annoying.
| gpm wrote:
| I think the court system is generally capable of
| resolving whether or not a bug makes a product defective.
| Courts and the legal system are very experienced at
| dealing with ambiguity.
|
| Absent marketing to the contrary (prior to sale), I would
| consider a software defined radio that cuts out for
| 10-15s at a time defective. That out right breaks a lot
| of use cases. If that's a software (and not instead the
| result of something like damage to your particular unit)
| I would expect that to be fixed in a reasonable period of
| time for a product to be considered supported.
| jandrese wrote:
| When the manufacturer declares it 'EOL' and says they won't
| release any new patches, even for security vulnerabilities?
| sokoloff wrote:
| If I'm the manufacturer, what is my incentive to _declare_
| that, rather than to stay silent and still act in a way
| indistinguishable from that?
| jandrese wrote:
| The service contracts that state you will support the
| hardware until it reaches EOL.
| oliwarner wrote:
| Turning off the central servers is a big clue ;) Happened to
| me with a "Kodak" baby monitor. Stll-great hardware left with
| 10% function.
|
| I accept there is some murky middle-ground so maybe there
| shouldn't be a start limit. You buy the hardware, you assume
| the right to alter what it runs (but lose official support
| thereafter).
| devops99 wrote:
| Always, and by law.
| FuriouslyAdrift wrote:
| Firmware frequently includes NDAs and license agreements for
| patented intellectual property.
|
| Now, once those patents expire then sure... open it up
___________________________________________________________________
(page generated 2024-12-17 23:01 UTC)