Hacker News Reader

Comment by nicoburns | Hacker News Reader

This is pretty cool. Would you consider releasing the reverse engineered source code? I imagine that could be pretty helpful for anyone dealing with future OS changes (perhaps trying to make this work on Windows ARM for example, or even linux), and while it's probably technically against the license agreement, I can't imagine anyone would care much about such old software that's no longer maintained.

View on HN

Like steve_austin said, releasing the code is in a grey area. Realistically, it's highly unlikely that anyone would actually be upset about it, so it may happen in the future.

Linux support is a completely different beast. There is a lot of code that I didn't talk about, including the absolutely massive image post-processing/color-correction library that we only have a Windows version of (and no source code for, obviously.) The Pakon's added complexity (especially automatically finding frame boundaries) makes a cross-platform, source-code-less port extremely unlikely to succeed in a remotely reasonable amount of time.

Perhaps share the code privately with someone in another jurisdiction that is more suitable (reverse engineering laws, copyright, whatever), and that person can take the legal liability? Perhaps someone who owns a scanner like user yesimahuman in this thread?

Does it need all that support stuff to just get an image out of the device?

I would guess there’d be value in just piping the raw output into photoshop (or something) and doing the color correction/frame boundaries there.

In theory it's unnecessary. The problem is that one of the main selling points of the Pakon is its convenience - then again, if somebody wants to do things the hard way, who am I to stop them?

I don't have any plans to develop a cross-platform client, but I will be publishing more technical information about the scanner so people aren't left wondering what I know.

It seems like a grey area. Especially given that the driver is a mash-up of sample code from a third-party hardware SDK and a Microsoft book, would Kodak/Pakon really care?

I would think the only part of the software that still might retain trade secrets would be the color management code, and that's not in the driver.

Maybe there's a way to distribute dissembler hints and patches where you need the original driver files to get the source code. I assume the MS code has a reasonable license since it was published as sample code

> trade secrets would be the color management code

Are trade secrets even protected? If there's a patent, yes, but that's expired. The implementation is protected by copyright, but the know-how isn't.

> Maybe there's a way to distribute dissembler hints

Tavis recently posted about using STABS for that <https://lock.cmpxchg8b.com/symbols.html> and has existing code that seems relevant: https://github.com/taviso/wpunix/blob/main/debug/idb2stabs.p...

I've never used Ghidra in anger to know if it would work for their platform, nor whether the Ghidra database can be shipped separate from the binary

Trade secrets may not be protected by patents (if expired), but protection of them is a potential motivation for copyright litigation.

Kodak sold a lot of their patents to other companies as a result, IIRC, of their bankruptcy. I'd have to look at the patents for this particular system again, because I can't remember if they were ever reassigned or if they were simply allowed to expire.

I don't think reassignment changes the duration of the patent. Looks like the early versions of the devices came out in 2004, so it's getting really close to when they'd expire.

IANAL, but my concern would be distributing either the original drivers or 64-bit drivers, but in practice, no one is going to care. It's not worth an hour of a lawyer's time to send a cease and desist letter for distributing driver source for an 18-year-old device.

Reply on news.ycombinator.com