> I'll answer with my own hypothetical. If I write a program that dynamically links a library performing the same GPL'd fluid sim calculations, it is presumably forced to be GPL, because it links to it. What if someone comes along and runs the program but at runtime uses LD_PRELOAD to override the dynamic linker, linking it to an alternative library that presents the same interface. Is the program still required to be GPL?
I've never believed that linking made your code necessarily GPL in the first place. I don't care what the FSF says, they're not exactly unbiased.
> I think you are specifically responding to my "does not work without" interpretation overly literally. Clearly if the program is written for and tested against a specific interface of a GPL'd program, it is intended to work with that program.
> On the other hand if it's written to call into some kind of standard interface, it no longer requires that GPL program specifically, but could work with any program implementing that interface.
Well that's basically how the standard already works. If your code is using a specialized enough interface, sharing data structures you got from the GPL code, then it's derivative of the GPL code and needs to follow the GPL.
So while "process boundary" is an inexact tool, your suggestion of "does not work without" doesn't seem significantly better to me.
Yeah, I think you make some great points and I'll give you that; you probably did show here why my idea is not correct. I don't know the right answer, I'm certainly no lawyer ;)
I just know that, to me, "dynamic linking" seems like an arbitrary and imprecise way to define "derivative work". And, I'm not sure whether it's really something that _can_ be defined and possible to determine without consider it on a case by case basis. It's a good "right hand rule", perhaps, but doesn't strike me as either necessary or sufficient to really define it. We'll never really know, I guess, until someone makes that actual argument in court.
I've never believed that linking made your code necessarily GPL in the first place. I don't care what the FSF says, they're not exactly unbiased.
> I think you are specifically responding to my "does not work without" interpretation overly literally. Clearly if the program is written for and tested against a specific interface of a GPL'd program, it is intended to work with that program.
> On the other hand if it's written to call into some kind of standard interface, it no longer requires that GPL program specifically, but could work with any program implementing that interface.
Well that's basically how the standard already works. If your code is using a specialized enough interface, sharing data structures you got from the GPL code, then it's derivative of the GPL code and needs to follow the GPL.
So while "process boundary" is an inexact tool, your suggestion of "does not work without" doesn't seem significantly better to me.