Is Arduino no longer open-source? | Hacker News Reader

Is Arduino no longer open-source?

lists.oshwa.org

358 pointsptorrone147 comments

Having worked in the Open Hardware community for a while, I think the most important part is:

PDFs are not considered design files https://www.oshwa.org/definition/

If you apply this rule, you can exclude 90% of the "Open Source/Hardware" products on the market.

Also 99% are missing a BOM (Bill Of Materials). That's like shipping an open source software without the config files, forcing the users to figure out the settings by reading the sources. Unless they are buying the pre-compiled binaries from the author.

> PDFs are not considered design files https://www.oshwa.org/definition/

This is a very good point!

BTW, in that sense most Creative Commons work is not "open source", either.

For example, a typical Creative Commons video that is just released as webm or mp4 can only be remixed, but not improved upon - which would require access to the raw video material, raw audio material and the project file of the used video cut program.

Same for CC music distributes just as mp3/flac/opus, you'll need the samples, notes, music cut program file, and so on. One notable exception are tracker files (mod, s3m, it, ...), and in some sense also the MIDI files (as long as you have access to all instruments).

The definition from OSHWA is tailored for hardware. OSI has the authorative for software.

But yeah, music and graphics frequently also don't include the actual 'source' - just a rendered output. This is way better that having a propiatary license on the output, but does not fulfill the full potential.

Some of it has to so with the tools and proceses, which frequently aren't really built to make collaborating on the source materials easy. And often the formats and tools used are proprietary. Freeware VSTs abound for instance...

Perhaps a key difference is that OSHWA isn't authoritative.

OSHWA are the FSF of hardware. As far as they're concerned, only their certification constitutes open hardware. Everyone else is wrong. Sound familiar?

As someone else pointed out, a lot of people don't provide BOM files, including people who have OSHWA certified hardware.

I'm glad for this inclusion, will reference it in the future. My pet peeve is people releasing only STLs of 3d-printed parts or DXF for lasercut/CNC, with no project files. Unlike music, these are 'functional' works which I may need to adapt to be suitable for use. Many times it is doable to recreate the project in my CAD software, but this does not scale.

Only releasing STLs is rough!

It's worth noting that there are exceptions though: https://www.blender.org/features/projects/

PDF lose too much information to be used as CAD input ?

Try to compile gcc from a gif of a screenshot and see how far you get.

Which ML training set data should I use to infer new applications from screenshots?

hmmm... MNIST will get you digits...

You jest, but actually, it might be an interesting problem to try to recreate program source from OCR'ed images. Using surrounding context, and then analyzing program flow, it might be possible to correct the inevitable transcription errors. The problem is just constrained enough to be interesting research.

OCR is good enough nowadays I cant see it having an issue with code screenshots - it's generally unstyled except for color, and in a fixed-width font.

Simply doesn't include enough data at the necessary format/units. PDFs are for printing and reading, not building.

For simple circuits it's fairly straightforward to recreate in a CAD tool.

The minute you get more than dual layer, things get hairy in a PDF. Also you can't really send PDFs to fabs to get boards built, as they miss info that you need in order to make a PCB.

My colleagues have developed a "spitting noise" ritual after any utterance of the word "Arduino" (<hock> ptui). As embedded developers attempting to teach others, they're not enamored of Arduino's burgeoning, and dominant, market of "people who want to do embedded development but not learn anything about embedded development" sucking up all the oxygen. I know, that's an oversimplification, but not as much of one as I could wish.

I don't want to wish anyone ill, but the emergence and success of competitors that don't go so far out of the way to hide the complexity (and the need for good practice) of working with embedded systems and SBCs, wouldn't be such a bad addition to the ecosystem.

(As one of two developers who actually fool around with Arduinos and Pis a fair bit (although I detest the Arduino dev environment and 'sketches'), I'm tired of all the vandalism and graffiti in my cubicle, TBH).

Lets view what your saying through another lens:

My colleagues have developed a "spitting noise" ritual after any utterance of the word "PC" (<hock> ptui). As MAINFRAME developers attempting to teach others, they're not enamored of PC's burgeoning, and dominant, market of "people who want to do COMPUTER development but not learn anything about MAINFRAME development" sucking up all the oxygen. I know, that's an oversimplification, but not as much of one as I could wish.

I don't want to wish anyone ill, but the emergence and success of competitors that don't go so far out of the way to hide the complexity (and the need for good practice) of working with COMPUTERS systems and MAINFRAMES, wouldn't be such a bad addition to the ecosystem.

(As one of two developers who actually fool around with PC's and APPLES a fair bit (although I detest the APPLE dev environment and 'PRODOS'), I'm tired of all the vandalism and graffiti in my cubicle, TBH).

Am I suggesting that this is going to be how things turn out? No probably not. It baffles me that many people who code, have little to no understand of their mainframe roots and commit sins that were solved ages ago. However some of this reaction is to the simplification and replacement of technology with things that are more affordable and more in reach even if they aren't the same.

There's another plane on which the analogy fails: the first generation of PC enthusiasts were working with a genuinely new thing. The consumer/hobbyist-grade hardware that the introduction of the 4004/8008/6502 made possible was quite literally impossible only a few years prior. And there was good competition (OK, we Apple ][ folks despised the 'Trash-80', and everyone looked askance when the Commodore 64 with its glitzy marketing toward people who didn't even own soldering irons showed up, but we peripherally recognized each other as factions of the same tribe, and there were options).

Neither of those things is true of the Arduino. I learned how to design simple control systems on Microsequence Controllers ancestral to the AVR more than thirty years ago. And the techniques I learned there still apply to the more sophisticated chips available now. Even the hobbyist platform stuff isn't new. I was wire-wrapping DIP 650*'s into perf-board in the early 1990's, and I built an HC11 model rocket launch controller for my kid the better part of two decades ago. And I know more than a dozen people, not all of them professional engineers, many with only two-year college diplomas who were doing sophisticated hobbyist projects well before the turn of the millennium.

The Arduino isn't analogous to the Apple ][. We had to learn how to program in BASIC and needed to know what a memory map was. It's analogous to Windows 95: a well-engineered product that completely dominates the market, establishes that you don't really need to know anything, and stifles innovation.

> stifles innovation

I'm really curious about this - what innovation does Arduino stifle?

From my position with some school level dabbling in embedded, it seems like the industry is quite healthy and that there is a lot of innovation happening in terms of hardware outside Arduino, especially on the commercial side of things, where the perception is that Arduino has next to no market share.

I disagree. Arduino was new because of the scale of its distribution. I built robots with Basic STAMPs in the early 2000's so I know there were prototyping platforms before, but they never took off in the way that arduino did.

And the openness of Arduino was critical to starting my own company, when I built an Arduino compatible board with a fast processor and wireless radio.

One could argue computers weren't new - we had vacuum tubes for ages. But it was putting it all together in a certain way (and the associated maturity of certain tech) that led to a step change in what those things meant.

For me, arduino similarly created an explosion of hobbyists working with circuits for the first time, and I'm happy that people who know very little have something to work on. But I am sad that the openness has been falling by the wayside.

I'm sorry, but I fail to see how a product that makes it not just easier, but possible in the first place for people to work with embedded controllers, is "stifling innovation."

+1 for ProDOS

I've been all over the map on this issue. I've hand-assembled 6502 code, written assembly language for PIC chips, and C code using Microchip IDE. I've hand-wired my own development boards, that I etched myself.

Today I use the Arduino IDE and one of the Teensy boards. I doubt I'd be happy with that setup for large projects, but it's perfect for what I'm doing right now, using the microcontroller practically as a glorified GPIO for a PC. You can use "pure" GCC to program the Teensy, but I'm not sure that I need to care at this point.

For the general population, I just like the idea that the Arduino and RPi ecosystems have practically revived the electronics hobby, and expanded the number of people who are interested in getting into programming. It's still a hobby, but it's a great hobby, and I admire hobbyists.

I understand your point, but there is a good middle ground for people. As a software developer, I was amazed the first time I connected a LED to the RPi's GPIOs and made it blink with software. From that, I moved to an Arduino, with its Lego style shields, and to an ESP8266 and my own PCBs.

I don't think the Arduino is just for people who don't want to learn anything about embedded. Those people exist, but it's good that they can do stuff with hardware without learning. The people who do want to learn, will learn faster with the Arduino ecosystem than without it.

That said, the Dev environment sucks, PlatformIO all the way.

That's a fair point, (and +1 for PlatformIO). And that is sort of the argument I sometimes find myself making: the Arduino Hardware is delightful. It's the ecosystem that has emerged around hobbyists that is problematic. It may just be early teething pains of something that will become remarkable. But right now, we find ourselves spending a lot of time walking back bad habits and lack of understanding of fundamentals when students show up with "projects" that involve a "schematic" that is really just a photograph of a breadboard, and the introduction of complex parts without ever consulting a data sheet, based on random code just pulled down over the Internet. And I've seen commercial products that are at about the same level of quality. The problem may be that Arduino is too forgiving.

s/Arduino/Node.js/g

It's exactly the same problem. These platforms make it really easy (too easy?) for people who don't really know what they are doing, to quickly build up something that is functional, but without then understand the underlying concepts. Grab this library, copy and paste from this tutorial, change a few lines and boom! You have a blog or IoT weather station.

And that is bad because?

That's bad when have tons of connected buggy, unsecured devices powering botnets. Not that I blame hobbyist for that, but such mindset that "hardware is easy" should not prevail.

The thing is, if you wait till you know things to start learning, you will not learn at all. This is quite visible in programming - people who assume "it is complicated" or try to learn all basics before doing things have low changed of becoming programmers. Whether they came to that conclusion alone or someone gave them that advice, "don't do stuff until you know what you are doing" is bad advice for students.

It also filter out precisely the people who tend to listen to advice.

Meanwhile, people who confidently do crap despite not knowing anything, make mistakes in the process, but can eventually learn to become good.

Mistakes are fine, and expected as someone is learning, but when you put something out there that has severe security problems, that's... a problem.

I don't have a good solution to that. Certainly a lot of the frameworks out there have security bolted on as an afterthought, or, at best, just don't make it easy to build things that are secure by default.

But ultimately it comes down to the author of the code to take responsibility for the security of the code they throw out there and promote as something people should use. And that's the crux of it: I want people to experiment and learn, but there needs to be a way to keep those sorts of people from building (or perhaps just distributing or promoting) things that (unintentionally) harm others, at least until they're knowledgeable enough to avoid doing that.

It is surprisingly hard to find good advice on how to code securely beyond absolute basic advice. And a lot of it even bundled in things that are good engineering/process (use linter, code review), but lead to security only indirectly. Code review wont make code more secure if reviewer does not know what to look for when doing said review.

The way it works is that general advice I have seen many times is "don't do it". Finding how to code securely or comprehensive list of insecure patterns is much harder. So, people inclined not to follow advice and the ones with huge ego are the ones attempting to create security related software.

I am not saying that I have instant solution, but strategy of discouraging people from trying does not work well. Promoting good beginer level write ups would work better.

----------

Nevertheless, the original topic was arduino and doing circuits while being unable to read schematic. That is seen as a problem, because they did not learned theory before doing 5V dummy circuits.

And I think it is as good start for learning or getting interest as any.

"Finding how to code securely or comprehensive list of insecure patterns is much harder."

The problem is not only secure coding, actually, I'd argue that it's not even the biggest concern. You can produce the most secure code on the whole world, but that won't matter if your device has an unprotected or easily brute forced telnet access by default. Loose default security settings and permissive access is the key concern imho.

If you want to learn how to secure software then learn how to hack. It will give you an insight into the tools and techniques used to breach systems and especially give you an insight on how many attack vectors there are.

Kali Linux and the tutorials for that are the Arduino of hacking.

I'd suggest that upwards of 95% of arduino projects are not accessible via any kind of network connection.

Also that around 95% of arduino projects are useful in educating & encouraging people around small microprocessor / electronics projects.

Lol...there are ALOT more buggy , unsecured devices on the internet that are made by companies with "professional" programmers. Look at the crappy DVR's and Webcams coming out of China, not to mention the buggy and perpetually exploitable software that companies like Microsoft and Adobe produce ( and sell for profit) I agree that inexpensive and easy to use developer boards make it easier for a hobbyist to screw up, but the things that are doing the most damage on the net are not hobbyist items.

It's bad when people that don't really understand what they're doing release products, but I didn't know that was the case with Arduino. I've used it for learning/prototyping without ever having any intention of creating the final product with it (or at all really).

I've made the argument that the Arduino is great for quick and dirty projects (a colleague builds stuff for Escape Rooms that only ever exist for a few months using them), and for trying out ideas when you already know what you're doing. They're less valuable as a tool for learning that stuff, if only because of the Wild West nature of the ecosystem.

Learning by experimentation is a perfectly valid way of learning. You can't force people to learn in depth but, if you want to, there's no problem gradually deepening your understanding over time by trying stuff and thinking about it.

That hasn't been my experience. In fact, I spent months finding an appropriate MOSFET to drive some LEDs because the random ones I spent a month waiting for couldn't switch fast enough. That taught me right quick to read datasheets to make sure I get what I need.

These days, however, I recommend the ESP8266, not so much the Arduino. You lose the shields' flexibility, which may put people off with the steeper learning curve, but you gain a lot in capability.

The problem may be that Arduino is too forgiving.

Isn't that the same argument for using xml over html?

It's the same argument for putting Republicans instead of Democrats on the bench. Whether or not you find that argument compelling doesn't really affect whether you find another one similarly structured to be similarly so.

> As embedded developers attempting to teach others, they're not enamored of Arduino's burgeoning, and dominant, market of "people who want to do embedded development but not learn anything about embedded development" sucking up all the oxygen.

I don't think oxygen is the finite resource your colleagues think it is in this metaphor. Why in the world would they not want something that lowers the barrier to getting more people involved with things like embedded development? Some of those people may even go on to start learning more about embedded development. It's so much better than keeping the barrier to entry high, thus discouraging people to get into it and learning more about how the world around them works. Would we rather people continue to have no context about what we do and treating electronics like a black box?

And who cares if they don't actually want to learn more than they need to about embedded development? Just as your colleagues spent their lives becoming experts and doing embedded development for a living (I'm presuming), others chose rather to spend their careers elsewhere. Everyone has different priorities and tradeoffs to consider vying for their time. Any time we can allow people to accomplish more with less, possibilities open up with the time we do have.

"Embedded developers" are really not Arduino's target audience. It's always been a platform for expanding the market of electronics hobbyists some of whom go on to learn more of the underlying chip features if they do something more serious.

On the other hand if you are in the business of selling embedded development education to newbies, then you need to realize that Arduino is outcompeting you - like iPhone destroyed the old Windows smartphones.

The old Symbian* smartphones.

Just a detail, I know, but as far as I remember, I changed few Symbian devices before the iPhone came out and I hopped over Android soon after.

I can't really recall there being any Windows phones back then. This is just how popular Symbian was in that period of time. If there were any Windows devices (forgive my ignorance), they were definitely not nearly as popular to make a mention of iPhone killing them instead of e.g Symbian ones.

Just my 2¢, but the crux of your argument doesn't change, so you got a +1 from me for it. :)

What about "Pocket PC"? I remember the Compaq IPaq having a high profile back then (2001).

Edit: maybe a more valid example is the O2 XDA "Windows Mobile" phone/PDA (2003)

> sucking up all the oxygen

Could you say a bit about what you mean by this? It's not at all clear to me why it matters to those who do "real" embedded development that there are hobbyists out there using a simplified platform (and, yes, perhaps developing some bad habits).

This is not to say I disagree, necessarily, that a competing platform that better introduces users to the complexities of embedded systems would be a bad thing. Though I'll also add that, as someone whose day-to-day work is very from from embedded development (I'm a lawyer), the Arduino platform has been great for leading me slowly into this world. I'm still a newb, but I've learned far more about embedded systems (and electrical engineering) than I think I ever would have otherwise. Personally, I think Arduino is a great way to learn both the basics and the complexities--you can accomplish something in a "rough and ready" way very very quickly, and then incrementally delve into the complexities as your interests (and needs of your project) demand.

As a software developer who has been doing hardware for a while I have to say I'm both unimpressed with the toolchains for embedded and the kind of software developers produce. Honestly: it is like you shed 30 IQ points and went 25 years back in time.

Of course embedded sucks and is hard: people think this brittle, shitty mess is a sign of cleverness and that this is how it should be.

Don't shit on Arduino for being old tech and attracting the plebs. It contributes to increasing the size of the audience which might in turn mean the embedded world becomes more professionalized when it comes to software. Because it sure as fuck is no fun to rewrite stuff all the time because the embedded industry tends to hire shit software people.

If something looks stupid but does the work, it's not stupid.

Ha, I bet that is annoying to deal with. The things are fun, but they are basically toys.

The answer to the question if these products are open source, the answer is: no.

Here is my blog post from more than 2 years ago regarding the status of the Arduino Yùn:

http://www.wifi4things.com/arduino-yun-what-is-under-the-hoo...

And here is my clarification request on the Arduino forum, which is still unanswered:

http://forum.arduino.cc/index.php?topic=187766.0

I would be interesting to know if this is due to their Kramer-vs-Kramer situation or it is simply their new policy.

I would say that the Betteridge's law of headlines has been proven once again by this thread, but this is no article and the headline here seems more click-baity than the actual subject line of the thread.

The answer to your parent comment's question is "no", but their question was the inverse of the post's title.

So, this actually is an exception to Betteridge's law; the answer to the question is "yes, arduino is no longer open source".

Hopefully I can provide a bit of insight on this, currently working on open hardware myself.

OSHW certification is a self-certification process. Individual products are certified, not companies. What Torrone is doing is conflating Arduino the company (or foundation, or companies, or whatever it is this week, guys please stahp) and Arduino the product series, and individual Arduino products. He knows what he's doing, but in this email does it anyway. Perhaps for good cause, but it's what he's doing.

There is no requirement for Arduino to certify all of it's hardware with OSHWA. In fact given the explosion of things-that-are-branded-arduino it would be unsurprising to see hardware that cannot be certified as open due to commercial agreements that override open licences. Whether this affects Arduino or not long term is a different matter but the Uno, Nano and Pro Mini are all still open.

OSHWA is an attempt to define what constitutes Open Source Hardware and to define some (hopefully) sane defaults. It's the hardware equivalent of the FSF, and it's licence is the maker equivalent of the GPL. It is not the only fruit.

My project[1] uses the V-USB library, which comes with an open licence[2]. The project is derived from another project, the digispark[3]. We're operating within the licence constraints, and consider our project to be open hardware (we're posting our board designs when we ship at the end of this month).

To further complicate things, when Arduino uses the term Open Source it rarely clarifies what that means. It may be referring to the software stack. It might be (but probably isn't in this day and age) referring to new hardware.

Either way, while it is right to pressure Arduino to clarify their position, I think it's unfair to mandate that every product they ever produce must comply with OSHWA's definition of Open Source Hardware, or that only OSHWA certified hardware can be considered "open hardware".

[1] - https://hidiot.com/

[2] - https://www.obdev.at/products/vusb/license.html

[3] - https://digistump.com/

The OSHWA requirements for compatible open hardware licenses [1] seem to allow for permissive open source licenses, similar to Apache 2.0. Attribution may or may not be required. Derivative works are required to follow the terms of the original license, but there doesn't seem to be a default requirement "share-alike".

[1]: https://www.oshwa.org/definition/

I think the Arduino civil war is inevitably going to lead to ESP8266/NodeMCU boards taking over this market.

I didn't know about the Arduino civil war until now but man I love my bag of ESP8266s. Just having them is inspiring. I whipped up a DIY star tracking camera mount with one last weekend on a whim. So fun, so easy, so cheap.

Any chance you have a write-up on that? That sounds awesome!

As a matter of fact I do!

https://partofthething.com/thoughts/?p=1327

Thanks for asking!

That's really well written and presented. Thanks for writing / sharing it.

Thanks for saying so! As you can probably tell I had a lot of fun writing it so I'm extra glad you enjoyed it.

I just want to mention that you are awesome.

Very cool! Thanks for doing a write-up!

This looks like a ton of fun!

What counts as "open source"?

We often run (open-source) Linux on a (closed-source) Intel processor and even a lot of diehard FOSS warriors are okay with that.

Arduino Unos are a bunch of (open-source) wiring and components plugged into a (closed-source) Atmel microcontroller and people seemed to be okay with that.

How does an ESP8266 differ from an ATMega in this regard? If we consider it a basic component just like the ATMega, it's not particularly any different.

I'm certainly not okay with having to use a closed processor to run my software. I'm longing for an alternative. Hopefully RISC-V will show some buyable results.

This question comes up a lot.

It doesn't mean "open source all the way to the materials mined."

It means "open source to what I used to produce this.*

Such that another person could replicate your work.

Sure. But just like one could source an ATMega, one could source an ESP8266 and replicate the work. It's an easily-available drop-in component. So I don't actually see anything inherently different about the new crop of Arduinos from what we had before.

According to the mail, this is about board schematics and source code for pre-burned firmware.

My comment was less about FOSS actually. I think it has more to do with the branding of Arduino. When people think educational or approachable microcontrollers, they think Arduino. As soon as that gets muddied a bit, I think folks may see that there are much better alternatives, and will shift to that.

The ability to do a custom board with the microcontroller and your custom peripherals is key for doing a production run. Open source lisenced source files for the board makes this very easy.

The times where making custom silicon is desirable is way more rare. But hopefully open-source will be standard there too, one day.

ESP32 development boards are also very impressive. And the prices are dropping every month. Can't wait to see that ecosystem evolve.

Same goes for STM32 (ARM Cortex-M) hardware. Actually, the prices have already basically hit rock bottom. :) You can get a STM32F103C8T6 (72 MHz, 20 KB RAM / 64 KB flash) on a development board for under $5, and a programmer/debugger for about the same price.

ESP32 advantage is having 512 KB, back to the PC1512 days, just being multi-core and having network access. :)

And Espressif got their act together this time and are working on a good and open-source SDK (ESP-IDF).

I just tried it out this week to make battery powered wireless temperature and humidity sensors. Sleep current for the whole system is not that great (~80uA of which 40-50 are used by ESP32 module). However, the simplicity and ease of use outweigh having to charge the battery every 3 months (3Ah li-ion cell).

30-40uA with only the ULP running?

Now that you're asking- I don't really have an answer what exactly remains powered on. I have seen reports of people achieving sub-10uA sleep currents, so my result could be improved by a factor of 2 (LDO I put on board has Iq of ~40uA).

I haven't looked really deep at what power modes are available for each power/clock domain- at the moment I just have the ESP waking up from RTC timer every 15 minutes and it can also be woken up manually with GPIO. It's entirely possible that I have left some peripherals at non-optimal state.

I see. I haven't explored the low-power states yet, the datasheet says 5µA is possible using hibernation and timer-controlled periodic wakeup. Was curious if those numbers are achievable.

On the ESP8266 I was able to get down to 16.3 µA deep sleep current.

A lot of easy-to-use modules come with a USB-serial converter and a 5v-to-3.3v converter. These will draw a few microamps even when there's no USB connected - and depending on the precise hardware, some will draw far more than that.

You should plan on buying a few different modules and de-soldering a few components if you want to achieve the absolute minimum current consumption :)

I don't have any use for them, already enough side projects as it is, but the technical specifications of ESP32 are great.

It is like having a PC1512 that fits on the pocket, there are already lots of programming languages that would fit on it.

There is no source code either for the WiFi stuff in the ESP8266.

That has yet to be an issue in my experience.

It's been an issue for me. I wanted to make a battery-powered sensor that would only enable the wifi hardware when the sensor had changed (to maximise battery life) - but the closed-source firmware means that's not possible.

Also, some of the SSL support is in the closed-source firmware, and it's incompatible with Mozilla's 'Modern Compatibility' ciphersuite list.

I used the ESP8266 anyway - it's not ideal, but for my application it was the best thing available. There's room for improvement, though.

Not exactly the same market as Arduino, and it'll continue to matter about as much since semiconductor manufacturing isn't getting any cheaper.

You know what I'd love to see? An Espressif with a gaggle of RISC-V cores in it. I don't know how much they pay Tensilica. I think they could do a lot with that.

Xtensa is a bit of a mess on the toolchain side, seems to require compiler flag customization for any given model, or it might not even run. For example, endianness is configurable at the architectural level.

Or mBed. Look how many boards they support:

https://developer.mbed.org/platforms/

Some are very cheap, e.g. the Nucleo ones:

http://uk.farnell.com/stmicroelectronics/nucleo-l432kc/dev-b...

The Star actually has an 8266 on it, oddly.

To me it feels like Arduino (both sides) has been trying to recapture lightning in a bottle.

The Star is also vaporware. It was announced over a year ago, and is still not available for sale.

The Tre was in the same situation for a while. It's no longer even listed on their products page...

I started with arduino a few years ago as a hobby and loved it as an easy way to get into the field but lately I have been realizing how many terrible habits I've obtained by learning this way. It took me weeks to retrain my brain to prefer looking at schematics instead of the breadboard views and I'm still trying to learn atmel studio and directly programming chips. It's coming along but slowly.

I still think arduino is a great way for interested people to break into electronics but there is no clear 'line in the sand' when they should stop learning that way

Do yourself a favour and just use 'make' and 'g++' directly, ignore the Arduino wrappers, they're just toys that hamper you after a while.

How?

The wrappers are slow. I have a project where I need to sample data at 50kHz and update at 5kHz, 14-bit output. Can't do it with Arduino's syntactic sugar.

The IDE is terrible for large, multi-file projects. It just doesn't have the level of integration of, e.g., Visual Studio (that Atmel Studio is based on).

It's a fantastic beginner tool and a great source of ultra-cheap hardware, but the IDE runs out of steam pretty quickly.

The Eclipse CDT guys do support Arduino devices.

http://www.eclipse.org/community/eclipse_newsletter/2017/apr...

Don't forget, avrgcc can generate hex files for atmel chips without dragging a whole IDE around.

I'm a novice when it comes to Arduinos and stuff, but I second your suggestion for using the avrgcc toolchain instead of the Arduino IDE.

I tinker with Arduinos and Arduino-likes that have the atmega32u4 chip with built-in USB controller, write the firmware in C with the LUFA library providing USB support, avrgcc to compile, and avrdude or dfu-programmer to flash.

Maybe there should be a button that dumps out your project as .cpp files and a working Makefile... It's not hard to take your arduino source and figure out which #includes are being hidden from you, write your own Makefile, etc if you already know what you're doing, but if you don't know what you're doing and try to stick your Arduino code into gcc, you're trying to learn with something that started broken.

Good questions on AdaFruit's side. I am interested in knowing what is the result of this inquiry.

Also relevant: http://hackaday.com/2015/03/28/arduino-srl-to-distributors-w...

http://hackaday.com/2016/10/01/arduino-vs-arduino-arduino-wo...

Creators do not like to follow rules. Avoidance of a bunch of nitpicks is probably the only way to motivate them.

IMHO, it is not a war, just a childish fight that is mostly positive.

3/5 of the boards mentioned here have not actually been publicly released as far as I can tell (Primo, Star Otto, Star LCD).

You cannot remove the open-Source from something that was previously open-source. I'm pretty sure its a one way street.

Once you've licensed something as open-source and published, that version with that license will always be there. You could take a future private version of the thing (assuming no code contributions) and license that differently.

Wouldn't it have to be rebuilt from scratch? I thought that any program containing open-source code must also be entirely open-source, at least with most common licenses.

no. If you're the sole contributor and have copyright, you can relicense the code however you like. You can't travel back in time and relicense the prior versions so they're no longer open source, but you can certainly control how future versions are licensed.

If you have copyright.

Well, except that gratuitous licenses are (irrespective of their surface terms) revocable at will. Promissory estoppel may mitigate, in some way, the effect of such revocation against people who took action in reliance on a promise of nob-revocation before or without knowledge of the subsequent revocation, but it is far from clear that the Free version will always be free; license terms don't override the governing law.

(Now if there is a Free version under a contracted-for rather than gratuitous license, that's a bit more secure, though there are ways that could go away, too.)

Do you have any court cases to back this assertion? The GPL is the license of millions (maybe billions) of lines of code. We've all bet on them being non-reversible on released code.

Given the way Linux is copyrighted (with many holders), it'd be an absurd situation if any copyright holder could just decide, after the fact, that they don't want their code being distributed under that license anymore. In fact...I think that's been litigated in SCO vs. IBM. So...what are you basing your legal theory on here?

The closest case seems to be a Mattel court case involving their CyberPatrol software and a program by Eddy Jahnsson and Matthew Skala called cphack. It raised the issue of whether a GPL license could be withdrawn. However, the case was such that no definitive legal conclusion came about. (I was shocked to find that Googling directed me to something I wrote 10 years ago :-) https://www.cnet.com/news/revoking-open-source/)

However, the widespread assumption is certainly that it doesn't require a contributor license agreement to keep this whole open source thing from crashing down. Which it would if an arbitrary developer could threaten pulling out their code from some project N years later. In today's climate, it's pretty reasonable to assume that if no one has pulled that sort of blackmail, no one thinks it has legs.

> Given the way Linux is copyrighted (with many holders), it'd be an absurd situation if any copyright holder could just decide, after the fact, that they don't want their code being distributed under that license anymore.

Even leaving aside general issued on the revocability of licenses that aren't special to copyright law, the US has a special provision making all licenses and transfers of rights by authors under copyright revocable by written notice, during a 5 year window 35 years from when they occurred; see 17 USC Sec. 203.

> So...what are you basing your legal theory on here?

The general American (Anglo-American, I think, as I'm fairly certain the principle is a common law one which is older than the US) of licenses.

17 USC Sec. 203 also covers derivative works and the fact that they remain distributable under the original terms (though future derivative works are up in the air if your interpretation holds water, which I still don't really buy).

Further, revocation of copyright on works with multiple authors must be signed off on by a majority of copyright holders, per the law you've cited. That's literally impossible with something like Linux (but maybe not with something like Arduino, if it only has a tiny number of authors, I don't know).

If it's so simple and obvious, why has it never happened in 30+ years of GPL software, when billions of dollars are at stake?

"The general American (Anglo-American, I think, as I'm fairly certain the principle is a common law one which is older than the US) of licenses."

Many things in "common law" have been replaced by written legislation and case law. Modern copyright bears no resemblance, and only has only tenuous connections, to common law. Copyright is among the most debated and litigated categories of law in the modern world, with legislation, legal precedent, and even international treaties covering it. If your position is that it is as you say because common law is as you say, that just sounds really shaky. Now, I need to ask you to back up the assertion that "common law" is the law in force on copyright in any developed Western nation, because that seems to be the crux of your interpretation of the law.

I don't know, man. I'm not an expert, by any means, but I'm just not following your reasoning here, at all.

My understanding of the GPL is that it is a one way street for released code. New releases can be under a new license if all of the authors agree to it, but once something is out there under the GPL, it is always under the GPL. Nothing you've said makes me think otherwise because the weight of precedent seems to disagree with you.

the US has a special provision making all licenses and transfers of rights by authors under copyright revocable by written notice, during a 5 year window 35 years from when they occurred; see 17 USC Sec. 203.

Wow, that's rather incredible. It's enheartening to see a US copyright law that seems biased toward authors rather than publishers.

The provisions of section 203 safeguard[] authors against unremunerative transfers. A provision of this sort is needed because of the unequal bargaining position of authors, resulting in part from the impossibility of determining a work’s value until it has been exploited.

http://www.sfwa.org/2013/08/second-bite-apple-termination-ri...

This is true. There have been many many many discussions over the years as to whether open source licenses are gratuitous. The general view (i'm just trying to sum up all the posts on all the open source counsel and legal networks i belong to in a few sentences, sorry!) is that the vast majority require at least some consideration (even in the form of attribution) in exchange for the rights they offer.

As far as i'm aware, legally, giving attribution attribution in exchange for a thing has been held to be plenty consideration since nearly the dawn of time.

(Even giving up the right to sue for warranty claims would likely be sufficient consideration, but no open source license explicitly says that, they just disclaim there are warranties, which is not quite the same)

There are some that are significantly more problematic. WTFPL is a good example of a maybe-gratuitous license.

Common ones have clear consideration (agreements to do certain things with your patent rights for downstream users, etc).

I have not yet found anyone who believes you would have a strong argument that most open source licenses are gratuitous.

Agreement to do a thing you didn't have to do (give attribution, include a copy of a license, whatever) in exchange for something, is plenty consideration.

On what do you base this claim? If you grant rights to someone, in what legal way can you simply revoke those rights?

Real question. I am not a lawyer, but would assume arbitrary revocation would essentially be a breach of contract. (But I guess it's not technically a contract since it's one sided?)

> On what do you base this claim?

The law governing licenses (of all kinds.)

> If you grant rights to someone, in what legal way can you simply revoke those rights?

If the grant is gratuitous (not contracted for) you generally have no legal obligation not to simply revoke those rights (it is exactly the same case as inviting someone into your house and then ejecting them when you decide they've worn out their welcome, which is also a case of gratuitous license.)

> Real question. I am not a lawyer, but would assume arbitrary revocation would essentially be a breach of contract.

Right, if there was a contract, then revocation inconsistent with its terms would generally be a breach, which would still least present a cause of action for damages and may permit an equitable remedy extending the license.

Most F/OSS license scenarios are not contract licenses, and even when they are, publication with an offer of a license isn't a contract, the offer must be accepted without the offer having expired or having been revoked first for a contract to exist.

Hmm. Is there some specific case law relevant here? I'm having trouble buying into the idea that an agreement can be unilaterally rescinded and the law doesn't care.

If I agree that my neighbor can have 5 feet on my side of the property line in perpetuity and put the offer in writing, I can simply change my mind later and take it back?

IANAL but my understanding is that giving someone something is not the same as giving someone a license to use it. If you have your neighbor permission to use that five feet then yes you can revoke it.

But if you instead gave your neighbor that 5 feet then you would not be able to revoke it.

A key part of most open source licenses is that the author is not giving up ownership of the code. This is why many projects require a copyright reassignments for contributions to avoid being hamstrung by an author revoking their right to use that contribution sometime in the future.

The GPL is non-revokable: http://www.groklaw.net/article.php?story=2006062204552163

This is explicit in GPLv3: "All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met."

License terms (no matter how explicit) don't override the governing law, and in US law at least, gratuitous licenses are revocable at will; the terms stated cannot change this but may still have some effect under the doctrine of promissory estoppel.

There's also a legal theory that the GPL is, or can be depending on the circumstance of a particulsr case, a contract license rather than a gratuitous license [0], but even in that case the contract offer would be revocable, and the GPL itself only irrevocable with respect to licensees with whom a contract was formed prior to the offer being revoked (because FOSS licenses are sublicensable, that licensee could offer sublicenses to the original work, but might not, e.g., if they chose not to do any of the acts which required such an offer.)

[0] which may not actually save the day, either, since some courts have held that contract licenses are revocable, but that revocation in violation of the terms of the contract makes available damaged for breach of contract rather than compulsory extension of the license.

The GPL appears to be rather clearly a contract license when it governs the give and take inherent in shared open source development within a community. Your points regarding gratuitous licenses seem applicable where publishing has occurred but no further open source development has taken place -- and this seems largely irrelevant to concerns regarding an existing open source community.

I'm not sure why concern would be raised with respect to the original contract offer. It seems entirely irrelevant given that any participant has full rights under the contract terms.

I think is about new Arduino products not being open source. Source files for old Arduino products are still directly available.

Adafruit is not as cool as one might expect. I was sourcing boards from them and my parcel got missing from courier company. I complained to them. Initially they tried to help but nothing came out of it. Guess what they did next ? My account with them was disabled . It almost knocked my little startup off the ground. I wrote mails but to no avail.

Reply on news.ycombinator.com