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.
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.
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.
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).
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.
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."
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.
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.
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.
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.
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.
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. :)
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.
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.
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".
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".
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.
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.
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.
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.
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.
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).
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 :)
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.
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
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.
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.
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.
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.
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?)
> 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.
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.
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.
"Arduinos are shit because the people who use them aren't real programmers" is the core of the argument there. Similarly, "PCs are shit because the people who use them aren't real programmers" is a poor argument. And we frequently see "Web applications are shit because the people who write them aren't real programmers", which is an equally poor response.
There are no rules about what constitutes a 'real' programmer and a 'not real' programmer. Complaining that inexperienced people are entering a field because the barrier to entry has been lowered is stupid. Instead, we should be focussing on solving and problems that introduces: things like security, safety and scalability need to be made easier.
I was there for the first generation of the PC revolution (and my father was a mainframe programmer---he and his colleagues LOVED Apple IIs and TRS-80s). There are echoes of the conflict, but it (as always) is more complex. The problem with Arduinos is not that they're "shit" (they're well-designed low-end general-purpose embedded development platforms). The problem is that their development ecosystem and community seem to purposefully hide the complexity and detail of the hardware. Which is precisely the opposite of what the early generation of hobbyist home PC developers and engineers did --- they revelled in the (modest) complexity of their platforms and actively tried to expand it (our home Apple II eventually had to escape the confines of it's case and sported a Z-80 co-processor so we could play with CP/M, too).
I was a member of the generation that cut their teeth on those simple home computers, and they were a fantastic way to start to learn our profession. They taught us abstractions that helped us move to the next levels of complexity, and the intuitions about computers that we learned were accurate and helpful.
My argument (not really mine, I'm reporting it from others, I'm a little more on the fence) is that, while the Arduino platform could do the same thing for a generation of hardware engineers, its community (and those who hope to make money off of it) seems to be going out of their way to avoid it. People who accept the default tools and attitude of the Arduino are not encouraged to understand how microcontrollers work. They are encouraged to follow a recipe, stuff some parts into a breadboard with no understanding of electronics or awareness that a datasheet is even a thing, download code they don't even read, and start high-fiving themselves when they make an LED glow. (OK, that's a caricature too, but I've decided to give myself some rhetorical license).
I know it's not your argument as such, but I still don't really buy it.
I would wager that every engineer gets started by following recipes. I started by copying code from books and magazines into QBasic with no idea what I was doing. I started web development by gluing together magic bits of Javascript that did god-knows-what. I don't recall being encourages to understand how these tools worked under the hood.
But that's just the start; once someone is familiar with the parts (and importantly, can make something do an interesting thing quickly) then they can start making changes to that recipe, and in time writing their own.
I do a lot of tiny Arduino programs for hire. Before you go off on me, I'm an experienced embedded developer -- my current project is taking a digital input and turning it into a resolver signal for a motion controller. Fun!
The simplicity of the Arduino ecosystem means that a rank beginner can throw together a simple program that provides huge value in just a few minutes . They don't need to know the intricacies of setting up an A/D channel: they just call analogRead() and it's done. These people don't want or need to be programmers. They have a simple task to automate and they found a way to automate it and move on with life.
I have a client that I've written two simple programs for that are essentially latches: take a transient input signal and hold an output constant forever when it's received. But it's faster/cheaper to throw an Arduino at the problem than go wire up a handful of 'LS74 latches and associated hardware.
Your argument is akin to complaining that no one drives stick shift any more because automatics are too popular.
There will ALWAYS be people like that. And those people, if Arduino wasn't available and as easy as it is, wouldn't move over to writing PIC or AVR assembly. They just wouldn't be doing their projects in the first place.
And there are plenty of people who do start with Arduino, and move on. Just like with everything else.
It is not like the people who complain about these were born professional programmers. They were born babies and at some point as clueless as current inexperienced newbies.
Just because someone perceived himself to be all knowing all the time does not mean that he was objectively all knowing from the day he was born. In all likelihood, it just means lack of self-awareness.
>I know people who have worked with Terrone. His reputation is not so great either, he is an arrogant dude.
>So take this post with a grain of salt, it is part of a smear campaign that Terrone is going about online.
I could not disagree with this more strongly. I have exchanged emails with both Limor and Philip on many occasions, both are the most authentic advocates and supporters of Maker culture I have ever encountered. They are true believers and I have seen them consistently put those values ahead of business considerations.
Federico Musto lied about his academic credentials and Limor made it very clear why she took that personally:
To women in the maker movement, who are often accused of being fake geeks and frequently have their expertise questioned, Musto’s apparent lies are personal affronts. “When you go to MIT, there is always this murmur that they had to lower the standards for you,” Fried says. “And after you graduate, you get asked all the time if you were actually smart enough to have earned your credentials. It’s a little bit insane that this guy has gotten this far without ever being questioned.”
So yeah, they have every reason to shut Federico Musto down and he in no way appears even remotely qualified to be in the position he is now. That's not a "smear" campaign- that's accountability and a community enforceing it's core values.
Perhaps i'm missing something, but who cares if Musto even blatantly lied about his credentials? It's not relevant to the project, except in terms of his credibility, and hopefully there are better guards against fraud than checking resumes.
Caring about academic credentials in a non-academic (or otherwise certified) field seems exhausting, pointless, and only bolsters the military-industrial-academic complex.
Doghunter labs received funding from the University of Messina in part because Musto claimed IBM, Olivetti, an MIT doctorate and an NYU masters on his resume. This is fraud under Italian law, and now Musto -- and by extension Doghunter labs and now Arduino -- may face criminal and civil penalties.
Musto is, simply, a liability to Arduino. Yet under last September's agreement, he controls 51% of the organization.
Contextualizing that, Arduino is by far the most successful Open Hardware effort ever. Allowing Musto to continue his influence over Arduino casts a shadow over the entire Open Hardware movement.
Calling Arduino "open hardware" is a bit of a stretch. That's like calling Windows an "open source" because you can create and run your own programs on it.
In addition to the aforementioned fraud, I think it's also about the fact that this was a lie, not necessarily that it's about the lack of credentials.
>The .org people (Federico Musto) are different than the Arduino.cc people
This is false. The 'Arduinos' were effectively combined last September. [1] It's now "Arduino Holding", and the "Arduino Foundation", of which Musto owns or controls 51%.
As for the outing of Musto's academic record, I would simply suggest Torrone is looking out for Arduino, and importantly the idea and reputation of Arduino as the most successful Open Hardware project. Musto has proven himself a liability to the Arduino brand, and he controls a majority of it. As child comments have said, it's not character assassination if it's true.
Personally, I think missing Eagle files for a few Arduino boards doesn't quite qualify for not being open source. That's a due diligence issue that many more open source projects are guilty of, especially in the open source hardware world. The power of Arduino is in the IDE and to a lesser extent, the bootloader, which are obviously Open Source. However, numerous publications [2] have written about the Musto situation, pointing out the grave situation they're in, and nothing has been done about it yet.
Disclosure: I wrote the hackaday post [1]. Torrone has shared documents with me, and I spent a few bucks on Fiverr to translate Italian court docs. The situation is fucked.
I'll definitely be checking that out, but the Arduino software platform has been the real winner and there's no question about its openness - their bootloader, IDE and libraries have all done very well in the community. They've even got tools to make pulling in external libraries super simple, I'll have to check out PlatformIO and compare.
PlatformIO is even simpler, you just add your libraries and versions to your config file and it pulls them in automatically, plus it autoupdates your platforms so you don't have to. I love it.
While we're taking things with a grain of salt. I'd like to point out that this poster (ArduinoGuy) only has posts defending arduino.org. I'm not saying they're wrong because of that, but I am saying that that is at least suspicious.
> In the article where Federico Musto is reported to have faked his background, it says at the bottom that Philip Terrone is the source of the tip about Musto's educational background
That's not evidence of a "back room" smear campaign. It's the opposite of that, an on-the-record and truthful accusation.
Mm, your comments is unrelated to the issue being talked about in the email. I don't particularly care about who sent the email as much as the source code being available.
How is this a "smear campaign"? He privately contacted someone who lied to tell them to stop lying, and in response, they lied again about whether they'd correct it. Only then did he go to the media.
Is lying good now, and pointing out liars bad? Can you explain this newfangled morality?
I find it hard to take a post that accuses someone of engaging in an unwarranted "vendetta" and smear campaign that includes the unsupported hearsay alleging the perpetrator has a bad reputation and is an "arrogant dude" very seriously. It's hard to take the high road when you're digging your own set of tunnels.
The accusation is "Arduino is no longer open source", but the "proof" is a mostly a few missing license files, with a few other incomplete source submissions. No change of licenses, no new bits without sources, nothing to really indicate an actual change instead of some minor oversights.
I'm not familiar with the conflict, but this really looks like smearing at worst, and bad clickbait at best.
> I know people who have worked with Terrone. His reputation is not so great either, he is an arrogant dude.
I used to watch the adafruit streams and youtube videos. You can definitely get a sense for this in those videos. I quit watching their stuff b/c he just rubbed me the wrong way with how he interacts with the community.
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.