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
[email protected]
https://mail.gna.org/listinfo/libsecondlife-dev
