Re: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe

[Dzonatas Sol]

Marine Kelley wrote:
> Exactly my thinking too, the problem us not clear whether the players  
> are cooperative or in competition. It totally changes the result.
>
> But I guess that the real goal of this challenge is to call you  
> "stupid" and to gauge your reaction. If you yell or punch the  
> recruiter, you're dismissed. If you say "my bad, you're right", you're  
> dismissed. But if you argue and explain your theory clearly, calmly  
> and with the objective of solving the problem instead of just  
> defending yourself, you prove that you're someone who can integrate a  
> team that works on a system that is both technical and social.
>
>
>
>   

Hmm. Let's think about this for a few...

The players are imperfect...

One is the recruiter that knows nothing about the recruitee...

The recruiter calls the recruitee "stupid"

In the reality of the recruitee, kids are missing (as in stolen), 
undergoing unknown symptoms of major depression, blisters on feet from 
working more than 40 hours a week, on up to 80 hours a week to keep 
family together for more than a year, pressured to work more due to 
legal problems, almost on the street due to leftover money not meeting 
needs, etc etc (this is not made up)

If the recruitor has no knowledge of this, which they shouldn't because 
of employment laws, then to call the recruitee "stupid" and for the 
recruitee to act any bit calm would be a major ability to stay calm 
under such hardship... even if the recruitee just simply said "my bad, 
your right" just to pass up an unfair question and explain anything now 
going on in the mind of the recruitee.

Major Depression Disorder is a disability that would be exploited by 
such question, and this recruitee would never get hired due to this 
disability, which is against law to not hire someone because of a 
disability.

The reruitee states the obvious and the recruiter takes it as a legal 
threat, which questions the ability of how this ever will work as a team 
on a system that is both technical and social... where both win.

Long story short... but one is still losing, so when does the "fighting" 
stop?
___
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] Consensus? was: Client-side scripting in Snowglobe

[Morgaine]

On Mon, Feb 22, 2010 at 11:56 PM, Carlo Wood  wrote:

> There is no need for A != B.
>
> Why not define the words A and B such that A includes B?  B \in A
>
> Then you can still talk about the subject, since there is still a C = A
> \not B,
> such that the intersection of B and C is empty.
>


For the simple reason that in our case there is no C = A \not B, because A
is the set of all scripts that execute client-side, and that includes all
the possible types of scripting/programming that we are discussing here:
they are all subsets of A.



>
> In other words, yes Client-Extensions include plugins that implement
> Client-side scripting, but it won't give confusion because if someone means
> that, they will say "Client-side scripting", so if they DON'T say that,
> they probably mean something else, either something broader (including
> client-side script plugins) or something entirely different even.



Except that there is no possibility of avoiding confusion your way, because
when people write scripts that execute in the client, they will unavoidably
call it client-side scripting.  It's totally unavoidable because it's normal
use of English.

It's also normal use of the word "scripting" in numerous language
communities --- for example, Lua and Perl and shell programmers always talk
about their Lua scripts and Perl scripts and shell scripts, regardless of
the application, and it's doubly prevalent when the scripting language is
used embedded in a host application because then it distinguishes the script
program from the host program.  This use of "scripting" is pervasive
throughout computing's many language communities.

That's not going to change, so rather than trying to sweep back the tide and
stopping people saying that they're doing client-side scripting when they're
programming client extensions, it's easier to accept that people will always
call scripting "scripting" wherever it is being applied, and invent two new
disjoint terms instead.

It's also worth adding to this Tigro Spottystripe's
observationthat
a control panel that provides information and control over script
properties, resourcing, protection, and so on, is applicable to all kinds of
scripts, regardless of where they come from and what role they play.  Even
just thinking about such practical areas alone, there is a push for
commonality.

It's not even totally black and white that there *are* two separate
categories.  One could easily envisage a system where the user controls what
local facilities are made accessible to a sandbox per script, so that it's
not "all or nothing" like we've been describing up to now.  Even trust is
not a black and white thing, and nor is installation --- scripts loaded
automatically could be cached for longer-lived retention, or even retained
forever.  Tigro's suggestion is interesting.  There really is a continuum
here.


Morgaine.



===

On Mon, Feb 22, 2010 at 11:56 PM, Carlo Wood  wrote:

> There is no need for A != B.
>
> Why not define the words A and B such that A includes B?  B \in A
>
> Then you can still talk about the subject, since there is still a C = A
> \not B,
> such that the intersection of B and C is empty.
>
> In other words, yes Client-Extensions include plugins that implement
> Client-side scripting, but it won't give confusion because if someone means
> that, they will say "Client-side scripting", so if they DON'T say that,
> they probably mean something else, either something broader (including
> client-side script plugins) or something entirely different even.
>
> On Mon, Feb 22, 2010 at 04:51:20AM +, Morgaine wrote:
> > The moral of the story as it pertains to our topic is that when the
> superset is
> > ambiguous as in our case (all scripts running client-side are naturally
> > "client-side scripts"), then the ambiguity won't stop until you subset
> the
> > space into disjoint subsets so that you can discuss each subset
> separately
> > without confusion.
> >
> > That's what I've been trying to do, because "client-side script" is a
> universal
> > term that naturally denotes all scripts running in the client by simple
> plain
> > English, so you can't call just one subset of the scripts by that name
> without
> > creating ambiguity.
>
> --
> Carlo Wood 
>
___
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] Snowglobe 2 and Open Source

[Howard Look]

Hi Open Source devs,

As you probably saw, we just launched Viewer 2 to public Beta. We've been dark 
for a long time, but it is for good reason: We needed to do a total overhaul of 
our user experience and that's not something best done by a large group. 
Honestly, there are times when we had an awful lot of cooks in the kitchen just 
with our internal team!

We also today are launching Snowglobe 2, the Open Source package of Viewer 2.0. 
Merov has been working really hard to make this happen on the same day that we 
launched the Viewer 2 Public Beta, so please send him lots of love. As I type, 
Merov is pushing the svn repository and updating the Snowglobe wiki.

We've been completely consumed with getting Viewer 2.0 out the door, which is 
why you've heard so little from us about where we plan to go from here. But I 
want to reiterate: We are committed to open source and to supporting the open 
development community. We embrace the notion that this community develops 
viewers that serve the needs of a wide range of Residents while we pursue a 
broader consumer market.

I realize that it frustrates some that we are not a completely "open 
development" project, i.e. we do not do our internal development in a public 
repository. I do not expect this change in the near future. Over time, we hope 
that core components of our code can be developed in the open, while the 
functionality that we wish to keep proprietary can be developed internally. I 
expect us to evolve to a model that is less like Firefox, and more like 
Safari+WebKit, where the core engine is an open development project but the 
high level app is proprietary. Unfortunately, we're not there yet. Our code is 
not yet modular enough to support that model.

There have been many wonderful ideas here recently regarding viewer 
scriptability, and that's definitely an area we intend to pursue. It goes 
hand-in-hand with making a more modular code base. The time hasn't been right 
for us to engage deeply in this conversation; again, we've been quite busy 
getting 2.0 out the door. Once the dust settles from the 2.0  launch and we're 
on track to deliver 2.1 in short order, we'll be back and very interested in 
engaging on this topic.

Thanks for your support and patience.

Regards,
Howard

___
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] Third party viewer policy

[Gigs]

http://secondlife.com/corporate/tpv.php

You all realize this is massively incompatible with the GPL, right?


___
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

[Mike Dickson]

On 02/23/2010 02:16 PM, Gigs wrote:
> http://secondlife.com/corporate/tpv.php
>
> You all realize this is massively incompatible with the GPL, right?
>
>
> ___
> 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
>
Not at all.  They're not restricting access to the code. They're 
restricting access to their service. And defining the terms under which 
that service is provided.

Mike
___
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

[Soft Linden]

On Tue, Feb 23, 2010 at 2:21 PM, Mike Dickson  wrote:
>
> On 02/23/2010 02:16 PM, Gigs wrote:
> > http://secondlife.com/corporate/tpv.php
> >
> > You all realize this is massively incompatible with the GPL, right?
> >
> Not at all.  They're not restricting access to the code. They're
> restricting access to their service. And defining the terms under which
> that service is provided.

Mike's correct.

If you see any wording that's ambiguous about that, let us know.
___
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

[Robin Cornelius]

On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden  wrote:
> Mike's correct.
>
> If you see any wording that's ambiguous about that, let us know.
> ___


Well you seem to have spelled the end of my debian/ubuntu project, I
can not meet the tems of the third party viewer policy:-

"On your software download page or in another location that a user
must visit before installing the Third-Party Viewer, you must disclose
the following:"

I cannot do this with an apt-repository, the user can bypass every
possible webpage or description field. and the fact the policy says
this is a MUST. The only possible way to do this is to create a custom
program that displays a screen during the install hook of the package
and aborts the package install. This can no longer be accepted in to
the main debian or ubuntu repositories.

Also it appears that i cannot use the snowglobe logo or name, even
though i'm basicly building from almost prestine source. I though this
was the entire point of the snowglobe rebranding, but now we are
exactly where we were with secondlife 12 months ago.

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] Third party viewer policy

[Gigs]

Soft Linden wrote:
> On Tue, Feb 23, 2010 at 2:21 PM, Mike Dickson  wrote:
>> On 02/23/2010 02:16 PM, Gigs wrote:
>>> http://secondlife.com/corporate/tpv.php
>>>
>>> You all realize this is massively incompatible with the GPL, right?
>>>
>> Not at all.  They're not restricting access to the code. They're
>> restricting access to their service. And defining the terms under which
>> that service is provided.
> 
> Mike's correct.
> 
> If you see any wording that's ambiguous about that, let us know.
> ___
> 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
> 

Nearly all of it?

I don't see how it would be possible to make a viewer that does not fall 
under this policy.

___
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

[Brent Tubbs]

For a while I've been batting around the idea of creating an SVN-bot to
enable much-improved version control for inworld scripts; a must-have when
you're developing as part of a team.  The same-creator policy on content
export would seem to prohibit that though.

I realize that you probably don't want to have different rules for each
different content type, but the one-size-fits-all rule in the current policy
doesn't fit scripts well at all.

On Tue, Feb 23, 2010 at 12:37 PM, Robin Cornelius  wrote:

> On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden  wrote:
> > Mike's correct.
> >
> > If you see any wording that's ambiguous about that, let us know.
> > ___
>
>
> Well you seem to have spelled the end of my debian/ubuntu project, I
> can not meet the tems of the third party viewer policy:-
>
> "On your software download page or in another location that a user
> must visit before installing the Third-Party Viewer, you must disclose
> the following:"
>
> I cannot do this with an apt-repository, the user can bypass every
> possible webpage or description field. and the fact the policy says
> this is a MUST. The only possible way to do this is to create a custom
> program that displays a screen during the install hook of the package
> and aborts the package install. This can no longer be accepted in to
> the main debian or ubuntu repositories.
>
> Also it appears that i cannot use the snowglobe logo or name, even
> though i'm basicly building from almost prestine source. I though this
> was the entire point of the snowglobe rebranding, but now we are
> exactly where we were with secondlife 12 months ago.
>
> 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
>
___
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

[Soft Linden]

On Tue, Feb 23, 2010 at 2:37 PM, Robin Cornelius
 wrote:
> On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden  wrote:
>> Mike's correct.
>>
>> If you see any wording that's ambiguous about that, let us know.
>> ___
>
>
> Well you seem to have spelled the end of my debian/ubuntu project, I
> can not meet the tems of the third party viewer policy:-
>
> "On your software download page or in another location that a user
> must visit before installing the Third-Party Viewer, you must disclose
> the following:"

I'll pass this back for discussion. Something like an extra dialog the
first time a user connects to the SL grid would probably be a
reasonable alternative. I'll find out for sure.
___
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] Snowglobe 2 and Open Source

[Mike Monkowski]

Howard Look wrote:
> from here. But I want to reiterate: *We are committed to open source and 
> to supporting the open development community.* We embrace the notion 
> that this community develops viewers that serve the needs of a wide 
> range of Residents while we pursue a broader consumer market.

I think you meant to say "a *narrower* consumer market," but no matter.

I can find the Snowglobe 2.0 source download, but not the beta viewer 
source download.  have you created a new place to put it?

Mike

___
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

[Ambroff Linden]

On Tue, Feb 23, 2010 at 12:37 PM, Robin Cornelius  wrote:

> On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden  wrote:
> > Mike's correct.
> >
> > If you see any wording that's ambiguous about that, let us know.
> > ___
>
>
> Well you seem to have spelled the end of my debian/ubuntu project, I
> can not meet the tems of the third party viewer policy:-
>
> "On your software download page or in another location that a user
> must visit before installing the Third-Party Viewer, you must disclose
> the following:"
>
> I cannot do this with an apt-repository, the user can bypass every
> possible webpage or description field. and the fact the policy says
> this is a MUST. The only possible way to do this is to create a custom
> program that displays a screen during the install hook of the package
> and aborts the package install. This can no longer be accepted in to
> the main debian or ubuntu repositories.
>

You can certainly do this using debconf, see the source for the
sun-java6-bin[1] package in 9.10 for an example. That package uses debconf
to present localized and frontend agnostic dialogs to prompt the user to
accept a special license. This is the same technique used by exim, postfix,
mysql-server, and loads of other packages to accept user input during
installation to perform some configuration tasks.

http://www.fifi.org/doc/debconf-doc/tutorial.html

-Ambroff

[1] Relevant code is in sun-java5-1.5.0-14/debian/JB-jdk.preinst.in
___
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

[Robin Cornelius]

On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden  wrote:
> Mike's correct.
>
> If you see any wording that's ambiguous about that, let us know.


Well there are many other issues another couple are :-

1h "Central to Second Life is the principle of shared experience. The
services we provide through our viewers, for example, our Land Store,
the LindeX exchange, and the Xstreet SL marketplace, are designed to
enhance Residents’ shared experience. We may ask you to make changes
to your Third-Party Viewer if it disables certain of our services, or
if we believe it is inconsistent with the principle of shared
experience or otherwise negatively affects the Second Life user
experience. If we do, you agree to make the changes we request."

This kind of blocks text viewers as well, of which i author one, as
clearly a text only viewer does not share the same experience as a
full 3d viewer.

Also any one using mono with libomv has an issue as that cannot get
the adaptor mac address and passes a NULL mac address, in the past LL
have allowed a null mac address as they knew of this problem, clearly
now though thats a breach of 2c part i.

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] Third party viewer policy

[C.J. Adams-Collier]

Are you sure?  I'd think that denying connection to their services would
not be limited in any way by the GPL.  But IANAL.

On Tue, 2010-02-23 at 15:16 -0500, Gigs wrote: 
> http://secondlife.com/corporate/tpv.php
> 
> You all realize this is massively incompatible with the GPL, right?
> 
> 
> ___
> 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



signature.asc
Description: This is a digitally signed message part
___
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

[C.J. Adams-Collier]

The Debian (Sun) Java runtime package has such an agreement requirement
or did at one point.

On Tue, 2010-02-23 at 20:37 +, Robin Cornelius wrote: 
> On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden  wrote:
> > Mike's correct.
> >
> > If you see any wording that's ambiguous about that, let us know.
> > ___
> 
> 
> Well you seem to have spelled the end of my debian/ubuntu project, I
> can not meet the tems of the third party viewer policy:-
> 
> "On your software download page or in another location that a user
> must visit before installing the Third-Party Viewer, you must disclose
> the following:"
> 
> I cannot do this with an apt-repository, the user can bypass every
> possible webpage or description field. and the fact the policy says
> this is a MUST. The only possible way to do this is to create a custom
> program that displays a screen during the install hook of the package
> and aborts the package install. This can no longer be accepted in to
> the main debian or ubuntu repositories.
> 
> Also it appears that i cannot use the snowglobe logo or name, even
> though i'm basicly building from almost prestine source. I though this
> was the entire point of the snowglobe rebranding, but now we are
> exactly where we were with secondlife 12 months ago.
> 
> 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



signature.asc
Description: This is a digitally signed message part
___
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

[Gigs]

Robin Cornelius wrote:
> On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden  wrote:
>> Mike's correct.
>>
>> If you see any wording that's ambiguous about that, let us know.
> 
> 
> Well there are many other issues another couple are :-
> 

There are many many other issues.

* It gives Linden Lab the ability to delete your private data:

"You agree to update or delete at our request any data that you have 
received from Second Life "


* It includes vague terms that are open ended:

"You must not violate or promote violation of any law or the rights of 
any individual or entity"

Any law?  Including Muslim law?  I guess depictions of homosexuality or 
women wearing normal clothes are right out.

"if you are a Developer, you are also responsible for all Third-Party 
Viewers that you develop or distribute."

Responsible in what way?  No one is going to accept liability for what 
their users do with the viewer software.  The GPL specifically allows 
developers to disclaim responsibility.  Here you give it back to them.

"Expose Second Life users, Linden Lab, or third parties to legal 
liability or harm as determined by us in our sole discretion."

How the hell are we supposed to prevent our users from exposing 
themselves to legal liability or harm?  The Internet is a big dangerous 
place.  We can't be responsible for what users do.  Period.

"we may request that you add, modify, or remove features, functionality, 
code or content, and you agree to comply with the request within a 
reasonable timeframe specified by Linden Lab."

The remedy should be solely limited to termination of access to the 
Second Life service.  Linden Lab should not be able to "assign work" to 
open source developers.

*No* developer should subject themselves to the terms of this draconian 
"policy".

We are going to need to know how we can "opt-out" of this and prevent 
our viewers from connecting to the Second Life service while remaining 
protocol compatible.  The way that it's written, you apparently wind up 
bound by it if your users connect to Second Life even if you don't want 
them to.
___
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

[Vex Streeter]

Soft Linden wrote:

  On Tue, Feb 23, 2010 at 2:21 PM, Mike Dickson  wrote:
  
  
On 02/23/2010 02:16 PM, Gigs wrote:


  http://secondlife.com/corporate/tpv.php

You all realize this is massively incompatible with the GPL, right?

  

Not at all.  They're not restricting access to the code. They're
restricting access to their service. And defining the terms under which
that service is provided.

  
  
Mike's correct.

If you see any wording that's ambiguous about that, let us know.
  

Section 1c unambiguously imposes a GPL-incompatible download and/or
installation requirement that is unrelated to the use of the software
with the SL grid(s).

IMHO, it would be more appropriate to handle this like new user dialogs
and license changes already do - then it is clearly a use of service
agreement, and the third-party viewer registry should already have all
that information on hand on Linden Labs' servers.


___
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

[Lawson English]

Vex Streeter wrote:
> Soft Linden wrote:
>> On Tue, Feb 23, 2010 at 2:21 PM, Mike Dickson  wrote:
>>   
>>> On 02/23/2010 02:16 PM, Gigs wrote:
>>> 
 http://secondlife.com/corporate/tpv.php

 You all realize this is massively incompatible with the GPL, right?

   
>>> Not at all.  They're not restricting access to the code. They're
>>> restricting access to their service. And defining the terms under which
>>> that service is provided.
>>> 
>>
>> Mike's correct.
>>
>> If you see any wording that's ambiguous about that, let us know.
>>   
> Section 1c unambiguously imposes a GPL-incompatible download and/or 
> installation requirement that is unrelated to the use of the software 
> with the SL grid(s).



The preamble specifically states that the policy only applies to viewers 
meant to be used by SL. In essence, LL reserves the right to deny access 
to viewers that don meet their requirements.


MY concern is about prototyping viewers. I can certainly add a thing to 
timestamp a version string during login, but with smalltalk, I'm 
constantly tweaking the code *while* I'm connected to SL. Does this mean 
I have to log out every time I modify something in my squeak client just 
so I can change the version string?

Even if I don't change the SL viewer code, but only something else in 
the Squeak image, its still part of the same application due to how 
Smalltalk works. So any time I'm connected to SL using smalltalk, and I 
play with the workspace to test a new one-liner, I'm effectively 
changing the viewer code, and must log out and back in with a new 
version string...

Only partly joking here. Taking this policy to its extreme may sound 
silly, but people are correct: its poorly worded.





Lawson


___
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

[Vector Hastings]

I love the text only viewers. Would hate to see them disappear. 

How about SLIM? I realize that can probably be categorized as a separate
service that's not a "viewer," but you could also see it as a "chat only"
viewer. 

Could a third-party text-only viewer be considered compliant with 1h if it
matches SLIM's functionality? 

Vector

-Original Message-
From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Robin
Cornelius
Sent: Tuesday, February 23, 2010 1:44 PM
To: Soft Linden
Cc: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] Third party viewer policy

On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden  wrote:
> Mike's correct.
>
> If you see any wording that's ambiguous about that, let us know.


Well there are many other issues another couple are :-

1h "Central to Second Life is the principle of shared experience. The
services we provide through our viewers, for example, our Land Store,
the LindeX exchange, and the Xstreet SL marketplace, are designed to
enhance Residents' shared experience. We may ask you to make changes
to your Third-Party Viewer if it disables certain of our services, or
if we believe it is inconsistent with the principle of shared
experience or otherwise negatively affects the Second Life user
experience. If we do, you agree to make the changes we request."

This kind of blocks text viewers as well, of which i author one, as
clearly a text only viewer does not share the same experience as a
full 3d viewer.

Also any one using mono with libomv has an issue as that cannot get
the adaptor mac address and passes a NULL mac address, in the past LL
have allowed a null mac address as they knew of this problem, clearly
now though thats a breach of 2c part i.

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

___
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

[Domino Marama]

> We may ask you to make changes
> to your Third-Party Viewer if it disables certain of our services, or
> if we believe it is inconsistent with the principle of shared
> experience or otherwise negatively affects the Second Life user
> experience. If we do, you agree to make the changes we request.

I guess I can cross making an offline rendering client for machinima off
my todo list :)

More seriously, the policy as it stands would make me cross anything
that remotely resembles a client off my todo list. Gigs nailed the major
reasons why..

___
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

[Latif Khalifa]

It also means that now I need to hire a lawyer in order to continue to
make and distribute my text viewer (Radegast), with special features
aimed at people with disabilities. The terms mandate that I need to
have an official privacy policy published, and I also need to to show
SL ToS to users (and I have no idea where would I get it, and how to
tell if it's updated). "Shared experience" clause doesn't even deserve
spending time on it.

On Tue, Feb 23, 2010 at 9:16 PM, Gigs  wrote:
> http://secondlife.com/corporate/tpv.php
>
> You all realize this is massively incompatible with the GPL, right?
>
>
> ___
> 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

[Lawson English]

Latif Khalifa wrote:
> It also means that now I need to hire a lawyer in order to continue to
> make and distribute my text viewer (Radegast), with special features
> aimed at people with disabilities. The terms mandate that I need to
> have an official privacy policy published, and I also need to to show
> SL ToS to users (and I have no idea where would I get it, and how to
> tell if it's updated). "Shared experience" clause doesn't even deserve
> spending time on it.
>   


If a media plugin provides collaboration between participating viewers 
and doesn't update the sim, or only updates the sim with a view-only 
version of what people are working on, does this violate the "shared 
experience" clause?

What about musicians sharing sound data between themselves via client 
plugins and doing mixing before uploading the sound to the sim?

And what about the VWRAP proposal to let clients establish connections 
for external services via capabilities? Such a capability could easily 
violate the new policy. Lots of vague stuff in this policy.


L.




> On Tue, Feb 23, 2010 at 9:16 PM, Gigs  wrote:
>   
>> http://secondlife.com/corporate/tpv.php
>>
>> You all realize this is massively incompatible with the GPL, right?
>>
>>
>> ___
>> 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

[opensource-dev] Trying to compile the viewer, what does this mean?

[james ross]

I am still trying to compile the viewer by trying every tutorial I can find.  I 
pasted the link to the wiki site below in which I am having issues. I am 
currently in the proccess of downloading a copy of .NET 2003 from the MSDNA so 
that I can open the Apache files without them corrupting on me.  I made it to 
this section on OpenSSL and hit a wall. I tried downloading the OpenSSL and 
noticed that it is a tarball..I found a WIN-32 Openssl but cannot locate 
this fabled 'perl Configure VC-WIN32'  command.  Also the cd %PATH% gives me a 
file path is to long error. 

If someone could explain this OPENSSL step I would appreciate it.

WebSiteLink: 
http://wiki.secondlife.com/wiki/Compiling_the_viewer_libraries_%28MSVS_2003%29#Boost

OpenSSL 
 Download and extract: http://www.openssl.org/source/
 Using the command prompt, build the static libraries:
 cd %PATH%
 perl Configure VC-WIN32
 ms\do_masm

 Edit openssl-X.X.Xy\ms\nt.mak
 Change /MD to /MT in CFLAGS

 back in the command prompt:
 "C:\Program Files\Microsoft Visual Studio .net 
2003\Common7\Tools\vsvars32.bat"
 nmake -f ms\nt.mak
 copy all the ".lib" files from "openssl-X.X.Xy\out32" to 
"libraries\i686-win32\lib_release"



Thanks,
James

  
_
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/___
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

[Rob Nelson]

Thanks LL, you killed my viewer that I have developed alone for two
years and was probably a week away from releasing, due to one stupid
copyright enfarcement rule: No "Life" in the name.  Do you realize how
much documentation, sourcecode, licensing, subdomains, bug trackers,
wiki, images, logos, google code/SVN repo, etc that I, a one-man
development team with other things on his mind have to change?  Did you
even consider all of this prior to releasing this policy?

If I do resume development, AGNI will not be a grid my users will be
able to connect to. I hope others with the same problem will also
boycott your grid because of this.

All I wanted to do was develop some software that would maybe be helpful
to people, or perhaps improve the user experience.  Now no one can use
it.  Thanks a lot.


I've tried hard over the last year to 
On Tue, 2010-02-23 at 15:16 -0500, Gigs wrote:
> http://secondlife.com/corporate/tpv.php
> 
> You all realize this is massively incompatible with the GPL, right?
> 
> 
> ___
> 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

[opensource-dev] Smoke test plans for viewer 2 available?

[Zai Lynch]

Hi here!

I was pondering:
Could existing test plans for viewer 2 be published in the public wiki?
It would certainly be cool to have these, since localization teams are now
asked to provide bug reports for localized versions. Having some kind of
step by step plan to cover all viewer parts would certainly be a benefit for
that.

Would also be good for Snowglobe 2.0.

zai
___
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] question on SL/SG 2.0 avatar backend

[Robert Martin]

ive been trying to get somebody to code an editor for SL clothing and
one of the things ive found is a file deep somewhere in the tree that
has the parameters of the avatar in a nice neat list.
The question is since i seem to have dumped the original could
somebody remind me where this file is in the source tree
(i would like to see the changes that 2.0 has done to this file).

-- 
Robert L Martin

oh and a side note to be flipped to the docs team specs for the tattoo
and alpha layer would be nifty
___
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] question on SL/SG 2.0 avatar backend

[Nyx Linden]

I believe you're referring to avatar_lad.xml, which is stored in the 
character subdirectory of your client's install directory.

If you have any specific questions on it, please let me know!

 -Nyx

Robert Martin wrote:
> ive been trying to get somebody to code an editor for SL clothing and
> one of the things ive found is a file deep somewhere in the tree that
> has the parameters of the avatar in a nice neat list.
> The question is since i seem to have dumped the original could
> somebody remind me where this file is in the source tree
> (i would like to see the changes that 2.0 has done to this file).
>
>   

___
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

[malachi]

im curious as to how this will apply to clients and bots that seem to 
have the ability to not only gather agents ip addresses but by obtaining 
this information raid those agents computers searching for data... 
particularly the new copybot detection system by an unmentioned 
developer. The fact that Linden Lab has allowed this product to be 
released implements Linden Lab in possible legal actions. This is a 
violation of not only the Second Life Terms of Service but various other 
Internet related Laws and policies. I for one would like to know if this 
bot system will be removed and its creators rights to the Second Life 
grid be revoked or if they will be allowed to continue to hack into 
residents computers looking for information regarding 3rd party clients 
being installed on the machines. If they are allowed to continue then i 
would like for Linden Lab to hand over all Real life information on its 
creator for a possible Law Suit.

Because for one i never authorized anyone at Linden Lab much less anyone 
that simply just plays Second Life to have access to my computer and my 
data. thus the ability of a resident to retrieve such information is a 
violation of my privacy. point blank.
___
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

[Thomas Shikami]

malachi schrieb:
> im curious as to how this will apply to clients and bots that seem to 
> have the ability to not only gather agents ip addresses but by obtaining 
> this information raid those agents computers searching for data... 
> particularly the new copybot detection system by an unmentioned 
> developer. The fact that Linden Lab has allowed this product to be 
> released implements Linden Lab in possible legal actions. This is a 
> violation of not only the Second Life Terms of Service but various other 
> Internet related Laws and policies.
Sills bot system doesn't do anything illegal in activity. It does not 
scan the users computers as can be verified by intrusion detection 
software. Also an IP address is not neccessary to fingerprint a used 
viewer. There is enough information publicly available from SL servers 
alone that allows detection of the viewer being used.
>  I for one would like to know if this 
> bot system will be removed and its creators rights to the Second Life 
> grid be revoked or if they will be allowed to continue to hack into 
> residents computers looking for information regarding 3rd party clients 
> being installed on the machines. If they are allowed to continue then i 
> would like for Linden Lab to hand over all Real life information on its 
> creator for a possible Law Suit.
>   
Pretty much a flame post. Don't feed the trolls.
> Because for one i never authorized anyone at Linden Lab much less anyone 
> that simply just plays Second Life to have access to my computer and my 
> data. thus the ability of a resident to retrieve such information is a 
> violation of my privacy. point blank.
Troll post.
___
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] Snowglobe 2 and Open Source

[Trilo Byte]

Awesome to see something posted so quickly (though huge shame that testing 
resources like this group and BSI weren't utilized).

Can't help but notice we've lost some functionality from Snowglobe 1.3 
namely the drop down to choose the user name on login, and panning around the 
mini-map.  What else from recent builds may have been lost/skipped/thrown away?

TriloByte Zanzibar

On Feb 23, 2010, at 11:42 AM, Howard Look wrote:

> Hi Open Source devs,
> 
> As you probably saw, we just launched Viewer 2 to public Beta. We've been 
> dark for a long time, but it is for good reason: We needed to do a total 
> overhaul of our user experience and that's not something best done by a large 
> group. Honestly, there are times when we had an awful lot of cooks in the 
> kitchen just with our internal team!
> 
> We also today are launching Snowglobe 2, the Open Source package of Viewer 
> 2.0. Merov has been working really hard to make this happen on the same day 
> that we launched the Viewer 2 Public Beta, so please send him lots of love. 
> As I type, Merov is pushing the svn repository and updating the Snowglobe 
> wiki.
> 
> We've been completely consumed with getting Viewer 2.0 out the door, which is 
> why you've heard so little from us about where we plan to go from here. But I 
> want to reiterate: We are committed to open source and to supporting the open 
> development community. We embrace the notion that this community develops 
> viewers that serve the needs of a wide range of Residents while we pursue a 
> broader consumer market.
> 
> I realize that it frustrates some that we are not a completely "open 
> development" project, i.e. we do not do our internal development in a public 
> repository. I do not expect this change in the near future. Over time, we 
> hope that core components of our code can be developed in the open, while the 
> functionality that we wish to keep proprietary can be developed internally. I 
> expect us to evolve to a model that is less like Firefox, and more like 
> Safari+WebKit, where the core engine is an open development project but the 
> high level app is proprietary. Unfortunately, we're not there yet. Our code 
> is not yet modular enough to support that model.
> 
> There have been many wonderful ideas here recently regarding viewer 
> scriptability, and that's definitely an area we intend to pursue. It goes 
> hand-in-hand with making a more modular code base. The time hasn't been right 
> for us to engage deeply in this conversation; again, we've been quite busy 
> getting 2.0 out the door. Once the dust settles from the 2.0  launch and 
> we're on track to deliver 2.1 in short order, we'll be back and very 
> interested in engaging on this topic.
> 
> Thanks for your support and patience.
> 
> Regards,
> Howard
> 
>> 
> ___
> 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

[malachi]

sorry thomas but the idea that a person can be detected by skills system 
while running LL's client on a name that is new today and never been 
logged in on any other client... shows that the information used to 
detect if a person has 'ever' used a bad client is coming from the 
persons computer. and the fact that one of the admins over skills system 
tells you that in order to run a bad client and not be detected by the 
system is to install vmware and run the client there tells me that the 
system is in fact gather information from your computer. the fact that 
the system in not installed on my computer leads me to believe its 
HACKING. you can protect your friends all you want thomas but Linden Lab 
needs to address that fact that this system is a HUGE violation of the 
terms of service and various local state and governmental laws.
On 2/23/2010 9:11 PM, Thomas Shikami wrote:
> malachi schrieb:
>
>> im curious as to how this will apply to clients and bots that seem to
>> have the ability to not only gather agents ip addresses but by obtaining
>> this information raid those agents computers searching for data...
>> particularly the new copybot detection system by an unmentioned
>> developer. The fact that Linden Lab has allowed this product to be
>> released implements Linden Lab in possible legal actions. This is a
>> violation of not only the Second Life Terms of Service but various other
>> Internet related Laws and policies.
>>  
> Sills bot system doesn't do anything illegal in activity. It does not
> scan the users computers as can be verified by intrusion detection
> software. Also an IP address is not neccessary to fingerprint a used
> viewer. There is enough information publicly available from SL servers
> alone that allows detection of the viewer being used.
>
>>   I for one would like to know if this
>> bot system will be removed and its creators rights to the Second Life
>> grid be revoked or if they will be allowed to continue to hack into
>> residents computers looking for information regarding 3rd party clients
>> being installed on the machines. If they are allowed to continue then i
>> would like for Linden Lab to hand over all Real life information on its
>> creator for a possible Law Suit.
>>
>>  
> Pretty much a flame post. Don't feed the trolls.
>
>> Because for one i never authorized anyone at Linden Lab much less anyone
>> that simply just plays Second Life to have access to my computer and my
>> data. thus the ability of a resident to retrieve such information is a
>> violation of my privacy. point blank.
>>  
> Troll post.
> ___
> 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

[opensource-dev] Flames about CDS (was: Re: Third party viewer policy)

[Thomas Shikami]

malachi schrieb:
> sorry thomas but the idea that a person can be detected by skills system 
> while running LL's client on a name that is new today and never been 
> logged in on any other client... shows that the information used to 
> detect if a person has 'ever' used a bad client is coming from the 
> persons computer. and the fact that one of the admins over skills system 
> tells you that in order to run a bad client and not be detected by the 
> system is to install vmware and run the client there tells me that the 
> system is in fact gather information from your computer. the fact that 
> the system in not installed on my computer leads me to believe its 
> HACKING. you can protect your friends all you want thomas but Linden Lab 
> needs to address that fact that this system is a HUGE violation of the 
> terms of service and various local state and governmental laws.
>   
Hardware based packet loggers don't lie about that. (Those that you plug 
between computer and internet)
What I see is that you are crying about her system and that you want it 
removed. Spreading unverifiable rumors about how her system works in 
your eyes. Because she put your client on the banlist because your 
client supports griefing or copybotting? Come on, mature. Just don't 
spread false informations that can easily be prooven being wrong. The 
system is detecting indeed if you used a griefer client, it does this 
pretty well. (it takes a while until the fingerprinting is changed to 
the currently used viewer and not guaranteed to be completely reverted, 
so relogging from a banned to a legit viewer and teleporting to a CDS 
enabled area will likely detect that you used that banned viewer on your 
last login. This effect can even last for multiple logins. So better not 
use a banned viewer ever.)
Do us a favour and take it up with LL and Skills. This mailing list is 
not for spreading of misinformation and slander.
___
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

[Morgaine]

Gigs is totally right that http://secondlife.com/corporate/tpv.php is
completely incompatible with the GPL.

Specifically, TPV clause 1c is incompatible with GPLv2 clause 6.

GPLv2 has a FAQ that elaborates on this point, highlighting from clause 6
that:


   - "*You may not impose any further restrictions on the recipients'
   exercise of the rights granted herein.*"


TPV 1c adds massive further restrictions on Developers that fall under the
condition of "*If you are a Developer who distributes Third-Party Viewers to
others".*

Please note the word "*distributes*" in the condition above, because it is
crucial.

GPLv2 is a *distribution license*, in other words it triggers at the point
of distribution of GPL-licensed code.  The freedoms that GPLv2 grants apply
at that specific point in time, allowing a developer to *distribute* his
code freely downstream to the next recipient, who can then modify the code
again and *distribute* it to others downstream, and so on.

It is this distribution that TPV 1c specifically entangles with a mass of
restrictions.  This cannot be done with the GPL of any version.  TPV is
dramatically GLPv2 non-compliant.

I fully expect that LL did not intend to make TPV 1c apply so broadly and to
be GPL non-compliant.  Rather than this being intentional, it's more likely
(I think) that the document was drafted by someone not very good at legal
language and ignorant of the GPL.  Unfortunately, the words stand as
written, so unless they are rewritten, no Linden-derived viewer will be
distributable under GPL.

GPL cannot be used to grant fewer freedoms than the GPL specifies.

Lindens are of course entirely within their rights to determine how their
service is used.  What they cannot do is use the GPLv2 license while at the
same time imposing on the developer "*further restrictions on the
recipients' exercise of the rights granted herein.*"


Morgaine.





===

On Tue, Feb 23, 2010 at 8:16 PM, Gigs  wrote:

> http://secondlife.com/corporate/tpv.php
>
> You all realize this is massively incompatible with the GPL, right?
>
>
> ___
> 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

[Vex Streeter]

On 2/23/2010 6:05 PM, Lawson English wrote:

Vex Streeter wrote:

Soft Linden wrote:
On Tue, Feb 23, 2010 at 2:21 PM, Mike Dickson  
wrote:

On 02/23/2010 02:16 PM, Gigs wrote:

http://secondlife.com/corporate/tpv.php

You all realize this is massively incompatible with the GPL, right?


Not at all.  They're not restricting access to the code. They're
restricting access to their service. And defining the terms under 
which

that service is provided.


Mike's correct.

If you see any wording that's ambiguous about that, let us know.
Section 1c unambiguously imposes a GPL-incompatible download and/or 
installation requirement that is unrelated to the use of the software 
with the SL grid(s).




The preamble specifically states that the policy only applies to 
viewers meant to be used by SL. In essence, LL reserves the right to 
deny access to viewers that don meet their requirements.

But that isn't what the policy says:

   1. Required Functionality and Disclosures
   If you are a Developer of Third-Party Viewers, we require the
   following of all Third-Party Viewers:
   ...
   c. On your software download page or in another location that a user
   must visit before installing the Third-Party Viewer, you must
   disclose the following:
   [1.c.i - 1.c.v contents don't matter at all to the GPL]

These are constraints which explicitly place new unconditional 
restrictions on the _delivery_of_software_ (derivative works of the SL 
viewer codebase) by third party developers to end-users and downstream 
developers, *not* constraints on connecting to LL's services.  This is 
one of the mechanisms (if not the content) of constraint that FSF 
carefully designed GPL to discourage.


MY concern is about prototyping viewers. I can certainly add a thing 
to timestamp a version string during login, but with smalltalk, I'm 
constantly tweaking the code *while* I'm connected to SL. Does this 
mean I have to log out every time I modify something in my squeak 
client just so I can change the version string?


Even if I don't change the SL viewer code, but only something else in 
the Squeak image, its still part of the same application due to how 
Smalltalk works. So any time I'm connected to SL using smalltalk, and 
I play with the workspace to test a new one-liner, I'm effectively 
changing the viewer code, and must log out and back in with a new 
version string...


Only partly joking here. Taking this policy to its extreme may sound 
silly, but people are correct: its poorly worded.
heh - then client-side scripting (of whichever varieties) will be 
generally problematic, as will any users of the media api.


___
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] Snowglobe 2 and Open Source

[Philippe (Merov) Bossut]

On Tue, Feb 23, 2010 at 6:19 PM, Trilo Byte  wrote:

> Awesome to see something posted so quickly (though huge shame that testing
> resources like this group and BSI weren't utilized).
>
> Can't help but notice we've lost some functionality from Snowglobe 1.3
> namely the drop down to choose the user name on login, and panning around
> the mini-map.  What else from recent builds may have been
> lost/skipped/thrown away?
>

Well, we "lost" more than that (SOCKS5 support, translator and OGP-Login are
*big* on my todo list), but they are not lost really: I haven't had time to
merge *everything*, especially the trickiest / UI related features.

The plan though is to get those in there too! Just hang in there...

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

[opensource-dev] So what happens if....

[Imaze Rhiano]

First I want to thank LL from efforts to create ethical guidelines for 
respectable viewers. Unfortunately I don't think that these rules are 
going to work in reality where we are living.(And as others have already 
pointed out - there might be incompatible with GPL and other licenses.)

Let's imagine one moment that instead of being ebil bitch I would be 
respectable software developer and create my own viewer that fully 
confirms policy. I would register my viewer to your viewer directory. 
Now - one of following scenarios would happen - what I should do - and 
what would be LL's reaction:

1) My viewer is open sourced. Some evil person(s) take source code and 
add functionality that breaks policy. They don't bother to change 
viewer's id or other identification data.

2) My viewer have plugin framework that allows 3rd party developers to 
create their own plugins. One evil person then writes plugin that is 
breaking rules of viewer policy.

3) Evil persons will develop proxy or software hook that will steal data 
directly from data stream between client and LL servers - or - 
communications between viewer's host module and DLLs. Proxy / hook is 
completely transparent - neither client or server can detect it.

4) I will develop closed source viewer and evil persons will develop 
their own evil viewer. Then they decide to fake my viewer's 
identification data so that server thinks that their evil viewer is my 
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] So what happens if....

[Rob Nelson]

>From my reading, you get banned in all four cases, since you
automatically take responsibility for the users' activities (Section 7
3PVP).

On Wed, 2010-02-24 at 07:08 +0200, Imaze Rhiano wrote:
> First I want to thank LL from efforts to create ethical guidelines for 
> respectable viewers. Unfortunately I don't think that these rules are 
> going to work in reality where we are living.(And as others have already 
> pointed out - there might be incompatible with GPL and other licenses.)
> 
> Let's imagine one moment that instead of being ebil bitch I would be 
> respectable software developer and create my own viewer that fully 
> confirms policy. I would register my viewer to your viewer directory. 
> Now - one of following scenarios would happen - what I should do - and 
> what would be LL's reaction:
> 
> 1) My viewer is open sourced. Some evil person(s) take source code and 
> add functionality that breaks policy. They don't bother to change 
> viewer's id or other identification data.
> 
> 2) My viewer have plugin framework that allows 3rd party developers to 
> create their own plugins. One evil person then writes plugin that is 
> breaking rules of viewer policy.
> 
> 3) Evil persons will develop proxy or software hook that will steal data 
> directly from data stream between client and LL servers - or - 
> communications between viewer's host module and DLLs. Proxy / hook is 
> completely transparent - neither client or server can detect it.
> 
> 4) I will develop closed source viewer and evil persons will develop 
> their own evil viewer. Then they decide to fake my viewer's 
> identification data so that server thinks that their evil viewer is my 
> 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


___
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] Snowglobe 2 update

[Philippe (Merov) Bossut]

Hi,

So, Snowglobe 2 is out there and ready to build/hack. Well, almost. What we
have today is basically the Viewer 2.0 beta source code + all the Snowglobe
branding on top of it but lots of Snowglobe specific features are still
missing. Before I go into the details of what's left to be done (and where
you can help), some pointers to orient yourself:

- svn : the code is available off :
   https://svn.secondlife.com/svn/linden/projects/2010/snowglobe/trunk
I choose svn over hg uniquely for practical reasons: we needed to go through
an export script anyway so rewriting the export for hg while keeping the
rest unchanged was a time saver. It'll also make merge from Snowglobe 1.3
based trunk easier (svn to svn merge).

- bundles: they are posted on :
http://wiki.secondlife.com/wiki/Source_downloads
The usual stuff, no change from the old 1.3 code base (artwork, libs and
source tarballs if you don't like svn)

At that point, building should be no different from before. If you use
develop.py, it should be a piece of cake. For the sake of completeness
though, I'm doing right now a build "from scratch" on Mac so I'll catch
anything that I may have missed in the svn commit this afternoon. Since I
had to work around some unexpected svn crashes, I did some commit manually
and may have missed something. Let me know if you see something going awry
on Windows or Linux.

For those of you compiling standalone and/or on Linux 64: I have *not* done
*any* build using those configurations. I did merge some of the build
changes when doing the branding merge but, without building myself, I'm sure
I missed some important things. For those issues, please discuss here or,
better, log a PJIRA and discuss there or attach a patch (please set "Affect
version" to "Snowglobe 2.0"). You'll see that, though lots of files are new,
most of the structure of the code base hasn't changed that much.

- What needs to be done
Now we have the code out, what's next? 2 categories of things:
- Scripts and build: I still have unfinished or hacky scripts on the
internal side of things that I need to polish and push to the main trunk so
that updates are easier. In particular, I need to make sure the automated
build on the public branch works again.
- Snowglobe features merge: I haven't merged all the things we've been doing
in 2009. Lots of those biggest things we did in Snowglobe though are now in
Viewer 2.0 so won't need to be merged. Some of the big features though are:
  - OGP-Login: Pixelq already volunteered to help merge that back
  - SOCKS5: here, Robin volunteered
  - Chat translator: for that one, that would be nice if someone would
volunteer to do the merge
  - Login drop down: same
I think I can take care of the other small fixes especially since I have
access to the internal JIRA that details which ones have been merged in the
Viewer 2.0. It's a little tedious work but not fundamentally hard. I think
it'll take me a couple of weeks to get all that in (that plus finishing the
script)

- How you can help
As usual: testing, building and submitting patches :) PJIRA is open. Please
set "Affect version" to "Snowglobe 2.0" for bugs found on that code base.

Snowglobe 2.0 and Viewer 2.0 are still very much young and starting and need
our collective care. I'm very happy personally to have Snowglobe now
tracking the main viewer (and getting out of the business of doing cherry
pick merges of huge feature sets...) so that our effort here can get to the
main viewer faster while we still maintain the freedom to experiment.

I'm really looking forward for more innovative Snowglobe developments now
we're back tracking the main code base.

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

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

is the policy just a set of requisites for a client to be included in
the list LL will have on their site or to be allowed to connect to Agni
at all?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuEvRgACgkQ8ZFfSrFHsmU1iwCfdWe7xzvnegSrZm1ApcPiR13C
2CIAn2ho4G5QXImDU5R8aiYqp5g7U9vE
=7GmR
-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

[Marine Kelley]

You gotta be kiddin me !! I call that a stab in the back. You guys  
disgust me.


Your Third-Party Viewer name must not be confusingly similar to or use  
any part of a Linden Lab trademark, including “Second,” “Life,”  
“SL,” or “Linden.” For example:
You must not have a Third-Party Viewer name that is “ Life”  
where “” is a term or series of terms___
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

[Gareth Nelson]

I have a strong urge to produce a viewer which violates this policy,
relying solely on the rights granted by the existing GPL. I will never
use this viewer myself to login to SL, and thus reject any of these
terms. Any developers who object to this policy should follow suit.

A few questions:
If I distribute a viewer which violates this policy but refuses to
login to any LL-owned grids, and one of my users modifies it to do so,
would you attempt to hold me liable?
If I was to close all my SL accounts today (probably won't actually,
but it's a thought experiment) and distribute a viewer that breaks
this policy, would you attempt to hold me liable? I say "attempt",
because I see no way LL could do so without the TOS binding me (the
only possible way this policy could be enforced - and even then some
lawyer type may be able to make a case against it).

Should be fine though, the policy states at the top that it
essentially only matters for people using the viewer to connect.

My question is if I develop a policy-breaking viewer for use on other
grids and simply neglect to add an if(grid=='agni')
refuse_connection() statement, will you be holding my users liable or
me? Assuming I never use it myself to connect to an LL-owned grid

On Wed, Feb 24, 2010 at 5:46 AM, Tigro Spottystripes
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> is the policy just a set of requisites for a client to be included in
> the list LL will have on their site or to be allowed to connect to Agni
> at all?
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuEvRgACgkQ8ZFfSrFHsmU1iwCfdWe7xzvnegSrZm1ApcPiR13C
> 2CIAn2ho4G5QXImDU5R8aiYqp5g7U9vE
> =7GmR
> -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
>



-- 
“Lanie, I’m going to print more printers. Lots more printers. One for
everyone. That’s worth going to jail for. That’s worth anything.” -
Printcrime by Cory Doctrow

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
___
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