Arduino Published Updated Terms and Conditions: No Longer an Open Commons
Key topics
Regulars are buzzing about Arduino's updated terms and conditions, which some see as a betrayal of the platform's open-source roots. Commenters riff on the implications of this shift, with some speculating that Qualcomm's influence may be behind the change. As the community grapples with the news, a consensus emerges that Arduino's new direction may stifle innovation and limit user freedoms. The discussion feels particularly relevant now, as it highlights the ongoing tension between open-source ideals and the commercial realities of maintaining a popular platform.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
3m
Peak period
55
0-6h
Avg / period
22.7
Based on 68 loaded comments
Key moments
- 01Story posted
Nov 21, 2025 at 10:44 AM EST
about 2 months ago
Step 01 - 02First comment
Nov 21, 2025 at 10:46 AM EST
3m after posting
Step 02 - 03Peak activity
55 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 24, 2025 at 1:42 PM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
This is a reminder - never sell out your baby unless you're willing to see it squeezed for every penny, community be damned.
https://arduinohistory.github.io
https://hackaday.com/2016/03/04/wiring-was-arduino-before-ar...
I’m not sure what the value proposition is overall, though. The IDE, perhaps? I never particularly saw the draw, but it clearly met the needs of some real market niche.
MCUs are lower power, have less overhead, and can perform hard real-time tasks. Most of what Arduino focuses on are MCUs. The equivalent is the Raspberry Pi Pico.
In my experience, the key thing is the library ecosystem for the C++ runtime environment. There are a large number of Arduino and third-party high-level libraries provided through their package management system that make it really easy to use sensors and other hardware without needing to write intermediate level code that uses SPI or I2C. And it all integrates and works together. The Pico C/C++ SDK is lower level and doesn’t have a good library / package management story, so you have to read vendor data sheets to figure out how to communicate with hardware and then write your own libraries.
It’s much more common for less experienced users to use MicroPython. It has a package management and library ecosystem. But it’s also harder to write anything of any complexity that fits within the small RAM available without calling gc.collect() in every other line.
But I'm not using Arduino, so idk.
Not all platforms give you the right to do this. For example, if you buy a dev board from STM - it's only licensed for research and development. Also, because you might want to continue to sell the same thing for years, and the board designs were open-sourced, you could buy the same part for years and years. So you can continue to sell your CNC kit that uses an Mega 2560 without worrying about Arduino coming after you or that they'd discontinue that part.
With the exception of a handful of applications for their higher-end boards, I would think most of this flotilla of ships has already sailed, just on a cost basis?
Especially lately. So much more choice.
The main feature of classic Arduino boards has always been a thin abstraction layer on bare metal. RPi is not that at all.
(As mentioned by the other commenter, I'm referring to their Linux boards, not the Pico)
I don't think anyone was arguing they cared about Atmel vs ARM. In fact, the point of Arduino is to make that not even something a user would need to know.
The argument is Linux vs Bare metal Arduino are vastly different user experiences and complexities.
You can do gpio, pwm etc from a linux pi but the hardware is worse at it and you'll be fighting against the system quite a bit. It's a lot of boring complexity to be allowed to do something simple; and the next update might break it.
If I need a linux system AND hardware interfacing, I'll usually use a regular pi + a pico for the hardware stuff and connect them via serial or something
There are meaningful disadvantages to replacing an Arduino with even the Pi Zero.
Yeah, makers will move to Raspberry Pi products for the ecosystem and documentation, but it will be to the RP2040/2350 products.
But also the ESP32 series, particularly Adafruit's kit.
I have dozens of Arduinos that I will never use.
With a similarly priced (sometimes cheaper) platform like the amazing rp2040 / rp2350 which is roughly 100 times more powerful, I have no idea what the niche is for them any more.
The way they dropped the ball with their IDE is amazing. It still looks and feels like something that was rejected during beta testing in 1993
Arduino is following roughly the same trajectory as BlackBerry, with the current phase being "rapidly fading into obscurity"
They just want something that works, and ideally to keep using the same thing they've always used. They know what Arduino is, as long as it does the job they aren't interested in researching alternatives. They don't want to get involved in adapting someone's instructions for a different pin layout, or risk that anything they've done up to now stops working.
Yes, we all know it's a massively out of date platform easily outclassed by much cheaper and more flexible solutions, and if you must use the Arduino IDE it can build code for all sorts of boards. But for non-technical people by far the most important factor is to stick with something safe and known.
The Arduino HAL and the overall comfort of the Arduino IDE are genuinely valuable. I didn’t have to learn new flashing tools or a new debugging toolchain just to light a few LEDs, read some buttons, and emulate keypresses on a PC. The learning curve was basically zero.
I’ve worked with embedded systems before, and this level of simplicity is incredibly useful for people who just want to ship simple solutions to simple problems without fighting through vendor-specific, arcane tooling.
I've got some RP2350s since then with Micropython, now those might be even better for getting stuff done (without network or extreme low power needs)
Other reasons I'll reach for an Arduino over alternatives like ESP, RasPi (Linux or 2040/2350) include:
Simplicity. I very much ascribe to KISS. Having WiFi or Linux as part of my hardware _always_ leads me into scope creep. If the idea could be done on an AT328 (or similar), in my head it _needs_ to be.
Robustness. I probably have thrown out dozens of 3.3V microcontrollers/SOCs with dead io pins because I fucked up. An Arduino will often shrug off shorting 12V to an io pin (or even vcc) without blinking. RasPis seem to sometimes get damaged just because you looked sideways at them while thinking about 12V.
Experience. For me, the way I come up with project ideas seems to often be fundamentally linked with "knowing" how I'll do it on an Arduino. I've been using them over 20 years now, practically since they first appeared. And I'd been writing code for ATMega chips since a Burningman project in 1999, struggling with a cross compiling gcc toolchain. Arduino IDE was both instantly familiar, and such a breath of fresh air for me back then. It allowed me to easily experiment, and lowered my barrier of entry to random weekend or evening project ideas.
Separateness from work. I find the low level coding on a bare 8 bit microcontroller to be almost a completely different thing to coding for work. When work is going badly and I'm approaching burnout, any personal time Linux based coding for RasPis pretty much grinds to a halt. I'll find myself reading a book or doomscrolling social media instead of tinkering with that kind of project. The Arduino IDE is different enough to "work tools" that it doesnt get affected quite as
In this case, though, I disagree that there was no competition. Ecosystems like Arduino are real threats to large incumbents in adjacent sectors. If all the tooling and products necessary to embedded development end up being easily accessible, expensive options like Qualcomm's become effectively commoditized. Qualcomm basically acted like Bill Gates buying Compu-Global-Hyper-Mega-Net https://simpsons.fandom.com/wiki/Compu-Global-Hyper-Mega-Net
Acquisitions tend to be done in a haze of dream-state thinking. Maybe that's part of it.
Most vendor lock-in isn't "it's impossible to do the thing" but "it's hard enough to do the thing any other way, so this is effectively the only practical way to do it"
I put together a simple setup to skip the arduino ide on an AVR design, but still be able to use their serial.println and other utilities. You can use it side by side with manual register masks for enabling IO.
How so? It uses bog standard avr-gcc and avrdude. There is nothing stopping you from using those yourself.
What's hard about it?
But take a room full of kids and get them to write a program that blinks an LED, or drive a simple 'robot' forward, and it's awesome. Easy to use. I've never burned out a board (even driving considerable current through them). Things are tolerably well marked. Lots of teaching tools. Lots of different suppliers of easy to connect motors, servos, lights, sensors, etc.
For the same reason, if you are not an embedded engineer, but need a simple micro-controller to turn something on an off like a heater in a chicken coop, it's fantastic. And if you want, buy the $5 knock-off Uno. It should be the same, except that it doesn't support the (now defunct) foundation.
Specific AVR Arduino annoyances I remember:
* Strings loaded to RAM instead of program memory, so you use up all your RAM if you have a lot of text. Easily fixed with a macro
* serial.println blocks, so your whole program has to stop and wait for the string to be transmitted. Easily fixed with a buffer and ISR
* Floating-point used everywhere, because fuck you
* No printf(). It's in avr-libc, and it's easy plumbed in, but the first C/C++ function that everybody ever learned to use was somehow too complicated or something.
* A hacked-together preprocessor that concatenated everything, which meant you could only have your includes in one place, thus breaking perfectly good, portable code.
I think they ultimately did a disservice to novice programmers by giving them something that was almost a standard C++ environment, but just not quite.
While it does concatenate, does it break something regarding the include mechanism, assuming said files use include guards? You can include stuff wherever anyway (though doing it within a scope needs special considerations).
Modern AVRs have program memory mapped into the RAM address space. The GCC linker scripts for the parts that support this put strings into .rodata within that memory region, obviating the need for special macros to retrieve them. However, you won't find this on most of the usual suspects in the Arduino AVR ecosystem.
It's true that you can (and always could) use avr-gcc and libc, but the core sale was what makes it not this.
The "locked in"/captured API and IDE were directly extensions of a language and IDE called Processing.
Processing overlaid an art-focussed layer on top of Java, providing a simpler API, and an IDE with just two buttons.
Arduino was based on this - the same IDE format, similar API conventions (just on top of C++), precisely to allow these same artists to move into physical installations and art.
Arduino was not designed initially to be so general, it was tool written by and for this specific group of people, so has opinions and handrails that limit the space to provide the same affordances as Processing specifically.
https://blog.arduino.cc/2025/11/21/the-arduino-terms-of-serv...
I'm not saying the person(s) who wrote that is(are) lying. It's just that it doesn't seem to come from someone with authority to make decisions like that or even from someone well informed about the global strategy of the corporation.
To me "Arduino Team" is just a bunch of hopeful or even naive employees.
> It's just that it doesn't seem to come from someone with authority to make decisions like that or even from someone well informed about the global strategy of the corporation.
Arduino is owned by Qualcomm, Qualcomm is known for being litigious. Whoever wrote that note, unless it was the CEO of Qualcomm, doesn't actually call the shots and if tomorrow the directive comes from above to sue makers they will have to comply.
Now, I imagine the bias pushing everyone to learn on arduino is even more intense? Who out there is programming these chips in pure C using open source compilers and bootloaders?
Edit: Of course there's other platforms like Esp32; teensy; seed. But I've only programmed Esp32s using the arduino dev environment. Are there other good ways of doing it?
The gcc-arm-none-eabi toolchain is pretty much what you are asking for at least for ARM targets. You can literally use a text editor and gcc-arm-none-eabi, that's it.
And if you want something really bare bones avr-gcc still targets the whole atmel family including those ATtiny chips which are also a lot of fun.
I don't know the state of it nowadays but 'Mbed' is probably worth looking into. The project had _a_lot_ of Middleware libraries to abstract hardware, a few levels below, makes embedded development a little less datasheet dependent, specially if you are just hacking something as a hobbyist.
If I were putting teaching materials today - I would pick something like Micro python. The down side is it isn't as "canned" a solution, meaning there might be something new to figure out every so often. Which means you spend more time helping people trouble shoot why something isn't working, instead of teaching something useful. On the up side, Python is pretty much the introductory language of choice, today. With lots of available materials.
That's not to say Arduino was perfect. Far from it. Just easier to do, and more consistent over time, than other options.
Everyone using Arduino, for a start.
I'm working on an ESP32 project right now, and Espressif provides shrink-wrapped toolchains for C/++ and Rust. The latter even comes with a little tool called 'espup' that cleanly installs their fork of Rust and LLVM (for Xtensa support) - I was able to compile and run a blinky in less than half an hour.
See https://docs.espressif.com/projects/rust/book/ - it also wasn't too hard for me to whip up a Nix Flake with the same toolchain, if that's your jam.
I started playing around with ATmega/ATtiny around 2008, and from what I remember, there were plenty of tutorials and examples out there.
I remember that AVR and PIC were two popular options among hobbyists at that time, but I started with AVR since it was easier to get the programmer, and it had a lot better open source tooling.
Well you can use PlatformIO/VSCode and the ESP-IDF.
If you're ok with the Arduino 2 framework, then you can use PlatformIO as well. Unfortunately Arduino 3 support isn't there yet so a lot of libraries like HomeSpan won't work on PlatformIO at the moment.
https://github.com/platformio/platform-espressif32/issues/12...
> 1.1 The Site is part of the platform developed and managed by Arduino, which allows users to take part in the discussions on the Arduino forum, the Arduino blog, the Arduino User Group, the Arduino Discord channel, and the Arduino Project Hub, and to access the Arduino main website, subsites, Arduino Cloud, Arduino Courses, Arduino Certifications, Arduino Docs, the Arduino EDU kit sites to release works within the Contributor License Agreement program, and to further develop the Arduino open source ecosystem (collectively, the “Platform”). The use of the Site, the Platform, and the Services is governed by these Terms including the other documents and policies made available on the Platform by Arduino.Certifications, Arduino Docs, the Arduino EDU kit sites to release works within the Contributor License Agreement program, and to further develop the Arduino open source ecosystem (collectively, the “Platform”). The use of the Site, the Platform, and the Services is governed by these Terms including the other documents and policies made available on the Platform by Arduino.
That list in 1.1 isn’t an exhaustive definition which is IMO, one of the causes of the fire. Again, "IMO", the list is an illustrative set of examples as there is no limiting language like "solely" or "only" and the clause even mixes services and purposes, which again signals it’s descriptive rather than definitive.
Saying that, whilst the list inside the definition of "the Platform" is illustrative, the category it defines seems scoped to Arduino-hosted online properties which could be argued is the intent. But its an argument alas...
Either way, ambiguous policy is being communicated by these T+C updates and that is a real problem.
Not a lawyer obviously - but lets see how this plays out.
"But Arduino isn’t SaaS. It’s the foundation of the maker ecosystem." is a giveaway, but the whole set of paragraphs of setup before that is chatgpt's style
That said, I definitely have some severe reservations about the path that Arduino is on, especially given Qualcomm's history. Old aphorisms like "The leopard doesn't change its spots", and "the apple doesn't fall far from the tree" weigh heavily in mind right now. As does the parable about the scorpion and the frog.
> This means Qualcomm could potentially assert patents against your projects if you built them using Arduino tools, Arduino examples, or Arduino-compatible hardware.
Yep, the complete opposite of "open".
License: GNU Affero General Public License v3.0
Who does the fork? Paging e.g. Adafruit and Sparkfun.
I wouldn't be where I am if it wasn't for Arduino. Thank you to the OSH community for making these boards open to all back then.
Nonetheless, this looks like another step toward robbing everyone of something useful and reducing our options... not to mention encouraging others to do the same thing. Depressing.
39 more comments available on Hacker News