[sldev] Re: [PROTOCOL] Protocol Documentation

Argent Stonecutter secret.argent at gmail.com
Fri Oct 5 09:36:04 PDT 2007


On 05-Oct-2007, at 10:44, dirk husemann wrote:
> Argent Stonecutter wrote:
>> On 05-Oct-2007, at 01:52, dirk husemann wrote:
>>> as we have seen
>>> with SCO you have ALWAYS the possibility of a greedy fool trying to
>>> attack you anyhow (e.g., claiming that the code you used was  
>>> stolen from
>>> him, don't mind the BSD/GPL/whatever license).

>> Um, the SCO case was coming from exactly the opposite direction. They
>> were claiming that certain GPLed code was derived from their code,
>> because it had been part of a system derived from their code. If they
>> actually *had* the licenses they claimed they had, *and* their  
>> license
>> terms meant what they claimed they meant, then they might have had  
>> had
>> a case. Their problems included:

> originally they claimed that code had been copied pretty much  
> literally
> from their code basis --- thus, claiming that code that was used in
> linux was copied from them. not sure how that is the opposite  
> direction.

That is that it was code copied from their license to GPL, not that  
they were claiming that the GPL or any other open source license  
imposed limitations on someone's use of directly or indirectly  
derived work. So I don't think there's any application here.

The only thing that could conceivably apply is that they claimed both  
literal copying and that IBM's code was a derived work simply because  
it was developed by a licensee (the 'viral UNIX license' theory).  
That should have been dead in the water because of the CSRG-USL row  
over the BSD code, and Novell shot it down anyway.

Linden Labs contributor agreement should protect against any indirect  
claims like that. If Linden Labs states[1] that simply using the code  
to figure out the protocol (including using things like constants  
from header files) does NOT make a work a derived work, that should  
eliminate any concern about direct claims.

[1] with appropriate legal terminology



More information about the SLDev mailing list