non-gcc linux?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Tim Riker
I understand "will not", but "can not"? There is nothing stopping anyone, let's say SGI for example, from branching a separate gcc which would include copyrights assigned to FSF and other parties. Let's say this happens and a new sgigcc source base is created. Presumably then any defense of gcc code could be met with the argument that the code used came from sgigcc. This being the case what has the FSD gained by the current policy?
I'm unclear on how you're defining your terms, but were someone to have violated the GPL license on gcc, I don't understand how the existence of sgigcc would allow them to mount a defense. The point of the copyright assignments is to make the copyright holder clear for legal purposes in the event of an attempt to violate the license. You *seem* to be saying that somehow one could claim that gcc code wasn't actually owned by the FSF because it might have come from sgigcc (?), but of course that wouldn't be the case because all gcc code has copyright assignments.
Quoted 7 lines
I suppose that this is even the case today as one could argue that code came from intel-gcc if they used the Intel patches for ia64 or any other non-FSF copyrighted patches including patches made by the same company that the FSD might be in legal action with.
In short, I do not see any enforceable advantages to the current FSF policies.
I can see a whole bunch of advantages, and I'm afraid that your paragraphs above don't make any semantic sense to me. Could you please clarify what you mean?
I think that the copyright assignment requirement is to some degree legal paranoia; sure, it's not *necessary* under copyright law, and in theory one could successfully defend the license without it. But I can also very readily believe the advice of lawyers on the subject, namely that enforcement of the copyright is significantly easier in real court if one entity owns all of the rights.
Signature · 5 lines
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
My understand of the argument for assigning all gcc copyright to the FSF is that this make 'gcc' easier to defend. My example of an sgi-gcc shows that sgi-gcc would have different criteria in a defense. This is solely because both SGI and FSF would hold copyrights.
Now Marc Lehmann claims that this dual copyright code would be "impossible" to defend. I merely pointed out that if that is truly the case, gcc would also be indefensible because any GPL violator could claim they took the source not from gcc, but from sgi-gcc which Marc claims is indefensible.
I therefore assert that the fictitious sgi-gcc IS defensible and then by conclusion that the current FSF position is not required to defend gcc GPL. I am merely trying to assert what you stated as a given below:
Quoted 6 lines
I think that the copyright assignment requirement is to some degree legal paranoia; sure, it's not *necessary* under copyright law, and in theory one could successfully defend the license without it. But I can also very readily believe the advice of lawyers on the subject, namely that enforcement of the copyright is significantly easier in real court if one entity owns all of the rights.
In short the impact of adding code to gcc that is not copyright FSF is minimal. Only the FSF copyrighted code would be defensible by the FSF. Any other code GPL violations would be the responsibility of the copyright owners to defend.
As before IANAL. ;-)
Quoted 39 lines · Russ Allbery
Quoted 7 lines · Tim Riker
I understand "will not", but "can not"? There is nothing stopping anyone, let's say SGI for example, from branching a separate gcc which would include copyrights assigned to FSF and other parties. Let's say this happens and a new sgigcc source base is created. Presumably then any defense of gcc code could be met with the argument that the code used came from sgigcc. This being the case what has the FSD gained by the current policy?
I'm unclear on how you're defining your terms, but were someone to have violated the GPL license on gcc, I don't understand how the existence of sgigcc would allow them to mount a defense. The point of the copyright assignments is to make the copyright holder clear for legal purposes in the event of an attempt to violate the license. You *seem* to be saying that somehow one could claim that gcc code wasn't actually owned by the FSF because it might have come from sgigcc (?), but of course that wouldn't be the case because all gcc code has copyright assignments.
Quoted 7 lines
I suppose that this is even the case today as one could argue that code came from intel-gcc if they used the Intel patches for ia64 or any other non-FSF copyrighted patches including patches made by the same company that the FSD might be in legal action with.
In short, I do not see any enforceable advantages to the current FSF policies.
I can see a whole bunch of advantages, and I'm afraid that your paragraphs above don't make any semantic sense to me. Could you please clarify what you mean?
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Signature · 7 lines
Tim Riker - http://rikers.org/ - short SIGs! <g> All I need to know I could have learned in Kindergarten ... if I'd just been paying attention. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · Tim Riker
In short the impact of adding code to gcc that is not copyright FSF is minimal. Only the FSF copyrighted code would be defensible by the FSF. Any other code GPL violations would be the responsibility of the copyright owners to defend.
Just as a minor point: pro64 _does_ use GCC code. It's effectively the GCC frontend stuck together with the SGI backend, with a translation layer in the middle to translate between the intermediate code formats that the two compilers use. There are some fairly entertaining "this is a gruesome hack" comments in the source code.
Signature · 7 lines
Adam Sampson [email protected] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/