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

[Able Whitman]

Howdy Dale,

I've been tackling many of the same issues you've been dealing with in
trying to roll a custom, license-compliant installer.

I reached the same conclusion that you did about the Kakadu library not
being redistributable. IANAL, so I'm not sure if having your installer take
a copy of the DLL from an existing official install could be construed as de
facto redistribution. Aside from Kakadu, all the other OSS-licensed
libraries are (as far as I can tell) freely redistributable. The Microsoft
DLLs, dbghelp (see:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=CD1FC4B2-0885-47F4-AF45-7FD5E14DB6C0)
and the msvcrt DLLs (see:
http://msdn2.microsoft.com/en-US/library/abx4dbyh(VS.71).aspx) are also
redistributable.

In order to try and simplify my custom installer, I built one using NSIS
which simply installs my custom viewer on top of an existing installation of
the official viewer, in such a way that the two can run side-by-side. My
installer requires that the user first install an official copy of the
version of the viewer from which my custom build is derived from. (In my
current case, this means requiring an official 1.17.3.0 install first.)

Here are the changes I made to my client to accommodate this:
1. Change the build number (llversion.h) to a custom value, leaving the
major, minor, and revision numbers the same.
2. My build requires changes to some XUL XML files, so I renamed the changed
files by adding a "_aw" suffix to the filename
3. In conjunction with #2, I changed the source code to refer to my modified
XML files, so that when my private build is executed it references the new,
modified XML files, while the official viewer still references the original,
unmodified files
4. Change the name of the crash dump files that are created by my viewer
(handleException in llwindebug.cpp) so as not to overwrite crash dumps from
the official viewer
5. Change the window class name for my viewer (gWindowName in viewer.cpp)
6. Change the name of the default settings XML file, so that the official
viewer and my private build use different configs and do not stomp on one
another, similar to First Look viewers (DEFAULT_SETTINGS_FILE in viewer.cpp;
changing the value here has the advantage of not requiring special command
line arguments)
7. Change the display name of the application (used as the window title,
etc.) to include the phrase "unofficial edition" (gSecondLife, in WinMain,
in viewer.cpp)
8. Change the executable name to not include the phrase "SecondLife" (I
chose "AbleSL.exe")

My installer does not use the SL logo, although the logo still remains as
the icon for the executable in my private build. I believe that this use is
consistent with the LL guidelines for use of their logo, but it's not
difficult to change if it is not.

I'd be happy to provide the NSI script I use and a diff for the source
changes I mentioned, if they would be helpful.

--Able

On 7/10/07, dale at daleglass.net <dale at daleglass.net> wrote:
>
> 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.
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070710/9fb45cf7/attachment-0001.htm