News for hackers. Stuff that matters.

A comment on We need a real GNU/Linux (not Android) smartphone ecosystem. Parent comment

Re:We need a real GNU/Linux (not Android) smartphone ecosystem by AnthonyMouse on Sunday October 06, 2024 @02:34AM (#41755235)
What stops someone from decompiling the closed source driver into barely legible "source code" and then grafting that onto a generic kernel so it can run on the device? It wouldn't be pretty but it would probably be a faster way to get running on the device than having to write a complete reverse-engineered driver from scratch before you can even boot, and then you have a starting point for writing an open source driver that doesn't suck as much.

Could some change be made to the kernel to make that process easier? Do we need better tools to make it more practical?

[ Parent | on HN ]
Re:We need a real GNU/Linux (not Android) smartphone ecosystem by transpute on Sunday October 06, 2024 @03:09AM (#41755365)
> decompiling

https://law.stackexchange.com/questions/101689/can-you-legal...

  If you look at a decompiled code and are influenced in how you write your code by the decompiled code, this is probably a "derivative work" of the original program and not just "reverse engineering" from the way that the computer program works. Copyright for software protects the decompiled code that is written, as a literary work, and anything derived from that decompiled code is also protected..

  [clean-room reverse engineering] One group examines the source to write the specs and rundown. Another to make the code again, with no people from group 1 taking to them but for the spec sheet
> do we need better tools to make it more practical?

Good question, perhaps others can comment. The challenge is likely economics, not tooling.

[ Parent | on HN ]
Re:We need a real GNU/Linux (not Android) smartphone ecosystem by gomerspiles on Sunday October 06, 2024 @03:19AM (#41755400)
This is GPL code so decompiling isn't necessary or the problem.

Accepting over the wall low quality code and having a submitter for it who may know nothing about it makes it difficult to work any of this low quality code into the mainline kernel via its resource starved processes.

[ Parent | on HN ]