IANAL. One thing to remember: several projects explicitly draw a line around the "derivative work" concept to limit what it can entail.
For example, every program that runs on the Linux kernel ends up including kernel code into the operating program because of the way programs run on operating systems. To make it easy to write a program a header file is typically used when compiling the program so that it knows how to incorporate the kernel bits. Linus Torvalds has stated that this use does not make the program a derivative work of the kernel.
In other cases, such as PHP (and C, to a lesser extent) the language can not be claimed to be a derivative work of its libraries. Sure, you can call strlen() and, at link time or run time your program is linked to a library you did not write. But the program itself is not a derivative work of the language or the runtime. In many cases the library used merely exposes an implementation of a standard, and thus the program is not a derivative of that library specifically. So your C program which calls strlen() can link against any C library that has a strlen() in it. Your program is not automatically a derivative work of Glibc. Even PHP has multiple implementations (The Resin webserver ships with a PHP implementation in Java). So even if PHP were GPL your program might not need to be.
A framework is really an extended set of libraries and the normal rules for libraries would apply. For example, if the framework is one implementation of a standard, then maybe distributing it with your app is a violation of the GPL but simply using it would not be since your app is a derivative of the standard and not this specific instance of the framework. For example, an application which uses EJBs can run on IBM WebSphere, RedHat's JBoss, Bea's Weblogic, etc, and not have to comply with JBoss's license. Maybe shipping JBoss and your app on the same CD would violate the license for JBoss but your app is otherwise free of restrictions (unless it includes parts of JBoss in it).
If the framework in question is not a standard and nobody else implements it, and/or you must include parts of the framework in your own code, then your app may be a derivative work. Consider a linux kernel module: it is difficult to create a module which does not violate the GPL because most modules must include kernel code to get their job done. nVidia sidesteps this by creating a proprietary blob which has no kernel code in it, but is not a fully functional module, and adds on some GPL glue code which makes it into a module. Most kernel devs consider it a GPL violation to distribute both the kernel and the driver together (since you create a derivative work of the kernel by adding a module, but that module is not GPL) but distributing the module by itself does not create a derivative work until it is combined by the end user, who no longer distributes it and thus is not bound by any distribution terms.
Keep in mind: not all projects have the same interpretations of the licenses they use. You may be within your legal rights to use code a certain way according to the stated license, but you probably don't want to be sued, so when in doubt consult with a lawyer the original copyright holders.
