Re: [opensource-dev] Request for clarification on mailing list guidelines

[Robin Cornelius]

On Tue, Mar 23, 2010 at 5:12 AM, Philippe (Merov) Bossut
 wrote:
> Hi,
>
> Each tool has its pluses and minuses and we use a variety of them:
> - IW meetings: we have our weekly Hippo meeting and I truly encourage folks
> to come. It's my favorite comm tool personally as it's a dedicated moment
> and we have full attention of everyone. Should we do more of this?

I agree this is a particulary productive meeting and for the most part
people plan ahead and add items to be discussed to the ajenda and we
normally make good progress on most issues.

The biggest issue is that a single hour is not often enough to cover
all issues, and the exact time it currently is will not suit everyone
(and i guess any other time will not suit everyone either), but
instead of extending the existing meeting, is there a call for 1 more
time slot? possibly at a completly different time so those who can't
make the Thursday meet can make the other one? some of the power of
this meeting is that its a single slot of time and this causes focus,
additional time slots could dilute this?

> - IRC: great for informal and quick discussions but *highly* distracting. I
> sometime choose not to be available so I can focus on work.

It can be distracting but I find it extreamly useful, tend to get real
time discussions going over issues and can really get in to techincal
issues with minimum overhead. Also useful as its exceedingly
lightweight so can be left idling. Certainly the current snowglobe
committers tend to idle there as well and its an easy way to get hold
of each other.

Robin
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Development project: extending avatar wearables

[Henri Beauchamp]

On Tue, 23 Mar 2010 06:57:54 +, Morgaine wrote:

> On Tue, Mar 23, 2010 at 4:35 AM, Bryon Ruxton  wrote:
>
>- Could you please stop putting everything into that sidebar as the only
>way to access stuff. You've kept wanting to make this "communicator window 
> "
>before into a single un-detachable block. And despite many of use hating it
>and asking for you to make separate floaters, (or at least give us that
>option), you keep attaching everything all together again in that sidebar.
>This is an ill conceived approach for many of us, who are used to identify
>specific panels at a specific position of our choice on the screen just 
> like
>. Blending it all together makes it harder in that sense.
>
> In addition to the fact that many people simply "do not like" the sidebar,
> there are several more technical reasons why it is a bad idea ergonomically
> too, such as limiting displays to only one type at a time (eg. not inventory
> AND friends) and only one instance at a time (e.g can't show two profiles).
> In addition, the continual movement and resizing shifts the 3D world in a
> very dizzying way, and chasing the '<<' tab across the screen breaks an
> elementary ergonomics rule for toggles and is very bad for accessibility, as
> well as extremely annoying.

Fully seconded !

The side bar is horribly limitating and should never have been designed this
way in the first place. Like all power users, role-players, builders, I want
to be able to define my own layout for the UI, has well as what amount of
space I want to dedicate to each function, and the floaters are exactly what
permit this.

I also want to be able to do several things at the same time, like having a
friends list open on my screen while examining the profile(s) of an(/some)
avatar(s), some of the groups they pertain to (thus having the group info
floater open too) and be able to still open my invetory (for example to give
them some items). This is impossible to do with the side bar.

> Given that the sidebar has so many problem and no advantages that have ever
> been defended, I suggest that the work should start by the sidebar advocates
> explaining the benefits that they see in the sidebar.  Since this is an open
> development project, the community can weigh the advantages of the sidebar
> against its disadvantages, and if the advantages are lacking then the
> sidebar can be dropped and filed under "bad idea", or at least made
> optional.

Indeed. The user should be the one able to decide in the first place. If
some want their side bar, so be it, but don't *force* it down others'
throat and let us have an option to disable it entirely, which also means
preserving individual floaters for each function in the side bar !

> Although some people will probably suggest that the *real* likelihood of
> getting the sidebar dropped is nil,

You can bet that should I develop a v2.0 Cool SL Viewer branch, the *first*
thing I'll drop in it is precisely this side bar thing !...

Whether or not I'll develop a v2.0 branch depends on how much work will be
needed to revert the whole UI (yes !) to the one currently existing in the
Cool SL Viewer (which is a (much) improved, pre-voice UI).

So, if LL really cares about third parties viewers that can "fill the gap"
and propose an alternative to their oldest users (who are also their regular
and most committed *customers* and made them earn *a lot of money* during
the years they used SL), they should let a chance for us developers to
revert things without having to rewrite the whole code for the UI logic:
LL should bear in mind that our *benevolent* work is limited in amount by
the "free time" we can dedicate aside from our RL work and life.

But in fact, if LL really cares about their *current* user base, they should
*seriously* consider providing the old UI as an alternative, switchable
"skin" (more than just a skin, of course) in the official viewer v2.0...

> I think we should take the moral high ground here and assume that the
> sidebar too is subject to community feedback.  Let's assume that this is
> an open development project in which advice from the community is
> considered seriously and in which engineering judgment and commonsense
> will prevail.

If only the develoment of viewer 2.0 had been made into the open (like a
truly Open Source software), this fiasco with the new UI won't have
happened in the first place, and LL could have invested their money better
than what they did. My guess is that since money is the key and they will
not want to spend more on viewer 2.0, they will refuse to hear about their
faithful users (and paying customers !) complaints... In the end, it will
mean less users on the grid, less revenues for the merchants, and less
money in LL's many and bottomless pockets... It already has been the case
in the past (and lead to a stagnation of the active users base during the
past two years: just check the "Logged in last 60 days" figure: it was
ab

Re: [opensource-dev] Request for clarification on mailing list guidelines

[Argent Stonecutter]

On 2010-03-23, at 00:12, Philippe (Merov) Bossut wrote:
> - Forum: there is actually one for Open Source 
> (https://blogs.secondlife.com/community/forums/open-source 
> ). I know that some folks at LL prefers this at it allows to create  
> topics and sub threads more easily. I went there today and posted in  
> some discussions. I think it's something we should use for specific  
> discussions that would hijack the mailing list but are not mature  
> for JIRA yet. Thoughts?


If this was still the old forums, that would be great, but the new  
forum software is just so painful to use...
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Development project: extending avatar wearables

[Argent Stonecutter]

On 2010-03-23, at 05:50, Henri Beauchamp wrote:
> Whether or not I'll develop a v2.0 branch depends on how much work  
> will be
> needed to revert the whole UI (yes !) to the one currently existing  
> in the
> Cool SL Viewer (which is a (much) improved, pre-voice UI).

As in, would it be easier to do that or to track the actual feature  
improvements in the new viewer?
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Third party viewer policy: commencement date

[Boy Lane]

I've put my summary about TVP on my blog 
http://my.opera.com/boylane/blog/linden-labs-final-3rd-party-viewer-policy-tpv


Linden Lab's final 3rd Party Viewer Policy (TPV)
TUESDAY, 23. MARCH 2010, 19:15:03

A lot of things are changing, I've voiced my opinion several times, and I want 
to summarize here what I think about Linden Lab's 3rd Party Viewer Policy (TVP) 
that can be found here: Policy on Third-Party Viewers | Second Life 

Under assumption of common sense LL produced guidelines that should regulate 
and control the way people can connect to their service, that is the SecondLife 
grid. Guidelines which would be correct under the aspect of common sense and I 
believe LL came from that perspective by initially creating that guidelines in 
form of the 3rd Party Viewer Policy. 

What went wrong? They gave it in the hands of JohnDoe Linden lawyers who 
obviously missed the subject completley and overstepped ridiculously. But let's 
get down to the roots. 

Basically there are 2 core things very wrong with it. Initially LL requires 
everyone to comply to the GPL licensing. Which is fine as that sets the 
context. The GPL clearly states a developer has no warranty or liability for 
the code whatsover, even if that means ones viewer starts a nuclear war against 
former Soviet Russia or China or both. That clause is included in every single 
file of sourcecode (not the part about the Russians or Chinese ). LL 
explicitely disclaims any liability themselves for the resulting world war but 
then puts exactly that liability back on the shoulders of anyone developing a 
viewer. 

Not only that, by complying to their TPV a developer would also accept 
universal responsibility for all and everything "viewer". To be exact, as a 
developer "You assume all risks, expenses, and defects of any Third-Party 
Viewers that you use, develop, or distribute." A viewer does not even need to 
be able or connect to SL for that. 

In this regard it does not matter if a JohnDoe Linden comments on a mailing 
list or if a legally not binding FAQ tells us that this would be only for usage 
by connecting to the SL grid. It is not. TPV in it's current form says "I'm 
responsible (read: guilty) for using, developing or distributing any 3rd party 
viewer". 

Already by simply developing I'm assuming full responsibility for everything. I 
could take the official LL sources and compile and distribute a sourcewise 
identical "official" viewer, without changing a single line of code; but with 
all the bugs and vulnerabilities *made by LL*. Guilty by TPV. It's really 
ridiculous. 

This is a clear violation of the in the first place by LL required GPL 
licensing. It puts further restrictions on developers GPL explicitly prohibits. 

Another point of concern, putting up the RL details (which is pointless as LL 
has them already and require them by ToS) is required for a listing in the 
viewer directory. The details of the two guinea pigs who registered (Kirsten's, 
Metabolt) were promptly published for a day before someone in LL pressed the 
emergency button. But that was not the first time that LL distributed private 
details. 

In summary, the policy is legal-technical flawed and not acceptable by any dev 
in their right mind. What it will achieve is the destruction of any *legal* 3rd 
party viewer; which probably is the (by some welcomed) goal of LL to 
close-source the viewer. It will not do anything to stop malicious clients to 
flourish, the Neils give a shit on policies or licenses. 

The consequence is that no 3rd party developer that uses LL's GPLed sources 
(including already registered KLee or famed Emerald) can produce a legitimate 
viewer that is either compliant to GPL and/or violates TPV (which says it must 
be GPL compliant). Both are mutually exclusive and LL created a nice legal 
chicken and egg scenario. 

In my opinion there are only 3 possible solutions: 
1) use LL's code and violate TPV 
2) create a viewer from scratch using BSD or another license and comply to TPV 
3) stop developing 3rd party viewers 

Linden Lab already said they do not plan to update their policy again. 
Therefore only option 3 remains. 

Luv, 
Boy


  - Original Message - 
  From: Joe Linden 
  To: Ryan McDougall 
  Cc: Argent Stonecutter ; Boy Lane ; opensource-dev@lists.secondlife.com 
  Sent: Monday, March 22, 2010 3:53 AM
  Subject: Re: [opensource-dev] Third party viewer policy: commencement date


  As I've stated repeatedly, the TPV policy governs viewers that connect to the 
SL grid.  The policy document as worded is explicit about the requirements for 
developers and for users of TPVs that connect to the SL grid.

  That probably sums up what I have to say about it today, so I'm only 
admitting that I'm going to use the rest of this Sunday to get some fresh air.

  Cheers,
  -- joe


  On Sun, Mar 21, 2010 at 12:47 PM, Ryan McDougall  wrote:

So for any malicious viewer developer, all he needs to do to avoid
sanction under

Re: [opensource-dev] 32 bit Official viewer 2 beta, Snowglobe binary (rev 3229) does't run 'out of the box'

[Carlo Wood]

That is the same error as one gets with (32bit) skype
when running it on 64bit debian. The work around there
is to make the audiopulse libs unreadable (chmod -r)
so that they are skipped.

It smells like an OS bug because it seems related to
64bit systems only? Ie, a lib32* package needs a fix?

On Mon, Mar 22, 2010 at 01:44:49PM -0700, Dzonatas Sol wrote:
> This is the error right after one types in "./snowglobe" or
> "./secondlife" to run the startup script:
> Inconsistency detected by ld.so: dl-open.c: 643: _dl_open: Assertion
> `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT'
> failed!
> 
> Note that libwrap does exist in lenny or squeeze, only in etch and
> sid: http://packages.debian.org/etch/libwrap-dev
> 
> 
> With "LD_DEBUG=versions", here is part of the output:
> 
> 19683:   19683:   19683:calling init:
> /home/dzonatas/Desktop/S/Snowglobe-i686-1.4.0.0/lib/libopenal.so.1
> 19683:   Inconsistency detected by ld.so: dl-open.c: 643:
> _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state ==
> RT_CONSISTENT' failed!
> *** Bad shutdown. ***
> 19684:checking for version `GLIBC_2.3' in file
> /lib/libc.so.6 [0] required by file uname [0]
> 19684:checking for version `GLIBC_2.2.5' in file
> /lib/libc.so.6 [0] required by file uname [0]
> 19684:checking for version `GLIBC_PRIVATE' in file
> /lib64/ld-linux-x86-64.so.2 [0] required by file /lib/libc.so.6 [0]
> 19684:checking for version `GLIBC_2.3' in file
> /lib64/ld-linux-x86-64.so.2 [0] required by file /lib/libc.so.6 [0]
> 19684:   19684:calling init: /lib/libc.so.6
> 
> 
> 
> With "LD-DEBUG=versions,libs", here is part of the output:
> 
> 
> 19583: 19583:find library=libwrap.so.0 [0];
> searching
> 19583: search 
> path=/home/dzonatas/Desktop/S/Snowglobe-i686-1.4.0.0/lib:tls/i686/sse2/cmov:tls/i686/sse2:tls/i686/cmov:tls/i686:tls/sse2/cmov:tls/sse2:tls/cmov:tls:i686/sse2/cmov:i686/sse2:i686/cmov:i686:sse2/cmov:sse2:cmov:
> (LD_LIBRARY_PATH)
> 19583:  trying
> file=/home/dzonatas/Desktop/S/Snowglobe-i686-1.4.0.0/lib/libwrap.so.0
> 19583:  trying file=tls/i686/sse2/cmov/libwrap.so.0
> 19583:  trying file=tls/i686/sse2/libwrap.so.0
> 19583:  trying file=tls/i686/cmov/libwrap.so.0
> 19583:  trying file=tls/i686/libwrap.so.0
> 19583:  trying file=tls/sse2/cmov/libwrap.so.0
> 19583:  trying file=tls/sse2/libwrap.so.0
> 19583:  trying file=tls/cmov/libwrap.so.0
> 19583:  trying file=tls/libwrap.so.0
> 19583:  trying file=i686/sse2/cmov/libwrap.so.0
> 19583:  trying file=i686/sse2/libwrap.so.0
> 19583:  trying file=i686/cmov/libwrap.so.0
> 19583:  trying file=i686/libwrap.so.0
> 19583:  trying file=sse2/cmov/libwrap.so.0
> 19583:  trying file=sse2/libwrap.so.0
> 19583:  trying file=cmov/libwrap.so.0
> 19583:  trying file=libwrap.so.0
> 19583: search cache=/etc/ld.so.cache
> 19583: search 
> path=/lib32/tls/i686/sse2/cmov:/lib32/tls/i686/sse2:/lib32/tls/i686/cmov:/lib32/tls/i686:/lib32/tls/sse2/cmov:/lib32/tls/sse2:/lib32/tls/cmov:/lib32/tls:/lib32/i686/sse2/cmov:/lib32/i686/sse2:/lib32/i686/cmov:/lib32/i686:/lib32/sse2/cmov:/lib32/sse2:/lib32/cmov:/lib32:/usr/lib32/tls/i686/sse2/cmov:/usr/lib32/tls/i686/sse2:/usr/lib32/tls/i686/cmov:/usr/lib32/tls/i686:/usr/lib32/tls/sse2/cmov:/usr/lib32/tls/sse2:/usr/lib32/tls/cmov:/usr/lib32/tls:/usr/lib32/i686/sse2/cmov:/usr/lib32/i686/sse2:/usr/lib32/i686/cmov:/usr/lib32/i686:/usr/lib32/sse2/cmov:/usr/lib32/sse2:/usr/lib32/cmov:/usr/lib32:/lib/i486-linux-gnu/tls/i686/sse2/cmov:/lib/i486-linux-gnu/tls/i686/sse2:/lib/i486-linux-gnu/tls/i686/cmov:/lib/i486-linux-gnu/tls/i686:/lib/i486-linux-gnu/tls/sse2/cmov:/lib/i486-linux-gnu/tls/sse2:/lib/i486-linux-gnu/tls/cmov:/lib/i486-linux-gnu/tls:/lib/i486-linux-gnu/i686/sse2/cmov:/lib/i486-linux-gnu/i686/sse2:/lib/i486-linux-gnu/i686/cmov:/lib/i486-linux-gnu/i686:/lib/i486-linux-gnu/sse2/cmov:/lib/i486-linux-gnu/sse2
> :/lib/i486-linux-gnu/cmov:/lib/i486-linux-gnu:/usr/lib/i486-linux-gnu/tls/i686/sse2/cmov:/usr/lib/i486-linux-gnu/tls/i686/sse2:/usr/lib/i486-linux-gnu/tls/i686/cmov:/usr/lib/i486-linux-gnu/tls/i686:/usr/lib/i486-linux-gnu/tls/sse2/cmov:/usr/lib/i486-linux-gnu/tls/sse2:/usr/lib/i486-linux-gnu/tls/cmov:/usr/lib/i486-linux-gnu/tls:/usr/lib/i486-linux-gnu/i686/sse2/cmov:/usr/lib/i486-linux-gnu/i686/sse2:/usr/lib/i486-linux-gnu/i686/cmov:/usr/lib/i486-linux-gnu/i686:/usr/lib/i486-linux-gnu/sse2/cmov:/usr/lib/i486-linux-gnu/sse2:/usr/lib/i486-linux-gnu/cmov:/usr/lib/i486-linux-gnu
> (system search path)
> 19583:  trying file=/lib32/tls/i686/sse2/cmov/libwrap.so.0
> 19583:  trying file=/lib32/tls/i686/sse2/libwrap.so.0
> 19583:  trying file=/lib32/tls/i686/cmov/libwrap.so.0
> 19583:  trying file=/lib32/tls/i68

[opensource-dev] Client 2.0 - sidebar (was: Re: Open Development project: extending avatarwearables)

[tillie]

Bryon Ruxton  wrote ..

> Could you please stop putting everything into that sidebar as the only way
> to access stuff.

Yah, it's just bad. Have a look at the Adobe Creative Suite UIs. You can hide 
any single submenu or entry, you can mark each one with one of several colors, 
you can move around all the windows, make them single floaters outside the main 
window or be part of the main window container, you can dock them on any side, 
you can 'stack' them so you have them tabbed, you can even create your own 
windows with the menu entries you really need.

A static (and not general usability rules following) UI is bad. Everyone has 
it's own needs. And the translations make it even worse. Where Ctrl-` for a 
snapshot becomes Ctrl-ö on the german keyboard, where something like Ctrl-y 
would be so much better because usable with one hand.

Naybe you wanted to clean up the clutter of all the different windows by 
stacking them into the right bar... but with all the small notice popups and 
the additional "you just declined xy " windows the screen clutter got even 
WORSE than in the 1.23 clients. :-(

Tillie
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Development project: extending avatar wearables

[Aleric Inglewood]

On Tue, Mar 23, 2010 at 7:57 AM, Morgaine wrote:

> Although some people will probably suggest that the *real* likelihood of
> getting the sidebar dropped is nil, I think we should take the moral high
> ground here and assume that the sidebar too is subject to community
> feedback.  Let's assume that this is an open development project in which
> advice from the community is considered seriously and in which engineering
> judgment and commonsense will prevail.
>

I know that emerald plans to make all those horrible changes optional and
thereby greatly improve the UI. I'm sure that almost everyone (all old users
for sure) will like their UI more than the UI of 2.0.

LL will not be able to take that code from emerald and use it themselves,
because of the user agreement stuff.

That kinda renders using an open source model useless. Can't benefit from
using the GPL. And what about snowglobe? Can we take the patches from
emerald
and put them in snowglobe? I mean, legally we can (we are GPL-ed), but will
LL allow that?
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] [META] Communication tools (was: Request for clarification on mailing list guidelines)

[Boroondas Gupte]

On 03/23/2010 06:12 AM, Philippe (Merov) Bossut wrote:
> - Mailing list: may be the most widely used tool. The problem I see
> with it is that it mixes everything: small requests, long discussions,
> policies, technicalities, etc... Other FLOSS projects use a variety of
> lists, breaking things in categories (Mozilla for instance). It tends
> to become another kind of mess with cross posting.
Mailman seems to allow to define several topic categories for each list.
Here's what you see when you edit your subscription:
>> *Which topic categories would you like to subscribe to?*
>>
>> By selecting one or more topics, you can filter the traffic on the
>> mailing list, so as to receive only a subset of the messages. If a
>> message matches one of your selected topics, then you will get the
>> message, otherwise you will not.
>>
>> If a message does not match any topic, the delivery rule depends on
>> the setting of the option below. If you do not select any topics of
>> interest, you will get all the messages sent to the mailing list.
>>
>>  /No topics defined/
>> *Do you want to receive messages that do not match any topic filter?*
>>
>> This option only takes effect if you've subscribed to at least one
>> topic above. It describes what the default delivery rule is for
>> messages that don't match any topic filter. Selecting /No/ says that
>> if the message does not match any topic filters, then you won't get
>> the message, while selecting /Yes/ says to deliver such non-matching
>> messages to you.
>>
>> If no topics of interest are selected above, then you will receive
>> every message sent to the mailing list.
>>
>>  No
>> Yes
>>
I've never seen this feature in use, but I guess a message can match
several topic filters at once. So if all topics of a given message are
on the same list, there's no need for cross-posting (and still only
those interested in the topic(s) would get the message).
> Yes, Gmail rocks and threaded discussions a god send but still...
Thunderbird isn't bad for it, either. I guess other sufficently advaned
email clients work similarly well.

> - wiki: it's one we underuse. The problem is that it needs a lot of
> wiki gardening and things can simply die there with no clear resolution.
The wiki format is great for documentation of both, ideas/plans and
facts, and for discussing that documentation. I feel it's less suited
for discussing the documented subjects themselves, though I can't really
explain why that is.

> - IW meetings: we have our weekly Hippo meeting and I truly encourage
> folks to come. It's my favorite comm tool personally as it's a
> dedicated moment and we have full attention of everyone. Should we do
> more of this?
If there were several meetings per week, most would probably choose to
only visit one of them, and would have to read the transcripts to keep
up with what's been discussed at the other one(s). If they then want to
comment on something said at a meeting they didn't attend, it gets
complicated and the discussion would probably have to continue on the
mailing list or on the forum.

Maybe the length of the meeting should be adaptable depending on the
agenda. Though, we then should be able to drop non-pressing topics or
reschedule them for less busy weeks, so that the meeting length doesn't
increase out of control. I'd suggest to always keep it between half an
hour and two hours.

> - Forum: there is actually one for Open Source
> (https://blogs.secondlife.com/community/forums/open-source). I know
> that some folks at LL prefers this at it allows to create topics and
> sub threads more easily. I went there today and posted in some
> discussions. I think it's something we should use for specific
> discussions that would hijack the mailing list but are not mature for
> JIRA yet. Thoughts?
I'm not totally opposed to use the forum, but I'd like to see some
details fixed first, that'd make it a more pleasant experience. WEB-1429
, WEB-1447
 and WEB-1399
 are some of those.

cheers
Boroondas
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Request for clarification on mailing list guidelines

[Aleric Inglewood]

Having the IW meetings always at the same time and the same day of the week
locks some people out.

Me for example. I can never attend on Thursdays. I'd really appreciate it
if it was possible to have the meetings regularly on another day of the
week. Maybe every two weeks on thursdays and every two weeks on
another day (preferably later, too).

On Tue, Mar 23, 2010 at 6:12 AM, Philippe (Merov) Bossut <
me...@lindenlab.com> wrote:

> - IW meetings: we have our weekly Hippo meeting and I truly encourage folks
> to come. It's my favorite comm tool personally as it's a dedicated moment
> and we have full attention of everyone. Should we do more of this?
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 32 bit Official viewer 2 beta, Snowglobe binary (rev 3229) does't run 'out of the box'

[Dzonatas Sol]

I found a workable solution.

$ mkdir /tmp/extralibs
$ wget 
http://ftp.us.debian.org/debian/pool/main/g/gdbm/libgdbm3_1.8.3-3_i386.deb
$ wget 
http://ftp.us.debian.org/debian/pool/main/t/tcp-wrappers/libwrap0_7.6.q-16_i386.deb
$ dpkg -x libgdbm3_1.8.3-3_i386.deb /tmp/extralibs
$ dpkg -x libwrap0_7.6.q-16_i386.deb /tmp/extralibs
$ cd YOURSNOWGLOBEDIR
$ cp /tmp/extralibs/lib/* lib
$ cp /tmp/extralibs/usr/lib/* lib

32 bit Snowglobe 1.4+ binaries then work on Debian Lenny 64

Carlo Wood wrote:
> That is the same error as one gets with (32bit) skype
> when running it on 64bit debian. The work around there
> is to make the audiopulse libs unreadable (chmod -r)
> so that they are skipped.
>
> It smells like an OS bug because it seems related to
> 64bit systems only? Ie, a lib32* package needs a fix?
>
>   

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client 2.0 - sidebar (was: Re: Open Development project: extending avatarwearables)

[Jonathan Irvin]

As I've said before, If you don't like it, fix it.  The code is there so
think up something more useful and do it.  Giving an example is a great
idea.  I use the adobe suite often; however, the Lindens already have spent
plenty of money with a design company to get the look that they want.

Switching to the 1.23 design isn't available yet so giving that as an option
for 2.x isn't there yet.  So, use the 2.0 design.

Jonathan Irvin


On Tue, Mar 23, 2010 at 08:28,  wrote:

> Bryon Ruxton  wrote ..
>
> > Could you please stop putting everything into that sidebar as the only
> way
> > to access stuff.
>
> Yah, it's just bad. Have a look at the Adobe Creative Suite UIs. You can
> hide any single submenu or entry, you can mark each one with one of several
> colors, you can move around all the windows, make them single floaters
> outside the main window or be part of the main window container, you can
> dock them on any side, you can 'stack' them so you have them tabbed, you can
> even create your own windows with the menu entries you really need.
>
> A static (and not general usability rules following) UI is bad. Everyone
> has it's own needs. And the translations make it even worse. Where Ctrl-`
> for a snapshot becomes Ctrl-ö on the german keyboard, where something like
> Ctrl-y would be so much better because usable with one hand.
>
> Naybe you wanted to clean up the clutter of all the different windows by
> stacking them into the right bar... but with all the small notice popups and
> the additional "you just declined xy " windows the screen clutter got
> even WORSE than in the 1.23 clients. :-(
>
> Tillie
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 32 bit Official viewer 2 beta, Snowglobe binary (rev 3229) does't run 'out of the box'

[Robin Cornelius]

On Tue, Mar 23, 2010 at 3:36 PM, Dzonatas Sol  wrote:
> I found a workable solution.
>
> $ mkdir /tmp/extralibs
> $ wget
> http://ftp.us.debian.org/debian/pool/main/g/gdbm/libgdbm3_1.8.3-3_i386.deb
> $ wget
> http://ftp.us.debian.org/debian/pool/main/t/tcp-wrappers/libwrap0_7.6.q-16_i386.deb
> $ dpkg -x libgdbm3_1.8.3-3_i386.deb /tmp/extralibs
> $ dpkg -x libwrap0_7.6.q-16_i386.deb /tmp/extralibs
> $ cd YOURSNOWGLOBEDIR
> $ cp /tmp/extralibs/lib/* lib
> $ cp /tmp/extralibs/usr/lib/* lib
>
> 32 bit Snowglobe 1.4+ binaries then work on Debian Lenny 64


Can we wiki this somewhere? would be handy to keep any compatability
work arounds documented somewhere.

Regards

Robin
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] [META] Communication tools

[Dzonatas Sol]

Boroondas Gupte wrote:
> On 03/23/2010 06:12 AM, Philippe (Merov) Bossut wrote:
>> - Mailing list: may be the most widely used tool. The problem I see 
>> with it is that it mixes everything: small requests, long 
>> discussions, policies, technicalities, etc... Other FLOSS projects 
>> use a variety of lists, breaking things in categories (Mozilla for 
>> instance). It tends to become another kind of mess with cross posting.
>> Yes, Gmail rocks and threaded discussions a god send but still...
> Thunderbird isn't bad for it, either. I guess other sufficently 
> advaned email clients work similarly well.
>

Thunderbird is whole reason why to keep discussions on a mail-list. The 
web-based forums (or gmail) just don't compare with the versatility, 
accessibility, and speed of Thunderbird.

I do agree both the web-based forums and mail-list should be used at 
their fullest. I think the more technical content discussions should be 
kept to the mail-list and policy based discussions can be moved to the 
web-forums.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 32 bit Official viewer 2 beta, Snowglobe binary (rev 3229) does't run 'out of the box'

[Dzonatas Sol]

Robin Cornelius wrote:
> On Tue, Mar 23, 2010 at 3:36 PM, Dzonatas Sol  wrote:
>   
>> I found a workable solution.
>>
>> $ mkdir /tmp/extralibs
>> $ wget
>> http://ftp.us.debian.org/debian/pool/main/g/gdbm/libgdbm3_1.8.3-3_i386.deb
>> $ wget
>> http://ftp.us.debian.org/debian/pool/main/t/tcp-wrappers/libwrap0_7.6.q-16_i386.deb
>> $ dpkg -x libgdbm3_1.8.3-3_i386.deb /tmp/extralibs
>> $ dpkg -x libwrap0_7.6.q-16_i386.deb /tmp/extralibs
>> $ cd YOURSNOWGLOBEDIR
>> $ cp /tmp/extralibs/lib/* lib
>> $ cp /tmp/extralibs/usr/lib/* lib
>>
>> 32 bit Snowglobe 1.4+ binaries then work on Debian Lenny 64
>> 
>
>
> Can we wiki this somewhere? would be handy to keep any compatability
> work arounds documented somewhere.
>
> Regards
>
> Robin
>
>   
Added here:

https://wiki.secondlife.com/wiki/User:Dzonatas_Sol/Snowglobe#Snowglobe_32_bit_Compatibility_on_Debian_Lenny_64

Thanks for the help and suggestions, everyone!
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Open Development project: extending avatar wearables

[Nyx Linden]

  The current iteration of the appearance floater needs to go away. The 
current implementation has been held together with chicken wire, bubble 
gum, and duct tape. It works for now, but it won't hold up to the 
addition of multiple wearables of a given type. The currently designed 
plan is to extend the appearance sidebar to pick up the extra 
functionality of editing a saved outfit and editing of individual 
wearables. I think the flow between the different stages (selecting your 
outfit, editing your outfit, editing a wearable item) should be pretty 
useful and intuitive. I'll be posting our initial design thoughts once 
we get the appropriate channels set up (forums most likely).

I will remind you, however, that this project is specifically about 
extending the avatar functionality. Yes there is a UI element here, and 
I'm open to discussion of various ways of presenting the UI for these 
specific features, given that the ideas are 1) easy to use and intuitive 
and 2) still able to be done within the given timeframe.

It sounds, however that you're asking for the ability to "tear off" any 
of the sidepanels into independent floaters. This is good feedback, and 
a perspective that a number of residents share, but this project is not 
the one that is capable of doing that. We have a design team and a 
"Viewer interactive" team that is in charge of the overall design and 
GUI implementation of the major elements of the viewer. I'm pretty sure 
that they're already aware of this feedback, but I'll send it their way 
again.

Let's keep discussion of the multi-wearables functionality on-target, 
please :)

-Nyx

Bryon Ruxton wrote:
> Could you please stop putting everything into that sidebar as the only 
> way to access stuff. You’ve kept wanting to make this “communicator 
> window “ before into a single un-detachable block. And despite many of 
> use hating it and asking for you to make separate floaters, (or at 
> least give us that option), you keep attaching everything all together 
> again in that sidebar. This is an ill conceived approach for many of 
> us, who are used to identify specific panels at a specific position of 
> our choice on the screen just like . Blending it all together makes it 
> harder in that sense.
>
> I recall LL hiring a guy who worked on the Tivo interface which is a 
> great one for its purpose. But the viewer is a much more complex 
> interface. I see too much of the Tivo formula into this “drawer”. The 
> worse part is that the sidebar buttons are stuck on the left side and 
> actual move with the sidebar panel itself. That seems wrong. Button 
> should stay at the same place on the right in an Adobe fashion for 
> distinction purpose.
>
> I wish you had studied and adopted the approach of the Adobe UIs with 
> stackable and detachable panels and buttons on the right side (which 
> always stay there). Their approach is a much better solution in my 
> view that this drawer type, which is a huge waste of space right now 
> and adding to the required amount of clicks to get somewhere.
>
> In short, please reserve an option for detachable floaters as much as 
> possible, and please
> consider the Adobe approach for a more flexible and customizable 
> sidebar(s) for Version 2.x.x
>
> Thank you
>
> On 3/22/10 8:06 PM, "Nyx Linden"  wrote:
>
> Good question! There is still a lot of detail left out of these
> descriptions, but we are planning on moving the UI in the
> appearance editor into the sidebar, along with creating a new
> outfit editor UI. You will still see the results of the changes
> you are making on your avatar in-world in real time. There will
> still be an "editing appearance" mode as you have now, it will
> just be accompanied by a panel in the sidebar instead of a
> separate floater.
>
> - Nyx
>
> On Mon, Mar 22, 2010 at 6:56 PM, Argent Stonecutter
>  wrote:
>
>
> On 2010-03-22, at 12:45, Nyx Linden wrote:
>
> 1) A new panel to edit what is stored in your saved outfit
> without
> creating a new one.
> This will include both an inventory view and a view of
> your outfit
> itself, so you can drag items from your inventory to your
> outfit without
> having an extra floater open
> 2) Editing of wearable items (body parts and/or clothing
> objects) in the
> sidebar, selectable from the outfit editor
> 3) Removal of the appearance floater
>
>
> I have a concern about this, where it comes to editing outfits
> containing prim parts. You have to see them in world, you
> can't just edit them in a sidebar window, because you may need
> to edit them with reference to objects in world.
>
> If I'm mistaken about what "removal of the appearance floater"
> means, in the context of a UI designed to allow you to edit
> outfits witho

Re: [opensource-dev] Third party viewer policy: commencement date

[Dahlia Trimble]

I have developed a BSD licensed viewer that is not derived from LL source
code. It is designed and intended for use with OpenSimulator, however since
it uses Linden Lab protocols it is capable of connecting to the Secondlife
grid, although functionality is impaired. I have no intention of making it
compliant with the TPV as *I never intended it to be used with SL*. However,
upon reading the TPV, it looks as though a possible interpretation may be
that my SL membership status may be at risk if someone (outside of my
control) uses the viewer to connect to SL and subsequently causes some
misfortune to another party, and that LL may wish to pursue legal remedies
against me as the developer of this viewer. As the viewer has been published
under a BSD style license long before the TPV came into existence. and I
have no control over already distributed copies and derivatives, and I have
no intention of stopping distribution, could my SL account be at risk, and
should I assume LL may attempt legal remedies against me for any unintended
use of this viewer?


On Tue, Mar 23, 2010 at 5:34 AM, Boy Lane  wrote:

>  I've put my summary about TVP on my blog
> http://my.opera.com/boylane/blog/linden-labs-final-3rd-party-viewer-policy-tpv
>
>
>  Linden Lab's final 3rd Party Viewer Policy (TPV)
> TUESDAY, 23. MARCH 2010, 19:15:03
>
> A lot of things are changing, I've voiced my opinion several times, and I
> want to summarize here what I think about Linden Lab's 3rd Party Viewer
> Policy (TVP) that can be found here: Policy on Third-Party Viewers |
> Second Life 
>
> Under assumption of common sense LL produced guidelines that should
> regulate and control the way people can connect to their service, that is
> the SecondLife grid. Guidelines which would be correct under the aspect of
> common sense and I believe LL came from that perspective by initially
> creating that guidelines in form of the 3rd Party Viewer Policy.
>
> What went wrong? They gave it in the hands of JohnDoe Linden lawyers who
> obviously missed the subject completley and overstepped ridiculously. But
> let's get down to the roots.
>
> Basically there are 2 core things very wrong with it. Initially LL requires
> everyone to comply to the GPL licensing. Which is fine as that sets the
> context. The GPL clearly states a developer has no warranty or liability for
> the code whatsover, even if that means ones viewer starts a nuclear war
> against former Soviet Russia or China or both. That clause is included in
> every single file of sourcecode (not the part about the Russians or Chinese
> ). LL explicitely disclaims any liability themselves for the resulting world
> war but then puts exactly that liability back on the shoulders of anyone
> developing a viewer.
>
> Not only that, by complying to their TPV a developer would also accept
> universal responsibility for all and everything "viewer". To be exact, as a
> developer "You assume all risks, expenses, and defects of any Third-Party
> Viewers that you use, develop, or distribute." A viewer does not even need
> to be able or connect to SL for that.
>
> In this regard it does not matter if a JohnDoe Linden comments on a mailing
> list or if a legally not binding FAQ tells us that this would be only for
> usage by connecting to the SL grid. It is not. TPV in it's current form
> says "I'm responsible (read: guilty) for using, developing or distributing
> any 3rd party viewer".
>
> Already by simply developing I'm assuming full responsibility for
> everything. I could take the official LL sources and compile and distribute
> a sourcewise identical "official" viewer, without changing a single line of
> code; but with all the bugs and vulnerabilities *made by LL*. Guilty by TPV.
> It's really ridiculous.
>
> This is a clear violation of the in the first place by LL required GPL
> licensing. It puts further restrictions on developers GPL explicitly
> prohibits.
>
> Another point of concern, putting up the RL details (which is pointless as
> LL has them already and require them by ToS) is required for a listing in
> the viewer directory. The details of the two guinea pigs who registered
> (Kirsten's, Metabolt) were promptly published for a day before someone in LL
> pressed the emergency button. But that was not the first time that LL
> distributed private details.
>
> In summary, the policy is legal-technical flawed and not acceptable by any
> dev in their right mind. What it will achieve is the destruction of any
> *legal* 3rd party viewer; which probably is the (by some welcomed) goal of
> LL to close-source the viewer. It will not do anything to stop malicious
> clients to flourish, the Neils give a shit on policies or licenses.
>
> The consequence is that no 3rd party developer that uses LL's GPLed sources
> (including already registered KLee or famed Emerald) can produce a
> legitimate viewer that is either compliant to GPL and/or violates TPV (which
> says it must be 

Re: [opensource-dev] Open Development project: extending avatar wearables

[Robert Martin]

On Tue, Mar 23, 2010 at 12:58 PM, Nyx Linden  wrote:
>  The current iteration of the appearance floater needs to go away. The
> current implementation has been held together with chicken wire, bubble
> gum, and duct tape. It works for now, but it won't hold up to the
> addition of multiple wearables of a given type.

I just had something of a wild idea
there exists 2 semi related programs that would be perfect to do this
and while the back end stuff would be "fun to do" 95% of the actual
program is already done

Poser and of course Daz Studio
Stuff needed
1 the various morphs need to be converted to Poser format
2 the clothing items need to be rebuilt as Poser items (with morphs)
3 some sort of export plugin needs to be created (or a Poser import
plugin needs to be made for SL)
4 whatever i forgot
N ect audnauseum
-- 
Robert L Martin
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Backports vs code reversal (was: Re: Open Development project: extending avatar wearables)

[Henri Beauchamp]

On Tue, 23 Mar 2010 06:16:32 -0500, Argent Stonecutter wrote:

> On 2010-03-23, at 05:50, Henri Beauchamp wrote:
> > Whether or not I'll develop a v2.0 branch depends on how much work  
> > will be needed to revert the whole UI (yes !) to the one currently
> > existing in the Cool SL Viewer (which is a (much) improved, pre-voice
> > UI).
>
> As in, would it be easier to do that or to track the actual feature  
> improvements in the new viewer?

Backporting the new features of viewer 2.0 to v1.23 is extremely tedious
although not impossible.

I already backported the Alpha and Tattoo support to v1.23 (and I hope soon
to v1.19: still a glitch to solve dealing with rendering within v1.19: it's
ok for baked textures sent to the server from v1.19 but for now Alphas
don't render properly in v1.19 itself), and I may also backport inventory
links and the new script functions, but doing more would prove very
difficult given the enormous amount of code changes that occurred between
v1.23 and v2.0 (with lots of changes to the C++ objects and their API):
just to give you a small idea, the diff between v1.23 and v2.0 is over 24Mb
large (and that's only the diff for the .cpp, .h and main (en-us) .xml
files)...

With my experience of the backports I did from v1.2x viewers to v1.19
(with very significant changes as well between them since v1.19 was
pre-Windlight), I can tell you it is not exactly an easy task (but it
was worth maintaining v1.19 for so long since it still represents almost
half of the downloads for the Cool SL Viewer, showing how many "old
computer" users were left in the blue by LL with the move to Windlight).

It would be easier for me to move on to v2.0 (like I did so far with the
main branch of the Cool SL Viewer, moving to v1.20, then 1.21, 1.22 and
1.23), but only as long as LL doesn't break all what existed in the v1.23
UI...

My free time is not infinite, by far, and reverting very large chunks
of code leads to many troubles each time the official viewer is updated
(for example from v2.0 to v2.1)...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Request for clarification on mailing list guidelines

[Philippe (Merov) Bossut]

Hi,

On Tue, Mar 23, 2010 at 7:12 AM, Aleric Inglewood <
aleric.inglew...@gmail.com> wrote:

> Having the IW meetings always at the same time and the same day of the week
> locks some people out.
>
> Me for example. I can never attend on Thursdays. I'd really appreciate it
> if it was possible to have the meetings regularly on another day of the
> week. Maybe every two weeks on thursdays and every two weeks on
> another day (preferably later, too).
>

Having a 2nd meeting in the week is something I'd be willing to try so to
accommodate more folks. Since we have one on Thursday, we could have another
one on Tuesday. But, later? Didn't you meant "earlier"?

Cheers,
- Merov
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Backports vs code reversal (was: Re: Open Development project: extending avatar wearables)

[Argent Stonecutter]

On 2010-03-23, at 13:30, Henri Beauchamp wrote:
> On Tue, 23 Mar 2010 06:16:32 -0500, Argent Stonecutter wrote:
>> On 2010-03-23, at 05:50, Henri Beauchamp wrote:
>>> Whether or not I'll develop a v2.0 branch depends on how much work
>>> will be needed to revert the whole UI (yes !) to the one currently
>>> existing in the Cool SL Viewer (which is a (much) improved, pre- 
>>> voice
>>> UI).

>> As in, would it be easier to do that or to track the actual feature
>> improvements in the new viewer?

> Backporting the new features of viewer 2.0 to v1.23 is extremely  
> tedious
> although not impossible.

[scary details]

Wow. I'd call that beyond the call of duty.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client 2.0 - sidebar (was: Re: Open Development project: extending avatarwearables)

[Maya Remblai]

Ok, I was trying to be diplomatic, but now I'm going to be frank.

It disturbs me that LL is ignoring how dangerous the shifting behavior 
of the sidebar and the blinking and winking of 2.0 is. Some people have 
already had or come close to having seizures because of it, and people 
without epilepsy are having motion sickness and vertigo. LL has been 
warned about it, especially on the JIRA, but the complaints haven't been 
acknowledged. If LL loves 2.0 so much, the very least they're going to 
have to do is include a video game style seizure warning on startup.

Read the comments on this JIRA entry.
http://jira.secondlife.com/browse/VWR-17249

Here's the meta for all sidebar issues. The comments on most of these 
point out the photosensitivity issue.
http://jira.secondlife.com/browse/VWR-17012

Maya

Maya Remblai wrote:
> All interesting ideas, but it would be prudent to include a floater as 
> an option. Not only will it make things easier on experienced users and 
> those who don't like the sidebar, it will make things easier for the 
> devs making versions of Viewer 2.0 for photo-sensitive people to use 
> without issue.
>
> Maya
>
> Nyx Linden wrote:
>   
>> Good question! There is still a lot of detail left out of these 
>> descriptions, but we are planning on moving the UI in the appearance 
>> editor into the sidebar, along with creating a new outfit editor UI. 
>> You will still see the results of the changes you are making on your 
>> avatar in-world in real time. There will still be an "editing 
>> appearance" mode as you have now, it will just be accompanied by a 
>> panel in the sidebar instead of a separate floater.
>>
>>  - Nyx
>>
>> On Mon, Mar 22, 2010 at 6:56 PM, Argent Stonecutter 
>> mailto:secret.arg...@gmail.com>> wrote:
>>
>>
>> On 2010-03-22, at 12:45, Nyx Linden wrote:
>>
>> 1) A new panel to edit what is stored in your saved outfit without
>> creating a new one.
>>   This will include both an inventory view and a view of your
>> outfit
>> itself, so you can drag items from your inventory to your
>> outfit without
>> having an extra floater open
>> 2) Editing of wearable items (body parts and/or clothing
>> objects) in the
>> sidebar, selectable from the outfit editor
>> 3) Removal of the appearance floater
>>
>>
>> I have a concern about this, where it comes to editing outfits
>> containing prim parts. You have to see them in world, you can't
>> just edit them in a sidebar window, because you may need to edit
>> them with reference to objects in world.
>>
>> If I'm mistaken about what "removal of the appearance floater"
>> means, in the context of a UI designed to allow you to edit
>> outfits without having to wear them, then I'll be happy to be
>> corrected.
>>
>>
>> 
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting 
>> privileges
>> 
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>
>   

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Third party viewer policy: commencement date

[Gareth Nelson]

In other news, an email provider today produced a list of requirements
for third party email client developers - I have an account with them,
but their TOS doesn't mention this list of requirements and they never
mentioned these requirements when I signed up for the account.

Should I worry about them sueing me?

IANAL, but it seems until the TOS is updated AND YOU ACCEPT THE NEW
TOS, this policy is binding on nobody

On Tue, Mar 23, 2010 at 5:28 PM, Dahlia Trimble  wrote:
> I have developed a BSD licensed viewer that is not derived from LL source
> code. It is designed and intended for use with OpenSimulator, however since
> it uses Linden Lab protocols it is capable of connecting to the Secondlife
> grid, although functionality is impaired. I have no intention of making it
> compliant with the TPV as *I never intended it to be used with SL*. However,
> upon reading the TPV, it looks as though a possible interpretation may be
> that my SL membership status may be at risk if someone (outside of my
> control) uses the viewer to connect to SL and subsequently causes some
> misfortune to another party, and that LL may wish to pursue legal remedies
> against me as the developer of this viewer. As the viewer has been published
> under a BSD style license long before the TPV came into existence. and I
> have no control over already distributed copies and derivatives, and I have
> no intention of stopping distribution, could my SL account be at risk, and
> should I assume LL may attempt legal remedies against me for any unintended
> use of this viewer?
>
>
> On Tue, Mar 23, 2010 at 5:34 AM, Boy Lane  wrote:
>>
>> I've put my summary about TVP on my blog
>> http://my.opera.com/boylane/blog/linden-labs-final-3rd-party-viewer-policy-tpv
>>
>>
>> Linden Lab's final 3rd Party Viewer Policy (TPV)
>> TUESDAY, 23. MARCH 2010, 19:15:03
>>
>> A lot of things are changing, I've voiced my opinion several times, and I
>> want to summarize here what I think about Linden Lab's 3rd Party Viewer
>> Policy (TVP) that can be found here: Policy on Third-Party Viewers | Second
>> Life
>>
>> Under assumption of common sense LL produced guidelines that should
>> regulate and control the way people can connect to their service, that is
>> the SecondLife grid. Guidelines which would be correct under the aspect of
>> common sense and I believe LL came from that perspective by initially
>> creating that guidelines in form of the 3rd Party Viewer Policy.
>>
>> What went wrong? They gave it in the hands of JohnDoe Linden lawyers who
>> obviously missed the subject completley and overstepped ridiculously. But
>> let's get down to the roots.
>>
>> Basically there are 2 core things very wrong with it. Initially LL
>> requires everyone to comply to the GPL licensing. Which is fine as that sets
>> the context. The GPL clearly states a developer has no warranty or liability
>> for the code whatsover, even if that means ones viewer starts a nuclear war
>> against former Soviet Russia or China or both. That clause is included in
>> every single file of sourcecode (not the part about the Russians or Chinese
>> ). LL explicitely disclaims any liability themselves for the resulting world
>> war but then puts exactly that liability back on the shoulders of anyone
>> developing a viewer.
>>
>> Not only that, by complying to their TPV a developer would also accept
>> universal responsibility for all and everything "viewer". To be exact, as a
>> developer "You assume all risks, expenses, and defects of any Third-Party
>> Viewers that you use, develop, or distribute." A viewer does not even need
>> to be able or connect to SL for that.
>>
>> In this regard it does not matter if a JohnDoe Linden comments on a
>> mailing list or if a legally not binding FAQ tells us that this would be
>> only for usage by connecting to the SL grid. It is not. TPV in it's current
>> form says "I'm responsible (read: guilty) for using, developing or
>> distributing any 3rd party viewer".
>>
>> Already by simply developing I'm assuming full responsibility for
>> everything. I could take the official LL sources and compile and distribute
>> a sourcewise identical "official" viewer, without changing a single line of
>> code; but with all the bugs and vulnerabilities *made by LL*. Guilty by TPV.
>> It's really ridiculous.
>>
>> This is a clear violation of the in the first place by LL required GPL
>> licensing. It puts further restrictions on developers GPL explicitly
>> prohibits.
>>
>> Another point of concern, putting up the RL details (which is pointless as
>> LL has them already and require them by ToS) is required for a listing in
>> the viewer directory. The details of the two guinea pigs who registered
>> (Kirsten's, Metabolt) were promptly published for a day before someone in LL
>> pressed the emergency button. But that was not the first time that LL
>> distributed private details.
>>
>> In summary, the policy is legal-technical flawed and not acceptable by any
>> dev in 

Re: [opensource-dev] Request for clarification on mailing list guidelines

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

How about Google Wave? (i'm not for nor against it, that was a completly
unbiased question)

On 23/3/2010 11:12, Aleric Inglewood wrote:
> Having the IW meetings always at the same time and the same day of the week
> locks some people out.
> 
> Me for example. I can never attend on Thursdays. I'd really appreciate it
> if it was possible to have the meetings regularly on another day of the
> week. Maybe every two weeks on thursdays and every two weeks on
> another day (preferably later, too).
> 
> On Tue, Mar 23, 2010 at 6:12 AM, Philippe (Merov) Bossut
> mailto:me...@lindenlab.com>> wrote:
> 
> - IW meetings: we have our weekly Hippo meeting and I truly
> encourage folks to come. It's my favorite comm tool personally as
> it's a dedicated moment and we have full attention of everyone.
> Should we do more of this?
> 
> 
> 
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkupIJoACgkQ8ZFfSrFHsmW0ogCeNzOP7XqR+NQ6OGJIbLFu4sEq
mzQAnR1Kl0nud9PiIx6BcCX4LjhURvDN
=OO5N
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Request for clarification on mailing list guidelines

[Opensource Obscure]

On Tue, 23 Mar 2010 17:12:14 -0300, Tigro Spottystripes
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> How about Google Wave? (i'm not for nor against it, that was a completly
> unbiased question)


And/or IRC relay. 
New thread on tools?

opensource obscure
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client 2.0 - sidebar

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Btw, how do those people that have seizure issues deal with the
possibility of people having quickly changing particle emitters,
suddenly rezzed prims, fast moving big objects etc?

On 23/3/2010 16:51, Maya Remblai wrote:
> Ok, I was trying to be diplomatic, but now I'm going to be frank.
> 
> It disturbs me that LL is ignoring how dangerous the shifting behavior 
> of the sidebar and the blinking and winking of 2.0 is. Some people have 
> already had or come close to having seizures because of it, and people 
> without epilepsy are having motion sickness and vertigo. LL has been 
> warned about it, especially on the JIRA, but the complaints haven't been 
> acknowledged. If LL loves 2.0 so much, the very least they're going to 
> have to do is include a video game style seizure warning on startup.
> 
> Read the comments on this JIRA entry.
> http://jira.secondlife.com/browse/VWR-17249
> 
> Here's the meta for all sidebar issues. The comments on most of these 
> point out the photosensitivity issue.
> http://jira.secondlife.com/browse/VWR-17012
> 
> Maya
> 
> Maya Remblai wrote:
>> All interesting ideas, but it would be prudent to include a floater as 
>> an option. Not only will it make things easier on experienced users and 
>> those who don't like the sidebar, it will make things easier for the 
>> devs making versions of Viewer 2.0 for photo-sensitive people to use 
>> without issue.
>>
>> Maya
>>
>> Nyx Linden wrote:
>>   
>>> Good question! There is still a lot of detail left out of these 
>>> descriptions, but we are planning on moving the UI in the appearance 
>>> editor into the sidebar, along with creating a new outfit editor UI. 
>>> You will still see the results of the changes you are making on your 
>>> avatar in-world in real time. There will still be an "editing 
>>> appearance" mode as you have now, it will just be accompanied by a 
>>> panel in the sidebar instead of a separate floater.
>>>
>>>  - Nyx
>>>
>>> On Mon, Mar 22, 2010 at 6:56 PM, Argent Stonecutter 
>>> mailto:secret.arg...@gmail.com>> wrote:
>>>
>>>
>>> On 2010-03-22, at 12:45, Nyx Linden wrote:
>>>
>>> 1) A new panel to edit what is stored in your saved outfit without
>>> creating a new one.
>>>   This will include both an inventory view and a view of your
>>> outfit
>>> itself, so you can drag items from your inventory to your
>>> outfit without
>>> having an extra floater open
>>> 2) Editing of wearable items (body parts and/or clothing
>>> objects) in the
>>> sidebar, selectable from the outfit editor
>>> 3) Removal of the appearance floater
>>>
>>>
>>> I have a concern about this, where it comes to editing outfits
>>> containing prim parts. You have to see them in world, you can't
>>> just edit them in a sidebar window, because you may need to edit
>>> them with reference to objects in world.
>>>
>>> If I'm mistaken about what "removal of the appearance floater"
>>> means, in the context of a UI designed to allow you to edit
>>> outfits without having to wear them, then I'll be happy to be
>>> corrected.
>>>
>>>
>>> 
>>>
>>> ___
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>> Please read the policies before posting to keep unmoderated posting 
>>> privileges
>>> 
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting 
>> privileges
>>
>>   
> 
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkupJPcACgkQ8ZFfSrFHsmVV3gCghcpL5bwgvc1saoo1D/R1TwvV
EgYAn0+e9ExJsSw+VTmKCySRZxuBunDK
=1Ope
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Third party viewer policy: commencement date

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The thing is, according to the TOS, LL can already deny you access to
all your account related data for any or no reason, and they can delete
anything they want in their own machines for any or no reason as well...

On 23/3/2010 16:58, Gareth Nelson wrote:
> In other news, an email provider today produced a list of requirements
> for third party email client developers - I have an account with them,
> but their TOS doesn't mention this list of requirements and they never
> mentioned these requirements when I signed up for the account.
> 
> Should I worry about them sueing me?
> 
> IANAL, but it seems until the TOS is updated AND YOU ACCEPT THE NEW
> TOS, this policy is binding on nobody
> 
> On Tue, Mar 23, 2010 at 5:28 PM, Dahlia Trimble  
> wrote:
>> I have developed a BSD licensed viewer that is not derived from LL source
>> code. It is designed and intended for use with OpenSimulator, however since
>> it uses Linden Lab protocols it is capable of connecting to the Secondlife
>> grid, although functionality is impaired. I have no intention of making it
>> compliant with the TPV as *I never intended it to be used with SL*. However,
>> upon reading the TPV, it looks as though a possible interpretation may be
>> that my SL membership status may be at risk if someone (outside of my
>> control) uses the viewer to connect to SL and subsequently causes some
>> misfortune to another party, and that LL may wish to pursue legal remedies
>> against me as the developer of this viewer. As the viewer has been published
>> under a BSD style license long before the TPV came into existence. and I
>> have no control over already distributed copies and derivatives, and I have
>> no intention of stopping distribution, could my SL account be at risk, and
>> should I assume LL may attempt legal remedies against me for any unintended
>> use of this viewer?
>>
>>
>> On Tue, Mar 23, 2010 at 5:34 AM, Boy Lane  wrote:
>>>
>>> I've put my summary about TVP on my blog
>>> http://my.opera.com/boylane/blog/linden-labs-final-3rd-party-viewer-policy-tpv
>>>
>>>
>>> Linden Lab's final 3rd Party Viewer Policy (TPV)
>>> TUESDAY, 23. MARCH 2010, 19:15:03
>>>
>>> A lot of things are changing, I've voiced my opinion several times, and I
>>> want to summarize here what I think about Linden Lab's 3rd Party Viewer
>>> Policy (TVP) that can be found here: Policy on Third-Party Viewers | Second
>>> Life
>>>
>>> Under assumption of common sense LL produced guidelines that should
>>> regulate and control the way people can connect to their service, that is
>>> the SecondLife grid. Guidelines which would be correct under the aspect of
>>> common sense and I believe LL came from that perspective by initially
>>> creating that guidelines in form of the 3rd Party Viewer Policy.
>>>
>>> What went wrong? They gave it in the hands of JohnDoe Linden lawyers who
>>> obviously missed the subject completley and overstepped ridiculously. But
>>> let's get down to the roots.
>>>
>>> Basically there are 2 core things very wrong with it. Initially LL
>>> requires everyone to comply to the GPL licensing. Which is fine as that sets
>>> the context. The GPL clearly states a developer has no warranty or liability
>>> for the code whatsover, even if that means ones viewer starts a nuclear war
>>> against former Soviet Russia or China or both. That clause is included in
>>> every single file of sourcecode (not the part about the Russians or Chinese
>>> ). LL explicitely disclaims any liability themselves for the resulting world
>>> war but then puts exactly that liability back on the shoulders of anyone
>>> developing a viewer.
>>>
>>> Not only that, by complying to their TPV a developer would also accept
>>> universal responsibility for all and everything "viewer". To be exact, as a
>>> developer "You assume all risks, expenses, and defects of any Third-Party
>>> Viewers that you use, develop, or distribute." A viewer does not even need
>>> to be able or connect to SL for that.
>>>
>>> In this regard it does not matter if a JohnDoe Linden comments on a
>>> mailing list or if a legally not binding FAQ tells us that this would be
>>> only for usage by connecting to the SL grid. It is not. TPV in it's current
>>> form says "I'm responsible (read: guilty) for using, developing or
>>> distributing any 3rd party viewer".
>>>
>>> Already by simply developing I'm assuming full responsibility for
>>> everything. I could take the official LL sources and compile and distribute
>>> a sourcewise identical "official" viewer, without changing a single line of
>>> code; but with all the bugs and vulnerabilities *made by LL*. Guilty by TPV.
>>> It's really ridiculous.
>>>
>>> This is a clear violation of the in the first place by LL required GPL
>>> licensing. It puts further restrictions on developers GPL explicitly
>>> prohibits.
>>>
>>> Another point of concern, putting up the RL details (which is pointless as
>>> LL has them already a

Re: [opensource-dev] Client 2.0 - sidebar

[Maya Remblai]

People on forums have said they know where such behavior can occur, and 
avoid those places. Clubs, mainland sandboxes, etc. But you'd have to 
ask them.

At any rate, that's not particularly relevant here. Up until now no one 
has had any reason to be wary of an LL viewer. But now, someone could 
install 2.0 without knowing about the problems. In your example, it's up 
to the individual to protect themselves. But with the new viewer, there 
are no warnings, so blame falls on LL.

Maya

Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Btw, how do those people that have seizure issues deal with the
> possibility of people having quickly changing particle emitters,
> suddenly rezzed prims, fast moving big objects etc?
>
>   

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Third party viewer policy: commencement date

[Gareth Nelson]

Yes, they can - but they can't sue you and claim damages, which is
quite a massive difference

On Tue, Mar 23, 2010 at 8:33 PM, Tigro Spottystripes
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> The thing is, according to the TOS, LL can already deny you access to
> all your account related data for any or no reason, and they can delete
> anything they want in their own machines for any or no reason as well...
>
> On 23/3/2010 16:58, Gareth Nelson wrote:
>> In other news, an email provider today produced a list of requirements
>> for third party email client developers - I have an account with them,
>> but their TOS doesn't mention this list of requirements and they never
>> mentioned these requirements when I signed up for the account.
>>
>> Should I worry about them sueing me?
>>
>> IANAL, but it seems until the TOS is updated AND YOU ACCEPT THE NEW
>> TOS, this policy is binding on nobody
>>
>> On Tue, Mar 23, 2010 at 5:28 PM, Dahlia Trimble  
>> wrote:
>>> I have developed a BSD licensed viewer that is not derived from LL source
>>> code. It is designed and intended for use with OpenSimulator, however since
>>> it uses Linden Lab protocols it is capable of connecting to the Secondlife
>>> grid, although functionality is impaired. I have no intention of making it
>>> compliant with the TPV as *I never intended it to be used with SL*. However,
>>> upon reading the TPV, it looks as though a possible interpretation may be
>>> that my SL membership status may be at risk if someone (outside of my
>>> control) uses the viewer to connect to SL and subsequently causes some
>>> misfortune to another party, and that LL may wish to pursue legal remedies
>>> against me as the developer of this viewer. As the viewer has been published
>>> under a BSD style license long before the TPV came into existence. and I
>>> have no control over already distributed copies and derivatives, and I have
>>> no intention of stopping distribution, could my SL account be at risk, and
>>> should I assume LL may attempt legal remedies against me for any unintended
>>> use of this viewer?
>>>
>>>
>>> On Tue, Mar 23, 2010 at 5:34 AM, Boy Lane  wrote:

 I've put my summary about TVP on my blog
 http://my.opera.com/boylane/blog/linden-labs-final-3rd-party-viewer-policy-tpv


 Linden Lab's final 3rd Party Viewer Policy (TPV)
 TUESDAY, 23. MARCH 2010, 19:15:03

 A lot of things are changing, I've voiced my opinion several times, and I
 want to summarize here what I think about Linden Lab's 3rd Party Viewer
 Policy (TVP) that can be found here: Policy on Third-Party Viewers | Second
 Life

 Under assumption of common sense LL produced guidelines that should
 regulate and control the way people can connect to their service, that is
 the SecondLife grid. Guidelines which would be correct under the aspect of
 common sense and I believe LL came from that perspective by initially
 creating that guidelines in form of the 3rd Party Viewer Policy.

 What went wrong? They gave it in the hands of JohnDoe Linden lawyers who
 obviously missed the subject completley and overstepped ridiculously. But
 let's get down to the roots.

 Basically there are 2 core things very wrong with it. Initially LL
 requires everyone to comply to the GPL licensing. Which is fine as that 
 sets
 the context. The GPL clearly states a developer has no warranty or 
 liability
 for the code whatsover, even if that means ones viewer starts a nuclear war
 against former Soviet Russia or China or both. That clause is included in
 every single file of sourcecode (not the part about the Russians or Chinese
 ). LL explicitely disclaims any liability themselves for the resulting 
 world
 war but then puts exactly that liability back on the shoulders of anyone
 developing a viewer.

 Not only that, by complying to their TPV a developer would also accept
 universal responsibility for all and everything "viewer". To be exact, as a
 developer "You assume all risks, expenses, and defects of any Third-Party
 Viewers that you use, develop, or distribute." A viewer does not even need
 to be able or connect to SL for that.

 In this regard it does not matter if a JohnDoe Linden comments on a
 mailing list or if a legally not binding FAQ tells us that this would be
 only for usage by connecting to the SL grid. It is not. TPV in it's current
 form says "I'm responsible (read: guilty) for using, developing or
 distributing any 3rd party viewer".

 Already by simply developing I'm assuming full responsibility for
 everything. I could take the official LL sources and compile and distribute
 a sourcewise identical "official" viewer, without changing a single line of
 code; but with all the bugs and vulnerabilities *made by LL*. Guilty by 
 TPV.
 It's really ridiculous.

Re: [opensource-dev] Client 2.0 - sidebar

[Miro]

Good review here of the 2.0 interface:

http://zhaewry.wordpress.com/2010/03/15/viewer2-0-beta-the-good-the-bad-the-ugly-and-the-odd/

Personally, I find the UI highly unintuitive, plus it breaks decades of 
well established "rules", like having file operations all in the top 
menu bar, under "File" (as 1.x viewers do). Search now is all over the 
place instead of centralized. And what about opening multiple inventory 
windows to facilitate moving things from one place to another?

The we have the new imposed outfit system. Why force people to use that 
if they have developed their own methods? Why saddle us with additional 
folders that cannot be deleted if they are not needed/used?

As for the sidebar, worst UI design I have seen since 1981 when I 
started in computing. Or nearly anyway.

[Goes back to lurking]


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] llcamera

[Philippe (Merov) Bossut]

Hi,

On Fri, Mar 19, 2010 at 6:56 AM, Thomas Schindler <
thomas.schind...@t-systems-mms.com> wrote:

>  Hi there,
>
> I have a question to the llcamera.cpp code. There is a function that
> calculates frustum planes. Four variables are existing: top, bottom, left,
> right. The bottom is the negative value of top, the same with left and
> write. If I change now the values and add +20 behind left and right, I
> expected an effect in which my avatar would stand not in the middle of the
> viewer window, but somewhere more left or right. But if I compile and run
> the viewer, I don't see any difference. Does anybody can explain it to me,
> please?
>
>
I haven't looked at that code in more than a year but, last time I did
something like that (to move the IW camera in sync with my head tracked by a
webcam), I remember I had to simply translate() the LLViewerCamera, since,
deep down, those objects (LLCamera and LLViewerCamera) are LLCoordFrame.

The data you try to modify are computed intermediate values used for culling
and whatever you do is likely overwritten by other calls at the next frame
drawing.

Cheers,
- Merov
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Third party viewer policy: commencement date

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

i dunno about the legal part, but they already have the power (and
according to the TOS the right) to deprive you of your SL account, and
mangle your SL assets

On 23/3/2010 17:38, Gareth Nelson wrote:
> Yes, they can - but they can't sue you and claim damages, which is
> quite a massive difference
> 
> On Tue, Mar 23, 2010 at 8:33 PM, Tigro Spottystripes
>  wrote:
> The thing is, according to the TOS, LL can already deny you access to
> all your account related data for any or no reason, and they can delete
> anything they want in their own machines for any or no reason as well...
> 
> On 23/3/2010 16:58, Gareth Nelson wrote:
 In other news, an email provider today produced a list of requirements
 for third party email client developers - I have an account with them,
 but their TOS doesn't mention this list of requirements and they never
 mentioned these requirements when I signed up for the account.

 Should I worry about them sueing me?

 IANAL, but it seems until the TOS is updated AND YOU ACCEPT THE NEW
 TOS, this policy is binding on nobody

 On Tue, Mar 23, 2010 at 5:28 PM, Dahlia Trimble  
 wrote:
> I have developed a BSD licensed viewer that is not derived from LL source
> code. It is designed and intended for use with OpenSimulator, however 
> since
> it uses Linden Lab protocols it is capable of connecting to the Secondlife
> grid, although functionality is impaired. I have no intention of making it
> compliant with the TPV as *I never intended it to be used with SL*. 
> However,
> upon reading the TPV, it looks as though a possible interpretation may be
> that my SL membership status may be at risk if someone (outside of my
> control) uses the viewer to connect to SL and subsequently causes some
> misfortune to another party, and that LL may wish to pursue legal remedies
> against me as the developer of this viewer. As the viewer has been 
> published
> under a BSD style license long before the TPV came into existence. and I
> have no control over already distributed copies and derivatives, and I 
> have
> no intention of stopping distribution, could my SL account be at risk, and
> should I assume LL may attempt legal remedies against me for any 
> unintended
> use of this viewer?
>
>
> On Tue, Mar 23, 2010 at 5:34 AM, Boy Lane  wrote:
>>
>> I've put my summary about TVP on my blog
>> http://my.opera.com/boylane/blog/linden-labs-final-3rd-party-viewer-policy-tpv
>>
>>
>> Linden Lab's final 3rd Party Viewer Policy (TPV)
>> TUESDAY, 23. MARCH 2010, 19:15:03
>>
>> A lot of things are changing, I've voiced my opinion several times, and I
>> want to summarize here what I think about Linden Lab's 3rd Party Viewer
>> Policy (TVP) that can be found here: Policy on Third-Party Viewers | 
>> Second
>> Life
>>
>> Under assumption of common sense LL produced guidelines that should
>> regulate and control the way people can connect to their service, that is
>> the SecondLife grid. Guidelines which would be correct under the aspect 
>> of
>> common sense and I believe LL came from that perspective by initially
>> creating that guidelines in form of the 3rd Party Viewer Policy.
>>
>> What went wrong? They gave it in the hands of JohnDoe Linden lawyers who
>> obviously missed the subject completley and overstepped ridiculously. But
>> let's get down to the roots.
>>
>> Basically there are 2 core things very wrong with it. Initially LL
>> requires everyone to comply to the GPL licensing. Which is fine as that 
>> sets
>> the context. The GPL clearly states a developer has no warranty or 
>> liability
>> for the code whatsover, even if that means ones viewer starts a nuclear 
>> war
>> against former Soviet Russia or China or both. That clause is included in
>> every single file of sourcecode (not the part about the Russians or 
>> Chinese
>> ). LL explicitely disclaims any liability themselves for the resulting 
>> world
>> war but then puts exactly that liability back on the shoulders of anyone
>> developing a viewer.
>>
>> Not only that, by complying to their TPV a developer would also accept
>> universal responsibility for all and everything "viewer". To be exact, 
>> as a
>> developer "You assume all risks, expenses, and defects of any Third-Party
>> Viewers that you use, develop, or distribute." A viewer does not even 
>> need
>> to be able or connect to SL for that.
>>
>> In this regard it does not matter if a JohnDoe Linden comments on a
>> mailing list or if a legally not binding FAQ tells us that this would be
>> only for usage by connecting to the SL grid. It is not. TPV in it's 
>> current
>> form says "I'm r

Re: [opensource-dev] Client 2.0 - sidebar

[Miro]

[replying back to list]

Thanks for the clarifications. :-)

Breaking well established norms of UI design (ie the File menu, to 
repeat one; there are others) makes the whole thing difficult for new 
users. Why not at least put that menu back - leave the existing file 
oeprations where they are, but duplicate the functionality in Top menu 
-> File. Having multiple ways to do that same thing is VERY common.

Anyway, I've said my peace, plus the article I pointed to does a better 
job than I can.

On 03/23/2010 04:55 PM, Nyx Linden wrote:
> Couple points here. You can open multiple inventory windows either by
> going to the file menu of the inventory side panel and selecting "new
> window", or using the shortcut key ctrl+shift+I. These inventory windows
> will open independent of the sidebar and can be moved around the screen
> or resized to fit whatever your needs are.
>
> Additionally, the new outfit system is not required for use. All of the
> old methods of managing your appearance through your inventory are still
> available and you can ignore the new appearance sidepanel and still use
> all of your normal appearance functions through inventory (replace
> outfit, add to outfit, etc). The "current outfit" and "My Outfits"
> folders are implemented as system folders, just like the other system
> folders our viewer uses, such as animations, body parts, favorites, etc.
> While they cannot be deleted because our viewer makes assumptions about
> their existence, they also can be safely ignored and not used for their
> intended purpose.
>
> -Nyx
>
> Miro wrote:
>> Good review here of the 2.0 interface:
>>
>> http://zhaewry.wordpress.com/2010/03/15/viewer2-0-beta-the-good-the-bad-the-ugly-and-the-odd/
>>
>>
>> Personally, I find the UI highly unintuitive, plus it breaks decades
>> of well established "rules", like having file operations all in the
>> top menu bar, under "File" (as 1.x viewers do). Search now is all over
>> the place instead of centralized. And what about opening multiple
>> inventory windows to facilitate moving things from one place to another?
>>
>> The we have the new imposed outfit system. Why force people to use
>> that if they have developed their own methods? Why saddle us with
>> additional folders that cannot be deleted if they are not needed/used?
>>
>> As for the sidebar, worst UI design I have seen since 1981 when I
>> started in computing. Or nearly anyway.
>>
>> [Goes back to lurking]
>>
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>
>

-- 
Co-owner, Animations Rising: http://tinyurl.com/l959f2
Digital art by Miro: http://tinyurl.com/lwtw3q
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Third party viewer policy: commencement date

[Gareth Nelson]

They always did have that ability, but they can't randomly invent a
new policy and then sue you for it

On Tue, Mar 23, 2010 at 8:51 PM, Tigro Spottystripes
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> i dunno about the legal part, but they already have the power (and
> according to the TOS the right) to deprive you of your SL account, and
> mangle your SL assets
>
> On 23/3/2010 17:38, Gareth Nelson wrote:
>> Yes, they can - but they can't sue you and claim damages, which is
>> quite a massive difference
>>
>> On Tue, Mar 23, 2010 at 8:33 PM, Tigro Spottystripes
>>  wrote:
>> The thing is, according to the TOS, LL can already deny you access to
>> all your account related data for any or no reason, and they can delete
>> anything they want in their own machines for any or no reason as well...
>>
>> On 23/3/2010 16:58, Gareth Nelson wrote:
> In other news, an email provider today produced a list of requirements
> for third party email client developers - I have an account with them,
> but their TOS doesn't mention this list of requirements and they never
> mentioned these requirements when I signed up for the account.
>
> Should I worry about them sueing me?
>
> IANAL, but it seems until the TOS is updated AND YOU ACCEPT THE NEW
> TOS, this policy is binding on nobody
>
> On Tue, Mar 23, 2010 at 5:28 PM, Dahlia Trimble  
> wrote:
>> I have developed a BSD licensed viewer that is not derived from LL source
>> code. It is designed and intended for use with OpenSimulator, however 
>> since
>> it uses Linden Lab protocols it is capable of connecting to the 
>> Secondlife
>> grid, although functionality is impaired. I have no intention of making 
>> it
>> compliant with the TPV as *I never intended it to be used with SL*. 
>> However,
>> upon reading the TPV, it looks as though a possible interpretation may be
>> that my SL membership status may be at risk if someone (outside of my
>> control) uses the viewer to connect to SL and subsequently causes some
>> misfortune to another party, and that LL may wish to pursue legal 
>> remedies
>> against me as the developer of this viewer. As the viewer has been 
>> published
>> under a BSD style license long before the TPV came into existence. and I
>> have no control over already distributed copies and derivatives, and I 
>> have
>> no intention of stopping distribution, could my SL account be at risk, 
>> and
>> should I assume LL may attempt legal remedies against me for any 
>> unintended
>> use of this viewer?
>>
>>
>> On Tue, Mar 23, 2010 at 5:34 AM, Boy Lane  wrote:
>>>
>>> I've put my summary about TVP on my blog
>>> http://my.opera.com/boylane/blog/linden-labs-final-3rd-party-viewer-policy-tpv
>>>
>>>
>>> Linden Lab's final 3rd Party Viewer Policy (TPV)
>>> TUESDAY, 23. MARCH 2010, 19:15:03
>>>
>>> A lot of things are changing, I've voiced my opinion several times, and 
>>> I
>>> want to summarize here what I think about Linden Lab's 3rd Party Viewer
>>> Policy (TVP) that can be found here: Policy on Third-Party Viewers | 
>>> Second
>>> Life
>>>
>>> Under assumption of common sense LL produced guidelines that should
>>> regulate and control the way people can connect to their service, that 
>>> is
>>> the SecondLife grid. Guidelines which would be correct under the aspect 
>>> of
>>> common sense and I believe LL came from that perspective by initially
>>> creating that guidelines in form of the 3rd Party Viewer Policy.
>>>
>>> What went wrong? They gave it in the hands of JohnDoe Linden lawyers who
>>> obviously missed the subject completley and overstepped ridiculously. 
>>> But
>>> let's get down to the roots.
>>>
>>> Basically there are 2 core things very wrong with it. Initially LL
>>> requires everyone to comply to the GPL licensing. Which is fine as that 
>>> sets
>>> the context. The GPL clearly states a developer has no warranty or 
>>> liability
>>> for the code whatsover, even if that means ones viewer starts a nuclear 
>>> war
>>> against former Soviet Russia or China or both. That clause is included 
>>> in
>>> every single file of sourcecode (not the part about the Russians or 
>>> Chinese
>>> ). LL explicitely disclaims any liability themselves for the resulting 
>>> world
>>> war but then puts exactly that liability back on the shoulders of anyone
>>> developing a viewer.
>>>
>>> Not only that, by complying to their TPV a developer would also accept
>>> universal responsibility for all and everything "viewer". To be exact, 
>>> as a
>>> developer "You assume all risks, expenses, and defects of any 
>>> Third-Party
>>> Viewers that you use, develop, or distribute." A viewer does

Re: [opensource-dev] Open Development project: extending avatar wearables

[Ricky]

While this is an amazing idea I love, that of being able to use some 3rd
party tool for the task, I do not own Poser, and $250 US, it's a bit steep
just to edit my appearance.

I think there should be in-UI tools for editing your avvie's appearance, but
the addition of integrating external tools would be great, and would be
easily done once the client extensions system has been built.  But that's
another topic. :)

Ricky
Cron Stardust

On Tue, Mar 23, 2010 at 11:01 AM, Robert Martin wrote:

> On Tue, Mar 23, 2010 at 12:58 PM, Nyx Linden  wrote:
> >  The current iteration of the appearance floater needs to go away. The
> > current implementation has been held together with chicken wire, bubble
> > gum, and duct tape. It works for now, but it won't hold up to the
> > addition of multiple wearables of a given type.
>
> I just had something of a wild idea
> there exists 2 semi related programs that would be perfect to do this
> and while the back end stuff would be "fun to do" 95% of the actual
> program is already done
>
> Poser and of course Daz Studio
> Stuff needed
> 1 the various morphs need to be converted to Poser format
> 2 the clothing items need to be rebuilt as Poser items (with morphs)
> 3 some sort of export plugin needs to be created (or a Poser import
> plugin needs to be made for SL)
> 4 whatever i forgot
> N ect audnauseum
> --
> Robert L Martin
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Third party viewer policy: commencement date

[Morgaine]

[CC Philip]

Boy Lane's article is the clearest summary of the whole sorry situation so
far.

I hope that his very accurate analysis is handed to someone at high level in
LL, because it is clear that no Lindens on this list are able or willing to
engage in the matter.  The lawyers behind the scenes at LL appear to be
truly out of control, and uncaring of the mammoth GPL non-compliance of what
they have written.

I have CC'd this post to Philip Linden, because being at arm's length from
the Lab nowadays, perhaps he can see more clearly than some how far the
situation has deteriorated from the original vision of an open client and an
ecosystem of GPL developers.

Boy Lane's article is enclosed.


Morgaine.






=

On Tue, Mar 23, 2010 at 12:34 PM, Boy Lane  wrote:

>  I've put my summary about TVP on my blog
> http://my.opera.com/boylane/blog/linden-labs-final-3rd-party-viewer-policy-tpv
>
>
>  Linden Lab's final 3rd Party Viewer Policy (TPV)
> TUESDAY, 23. MARCH 2010, 19:15:03
>
> A lot of things are changing, I've voiced my opinion several times, and I
> want to summarize here what I think about Linden Lab's 3rd Party Viewer
> Policy (TVP) that can be found here: Policy on Third-Party Viewers |
> Second Life 
>
> Under assumption of common sense LL produced guidelines that should
> regulate and control the way people can connect to their service, that is
> the SecondLife grid. Guidelines which would be correct under the aspect of
> common sense and I believe LL came from that perspective by initially
> creating that guidelines in form of the 3rd Party Viewer Policy.
>
> What went wrong? They gave it in the hands of JohnDoe Linden lawyers who
> obviously missed the subject completley and overstepped ridiculously. But
> let's get down to the roots.
>
> Basically there are 2 core things very wrong with it. Initially LL requires
> everyone to comply to the GPL licensing. Which is fine as that sets the
> context. The GPL clearly states a developer has no warranty or liability for
> the code whatsover, even if that means ones viewer starts a nuclear war
> against former Soviet Russia or China or both. That clause is included in
> every single file of sourcecode (not the part about the Russians or Chinese
> ). LL explicitely disclaims any liability themselves for the resulting world
> war but then puts exactly that liability back on the shoulders of anyone
> developing a viewer.
>
> Not only that, by complying to their TPV a developer would also accept
> universal responsibility for all and everything "viewer". To be exact, as a
> developer "You assume all risks, expenses, and defects of any Third-Party
> Viewers that you use, develop, or distribute." A viewer does not even need
> to be able or connect to SL for that.
>
> In this regard it does not matter if a JohnDoe Linden comments on a mailing
> list or if a legally not binding FAQ tells us that this would be only for
> usage by connecting to the SL grid. It is not. TPV in it's current form
> says "I'm responsible (read: guilty) for using, developing or distributing
> any 3rd party viewer".
>
> Already by simply developing I'm assuming full responsibility for
> everything. I could take the official LL sources and compile and distribute
> a sourcewise identical "official" viewer, without changing a single line of
> code; but with all the bugs and vulnerabilities *made by LL*. Guilty by TPV.
> It's really ridiculous.
>
> This is a clear violation of the in the first place by LL required GPL
> licensing. It puts further restrictions on developers GPL explicitly
> prohibits.
>
> Another point of concern, putting up the RL details (which is pointless as
> LL has them already and require them by ToS) is required for a listing in
> the viewer directory. The details of the two guinea pigs who registered
> (Kirsten's, Metabolt) were promptly published for a day before someone in LL
> pressed the emergency button. But that was not the first time that LL
> distributed private details.
>
> In summary, the policy is legal-technical flawed and not acceptable by any
> dev in their right mind. What it will achieve is the destruction of any
> *legal* 3rd party viewer; which probably is the (by some welcomed) goal of
> LL to close-source the viewer. It will not do anything to stop malicious
> clients to flourish, the Neils give a shit on policies or licenses.
>
> The consequence is that no 3rd party developer that uses LL's GPLed sources
> (including already registered KLee or famed Emerald) can produce a
> legitimate viewer that is either compliant to GPL and/or violates TPV (which
> says it must be GPL compliant). Both are mutually exclusive and LL created a
> nice legal chicken and egg scenario.
>
> In my opinion there are only 3 possible solutions:
> 1) use LL's code and violate TPV
> 2) create a viewer from scratch using BSD or another license and comply to
> TPV
> 3) stop developing 3rd party viewer

Re: [opensource-dev] Third party viewer policy: commencement date

[Rob Nelson]

Boy's right, too.

 * FAQs are not legally binding. 
 * Comments on a mailing list are not legally binding.  
 * Policies attached to a Terms of Service agreement ARE legally binding
once we agree to them.

I am not going to do any further development of any type of software for
Second Life until I am absolutely certain that:

 * I am not going to be held accountable for any of my user's actions
 * I will not violate my software's licensing agreement by agreeing to
the TPV
 * I am not going to be forced to place my personal information in a
publically viewed area in order to advertise my viewer.

Since Linden Lab has already told Massively that they do not plan to
update the TPV
,
 I do not plan to do any further work on any SL-based OSS.  I advise other 
viewer devs to also suspend their projects until a fixed TPV comes out, as 
there are very serious consequences to continuing SL OSS development with the 
current state of the TPV.

It would be nice if LL actually listened to us and fixed the TPV as we
asked instead of merely clarifying the statements they've made, but
knowing LL's previous track record, I'm not holding my breath.   Their
statements about "getting a lawyer" before commenting on this very
serious issue is also very troubling, as it doesn't take a lawyer to see
that there's something very, very wrong with the TPV.


On Wed, 2010-03-24 at 01:24 +, Morgaine wrote:
> [CC Philip]
> 
> Boy Lane's article is the clearest summary of the whole sorry
> situation so far.
> 
> I hope that his very accurate analysis is handed to someone at high
> level in LL, because it is clear that no Lindens on this list are able
> or willing to engage in the matter.  The lawyers behind the scenes at
> LL appear to be truly out of control, and uncaring of the mammoth GPL
> non-compliance of what they have written.
> 
> I have CC'd this post to Philip Linden, because being at arm's length
> from the Lab nowadays, perhaps he can see more clearly than some how
> far the situation has deteriorated from the original vision of an open
> client and an ecosystem of GPL developers.
> 
> Boy Lane's article is enclosed.
> 
> 
> Morgaine.
> 
> 
> 
> 
> 
> 
> =
> 
> On Tue, Mar 23, 2010 at 12:34 PM, Boy Lane  wrote:
> I've put my summary about TVP on my blog
> 
> http://my.opera.com/boylane/blog/linden-labs-final-3rd-party-viewer-policy-tpv
>  
>  
> Linden Lab's final 3rd Party Viewer Policy (TPV)
> TUESDAY, 23. MARCH 2010, 19:15:03
> 
> A lot of things are changing, I've voiced my opinion several
> times, and I want to summarize here what I think about Linden
> Lab's 3rd Party Viewer Policy (TVP) that can be found
> here: Policy on Third-Party Viewers | Second Life 
> 
> Under assumption of common sense LL produced guidelines that
> should regulate and control the way people can connect to
> their service, that is the SecondLife grid. Guidelines which
> would be correct under the aspect of common sense and I
> believe LL came from that perspective by initially creating
> that guidelines in form of the 3rd Party Viewer Policy. 
> 
> What went wrong? They gave it in the hands of JohnDoe Linden
> lawyers who obviously missed the subject completley and
> overstepped ridiculously. But let's get down to the roots. 
> 
> Basically there are 2 core things very wrong with it.
> Initially LL requires everyone to comply to the GPL licensing.
> Which is fine as that sets the context. The GPL clearly states
> a developer has no warranty or liability for the code
> whatsover, even if that means ones viewer starts a nuclear war
> against former Soviet Russia or China or both. That clause is
> included in every single file of sourcecode (not the part
> about the Russians or Chinese ). LL explicitely disclaims any
> liability themselves for the resulting world war but then puts
> exactly that liability back on the shoulders of anyone
> developing a viewer. 
> 
> Not only that, by complying to their TPV a developer would
> also accept universal responsibility for all and everything
> "viewer". To be exact, as a developer "You assume all risks,
> expenses, and defects of any Third-Party Viewers that you use,
> develop, or distribute." A viewer does not even need to be
> able or connect to SL for that. 
> 
> In this regard it does not matter if a JohnDoe Linden comments
> on a mailing list or if a legally not binding FAQ tells us
> that this would be only for usage by connecting to
> the SL grid. It is not. TPV in it's current form says "I'm
>

Re: [opensource-dev] Client 2.0 - sidebar (was: Re: Open Development project: extending avatarwearables)

[Jonathan Irvin]

Not to be rude, but if people are getting vertigo, epilepsy, etc. from
SL...viewer 2.0 isn't going to make a difference.  Viewer 1.23 would have
the same effect.  Maybe not in your coveted sidebar, but it SL in general.
You know it, I know it, everyone knows it.  This is common knowledge.  LCD
monitors nowadays will cause those effects *regardless* of the application
running, so please don't make someone else's illness as your point in
voicing your opinions.

Keep this in mind, your post accomplishes *nothing*.  Do you really think
Linden Labs wants to waste company money on replying to complaints of your
calibre?  They already know, trust me.  Linden Labs is a small company and
you can't expect them to reply to every single Tom, Dick, and Harriet that
wants to complain about this feature or that feature.

OpenSource-Dev is about fixing issues, not complaining about them.  This
list is for developers to collaborate, not tech support for your
complaints.  If you want to vent, for heaven's sake do that in a personal
blog, twitter, facebook, etc.

Please follow these SIMPLE STEPS before you waste our time in reading yet
another "I-hate-LL-viewer-2.0-and-they-should-fix-it-post."


   1. Has it been logged in JIRA?
  - Yes, Comment on it there.
  - No, Log it in JIRA.

Linden Labs CAN view JIRA, so posting about specific articles becomes
redundancy at that point.  All you need to do is vote for the JIRA topic.
Once you've logged your vote you can either get others to vote, or sit
quietly.

Complaining about a feature and throwing around JIRA articles accomplishes
nothing except annoy those who have to hear that same story, yet again.  And
while the Lindens do monitor this, for the most part, you are preaching to
the choir.

So please, if you aren't going to pull up your sleeves and FIX IT, then
don't waste our time.  We know, the Linden's know.  Your post was
unnecessary.

Jonathan Irvin

P.S. Sorry for any one else who had to hear my rant.  Thanks.


On Tue, Mar 23, 2010 at 14:51, Maya Remblai <
snowfox...@dragonkeepcreations.com> wrote:

> Ok, I was trying to be diplomatic, but now I'm going to be frank.
>
> It disturbs me that LL is ignoring how dangerous the shifting behavior
> of the sidebar and the blinking and winking of 2.0 is. Some people have
> already had or come close to having seizures because of it, and people
> without epilepsy are having motion sickness and vertigo. LL has been
> warned about it, especially on the JIRA, but the complaints haven't been
> acknowledged. If LL loves 2.0 so much, the very least they're going to
> have to do is include a video game style seizure warning on startup.
>
> Read the comments on this JIRA entry.
> http://jira.secondlife.com/browse/VWR-17249
>
> Here's the meta for all sidebar issues. The comments on most of these
> point out the photosensitivity issue.
> http://jira.secondlife.com/browse/VWR-17012
>
> Maya
>
> Maya Remblai wrote:
> > All interesting ideas, but it would be prudent to include a floater as
> > an option. Not only will it make things easier on experienced users and
> > those who don't like the sidebar, it will make things easier for the
> > devs making versions of Viewer 2.0 for photo-sensitive people to use
> > without issue.
> >
> > Maya
> >
> > Nyx Linden wrote:
> >
> >> Good question! There is still a lot of detail left out of these
> >> descriptions, but we are planning on moving the UI in the appearance
> >> editor into the sidebar, along with creating a new outfit editor UI.
> >> You will still see the results of the changes you are making on your
> >> avatar in-world in real time. There will still be an "editing
> >> appearance" mode as you have now, it will just be accompanied by a
> >> panel in the sidebar instead of a separate floater.
> >>
> >>  - Nyx
> >>
> >> On Mon, Mar 22, 2010 at 6:56 PM, Argent Stonecutter
> >> mailto:secret.arg...@gmail.com>> wrote:
> >>
> >>
> >> On 2010-03-22, at 12:45, Nyx Linden wrote:
> >>
> >> 1) A new panel to edit what is stored in your saved outfit
> without
> >> creating a new one.
> >>   This will include both an inventory view and a view of your
> >> outfit
> >> itself, so you can drag items from your inventory to your
> >> outfit without
> >> having an extra floater open
> >> 2) Editing of wearable items (body parts and/or clothing
> >> objects) in the
> >> sidebar, selectable from the outfit editor
> >> 3) Removal of the appearance floater
> >>
> >>
> >> I have a concern about this, where it comes to editing outfits
> >> containing prim parts. You have to see them in world, you can't
> >> just edit them in a sidebar window, because you may need to edit
> >> them with reference to objects in world.
> >>
> >> If I'm mistaken about what "removal of the appearance floater"
> >> means, in the context of a UI designed to allow you to edit
> >> outfits without having to wear 

Re: [opensource-dev] Client 2.0 - sidebar

[Maya Remblai]

I'm not going to bother trying to educate you about photosensitivity 
since you clearly don't have it. I'll just suggest you go read the SLU 
forums and elsewhere, where people with epilepsy and other 
photosensitvity problems are talking about this. And also suggest you 
take note of the epilepsy support groups in SL. Maybe even read 
Wikipedia's photosensitivity articles. Companies can and do get sued 
over stuff like this, because people with epilepsy and photosensitivity 
can and do watch TV, use computers, and play video games, whether you 
think they do or not.

And FYI, LL didn't pay attention to the alpha testers who said they 
didn't like 2.0. They didn't pay attention to the people who said they 
didn't like it in the beta. I suspect they'll pay attention to a 
lawsuit, but I'd rather it not come to that, therefore I and many other 
people are pointing out the ethical and legal problems. Don't attack me 
for someone else's mistake.

Maya

Jonathan Irvin wrote:
> Not to be rude, but if people are getting vertigo, epilepsy, etc. from 
> SL...viewer 2.0 isn't going to make a difference.  Viewer 1.23 would 
> have the same effect.  Maybe not in your coveted sidebar, but it SL in 
> general.  You know it, I know it, everyone knows it.  This is common 
> knowledge.  LCD monitors nowadays will cause those effects 
> *regardless* of the application running, so please don't make someone 
> else's illness as your point in voicing your opinions.
>
> Keep this in mind, your post accomplishes *nothing*.  Do you really 
> think Linden Labs wants to waste company money on replying to 
> complaints of your calibre?  They already know, trust me.  Linden Labs 
> is a small company and you can't expect them to reply to every single 
> Tom, Dick, and Harriet that wants to complain about this feature or 
> that feature.
>
> OpenSource-Dev is about fixing issues, not complaining about them.  
> This list is for developers to collaborate, not tech support for your 
> complaints.  If you want to vent, for heaven's sake do that in a 
> personal blog, twitter, facebook, etc.
>
> Please follow these SIMPLE STEPS before you waste our time in reading 
> yet another "I-hate-LL-viewer-2.0-and-they-should-fix-it-post."
>
>1. Has it been logged in JIRA?
>   * Yes, Comment on it there.
>   * No, Log it in JIRA.
>
> Linden Labs CAN view JIRA, so posting about specific articles becomes 
> redundancy at that point.  All you need to do is vote for the JIRA 
> topic.  Once you've logged your vote you can either get others to 
> vote, or sit quietly.
>
> Complaining about a feature and throwing around JIRA articles 
> accomplishes nothing except annoy those who have to hear that same 
> story, yet again.  And while the Lindens do monitor this, for the most 
> part, you are preaching to the choir. 
>
> So please, if you aren't going to pull up your sleeves and FIX IT, 
> then don't waste our time.  We know, the Linden's know.  Your post was 
> unnecessary.
>
> Jonathan Irvin
>
> P.S. Sorry for any one else who had to hear my rant.  Thanks.
>
>
> On Tue, Mar 23, 2010 at 14:51, Maya Remblai 
>  > wrote:
>
> Ok, I was trying to be diplomatic, but now I'm going to be frank.
>
> It disturbs me that LL is ignoring how dangerous the shifting behavior
> of the sidebar and the blinking and winking of 2.0 is. Some people
> have
> already had or come close to having seizures because of it, and people
> without epilepsy are having motion sickness and vertigo. LL has been
> warned about it, especially on the JIRA, but the complaints
> haven't been
> acknowledged. If LL loves 2.0 so much, the very least they're going to
> have to do is include a video game style seizure warning on startup.
>
> Read the comments on this JIRA entry.
> http://jira.secondlife.com/browse/VWR-17249
>
> Here's the meta for all sidebar issues. The comments on most of these
> point out the photosensitivity issue.
> http://jira.secondlife.com/browse/VWR-17012
>
> Maya
>
> Maya Remblai wrote:
> > All interesting ideas, but it would be prudent to include a
> floater as
> > an option. Not only will it make things easier on experienced
> users and
> > those who don't like the sidebar, it will make things easier for the
> > devs making versions of Viewer 2.0 for photo-sensitive people to use
> > without issue.
> >
> > Maya
> >
> > Nyx Linden wrote:
> >
> >> Good question! There is still a lot of detail left out of these
> >> descriptions, but we are planning on moving the UI in the
> appearance
> >> editor into the sidebar, along with creating a new outfit
> editor UI.
> >> You will still see the results of the changes you are making on
> your
> >> avatar in-world in real time. There will still be an "editing
> >> appearance" mode as you have now, it will just be accompa

Re: [opensource-dev] Third party viewer policy: commencement date

[Joe Linden]

Let me take just one more crack at explaining the situation here, then I'll
let the TPV Policy document stand on it's own.

First, the Linden Lab viewer source code is being made available to all
under the terms of the GPLv2 License.  Nothing has changed that, and the
policy doesn't modify, enhance, or limit your rights or obligations under
the GPL.

The TPV Policy is designed to set access conditions and terms for developers
and users of viewer binaries that connect to the Second Life grid, whether
produced from code licensed under the GPL or not.  Note that the definition
of TPV in that document stipulates that these are viewers that actually
connect to the SL grid, not those that may be capable of it but are never
used to log in.

If a developer of a TPV never uses it to connect to SL, there is nothing in
that document that applies to them. Period.  By the same token, if that
viewer is designed and intended to be used to access the Second Life grid(s)
there are responsibilities that follow, both for users of those viewers and
for developers.

Surely no one here is making an argument that a viewer that is designed to
transmit user passwords (encrypted or otherwise) back to the author or the
author's proxies should be allowed to the connect to the SL grid at will and
without responsibility on the part of the author?  Or that Linden Lab should
just allow unbridled use of viewers that are designed to bring down
simulators through dos vectors, expressly designed to crash viewers
repeatedly, or bypass the intent and purpose of the in-world permission
system?  Those aren't rhetorical questions.

There is no "catch 22" here.  No "overstepping", and no rocket science.  The
terms of the GPL are clear and well understood.  The arguments around
clauses 11 and 12 of the GPL are completely baseless.

I've seen some very dramatic "exits" from the SL open source program here in
this thread by people who have never contributed.  We're making a number of
changes to the practice and policy of what we will permit to connect to our
grid so we can invest in a richer conversation with the contributors who are
interested in innovating in this space with us.   The decision to work with
us as we redouble our efforts to create a more meaningful program is one
each contributor will have to make.  But, we're committed to moving forward
with those who are willing to accept a reasonable level of responsibility
for what they create.  That's what the TPV Policy and Viewer Directory
programs are about.

The code is licensed under GPLv2 and that isn't going to change.

This thread has become a zero sum game for all participants, so I look
forward to more generative conversation with those of you who are sticking
around for the next one.

-- joe

p.s. I have a suspicion this reply will be parsed to the same degree all
other responses have been, but I'm not going to recurse on the subject, and
I'm not going to make excuses.  Please keep the conversation here civil for
everyone.


On Tue, Mar 23, 2010 at 6:24 PM, Morgaine wrote:

> [CC Philip]
>
> Boy Lane's article is the clearest summary of the whole sorry situation so
> far.
>
> I hope that his very accurate analysis is handed to someone at high level
> in LL, because it is clear that no Lindens on this list are able or willing
> to engage in the matter.  The lawyers behind the scenes at LL appear to be
> truly out of control, and uncaring of the mammoth GPL non-compliance of what
> they have written.
>
> I have CC'd this post to Philip Linden, because being at arm's length from
> the Lab nowadays, perhaps he can see more clearly than some how far the
> situation has deteriorated from the original vision of an open client and an
> ecosystem of GPL developers.
>
> Boy Lane's article is enclosed.
>
>
> Morgaine.
>
>
>
>
>
>
> =
>
> On Tue, Mar 23, 2010 at 12:34 PM, Boy Lane  wrote:
>
>>  I've put my summary about TVP on my blog
>> http://my.opera.com/boylane/blog/linden-labs-final-3rd-party-viewer-policy-tpv
>>
>>
>>  Linden Lab's final 3rd Party Viewer Policy (TPV)
>> TUESDAY, 23. MARCH 2010, 19:15:03
>>
>> A lot of things are changing, I've voiced my opinion several times, and I
>> want to summarize here what I think about Linden Lab's 3rd Party Viewer
>> Policy (TVP) that can be found here: Policy on Third-Party Viewers |
>> Second Life 
>>
>> Under assumption of common sense LL produced guidelines that should
>> regulate and control the way people can connect to their service, that is
>> the SecondLife grid. Guidelines which would be correct under the aspect of
>> common sense and I believe LL came from that perspective by initially
>> creating that guidelines in form of the 3rd Party Viewer Policy.
>>
>> What went wrong? They gave it in the hands of JohnDoe Linden lawyers who
>> obviously missed the subject completley and overstepped ridiculously. But
>> let's get down to the roots.
>>
>> Basically there are 2 co

Re: [opensource-dev] Third party viewer policy: commencement date

[Jesse Barnett]

Just some thoughts in passing

Precedent has been set in cases that clickwrap agreements take precedence
and supercede any conflicting statements in shrinkwrap agreements.

Although it has not been stated, it is logical that Linden Labs will make
the TPV pop up as a clickwrap agreement starting on the 30th and you will
have to click through and accept before it will allow you to access the
grid. Same as has been done in the past with changes to the TOS.

BUT if devs used Inno Setup for example, to make the GPL popup as a
clickwrap agreement itself before the program could be installed then if
there are any conflicts, you would have a "battle of documents" where both
would have equal legal weight.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Third party viewer policy: commencement date

[Boy Lane]

Thanks Joe for just confirming our concerns.

> If a developer of a TPV never uses it to connect to SL, there is nothing in 
> that 
> document that applies to them. Period. By the same token, if that viewer is
> designed and intended to be used to access the Second Life grid(s) there are 
> responsibilities that follow, both for users of those viewers and for 
> developers.

As a developer I do not need to connect to the SL grid. By simply developing a 
viewer that is able to connect to SL I as a developer assume universal 
responsibility.

That is a responsibility and an uncalculable risk I as a developer or any other 
sane
person can not accept for 2 simple reasons:

a) I don't have control over (hidden) bugs and vulnerabilities in the code
b) I don't have control over any action of any user of my viewer

LL themselves disclaims any responsibility and warranty and it's not only 
unreasonable 
but impossible to shoulder such universal guilt on us developers.

As every viewer made after the commencement date of 30 April will fall under 
the TPV
and I as developer would be forced to accept these TPV terms there can only be 
one outcome of this: 

Discontinue 3rd party SL viewer development after 30 April ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Third party viewer policy: commencement date

[Jesse Barnett]

On Tue, Mar 23, 2010 at 10:57 PM, Joe Linden  wrote:

> I've seen some very dramatic "exits" from the SL open source program here
> in this thread by people who have never contributed.  We're making a number
> of changes to the practice and policy of what we will permit to connect to
> our grid so we can invest in a richer conversation with the contributors who
> are interested in innovating in this space with us.   The decision to work
> with us as we redouble our efforts to create a more meaningful program is
> one each contributor will have to make.  But, we're committed to moving
> forward with those who are willing to accept a reasonable level of
> responsibility for what they create.  That's what the TPV Policy and Viewer
> Directory programs are about.
>
> The code is licensed under GPLv2 and that isn't going to change.
>
> This thread has become a zero sum game for all participants, so I look
> forward to more generative conversation with those of you who are sticking
> around for the next one.
>
> -- joe
>
> p.s. I have a suspicion this reply will be parsed to the same degree all
> other responses have been, but I'm not going to recurse on the subject, and
> I'm not going to make excuses.  Please keep the conversation here civil for
> everyone.
>
>
Just a friendly reminder that we also expect the same level of
professionalism and civility from the Lindens on the list. Marine, Rob and
Boy have all contributed to the OS program and their further contributions
are going to be sorely missed by the community, so what "departures" are you
referring to? I have not contributed in a lng time. All of my
contributions were in Aditi for two years with QA before the jira was even
around and the first couple of months in OSDev when Rob started here. But
take a hard look at the other names here, I see one heck of a lot of names
from people that have made significant contributions to the program.
Evidently they do not feel like you that this is a meaningless "zero sum
game". None of us would be here unless we cared deeply for the OS movement
and wish to ensure that it does continue without being over restrained.

None of us receive a paycheck for what we are doing. There is no spare money
to hire a lawyer for the majority. As you yourself pointed out, the GPL is
clearly written and easy to understand, the same can not be said for the TPV
or we would not be having this conversation.

with regards,
Jesse Barnett
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Third party viewer policy: commencement date

[Darmath]

On 24/03/2010 1:57 PM, Joe Linden wrote:
> Let me take just one more crack at explaining the situation here, then 
> I'll let the TPV Policy document stand on it's own.
>
> First, the Linden Lab viewer source code is being made available to 
> all under the terms of the GPLv2 License.  Nothing has changed that, 
> and the policy doesn't modify, enhance, or limit your rights or 
> obligations under the GPL.
and a whole lot of other stuff...Yeah what he said +1

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Third party viewer policy: commencement date

[Tony Agudo]

(Delurking here just to throw in my $L2; standard IANAL disclaimer)

Joe, most of the TPV Policy *is* reasonable and nobody(except obviously
malicious viewer creators) is disputing that requiring reasonable, common
sense responsibilities to keep viewers honest is bad at all, it's simply
that Section 7(d) can open a can of worms for third-party viewer devs by not
clearly stating something along the lines of "You assume all risks,
expenses, and defects of any Third-Party Viewers that you use, develop, or
distribute* in the context of the broader sections of this Policy*. Linden
Lab shall not be responsible or liable for any Third-Party Viewers". Without
a clarification such as that, as an example, a third-party viewer user who
believes the viewer is causing harm to his/her SL experience(supposing the
"harm" is merely a glitch or bug that occurs in normal development, or even
if it's not the viewer but the user thinks it is), that user can point to
specifically that section of the TPV Policy and claim "By this, you *are*
legally liable for my problems, I can actually sue you". The Lab's own ToS
completely disclaims responsibility for the official viewer and has pretty
much protected the Lab against such actions in a majority of cases. It's
what has kept the development cycle in the Lab from becoming a legal
minefield, I'm sure you agree. What the third-party devs are asking is that
that legal threat shouldn't be thrust on them via the TPV Policy and it be
made clear and unambiguous if they're to continue developing for the benefit
of the SL grid without fear of nagging lawsuits. That's not an unreasonable
request, is it?

(*going back to lurking*)

On Tue, Mar 23, 2010 at 10:57 PM, Joe Linden  wrote:

> Let me take just one more crack at explaining the situation here, then I'll
> let the TPV Policy document stand on it's own.
>
> First, the Linden Lab viewer source code is being made available to all
> under the terms of the GPLv2 License.  Nothing has changed that, and the
> policy doesn't modify, enhance, or limit your rights or obligations under
> the GPL.
>
> The TPV Policy is designed to set access conditions and terms for
> developers and users of viewer binaries that connect to the Second Life
> grid, whether produced from code licensed under the GPL or not.  Note that
> the definition of TPV in that document stipulates that these are viewers
> that actually connect to the SL grid, not those that may be capable of it
> but are never used to log in.
>
> If a developer of a TPV never uses it to connect to SL, there is nothing in
> that document that applies to them. Period.  By the same token, if that
> viewer is designed and intended to be used to access the Second Life grid(s)
> there are responsibilities that follow, both for users of those viewers and
> for developers.
>
> Surely no one here is making an argument that a viewer that is designed to
> transmit user passwords (encrypted or otherwise) back to the author or the
> author's proxies should be allowed to the connect to the SL grid at will and
> without responsibility on the part of the author?  Or that Linden Lab should
> just allow unbridled use of viewers that are designed to bring down
> simulators through dos vectors, expressly designed to crash viewers
> repeatedly, or bypass the intent and purpose of the in-world permission
> system?  Those aren't rhetorical questions.
>
> There is no "catch 22" here.  No "overstepping", and no rocket science.
> The terms of the GPL are clear and well understood.  The arguments around
> clauses 11 and 12 of the GPL are completely baseless.
>
> I've seen some very dramatic "exits" from the SL open source program here
> in this thread by people who have never contributed.  We're making a number
> of changes to the practice and policy of what we will permit to connect to
> our grid so we can invest in a richer conversation with the contributors who
> are interested in innovating in this space with us.   The decision to work
> with us as we redouble our efforts to create a more meaningful program is
> one each contributor will have to make.  But, we're committed to moving
> forward with those who are willing to accept a reasonable level of
> responsibility for what they create.  That's what the TPV Policy and Viewer
> Directory programs are about.
>
> The code is licensed under GPLv2 and that isn't going to change.
>
> This thread has become a zero sum game for all participants, so I look
> forward to more generative conversation with those of you who are sticking
> around for the next one.
>
> -- joe
>
> p.s. I have a suspicion this reply will be parsed to the same degree all
> other responses have been, but I'm not going to recurse on the subject, and
> I'm not going to make excuses.  Please keep the conversation here civil for
> everyone.
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the p

Re: [opensource-dev] Third party viewer policy: commencement date

[Darmath]

On 24/03/2010 4:35 PM, Tony Agudo wrote:
that user can point to specifically that section of the TPV Policy and 
claim "By this, you *are* legally liable for my problems, I can 
actually sue you".
And herein lies why the construction thats sought to be advanced by 
those who have made rumblings on this list are wrongThe clause reads:


"d. You assume all risks, expenses, and defects of any Third-Party 
Viewers that you use, develop, or distribute. Linden Lab shall not be 
responsible or liable for any Third-Party Viewers."


The clause, as with the others, CANNOT DEEM a developer liable to a 
third party such as a user. It's an agreement between LL's and TPV 
developers.


The clause is similar to a clause that is inserted into a car lease 
rental whereby the lessor and the lesse might agree that:


"The lessee assumes all risks and expenses in relation to the leased 
vehicle throughout the rental period."


That clause wouldn't deem the lessee liable to a person that the lessee 
decided could take the vehicle for a spin, who subsequently crashes it 
into a shop building due to defective brakes on the vehicle. Note I am 
not saying that the lessee may not be found to be liable. However, the 
liability of the lessee, which is analogous to the position of TPV 
developers here, may arise as an issue, as between the lessee and the 
person to whom he leant the car, or even possibly the business owner of 
the building that he crashed the car into. But in that case it would be 
for a court to consider the whole of the circumstances as between the 
lessee of the car and the person to whom he said it was ok to take it 
for a spin. The term in the agreement between the lesser and lessee does 
not conclude the liability of the lessee. But IF the lessee had put 
their OWN legal mechanisms in place to avoid their own liabilty to the 
person that he said could take the car for a spin those mechanisms would 
be legally effective the lessee would not be liable.


The effect of that term in that rental agreement would be read by a 
court to effect the liability of lessor as between the lessor and the 
lessee.


And that is what 7(d) does in the context of the TPV policy. A court, at 
least those from a common law tradition, would read the document in the 
context of the entire situation. They dont read snippets and proceed to 
say  "literal interpretation here we go irrespective of how forced those 
interpretations may be".The first sentence in the clause derives its 
meaning and is unambiguously clear from the second sentence:


 "Linden Lab shall not be responsible or liable for any Third-Party 
Viewers".


There is no need for clarification from LL's lawyers or redrafting. It's 
perfectly understandable as it is. It serves the intended legal effect 
that Linden Lab intends it to have. It is NOT LL's responsibility to 
make and design legal protection mechanisms to protect TPV developers. 
It's their own responsibility.


The important thing is that it DOES NOT deprive the developer from 
putting in place their own legal mechanisms to protect the developer 
from liability to users and other third party's.


The ONLY way that you could claim that TPV policy had the effect that's 
been sought to be argued so loudly on this list is if you construed it 
as an agreement between the users of TPV's and TPV developers. And quite 
frankly it's not and the context of the document makes that reasonably 
clear. It is a policy that takes effect as part of a much larger 
agreement between, on the one hand LL's and users of their services, and 
on the other hand between LL's and TPV developers. It is possible that 
LL's could have made the documents two separate documents but as its 
shown it need not have and its reasonably clear without having to do so.


On the subject of whether there is anything that renders the TPV 
developer liable to LL's addtional to what a TPV developer may already 
be exposed it is my personal belief that there is nothing in that 
document that adds anything on that front. Aside from the TPV policy a 
TPV developer, as a result of developing software that may be used to 
connect to LL's service,/* may*/ very well be found to be under a legal 
duty to take reasonable care in the design of any additional code that 
goes into that code. A duty imposed by the common law of negligence 
separate and distinct from any legal agreement.


Additionally I dont think anyone would seek to suggest that Microsoft 
becomes liable to a company here in melbourne Australia when as a result 
of my use of the windows operating system at my home I manage to lose 
valuable information/data belonging to the company here in Australia due 
to  bug in the windows os...Now draw the approriate analogy substituting 
the relevant parties as neededMicrosoft's place is assumed by the 
TPV developer. The place of the melbourne company is assumed by LL's. 
And of course I as a user am now using the TPV developed by the TPV 
developer