4 ms·
> make it unenforceable for a TOS to ban reverse-engineering for compatibility reasons While I appreciate that (and since I don't appreciate my work being lock
by tonyarkles 7y ago
> make it unenforceable for a TOS to ban reverse-engineering for compatibility reasons
While I appreciate that (and since I don't appreciate my work being locked up in proprietary formats, I primarily use either plain-text or LaTeX for documents), there's a whole can of worms around that.
[note that I do not know the specific details of .PSD files, nor the patent status of things below. It's an example]
As an example off the top of my head, Photoshop has a feature called "Content-aware Fill". This lets you delete a region of an image and have it be replaced by auto-generated "reasonable" context (if you delete someone standing on a hill with the sky behind them, it'll interpolate grass and sky for you).
So now I'm reverse-engineering the .PSD format, and discover that a content-aware fill operation is stored in the file as the pixel coordinates and CAF parameters; not the pixels themselves. The CAF algorithm is patented. What now? Under your proposal I'd be justified in carrying on figuring out how to make an interoperable implementation, but... I couldn't distribute that implementation without violating Adobe's patent.