For what it's worth, I believe one of the main tenets of libsecondlife should be the following:
Libsecondlife does not and will not enable anything that cannot already be done manually by logging in with the official client. The purpose of libsecondlife should be to allow Agent automation so actions can be performed more quickly and/or without human intervention. These actions are restricted to anything already allowed by the official client. In keeping with this, I agree with John Hurliman. The fee must be paid to simulate exactly the actions of the client. To do otherwise would enable actions that cannot already be done manually by logging in with the official client. -Sam -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hurliman Sent: Sunday, July 09, 2006 3:16 PM To: Development list for libsecondlife Subject: Re: [libsecondlife-dev] Inventory Upload & Fees Tom Wilson wrote: > I wonder if this is how the guys at the Manhattan Project felt when > they successfully detonated the world's first nuclear bomb: we have > this tool, but do we dare use it? > > I do agree that it's a bad idea to turn libSL in to a potential > vehicle for a free upload program - especially when all of the > textures, sounds, and animations are hosted on one server at LL (the > true weak point of SL). Is this the same for scripts and notecards? I > think someone on the forum mentioned that it's possible to use libSL > to upload a compiled script. I don't really care if people turn libsl in to a free upload program, but the official release won't support it. Skirting around upload fees is a problem between the particular user doing it and LL, and LL can handle it how they see fit. Our concern is making sure users aren't going to get banned for using libsl itself, not rogue apps developed with it. > > What about this? Contact LL, /keep the checksum algorithm a secret for > now,/ and don't publish the upload function to the SVN until you get a > definitive answer from LL. In the meantime, I'm sure that the people > who are reading this list are sensitive enough to the problem to be > responsible, and not publish or release the checksum algorithm or any > programs that upload textures, animations, or sounds without charging > the obligatory L$10 fee (and paying it to LL, of course). Too late, as of two days ago the mailing list archive has pseudo-code on how to generate the CRC, as of yesterday the sldump program had proof of concept code to test it, and as of right now the UpdateInventoryItem packet builder has support for it. The cat's already out of the bag, and I don't think there's any reason to censor that information. Also as I mentioned in the earlier e-mail, someone already has released a program that gets around the upload fee and LL is already having to deal with it. Namely by scanning log files and banning people who do this. > > My thought is to use developer registration: essentially, LL would > have some sort of validation sequence with third-party applications. > The system could be as simple as PGP-encryping a security sequence on > the client side and the SL servers decoding the key and confirming the > developer's identity. If the key can't be confirmed, the app isn't > allowed to log in. This would require SL to create a database of > developers, and could help them track developers who break the TOS by > writing apps that don't follow the rules. > > Doing that also helps you with some of your responsiblity and > liability. Developers who register in the developer program have > certified to LL that they will follow the TOS with all of their programs. > This topic deserves a thread of it's own really. Of course I'm in favor of LL forcing registration because barriers to entry in a market are the first step to creating a cartel, which can produce a monopoly. The developers here are in prime position to become a part of that cartel with monopoly control over all third party applications developed for SL. However I think LL and other developers would realize that is a dangerous precedent, and probably shouldn't be the goal of an open source third party library. John _______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev _______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev
