Bricking Incident – Public Announcement
orqafpv.com
orqafpv.com
But given the correct thing to do in that case is to wait for the time limit to roll over and then sue them for violating the copyright (10-100k * per device?), doing it this way:
* (from another thread) The time gate was hidden in a separate, known (and so not re-reviewed, for better or worse) driver, not the thing the contractor presumably work on? Also, that would open you to "they removed the contractor's code but the contractor's bricking code was still present", which would seem independently a Bad Thing
* The article states a specific date was chosen (middle of a long weekend) which makes it seem malicious rather than "license enforcement", but again, if that's not just the result of pasting in the contract termination date + <reasonable math> (which they can point to if this is legit) in which case it's just questionable decision making.
I suspect this will at least improve their policies for code reviews (and their sourcing and source checks for large third party libraries).
Doesn't excuse ransomware, but it does make you wonder what drove someone to that end.
———
Official Statment
SWARG as the copyright owner implemented a time-limited license into the code used by ORQA.
The license has expired which causes a blocked device until a new license is provided.
To enable normal usage of the product SWARG provides a license extension till 1. July 2023.
In the meantime, SWARG and ORQA will hopefully reach an agreement about Copyright/licensing.
You can download the binary files under the following link: https://drive.google.com/drive/folders/1...3XtHTUEVsN
To extend the license place the update.bin file into a license folder at the root of the SD card. After the update is finished delete the folder with its content and perform a firmware update by placing the .orqa update file at the root of the SD card.
Thank you for your attention.
Dr.techn. Tomislav Jukić CEO at SWARG d.o.o.
But what matters is the contract that they signed for the development contract that they undertook. It could be that ORQA’s lawyers really screwed up, but in every contract-for-code I have ever encountered (either directly or through friends), the copyright of the written code ends up belonging to the company hiring the contractor, not the contractor.
Given the way the contractor handled the “license violation”, they’ve already put themselves in the unethical behavior bin and so I don’t trust them unless they demonstrate that the contracts they agreed to left the copyright with the contractor, and included a time limit. The latter especially would be “time to fire our law firm” moment for ORQA, if it’s actually what has happened.
This presupposes the entity that created the code was hired as a contractor, rather than a company with intellectual property to license.
First a quick and simple answer to your question: Demo/Evaluation code, allows the device manufacturer to evaluate your library to make sure its fit for purpose before commiting to licencing it, however you don't want manufacturers just ripping off your code and shipping it to customers without a licence. So the demo code stops functioning at the end of the trial period. But this code is only ever meant to be ran in the lab, never on the end customers device.
Now a more WALL O'TEXT answer.
A common example of a soft brick could be the iCloud Activation Lock but another could be an expired licence (depends completely on the business model of the thing in question).
Personally, my ethos on selling a "module"/library to be included in someone else's product would be that you wouldn't brick the device on licence expiry but alert the user/company by other means that the licence has expired. My views might be different if it was the device manufacturer put in the code, for example iCloud Activation Lock, which in general is a good thing as it helps reduce the resale value of stolen devices, however I'm not a big fan of the eWaste it creates when people forget to remove the lock when recycling devices.
In this case it seems to be part of the devices bootloader, and a quick google of the company involved I'm gonna guess it relates to the firmware updater part of the bootloader.
How would I have done it in this case? Well in the first place I prob would have sold a perpetual licence with no expiry in the binary and then work out a support plan with the company for my recurring income stream, But for the sake of argument, if I were going to do down the time based expiry method (Making dam sure the company knew of this expiry and what the extension cost would be, and how to issue an update without my updater, as the company may decide to invest the time in creating their own updater instead of using mine - one final update so to speak) I would set a deadline in the updater to stop accepting new updates after that date unless a new signed licence was included in the update file. That way the user gets to still use their device (wouldn't even have to pester the user that my module was expired) but if the company wanted to push updates using my updater they would have to sign a new agreement.
However this would prob just drive the company to stop releasing updates for the device in question instead of paying up. (which would go against my ethos, I want companies to update their devices for as long as possible, I'm also a believer of the expression "you get more flies with honey than with vinegar", bricking your clients customers devices ain't gonna win you many friends if any at all, thats gonna hit the pocket book later down the road even if you were 100% legally right to do so because who is going to want to do business with you after the cat is out of the bag?
EDIT: I still remember the FDTI bricking incident - long story short: there are clones of FDTI chips, these clones got into end users products, FDTI pushed a driver update via windows update that "bricked" these clones (reworte the PID on them), were dicks to people about it on twitter, FDTI lost a ton of good will, MS pulled the update after it was discovered, FDTI reversed course and changed the driver to split of a canned message instead of its real output when a clone is detected instead of bricking the clone chip. But ever since then I've avoided using FDTI chips even if they are dam useful at times.
it was timed so it activates on a spring Saturday,
during a long weekend, when most of you should be flying,
and most of our engineering team should be enjoying their
well-deserved days off