Re: [opensource-dev] Third party viewer policy

[Lance Corrimal]

Am Donnerstag 25 Februar 2010 schrieb Soft Linden:
> On Wed, Feb 24, 2010 at 2:47 PM, Marine Kelley 
 wrote:
> > But what I am concerned about is the viewer directory. I see that
> > I need to provide my RL info to list my viewer there, and that
> > this RL info would then be visible to all for liability.
> 
> More conversation with legal. Expect an update in coming days, but
> tentatively: it looks like providing the info to LL will be
> sufficient. Names won't be published in the public Viewer
>  Directory. ___


That would mean it should be possible to register for the viewer 
directory without even having to fill in the form with real life data 
AT ALL IF YOU ARE ID VERIFIED (Aristotle or copy-of-passport-by-
support-ticket).


bye,
LC
___
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

[Jonathan Bishop]

snip

Boy wrote:-

LL's new policy says under 7. 

"If you are a user or Developer of Third-Party Viewers:

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

In it's current form that reads: a developer is fully legally responsible
for the code, and in addition to that also carries full responsibility for
any user action of anyone using that viewer. In my opinion that's a killer
clause nobody halfway intelligent can accept.

End Snip

 

That's not how I interpreted the line, although I agree it is ambiguous.  My
reading was that you are responsible for:

a) what you write as a developer with which you then log on to the grid (so
the "Oops I didn't mean to delete the grid with my pre-alpha release "Fluffy
Lief Deathstar Viewer", it was just an experimental feature to see what
would happen if I spoofed admin rights and pressed delete - it wasn't a
production ready feature." excuse wont work.).  This seems just a
restatement of the TOS for accessing the SL grid (i.e. It's a violation of
the TOS to wreck the grid); and 

b) what you then publish to the world either by passive distribution (such
as a public source archive) or direct distribution (eg emailing it to
friends).  This means make sure you put the approved Gamma release of the
"Fluffy Lief Deathstar Viewer" not the auto-grid-deleting alpha version out
for public consumption (so the "Oops I just renamed and copied the KoobFace
trojan to the distribution list as the 'Fluffy Lief Deathstar Viewer' by
accident."  Doesn't work, because you are responsible for getting the
publication of your viewer right as well.  It might be arguable that the
obligation extends to ensuring that the public distribution is not
subsequently replaced with non-official hacked version, but this might be
satisfied by electronic code and zip file signing (which I gently suggest
you should probably be doing anyway).

 

I don't see that it says you are then responsible for what the users then do
with your browser or code.  That is between them and LL and covered by the
TOS.  (Even if it did say that, it would probably be an unenforceable
requirement in most if not all jurisdictions and would, in a badly written
license or other contract, cause the entire agreement to fail, and in a
correctly written document, just result in the clause being struck).   To
cover the end user use of the viewer the policy would, to my reading,
require something more - eg "are also responsible for all Third-Party
Viewers that you develop or distribute, broadcast (or otherwise cause or
allow to be transmitted in electronic or physical form), duplicates made
there-from and all works derived therefrom regardless of whether said
duplicated, broadcastn (etc.), or derived works were authorised, enabled or
performed by you".   Which, of course would be your classic unenforceable
obligation.but it didn't say that, I don't think.

 

Read this way the requirement is reasonable - it means "be careful what you
code and don't screw us up through deliberate or accidental breach of this
agreement, and then be careful that what you supply to others as the viewer
you registered with us is actually the viewer you registered with us".   It
might also mean: "LL hold you responsible for protecting the integrity of
the public master copy of the registered viewer (not each duplicate made
therefrom), because we aren't doing the distribution ourselves, but linking
to your distribution site."   Which also seems fair enough to me.

 

Trying to hold the original author responsible for a third party's
derivative version of a work after the third party has defaced it, is
patently silly and (at least inn the general case) unenforceable and I doubt
very strongly where LL's lawyers would intend such an "courageous" clause. 

 

The wording probably needs a little rework so that the apparent ambiguity is
removed, particularly since there is still an ongoing argument in IP
legislation circles about the relationship between duplication, distribution
and broadcasting, so the full meanings of some of these terms are yet to be
completely distilled.  

 

Another key issue revolves around the meaning of the term "responsible".  I
read that as "you agree to not code into your viewer any of the stuff we
said you shouldn't, and that you agree to ensure that the version(s) of the
browser we agree to put on our register is/are the ones you actually
distribute."  Other responsibilities such as not breaking the grid, are
governed by the TOS - as a viewer that is not connected to the grid is
effectively outside the reach of the said policy.  

 

 

 

 

Regards

 

Jonathan Bishop 
Managing Director

 


 

Bishop Phillips Consulting | Melbourne, Australia - Vancouver, Canada
Mobile +61 411.404.483 | Office +61 (3) 9525.7066 | Fax +61 (3) 9525.6080
bish...@bishopphillips.com | w

Re: [opensource-dev] Third party viewer policy

[Morgaine]

That's good to hear, Soft, thanks.

Please also make Legal aware of the impact of GPLv2's "NO WARRANTY" section
to avoid yet another cause of GPL non-compliance through imposing conditions
and liabilities on developers.  I've listed it
herefollowing
on from Boy Lane's good points about liability.

Apparently a large amount of the confusion you mentioned is due to the TPV
being addressed to developers and users *simultaneously*, as one Linden
suggested today.  Clearly this mixing doesn't work, and is the reason for
multiple areas of GPL non-compliance in the TPV.

I hope that a very clear distinction between developers and users is
forthcoming in the next revision and FAQ, so that the GPL can continue to be
used.


Morgaine.



===

On Thu, Feb 25, 2010 at 12:12 AM, Soft Linden  wrote:

> On Wed, Feb 24, 2010 at 4:30 PM, Morgaine
>  wrote:
> > Soft,
> >
> > Please add to your list of issues to pass to Legal, a highlighted copy of
> > Clause 6 in the GPLv2 license, as well as a highlighted copy of the
> section
> > of the GPLv2 FAQ which addresses the relevant clause of the license with
> a
> > clear example of GPL non-compliance.  [Search for "impose any further
> > restrictions" to find it].
> >
> > TPV section 1c is dramatically incompatible with GPLv2 clause 6 because
> it
> > conflicts with this part of clause 6 (an extremely important term in all
> GPL
> > licenses), in the specific case where the "recipient" of the code is the
> > developer:
> >
> > "You may not impose any further restrictions on the recipients' exercise
> of
> > the rights granted herein."
>
> Legal doesn't intend this to be a restriction on anything but use of
> our service or eligibility for inclusion in the Viewer Directory.
> Context is important here. Even the maintainers of GNU telnet won't
> let someone use telnet to mess up the FSF's servers.
>
> Legal is aware that there has been confusion on this. There will be an
> update soon, which makes the terms more clear.
>
___
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]

Carlo Wood wrote:
> On Tue, Feb 23, 2010 at 12:45:01PM -0800, Brent Tubbs wrote:
>   
>> 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.
>> 
>
> I didn't even READ the TVP all that well, I'm just going to
> stubbornly use my own common sense. If anything that is not
> common sense is going to be enforced then by all means I don't
> want to be part of SL anymore.
>
> In this case the common sense says: If something is full perm,
> you may export it. Second Inventory does this, and I doubt
> that is suddenly made illegal.
>
>   
Actually that is NOT common sense. When the author of some intellectual 
bit of property agrees to distribution, its generally for existing 
channels of distribution only. The SL TOS only applies to intellectual 
property distributed by Linden Lab in the manner that the content 
creator agreed to. Someone ELSE coming along and saying "oh, full perms 
means I own the IP rights to this and can take it anywhere I please and 
do anything I want in any way I want without consideration for the 
original creator" goes against even the CC license, and the LL full 
perms isn't the CC license or any kind of abbreviation of it.




> Scripts that a team work on are definitely full-perm (from the
> point of view of SL permissions), so you can export it all
> you like.
>
>   
Who says? If they don't say so, then legally, full perms stuff is only 
full perms for SL use. If the content creator(s) give you permission to 
move stuff around, that's different, but YOU don't have the right to 
assume such things without explicit permission concerning this specific 
point. Your right to "own" stuff only exists within the SL framework. 
Outside the framework, the IP rights of the content creator 
automatically revert to them.

Or such is how I have had it explained quite a few times over the years.


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

[Morgaine]

Good points, Boy Lane, concerning developer liability not being acceptable.

But it goes even further than that.  Developer liability is *not GPLv2
compliant*.

Here are GPLv2 's "*NO
WARRANTY*" clauses:


QUOTE

*NO WARRANTY*

*11.* BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO
THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM
PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
CORRECTION.

*12.* IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO
LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR
THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END QUOTE


All liability and responsibility for the use of a GPL program rests with the
users of the program, not with the developer of the program.  This is an
explicit condition of all GPL licenses, and these licenses cannot be
employed by LL if section 7 of the TPV document is valid.

It is worth noting that the BSD license also has a similar NO WARRANTY
clause to protect its developers.


Morgaine.




==

On Thu, Feb 25, 2010 at 4:18 AM, Boy Lane  wrote:

>  I would like to reiterate on one point that was mentioned shortly
> already, the liability of a developer.
>
> LL's new policy says under 7.
>
> "If you are a user or Developer of Third-Party Viewers:
>
> a. You are responsible for all uses you make of Third-Party Viewers, and if
> you are a Developer, you are also responsible for all Third-Party Viewers
> that you develop or distribute."
>
> In it's current form that reads: a developer is fully legally responsible
> for the code, and in addition to that also carries full responsibility for
> any user action of anyone using that viewer. In my opinion that's a killer
> clause nobody halfway intelligent can accept.
>
> In detail, this clause has two major implications.
>
> Firstly by accepting 3PVP a developer would have to take full
> responsibility for the viewer and the code it is based on. We all know that
> these sources were developed by hundreds of different people and contain
> hundreds if not thousands of known and unknown bugs (not sure about actual
> Jira statistics). LL itself declines any responsibility in the sourcecode by
> sating "ALL LINDEN LAB SOURCE CODE IS PROVIDED "AS IS." LINDEN LAB MAKES NO
> WARRANTIES, EXPRESS, IMPLIED OR OTHERWISE, REGARDING ITS ACCURACY,
> COMPLETENESS OR PERFORMANCE." Now LL forces a 3rd party viewer developer to
> take on exactly that responsibility LL explicitly disclaims. I as a
> developer can not accept this as I'm simply unable to guarantee that the
> underlying code is 100% failure free or that there are no exploits possible
> to abuse that code. Nobody can guarantee this and therefore should limit
> ones liability to either the value of the software itself, here free
> open-sourced code with a value of zero; or completely disclaims any
> responsibility as it is the current status of the viewer code.
>
> Secondly and worse than the first point, by accepting the policy I'd also
> automatically take on full responsibility for anything a user does with the
> viewer. Be it using build in features (abuse, harassment, griefing, you name
> it), or furthermore use exploits in the code for not only malicious
> activities. No developer ever could control or prevent any user action and
> should never be held responsible for any action a user does with the
> software provided.
>
> I fully agree that a certain level of accountability is necessary. LL has
> already all means to implement such accountability by having RL details of
> each developer that is connected to an avatar. That's what the ToS warrant.
> As such LL is already enabled to identify and prevent access of malicious
> viewers and creators behind. The current liability clause therefore goes way
> to far, is unfeasible, and renders the complete policy unacceptable.
>
> In addition to that I can only second the concerns of Marine, Henri and
> others that RL details of viewer developers should never be made public in
> any form. LL per ToS has all RL details required. Publishing them would

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

[Morgaine]

Only in your ambiguous definition, which I've already debunked.


Morgaine.





On Thu, Feb 25, 2010 at 12:00 AM, Carlo Wood  wrote:

> On Tue, Feb 23, 2010 at 03:10:55PM +, Morgaine wrote:
> > 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.
>
> No, A (client-extension) is all plugins, and B (client-side scripting)
> is all untrusted client-side scripting.
>
> --
> 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

Re: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

hm, but then in Agni,  isn't LL the one that is really distributing data
to people that are not LL, which is among the rights IP owners give LL
when they first upload their IP into their servers with the client?
Basicly, people are just "hotlinking" to stuff that LL has been given
the right to offer to anyone they want, no?

On 25/2/2010 01:28, Jason Giglio wrote:
> Tigro Spottystripes wrote:
>> if it's just about copying and modification, but not use, then how come
>> we can't use, say a texture, without explicit permission from the
>> creator under the risk of being prosecuted for copyright infringement?
> 
> With textures and prims in SL, "use" is inherently also distribution.
> When a viewer comes within range, textures and prims are distributed
> automatically to that viewer.
> 
> In US law Title 17 chapter 1 section 106 gives 6 enumerated exclusive
> rights. In short, they are reproduction, modification, distribution,
> public performance, public display, and digital audio transmission.
> 
> In the digital realm these generally boil down to "copying/distribution
> and modification".
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuF/qoACgkQ8ZFfSrFHsmUVWgCfTJPLP747NR/yPYF5HdC6WVcA
0/EAn0aPnIgQ47JJKYSdRrYIrYwBXR4U
=L4R8
-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] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses

[Jason Giglio]

Tigro Spottystripes wrote:
> if it's just about copying and modification, but not use, then how come
> we can't use, say a texture, without explicit permission from the
> creator under the risk of being prosecuted for copyright infringement?

With textures and prims in SL, "use" is inherently also distribution.
When a viewer comes within range, textures and prims are distributed
automatically to that viewer.

In US law Title 17 chapter 1 section 106 gives 6 enumerated exclusive
rights. In short, they are reproduction, modification, distribution,
public performance, public display, and digital audio transmission.

In the digital realm these generally boil down to "copying/distribution
and modification".

___
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

[Boy Lane]

I would like to reiterate on one point that was mentioned shortly already, the 
liability of a developer.

LL's new policy says under 7. 

"If you are a user or Developer of Third-Party Viewers:

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

In it's current form that reads: a developer is fully legally responsible for 
the code, and in addition to that also carries full responsibility for any user 
action of anyone using that viewer. In my opinion that's a killer clause nobody 
halfway intelligent can accept.

In detail, this clause has two major implications.

Firstly by accepting 3PVP a developer would have to take full responsibility 
for the viewer and the code it is based on. We all know that these sources were 
developed by hundreds of different people and contain hundreds if not thousands 
of known and unknown bugs (not sure about actual Jira statistics). LL itself 
declines any responsibility in the sourcecode by sating "ALL LINDEN LAB SOURCE 
CODE IS PROVIDED "AS IS." LINDEN LAB MAKES NO WARRANTIES, EXPRESS, IMPLIED OR 
OTHERWISE, REGARDING ITS ACCURACY, COMPLETENESS OR PERFORMANCE." Now LL forces 
a 3rd party viewer developer to take on exactly that responsibility LL 
explicitly disclaims. I as a developer can not accept this as I'm simply unable 
to guarantee that the underlying code is 100% failure free or that there are no 
exploits possible to abuse that code. Nobody can guarantee this and therefore 
should limit ones liability to either the value of the software itself, here 
free open-sourced code with a value of zero; or completely disclaims any 
responsibility as it is the current status of the viewer code.

Secondly and worse than the first point, by accepting the policy I'd also 
automatically take on full responsibility for anything a user does with the 
viewer. Be it using build in features (abuse, harassment, griefing, you name 
it), or furthermore use exploits in the code for not only malicious activities. 
No developer ever could control or prevent any user action and should never be 
held responsible for any action a user does with the software provided.

I fully agree that a certain level of accountability is necessary. LL has 
already all means to implement such accountability by having RL details of each 
developer that is connected to an avatar. That's what the ToS warrant. As such 
LL is already enabled to identify and prevent access of malicious viewers and 
creators behind. The current liability clause therefore goes way to far, is 
unfeasible, and renders the complete policy unacceptable.

In addition to that I can only second the concerns of Marine, Henri and others 
that RL details of viewer developers should never be made public in any form. 
LL per ToS has all RL details required. Publishing them would only do one 
thing, open a can of worms for RL consequences, abuse, grief and enable 
self-proclaimed better-citizens to take law and right in their own hands as 
recent examples just showed.

Please revise the developer liability accordingly and add a clause that RL 
details of viewer developers must never be made available to anyone else but LL 
and legal authorities if required. Anything else is simply unacceptable.

Boy
___
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] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

if it's just about copying and modification, but not use, then how come
we can't use, say a texture, without explicit permission from the
creator under the risk of being prosecuted for copyright infringement?

On 25/2/2010 00:27, Jason Giglio wrote:
> Darmath wrote:
>> lots of stuff
> 
> Well, here's some papers about it:
> 
> http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1029366
> https://litigation-essentials.lexisnexis.com/webcd/app?action=DocumentDisplay&crawlid=1&doctype=cite&docid=30+U.+La+Verne+L.+Rev.+296&srctype=smi&srcid=3B15&key=bb13d4040c3db45188ff18b96fe84132
> 
> The nutshell: Licensing is a unilateral act, unlike contracts.  You are
> bound by a license only if you want to carry out the act that would be
> otherwise forbidden (in this case by copyright law).  For this reason,
> CC-SA and GPL can't dictate or control usage of a program that doesn't
> involve copying or modification, since usage is outside of copyright
> law.  There needs to be no meeting of the minds nor exchange of
> consideration.  Remedies are also different as I mentioned.
> 
> We should probably take this off list for further discussion.
> ___
> 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/

iEYEARECAAYFAkuF9wQACgkQ8ZFfSrFHsmWRywCeNMK0WA9OtYk1G2NkRfnsfAKc
1AcAnjhimNNcYiaUJNYsx+rjI3RYbThW
=6p3x
-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

[Vector Hastings]

Thank you Soft for working through this large thread so calmly. 

This seems like one of the more crucial areas of concern, and your response
is reassuring. 

Cheers,

Vector

-Original Message-
From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Soft
Linden
Sent: Wednesday, February 24, 2010 4:12 PM
To: Morgaine
Cc: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] Third party viewer policy

On Wed, Feb 24, 2010 at 4:30 PM, Morgaine
 wrote:
> Soft,
>
> Please add to your list of issues to pass to Legal, a highlighted copy of
> Clause 6 in the GPLv2 license, as well as a highlighted copy of the
section
> of the GPLv2 FAQ which addresses the relevant clause of the license with a
> clear example of GPL non-compliance.  [Search for "impose any further
> restrictions" to find it].
>
> TPV section 1c is dramatically incompatible with GPLv2 clause 6 because it
> conflicts with this part of clause 6 (an extremely important term in all
GPL
> licenses), in the specific case where the "recipient" of the code is the
> developer:
>
> "You may not impose any further restrictions on the recipients' exercise
of
> the rights granted herein."

Legal doesn't intend this to be a restriction on anything but use of
our service or eligibility for inclusion in the Viewer Directory.
Context is important here. Even the maintainers of GNU telnet won't
let someone use telnet to mess up the FSF's servers.

Legal is aware that there has been confusion on this. There will be an
update soon, which makes the terms more clear.
___
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] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses

[Jason Giglio]

Darmath wrote:
>lots of stuff

Well, here's some papers about it:

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1029366
https://litigation-essentials.lexisnexis.com/webcd/app?action=DocumentDisplay&crawlid=1&doctype=cite&docid=30+U.+La+Verne+L.+Rev.+296&srctype=smi&srcid=3B15&key=bb13d4040c3db45188ff18b96fe84132

The nutshell: Licensing is a unilateral act, unlike contracts.  You are
bound by a license only if you want to carry out the act that would be
otherwise forbidden (in this case by copyright law).  For this reason,
CC-SA and GPL can't dictate or control usage of a program that doesn't
involve copying or modification, since usage is outside of copyright
law.  There needs to be no meeting of the minds nor exchange of
consideration.  Remedies are also different as I mentioned.

We should probably take this off list for further discussion.
___
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] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses

[Darmath]

Brent Tubbs wrote:
>
>
> On Wed, Feb 24, 2010 at 5:53 PM, Jason Giglio  > wrote:
>
> Darmath wrote:
> > Having read the TOS i'm comfortable in saying that it is reasonably
> > clear that two exchanges don't take place, but that the agency
> > situation, with LL existing as a mutual agent, would apply to SL.
> >> Darmath wrote:
>
> The CC-SA-By is not a contract, it's a copyright license.
>  Contract law
> concepts are mostly irrelevant.
>
> If you fail to comply with the license, then your right to distribute
> the work terminates, and you are committing copyright infringement if
> you continue to distribute.  You aren't in breach of contract.
>
> Your remedies would be limited to those under copyright law, not
> contract law.  This is a common confusion, mostly because
> companies like
> Microsoft have conflated copyright licenses with copyright law with
> their contract-like EULAs.
>
>  
> You sound a lot more sure of this than I think is warranted.  There's 
> nothing stopping licenses from being contracts and vice versa.  If 
> there's an offer, an acceptance, and an exchange of value (even just 
> promises to do or not do something), then there's a contract, even if 
> the word "contract" never appears in the text.
>  
>
>
> ___
> 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
> 
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.733 / Virus Database: 271.1.1/2707 - Release Date: 02/24/10 
> 18:34:00
>
>   
I'll start by saying i'm actually a law student. And whilst by no means 
does that make me a legal expert yet, and intellectual property law is 
not something that i have examined in depth (but will do according to 
the laws of Australia where I reside over the course of the coming 
months) I must say that as a law student the logic behind the statement 
that a copyright licence is not a contract completely confounds. It 
confounds me to the point that in the absence of court authority to the 
contrary it will be outrightly rejected.

As I understand law surrounding copyright the transfers of rights in 
relation to a copyright is very much like the position with respect to 
leases and licenses with respect to real property (land). When I enter 
into a license in respect of land I enter into a contract that confers 
upon the licensee a right to enter my land. But that right is very much 
a contractual right. The contract confers in personam rights to the 
licensee that if I infringe I may be sued for in contract. Therefore if 
i wrongful interfere with your right to be on my land then i may be 
liable in contractual damages for the infringement of the. When the 
licensee however steps outside of the terms of our license then I 
terminate his contract with me under which he acquired rights to be on 
my land and then I enforce my property law rights against him to eject 
him from my land. Note that although neither of the parties may have 
referred to the license as a contract it is very much a contract.

In the case of a lease with respect to real property than the lessor and 
the lesses enter into a contract which transfers a proprietary interest 
to the lesssee. As between lessor and lessee their is both a contractual 
relationship. That contractual relationship operated to transfer property.

Now you may be wondering why i'm discussing land law when the original 
topic was intellectual property, named copyright, then again you may not.

But in my opinion the real position, which i think you may have failed 
to understand is this. A copyright license in my opinion must in its 
nature be contractual. Like in the case of a license with respect to 
land I confer rights in respect of a property in this case the 
copyright. That is when I as a content creator enter into a copyright 
license i grant people the legal right, pursuant to a contract, to deal 
with my property. However, where the licensee steps outside the bounds 
of that agreement, I am entitled, just as i did in the case of the above 
position with regards to lands to terminate that agreement bringing an 
end to the licensees rights to act in relation to the property and then 
enforce my property rights against them that are created and regulated 
by statute. Perhaps the best way to appreciate why a copyright license 
would

Re: [opensource-dev] Third party viewer policy

[Dzonatas Sol]

Jason Giglio wrote:
>> Legal is aware that there has been confusion on this. There will be an
>> update soon, which makes the terms more clear.
>> 
>
> Is it an actual update to the policy document?
>
> Not a mere FAQ that says "Oh we didn't really mean what the policy says
> in plain English"?
>   

Don't you love how layers say "oh but we mean these terms only in this 
sense" but in court they say "to the fullest extent of the law."

Earth World Version 2012...

Day awaits for court where we measure patents and who really means what. 
I, and others, don't need lawyers to say "oh but we mean this..."

This isn't a threat, it's just stupid common sense.
___
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] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses

[Brent Tubbs]

On Wed, Feb 24, 2010 at 5:53 PM, Jason Giglio  wrote:

> Darmath wrote:
> > Having read the TOS i'm comfortable in saying that it is reasonably
> > clear that two exchanges don't take place, but that the agency
> > situation, with LL existing as a mutual agent, would apply to SL.
> >> Darmath wrote:
>
> The CC-SA-By is not a contract, it's a copyright license.  Contract law
> concepts are mostly irrelevant.
>
> If you fail to comply with the license, then your right to distribute
> the work terminates, and you are committing copyright infringement if
> you continue to distribute.  You aren't in breach of contract.
>
> Your remedies would be limited to those under copyright law, not
> contract law.  This is a common confusion, mostly because companies like
> Microsoft have conflated copyright licenses with copyright law with
> their contract-like EULAs.
>

You sound a lot more sure of this than I think is warranted.  There's
nothing stopping licenses from being contracts and vice versa.  If there's
an offer, an acceptance, and an exchange of value (even just promises to do
or not do something), then there's a contract, even if the word "contract"
never appears in the text.


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

[Latif Khalifa]

On Thu, Feb 25, 2010 at 1:12 AM, Soft Linden  wrote:
> Legal doesn't intend this to be a restriction on anything but use of
> our service or eligibility for inclusion in the Viewer Directory.
> Context is important here. Even the maintainers of GNU telnet won't
> let someone use telnet to mess up the FSF's servers.

Soft, nobody is disputing the parts of the policy that are designed to
prevent malicious software that causes harm to the servers it connects
to, or to user data or privacy.

But I fail to see how that relates to the topics that have been raised
in this thread. How does calling an API and a client "Restrained Life
Viewer" become a violation? Is anyone honestly going to confuse
"Second Life" with "Restrained Life Viewer" or to claim that it can be
seen as trademark infringement? RLV has created a whole industry which
I'd argue has helped Linden Lab's business. It has also transcended
it's original purpose, as it is being widely used by people with
disabilities. I have been working closely with the blind users of
Second Life, and have seen some really amazing in world scripted
devices that help the blind users overcome poor accessibility of the
official client.

It's Linden Lab's treatment of open source developers like that which
is causing concern, not it's efforts at preventing harmful software
from disrupting the grid.
___
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

[Darmath]

Marine Kelley wrote:
> Besides I don't see why on Earth any RL info should be disclosed to 
> everyone in the open, it is nobody's business except LL's who is 
> making and publishing third party viewers to connect to their grid. To 
> me the average developer of a third party viewer should be allowed to 
> remain anonymous, since the real griefers are never going to publish 
> their data anyway. And since a viewer developer cannot be held 
> responsible for the use of their viewer (despite what the policy 
> implies), this is a moot point.
I disagree. It's actually the business of the user of the client who the 
relevant developer is. However that said I agree a developer should be 
able to remain anonymous should they choose. The reality is it's in the 
users hands whether he, she or it, will use a client from an unknown 
source or not. If they choose that they don't want to run a program on 
their computer from an unknown source then that is a choice for them to 
make.

Additionally I  seem to be reading a lot seeking to suggest that 
developers in open source projects cannot be held liable with respect to 
the damage that the software developed may do to a user of that 
software. Whilst you can't judge each and every case in a vacuum I 
believe that notion is somewhat misguided. In my opinion the only thing 
that protects such persons from actually being sued is their ability to 
remain anonymous. After all it is kind of hard to sue people that are 
hiding in the shadows ;-). That doesn't mean that unknown individuals 
aren't actually liable. Liability and the practical ability to sue 
people are two different things.

Kind regards

Darren
___
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] Summary of TPV concerns

[Jason Giglio]

I have created a page with all the concerns I could think of listed so
that nothing falls in the cracks.

https://wiki.secondlife.com/w/index.php?title=TPV_concerns

Feel free to edit.
___
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] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses

[Jason Giglio]

Darmath wrote:
> Having read the TOS i'm comfortable in saying that it is reasonably 
> clear that two exchanges don't take place, but that the agency 
> situation, with LL existing as a mutual agent, would apply to SL.
>> Darmath wrote:

The CC-SA-By is not a contract, it's a copyright license.  Contract law
concepts are mostly irrelevant.

If you fail to comply with the license, then your right to distribute
the work terminates, and you are committing copyright infringement if
you continue to distribute.  You aren't in breach of contract.

Your remedies would be limited to those under copyright law, not
contract law.  This is a common confusion, mostly because companies like
Microsoft have conflated copyright licenses with copyright law with
their contract-like EULAs.

___
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] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses

[Darmath]

Having read the TOS i'm comfortable in saying that it is reasonably 
clear that two exchanges don't take place, but that the agency 
situation, with LL existing as a mutual agent, would apply to SL.
> Darmath wrote:
>   
>> Gigs wrote:
>> 
>>> Darmath wrote:
>>>   
 If I understand your comments in this regard correctly you appear to 
 be trying to suggest that because a recipient of a work covered by 
 the  CC-SA or other like license has agreed with Linden Labs that 
 they will not export a work that doesn't bare their name as a 
 creator the person who initially uploaded the content and 
 distributed it to the received is now in violation of the CC-SA.

 If the above is what you're trying to suggest then I must disagree 
 with you. But I will wait to see that the above is what you're 
 actually trying to assert before i respond as to why...

 
>>> Person A creates content and releases it under CC-SA-By
>>> Person B uploads this content to Second Life
>>> Person B distributes the content to Person C
>>>
>>> Person C now has additional terms imposed on them that restrict their 
>>> exercise of the rights granted under CC-SA-By because of the TPV 
>>> agreement.  Previously they could run any client with export 
>>> capability to download the work in order to modify it.  Now they 
>>> can't do that. Their rights to redistribute and modify under the 
>>> CC-SA have been restricted which is a violation of the CC-SA license.
>>>   
>> When I first came across this topic it was 3am and I was on my way to 
>> bed so you'll forgive me for not thinking my way entirely through the 
>> CC-SA. Having considered the issue this morning somewhat fresh I would 
>> agree that Person B may be in violation with that agreement but not 
>> for the reason Gigs (Jason) had initially stated. Initially the 
>> conclusion appeared to be based upon the following from the CC-SA:.
>>
>> "You may not offer or impose any terms on the Work that restrict the 
>> terms of this License or the ability of the recipient of the Work to 
>> exercise the rights granted to that recipient under the terms of the 
>> License."
>>
>> Putting aside for the moment that I believe that the paragraph is 
>> horribly drafted as a legal document and doesn't accord with its 
>> intent in its wording as far as I'm concerned I don't believe you can 
>> say that as between Person B and Person C, Person B offered or imposed 
>> any terms on the new recipient licensee that curtails Person's C's 
>> rights under the licence.  The simple fact is that Person B didn't 
>> impose any terms on Person C or offer the Work to C on any terms that 
>> were more restrictive than what the license does.
>>
>> The fact is that Person C would fall subject to obligations to a 
>> fourth Person, Linden Labs (Person D)  a result of C's own agreement 
>> with D  that they won't export that content from SL unless their named 
>> as the creator. The fact that C's own agreement with a fourth party 
>> means that they now have obligations upon them that interfere with 
>> their rights under the license they entered into and acqured from B, 
>> doesn't mean that Person B imposed more restrictive terms upon C. The 
>> terms that restricted C were effectively imposed by Person D.
>>
>> I also think there is potentially a much more interesting analysis 
>> that is capable of following in the circumstances of SL, with regard 
>> to the exchange of the Work from B to C, and that is whether the 
>> exchange can actually be regarded as one exchange between Person B and 
>> C, mediated by a mutual agent in LL (Person D). Or alternatiely 
>> whether two exchanges take place both of which falling subjectable to 
>> the CC-SA or possibly other like agreements. In the latter scenario  
>> the first exchange would take place between Person B and Person D (LL) 
>> and Person C and Person D. One would however have to refer to the TOS 
>> for SL to canvass that possibility.
>>
>> Putting the above aside the reason why I agree that Person B falls 
>> into violation of the license from the following from the CC-SA. It 
>> states that:
>>
>> "You may not impose any effective technological measures on the Work 
>> that restrict the ability of a recipient of the Work from You to 
>> exercise the rights granted to that recipient under the terms of the 
>> License."
>>
>> By introducing the content into an environment where it can't be 
>> easily downloaded and shared with any person quite independently from 
>> SL may very well be considered to constitute the a person applying a 
>> technological measure to the Work that restricts the ability of the 
>> recipient from exercising their rights under the license.
>>
>> But that is a fundamentally different from the person imposing terms 
>> or offering the Work to the recipient on more restrictive terms which 
>> is what the initial quotation was referring to.
>>
>> Kind regards
>>
>> Darren
>>

Re: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses

[Darmath]

Darmath wrote:
> Gigs wrote:
>> Darmath wrote:
>>> If I understand your comments in this regard correctly you appear to 
>>> be trying to suggest that because a recipient of a work covered by 
>>> the  CC-SA or other like license has agreed with Linden Labs that 
>>> they will not export a work that doesn't bare their name as a 
>>> creator the person who initially uploaded the content and 
>>> distributed it to the received is now in violation of the CC-SA.
>>>
>>> If the above is what you're trying to suggest then I must disagree 
>>> with you. But I will wait to see that the above is what you're 
>>> actually trying to assert before i respond as to why...
>>>
>>
>>
>> Person A creates content and releases it under CC-SA-By
>> Person B uploads this content to Second Life
>> Person B distributes the content to Person C
>>
>> Person C now has additional terms imposed on them that restrict their 
>> exercise of the rights granted under CC-SA-By because of the TPV 
>> agreement.  Previously they could run any client with export 
>> capability to download the work in order to modify it.  Now they 
>> can't do that. Their rights to redistribute and modify under the 
>> CC-SA have been restricted which is a violation of the CC-SA license.
>
> When I first came across this topic it was 3am and I was on my way to 
> bed so you'll forgive me for not thinking my way entirely through the 
> CC-SA. Having considered the issue this morning somewhat fresh I would 
> agree that Person B may be in violation with that agreement but not 
> for the reason Gigs (Jason) had initially stated. Initially the 
> conclusion appeared to be based upon the following from the CC-SA:.
>
> "You may not offer or impose any terms on the Work that restrict the 
> terms of this License or the ability of the recipient of the Work to 
> exercise the rights granted to that recipient under the terms of the 
> License."
>
> Putting aside for the moment that I believe that the paragraph is 
> horribly drafted as a legal document and doesn't accord with its 
> intent in its wording as far as I'm concerned I don't believe you can 
> say that as between Person B and Person C, Person B offered or imposed 
> any terms on the new recipient licensee that curtails Person's C's 
> rights under the licence.  The simple fact is that Person B didn't 
> impose any terms on Person C or offer the Work to C on any terms that 
> were more restrictive than what the license does.
>
> The fact is that Person C would fall subject to obligations to a 
> fourth Person, Linden Labs (Person D)  a result of C's own agreement 
> with D  that they won't export that content from SL unless their named 
> as the creator. The fact that C's own agreement with a fourth party 
> means that they now have obligations upon them that interfere with 
> their rights under the license they entered into and acqured from B, 
> doesn't mean that Person B imposed more restrictive terms upon C. The 
> terms that restricted C were effectively imposed by Person D.
>
> I also think there is potentially a much more interesting analysis 
> that is capable of following in the circumstances of SL, with regard 
> to the exchange of the Work from B to C, and that is whether the 
> exchange can actually be regarded as one exchange between Person B and 
> C, mediated by a mutual agent in LL (Person D). Or alternatiely 
> whether two exchanges take place both of which falling subjectable to 
> the CC-SA or possibly other like agreements. In the latter scenario  
> the first exchange would take place between Person B and Person D (LL) 
> and Person C and Person D. One would however have to refer to the TOS 
> for SL to canvass that possibility.
>
> Putting the above aside the reason why I agree that Person B falls 
> into violation of the license from the following from the CC-SA. It 
> states that:
>
> "You may not impose any effective technological measures on the Work 
> that restrict the ability of a recipient of the Work from You to 
> exercise the rights granted to that recipient under the terms of the 
> License."
>
> By introducing the content into an environment where it can't be 
> easily downloaded and shared with any person quite independently from 
> SL may very well be considered to constitute the a person applying a 
> technological measure to the Work that restricts the ability of the 
> recipient from exercising their rights under the license.
>
> But that is a fundamentally different from the person imposing terms 
> or offering the Work to the recipient on more restrictive terms which 
> is what the initial quotation was referring to.
>
> Kind regards
>
> Darren
>
>
>
>
>
>

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

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

(just bouncing back to the list)

-  Original Message 
Subject: Re: [opensource-dev] Third party viewer policy
Date: Wed, 24 Feb 2010 14:04:32 -0800
From: Rob Nelson 
To: Tigro Spottystripes 

Not to mention the many existing griefing apps that will continue to
mask hardware-based IDs and completely ignore the LL TPV. :/

Thank you for the three-month extension, should give me plenty of time
to work on changing all references of FlexLife to whatever the hell we
decide on renaming to.

The next time you guys do this sort of thing, try asking the community
about it first before setting everything in stone.  Changing brandnames
may be easy for a company with 200 developers and a marketing team, but
stuff like this takes smaller teams like Emerald, FlexLife, and Rainbow
a much longer time to implement.  Not all of us are huge megacorps like
LL.  Consider that before dropping a new policy on us without warning.

Rob Nelson
Lead Developer
The Viewer Formerly Known as FlexLife

On Wed, 2010-02-24 at 13:21 -0300, Tigro Spottystripes wrote:
> actually, changing the MAC address of your network card is quite easy in
> some cases (i've been using a custom MAC address for quite some time)
> 
> On 24/2/2010 11:28, Scott McCulley wrote:
>> Argent,
> 
>>  From a network standpoint, the mac address is a layer two address  
>> that is not seen when crossing a router to a new network. So, therer  
>> is no way to see your mac address from the network packets. LL is  
>> using the mac address as a unique identifier of your computer. When  
>> you use the SL viewer, it can read your mac address locally, then send  
>> it along to LL to be used to identify you on the grid. So if you have  
>> multiple accounts that you use from the same computer, they know it is  
>> you, no matter what your IP address, proxy server, or other network  
>> layer protection is used.
> 
>> In the case of known griefers, LL could simply disable access from  
>> that mac address that is reported by the viewer, and the person cannot  
>> get back in to the grid, regardless of IP or SL account. The only way  
>> is to use a completely new computer with a different mac address.
> 
>> That being said, if the developers mask the ability to read and report  
>> the mac address to the LL grid, they lose the abilit to block the bad  
>> guys.
> 
>> -Scott
> 
> 
>> Sent from my iPhone
> 
>> On Feb 24, 2010, at 5:49 AM, Argent Stonecutter  
>>  wrote:
> 
>>> Admittedly this is not likely to be a common scenario, but the whole
>>> idea that a MAC address is a unique identifier for a device is based
>>> on a deep-seated confusion about the network stack.
>> ___
>> 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/

iEYEARECAAYFAkuFyrgACgkQ8ZFfSrFHsmUMLACfdawsVxdug1i417EROcPVhUi0
Q/0An0Sq46pyI27iZuhmdj6YSiZlTCIa
=gMvE
-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

[Carlo Wood]

On Tue, Feb 23, 2010 at 04:05:57PM -0700, Lawson English wrote:
> 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?

Common sense again (see previous post, not claiming you're not using
common sense ;):

The whole version string is only needed in order to detect viewers
that are KNOWN bad. That is, LL is not going to make a list of
viewers that may connect, and everyone else is going to be barred;
they will contact devlopers of third party viewers with lots of
users and request changes, and when those changes are not made,
then they will bar the access of that viewer to the grid.

Thus, any viewer that doesn't have a large user base, like the
personal play toy of some developer, does not have to meet this
requirement: whatever it is, it is unknown to Linden Lab and THUS
they cannot have a reason to want to bar access of it. If your
viewer is very different from whatever you based it on then you
can just pick some unique, but constant, version string, and
that's it. 

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

Re: [opensource-dev] Third party viewer policy

[Soft Linden]

On Wed, Feb 24, 2010 at 6:23 PM, Jason Giglio  wrote:
> Soft Linden wrote:
>> Legal doesn't intend this to be a restriction on anything but use of
>> our service or eligibility for inclusion in the Viewer Directory.
>> Context is important here. Even the maintainers of GNU telnet won't
>> let someone use telnet to mess up the FSF's servers.
>>
>> Legal is aware that there has been confusion on this. There will be an
>> update soon, which makes the terms more clear.
>
> Is it an actual update to the policy document?
>
> Not a mere FAQ that says "Oh we didn't really mean what the policy says
> in plain English"?

A FAQ and an updated policy are both in the works. I don't know which
of the two this change sits in.

I'm passing on the suggestion that termination should always be one
choice of remedy, per your much earlier mail. Of the things listed, I
think that's the one which could still create a problem for the GPL,
even in a service and directory listing context. A developer can't
agree to be subject to Linden requests that might violate the license
of that developer's software.
___
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

[Jason Giglio]

Carlo Wood wrote:
> I didn't even READ the TVP all that well, I'm just going to
> stubbornly use my own common sense. If anything that is not
> common sense is going to be enforced then by all means I don't
> want to be part of SL anymore.
> 
> In this case the common sense says: If something is full perm,
> you may export it. Second Inventory does this, and I doubt
> that is suddenly made illegal.
> 
> Scripts that a team work on are definitely full-perm (from the
> point of view of SL permissions), so you can export it all
> you like.


The policy explicitly forbids exporting full permission items if you
didn't create every part of them.  Even if you have permission from the
creator to export them.  Even if the item is open source licensed.  Even
if it's from your collaboration partner.

As you imply this may not be enforced because it's frankly a very stupid
policy, but if that is the case and intent then there is no reason for
the policy to say it and it should be removed from the document.

-Jason
___
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] Viewer 2.0 JIRA - Classic UI option

[Maya Remblai]

http://jira.secondlife.com/browse/VWR-17176 -Make the classic UI optional

I know a lot of you don't like the new UI at all, or like some things 
and don't like others. I'd like to see LL make it possible to have the 
classic UI by ticking an option in Preferences. As I state in this JIRA, 
the new UI is for me unusable for content creation.

While I imagine that most third party developers will fix this, it would 
be in LL's favor to do it themselves.

Maya Remblai
___
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

[Jason Giglio]

Dale Glass wrote:
> В сообщении от Четверг 25 февраля 2010 01:30:52 автор Morgaine написал:
>> Soft,
>>
>> Please add to your list of issues to pass to Legal, a highlighted copy of
>> Clause 6 in the GPLv2
> [snip]
> 
> Seconded.
> 
> Additionally, please ensure compatibility with Creative Commons licenses, 
> especially CC-SA.
> 
> Also, I am annoyed at the limitations regarding export, imposed for content 
> where I do not want them. I would like some way in the viewer (license field 
> perhaps) to explicitly ALLOW exporting the content.


It was pointed out on other forums, this new export restriction breaks a
ton of use cases other than CC-SA:

1. Megaprims are all created by gene replacement, so you can't export them
2. Invisiprims, same deal
3. Can't collaborate with someone on a project and then export it to
other grids, since it will fail the creator check
4. Can't build on an alt and then export it on your main... less of an
issue since you can export on the alt but still very annoying.  Also
can't use textures uploaded on alt when building on main, and vice versa.

That is in addition to the concern I raised that it will effectively
make Second Life incompatible with CC-SA-By content or at least make it
very difficult to comply with.

The policy should just remove all mention of a creator check and have
some kind of general term that exporting should not be used in a way
that constitutes copyright infringement.

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

[Jason Giglio]

Soft Linden wrote:
> Legal doesn't intend this to be a restriction on anything but use of
> our service or eligibility for inclusion in the Viewer Directory.
> Context is important here. Even the maintainers of GNU telnet won't
> let someone use telnet to mess up the FSF's servers.
> 
> Legal is aware that there has been confusion on this. There will be an
> update soon, which makes the terms more clear.

Is it an actual update to the policy document?

Not a mere FAQ that says "Oh we didn't really mean what the policy says
in plain English"?


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

[Carlo Wood]

On Tue, Feb 23, 2010 at 01:16:18PM -0800, Ambroff Linden wrote:
> 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.

He said "main". A construct like that would demand the package to
be in non-free, which is highly highly to be discouraged, to the
point that I'd understand it if Robin would stop caring anymore.
It is also completely unnecessary.

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

Re: [opensource-dev] Third party viewer policy

[Carlo Wood]

On Tue, Feb 23, 2010 at 12:45:01PM -0800, Brent Tubbs wrote:
> 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.

I didn't even READ the TVP all that well, I'm just going to
stubbornly use my own common sense. If anything that is not
common sense is going to be enforced then by all means I don't
want to be part of SL anymore.

In this case the common sense says: If something is full perm,
you may export it. Second Inventory does this, and I doubt
that is suddenly made illegal.

Scripts that a team work on are definitely full-perm (from the
point of view of SL permissions), so you can export it all
you like.

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

Re: [opensource-dev] Third party viewer policy

[Soft Linden]

On Wed, Feb 24, 2010 at 4:30 PM, Morgaine
 wrote:
> Soft,
>
> Please add to your list of issues to pass to Legal, a highlighted copy of
> Clause 6 in the GPLv2 license, as well as a highlighted copy of the section
> of the GPLv2 FAQ which addresses the relevant clause of the license with a
> clear example of GPL non-compliance.  [Search for "impose any further
> restrictions" to find it].
>
> TPV section 1c is dramatically incompatible with GPLv2 clause 6 because it
> conflicts with this part of clause 6 (an extremely important term in all GPL
> licenses), in the specific case where the "recipient" of the code is the
> developer:
>
> "You may not impose any further restrictions on the recipients' exercise of
> the rights granted herein."

Legal doesn't intend this to be a restriction on anything but use of
our service or eligibility for inclusion in the Viewer Directory.
Context is important here. Even the maintainers of GNU telnet won't
let someone use telnet to mess up the FSF's servers.

Legal is aware that there has been confusion on this. There will be an
update soon, which makes the terms more clear.
___
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

[Carlo Wood]

On Tue, Feb 23, 2010 at 03:10:55PM +, Morgaine wrote:
> 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.

No, A (client-extension) is all plugins, and B (client-side scripting)
is all untrusted client-side scripting.

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

Re: [opensource-dev] Third party viewer policy

[Soft Linden]

On Wed, Feb 24, 2010 at 2:47 PM, Marine Kelley  wrote:
>
> But what I am concerned about is the viewer directory. I see that I need to
> provide my RL info to list my viewer there, and that this RL info would then
> be visible to all for liability.

More conversation with legal. Expect an update in coming days, but
tentatively: it looks like providing the info to LL will be
sufficient. Names won't be published in the public Viewer Directory.
___
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

[Peter Leonard/Dante]

I have no interest in distributing my viewer, my hack and slash
modifications are not exactly release quality anyway :P However my viewer is
heavily modified having worked on it for years.

How does this new policy affect me?

I have no intentions of doing most of what is required by the policy, such
as the branding rules. Simply because I am the only person that will ever
see this client, so it does not matter. Will these new policies prevent
people like me from using out own client? Will we just not be able to log
in? Little confused here.
___
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

[Henri Beauchamp]

On Wed, 24 Feb 2010 15:21:45 -0600, Soft Linden wrote:

> On Wed, Feb 24, 2010 at 2:47 PM, Marine Kelley 
> wrote:
>
> > But what I am concerned about is the viewer directory. I see that
> > I need to provide my RL info to list my viewer there, and that this
> > RL info would then be visible to all for liability.
> 
> I'm putting together a list of concerns for more discussion with
> legal; I'll add this to the list.

Greetings Soft,

I fully second Marine on this point, and will even add that as per the
French Law (but also EU, and I think Canada), a company like Linden Lab
is NOT founded in demanding personal data to their user unless it is
strictly impossible for them to provide the service without the said
info/data.

Since connections to SL, communications between LL and the residents, and
even the third parties viewers code publication are all achieved via
Internet, it should not be required for any developper to provide their
snail mail address like requested in the directory form: it brings nothing
and is not needed to provide the service and/or to trace back the real
person behind the avatar in case of violations (judges can for example
require personal data form the ISPs based on the sole IP used by a person).

As far as I am concerned I will not provide such info to Linden Lab as
I consider it a breach of my privacy (call me paranoid if you want).

Regards,

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

[Dale Glass]

В сообщении от Четверг 25 февраля 2010 01:30:52 автор Morgaine написал:
> Soft,
> 
> Please add to your list of issues to pass to Legal, a highlighted copy of
> Clause 6 in the GPLv2
[snip]

Seconded.

Additionally, please ensure compatibility with Creative Commons licenses, 
especially CC-SA.

Also, I am annoyed at the limitations regarding export, imposed for content 
where I do not want them. I would like some way in the viewer (license field 
perhaps) to explicitly ALLOW exporting the content.
___
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

[Lance Corrimal]

Am Mittwoch 24 Februar 2010 schrieb Soft Linden:
> On Wed, Feb 24, 2010 at 2:47 PM, Marine Kelley 
 wrote:
> > But what I am concerned about is the viewer directory. I see that
> > I need to provide my RL info to list my viewer there, and that
> > this RL info would then be visible to all for liability.
> 
> I'm putting together a list of concerns for more discussion with
> legal; I'll add this to the list.


I can see why LL would want the RL information... I'm ID verified (not 
thru aristotle, I sent copies of stuff directly to LL), so you guys 
have my data anyways...
BUT  I would not want my RL information disclosed on that viewer 
directory either.

bye,
LC
___
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

[Tim Shephard]

> i'm not a lawyer but restriction are about Linden services... not
> viewer source code..

Yes, that's how I read it as well.
___
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

[Tayra Dagostino]

On Wed, 24 Feb 2010 22:30:52 +
Morgaine  wrote:

> Please add to your list of issues to pass to Legal, a highlighted
> copy of Clause 6 in the GPLv2
> license,
> as well as a highlighted copy of the section of the GPLv2
> FAQwhich
> addresses the relevant clause of the license with a clear example of
> GPL non-compliance.  [Search for "*impose any further restrictions"*
> to find it].
[cut]
> Please do your best to help them understand this issue.

i'm not a lawyer but restriction are about Linden services... not
viewer source code...
___
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]

Soft,

Please add to your list of issues to pass to Legal, a highlighted copy of
Clause 6 in the GPLv2
license,
as well as a highlighted copy of the section of the GPLv2
FAQwhich
addresses the relevant clause of the license with a clear example of
GPL non-compliance.  [Search for "*impose any further restrictions"* to find
it].

TPV  section 1c is dramatically
incompatible with GPLv2 clause 6 because it conflicts with this part of
clause 6 (an extremely important term in all GPL licenses), in the specific
case where the "recipient" of the code is the developer:


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


I fear that LL Legal may still not get the point that this has *absolutely
nothing to do with access* to the SL service --- the GPL is not concerned
with that, and the "restrictions" mentioned in clause 6 are unrelated to
service access.  They are concerned exclusively with restrictions on the
developer's freedom to *modify and distribute GPL programs*.  Modification
and distribution of GPL-licensed programs are guaranteed by the GPL to be
free of any restrictions not mentioned in the GPL license.

A party that imposes additional restrictions (or conditions) on the freedom
of a developer to modify and distribute code may not use GPLv2 as their
license.

If LL wishes to continue using the GPL, they will need to remove the
restrictions and conditions that TPV currently imposes on the developer, and
(presumably) replace them by restrictions on access to the service by the
users of the software instead.

It worries me that this key point about the GPL will not get across to
Legal, given that they clearly failed to comprehend the GPL when drafting
TPV.

Please do your best to help them understand this issue.


Morgaine.





==

On Wed, Feb 24, 2010 at 9:21 PM, Soft Linden  wrote:

> On Wed, Feb 24, 2010 at 2:47 PM, Marine Kelley 
> wrote:
> >
> > But what I am concerned about is the viewer directory. I see that I need
> to
> > provide my RL info to list my viewer there, and that this RL info would
> then
> > be visible to all for liability.
>
> I'm putting together a list of concerns for more discussion with
> legal; I'll add this to the list.
> ___
> 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 Wed, Feb 24, 2010 at 2:47 PM, Marine Kelley  wrote:
>
> But what I am concerned about is the viewer directory. I see that I need to
> provide my RL info to list my viewer there, and that this RL info would then
> be visible to all for liability.

I'm putting together a list of concerns for more discussion with
legal; I'll add this to the list.
___
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]

Thank you Soft, I knew you wouldn't let me down. Three months is okay, I can
cope with that without rushing I think. The real plus is that they offer to
help in making sure people can still find the RLV under its new name (which
would still be "RLV" anyway, just not "Restrained Life Viewer" anymore) by
typing "Restrained Life", since most scripts in-world will not change to
reflect the name change. Without this bridge from the old name to the new
name, new people would arrive in SL, be interested in that "RLV stuff this
object is using", fail at finding it, and give up. Eventually that would be
the death of the RLV itself.

But what I am concerned about is the viewer directory. I see that I need to
provide my RL info to list my viewer there, and that this RL info would then
be visible to all for liability. I can't do that. My overall work in SL
(viewer and business alike) shows strongly my personal fetishes, and I
simply cannot afford to disclose any info that could link my avatar to my RL
identity. I could lose my job otherwise. Or worse. People in the US are
pretty cool about fetishes, but not Europeans. We are still very old school
on this side of the pond.

Besides I don't see why on Earth any RL info should be disclosed to everyone
in the open, it is nobody's business except LL's who is making and
publishing third party viewers to connect to their grid. To me the average
developer of a third party viewer should be allowed to remain anonymous,
since the real griefers are never going to publish their data anyway. And
since a viewer developer cannot be held responsible for the use of their
viewer (despite what the policy implies), this is a moot point.

Thanks though,
Marine


I talked to legal to ask if there were any concessions they could make
> - I know there are hundreds of items that use your name, which makes
> this really disruptive. Unfortunately they maintain that we put our
> trademark at risk without consistent enforcement. They can't budge.
> However, they were willing to offer some extra time for transitioning
> to a new name, as well as help in making sure people can still find
> your viewer based on the old name.
>
> First, you wouldn't need to change the name right away. They were okay
> with giving three months to make a change, in hopes that that's enough
> time to do so without a rush or an extra release.
>
> Second, if you're able to do that, you can still be listed in the
> viewer registry right away. You'd need to select a new name for the
> viewer, but "(formerly Restrained Life)" will be shown underneath the
> name so there's no question as to which viewer people would download
> if they came in search of your own.
>
> If there's anyone else with an established viewer name that conflicts
> with the viewer policy, and who wants to be included in the registry,
> the same offer is open to you as well.
>
___
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

[Ryan McDougall]

On Wed, Feb 24, 2010 at 9:40 PM, Soft Linden  wrote:
> On Wed, Feb 24, 2010 at 1:18 PM, Soft Linden  wrote:
>> On Wed, Feb 24, 2010 at 4:58 AM, Ryan McDougall  wrote:
>>> On Tue, Feb 23, 2010 at 10:31 PM, Soft Linden  wrote:

 If you see any wording that's ambiguous about that, let us know.
>>>
>>> Section 3.b.iii says that Third-party viewers must comply with the GPL 
>>> license.
>>>
>>> What if the view is not licensed under the GPL at all -- say Apache 2.0?
>>
>> This only applies to viewers based on our GPL'd viewer source. I'll
>> point that out to legal - I know the intent was to make that specific,
>> and this was an oversight.
>
> I just checked before writing to legal, and this phrase is already
> included in 3.b.iii:
> "if you have based your application on the official Second Life
> viewer, which we have made available under the GPL"
>
> So this guy's already covered.
>

Not sure how I missed that -- or maybe I am (too much legalese text).
Can you also clarify what the penalties are for non-compliance?

Cheers,
___
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] Request for help on compiling Snowglobe

[malachi]

i have been trying since snowglobe started to compile this thing. and 
for some reason i have yet to be successful in doing so. i think 
snowglobe hates me. i can compile the standard client source just fine. 
but when it comes to snowglobe i always seem to get hundreds of errors. 
so im finally done trying to sort it out alone

anyone here willing to spend a few minutes to help me figure out what is 
going wrong with snow that wont allow it to compile?



i have tried this with visual studio 2008, visual c++ 2008 express, 
visual studio 2005, visual c++ 2005, i have tried all versions of cmake 
and python and have tried while using vista and win7 both 32bit and 
64bit OS.

so far im down to just Build: 21 succeeded, 50 failed, 30 up-to-date, 2 
skipped. which is way better than it was before lol.
___
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 update

[Michael Schlenker]

Am 24.02.2010 um 09:51 schrieb Lance Corrimal:

> Am Mittwoch, 24. Februar 2010 09:26:12 schrieb Thomas Shikami:
>> Philippe (Merov) Bossut schrieb:
>>>  - SOCKS5: here, Robin volunteered
>> 
>> SOCKS5 is against the TPV Policy term
>> 2c. You must not circumvent any security-related features or measures we
>> may take to limit access to Second Life. For example:
>> 2c.i.You must not mask IP or MAC addresses.
>> 
>> SOCKS5 is usually used by griefers to mask the IP address.
> 
> 
> I'd say "bull" here. While it is true that the IP address of traffic coming 
> thru a socks (or any other) proxy is the ip of the proxy, the mac address IN 
> THE IP HEADER is the one of the router anyways... if any.
> 
> What LL means is "You must not circumvent the viewer finding out its local 
> mac 
> address and sending that in the authorization data".

Which is silly anyway as any decent network card can change its MAC via its 
driver.

Michael
___
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 Wed, Feb 24, 2010 at 1:18 PM, Soft Linden  wrote:
> On Wed, Feb 24, 2010 at 4:58 AM, Ryan McDougall  wrote:
>> On Tue, Feb 23, 2010 at 10:31 PM, Soft Linden  wrote:
>>>
>>> If you see any wording that's ambiguous about that, let us know.
>>
>> Section 3.b.iii says that Third-party viewers must comply with the GPL 
>> license.
>>
>> What if the view is not licensed under the GPL at all -- say Apache 2.0?
>
> This only applies to viewers based on our GPL'd viewer source. I'll
> point that out to legal - I know the intent was to make that specific,
> and this was an oversight.

I just checked before writing to legal, and this phrase is already
included in 3.b.iii:
"if you have based your application on the official Second Life
viewer, which we have made available under the GPL"

So this guy's already covered.
___
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

Could you please ask them to review everything and making it all as
specific and clear as possible? (i know that this is kinda the opposite
of what people usually try to do in legal documents like contracts,
EULAs etc, but it would really benefit the community to have things
spelled out to the last character, knowing what is and what isn't
allowed without doubts and without fear that things could be interpreted
differently by LL or some laywers or somthing would make developers and
users much happier)

On 24/2/2010 16:23, Soft Linden wrote:
> On Tue, Feb 23, 2010 at 2:31 PM, 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.
> 
> There were some follow-on concerns about who's responsible for
> modified viewers that do non-compliant things, but misrepresent
> themselves as the viewer in the viewer directory. Legal's going to
> follow up with changes that make this more clear - they're still
> hammering out some of the specifics. But it's not as onerous as some
> of the interpretations so far; you're not going to get banned or lose
> your directory listing over someone else's actions.
> ___
> 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/

iEUEARECAAYFAkuFgD0ACgkQ8ZFfSrFHsmUutwCfR3lXWEkTzzhIW8tuoE5wNITL
QEIAmLHWGWzWS0NMfXm101ABmem7vbM=
=xhfl
-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] DRM vs TOS Was: Third party viewer policy

[Dzonatas Sol]

Lawson English wrote:
> Dzonatas Sol wrote:
>> Lawson English wrote:
>>  
>>> For a real life use case, the realxtend developers are currently 
>>> debating whether or not it is worth their while to continue to add 
>>> more support to SL rather than just go with OpenSim-only.
>>>
>>>   
>>
>>
>> If any viewer is under GPL terms, rather it is derived or not, it 
>> probably won't comply with the TOS if the TOS mandates DRM.
>>
>> Software that runs on hardware that enforces DRM is not different 
>> than software that connects to a service that enforces DRM.
>>
>> Obviously, basic login credentials aren't being seen as DRM, yet MAC 
>> address, channels, and other means to enforce control of the client 
>> software, especially through TOS policy, is DRM.
>>
>> All those discussion's we've had on this list about "signed-off" 
>> scripts and programs, even encrypted, have had their rug pulled. Even 
>> Microsoft's one-click programs are affected.
>>
>> I wouldn't say LL backpedaled on the GPL, yet I will say the DRM 
>> movement is highly questionable. I can understand why realxtend would 
>> want to not continue support for SL with such cloud of questions. 
>> This would have been prevented if...  you know, there is a big 
>> elephant in the room.
>>
>>   
>
> the Naali viewer is from-scratch under a freebsd license. No GPL code 
> at all.
>
>
> Lawson
>
>


I can hit that Infinite Button of 'what see what this does' too??? They 
make great bitch points.
___
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:31 PM, 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.

There were some follow-on concerns about who's responsible for
modified viewers that do non-compliant things, but misrepresent
themselves as the viewer in the viewer directory. Legal's going to
follow up with changes that make this more clear - they're still
hammering out some of the specifics. But it's not as onerous as some
of the interpretations so far; you're not going to get banned or lose
your directory listing over someone else's actions.
___
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 Wed, Feb 24, 2010 at 4:58 AM, Ryan McDougall  wrote:
> On Tue, Feb 23, 2010 at 10:31 PM, Soft Linden  wrote:
>>
>> If you see any wording that's ambiguous about that, let us know.
>
> Section 3.b.iii says that Third-party viewers must comply with the GPL 
> license.
>
> What if the view is not licensed under the GPL at all -- say Apache 2.0?

This only applies to viewers based on our GPL'd viewer source. I'll
point that out to legal - I know the intent was to make that specific,
and this was an oversight.
___
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 Wed, Feb 24, 2010 at 1:50 AM, Marine Kelley  wrote:
> 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

I talked to legal to ask if there were any concessions they could make
- I know there are hundreds of items that use your name, which makes
this really disruptive. Unfortunately they maintain that we put our
trademark at risk without consistent enforcement. They can't budge.
However, they were willing to offer some extra time for transitioning
to a new name, as well as help in making sure people can still find
your viewer based on the old name.

First, you wouldn't need to change the name right away. They were okay
with giving three months to make a change, in hopes that that's enough
time to do so without a rush or an extra release.

Second, if you're able to do that, you can still be listed in the
viewer registry right away. You'd need to select a new name for the
viewer, but "(formerly Restrained Life)" will be shown underneath the
name so there's no question as to which viewer people would download
if they came in search of your own.

If there's anyone else with an established viewer name that conflicts
with the viewer policy, and who wants to be included in the registry,
the same offer is open to you as well.
___
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 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.

I've talked to legal, and there will be an alternative option to
presentation at download or install time. Expect more details soon.
___
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] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses

[Gigs]

Mike Dickson wrote:
> Right. Person B has the responsibility to make available or point to an 
> unrestricted source for the content they upload to Second Life.  The 
> same with GPL'd content.  I don't see a reason why LL can't put 
> restrictions on content distribution within the service. It's the person 
> who imports the content that has the responsibility to insure that it 
> meets the distribution requirements under which it's licensed.

That last part is correct, it is person B's responsibility not to 
distribute the work in a way that places additional restrictions upon it.

Providing a URL to an unprotected version is not sufficient, because 
Person B has no license to distribute a restricted version within Second 
Life.  Including a URL doesn't magically grant them such a license to 
distribute a version under terms other than the CC-SA allows.

-Jason
___
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] DRM vs TOS Was: Third party viewer policy

[Lawson English]

Dzonatas Sol wrote:
> Lawson English wrote:
>   
>> For a real life use case, the realxtend developers are currently 
>> debating whether or not it is worth their while to continue to add more 
>> support to SL rather than just go with OpenSim-only.
>>
>>   
>> 
>
>
> If any viewer is under GPL terms, rather it is derived or not, it 
> probably won't comply with the TOS if the TOS mandates DRM.
>
> Software that runs on hardware that enforces DRM is not different than 
> software that connects to a service that enforces DRM.
>
> Obviously, basic login credentials aren't being seen as DRM, yet MAC 
> address, channels, and other means to enforce control of the client 
> software, especially through TOS policy, is DRM.
>
> All those discussion's we've had on this list about "signed-off" scripts 
> and programs, even encrypted, have had their rug pulled. Even 
> Microsoft's one-click programs are affected.
>
> I wouldn't say LL backpedaled on the GPL, yet I will say the DRM 
> movement is highly questionable. I can understand why realxtend would 
> want to not continue support for SL with such cloud of questions. This 
> would have been prevented if...  you know, there is a big elephant in 
> the room.
>
>   

the Naali viewer is from-scratch under a freebsd license. No GPL code at 
all.


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] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses

[Mike Dickson]

On 02/24/2010 11:07 AM, Gigs wrote:
> Darmath wrote:
>
>> If I understand your comments in this regard correctly you appear to be
>> trying to suggest that because a recipient of a work covered by the
>> CC-SA or other like license has agreed with Linden Labs that they will
>> not export a work that doesn't bare their name as a creator the person
>> who initially uploaded the content and distributed it to the received is
>> now in violation of the CC-SA.
>>
>> If the above is what you're trying to suggest then I must disagree with
>> you. But I will wait to see that the above is what you're actually
>> trying to assert before i respond as to why...
>>
>>  
>
> Person A creates content and releases it under CC-SA-By
> Person B uploads this content to Second Life
> Person B distributes the content to Person C
>
> Person C now has additional terms imposed on them that restrict their
> exercise of the rights granted under CC-SA-By because of the TPV
> agreement.  Previously they could run any client with export capability
> to download the work in order to modify it.  Now they can't do that.
> Their rights to redistribute and modify under the CC-SA have been
> restricted which is a violation of the CC-SA license.
>
Right. Person B has the responsibility to make available or point to an 
unrestricted source for the content they upload to Second Life.  The 
same with GPL'd content.  I don't see a reason why LL can't put 
restrictions on content distribution within the service. It's the person 
who imports the content that has the responsibility to insure that it 
meets the distribution requirements under which it's licensed.

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] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses

[Gigs]

Darmath wrote:
> If I understand your comments in this regard correctly you appear to be 
> trying to suggest that because a recipient of a work covered by the  
> CC-SA or other like license has agreed with Linden Labs that they will 
> not export a work that doesn't bare their name as a creator the person 
> who initially uploaded the content and distributed it to the received is 
> now in violation of the CC-SA.
> 
> If the above is what you're trying to suggest then I must disagree with 
> you. But I will wait to see that the above is what you're actually 
> trying to assert before i respond as to why...
> 


Person A creates content and releases it under CC-SA-By
Person B uploads this content to Second Life
Person B distributes the content to Person C

Person C now has additional terms imposed on them that restrict their 
exercise of the rights granted under CC-SA-By because of the TPV 
agreement.  Previously they could run any client with export capability 
to download the work in order to modify it.  Now they can't do that. 
Their rights to redistribute and modify under the CC-SA have been 
restricted which is a violation of the CC-SA license.
___
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

actually, changing the MAC address of your network card is quite easy in
some cases (i've been using a custom MAC address for quite some time)

On 24/2/2010 11:28, Scott McCulley wrote:
> Argent,
> 
>  From a network standpoint, the mac address is a layer two address  
> that is not seen when crossing a router to a new network. So, therer  
> is no way to see your mac address from the network packets. LL is  
> using the mac address as a unique identifier of your computer. When  
> you use the SL viewer, it can read your mac address locally, then send  
> it along to LL to be used to identify you on the grid. So if you have  
> multiple accounts that you use from the same computer, they know it is  
> you, no matter what your IP address, proxy server, or other network  
> layer protection is used.
> 
> In the case of known griefers, LL could simply disable access from  
> that mac address that is reported by the viewer, and the person cannot  
> get back in to the grid, regardless of IP or SL account. The only way  
> is to use a completely new computer with a different mac address.
> 
> That being said, if the developers mask the ability to read and report  
> the mac address to the LL grid, they lose the abilit to block the bad  
> guys.
> 
> -Scott
> 
> 
> Sent from my iPhone
> 
> On Feb 24, 2010, at 5:49 AM, Argent Stonecutter  
>  wrote:
> 
>> Admittedly this is not likely to be a common scenario, but the whole
>> idea that a MAC address is a unique identifier for a device is based
>> on a deep-seated confusion about the network stack.
> ___
> 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/

iEYEARECAAYFAkuFUfgACgkQ8ZFfSrFHsmWWwACggOJbg9m66z8tj47Gmcx0oquQ
hswAmwTv24H2Vh7KYwP5U938ulbt5EVB
=g8wT
-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] Snowglobe 2 update

[Matrice64]

Yeah I commented out everything in the  if (test)   part of the
CMakeLists.txt towards the bottom and it worked out for me

On Wed, Feb 24, 2010 at 6:11 AM, Argent Stonecutter
 wrote:
> On 2010-02-24, at 02:26, Thomas Shikami wrote:
>> SOCKS5 is usually used by griefers to mask the IP address.
>
> SOCKS5 is the only way to connect if you are behind a reasonably
> secure corporate firewall.
>
> SL is completely out of the question for business use without SOCKS5
> support, even for the kind of "3d corporate website" model that LL is
> pushing.
>
> ___
> 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] "Resposibility" - Third party viewer policy

[Vex Streeter]

Lance Corrimal wrote:

  Am Dienstag, 23. Februar 2010 21:16:44 schrieb Gigs:
  
  
http://secondlife.com/corporate/tpv.php

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

  
  

Correct me if  I'm wrong...

The whole "you are responsible" stuff seems to mean that if X provides any 
open source viewer, X is also responsible for any misdeeds committed with 
other people's derivatives of X?

  

GPL also specifically disclaims warranty and liability unless you
choose to provide such for your code or distribution.  Policy sections
1.c.i and 1.c.ii are redundant w/rt GPL but_requiring_ such statements
of downstream distributors conflicts with GPL.  Policy section 7.d is
even worse as it directly contradicts GPL liability disclaimers.


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

[Gareth Nelson]

And now we get griefers spoofing channels specifically to get viewers
banned..

On Wed, Feb 24, 2010 at 2:12 PM, Maggie Leber (sl: Maggie Darwin)
 wrote:
> On Wed, Feb 24, 2010 at 12:08 AM, Imaze Rhiano  wrote:
>
>> Now - one of following scenarios would happen - what I should do - and
>> what would be LL's reaction...
>
> Long story short, it seems clear that as soon as somebody is suspected
> of using a ToS-violating viewer, the channel that viewer is running
> under will get blocked, and it will fall to the registered owner of
> the channel (if any) to figure out what happened and who did it in
> order to get their channel restored. Without being able to log on to
> Second Life, since your accounts will be suspended.
>
> Meanwhile, griefers and content copiers will morph automatically to
> unblocked channels. Sure, spoofing channels a ToS violation, but so is
> greifing and content copying. Just as much a feel-good cop-out as
> relying on a handgun ban to stop armed robbery.
> ___
> 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

[opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses

[Gigs]

CC-SA says:

"You may not offer or impose any terms on the Work that restrict the 
terms of this License or the ability of the recipient of the Work to 
exercise the rights granted to that recipient under the terms of the 
License."

If anyone has uploaded CC-SA licensed textures or other materials to 
Second Life, they are now in violation of that license because of the 
new third party viewer policy section 2b which forbids reproduction of 
materials that were uploaded by someone else.

As well, any full perm materials uploaded to Second Life under a GPL 
license cannot fulfill their requirements either since there have been 
additional restrictions placed on the distribution.
___
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]

Legally speaking, it's difficult to see how they could make you bound
by it - only way I can see is with the TOS

So. someone closes their SL account and makes a noncompliant
viewer - what happens?

On Wed, Feb 24, 2010 at 2:34 PM, Gigs  wrote:
> Lawson English wrote:
>> For a real life use case, the realxtend developers are currently
>> debating whether or not it is worth their while to continue to add more
>> support to SL rather than just go with OpenSim-only.
>
> Unless Linden Lab is willing to provide an already-banned channel ID for
> third party developers to use to prevent their software from connecting
> to Second Life, it's going to be very hard to not be subject to this
> "agreement".
>
> Even then they user could change the channel and potentially make the
> developer liable under this agreement.
> ___
> 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

Re: [opensource-dev] Third party viewer policy

[Gigs]

Lawson English wrote:
> For a real life use case, the realxtend developers are currently 
> debating whether or not it is worth their while to continue to add more 
> support to SL rather than just go with OpenSim-only.

Unless Linden Lab is willing to provide an already-banned channel ID for 
third party developers to use to prevent their software from connecting 
to Second Life, it's going to be very hard to not be subject to this 
"agreement".

Even then they user could change the channel and potentially make the 
developer liable under this agreement.
___
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

[Anders Arnholm]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 2010-02-24 15:28, Scott McCulley wrote:
> In the case of known griefers, LL could simply disable access from
> that mac address that is reported by the viewer, and the person
> cannot get back in to the grid, regardless of IP or SL account.
> The only way is to use a completely new computer with a different
> mac address.
Or, edit the ethernets card mac address, as this is changeably in
software. In windows it's in the device manager. Using that for
security sounds kinda stupid.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkuFOK8ACgkQtbR3SXmySrce6QCfduEy3PLGx477dk3FKHy50qtY
FX0An2oM1kFoGIzc1MbaQHo9mqVuiufk
=dv6e
-END PGP SIGNATURE-


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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] DRM vs TOS Was: Third party viewer policy

[Dzonatas Sol]

Lawson English wrote:
> For a real life use case, the realxtend developers are currently 
> debating whether or not it is worth their while to continue to add more 
> support to SL rather than just go with OpenSim-only.
>
>   


If any viewer is under GPL terms, rather it is derived or not, it 
probably won't comply with the TOS if the TOS mandates DRM.

Software that runs on hardware that enforces DRM is not different than 
software that connects to a service that enforces DRM.

Obviously, basic login credentials aren't being seen as DRM, yet MAC 
address, channels, and other means to enforce control of the client 
software, especially through TOS policy, is DRM.

All those discussion's we've had on this list about "signed-off" scripts 
and programs, even encrypted, have had their rug pulled. Even 
Microsoft's one-click programs are affected.

I wouldn't say LL backpedaled on the GPL, yet I will say the DRM 
movement is highly questionable. I can understand why realxtend would 
want to not continue support for SL with such cloud of questions. This 
would have been prevented if...  you know, there is a big elephant in 
the room.
___
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

[Scott McCulley]

Argent,

 From a network standpoint, the mac address is a layer two address  
that is not seen when crossing a router to a new network. So, therer  
is no way to see your mac address from the network packets. LL is  
using the mac address as a unique identifier of your computer. When  
you use the SL viewer, it can read your mac address locally, then send  
it along to LL to be used to identify you on the grid. So if you have  
multiple accounts that you use from the same computer, they know it is  
you, no matter what your IP address, proxy server, or other network  
layer protection is used.

In the case of known griefers, LL could simply disable access from  
that mac address that is reported by the viewer, and the person cannot  
get back in to the grid, regardless of IP or SL account. The only way  
is to use a completely new computer with a different mac address.

That being said, if the developers mask the ability to read and report  
the mac address to the LL grid, they lose the abilit to block the bad  
guys.

-Scott


Sent from my iPhone

On Feb 24, 2010, at 5:49 AM, Argent Stonecutter  
 wrote:

> Admittedly this is not likely to be a common scenario, but the whole
> idea that a MAC address is a unique identifier for a device is based
> on a deep-seated confusion about the network stack.
___
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....

[Maggie Leber (sl: Maggie Darwin)]

On Wed, Feb 24, 2010 at 12:08 AM, Imaze Rhiano  wrote:

> Now - one of following scenarios would happen - what I should do - and
> what would be LL's reaction...

Long story short, it seems clear that as soon as somebody is suspected
of using a ToS-violating viewer, the channel that viewer is running
under will get blocked, and it will fall to the registered owner of
the channel (if any) to figure out what happened and who did it in
order to get their channel restored. Without being able to log on to
Second Life, since your accounts will be suspended.

Meanwhile, griefers and content copiers will morph automatically to
unblocked channels. Sure, spoofing channels a ToS violation, but so is
greifing and content copying. Just as much a feel-good cop-out as
relying on a handgun ban to stop armed robbery.
___
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 update

[Argent Stonecutter]

On 2010-02-24, at 02:26, Thomas Shikami wrote:
> SOCKS5 is usually used by griefers to mask the IP address.

SOCKS5 is the only way to connect if you are behind a reasonably  
secure corporate firewall.

SL is completely out of the question for business use without SOCKS5  
support, even for the kind of "3d corporate website" model that LL is  
pushing.

___
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

[Argent Stonecutter]

On 2010-02-23, at 15:43, Robin Cornelius wrote:
> 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.

Not to mention that any device using SLIP or PPP, (and probably other  
point-to-point protocols that don't require an address at the physical  
layer) may not have a MAC address or ANY analogous hardware layer  
address (even a PSTN). TCP/IP does not imply Ethernet.

Admittedly this is not likely to be a common scenario, but the whole  
idea that a MAC address is a unique identifier for a device is based  
on a deep-seated confusion about the network stack.
___
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]

Ryan McDougall wrote:
> On Tue, Feb 23, 2010 at 10:31 PM, Soft Linden  wrote:
>   
>> If you see any wording that's ambiguous about that, let us know.
>> 
>
> Section 3.b.iii says that Third-party viewers must comply with the GPL 
> license.
>
> What if the view is not licensed under the GPL at all -- say Apache 2.0?
>
> Cheers,
>   

For a real life use case, the realxtend developers are currently 
debating whether or not it is worth their while to continue to add more 
support to SL rather than just go with OpenSim-only.

If LL's aim was to squelch all third party work on SL-compatible 
viewers, they've done admirably.

If not, they've just shot themselves in the foot with a blended metal 
bullet:

http://www.metacafe.com/watch/180211/blended_metal_vs_ham/


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

[Ryan McDougall]

On Wed, Feb 24, 2010 at 1:10 PM, Thomas Shikami
 wrote:
> Ryan McDougall schrieb:
>> On Tue, Feb 23, 2010 at 10:31 PM, Soft Linden  wrote:
>>
>>> If you see any wording that's ambiguous about that, let us know.
>>>
>>
>> Section 3.b.iii says that Third-party viewers must comply with the GPL 
>> license.
>>
>> What if the view is not licensed under the GPL at all -- say Apache 2.0?
>>
>> Cheers,

> It says, that Third-Party Viewers deriving from LL's GPLed viewer source
> must comply with the GPL license. That doesn't apply to libomv based
> viewers or pygop based ones or smalltalk or a complete reimplementation
> of it.

Actually it doesn't.

"By “Third-Party Viewer,” we mean any third-party software client on
any device that logs into our servers that support Second Life.
Third-Party Viewers include software for viewing Second Life, any chat
clients, utilities, bots, and proxies as well as applications that may
not be listed in our Viewer Directory."

Cheers,
___
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]

Ryan McDougall schrieb:
> On Tue, Feb 23, 2010 at 10:31 PM, Soft Linden  wrote:
>   
>> If you see any wording that's ambiguous about that, let us know.
>> 
>
> Section 3.b.iii says that Third-party viewers must comply with the GPL 
> license.
>
> What if the view is not licensed under the GPL at all -- say Apache 2.0?
>
> Cheers,
> ___
> 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
>
>   
It says, that Third-Party Viewers deriving from LL's GPLed viewer source 
must comply with the GPL license. That doesn't apply to libomv based 
viewers or pygop based ones or smalltalk or a complete reimplementation 
of it.
___
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

[Ryan McDougall]

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

Section 3.b.iii says that Third-party viewers must comply with the GPL license.

What if the view is not licensed under the GPL at all -- say Apache 2.0?

Cheers,
___
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 update

[Robin Cornelius]

On Wed, Feb 24, 2010 at 9:18 AM, Lance Corrimal
 wrote:
> Am Mittwoch, 24. Februar 2010 06:45:56 schrieb Philippe (Merov) Bossut:
>> Hi,
>>
>> So, Snowglobe 2 is out there and ready to build/hack. Well, almost.
>
>
> trying to build a svn checkout:
> after running develop.py i get this:
>
> -- Version of viewer is 2.0.0.0
> -- Configuring done
> CMake Error in newview/CMakeLists.txt:
>  Cannot find source file "llcapabilitylistener_test.cpp".  Tried extensions
>  .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx
>


Looks like it got forgotton in the export, please open a jira against
snowglobe 2.0, source code and mention that.

For the moment if you edit newview/CMakeLists.txt and find that entry
and remove it, that should let you continue, but its possible there
could be more of these so worth investigating

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

[Lance Corrimal]

Am Mittwoch, 24. Februar 2010 06:45:56 schrieb Philippe (Merov) Bossut:
> Hi,
> 
> So, Snowglobe 2 is out there and ready to build/hack. Well, almost.


trying to build a svn checkout:
after running develop.py i get this:

-- Version of viewer is 2.0.0.0
-- Configuring done
CMake Error in newview/CMakeLists.txt:
  Cannot find source file "llcapabilitylistener_test.cpp".  Tried extensions
  .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx

___
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

[Lance Corrimal]

Am Mittwoch, 24. Februar 2010 10:06:20 schrieb Robin Cornelius:
> Merov had to get at least a working viewer and code out the door

This might not apply to "snowglobe 2.0" at all, havent built yet... but 
"SecondLife 2.0" is hardly working.
I'm stuck in cloud mode, appearance won't load. Doesn't matter where i log in 
to, and cache is cleared.


Therefor... calling that "a working viewer" in my opinion only reads as "well 
at least it doesn't crash on start".

bye,
LC
___
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

[Robin Cornelius]

On Wed, Feb 24, 2010 at 2:19 AM, 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?

Posponed is the word, Merov has done the port to snowglobe 2.0 as fast
as he could and not every single feature that was in SG 1.2/1.3 has
_yet_ been ported across. There was a deadline of yesterday for the
release of 2.0 so Merov had to get at least a working viewer and code
out the door so somethings just had to wait. He always said this would
happen in the last few opensource meetings and that now the code has
landed the last bits can be added back in

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

[Dahlia Trimble]

Wasn't meant to torment anyone. Actually I was considering it for a viewer
name ;)


On Wed, Feb 24, 2010 at 1:00 AM, Marine Kelley wrote:

> Laugh, while I work at finding a name that will not infringe LL's new
> policy, update countless pages of documentation, download websites and
> blogs, update all my scripts and manuals, and explain to scripters why they
> have to update theirs.
>
>
>
> On 24 févr. 2010, at 09:48, Dahlia Trimble 
> wrote:
>
> C'est la vie
>
>
>
> On Wed, Feb 24, 2010 at 12:43 AM, Lawson English < 
> lengli...@cox.net> wrote:
>
>> Marine Kelley wrote:
>> > You gotta be kiddin me !! I call that a stab in the back. You guys
>> > disgust me.
>> >
>> >1. 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:
>> >  1. You must not have a Third-Party Viewer name that is
>> > “ Life” where “” is a term or series of
>> terms
>> >
>>
>> I wonder if 二回♀will violate this
>>
>>
>> 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
>>
>
> ___
> 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

[Marine Kelley]

Laugh, while I work at finding a name that will not infringe LL's new  
policy, update countless pages of documentation, download websites and  
blogs, update all my scripts and manuals, and explain to scripters why  
they have to update theirs.




On 24 févr. 2010, at 09:48, Dahlia Trimble   
wrote:



C'est la vie



On Wed, Feb 24, 2010 at 12:43 AM, Lawson English   
wrote:

Marine Kelley wrote:
> You gotta be kiddin me !! I call that a stab in the back. You guys
> disgust me.
>
>1. 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:
>  1. You must not have a Third-Party Viewer name that is
> “ Life” where “” is a term or  
series of terms

>

I wonder if 二回♀will violate this


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


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

[Lance Corrimal]

Am Dienstag, 23. Februar 2010 21:16:44 schrieb Gigs:
> http://secondlife.com/corporate/tpv.php
> 
> You all realize this is massively incompatible with the GPL, right?


Correct me if  I'm wrong...

The whole "you are responsible" stuff seems to mean that if X provides any 
open source viewer, X is also responsible for any misdeeds committed with 
other people's derivatives of X?


well... Linden Labs provides an open source viewer.

Talk about a double-edged sword.

on the other hand...

While LL does in fact have my full RL adress and name (I'm ID verified and not 
thru aristotle, I sent in copies of stuff since a service like aristotle is of 
dubious legality in europe), I do not want my real life information publicly 
visible in that "viewer directory".

bye,
LC
___
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 update

[Lance Corrimal]

Am Mittwoch, 24. Februar 2010 09:26:12 schrieb Thomas Shikami:
> Philippe (Merov) Bossut schrieb:
> >   - SOCKS5: here, Robin volunteered
> 
> SOCKS5 is against the TPV Policy term
> 2c. You must not circumvent any security-related features or measures we
> may take to limit access to Second Life. For example:
> 2c.i.You must not mask IP or MAC addresses.
> 
> SOCKS5 is usually used by griefers to mask the IP address.


I'd say "bull" here. While it is true that the IP address of traffic coming 
thru a socks (or any other) proxy is the ip of the proxy, the mac address IN 
THE IP HEADER is the one of the router anyways... if any.

What LL means is "You must not circumvent the viewer finding out its local mac 
address and sending that in the authorization data".

bye,
LC
___
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

[Dahlia Trimble]

C'est la vie



On Wed, Feb 24, 2010 at 12:43 AM, Lawson English  wrote:

> Marine Kelley wrote:
> > You gotta be kiddin me !! I call that a stab in the back. You guys
> > disgust me.
> >
> >1. 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:
> >  1. You must not have a Third-Party Viewer name that is
> > “ Life” where “” is a term or series of terms
> >
>
> I wonder if 二回♀will violate this
>
>
> 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
>
___
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]

Marine Kelley wrote:
> You gotta be kiddin me !! I call that a stab in the back. You guys 
> disgust me.  
>
>1. 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:
>  1. You must not have a Third-Party Viewer name that is
> “ Life” where “” is a term or series of terms
>

I wonder if 二回♀will violate this


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

[Thomas Shikami]

Philippe (Merov) Bossut schrieb:
>   - SOCKS5: here, Robin volunteered

SOCKS5 is against the TPV Policy term
2c. You must not circumvent any security-related features or measures we 
may take to limit access to Second Life. For example:
2c.i.You must not mask IP or MAC addresses.

SOCKS5 is usually used by griefers to mask the IP address.

And yes, the developers are responsible for what the users do with it. 
It's also in the TPV Policy
7a.You are responsible for all uses you make of Third-Party Viewers, and 
if you are a Developer, you are also responsible for all Third-Party 
Viewers that you develop or distribute
___
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

[Ryan McDougall]

As far as I can tell, LL provides a *service* called SL; and they can
choose to deny access to that service to whomever they please for
whatever reason they please.

So long as they control the server software and grid infrastructure
this will always be the case. Having an "open" viewer to closed palace
garden is *meaningless*.

Even now, the viewer is becoming more closed (see Merov's Firefox v.
WebKit comparison). What is the point of having an "open" core,
missing all the value-added features, connecting to a black box, over
non-standard (in any sense) protocol, governed by the legal policies
of a single company?

Google used WebKit to make Chrome. Does anyone here think someone is
really going to turn Snow Globe into an independent application (any
more)?

Luckily there *are* truly open, free for any use implementations
available. But they're alpha software, and will require much love
before giving a real challenge to the professionally developed SL.

As developers why continue to support the thing you rail against? Why
not lend a hand to the small number of people trying to give you what
you're looking for?

Cheers,
___
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

[Skidz Tweak]

Looks like Slashdot just picked this up.
http://news.slashdot.org/story/10/02/24/014209/Second-Life-Tries-To-Backpeda
l-On-the-GPL


-Original Message-
From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Gigs
Sent: Tuesday, February 23, 2010 2:17 PM
To: opensource-dev@lists.secondlife.com
Subject: [opensource-dev] Third party viewer policy

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