Copyright Data, But Do It Right

Copyright law is a triple-edged sword. Historically, it has been used to make sure that authors and rock musicians get their due, but it’s also been extended to the breaking point by firms like Disney. Strangely, a concept that protected creative arts got pressed into duty in the 1980s to protect the writing down of computer instructions, ironically a comparatively few bytes of BIOS code. But as long as we’re going down this strange road where assembly language is creative art, copyright law could also be used to protect the openness of software as well. And doing so has given tremendous legal backbone to the open and free software movements.

So let’s muddy the waters further. Looking at cases like the CDDB fiasco, or the most recent sale of ADSB Exchange, what I see is a community of people providing data to an open resource, in the belief that they are building something for the greater good. And then someone comes along, closes up the database, and sells it. What prevents this from happening in the open-software world? Copyright law. What is the equivalent of copyright for datasets? Strangely enough, that same copyright law.

Data, being facts, can’t be copyrighted. But datasets are purposeful collections of data. And just like computer programs, datasets can be licensed with a restrictive copyright or a permissive copyleft. Indeed, they must, because the same presumption of restrictive copyright is the default.

I scoured all over the ADSB Exchange website to find any notice of the copyright / copyleft status of their dataset taken as a whole, and couldn’t find any. My read is that this means that the dataset is the exclusive property of its owner. The folks who were contributing to ADSB Exchange were, as far as I can tell, contributing to a dataset that they couldn’t modify or redistribute. To be a free and open dataset, to be shared freely, copied, and remixed, it would need a copyleft license like Creative Commons or the Open Data Commons license.

So I’ll admit that I’m surprised to have not seen permissive licenses used around community-based open data projects, especially projects like ADSB Exchange, where all of the software that drives it is open source. Is this just because we don’t know enough about them? Maybe it’s time for that to change, because copyright on datasets is the law of the land, no matter how absurd it may sound on the face, and the closed version is the default. If you want your data contributions to be free, make sure that the project has a free data license.

Speak To The Machine

If you own a 3D printer, CNC router, or basically anything else that makes coordinated movements with a bunch of stepper motors, chances are good that it speaks G-code. Do you?

If you were a CNC machinist back in the 1980’s, chances are very good that you’d be fluent in the language, and maybe even a couple different machines’ specialized dialects. But higher level abstractions pretty quickly took over the CAM landscape, and knowing how to navigate GUIs and do CAD became more relevant than knowing how to move the machine around by typing.

a Reprap Darwin
Reprap Darwin: it was horrible, but it was awesome.

Strangely enough, I learned G-code in 2010, as the RepRap Darwin that my hackerspace needed some human wranglers. If you want to print out a 3D design today, you have a wealth of convenient slicers that’ll turn abstract geometry into G-code, but back in the day, all we had was a mess of Python scripts. Given the state of things, it was worth learning a little G-code, because even if you just wanted to print something out, it was far from plug-and-play.

For instance, it was far easier to just edit the M104 value than to change the temperature and re-slice the whole thing, which could take an appreciable amount of time back then. Honestly, we were all working on the printers as much as we were printing. Knowing how to whip up some quick bed-levelling test scripts and/or demo objects in G-code was just plain handy. And of course the people writing or tweaking the slicers had to know how to talk directly to the machine.

Even today, I think it’s useful to be able to speak to the machine in its native language. Case in point: the el-quicko pen-plotter I whipped together two weekends ago was actually to play around with Logo, the turtle language, with my son. It didn’t take me more than an hour or so to whip up a trivial Logo-alike (in Python) for the CNC: pen-up, pen-down, forward, turn, repeat, and subroutine definitions. Translating this all to machine moves was actually super simple, and we had a great time live-drawing with the machine.

So if you want to code for your machine, you’ll need to speak its language. A slicer is great for the one thing it does – turning an STL into G-code, but if you want to do anything a little more bespoke, you should learn G-code. And if you’ve got a 3D printer kicking around, certainly if it runs Marlin or similar firmware, you’ve got the ideal platform for exploration.

Does anyone else still play with G-code?

Irreproducible, Accumulative Hacks

Last weekend, I made an incredibly accurate CNC pen-plotter bot in just 20 minutes, for a total expenditure of $0. How did I pull this off? Hacks accumulate.

In particular, the main ingredients were a CNC router, some 3D-printed mounts that I’d designed and built for it, and a sweet used linear rail that I picked up on eBay as part of a set a few years back because it was just too good of a deal. If you had to replicate this build exactly, it would probably take a month or two of labor and cost maybe $2,000 on top of that. Heck, just tuning up the Chinese 6040 CNC machine alone took me four good weekends and involved replacing the stepper motors. Continue reading “Irreproducible, Accumulative Hacks”

Too Many Pixels

Sometimes simpler is more impressive than complicated, and part of this is certainly due to Arthur C. Clarke’s third law: “Any sufficiently advanced technology is indistinguishable from magic.”. It’s counter-intuitive, though, that a high-tech project would seem any less amazing than a simpler one, but hear me out.

I first noticed this ages ago, when we were ripping out the blue laser diodes from Casio XJ-A130 laser projectors back when this was the only way to get a powerful blue laser diode. Casio had bought up the world’s supply of the 1.5 W Nichias, and was putting 24 of them in each projector, making them worth more dead than alive, if you know what I mean. Anyway, we were putting on a laser show, and the bright blue diode laser was just what we needed.

RGB Laser show
A sweeter setup than mine, but you get the idea. 

Color laser setups take three or more different lasers, combine the beams, and then bounce them off of mirrors attached to galvos. Steer the mirrors around, and you can project vector images. It’s pretty cool tech, and involves some serious fine-tuning, but the irony here is that we were tearing apart a device with 788,736 microscopic DLP mirrors to point the lasers through just two. And yet, a DIY laser show is significantly cooler than just putting up your powerpoint on the office wall.

The same thing goes for 2D plotting machines like the AxiDraw. The astonishing tech behind any old laser printer is mind-numbing. Possibly literally. Why else would we think that art drawn out by a pen in the hands of a stepper-powered robot is cooler than the output of a 1600 DPI unit coming from HP’s stable? I mean, instead of running an hours-long job to put ink on paper with a pen, my Laserjet puts out an image in ten seconds. But it’s just not as much fun.

So here we are, in an age where there’s so darn much magic all around us, in the form of sufficiently advanced technology, that comprehensible devices are actually more impressive. And my guess is that it’s partly because it’s not surprising when a device that’s already magic does something magical. I mean, that’s just what it’s supposed to do. Duh!

But when something beautiful emerges from a pair of mirrors epoxied to shafts on springs turned by copper coils, that’s real magic.

Happy New Year, Hackaday!

[Tom Nardi] and I were talking on the podcast about 2022, and how it went from the hacker’s perspective. As the global chip shortage entered its second full year, we both thought back on the ways that we all had to adapt and work around the fact that we just couldn’t get the parts we were accustomed to picking up with ease.

What had previously been an infinite supply of knockoff Arduino clones and STM32 Blue Pill boards all of a sudden just dried up. Sometimes you just couldn’t get the DAC chip you wanted, or at least not without many weeks’ lead time, and even then, it’d cost you. Raspberry Pi single-board computers became hard to find. PCB designs had to change and new SDKs needed to be learned. I know I had to grab twice for unfamiliar microcontroller platforms this year.

We hacked around the problems. It would be absurd to say that the chip shortage wasn’t a pain in the posterior, but in the end we all managed to carry on and keep creating. We created more flexible footprints, learned to design around what we could get, and definitely had to do more planning. We pulled parts for projects out of the junk box or shelf stock. Or, as Tom noted, we did what everyone in the parts of the world who aren’t as fortunate to get free expedited shipping does – we made do.

Making do often meant learning new environments, questioning old habits, and double-checking pinouts. But if you’re like me, not all of that time was wasted. Sometimes it’s good to get shaken out of comfy workflows, even if by force. So while we wish you parts-in-stock and easy availability for 2023, don’t forget the lessons learned from 2022. Stay scrappy, Hackaday!

In Praise Of “Just Because” Hacks

Sometimes you pick a project because the world needs it to be done. Or maybe you or a friend need it. Or maybe you don’t really need it, but it fulfills a longstanding dream. In my mind, the last stop before you reach “why am I doing this” is the “just because” hack.

The ideal “just because” hack is limited in scope. You don’t want to spend years on a whimsical project, and because of this a “just because” hack isn’t usually motivating enough to keep you going that long anyway, except for the tenacious few. A “just because” doesn’t necessarily have to be an easy win, but it makes sense for you to see your way out before you get in too deep.

I’m not sure if it’s the Baader-Meinhof phenomenon or not, but in the last week or so in the Hackaday universe, a lot of people have been singing the praises of “just because” hacks. (Check out this one discussion, for instance.) Mostly, it’s a combination of them turning out better than initially thought, or it’s about the learning that came along for the ride. Of course, many of them spin off into longer, serious projects even if they didn’t start that way.

Not everything in life can be frivolous, of course. But that makes the “just because” hack that much sweeter, and you should try to make mental room for them if you can. When the stakes are low, creativity can be high. You might still want to impose a deadline, lest you fall into eternal yak shaving, but take it easy. You don’t need a justification all the time: the journey can be the destination.

Yesterday’s Future Is Brighter Today

The demoscene never ceases to amaze. Back in the mid-80s, people wouldn’t just hack software to remove the copy restrictions, but would go the extra mile and add some fun artwork and greetz. Over the ensuing decade the artform broke away from the cracks entirely, and the elite hackers were making electronic music with amazing accompanying graphics to simply show off.

Looked at from today, some of the demos are amazing given that they were done on such primitive hardware, but those were the cutting edge home computers at the time. I don’t know what today’s equivalent is, with CGI-powered blockbusters running in mainstream cinemas, the state of the art in graphics has moved on quite a bit. But the state of the old art doesn’t rest either. I’ve just seen the most amazing demo on a ZX Spectrum.

Simply put, this demo does things in 2022 on a computer from 1982 that were literally impossible at the time. Not because the hardware was different – this is using retro gear after all – but because the state of our communal knowledge has changed so dramatically over the last 40 years. What makes 2020s demos more amazing than their 1990s equivalents is that we’ve learned, discovered, and shared enough new tricks with each other that we can do what was previously impossible. Not because of silicon tech, but because of the wetware. (And maybe I shouldn’t underestimate the impact of today’s coding environments and other tooling.)

I love the old demoscene, probably for nostalgia reasons, but I love the new demoscene because it shows us how far we’ve come. That, and it’s almost like reverse time-travel, taking today’s knowledge and pushing it back into gear of the past.