I intend my products to pull packages not only from my own servers but also Debian official servers, so bugfixes upstream can be automatically applied without me responding.
Yup; sounds like the device is closer to a server than a single-purpose appliance (say, a TV or a talking toaster) with relatively "lots" of software, so this approach should make sense.
I've built binary only packages using the naïve direct method (
dpkg-buildpackage -b -us -uc, nowadays
debuild -b), so the result does not have a source package at all – for example, for things like Plymouth bootsplashes, which do not contain ELF executables, just images and scripts, and therefore do not have any real "sources" anyway.
Another way to look at the situation is to consider it a custom Debian derivative, with specific proprietary blobs (your own) enabled (and also provided by your own repo).
The reason
the way you or any business approaches this situation is so important, I believe, is that it dictates the unstated expectations for both yourself/the business, as well as the customers. In all cases in the spectrum – from a Debian derivative, to your own full stack source three –, any licensing issues are rather simple to solve while still keeping the core product features proprietary; it's just that often the solutions depend on the approach. (There are some difficult licensing questions when you need a kernel with proprietary drivers, that you do need to talk with a lawyer or some experienced kernel developers like Greg KH to solve; typical solution is a two-part driver with the GPL part exporting a clear interface the proprietary part uses, so that a "knowledgeable" developer could replace the proprietary part with a GPL'd one performing the same functions.)
In particular, lurking on LKML or related mailing lists to see how the core devs have reacted to similar drivers in the past, gives a good idea how not to do it. Placing oneself as a kernel developer, and thinking of how to do it with the least amount of pain (for oneself as a kernel developer), then working on top of that, seems to work.
Similarly, incorporating proprietary code into GPL packages is always problematic. Usually, the proper/acceptable answer is a modular GPL'd interface, to which a clearly defined (but just happens to be proprietary) part can interface to, always with a clear description of the full interface. The last is the key: you do NOT want to reopen cans of worms and do it like graphics drivers or ALSA does. For kernel drivers, it is always a bit of a tight rope walk to try and open up the
interface, while keeping only the
implementation proprietary. (I wish more developers realized the last: for me, it well balances the needs of proprietary licensed software, with the copyleft requirements of GPL; so much so that I have no problem working with either.)
On the other hand, having a distribution (or equivalently, a GNU/Linux based firmware image) with both GPL and proprietary packages, is no problem at all, because the standard interfaces (standard C library, other standard dynamic libraries with multiple compatible implementations; inter-process communication, sockets, etc.) are considered a boundary for software licensing. (The US Supreme Court
decision in Oracle v Google case is informative. The vast majority of C/C++ developers in particular operate wholly upon the expectation of interfaces described in public header files and elsewhere to be such a license barrier: that writing your own code from scratch, but implementing the same interface as some other software, does not create a derivative work of that other software.)
One very tricky/problematic/hard/prickly question remains: will you try to stop your end users from replacing the firmware image with something completely different?
On Intel/AMD x86 land, there is a feature called Secure Boot. When enabled, the hardware refuses to boot unless the boot image has been cryptographically signed by Microsoft. (This is because most BIOSes only contain a Microsoft root certificate.) As you can imagine, if this feature cannot be turned off in the BIOS, most Linux users are very, very unhappy. (There is a reason why ASUS server motherboards are basically Windows-only, and unheard of in Linux datacenters, clusters, and HPC, and it is not really a technical one. ASUS's choices when Secure Boot came out burned a lot of old Linux greybeards, a lot of whom are in charge of building said datacenters, clusters, and HPC in general, and don't want to go through the same troubles again.)
I believe it is good to understand the long-term implications of such choices, and make sure they align with your business strategy.
As to regulatory requirements, make sure your documentations specifies that the thing you're selling has two components, software and hardware, and that you guarantee nothing for either part alone, only for the combined product. This means that your regulatory responsibility ends if an user replaces either the software stack, or the hardware – this is similar to the "non user serviceable parts inside" sticker, or "guarantee void if broken" stickers on hardware; neither is actually legally exactly correct, but they convey the right idea, which is enough. This has already been solved for basically all countries in the world, wrt. radio frequencies. Basically, a majority of WiFi Access Points and routers run Linux. A decade or so ago, there was a lot of discussion on how to restrict the hardware to the frequency bands allowed in each geographic jurisdiction, since these vary a lot. Some suggested that it would be impossible to allow Open Source implementations, because the users could then just modify the frequency band selection, and therefore break the restrictions; stricter hardware restrictions were required, according to them. I guess everyone slowly realized that an user could just buy the hardware elsewhere, and achieve the exact same thing.. In any case, if regulatory compliance comes up, looking up the Linux (and OpenWRT/DD-WRT) mailing list posts and blog posts and tech magazine articles, shows up how it ended up being resolved in the WiFi land. In short in practice, the device should be compliant by default, and yell (either in the UI or in the documentation; in the documentation suffices, although not without grumbles) at the user when they fiddle with knobs that may affect regulatory compliance. So, if you expect to sell under different regulatory requirements, do design your product so that the user only needs to select the geographic location, which you internally map to a set of regulatory requirements/rules, and apply to all parts. That's how other existing global products do it, anyway.
For any litigation-happy USians, I am not a lawyer, and none of my posts anywhere are legal advice. (In the rest of the world, writing opinions about various laws in various jurisdictions tends not to require a license or specific utterances to avoid liability. And people are expected to know without an always-visible label that using a keyboard strains our wrists, or that putting an animal in a microwave oven will kill them. The unskippable FBI warning in DVDs and BDs mastered for Nordic audiences and sold in Finland – just try to sue me, G-man, please – turned me from an avid video renter into an illegal downloader a couple of decades ago; nowadays I use legal streaming services like Youtube, though: I find better entertainment than Hollywood produces there.)