@ 11/05/2004 18:23 : wrote Raul Miller :
People without proper palladium licenses would not have the rights
required by the gpl.
On Tue, May 11, 2004 at 09:18:28PM +0100, Henning Makholm wrote:
Why not?
Because palladium is a proprietary work, and it's more than just an OS.
But you can combine gcc with it, you can't LINK gcc with it directly...
You have at least half a point here. Derived works... are you implying
that if you integrate gcc better with Palladium you will make the
new-gcc a derived work of Palladium? This is not necessarily true.
Brazilian copyright law (9610/98) definition of derived work: the work
achieved by some transformation of the original work, but is a novel
intellectual creation in (and by) itself. Is new-gcc result of a
transformation on palladium? no, I don't think so. (Remember Brazilian
law is strongly influenced by Berne convention, and similar terms are in
copyright law in various other jurisdictions of Debian interest).
I'll grant that if the changes were limited to what was required to get
the OS to support it, that would probably be distributable. But that's
not the kind of example I was proposing.
I was not proposing "make gcc work on that OS", I was proposing
functional
modifications to GCC to make it integrate better with that environment.
It still won't make the new-gcc a derived work on that environment.
As a rough idea, imagine if gcc were made to support special keywords or
control files to make it easier to build programs which use palladium's
proprietary encryption and digital rights management facilities object
model. Or, more generally, imagine any change which makes gcc into
something that works in a proprietary fashion.
What you are supposing is something that was done once in the form of
__near and __far pointers; you did not clarify what you call "work in a
proprietary fashion". Describe this to me, please, as I can be
overlooking something. If you can, give some example of modification
that would trigger unGPLrightness in a modified gcc.
--
br,M
