[sldev] Working on an installer, anybody figured out licensing yet_

[dale at daleglass.net]

On Mon, Jul 09, 2007 at 09:15:22PM -0700, Chance Unknown wrote:
> LL has a branding policy you need to follow for use of their images on other
> hosted media such as websites, assume that you would have to follow
> something to use their copyrighted images. in as far as it goes, you might
> just want to get your own mascot for installer branding and avoid their
> images.
Installer doesn't use the SL logo currently (has the default NSIS one),
but the icon on the binary is the LL-provided one ATM.

Wondering what other things should I do. For example:

* Change the name in the title bar
* Replace the login screen
* Modify the help menu to avoid bug submission to LL
* Change the interface color to make it clearly visible it's not offical
etc

There are two angles I'm interested in here:

The LL one: What I MUST do to avoid problems. Licensing issues, too.

End-user one: How far should I go for the sake of the end user. I expect
that non-technically minded people will try it, so I'm wondering how to
best present it in such a way that avoids confusion.

> since you are forking and rebuilding from open source - erm sources - its
> worth considering how to differentiate your viewer. different versioning is
> confusing, and is the intent to identify to the grid, the user, or ___?
> since they havent identified how forks are to connect to their grid, this is
> a great question. if you rebuild using their sources without change, then
> you will identify just as the official viewer does. caveat emptor.
IIRC, if I identify as a third party client, I get to skip the version
check. Which probably would be a good thing, since otherwise in the
interval between the release of a required new version, and the release
and compilation of new source, users of my viewer couldn't log in.


> what you are describing is a fork from the original baseline? are you going
> to track version numbers or use your own? are you adding only bug fixes (in
> which case, whats the problem with submission back to the original
Sort for a fork, but not a drastic one. Standard client, plus my
improvements.

Current improvements include:
* Avatar scanner, which shows information about people found nearby.
  It can do things like moving the camera to an avatar, opening profile
  windows, sending IM, administrative stuff, etc. Currently not polished
  enough for integration.

* Integration with my reputation system. Doubtful that such a thing
  would ever get integrated into the official viewer, as it requires a
  subscription. 

* Modifications for dealing with griefers. For example, there's a hack
  to log the names of avatars who own objects that emit sounds, but
  aren't found nearby. There are probably too specific, and not nearly
  polished enough for general usage.

I don't think integration of third party commercial services into the
official viewer is something that's going to happen any time soon.


Over time I plan to track the official viewer, so this isn't intended to
be a fork that goes in a radically different direction.

> baseline)? the group or team that forks from the original baseline generally
> assumes the responsiblity for licensing compliance on the forked project, is
> it your intent to follow up on that as part of the fork? if you are just
> pissed at the installer, then open source yours and submit it to replace the
> one that resembles the nullsoft installer?
Will OSS the installer, as soon as I get it working properly, which
should be soon. 

For me, a custom installer is a requirement, as I can't ship llkdu.dll.
So mine grabs it from an existing install.

My understanding is that using OpenJPEG instead should result in a fully
redistributable package, but it still has some bugs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070710/f6bbcb79/attachment.pgp