Re: [opensource-dev] An SL appliance...

[Discrete Dreamscape]

If you want to use X forwarding, you're probably not going to be happy with
the results. Machines on the same gigabit switch can even have poor
performance just loading or refreshing a file manager. There may be other
ways, and there are always remote desktop-type layers like NX..


Discrete


On Thu, Jul 14, 2011 at 10:56 AM, Lee ponzu  wrote:

> Does the Linux viewer use X?  If you DISPLAY SL on another computer running
> an XServer, does it behave OK.
>
> If so, could you assemble a small Linux host with a high end GPU and then
> DISPLAY SL on a different computer on the same local network?
>
> ponzu
>
> ___
> 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] Review Request: STORM-1122 Linux viewer sucks up file descriptors, stops loading content and crashes

[Discrete Dreamscape]

> On April 3, 2011, 8:29 p.m., Merov Linden wrote:
> > indra/llwindow/llwindow.cpp, line 210
> > <http://codereview.secondlife.com/r/245/diff/1/?file=1369#file1369line210>
> >
> > Hmmm, this is basically doing for Linux what is already done for Mac 
> > and Win32. If that's the case, I'd rather have your hack move to 
> > llwindowsdl.cpp. It might be time to retire that 
> > getDynamicFallbackFontList() code entirely then.

After speaking to a friend and looking a little deeper, it appears that the 
function does have some reasonable purpose.. the font files included in the 
viewer do not have substantial Unicode support, which I discovered when trying 
to input Japanese. On Windows/Mac, there are sections clearly defining fonts 
that provide this support, but no such fonts exist for Linux, perhaps because 
it's not certain that they're on the system. I recall from the past that Arial 
Unicode isn't a completely free font and can't be included by default.. So I 
guess the proper solution would actually first be to either add Linux (or 
universal) fonts that provide proper support, or dig deeper into the fallback 
font function to figure out why it's going descriptor-crazy. It's a pretty 
hairy-looking thing..


- Discrete


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/245/#review538
-------


On March 30, 2011, 11:49 a.m., Discrete Dreamscape wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/245/
> ---
> 
> (Updated March 30, 2011, 11:49 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Resolved Linux file descriptor greediness by removing obsolete fallback font 
> searching (call to LLWindowSDL::getDynamicFallbackFontList()), as this seems 
> to be obsolete unless your skin's configuration references font files that 
> are not packaged with the viewer, which is not the default case. Would like 
> to know if this solves the instability described in STORM-1122 for Linux 
> users, particularly those with lower than average file descriptor limits set 
> (find out by running `ulimit -a`, it's the value 'open files', mine is 1024 
> on Ubuntu 10.10 and I'd have extreme problems prior to the patch).
> 
> 
> This addresses bug STORM-1122.
> http://jira.secondlife.com/browse/STORM-1122
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt a8f868007986 
>   indra/llwindow/llwindow.cpp a8f868007986 
> 
> Diff: http://codereview.secondlife.com/r/245/diff
> 
> 
> Testing
> ---
> 
> Useful ways to examine file descriptor usage for the viewer
> 
> lsof -c do-not | less
> 
> This should be much, much less than 1024
> lsof -c do-not | wc -l
> 
> This shows all descriptors containing the word 'font' along with the number 
> of each (there are tons of duplicates)
> lsof -c do-not | egrep -o '[^ ]*font[^ ]*' | sort | uniq -c | less
> 
> 
> Thanks,
> 
> Discrete
> 
>

___
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] Review Request: STORM-1122 Linux viewer sucks up file descriptors, stops loading content and crashes

[Discrete Dreamscape]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/245/
---

Review request for Viewer.


Summary
---

Resolved Linux file descriptor greediness by removing obsolete fallback font 
searching (call to LLWindowSDL::getDynamicFallbackFontList()), as this seems to 
be obsolete unless your skin's configuration references font files that are not 
packaged with the viewer, which is not the default case. Would like to know if 
this solves the instability described in STORM-1122 for Linux users, 
particularly those with lower than average file descriptor limits set (find out 
by running `ulimit -a`, it's the value 'open files', mine is 1024 on Ubuntu 
10.10 and I'd have extreme problems prior to the patch).


This addresses bug STORM-1122.
http://jira.secondlife.com/browse/STORM-1122


Diffs
-

  doc/contributions.txt a8f868007986 
  indra/llwindow/llwindow.cpp a8f868007986 

Diff: http://codereview.secondlife.com/r/245/diff


Testing
---

Useful ways to examine file descriptor usage for the viewer

lsof -c do-not | less

This should be much, much less than 1024
lsof -c do-not | wc -l

This shows all descriptors containing the word 'font' along with the number of 
each (there are tons of duplicates)
lsof -c do-not | egrep -o '[^ ]*font[^ ]*' | sort | uniq -c | less


Thanks,

Discrete

___
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] Linux build without the pausing behaviour

[Discrete Dreamscape]

It's due to libcurl, noted in STORM-809, and supposedly fixed (in the
autobuild repo)? If someone can verify that, maybe you can build it and
solve your problem, otherwise you'll have to build your own libcurl to drop
in. Another alternative seems to be maintaining your own DNS server/cache,
but that's pretty unnecessary IMO.

On Mon, Mar 28, 2011 at 10:50 AM, Francesco Rabbi  wrote:

> Il giorno 28/mar/2011, alle ore 16:41, Mike Chase
>  ha scritto:
>
> > Is there a Linux build of V2 of any version that doesnt exhibit the
> > annoying multi-second pauses that freeze the UI?  I find myself without
> > any useable V2 viewer at present.  I've tried 2.5.2 and 2.6.3 and both
> > still have this issue.
> >
> > How in the world did this every get past QA?  It really renders the
> > viewer unusable. I've been using Imprudence the last few days which is
> > nice but a huge shift in UI and I've actually gotten both used to and
> > productive with the V2 paradigm.
>
> Can you explain better the kind of pause? I don't notice sort of...
>
>
>
> --
> Sent by iPhone
> ___
> 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] Is 'STANDALONE' confusing?

[Discrete Dreamscape]

USE_PREBUILT_LIBS doesn't make absolute sense either if you consider the
fact that your system's libraries are "prebuilt". This would imply that the
inverse of the setting would cause supporting libraries to be built from
source or some such.

I would make it something like "USE_LINDEN_LIBS".


Discrete


On Mon, Feb 21, 2011 at 10:00 AM, Thickbrick Sleaford <
thickbrick.sleaf...@gmail.com> wrote:

> On Monday 21 February 2011 16:38:01 Boroondas Gupte wrote:
> > On 02/21/2011 03:28 PM, Oz Linden (Scott Lawrence) wrote:
> > > If we are going to change it, the replacement term should, in addition
> > > to being more accurately descriptive of what it does, be an affirmative
> > > term - don't suggest any 'NO_*" replacements.
> >
> > Would it be acceptable to invert the setting's semantic in order to
> > avoid a negation? I.e., STANDALONE=OFF would become NEW_SETTING=ON and
> > vice versa. That'd allow for easy-to-understand names like
> > USE_PREBUILD_LIBS or DOWNLOAD_NEEDED_DEPENDENCIES.
> >
> > Off course, the default value should be inverted together with the
> > setting's semantic, such that the default behavior does not change.
> >
>
> I agree with Boroondas. I think it *should* be changed, and my vote goes to
> USE_PREBUILT_LIBS (which should default to on.)
>
>
> --
> Thickbrick
> ___
> 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] Help prevent DOS line endings...

[Discrete Dreamscape]

This is from the help page on the extension:


The optional "[repository]" section specifies the line endings to use for
files stored
in the repository. It has a single setting, "native", which determines the
storage line
endings for files declared as "native" in the "[patterns]" section. It can
be set to
"LF" or "CRLF". The default is "LF". For example, this means that on
Windows, files
configured as "native" ("CRLF" by default) will be converted to "LF" when
stored in the
repository. Files declared as "LF", "CRLF", or "BIN" in the "[patterns]"
section are
always stored as-is in the repository.

Example versioned ".hgeol" file:

  [patterns]
  **.py = native
  **.vcproj = CRLF
  **.txt = native
  Makefile = LF
  **.jpg = BIN

  [repository]
  native = LF


So if a file pattern is specifically declared to have Windows line-endings,
it should remain that way for everyone and in the repository.. probably
worth some quick testing.


Discrete


On Wed, Feb 2, 2011 at 3:06 PM, Oz Linden (Scott Lawrence)  wrote:

> On 2011-02-01 15:33, Discrete Dreamscape wrote:
>
>> Possible cover-all solution: use Mercurial's "eol" extension. It's worked
>> pretty well for me so far, and handily autofixed all the DOS endings in a
>> particular fork I looked at in one go. It works much like the autoprops
>> configuration does in Subversion; hopefully with less pain.
>>
>> Enable it (should be included by default in all recent versions, dunno
>> about Tortoise) by adding the following section and options to your
>> system-wide or repo-local .hgrc file:
>>
>> [extensions]
>> eol =
>>
>> Then add a ".hgeol" file to the root of the repository (it can be
>> versioned and thus easily distributed!), and fill it with whatever standard
>> Mercurial pattern entries are needed, like so:
>>
>> [patterns]
>> **.py = native
>> **.txt = native
>> **.h = native
>> **.cpp = native
>> **Makefile = LF
>>
>> As soon as this file exists and the extension is active for you, further
>> hg commands will immediately treat any non-conforming line-endings as
>> modifications to your current working copy. Hope this is helpful; if so, it
>> could be added to that page as well.
>>
>
> I considered adding that, but didn't know whether some of the
> windows-specific files might be broken by it (if so, they too could be
> configured).   Does anyone know?
>
> Could always put this into a test repo and run a TeamCity build
>
___
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] Help prevent DOS line endings...

[Discrete Dreamscape]

Possible cover-all solution: use Mercurial's "eol" extension. It's worked
pretty well for me so far, and handily autofixed all the DOS endings in a
particular fork I looked at in one go. It works much like the autoprops
configuration does in Subversion; hopefully with less pain.

Enable it (should be included by default in all recent versions, dunno about
Tortoise) by adding the following section and options to your system-wide or
repo-local .hgrc file:

[extensions]
eol =

Then add a ".hgeol" file to the root of the repository (it can be versioned
and thus easily distributed!), and fill it with whatever standard Mercurial
pattern entries are needed, like so:

[patterns]
**.py = native
**.txt = native
**.h = native
**.cpp = native
**Makefile = LF

As soon as this file exists and the extension is active for you, further hg
commands will immediately treat any non-conforming line-endings as
modifications to your current working copy. Hope this is helpful; if so, it
could be added to that page as well.


Discrete


On Tue, Feb 1, 2011 at 1:54 PM, Celierra Darling  wrote:

> For those that have already followed the instructions there - the coding
> standard says to prefer tabs, not spaces, which is the opposite of what the
> page was instructing until just now.
>
> Celi
>
>
> On Tue, Feb 1, 2011 at 7:35 AM, Oz Linden (Scott Lawrence) <
> o...@lindenlab.com> wrote:
>
>> Other than a few files that appear to be completely Windows specific,
>> and I did not know for sure did not require them, I've converted all the
>> DOS line endings in viewer-development back to plain linefeeds.  I'll be
>> checking regularly for any that get added (hopefully before they get
>> into the main repo) and advising the perpetrators of the error of their
>> ways...
>>
>> So that I have a resource to direct them to, and to help prevent any new
>> developers from committing this minor sin, we need a set of clear
>> instructions on what Windows tools do this correctly and how to
>> configure them to do so.   Please help by adding to:
>>
>>
>> https://wiki.secondlife.com/wiki/How_to_avoid_DOS_line_endings_in_Windows_tools
>>
>> ___
>> 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] Malicious payloads in third-party viewers: is the policy worth anything?

[Discrete Dreamscape]

I don't care if it's relevant; it should still be clarified. "Did
nobody think?" Of course not, nobody knew he would actually go through
with something like that.


Discrete


On Aug 21, 2010, at 11:31 AM, Katharine Berry
 wrote:

>> 2) The active developer of a malicious viewer under the lolguise of
>> promoting exploit/bugfixing.
>
> As I have pointed out elsewhere – I don't think that anyone was actually 
> considering the target to be terribly virtuous. I also don't think this is 
> terribly relevant.
>
> But given you repeatedly emphasise that he is malicious, did nobody think 
> that it might be unwise to secretly load a website owned by a malicious party 
> on login? Aside from WebKit/Qt exploits and the like, the SL client also 
> considers the login frame to be "trusted" (admittedly, there's not much you 
> can do with this before logging in besides changing the login location, off 
> the top of my head).
___
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] Malicious payloads in third-party viewers: is the policy worth anything?

[Discrete Dreamscape]

Actually, I prefer to remember him as:

1) The guy who hacked Emerald's servers before discovering the data
storage issue and

2) The active developer of a malicious viewer under the lolguise of
promoting exploit/bugfixing.

But hey, they keep antagonizing him, so of course this kind of thing continues.


Discrete


On Aug 21, 2010, at 11:10 AM, Brian McGroarty  wrote:

> On Sat, Aug 21, 2010 at 7:46 AM, Discrete Dreamscape
>  wrote:
>> This was one person's decision, and was deliberately done for the sole
>> purpose of messing with the owner of the victim site (although I'd
>> hardly call the particular individual a victim). Regardless, the team
>> was pretty disappointed. The one person currently owns all parts of
>> Emerald's hosting, so it was their decision, albeit a ridiculous one.
>> They don't take the project seriously, and it's more than a little
>> embarrassing to the rest of the people associated with the team that
>> this kind of thing keeps happening, over and over again.
>
> Appreciated - it's helpful to have this put plainly and publicly.
>
> Am I right that the target server belongs to the guy who:
>
> 1) Was interviewed in a previous blog write-up about the IP & username
> database and geolocation tool that he sought to show was built up for
> Emerald Point visitors, Insilico visitors, and people creating
> accounts via the Modular Systems website?
>
> 2) Demonstrated that Emerald wasn't removing usernames from paths
> before embedding them in textures even after the team's first
> attempted fix?
>
> I know we already talked to the team and set some conditions after the
> first one. The second one's been explained as a mistake that Modular
> Systems would be willing to publicly acknowledge and correct - the
> potential for collecting usernames would have to be in the viewer's
> privacy policy otherwise, and it isn't to date. But that one of these
> incidents was history and the second was supposed to be a mistake made
> the hidden request activity all the more confusing.
>
> --
> Brian McGroarty | Linden Lab
> Sent from my Newton MP2100 via acoustic coupler
___
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] Malicious payloads in third-party viewers: is the policy worth anything?

[Discrete Dreamscape]

This was one person's decision, and was deliberately done for the sole
purpose of messing with the owner of the victim site (although I'd
hardly call the particular individual a victim). Regardless, the team
was pretty disappointed. The one person currently owns all parts of
Emerald's hosting, so it was their decision, albeit a ridiculous one.
They don't take the project seriously, and it's more than a little
embarrassing to the rest of the people associated with the team that
this kind of thing keeps happening, over and over again.


Discrete


On Aug 21, 2010, at 10:33 AM, Brian McGroarty  wrote:

> On Sat, Aug 21, 2010 at 7:04 AM, Thomas Grimshaw  wrote:
>>  Loading 1mb of content per user is hardly a denial of service attack.
>> Crosslinking occurs everywhere on the web, this is simply nothing but
>> paranoid bull.
>
> "Crosslinking" drops the context of hiding gibberish requests to a
> critic's website in a hidden frame that will never be revealed to the
> user. This isn't a mere hyperlink to another page or naively stealing
> someone else's image hosting.
>
> My read (but I'm no lawyer) is that this looks like 2.d.iii of
> http://secondlife.com/corporate/tpv.php and we're already having that
> discussion. If anyone can come up with specific reasons why this might
> have had legitimate reason to be there, or how this one could be yet
> another oversight or mistake, that would be helpful. I sure haven't
> heard any to date.
>
> --
> Brian McGroarty | Linden Lab
> Sent from my Newton MP2100 via acoustic coupler
> ___
> 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] Viewer blacklist to replace the TPV

[Discrete Dreamscape]

I'd like to remark that the information you found is just the data of the
ModularSystems website, and all of the other viewer directory listings look
about the same as Emerald's. The actual real-life name(s) of people involved
aren't required to be publicly viewable, but Linden Lab does have them.
Also, consider the possibility that .sl was chosen as a domain because it
could be an abbreviation for SecondLife. Cute, eh?

I seriously doubt anyone with malicious intent is going to bother trying to
register their viewer in the directory.

On Thu, Apr 29, 2010 at 8:38 PM, Boy Lane  wrote:

> We certainly should follow the bright example of Emerald / Modularsystems,
> where you Discrete are a member of. A pseudo company set up and owned
> by known banned griefer JCool aka who revived his banned account(s) under
> the names of Fractured Crystal/Fractured Modularsystems.
>
> Back to their registration. JCool set up Modularsystems. A mailbox company
> with the following contact details:
>
> http://modularsystems.sl/
> P.O. Box 5702
> West Columbia, South Carolina 29171-5702
> United States
> administra...@modularsystems.sl
>
> That is an untraceable anonymized entity without any name attached to it
> and
> unknown legal status, registered with a domain name in Sierra Leone, a
> country
> that does not even have a WHOIS.
>
> This information was used to register and self-certify Emerald in the
> Viewer
> Directory.
>
> As I as a legally uniformed hobby programmer without commercial interest
> can
> evaluate this situation and validity of the Emerald listing, it is meant to
> circumvent
> any means of the viewer directory to hold a developer accountable for their
> viewers. It is also meant to avoid any possible litigation from LL in case
> indeed
> some malicious code may be found in their viewer(s). Besides Emerald,
> Modularsystems
> also develops and uses a malicious viewer named "Onyx" that is in clear
> violation of
> ToS/TPV.
>
> So no, Discrete, all these things completely contradict your argument. As
> shown a
> listing in Lindens viewer directory doesn't add a single piece of safety or
> security. To
> look for a legitimate viewer the Alternate Viewer list in the community
> edited SL Wiki
> is a better place to, for the simple reason malicious clients may not
> easily
> slip in as
> this is possible with self-certification. A blacklist is a good thing and
> could at least
> complement Viewer Directory and Alternate Viewers list. But of course it
> would
> include most of the malicious viewer from the key developers behind
> Modularsystems
> which obviously you try to avoid.
>
> Additional question to Linden Lab: How can for repeated ToS violations
> permanently
> banned people just circumvent that ban by creating new accounts as many of
> the
> Emerald developers did? Is it money spent for SL that counts rather than
> ToS?
>
> Boy
>
> - Original Message - > Date: Thu, 29 Apr 2010 16:39:16 -0400
> > From: Discrete Dreamscape 
> > Subject: Re: [opensource-dev] Viewer blacklist to replace the TPV
> > directory ?
> > To: Tigro Spottystripes 
> > Cc: opensource-dev@lists.secondlife.com
> > Message-ID:
> > 
> > Content-Type: text/plain; charset="utf-8"
> >
> > This discussion seems to have been created with misleading intentions.
> >
> > Because some TPV creators don't want to reveal any personal information
> > about themselves, they can't be posted on the TPV directory, and because
> > of
> > this, it's understandable they might view the directory as unfair. But,
> > this
> > doesn't strike me as a valid reason to criticize the list.
> >
> > It's certainly valid to say that the viewers on the list are not
> > absolutely
> > trustworthy unless a full code audit is done, but even then, do you
> really
> > know that what's in the code is the same as what's in the binary? Isn't
> > there a limit to what LL can do, given a lack of resources to perform
> such
> > audits, especially when what you download requires trust that it's the
> > same
> > as what they've audited?
> >
> > But really, trust is supposed to be provided by the fact that the viewer
> > has
> > indeed registered using real-life contact information, because who would
> > give such a thing knowing they could be held liable if they indeed
> decided
> > to include malicious code? In general, there is no way to certify purity
> > here, you can only provide a level of trust as a guideline. You can't
> rely
> > on babysitting the users, because LL i

Re: [opensource-dev] Viewer blacklist to replace the TPV directory ?

[Discrete Dreamscape]

This discussion seems to have been created with misleading intentions.

Because some TPV creators don't want to reveal any personal information
about themselves, they can't be posted on the TPV directory, and because of
this, it's understandable they might view the directory as unfair. But, this
doesn't strike me as a valid reason to criticize the list.

It's certainly valid to say that the viewers on the list are not absolutely
trustworthy unless a full code audit is done, but even then, do you really
know that what's in the code is the same as what's in the binary? Isn't
there a limit to what LL can do, given a lack of resources to perform such
audits, especially when what you download requires trust that it's the same
as what they've audited?

But really, trust is supposed to be provided by the fact that the viewer has
indeed registered using real-life contact information, because who would
give such a thing knowing they could be held liable if they indeed decided
to include malicious code? In general, there is no way to certify purity
here, you can only provide a level of trust as a guideline. You can't rely
on babysitting the users, because LL isn't going to compile every third
party's code and release the binaries themselves.

In this regard, you may begin to argue that indeed, a blacklist would better
serve users. I argue that this is exactly the opposite. You may be able to
pick out which viewers are explicitly untrusted, but you make no statements
about the trustworthiness of any others. In this situation, a user is left
to choose between either a viewer which is in the grey about its status, or
an official Linden viewer. This point is key, as far less warranty is
provided for users that they won't be banned for using a third party viewer.
I suspect that in this case, many would simply give up and use the official
client rather than risk their business, etc.

If you want to provide a system where users can trust the clients they use,
it seems like our current one is decent enough. In any case, a blacklist
doesn't appear to be any safer.

Discrete

On Thu, Apr 29, 2010 at 4:02 PM, Tigro Spottystripes <
tigrospottystri...@gmail.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> the disclaimer instead of being hidden in small print in the bottom
> should be the first thing in the page, in big bold red font, to at least
> start helping users be less confused about how much trust they should
> put on the viewers listed
>
> On 29/4/2010 16:35, Kitty wrote:
> >
> >
> 
> > *From:* opensource-dev-boun...@lists.secondlife.com
> > [mailto:opensource-dev-boun...@lists.secondlife.com] *On Behalf Of
> > *Ron Festa
> > *Sent:* Thursday, April 29 2010 20:27
> > *To:* Henri Beauchamp
> > *Cc:* opensource-dev@lists.secondlife.com
> > *Subject:* Re: [opensource-dev] Viewer blacklist to replace the TPV
> > directory ?
> >
> > Despite claiming the list is Self-Certified those viewers on the
> > list still had to have their viewer reviewed by LL before being
> > listed so really all the TPV's on the TPV Directory are Certified by
> > LL ensuring they comply with their standards & policies.
> >
> > - release a viewer that's the LL source + a handful of innocent patches
> > - apply for the directory and get listed
> > - release a new viewer
> >
> > The last step doesn't invalidate the current listing as far as I know so
> > I really don't see how the viewer directory could possibly be stamped as
> > "reviewed by LL" by any stretch, let alone go as far as claiming that
> > they're "certified by LL" as compliant.
> >
> > Since the reason for the directory is really end-user assurance the
> > viewer directory doesn't really work in that sense because it doesn't
> > actually offer much: LL still reserves the right to ban anyone just for
> > using any third party viewer (whether listed or unlisted).
> >
> > With all the threatening (whether intended or not) language in blog
> > posts or emails a lot of people are going by the assumption that
> > "listed" means "I won't get banned" or that it means
> > "approved/sanctioned/verified/vouched for by LL" but that's just not the
> > case. It would be a lot better for any resident wanting to use any third
> > party viewer to at least know that if they go by the list that their
> > account isn't in jeopardy (no matter how unlikely a ban might be) for as
> > long as that viewer is listed.
> >
> > For better or worse the perception that the viewer directory is a
> > "safelist" is already there now, in spite of any disclaimers on that
> > same page, and it's too late to still reverse that. Personally it seems
> > best if the directory just officially became a "safelist". If a
> > malicious viewer ever makes the list then that wouldn't
> > undermine people's trust in any other listed viewer because LL would
> > guarantee that any viewer they list is in

Re: [opensource-dev] Viewer blacklist to replace the TPV directory ?

[Discrete Dreamscape]

That's right. However, note what I implied: a blacklist would be worse by
misleading users even more, and it would discourage TPV usage in general.

On Thu, Apr 29, 2010 at 3:54 PM, Tigro Spottystripes <
tigrospottystri...@gmail.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Discrete, in both ways you can have viewers that the users think can be
> trusted, but actually shouldn't
>
> On 29/4/2010 15:04, Discrete Dreamscape wrote:
> > A list of trusted entities is virtually always more robust and reliable
> > than a list of untrusted ones.
> >
> > Weigh the two possibilities that would occur and their consequences,
> > given that the user is making assumptions, as you say:
> > - User believes viewers ON the whitelist are the ONLY ones that can be
> used
> > - User believes viewers NOT on the blacklist can ALL be used
> >
> > The latter is clearly not a situation that benefits users in any way.
> >
> > Discrete
> >
> > On Thu, Apr 29, 2010 at 1:59 PM, Henri Beauchamp  > <mailto:sl...@free.fr>> wrote:
> >
> > On Thu, 29 Apr 2010 05:40:15 -0700 (PDT), Nicky Perian wrote:
> >
> > > +1
> > > A blacklist would just give potential bad actors a menu and
> > > template to use for more bad viewers that could be modified and get
> > > past the login screens.
> >
> > What you must understand is that the TPV policy is in no way a mean
> > to prevent pirates from connecting to SL with hacked viewers (or
> > through hacked proxies)...
> > All what pirates have to do is to make sure these viewers impersonate
> > an official (Linden) one (which is done very simply) and then they
> can
> > pursue their illegal activity without even being spotted...
> >
> > The TPV policy might give some better ground to LL to sue such
> pirates
> > when they are lucky enough to spot and trace one, but the true aim of
> > the TPV is to set acceptable standards for non-hacked viewers as well
> > as to provide their user with some minimum confidence that such
> viewers
> > will not try to steal their private data or put them into troubles.
> >
> > As such, the blacklist would provide a much better service to the
> users
> > by clearly identifying viewers which are *known* to be not compliant.
> >
> > With the current directory, you only got a *partial* list of
> *possibly*
> > compliant viewers (without any guarantee from LL) and know nothing at
> > all about non-listed viewers.
> >
> > 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
> >
> >
> >
> >
> > ___
> > 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.14 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEUEAREKAAYFAkvZ5A4ACgkQ8ZFfSrFHsmXOBQCfcpptZyKU+Tr1uv+FsJVUj04s
> 6c8AmPF6F2bQpBxhVHCTLY4yrcC38sM=
> =Cbvj
> -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
>
___
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] Viewer blacklist to replace the TPV directory ?

[Discrete Dreamscape]

Users could then assume all unlisted viewers are safe enough for use, which
is far more misleading than assuming a specific few are safe. A few who are
both known and have contact information on file, no less. If they don't make
this assumption, an action which any smart user should choose, then in
general no third party viewers would be trusted and used.

If you want a blacklist, there's already an informal one at
http://onyx.modularsystems.sl/viewer_reference.html .

On Thu, Apr 29, 2010 at 2:09 PM, Henri Beauchamp  wrote:

> On Thu, 29 Apr 2010 14:04:21 -0400, Discrete Dreamscape wrote:
>
> > A list of trusted entities is virtually always more robust and reliable
> than
> > a list of untrusted ones.
>
> This would be only true if LL was to *guarantee* that the listed viewer
> can *actually* be trusted, which is *not* the case with the current
> implementation of teh TPV directory.
>
> > Weigh the two possibilities that would occur and their consequences,
> given
> > that the user is making assumptions, as you say:
> > - User believes viewers ON the whitelist are the ONLY ones that can be
> used
> > - User believes viewers NOT on the blacklist can ALL be used
> >
> > The latter is clearly not a situation that benefits users in any way.
>
> Not when the blacklist in question is edited by LL themselves: you then
> are sure that the listed viewers are illegal, which gives more reliable
> info than an unwarranted white list...
>
> 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
>
___
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] Viewer blacklist to replace the TPV directory ?

[Discrete Dreamscape]

A list of trusted entities is virtually always more robust and reliable than
a list of untrusted ones.

Weigh the two possibilities that would occur and their consequences, given
that the user is making assumptions, as you say:
- User believes viewers ON the whitelist are the ONLY ones that can be used
- User believes viewers NOT on the blacklist can ALL be used

The latter is clearly not a situation that benefits users in any way.

Discrete

On Thu, Apr 29, 2010 at 1:59 PM, Henri Beauchamp  wrote:

> On Thu, 29 Apr 2010 05:40:15 -0700 (PDT), Nicky Perian wrote:
>
> > +1
> > A blacklist would just give potential bad actors a menu and
> > template to use for more bad viewers that could be modified and get
> > past the login screens.
>
> What you must understand is that the TPV policy is in no way a mean
> to prevent pirates from connecting to SL with hacked viewers (or
> through hacked proxies)...
> All what pirates have to do is to make sure these viewers impersonate
> an official (Linden) one (which is done very simply) and then they can
> pursue their illegal activity without even being spotted...
>
> The TPV policy might give some better ground to LL to sue such pirates
> when they are lucky enough to spot and trace one, but the true aim of
> the TPV is to set acceptable standards for non-hacked viewers as well
> as to provide their user with some minimum confidence that such viewers
> will not try to steal their private data or put them into troubles.
>
> As such, the blacklist would provide a much better service to the users
> by clearly identifying viewers which are *known* to be not compliant.
>
> With the current directory, you only got a *partial* list of *possibly*
> compliant viewers (without any guarantee from LL) and know nothing at
> all about non-listed viewers.
>
> 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
>
___
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] Quiet amendments of TPV (again)

[Discrete Dreamscape]

Agreed, this is a major improvement.

Thanks, Joe.

On Tue, Apr 20, 2010 at 10:12 AM, Latif Khalifa wrote:

> I second that Gigs, very positive changes indeed.
>
> My thanks to Joe for making this happen.
>
> Latif
>
>
> On Tue, Apr 20, 2010 at 4:10 PM, Gigs  wrote:
> > These look like positive changes that address some of the concerns.
> >
> > Thank you for your efforts Joe.
> >
> > Joe Linden wrote:
> >> Boy,
> >>
> >> There was nothing quiet, or "in the background" about it, believe me.
> >> This update is the topic of conversation at the noon PDT brown bag I'm
> >> hosting today.  The changes were pushed live ahead of the meeting, so
> >> there would be no question they are incorporated in to the TPV and TOS,
> >> both of which are effective on 4/30.
> >>
> >> I'll see those of you still interested in the subject at noon here:
> >>
> http://maps.secondlife.com/secondlife/Linden%20Estate%20Services/229/230/29
> >>
> >> -- joe
> >>
> > ___
> > 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] Requesting Linden Response: Please move TPVPTopics to a different mailing list

[Discrete Dreamscape]

These comments are beginning to seem rather like pure speculation. If you're
concerned about your project or your liabilities, I recommend consulting
with someone from LL or with your lawyer.

Anyhow, the discussion at hand could use some more focus on what further
modifications would be appreciated in the TPVp pending further discussions
with Joe.

On Thu, Apr 15, 2010 at 5:24 PM, VR Hacks  wrote:

> Michael wrote in part (full off-list comment is included below sig):
>
> > That means that you can write and distribute anything you please, but if
> > you connect to the grid with something like NeilLife and you get caught
> > doing it then you will loose your account.
>
> Yup, something to that effect.
>
> > I mean you can't legally be held liable for users who refuse to follow a
> > contract they made with you, can you?
>
> Sure you can. After all, if you write malicious code, you know you're doing
> it. So, if you choose to distribute that code that allows connection to the
> grid, and even if you included a "connect to the grid at your own risk"
> clause in your EULA, it could easily be shown in a court of law that you
> were attempting to circumvent the lab's TPV policy. In fact, if anything,
> such a clause in the EULA would clearly indicate that you know you're
> distributing a non-compliant viewer for connecting to the SL grid. Again,
> this would only apply if you provided a means for your viewer to connect to
> the SL grid.
>
> Angela Talamasca (in-world)
> MA Forensic Psychology
>
> 
> VR Hacks Blog: http://bit.ly/VRHacksBlog
> VR Hacks Twitter: http://bit.ly/VRHacksTwitter
> VR Hacks YouTube: http://bit.ly/VRHacksYouTube
> Digital DNA in SL: http://bit.ly/VRHacksSLmap
> Digital DNA in Blue Mars: http://bit.ly/BMclient
> --
> "Ordinary riches can be stolen, real riches cannot. In your soul are
> infinitely precious things that cannot be taken from you." - Oscar Wilde
>
>
> Angela Talamasca (in-world)
> MA Forensic Psychology
>
> 
> VR Hacks Blog: http://bit.ly/VRHacksBlog
> VR Hacks Twitter: http://bit.ly/VRHacksTwitter
> VR Hacks YouTube: http://bit.ly/VRHacksYouTube
> Digital DNA in SL: http://bit.ly/VRHacksSLmap
> Digital DNA in Blue Mars: http://bit.ly/BMclient
> --
> "Ordinary riches can be stolen, real riches cannot. In your soul are
> infinitely precious things that cannot be taken from you." - Oscar Wilde
>
> - Original Message -
> From: "Michael Daniel" 
> To: "VR Hacks" 
> Sent: Thursday, April 15, 2010 1:38 PM
> Subject: Re: [opensource-dev] Requesting Linden Response: Please move
> TPVPTopics to a different mailing list
>
>
> >I know many others have looked at this, but to me the important part of
> the
> >policy is this:
> >
> > "This Policy does not place any restriction on modification or use of our
> > viewer source code 
> > that we make available under the GPL
> > <
> http://secondlifegrid.net/technology-programs/license-virtual-world/viewerlicensing/gplv2
> >.
> > Rather, the Policy sets out requirements for connecting to our Second
> Life
> > service using a Third-Party Viewer, regardless of the viewer source code
> > used, and for participating in our Viewer Directory
> > ."
> >
> > That means that you can write and distribute anything you please, but if
> > you connect to the grid with something like NeilLife and you get caught
> > doing it then you will loose your account.
> >
> > If you don't want the liability just toss something in the EULA for your
> > users that makes them agree to not use your TPV to connect to SL and
> > you're covered, I think.  I'm pretty sure that counts as due dilligance.
> > I mean you can't legally be held liable for users who refuse to follow a
> > contract they made with you, can you?
> >
> > Again, I'm not a lawyer.
> >
> > ~Bubblesort
> >
> >
> > VR Hacks wrote:
> >> Tigro Spottystripes
> >>
> >>
> >>> Why developers for other grids would need to do any changes on their
> >>> code? And why can't a SL resident develop clients for other grids while
> >>> keeping their SL accounts safe without being forced to jump thru hoops?
> >>>
> >>
> >> For argument's sake, let's say I, as an SL user, choose to extend the
> >> linden lab viewer code base to access, say, reaction grid. Let's also
> say
> >> that I do wish to agree to the TPV policy for my code. In other words,
> >> say, I want to include functionality that is allowable on that grid but
> >> not allowable on the SL grid. It is then my "responsibility" to create
> my
> >> viewer such that the option for connecting to the SL grid is not
> >> available without some sort of code change. At which point I can deploy
> >> my code.
> >>
> >> Of course, I still plan to access the second life grid. In order to do
> >> so, I cannot use my viewer. Rather, I must use a viewer that was
> >> developed by som

Re: [opensource-dev] Requesting Linden Response: Please move TPVPTopics to a different mailing list

[Discrete Dreamscape]

Devs for other grids that don't need to agree to LL's policy probably
wouldn't have anything to worry about at all, especially if they included
EULAs with the right terms. As for residents, I wouldn't say their account
becomes 'unsafe.' However, my (emphasis on my) interpretation of the policy
is that you would be "responsible" (read: liable) to LL for the results of
your code.

On Thu, Apr 15, 2010 at 4:03 PM, Tigro Spottystripes <
tigrospottystri...@gmail.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Why developers for other grids would need to do any changes on their
> code? And why can't a SL resident develop clients for other grids while
> keeping their SL accounts safe without being forced to jump thru hoops?
>
> On 15/4/2010 17:00, Discrete Dreamscape wrote:
> > I would assume that, to be more detailed, your code would either not
> > allow connections to the LL grid, or you would have to decline the
> > updated ToS/TPVp, thus not agreeing to be bound to it but also
> > preventing you from using the LL grid yourself.
> >
> > On Thu, Apr 15, 2010 at 3:58 PM, Tigro Spottystripes
> > mailto:tigrospottystri...@gmail.com>>
> wrote:
> >
> > So any developer not willing to abide by the TPVp can simply say their
> > viewer is not meant for LL's grid and that is it?
> >
> > On 15/4/2010 16:54, VR Hacks wrote:
> >> Tigro wrote:
> >
> >>> What if the developer develops a viewer for other grids?
> >
> >> Then the TPV policy does not apply to them. Though, again, and
> > imo, it would
> >> still be prudent for them to include a EULA with their binary
> > distribution.
> >> And, of course, if their code is extending GPL code, they must
> > retain said
> >> GPL with the souce code distribution.
> >
> >> Angela Talamasca (in-world)
> >> MA Forensic Psychology
> >
> >> 
> >> VR Hacks Blog: http://bit.ly/VRHacksBlog
> >> VR Hacks Twitter: http://bit.ly/VRHacksTwitter
> >> VR Hacks YouTube: http://bit.ly/VRHacksYouTube
> >> Digital DNA in SL: http://bit.ly/VRHacksSLmap
> >> Digital DNA in Blue Mars: http://bit.ly/BMclient
> >> --
> >> "Ordinary riches can be stolen, real riches cannot. In your soul are
> >> infinitely precious things that cannot be taken from you." - Oscar
> > Wilde
> >
> >> ___
> >> 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/
>
> iEYEARECAAYFAkvHcSEACgkQ8ZFfSrFHsmXSNQCfdYb7Oshh7XjnJh8D3a+2UjGB
> uLcAniiljZlImaLgf2MBhyZWbQO/Hd42
> =HZCv
> -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] Requesting Linden Response: Please move TPVPTopics to a different mailing list

[Discrete Dreamscape]

I would assume that, to be more detailed, your code would either not allow
connections to the LL grid, or you would have to decline the updated
ToS/TPVp, thus not agreeing to be bound to it but also preventing you from
using the LL grid yourself.

On Thu, Apr 15, 2010 at 3:58 PM, Tigro Spottystripes <
tigrospottystri...@gmail.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> So any developer not willing to abide by the TPVp can simply say their
> viewer is not meant for LL's grid and that is it?
>
> On 15/4/2010 16:54, VR Hacks wrote:
> > Tigro wrote:
> >
> >> What if the developer develops a viewer for other grids?
> >
> > Then the TPV policy does not apply to them. Though, again, and imo, it
> would
> > still be prudent for them to include a EULA with their binary
> distribution.
> > And, of course, if their code is extending GPL code, they must retain
> said
> > GPL with the souce code distribution.
> >
> > Angela Talamasca (in-world)
> > MA Forensic Psychology
> >
> > 
> > VR Hacks Blog: http://bit.ly/VRHacksBlog
> > VR Hacks Twitter: http://bit.ly/VRHacksTwitter
> > VR Hacks YouTube: http://bit.ly/VRHacksYouTube
> > Digital DNA in SL: http://bit.ly/VRHacksSLmap
> > Digital DNA in Blue Mars: http://bit.ly/BMclient
> > --
> > "Ordinary riches can be stolen, real riches cannot. In your soul are
> > infinitely precious things that cannot be taken from you." - Oscar Wilde
> >
> > ___
> > 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/
>
> iEYEARECAAYFAkvHb8wACgkQ8ZFfSrFHsmWpPwCeMIV18rdRa3EPca4SGEAPENbm
> HU0An2JEkCBTgZ7mO7ccPACDcsswBHCa
> =yy0t
> -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
>
___
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] Requesting Linden Response: Please move TPVP Topics to a different mailing list

[Discrete Dreamscape]

"Many coders would likely accept liability when being paid well, or possibly
at all. But in the case of open source code created as a hobby, the GPL idea
of no warranty has so far been successful in the community because code can
be inspected by its users, and because the users can verify, alter, and fix
any problems in it on their own, so they shouldn't claim fault on the
developer when it was their own choice to use the code. However, in LL's
case, they don't even get to choose whether they use your code. Anyone can
basically force it upon their service to feel the effects of using arbitrary
viewer code. Thus, since there is no choice, ultimately some liability is
inherent."

Basically, consent does agree on both sides. LL is forced into the situation
by the nature of their service, and starting April 30th, developers consent
as well, if they wish to use the service.

On Thu, Apr 15, 2010 at 11:57 AM, Gareth Nelson wrote:

> The problem with that is a contract requires assent on both sides
>
> On Thu, Apr 15, 2010 at 4:47 PM, Discrete Dreamscape
>  wrote:
> > It's possible to willingly agree to liability and wave whatever
> protections
> > you wish that are normally under the GPL, which seems to be what the TPV
> > asks you to do. The issue most people seem to have is that it's not
> explicit
> > in this regard and it also doesn't make it clear that it is a contract
> > between you and LL.
> >
> > On Thu, Apr 15, 2010 at 11:42 AM, Tigro Spottystripes
> >  wrote:
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> from what i understand, according to GPL, developers and distributers of
> >> GPL'd stuff are _*NOT*_ liable for any GPL code they create, modify or
> >> distribute
> >>
> >> On 15/4/2010 12:28, Robert Martin wrote:
> >> > On Thu, Apr 15, 2010 at 11:01 AM, Gareth Nelson
> >> >  wrote:
> >> >> A quick note on that - this is not the whole meeting, some of the
> >> >> start was missing
> >> >>
> >> > suggestion for the next meeting MAKE IT TEXT CHAT ONLY.
> >> > how much of the meeting was lost to overhead related to voice links
> >> > getting garbled or relaying info being given in voice or a client
> >> > crashing or ...
> >> >
> >> > anyway i think that the core problem of the current TPVp is not
> >> > limiting the liability of a developer to 1 code he changed 2 fixing
> >> > bugs in said code so
> >> >
> >> > LL is only liable for Linden Core Code*
> >> > a TPV is only liable for code changed from LLC**
> >> > a user is liable for actions on the grid (and whatever changes done to
> >> > either LLC or TP code)
> >> -BEGIN PGP SIGNATURE-
> >> Version: GnuPG v2.0.12 (MingW32)
> >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >>
> >> iEYEARECAAYFAkvHM9UACgkQ8ZFfSrFHsmUi3gCdF9rXeLoWwsxEF1bwaXjSeqmV
> >> jWsAn3i1Dpa0KjNrokHYukjq4YONoGcm
> >> =t1M5
> >> -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
> >
> >
> > ___
> > 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] Requesting Linden Response: Please move TPVP Topics to a different mailing list

[Discrete Dreamscape]

It's possible to willingly agree to liability and wave whatever protections
you wish that are normally under the GPL, which seems to be what the TPV
asks you to do. The issue most people seem to have is that it's not explicit
in this regard and it also doesn't make it clear that it is a contract
between you and LL.

On Thu, Apr 15, 2010 at 11:42 AM, Tigro Spottystripes <
tigrospottystri...@gmail.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> from what i understand, according to GPL, developers and distributers of
> GPL'd stuff are _*NOT*_ liable for any GPL code they create, modify or
> distribute
>
> On 15/4/2010 12:28, Robert Martin wrote:
> > On Thu, Apr 15, 2010 at 11:01 AM, Gareth Nelson 
> wrote:
> >> A quick note on that - this is not the whole meeting, some of the
> >> start was missing
> >>
> > suggestion for the next meeting MAKE IT TEXT CHAT ONLY.
> > how much of the meeting was lost to overhead related to voice links
> > getting garbled or relaying info being given in voice or a client
> > crashing or ...
> >
> > anyway i think that the core problem of the current TPVp is not
> > limiting the liability of a developer to 1 code he changed 2 fixing
> > bugs in said code so
> >
> > LL is only liable for Linden Core Code*
> > a TPV is only liable for code changed from LLC**
> > a user is liable for actions on the grid (and whatever changes done to
> > either LLC or TP code)
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkvHM9UACgkQ8ZFfSrFHsmUi3gCdF9rXeLoWwsxEF1bwaXjSeqmV
> jWsAn3i1Dpa0KjNrokHYukjq4YONoGcm
> =t1M5
> -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
>
___
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] oh give me a break

[Discrete Dreamscape]

You can find grids exactly like you want already, but they have online
concurrencies that can be counted on one hand and are slow as molasses, plus
no one makes any content there for exactly the reasons you would like to use
them.

It would be narrow-minded to think that open source is the only business
model that should ever be employed, especially when the existing models
produce livable income for only a small percentage of the Linden grid.

On Sun, Mar 14, 2010 at 6:39 PM, New Hax  wrote:

> agree to disagree yea but then your days are numbered in SL. If the
> project forks then there will be a VW without all these restrictions
> and lindens threatening people for asking them to keep their promises?
>
> On 3/14/10, New Hax  wrote:
> > I want a grid where people can have the freedom to develop what they
> > want and do what they want, without being told whats allowed, and
> > without being watched because you might move the wrong bits from one
> > place to another. and without lindens threatening if we dont "play
> > nice" with draconinan DRM. That was what i hoped the spirit of Open
> > source SL would be. but i guess im wrong.
> >
> >
> > On 3/14/10, Glen Canaday  wrote:
> >> Then what are you doing here?
> >>
> >> On 03/14/2010 06:32 PM, New Hax wrote:
> >>> I know better than to try to get rich off of selling ones and zeroes.
> >>>
> >>> On 3/14/10, Glen Canaday  wrote:
> >>>
>  Then what are you doing in SL? Not making a living, I can assure you.
> 
>  Nor are you putting food on the table RL except perhaps by manual
>  labor,
>  which cannot be copied. Ex: Ditches need to be dug. The ditch-digger
>  can
>  be changed out, but that doesn't change the fact that even if you get
> a
>  new digger, you still have a ditch when you're done.
> 
>  OSS/Free Software and Proprietary software are the diggers; they're
> not
>  the ditch itself.
> 
>  On 03/14/2010 06:18 PM, New Hax wrote:
> 
> > then what are you doing on an opensource list if you want your
> content
> > wrapped in DRM.
> >
> > sl will die if its not open. and you can't compare rl doors to the
> > internet. if you dont lock your rl door I can come in and take
> > something of yours that isnt replaceable.
> >
> > but on the internet as a content maker you can make INFINITE products
> > so you arent losing anything if i copy it and make no money off of
> it.
> >
> >
> > On 3/14/10, Marine Kelley   wrote:
> >
> >
> >> well I am a content creator, content theft is a problem to me, it is
> >> tied
> >> to
> >> IP rights which are a legal issue. And I am not one of those who say
> >> "content theft is inevitable, let's not do anything about it". Doors
> >> can
> >> be
> >> lock picked, that's not a reason for me to leave my door wide open.
> >>
> >>
> >> On 14 March 2010 23:04, New Hax   wrote:
> >>
> >>
> >>
> >>> On 3/14/10, Marine Kelley   wrote:
> >>>
> >>>
>  Err... Content theft has always been a problem, will always be a
>  problem,
>  and LL better be on the same page with developers, content makers
>  and
>  customers here.
> 
> 
> >>> content theft isn't a problem, never has been a problem, and is the
> >>> nature of the internet and digital things.  if content makers are
> >>> worried about content "theft" then they shouldn't be on SL. because
> >>> its inevitable and cant be stopped.
> >>>
> >>>
> >>>
> >>
> > ___
> > 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
> >>
> >
> ___
> 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