3 ms·
If there's a security flaw present in the original and fork, how do you write a patch to the same bug without writing identical code? How do you avoid accidenta
by JCharante 3y ago
If there's a security flaw present in the original and fork, how do you write a patch to the same bug without writing identical code? How do you avoid accidentally being influenced by Business Source License code, especially as devs start using LLMs that may ingest that code in their training data?
- JCharante 3y agoI'm not trying to discourage the project, this is just a genuine question for any project that has 2 "open source" versions that are very alike
- mnahkies 3y agoThe scenario you present in the parent comment has echoes of https://en.m.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc https://en.m.wikipedia.org/wiki/Google_LLC_v._Oracle_America.... - if I recall correctly they did "clean room" re-implementations of the same public API surfaces which in some cases resulted in identical implementations. To my understanding if some piece of code is the only / obvious way to solve a problem it's not an issue. To use a trivial example there's only so many ways you can implement a sum contents of array function, I'd imagine for many security vulnerabilities it'll be similar - adding a bounds check or whatever isn't going to be problematic just because you weren't first.
- JCharante 3y agoOkay, nice. I didn't know there were identical implementations in that case, I just thought it was about the method signatures being identical (because that's necessary when it's API Compatible).