[HN Gopher] Using FujiFilm SDK on a Camera Voids Its Warranty
       ___________________________________________________________________
        
       Using FujiFilm SDK on a Camera Voids Its Warranty
        
       Author : dennisvennink
       Score  : 104 points
       Date   : 2022-03-24 17:10 UTC (5 hours ago)
        
 (HTM) web link (fujifilm-x.com)
 (TXT) w3m dump (fujifilm-x.com)
        
       | Maursault wrote:
       | I, for one, can forgive FujiFilm... because, even though recently
       | finally discontinued, they gave us FujiChrome Velvia 100 (& 50).
        
       | themerone wrote:
       | This is illegal in the US due to the Magnuson-Moss Warranty Act.
       | 
       | They can only void the warrenty if they can prove that the damage
       | is the result of the SDK usage.
        
       | AlexandrB wrote:
       | > 5.2 YOU AGREE AND ACKNOWLEDGE THAT, ONCE A PRODUCT IS USED OR
       | CONTROLLED BY OR THROUGH THE DIGITAL IMAGING SYSTEM, SUCH PRODUCT
       | SHALL BE OUT OF SUCH MANUFACTURER-WARRANTY WITH RESPECT TO THE
       | PRODUCT AS SEPARATELY SPECIFIED BY FUJIFILM, FUJIFILM'S
       | AFFILIATES, OR THEIR BUSINESS PARTNERS.
       | 
       | Brutal. Consumer protections are lagging badly behind in the
       | software era. It's bad enough that commercial software has broad
       | disclaimers against ensuring any kind of functionality, but this
       | stuff is starting to creep into hardware too. I think right-to-
       | repair is a good start.
        
         | Manuel_D wrote:
         | I think it's totally valid to void warranty when customers
         | modify product software. If users do things like disable
         | temperature limits and mess up their camera, then I see no
         | reason why the company (and be extension, other customers)
         | should foot the bill.
         | 
         | Giving away the SDK, regardless of warranty revocation, is a
         | step ahead of most camera manufacturers.
        
           | hexo wrote:
           | No, it's not valid. At all. I think it is illegal in some
           | countries and should be illegal everywhere. It was enough of
           | these "practices".
        
             | Manuel_D wrote:
             | If I swap out my car's engine with a more powerful one and
             | screw up the drivetrain will warranty cover it? If I load
             | broken firmware onto my device that screws it up, why
             | should the company be on the hook? Replacing firmware is no
             | different than replacing any other component.
             | 
             | What countries force companies to provide warranty when
             | users load faulty firmware onto devices?
        
               | MrStonedOne wrote:
               | > If I swap out my car's engine with a more powerful one
               | 
               | yes, legally required to be covered in the us.
               | 
               | > and screw up the drivetrain will warranty cover it?
               | 
               | No, not legally required to be covered in the us.
               | 
               | The difference is the law specifies the manufacturer can
               | not assume a leads to b, they have to _a reason_ to think
               | b was caused by a.
        
               | UncleEntity wrote:
               | A more apt analogy would be the MVD plugged a dongle into
               | the canbus plug and now your warranty is void.
               | 
               | I mean, this is exactly what they are doing.
        
               | cge wrote:
               | That's not the problem. The problem here is that Fuji
               | appears to be claiming that _any_ use of the SDK voids
               | the warranty _entirely_ , regardless of the defect. t
               | would be like if you swapped out your car's engine with a
               | more powerful one, and then, from a completely unrelated
               | fault, its navigation system stops working.
               | 
               | In the US, my understanding is that this is explicitly
               | not legal, per the Magnuson-Moss Warranty Act. FujiFilm
               | can choose not to offer a warranty at all, but if they
               | offer one, then it must cover defects on modified devices
               | unless they can show that the modification caused or
               | contributed to the defect.
               | 
               | In the EU, it is my understanding that it is legal to
               | have a guarantee with terms like these. However,
               | regardless of any guarantee the manufacturer may offer,
               | there is a statutory guarantee in the EU for most
               | products, which completely ignores the terms that the
               | manufacturer might prefer. This _usually_ ends up being
               | weaker than Magnuson-Moss in terms of duration and
               | modifications. But it usually means that for six months,
               | the seller must prove that the fault with the product was
               | caused by the consumer, and for two years, if you can
               | show that the problem is from a defect with the device
               | originally and not from you, then you can still get
               | repairs, replacement, or a refund.
        
               | DannyBee wrote:
               | The short answer is: The warranty must cover damage not
               | caused by your modification.
               | 
               | There are no countries i'm aware of that require you
               | warranty damage caused by user modification. Lots of
               | countries require that you do not void the entire
               | warranty, or refuse service, of any damage _not_ caused
               | by the modification, and generally the manufacturer has
               | to show the damage was caused by the modification if they
               | want to refuse service.
               | 
               | In this case, Fuji is trying to void the _entire_
               | warranty. That is not legal in a lot of countries.
        
               | Zak wrote:
               | In the US, car manufacturers are required to honor the
               | warranty for the rest of the car after you swap the
               | engine _unless_ they can prove your engine swap caused
               | the failure they don 't want to repair. They will
               | probably have little difficulty proving that for a
               | scenario like a more powerful engine breaking a
               | transmission. They'd have a much harder time claiming it
               | caused the heated seats to stop working.
               | 
               | This SDK seems to be for PC-based remote control apps,
               | not camera firmware. A well-designed camera firmware
               | would not accept remote control commands that exceed the
               | hardware's safety limits.
        
             | rosndo wrote:
             | Not illegal, just not binding.
        
           | jchw wrote:
           | Hardware should be designed to be resilient to broken
           | software to whatever degree possible.
           | 
           | And then still, warranty should cover defects in the face of
           | modified software.
           | 
           | The SDK is not some hack downloaded from some shady website.
           | It's not a third-party unauthorized tool. This isn't like, "I
           | transformed my Tesla into an ICE car and then asked them to
           | fix it." It's like, "I paired my phone via Bluetooth to the
           | entertainment system and now they won't fix my defective AC."
           | 
           | Yes it's hard to prove that hardware wasn't broken by broken,
           | unauthorized software modifications. Is there even a small
           | amount of evidence that the warranty burden caused by
           | software modifications is significant? Many stores are happy
           | to cover occasional consumer error even if they're not
           | actually liable to, and that is SURELY more common than
           | firmware modifications.
           | 
           | Not to mention the directions this could go into. Oh, malware
           | exploited our phones and then modified the system firmware?
           | Sorry, your warranty is void because you ran unofficial
           | firmware, goodbye.
           | 
           | (Obviously, and especially in the last case, if you _do_
           | break your device on your own, or someone else does, then of
           | course manufacturer warranties do not cover that. That's a
           | whole different wheelhouse. But your warranty should not be
           | entirely void over software. This is the same as those
           | technically-not-legally-binding "warranty void if removed"
           | stickers everyone unfortunately tolerates.)
        
           | opencl wrote:
           | The SDK basically gives remote shutter control and file
           | transfer. There is nothing in it that could plausibly damage
           | anything.
        
             | judge2020 wrote:
             | There are a lot of changeable settings listed in those
             | header files, chances are some combination of settings or
             | other highly-tuned SDK usage could put the camera to work
             | and potentially cause it to overheat (eg. forcing a
             | specific shutter speed while also capping the movie shutter
             | speed, perhaps) since they're not testing the use cases you
             | could theoretically enable via the SDK.
        
               | deathanatos wrote:
               | Then that's a defect in the product, not the fault of the
               | user, and should be covered under warranty.
               | 
               | (& the defect should get fixed. Nobody wants to brick
               | their camera.)
        
             | ceeg wrote:
             | wouldnt shutter control give the possibility of the image
             | sensor overheating from extended exposures? I could
             | absolutely be talking out of my ass but I thought I
             | remembered that being a risk when I flashed ML to my Canon
             | for star photos.
        
               | muhehe wrote:
               | Basically every camera I have had has a "bulb", which is
               | pretty much as-long-as-you-want exposure. Never heard of
               | sensor overheating even after hours of exposure.
        
               | Manuel_D wrote:
               | Overheating is more of an issue for the image processor,
               | at high frame rates. During bulb mode, the sensor is on
               | for a long time but it's only one frame being handled by
               | the image processor.
        
               | buildbot wrote:
               | Any CCD based camera will certainly heat up a lot, and
               | cmos as well to a lesser degree without good/active
               | cooling.
               | 
               | Most cameras time out at about an hour maximum unless
               | they are special purpose astro cameras.
        
               | dylan604 wrote:
               | The worst I can thing of is extra noise from the heat
               | build up from the sensor being energized for extended
               | period. This is one of the many reasons that image
               | stacking is so advantageous. Cold winter nights imaging
               | Orion is probably not going to notice it nearly as much
               | as those hot summer nights trying to image Milky Way.
               | (I'm hoping to take my camera cooler out for a spin this
               | summer. Just a modified pelican case with insulation and
               | ice chest freezer packs. lo-tech)
        
         | jug wrote:
         | Good luck enforcing this in an EU court lol
        
         | DannyBee wrote:
         | Even in consumer places like the US, this is generally illegal.
         | 
         | They would not be able to refuse warranty service without
         | showing that your use of the SDK was the reason the camera
         | failed (and the burden would be on them).
         | 
         | IE they can't say "Yes, the lens popped out because it was
         | defective, but you used the SDK so tough crap"
        
           | tomaskafka wrote:
           | Funnily I had exactly this happen with HTC One - yes, your
           | phone camera has degraded inside a warranty period and all
           | photos have purple fade, but since you unlocked the
           | bootloader, you're out of luck, bye.
        
             | DannyBee wrote:
             | I've had good luck without having to resort to legal
             | process. But some companies are recalcitrant about it.
        
         | [deleted]
        
         | e2le wrote:
         | Is that even legal? It seems similar to the "warranty void"
         | stickers which are nothing more than an illegal scare tactic
         | that many individuals are conned into believing.
         | 
         | https://www.ifixit.com/News/11748/warranty-stickers-are-ille...
         | 
         | https://www.ifixit.com/News/15464/warranty-voiding-stickers-...
        
           | judge2020 wrote:
           | Even if it's illegal it doesn't override user protection
           | laws, so the statement has no effect and they'd need to prove
           | your SDK usage caused an issue with the product to legally
           | deny warranty.
        
           | kahrl wrote:
           | It's not just a scare tactic, it's how these companies
           | operate. They will illegally refuse to service products they
           | have an obligation to. Until there are massive class action
           | lawsuits, this isn't changing.
        
         | cosmotic wrote:
         | Regardless of their written policy or silly warranty void
         | stickers, the law dictates the warranty still covers all
         | components not modified or damaged by the consumer. You might
         | have to fight in court, but thats the law.
        
       | noasaservice wrote:
       | The text (at bottom, outside of the block):
       | 
       | "AS STARTED ABOVE, USING THIS SDK TO CONNECT TO OR CONTROL, ANY
       | COMPATIBLE FUJIFILM CAMERA WILL VOID THE CAMERA'S LIMITED PRODUCT
       | WARRANTY."
       | 
       | I'm sure the FTC would like to have a word, about revoking a
       | warranty by using intended software.
        
         | justin_oaks wrote:
         | Exactly, this part of the agreement may not void the warranty.
         | Just like stickers on the outside of a product that say
         | "Warranty void if broken" don't void the warranty.
         | 
         | In fact, those stickers themselves are illegal:
         | https://www.npr.org/sections/thetwo-way/2018/04/11/601582169...
        
         | oh_sigh wrote:
         | In fact, the Magnusson-Moss act makes it illegal to void a
         | warranty even for 3rd party, aftermarket modifications to a
         | product, unless it can be shown that the aftermarket
         | modification is the cause of or contributed to the warranty
         | claim.
         | 
         | So even if you had some random black box that you plugged into
         | your cameras USB port, and it would send all sorts of wild
         | commands to the camera, _that_ would not void your warranty
         | unless the black box was actually responsible for the damage to
         | the camera.
        
           | judge2020 wrote:
           | The thing is, if the image sensor overheats with this
           | supposed camera stresser, how would they prove it? Do they
           | start to keep tons of logs about API usage and deny a
           | warranty claim if that log has been wiped?
        
       | ISL wrote:
       | Kind of surprising to see Fujifilm do this.
       | 
       | On the flip side, it suggests that there are probably some
       | interesting things that are possible with the SDK.
        
         | spaetzleesser wrote:
         | Not so sure about that. I bet it was just some lawyers adding
         | the clause.
        
           | judge2020 wrote:
           | Here are the header files for the main api (i imagine) and
           | the X-S10[0]. There's a lot of stuff you can do in there.
           | 
           | 0: https://gist.github.com/judge2020/6ed181c1367979333baec948
           | 4e...
        
       | ciprian_craciun wrote:
       | I am an amateur photographer, and I can't understand why the
       | major camera brands (Canon, Nikon, Sony, Fuji, etc.) aren't open
       | at least to the concept of SDK's to control their cameras (let
       | alone opening the lens mount specifications)...
       | 
       | It would make their cameras much more flexible and useful, thus
       | perhaps gaining some users that currently use smartphones where
       | it seems there is greater control over and integration with the
       | cameras. On the other side, if one can implement in software what
       | the producer doesn't want to implement in firmware, they might
       | miss some future upgrade sales...
       | 
       | I am currently thinking on buying a FujiFilm X-T4, and I was
       | pleased to see there is a SDK, but now, finding out that using
       | the SDK is practically forbidden (until the warranty ends), it
       | makes me stop and think about my decision... What could the SDK
       | do to the camera so that it voids the warranty? (On the other
       | hand, given the quality of camera brand produced software, I can
       | imagine the quality of the code that went into it...) :)
        
         | daveslash wrote:
         | I agree with you.
         | 
         | This is a bit off topic, but I have a Sony a3000 and a6000. I
         | have a non-sony USB camera timer/remote [1], and I'm pretty
         | pleased with it. There seem to be similar products out there.
         | 
         | If there is no USB SDK released by Sony, how are these
         | manufacturers creating this USB control devices? Do they
         | partner with camera vendors behind NDAs? Do they reverse
         | engineer the protocol? Just curious.
         | 
         | [1] https://www.amazon.com/Remote-Control-Wireless-Shutter-
         | Relea...
        
         | hadlock wrote:
         | Gating features allows them to wait for a future model to
         | release them there and drive sales. There's not much blood left
         | to wring from the digital camera stone.
        
         | ska wrote:
         | > I am an amateur photographer, and I can't understand why the
         | major camera brands (Canon, Nikon, Sony, Fuji, etc.) aren't
         | open ...
         | 
         | How much are you willing to pay for this? I suspect they've all
         | looked at it, and decided the ROI wasn't worth it.
        
           | pdpi wrote:
           | I'm not sure they have looked at it, and I'm not sure they'd
           | even examine this from an ROI point of view.
           | 
           | Camera makers (even camera divisions in more "high-tech"
           | companies like Sony) are very much traditional hardware-first
           | companies, I'm fairly certain he idea of opening up the
           | cameras is just alien to them.
        
             | ska wrote:
             | That's fair, it may be a blind spot. But even if it
             | weren't, it's not clear it's would be a net win for them.
        
           | ciprian_craciun wrote:
           | Well, the camera is already ~1.5-2K EUR (without lens), thus
           | I think the price already covers it... But if I must put a
           | price on it, I would say ~100-200 EUR, but then it should
           | come with at least 5 years of updates, and it should work on
           | Linux. :)
           | 
           | Also, just supporting some basic features, like shutter and
           | all the exposure settings, shouldn't be that hard... I bet
           | all of these are already implemented, because many cameras
           | have smartphone applications that do allow to control all of
           | these.
           | 
           | Thus, the largest cost would be mostly documentation,
           | packaging and support for the various OS. Which, although
           | might end up being quite a non trivial amount, it could be
           | seen as money well invested in brand building, especially
           | since now, in 2022, only professionals or invested amateurs
           | are buying these dedicated cameras...
        
             | lowbloodsugar wrote:
             | I would happily pay a subscription for an iOS app. The
             | usual argument against this is being commodified, but for
             | the vast majority of the market, Canon has already been
             | commodified in the shape of Apple and Samsung phones. They
             | have to compete now on how good their hardware is, but
             | their "stupid" hardware doesn't cut it without smart
             | software. Their time in the broader marketplace is gone.
             | They can get a small amount of marketshare back if they can
             | make their hardware work with iPhones and Galaxies.
             | Possibly just iPhones.
             | 
             | I've got the cash for a great canon camera. I used to carry
             | one around with me all the time. The size isn't what's
             | stopping me. It's the UX.
        
             | ska wrote:
             | > Which, although might end up being quite a non trivial
             | amount, i
             | 
             | Right. Engineers usually underestimate how much this really
             | is. Often by an order of magnitude or two.
             | 
             | I'm pretty confident their margins aren't fat enough they'd
             | be happy considering eating 1-2% (i.e. your numbers) on
             | something that might help a fraction of install base. Hell
             | they may already not be making next to nothing on these
             | bodies.
             | 
             | So it would be a real project, and it would cost them
             | enough that (using your rough numbers) they'd need to sell
             | probably a few thousand support contracts a year to justify
             | doing it properly (supporting multiple cameras, customer
             | support, testing etc.). So I imagine if they have looked at
             | it, they've balanced that against the "brand building" as
             | you put it, and aren't sure it's a net win.
             | 
             | The prosumer space is funny for stuff like this, as people
             | are often quite capable but not really willing to pay
             | enough to justify the cost of real support. Some companies
             | solve this by throwing something unsupported/unofficial
             | over the wall, others (or their lawyers) decide the whole
             | thing isn't worth the hassle.
        
         | carl_dr wrote:
         | > I am an amateur photographer, and I can't understand why the
         | major camera brands (Canon, Nikon, Sony, Fuji, etc.) aren't
         | open at least to the concept of SDK's to control their cameras
         | (let alone opening the lens mount specifications)...
         | 
         | At least Canon and Nikon do.
         | 
         | I use the Canon and Nikon SDKs in a product for work, and there
         | are plenty of third party applications which allow control of
         | their cameras.
         | 
         | They might not officially offer support for them, but they do
         | keep them updated for new cameras and I have had bugs fixed and
         | questions answered.
         | 
         | There are open source projects using these SDKs - See NINA [0]
         | as just one example.
         | 
         | [0] https://nighttime-imaging.eu/
        
         | Melatonic wrote:
         | The Sony mirrorless cameras used to have some third party
         | "apps" that were pretty cool but apparently are now all
         | discontinued. And what the Magic Lantern team did for Canon
         | cameras (especially the 5DmkIII) was absolutely amazing. I
         | still miss features to this day.
         | 
         | If you are looking for a new camera also definitely checkout
         | the new Panasonic Lumix line of full frame cameras - they are
         | damn amazing. Extremely intuitive UI, tons of features you do
         | not find in other cameras, amazing video (especially with an
         | external recorder - you can do 6K raw video) and built like a
         | tank. And they all use L-Mount which is shared among multiple
         | camera manufacturers with tons of lenses available from Sigma
         | and others. The Panasonic lenses are pricey but also extremely
         | high quality (probably because they also design super high end
         | cinema glass)
        
           | to11mtm wrote:
           | Sony does have SDKs, They're just fragmented between older
           | and newer models now. =/
        
         | ISL wrote:
         | For the bigger players, they miss out on market segmentation.
         | An EOS M with Magic Lantern has a number of features that are
         | featured on Canon's cinema line, for example. The M is perhaps
         | no longer competitive in key ways, but had ML been available
         | with today's level of polish in 2012, it would have eaten into
         | higher-margin products.
         | 
         | Fuji is perhaps best poised to enable open development -- their
         | pricing structure is more around hardware variations on a
         | common sensor/processing than strict differentiation in
         | capability.
         | 
         | The far future of camera development probably does look like
         | open-source (or, at a minimum, common-versioned closed-source)
         | software/firmware riding on commercially-manufactured hardware
         | platforms (just like computers today). We're not there yet, but
         | the technical success of Magic Lantern shows that the door is
         | open.
         | 
         | A dark-horse entrant like Sigma could, in addition to Fuji, be
         | a hardware vendor that could crack open a "commoditize your
         | competition" market.
        
           | jseliger wrote:
           | In the meantime, everyone except professionals and image-
           | quality obsessives has moved to phone cameras, for which
           | Google and Apple have developed incredible software. It's
           | been obvious for at least ten years that camera makers need
           | to improve their software, and they've not done so, or very
           | minimally done so.
        
         | 999900000999 wrote:
         | I strongly suspect it's just easier from a customer support
         | point of view, if you develop an application that causes the
         | camera to overheat and fail.
         | 
         | They really don't want to send you a new camera. The dangerous
         | thing with code controlling hardware directly, is absent safe
         | guards you can easily exceed the mechanical limits of the
         | device.
         | 
         | This is why seriously overclocking a CPU will definitely void
         | the warranty, but at the same time CPUs are often marketed
         | based on how well they handle overclocking.
        
           | morpheuskafka wrote:
           | But in this case, the camera processor still retains final
           | control over the commands from the SDK. This isn't a customer
           | firmware, just a networking interface that simulates pushing
           | buttons and changing menus. The firmware has just as much
           | ability to reject damaging commands as it would if the user
           | was physically entering them.
        
       | Rucadi wrote:
       | I suppose they have to demonstrate that the error you get derived
       | from the use of the SDK.
        
       | spaetzleesser wrote:
       | Camera manufacturers really seem to try to shoot themselves in
       | the foot as much as possible. They are putting on something
       | interesting and immediately kill it for braid use. Nobody is
       | going to publish software based on the SDK. At least nobody who
       | doesn't want the threat of lawsuits hanging over them.
        
       | Proven wrote:
        
       | EMIRELADERO wrote:
       | > Subject to the terms and conditions of this Agreement, Fujifilm
       | hereby grants to you a limited, non-exclusive, non-transferable,
       | and royalty-free license to;
       | 
       | (a) use, _modify_ and make a limited number of copies of the SDK
       | solely for the purpose of the Development;
       | 
       | Later in the same agreement...
       | 
       | > 3.5 You shall not (and shall not permit others), to reverse
       | engineer, reverse compile, or disassemble the SDK in any way(in
       | whole or in part); and you shall not (and shall not permit
       | others) to use any method to trace, decompile, or disassemble the
       | SDK.
       | 
       | So, which one is it?
        
         | detaro wrote:
         | You can do all modifications that do not involve things banned
         | in the second quote?
        
           | EMIRELADERO wrote:
           | And what would those entail? How could one modify an SDK
           | without disassembling or even debugging?
        
             | gambiting wrote:
             | An SDK typically isn't a binary blob - it's usually a
             | collection of header files you can integrate into your
             | projects, media assets, config files etc. All of those can
             | by modified by hand without disassembling anything.
        
               | EMIRELADERO wrote:
               | That is true. It would be interesting to see this played
               | out in court. When there are doubts around a certain
               | clause on a contract of adhesion/license with non-
               | negotiable terms, courts tend to side with the
               | interpretation most favorable to the consumer.
        
       | hexo wrote:
       | That's certainly illegal here.
        
       ___________________________________________________________________
       (page generated 2022-03-24 23:00 UTC)