[SLED] Copybot, the scare, the spin, and you

Emin Saglamer es26 at txstate.edu
Mon Nov 20 09:42:49 PST 2006


This has been pointed out to me in the forums as wrong. Yes I was wrong. I
simply did not understand the relationship between LL and libSL and I must
admit I don¹t think I still do.

Mostly because, no other party would have been able to get away with what
was done here. So what is different about the members of the libSL team?


I repeat: Source code of the SL client has been shared. However I do believe
that the libSL team has otherwise been empowered with resources not
available to other SL users.


Thanks for the correction.

ES

> From: "Static Sprocket" <static.sprocket at gmail.com>
> Reply-To: SL Educators <educators at lists.secondlife.com>
> Date: Sat, 18 Nov 2006 01:33:25 -0800
> To: "SL Educators" <educators at lists.secondlife.com>
> Subject: Re: [SLED] Copybot, the scare, the spin, and you
> 
> Emin Saglamer (Troy Vogel) said:
>> 
>> Can TCP IP packets be sniffed by experienced programmers? Yes but that's
>> a lot of data to sniff to figure out what's what. And usually it would
>> take a long long time to figure out all these packets and assemble an
>> interpreter of sorts WITHOUT HELP. It is my personal theory that if LL
>> had not empowered the members of libSL (most of whom are old timers with
>> great prestige and programming expertise) by sharing parts of the source
>> code with them, this situation would never have come into existence.
> 
> If Linden Labs shared source code with us, then we'd really appreciate
> someone pointing out where that code is.  Because although LL
> employees have occasionally answered questions we had about specific
> packet payloads -- they've never specifically given us any source
> code.  For example, they've assisted us in determining the bit mask
> needed to allow an avatar to move around, but they've never once
> assisted with any Asset or Inventory packets.
> 
> Our earliest breakthroughs were made by decompiling the SL Client, and
> reverse engineering data out of the client, and the files distributed
> with the client.
> 
> We've (as far as I know) never needed to "sniff" packets TPC packets
> -- as we were able to pull enough information about how the packets
> were constructed directly out of the client and it's associated data
> files.
> 
>> So saying the source code of Second Life is
>> open source is simply inaccurate.
> 
> I'm not sure who is saying that SL's source code is open source -- but
> I  can tell any of them that it is not.  However libsecondlife's
> source code is.
> 
>> Even if it were capable of backing up onto your hard drive, how would
>> you move these localized items back into SL since there's no import
>> object or asset option?
> 
> There is in fact already an import example in libsecondlife.  It
> imports files in a ".prim" format, which is an XML format designed to
> allow the import of prims from other 3D design programs.
> 
> 
>> The people who released this tool without consulting LL or the content
>> creator guilds in SL can be assumed by default to have done this with
>> ill intend.
> 
> LL is aware of the fact that everything we do is placed in our source
> code repository which was publicly available to anyone.  Prior to the
> source code being added to our repository, more then one LL employee
> was given a demo of it.
> 
> 
> --
> Michael Cortez
> AKA Static Sprocket
> _______________________________________________
> Educators mailing list
> To unsubscribe
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/educators
> 



More information about the Educators mailing list