3 ms·

So if VMware loses this what would prevent e.g. Microsoft from claiming that the kernel driver in Process Hacker is a derivative work of the Windows kernel? Or

So if VMware loses this what would prevent e.g. Microsoft from claiming that the kernel driver in Process Hacker is a derivative work of the Windows kernel? Or worse, anything that patches a Windows DLL is a derivative work of that dll?

__david__ 11y ago
> Or worse, anything that patches a Windows DLL is a derivative work of that dll? Isn't this the current status quo? How can a patched DLL be anything but a derivative work?
- wolf550e 11y ago
  A patched DLL is a derivative work. But is the patch itself a derivative work?
  - Karunamon 11y ago
    Not sure what the difference in this case would be - VMWare is doing the equivalent of distributing the patched DLL.
davexunit 11y ago
This makes no sense because you are talking about hacking proprietary binaries, not source code under a copyleft license.
- poizan42 11y ago
  I'm talking about that if a proprietary driver that links to the linux kernel is a derivative work then surely an open source driver linking to the Windows kernel is too.
  - SXX 11y ago
    I'm not a lawyer, but I totally sure that all Windows APIs that used by drivers and programs have clear statement within license that licensing is not "viral". GPL is opposite. It's clearly state that your code depend on GPLed code become derivative work.
    - poizan42 11y ago
      I didn't say it would infringe on anything just that it would be a derivative. Maybe that was a bad example though, but do we really want to disallow opensource project from extending proprietary software without the blessing of the copyright owner? Because that is the other side of the coin.
      - SXX 11y ago
        It's depend on what you mean as "extending": official module/plugin or process memory patching. Some example would be helpful if you seriously want to discuss it. Though for officially supported add ons system of proprietary products usually state what license you can or can't use. All kind of tools that access and patch process memory are not in danger because most of time they modify process state via 3rd party OS APIs and they do not interact with programs they patching. In same time changes that patcher do within process can't go under GPL and fact that developers keep licensing that code under open source licenses doesn't change the fact it's break EULA.
    - tzs 11y ago
      It seems that you are under the impression that the license can determine whether or not something that uses or interfaces with some program is a derivative work of that program. That is not the case. The answer to whether or not X is a derivate work of Y is the same regardless of the license of Y. It is answered by looking at how much of Y's copyrighted expression has been incorporated into X. All the license of Y determines is whether or not, in the case that X is a derivative work, that making or distributing such a derivative work is allowed. Some licenses have contributed to confusion over this by using terms like "derived work" or "derived from", which people confuse with "derivative work".
xorcist 11y ago
Try to incorporate any code from the Windows kernel into your proprietary product without permission, and count the seconds until lawyers from Redmond start calling.
- poizan42 11y ago
  Who said anything about that?
caf 11y ago
If you distributed Process Hacker together as a combined work with Windows, you certainly would be in trouble.

__david__ 11y ago

> Or worse, anything that patches a Windows DLL is a derivative work of that dll? Isn't this the current status quo? How can a patched DLL be anything but a derivative work?

wolf550e 11y ago
A patched DLL is a derivative work. But is the patch itself a derivative work?
- Karunamon 11y ago
  Not sure what the difference in this case would be - VMWare is doing the equivalent of distributing the patched DLL.

davexunit 11y ago

This makes no sense because you are talking about hacking proprietary binaries, not source code under a copyleft license.

poizan42 11y ago
I'm talking about that if a proprietary driver that links to the linux kernel is a derivative work then surely an open source driver linking to the Windows kernel is too.
- SXX 11y ago
  I'm not a lawyer, but I totally sure that all Windows APIs that used by drivers and programs have clear statement within license that licensing is not "viral". GPL is opposite. It's clearly state that your code depend on GPLed code become derivative work.
  - poizan42 11y ago
    I didn't say it would infringe on anything just that it would be a derivative. Maybe that was a bad example though, but do we really want to disallow opensource project from extending proprietary software without the blessing of the copyright owner? Because that is the other side of the coin.
    - SXX 11y ago
      It's depend on what you mean as "extending": official module/plugin or process memory patching. Some example would be helpful if you seriously want to discuss it. Though for officially supported add ons system of proprietary products usually state what license you can or can't use. All kind of tools that access and patch process memory are not in danger because most of time they modify process state via 3rd party OS APIs and they do not interact with programs they patching. In same time changes that patcher do within process can't go under GPL and fact that developers keep licensing that code under open source licenses doesn't change the fact it's break EULA.
  - tzs 11y ago
    It seems that you are under the impression that the license can determine whether or not something that uses or interfaces with some program is a derivative work of that program. That is not the case. The answer to whether or not X is a derivate work of Y is the same regardless of the license of Y. It is answered by looking at how much of Y's copyrighted expression has been incorporated into X. All the license of Y determines is whether or not, in the case that X is a derivative work, that making or distributing such a derivative work is allowed. Some licenses have contributed to confusion over this by using terms like "derived work" or "derived from", which people confuse with "derivative work".

xorcist 11y ago

Try to incorporate any code from the Windows kernel into your proprietary product without permission, and count the seconds until lawyers from Redmond start calling.

poizan42 11y ago
Who said anything about that?

caf 11y ago

If you distributed Process Hacker together as a combined work with Windows, you certainly would be in trouble.