@james_pattison it doesn’t look like APM is trademarked (for autopilots anyway). I understand your concern and we can watch out for it, but I don’t think DroneCode is likely to be making much use of the APM name in future.
1 Like
@tridge Thanks, no worries. I hope the whole process isn’t more complex than it absolutely needs to be.
As a relatively new user, I’d suggest maybe it’s time for a rebranding of the project. "ArduPilot’ is obviously derived from “Arduino”, which, to those just getting started, means it should run on hardware called an “ArduPilot Mega” (APM), but the current generation of software/hardware has evolved away from the Arduino, at least for multicopters. Something called ArduPilot (again, bringing to mind Arduino) is not the immediately obvious choice for a Pixhawk running an STM32F* CPU, and it’s odd to think that ArduPilot’s ArduCopter 3.3+ won’t run on an ArduPilot Mega, especially for a new user. I think something more along the lines of Baseflight/Cleanflight/Betaflight, which keeps the hardware ambiguous, would be more appropriate. Just my 2 cents.
I’d also like to suggest this thread be relocated to the General Discussion area, I don’t know about other folks but I’m getting emailed every few posts. Those interested could subscribe to a thread there, while not spamming the rest of the forum members 
You should only receive e-mails if you subscribed to the thread I believe. At the end of the thread you should have a button where you can choose what notifications you receive.
Just my two cent: We would like to support the ArduPilot project with our hardware and may be bringing some rugged and high-level products to the ArduPilot community. I feel the community is great with a lots of high potential, but it is lacking in professional hardware (same for PX4). This is where we would like to fill the gap. For sure 90% of the community will not be interested in this kind of hardware, but 10% could be.
ArduPilot is not our core business, as the AdaRacer-FCS (and its ecosystem) has been specificaly made for the Ada/SPARK programming language and community, but I feel it could be a good complementary way of cooperation between AdaPilot and ArduPilot in sharing some professional hardware.
2 Likes
@tridge @MagicRuB: clearly what’s been happening here seems very crummy, but two thoughts came to mind:
- Have you considered having an Apache style CLA on AP that would allow you to change the license if you decide it is the best course of action?
- As I was discussing a week ago, as much as the GPLv3 is great for many uses, I am worried that any vendor of any piece of hardware that has enough potential to injure or kill others if it misbehaves, is not going to feel good about selling hardware that can be reflashed by the end user with firmware that they did not verify is safe, and for which they could be sued for millions if their hardware crashes and injures/kills others after the firmware was replaced/modified as allowed by GPLv3.
If a 50lbs drone to do crop dusting is modified by an end user, and crashes into a school, wiping out some kids in the playground, do you think the parents aren’t going to sue the drone company into oblivion, or care a single second that the firmware had been modified by the end user as required by GPLv3?
I personally think if you had GPLv2 instead, or Apache2, more such companies would be willing to be using the great ardupilot codebase.
I’m sure many such companies are not against open source at all, nor do they require a BSD license, but for the reason I just explained, GPLv3 requires too much from them liability-wise.
As much as GPLv3 would be great for my Tivo or my Chromebook, or my phone, I’d be more than happy enough with GPLv2 for ardupilot since it’s still just as free, and if some vendors ship ardupilot hardware that I can’t reflash, I don’t have to buy their hardware.
As things stand, it’s what they are going to do anyway, except they won’t even have to provide their source code at all, which is even worse.
@marcmerlin you’re talking to a couple of copyleft fanatics here 
(and I mean that as a neutral description, not anything else).
No. That’s not the way to do it. Any device should FORCE signing of code. What is should NOT do is force using the manufacturer’s keys - it should be easy to add your own keys, and sign your own code.
That way, code can be modified as per the GPL, but the mere existence of a user key on the device indicates that they (may) have tampered with the code. And it won’t need much more than a cursory glance to tell what code has been tampered with.
That’s (sort of) the way it’s always been, and that’s the way it should stay - as in - even with mechanical devices people have been able to tamper with settings, and what you need is the digital equivalent of a “warranty void if removed” sticker.
1 Like
I have heard that from several sources, but I don’t think it makes any sense. Our world is full of large dangerous devices with user replaceable parts. You can buy a new steering wheel, engine, tyres or brakes for your car, and if those replaced parts fail and cause an accident then the original car manufacturer isn’t responsible. Car makers have not responded to this supposed risk by welding the wheels to the car.
The same thing happens in aviation. You can buy new parts for your full sized plane (including autopilots) and if those parts fail then you won’t have any luck suing the original plane manufacturer if the failure was due to the replaced part.
In fact, I think the opposite argument is much more plausible. Drone makers often abandon their products, leaving users stuck with DRM on those drones with no ability to update for new fixes (including safety fixes). Being able to put a new (fixed) firmware on the drone makes it safer and is what a responsible manufacturer should enable.
I know many companies do want to use DRM to prevent users from updating the software on drones, and this liability argument is used to justify that. I don’t believe for a minute that it is the true motivation. I think instead it is motivated by increased market control. Having DRM on a drone gives a company a few things:
- they can control who can sell add-ons to the drone
- they can stop supporting an old model and pressure users to buy a new model instead of upgrading software in the old model
Neither of those things are good for end users however, and they are most certainly not good for the DIY community.
I don’t mind at all if drone manufacturers include additional steps that are required to initially “unlock” a drone before you install a new firmware. This could include a screen with copious warnings on the dangers of modifying the software. Locking it down completely is not a good idea though and I don’t think can really be justified on liability grounds.
3 Likes
What would be nice (and I doubt it would happen) is that insurers should insist that the device (be it drone, car, whatever) has current, suitably patched and secured, code installed. And if it doesn’t, the premiums go through the roof.
One thinks of the flashy new keys that come with, say, BMWs, that are so secure that owners have gone back to using crooklocks to protect their vehicles from theft.
If the insurers would keep a “vulnerability register” and the owner has to show their gear has been protected against it, manufacturers might find it hard to fight against owners of brand new gear finding their insurance premiums are sky high … but - I won’t say the insurers and the industry are in cahoots - but I can’t see them as seeing it being especially in their interest to have safe code … 
@tridge your points are well taken, I think there is no one true answer here, but just on the aviation side, you absolutely cannot change a random part on a certified plane without said part being certified and replaced by a certified mechanic.
You also cannot change the software on any piece of the plane with anything other than the one from the manufacturer.
Similarly, few cars allow you to change their firmware in a supported way (there are aftermarket solutions, piggyback CPUs and full CPU replacements which are tolerated for cars but absolutely illegal for planes unless it’s a non certified homebuilt airplane which you then are required to have built at least 50% of) .
So basically in the US (and I think most everywhere else), you cannot buy a plane and replace any software on it with your own.
I don’t speak for the FAA of course, but I’m guessing they’ll be doing the same for UAVs: if you built it, you can install your own firmware, if you didn’t build it, you will likely not be able to put your own firmware on it, before long.
1 Like
I do not see that happening any time soon with UAV’s in the US that are under 55lb takeoff weight and have no Type Certification. It would be impossible to enforce. That does not mean that UAV manufacturers will not lock down their products to force obsolescence and keep sales going once the market is saturated. But I don’t see the FAA having anything to do with it because they have way bigger fish to catch.
The issue with full size aircraft is not the provider of the software, but the assurance/certification of it - it isn’t that you can’t change software, but that there arent any after-market options available to do so, and recertification is prohibitive.
@ChrisOlson you’re half correct actually. I already had to register my self built UAVs which included a full description, manufacturer and all (because the pilot registration thing is not acceptable to me due to its restrictions). The FAA reviews it and can give you a tail number, or not.
I believe (I could be wrong) that for commercial UAV applications, you have to go through a similar process.
Now, I think you’re right that the FAA does not currently enforce anything on locked down firmware for even commercial UAVs, but they do for full size aircraft, so I wouldn’t be surprised if one day they start doing this for heavier commercial UAVs (maybe 4kg to 20kg) since quite frankly they start getting in the somewhat lethal category.
As for bigger fish to catch, sadly, I’m not sure that will be lasting for much longer, I think heavy UAVs will become the bigger fish to catch before long. Admittedly they already started by threatening anyone flying even a foam airplane that weighs more than 250g with up to 3 years in jail if they don’t take the right registration steps. Needless to say that I think it’s way overboard, but they’ve already done it and now they’re just saying that they likely wouldn’t apply the full 3 years in jail for a small foam plane, but that does not fill me with any joy or reassurance
@marcmerlin As it is at present the FAA does not have enough staff to properly enforce GA regulations and depends on whistleblowers for enforcement actions. Part 107 was a knee jerk reaction to industry pressure from manufacturers and people who want to use UAV’s for commercial purposes to “do something”. It was not well thought out and is pretty much a joke IMO, giving away a Remote Pilot Certificate to somebody who passes a written test, with no practical exam at all. So the result is that we have commercial UAV pilots that don’t have a single clue how to fly, and are depending on software to fly the aircraft for them. To my way of thinking this is akin to getting your instrument rating by shooting an ILS slaved to the autopilot.
Where software is going to get locked down is manufacturers of commercial UAV’s who will be named in a lawsuit when a UAV crashes with an unskilled pilot at the controls, that is depending on the software to fly it for him/her - and that software fails. I don’t see the FAA getting involved with it and attempting to certify every component, including software, on <55lb UAV’s. They simply do not have the manpower to do it.
As many other open-source software projects have proven over time, when you have thousands of eyes all over the world looking at the code for an application, vs only a small team of developers for a closed-source proprietary application, the open-source one always produces a more secure, robust, stable product. Just like the vast majority of the internet prefers to use linux/apache vs IIS, commercial manufacturers of UAV’s that choose to use the ArduPilot stack will find themselves in much better hands, with a more robust and stable product than they can build themselves. Even the largest software companies like Microsoft are not able to assemble a developer team that can match the open-source model. There will be a few like DJI that attempt to maintain control of the market with totally proprietary offerings locked down tighter than a drum. And they will eventually shoot themselves in the foot because they shove stuff out the door half-baked and depend on their end-users to find the problems with their products. In the proprietary world that only works until those end-users get tired of paying $3000 for something that doesn’t work, and goes thru 5 or 6 revisions before the problem gets fixed.
So I see it as being a non-issue. It will take care of itself.
@ChrisOlson you may be right on the FAA, we’ll see.
BTW, I don’t expect them to certify the software either way, as you said.
I also agree that OSS with more eyes is more likely to be bug free than a closed source firmware. That said, you can also remove limitations that may be imposed by the local FAA the regulates your airspace, and then my original point about liability which I will not re-iterate.
To be clear, I love ardupilot, I think with more users and more eyes, it can only be better than closed source firmware, but commercial vendors sadly seem to have an issue with ardupilot for reasons I won’t repeat. You may disagree with me, but right not the evidence is here IMO
Anyway, I think we’ve said all there is to say on this topic. Cheers.
Thanks to the ArduPilot Dev Team. I started my first donation today on a monthly base.
3 Likes
Interesting all this !
The core of Ardupilot is being used is thousands of hours of flights. It has a track record. It is insurable. It is airworthy. It is FAA friendly. Let’s just keep track of successful hours of flight in the core Ardupilot.
On another subject, Uber and Tesla have street legal cars who drive themselves. They say the machine driver is now more safe than the human driver ! The same will happen with UAV guaranteed !
Semi-autonomous quadcopters are the future. Autonomous if you bend the rule. I founded flyingscarecrow.com. We hunt wabbit ! No really we chase birds.
www.miniphone.ca/patentpendinguntildecember2016.pdf
1 Like
@maxmay just to correct one bit. Teslas are not safer than human drivers, not even close. I know, I have one I have multiple instances where its limited sensors would have caused an accident, including once plowing into a car at 50mph because it didn’t even see it, and it was right in front of me.
They claim the next autopilot version (new hardware) will be at some point, but at this point, it’s still vapourware.