From cjac at colliertech.org Fri Feb 5 10:35:26 2010 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Fri, 05 Feb 2010 10:35:26 -0800 Subject: [opensource-dev] Ohai! Message-ID: <1265394926.15384.2.camel@calcifer> I don't recall signing up for this list, but I'm happy to be here. If nobody else takes credit, I'll blame robla. I haven't done anything with SL in a while... busy with school and work. Speaking of school, I'm attending classes with a focus on computational linguistics. There has been some discussion among the members of the department regarding the use of language processing in massively multiplayer games, and even some discussion about writing some libs in C#. Since I'm a Mono dev, I'll be sure that all of the stuff works on that platform. But for now, I've got to run to the U and get to studying Lushootseed. Cheers, C.J. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100205/b1afe516/attachment.pgp From kakurady at gmail.com Fri Feb 5 11:09:38 2010 From: kakurady at gmail.com (Kakurady Drakenar) Date: Fri, 5 Feb 2010 14:09:38 -0500 Subject: [opensource-dev] What's with the rename? Message-ID: <21b2f1351002051109t3ee6b955h681109296cdaceca@mail.gmail.com> I don't like the name "opensource-dev". The old name, SLDev, fits just well - it was about people getting together developing Second Life-related stuff. Now what are we developing? "Open Source"? That's a slogan, it does not manifest as anything, like an actual virtual world. Not to mention that, since there are so many Free Software and Open Source projects in the world, naming the list "opensource-dev" will only serve to confuse people. Some may say it's no longer fitting as the community developers' focus have shifted from the mainline Second Life client to Snowglobe, but it's still a Second Life client, so SLDev is still a good candidate for the name of the mailing list. If you guys really don't like it, I propose this list be named "sl-client-dev", or "hippo-hackers". Kakurady (Geneko Nemeth) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100205/b5f3d0ea/attachment.htm From kakurady at gmail.com Fri Feb 5 11:13:51 2010 From: kakurady at gmail.com (Kakurady Drakenar) Date: Fri, 5 Feb 2010 14:13:51 -0500 Subject: [opensource-dev] What's with the rename? In-Reply-To: <21b2f1351002051109t3ee6b955h681109296cdaceca@mail.gmail.com> References: <21b2f1351002051109t3ee6b955h681109296cdaceca@mail.gmail.com> Message-ID: <21b2f1351002051113t6af46e93l72f580952a842077@mail.gmail.com> P.S. Actually "viewer-dev" might be even better. Kakurady (Geneko Nemeth) 2010/2/5 Kakurady Drakenar > I don't like the name "opensource-dev". The old name, SLDev, fits just well > - it was about people getting together developing Second Life-related stuff. > Now what are we developing? "Open Source"? That's a slogan, it does not > manifest as anything, like an actual virtual world. Not to mention that, > since there are so many Free Software and Open Source projects in the world, > naming the list "opensource-dev" will only serve to confuse people. > > Some may say it's no longer fitting as the community developers' focus have > shifted from the mainline Second Life client to Snowglobe, but it's still a > Second Life client, so SLDev is still a good candidate for the name of the > mailing list. If you guys really don't like it, I propose this list be named > "sl-client-dev", or "hippo-hackers". > > Kakurady (Geneko Nemeth) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100205/0da8ec69/attachment.htm From maggie at matrisync.com Fri Feb 5 11:21:37 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Fri, 5 Feb 2010 14:21:37 -0500 Subject: [opensource-dev] What's with the rename? In-Reply-To: <21b2f1351002051113t6af46e93l72f580952a842077@mail.gmail.com> References: <21b2f1351002051109t3ee6b955h681109296cdaceca@mail.gmail.com> <21b2f1351002051113t6af46e93l72f580952a842077@mail.gmail.com> Message-ID: > 2010/2/5 Kakurady Drakenar >> >> I don't like the name "opensource-dev". The old name, SLDev, fits just >> well - i Yes, but Linden Research owns "SL". From djfoxyslpr at gmail.com Fri Feb 5 11:43:30 2010 From: djfoxyslpr at gmail.com (Jonathan Irvin) Date: Fri, 5 Feb 2010 13:43:30 -0600 Subject: [opensource-dev] What's with the rename? In-Reply-To: References: <21b2f1351002051109t3ee6b955h681109296cdaceca@mail.gmail.com> <21b2f1351002051113t6af46e93l72f580952a842077@mail.gmail.com> Message-ID: <9f4fbd5c1002051143y55fd501fmd7a470746849a240@mail.gmail.com> if I'm not mistaken, this is hosted on a secondlife.com domain, correct? what's the difference? On Fri, Feb 5, 2010 at 13:21, Maggie Leber (sl: Maggie Darwin) < maggie at matrisync.com> wrote: > > 2010/2/5 Kakurady Drakenar > >> > >> I don't like the name "opensource-dev". The old name, SLDev, fits just > >> well - i > > Yes, but Linden Research owns "SL". > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100205/949463ea/attachment.htm From andsim2 at gmail.com Fri Feb 5 13:55:25 2010 From: andsim2 at gmail.com (Andrew Simpson) Date: Fri, 05 Feb 2010 16:55:25 -0500 Subject: [opensource-dev] quicktime failed?? Message-ID: <4B6C93CD.2000307@gmail.com> hello is there is anyone why my build fail to start after it compiled? i get this 'secondlife-bin.exe': Loaded 'C:\Program Files (x86)\QuickTime\QTSystem\QuickTimeCapture.qtx' The thread 'Win32 Thread' (0x1998) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x112c) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1ec4) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1714) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x18a8) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1874) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1f34) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1814) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1f0c) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x19d4) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1ee8) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1db0) has exited with code 0 (0x0). The thread 'Win32 Thread' (0xb7c) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1d34) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x11ec) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x196c) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1920) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1ef8) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1c60) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1c40) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x197c) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1cfc) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1ed4) has exited with code 0 (0x0). The thread 'Win32 Thread' (0x1fe4) has exited with code 0 (0x0). let me know what causes it to fail From monkowsk at fishkill.ibm.com Fri Feb 5 14:16:02 2010 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Fri, 05 Feb 2010 17:16:02 -0500 Subject: [opensource-dev] quicktime failed?? In-Reply-To: <4B6C93CD.2000307@gmail.com> References: <4B6C93CD.2000307@gmail.com> Message-ID: <4B6C98A2.20009@fishkill.ibm.com> code 0 means no fail. Check the log file. Mike Andrew Simpson wrote: > hello is there is anyone why my build fail to start after it compiled? > > > i get this > 'secondlife-bin.exe': Loaded 'C:\Program Files > (x86)\QuickTime\QTSystem\QuickTimeCapture.qtx' > The thread 'Win32 Thread' (0x1998) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x112c) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1ec4) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1714) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x18a8) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1874) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1f34) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1814) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1f0c) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x19d4) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1ee8) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1db0) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0xb7c) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1d34) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x11ec) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x196c) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1920) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1ef8) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1c60) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1c40) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x197c) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1cfc) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1ed4) has exited with code 0 (0x0). > The thread 'Win32 Thread' (0x1fe4) has exited with code 0 (0x0). > let me know what causes it to fail > _______________________________________________ > 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 > From nexiim at googlemail.com Fri Feb 5 14:27:14 2010 From: nexiim at googlemail.com (Nexii Malthus) Date: Fri, 5 Feb 2010 22:27:14 +0000 Subject: [opensource-dev] Ohai! In-Reply-To: <1265394926.15384.2.camel@calcifer> References: <1265394926.15384.2.camel@calcifer> Message-ID: <824c8ab71002051427i7b4985b7md571c43858d93446@mail.gmail.com> It is basically the SLDev list, just with a new name. - Nexii On Fri, Feb 5, 2010 at 6:35 PM, C.J. Adams-Collier wrote: > I don't recall signing up for this list, but I'm happy to be here. ?If > nobody else takes credit, I'll blame robla. > > I haven't done anything with SL in a while... busy with school and work. > > Speaking of school, I'm attending classes with a focus on computational > linguistics. ?There has been some discussion among the members of the > department regarding the use of language processing in massively > multiplayer games, and even some discussion about writing some libs in > C#. ?Since I'm a Mono dev, I'll be sure that all of the stuff works on > that platform. > > But for now, I've got to run to the U and get to studying Lushootseed. > > Cheers, > > C.J. > > > _______________________________________________ > 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 > From nexiim at googlemail.com Fri Feb 5 14:29:34 2010 From: nexiim at googlemail.com (Nexii Malthus) Date: Fri, 5 Feb 2010 22:29:34 +0000 Subject: [opensource-dev] Client-side prediction In-Reply-To: <824c8ab71002051354o4b908399l27a2e0f8e21b3fa8@mail.gmail.com> References: <824c8ab71002051354o4b908399l27a2e0f8e21b3fa8@mail.gmail.com> Message-ID: <824c8ab71002051429i324ba3a3q144dfab2b0d3afa7@mail.gmail.com> Re-send. Didn't realize the new list was up already. Heya, > I written a quick article about a theoretical implementation that I had been > baffling on about for a while now. > > > http://www.avatarsunited.com/avatars/nexii/apps/blogs?view-params={"section":"show","id":"2442"} > > I realized that moving the 2D representation to 3D space is a bit more > complex than the picture gives. But it should still work if you work from > each of the 3D planes and apply to the XYZ values individually kinda, I > think, not sure if that phrases well or makes sense. > - Nexii -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100205/73cdb913/attachment.htm From kakurady at gmail.com Fri Feb 5 15:01:52 2010 From: kakurady at gmail.com (Kakurady Drakenar) Date: Fri, 5 Feb 2010 18:01:52 -0500 Subject: [opensource-dev] [sldev] Build tools improvements in Viewer 2.0? In-Reply-To: <77c421f01002051406i16623291lb8de770b2c973694@mail.gmail.com> References: <4B6B822B.4000409@gmail.com> <4B6C8EAF.3040108@lindenlab.com> <77c421f01002051406i16623291lb8de770b2c973694@mail.gmail.com> Message-ID: <21b2f1351002051501i48fb72bdld1d4826fd06d528e@mail.gmail.com> Yup that was about the in-world build tools all right. Nothing about compiling it. Kakurady (Geneko Nemeth) 2010/2/5 Colin Kern > On Fri, Feb 5, 2010 at 4:33 PM, Paul Oppenheim (Poppy Linden) > wrote: > > It's still CMake, if that's what you're asking. I'm not on the viewer 2 > team, so I can't say much more than that. > > > > + poppy > > > > Geneko Nemeth wrote: > >> I want to ask any Lindens around here, is there much improvements in > >> build tools in Viewer2? 'cause if not, I want to base my term project > >> for a UI course on it. Thanks! > >> > >> Kakurady (Geneko Nemeth) > > It sounds like he was referring to the in-world prim building tools. > > Colin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100205/33504361/attachment.htm From merov at lindenlab.com Fri Feb 5 16:53:48 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Fri, 5 Feb 2010 16:53:48 -0800 Subject: [opensource-dev] Ohai! In-Reply-To: <824c8ab71002051427i7b4985b7md571c43858d93446@mail.gmail.com> References: <1265394926.15384.2.camel@calcifer> <824c8ab71002051427i7b4985b7md571c43858d93446@mail.gmail.com> Message-ID: <78f69851002051653q1da795f3tc7ee2b7b7e9f3530@mail.gmail.com> Welcome back all of you :) - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100205/51c9f0bb/attachment.htm From merov at lindenlab.com Fri Feb 5 16:54:16 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Fri, 5 Feb 2010 16:54:16 -0800 Subject: [opensource-dev] Snowglobe 1.3 RC1 Message-ID: <78f69851002051654w78fda56rafd4586805edabfd@mail.gmail.com> Hi, With the landing of a patch for SNOW-196 (mutex locking) that was causing freezes, hangs and crashes, we created new binaries for 1.3, aptly named RC 1. We're still unsure about that fix though so please, download, use, test and report bugs in PJIRA when finding them (don't forget screen shots, SLURLs and other contextual data that can help repro and narrow the bug). Here are the bugs fixed since RC0 (build 3119): * SNOW-196 Deadlock in LLTextureFetchWorker::lockWorkMutex / LLThread::lockData / LLTextureFetch::lockQueue * SNOW-462 Double-Click Auto-Pilot and Double-Click Teleport menu options should be mutualy exclusive Downloads: Windows: http://secondlife.com/developers/opensource/downloads/2010/1.3/3125/Snowglobe_1-3-1-3125_Setup.exe Darwin: http://secondlife.com/developers/opensource/downloads/2010/1.3/3125/Snowglobe_1_3_1_3125.dmg Linux: http://secondlife.com/developers/opensource/downloads/2010/1.3/3125/Snowglobe-i686-1.3.1.3125.tar.bz2 Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100205/512772e9/attachment.htm From rusyasoft at gmail.com Fri Feb 5 16:59:14 2010 From: rusyasoft at gmail.com (Rustam Rakhimov) Date: Sat, 6 Feb 2010 09:59:14 +0900 Subject: [opensource-dev] (no subject) Message-ID: <7600b1331002051659m64be4487na60ae42d0f294171@mail.gmail.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100206/531ffd9a/attachment.htm From stickman at gmail.com Fri Feb 5 17:28:10 2010 From: stickman at gmail.com (Stickman) Date: Fri, 5 Feb 2010 17:28:10 -0800 Subject: [opensource-dev] Ohai! In-Reply-To: <78f69851002051653q1da795f3tc7ee2b7b7e9f3530@mail.gmail.com> References: <1265394926.15384.2.camel@calcifer> <824c8ab71002051427i7b4985b7md571c43858d93446@mail.gmail.com> <78f69851002051653q1da795f3tc7ee2b7b7e9f3530@mail.gmail.com> Message-ID: > Welcome back all of you :) It's alive, IT'S ALIVE! http://www.youtube.com/watch?v=8H3dFh6GA-A From Celierra at gmail.com Fri Feb 5 17:28:51 2010 From: Celierra at gmail.com (Celierra Darling) Date: Fri, 5 Feb 2010 20:28:51 -0500 Subject: [opensource-dev] Client-side prediction In-Reply-To: <824c8ab71002051429i324ba3a3q144dfab2b0d3afa7@mail.gmail.com> References: <824c8ab71002051354o4b908399l27a2e0f8e21b3fa8@mail.gmail.com> <824c8ab71002051429i324ba3a3q144dfab2b0d3afa7@mail.gmail.com> Message-ID: I'm not sure about this -- I tried this with a free-flight parabola and got a nonsense value out. Calculations attached at the end. What is the significance of the "anchor"? It looks like you're trying to estimate the center of the path's curvature? If you were doing that, you want to intersect using the lines through p and *perpendicular* to v (in 2D), not intersect the lines created by v. In 3D, I think you'd want to intersect 3 planes, the two planes through p perpendicular to their respective v and also the plane that contains both points. I'm not sure how to extend that to handle torques on the object.... Have you tried estimating a = (v1 - v2)/t, and extrapolating using that (p_next = p_cur + v_cur*dt + 1/2*a*dt^2)? It would also extend to torques and angular velocity using the analogous equation. (I'm sure you could even fit a line or spline to multiple previous values of v to get something even higher-order, if you wanted, though with diminishing returns.) Celi The aforementioned calculation: dt = 0.1 a = g = [0,-2] initial position and velocity: p1 = [0, 0] v1 = [1, 0] next position and velocity p2 = [0.1, -0.01] v2 = [1, -0.2] perfect value: p3 = [0.2, -0.04] lines are (p1 + s*v1) and (p2 + t*v2) intersect at s = 0.05, t = -0.05, position = [0.05, 0] angle change = clockwise 3pi/4 (radians) current angle = -pi/4 angle after "twist" = pi/2 (upwards!?) (it just gets worse from here - you estimate a distance upwards, and the step forward using the current velocity doesn't get you back to y=0.) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100205/5704c928/attachment-0001.htm From billyrose at netins.net Fri Feb 5 18:12:07 2010 From: billyrose at netins.net (Billy Rose) Date: Fri, 5 Feb 2010 20:12:07 -0600 Subject: [opensource-dev] Client-side prediction In-Reply-To: <824c8ab71002051429i324ba3a3q144dfab2b0d3afa7@mail.gmail.com> References: <824c8ab71002051354o4b908399l27a2e0f8e21b3fa8@mail.gmail.com> <824c8ab71002051429i324ba3a3q144dfab2b0d3afa7@mail.gmail.com> Message-ID: <802E06CB-634C-4BD6-ABB8-F9CFF45463F1@netins.net> If you apply 6-sigma calculations to the expected future and the actual future as reported when the position changes, you can begin to build a predictor that has a high degree of precision and is based off quantifiable history. Using the predictor as a an input, you can fine tune the expected position and velocity with a very high degree of accuracy for that short a period of time. Billy On Feb 5, 2010, at 4:29 PM, Nexii Malthus wrote: > Re-send. Didn't realize the new list was up already. > > Heya, > I written a quick article about a theoretical implementation that I > had been baffling on about for a while now. > > http://www.avatarsunited.com/avatars/nexii/apps/blogs?view-params= > {"section":"show","id":"2442"} > > I realized that moving the 2D representation to 3D space is a bit > more complex than the picture gives. But it should still work if you > work from each of the 3D planes and apply to the XYZ values > individually kinda, I think, not sure if that phrases well or makes > sense. > > - Nexii > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100205/cef135d3/attachment.htm From soft at lindenlab.com Fri Feb 5 19:00:47 2010 From: soft at lindenlab.com (Soft Linden) Date: Fri, 5 Feb 2010 21:00:47 -0600 Subject: [opensource-dev] Ohai! In-Reply-To: <78f69851002051653q1da795f3tc7ee2b7b7e9f3530@mail.gmail.com> References: <1265394926.15384.2.camel@calcifer> <824c8ab71002051427i7b4985b7md571c43858d93446@mail.gmail.com> <78f69851002051653q1da795f3tc7ee2b7b7e9f3530@mail.gmail.com> Message-ID: New car smell. It's nice. (Stealth test post - checking archiving & bad attachment stripping) On Fri, Feb 5, 2010 at 6:53 PM, Philippe (Merov) Bossut wrote: > Welcome back all of you :) > - Merov From nexiim at googlemail.com Fri Feb 5 19:22:28 2010 From: nexiim at googlemail.com (Nexii Malthus) Date: Sat, 6 Feb 2010 03:22:28 +0000 Subject: [opensource-dev] Client-side prediction In-Reply-To: References: <824c8ab71002051354o4b908399l27a2e0f8e21b3fa8@mail.gmail.com> <824c8ab71002051429i324ba3a3q144dfab2b0d3afa7@mail.gmail.com> Message-ID: <824c8ab71002051922m4b8438e2tc5afc96e5a882ea0@mail.gmail.com> Ah, thanks Celierra. 3 planes, yes that makes a lot more sense. Hmm, trying to step through your calculations. I think you have to subtract the angle difference rather than add it on. I just tried visually going through your calcs and it seems to hit right on your perfect value p3. http://i48.tinypic.com/15x2wz8.png - Nexii On Sat, Feb 6, 2010 at 1:28 AM, Celierra Darling wrote: > I'm not sure about this -- I tried this with a free-flight parabola and got > a nonsense value out. Calculations attached at the end. > What is the significance of the "anchor"? It looks like you're trying to > estimate the center of the path's curvature? If you were doing that, you > want to intersect using the lines through p and *perpendicular* to v (in > 2D), not intersect the lines created by v. In 3D, I think you'd want to > intersect 3 planes, the two planes through p perpendicular to their > respective v and also the plane that contains both points. > I'm not sure how to extend that to handle torques on the object.... > Have you tried estimating a = (v1 - v2)/t, and extrapolating using that > (p_next = p_cur + v_cur*dt + 1/2*a*dt^2)? It would also extend to torques > and angular velocity using the analogous equation. (I'm sure you could even > fit a line or spline to multiple previous values of v to get something even > higher-order, if you wanted, though with diminishing returns.) > > Celi > The aforementioned calculation: > > dt = 0.1 > a = g = [0,-2] > initial position and velocity: > p1 = [0, 0] > v1 = [1, 0] > next position and velocity > p2 = [0.1, -0.01] > v2 = [1, -0.2] > perfect value: p3 = [0.2, -0.04] > lines are (p1 + s*v1) and (p2 + t*v2) > intersect at s = 0.05, t = -0.05, position = [0.05, 0] > angle change = clockwise 3pi/4 (radians) > current angle = -pi/4 > angle after "twist" = pi/2 (upwards!?) > (it just gets worse from here - you estimate a distance upwards, and the > step forward using the current velocity doesn't get you back to y=0.) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100206/87dc3836/attachment.htm From partners at scifipc.com Fri Feb 5 21:08:10 2010 From: partners at scifipc.com (Science Fiction Computer - SCi-Fi PC) Date: Sat, 6 Feb 2010 15:08:10 +1000 Subject: [opensource-dev] The new name. In-Reply-To: References: <1265394926.15384.2.camel@calcifer> <824c8ab71002051427i7b4985b7md571c43858d93446@mail.gmail.com> <78f69851002051653q1da795f3tc7ee2b7b7e9f3530@mail.gmail.com> Message-ID: "opensource-dev" We support the new name, it's logical & clear. Nice work, DMC Jurassic/Zsigmond Science Fiction -----Original Message----- From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Soft Linden Sent: Saturday, February 06, 2010 1:01 PM To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Ohai! New car smell. It's nice. (Stealth test post - checking archiving & bad attachment stripping) On Fri, Feb 5, 2010 at 6:53 PM, Philippe (Merov) Bossut wrote: > Welcome back all of you :) > - Merov _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2668 - Release Date: 02/06/10 05:35:00 From Celierra at gmail.com Fri Feb 5 21:13:29 2010 From: Celierra at gmail.com (Celierra Darling) Date: Sat, 6 Feb 2010 00:13:29 -0500 Subject: [opensource-dev] Client-side prediction In-Reply-To: <824c8ab71002051922m4b8438e2tc5afc96e5a882ea0@mail.gmail.com> References: <824c8ab71002051354o4b908399l27a2e0f8e21b3fa8@mail.gmail.com> <824c8ab71002051429i324ba3a3q144dfab2b0d3afa7@mail.gmail.com> <824c8ab71002051922m4b8438e2tc5afc96e5a882ea0@mail.gmail.com> Message-ID: I made a small mistake at the "current angle" (it should be -0.2ish radians instead of -pi/4), which makes the angle difference close to a semicircle. But still, if you add that, you end up with a vector pointing up and backwards... (If you subtract, you end up just heading back left...) Maybe I'm just not interpreting what you mean by the "twist" correctly? (Even when I 'visually' do it to your picture, I get the same result...) Am I supposed to be finding the angle between the velocity vectors, or the angle between the (position - intersection point) vectors? (We might want to work things out off-list, unless anyone would like to see those details.) Celi . On Fri, Feb 5, 2010 at 10:22 PM, Nexii Malthus wrote: > Ah, thanks Celierra. 3 planes, yes that makes a lot more sense. > > Hmm, trying to step through your calculations. I think you have to subtract > the angle difference rather than add it on. > I just tried visually going through your calcs and it seems to hit right on > your perfect value p3. > > http://i48.tinypic.com/15x2wz8.png > > - Nexii > > > > On Sat, Feb 6, 2010 at 1:28 AM, Celierra Darling > wrote: > > I'm not sure about this -- I tried this with a free-flight parabola and > got > > a nonsense value out. Calculations attached at the end. > > What is the significance of the "anchor"? It looks like you're trying to > > estimate the center of the path's curvature? If you were doing that, you > > want to intersect using the lines through p and *perpendicular* to v (in > > 2D), not intersect the lines created by v. In 3D, I think you'd want to > > intersect 3 planes, the two planes through p perpendicular to their > > respective v and also the plane that contains both points. > > I'm not sure how to extend that to handle torques on the object.... > > Have you tried estimating a = (v1 - v2)/t, and extrapolating using that > > (p_next = p_cur + v_cur*dt + 1/2*a*dt^2)? It would also extend to > torques > > and angular velocity using the analogous equation. (I'm sure you could > even > > fit a line or spline to multiple previous values of v to get something > even > > higher-order, if you wanted, though with diminishing returns.) > > > > Celi > > The aforementioned calculation: > > > > dt = 0.1 > > a = g = [0,-2] > > initial position and velocity: > > p1 = [0, 0] > > v1 = [1, 0] > > next position and velocity > > p2 = [0.1, -0.01] > > v2 = [1, -0.2] > > perfect value: p3 = [0.2, -0.04] > > lines are (p1 + s*v1) and (p2 + t*v2) > > intersect at s = 0.05, t = -0.05, position = [0.05, 0] > > angle change = clockwise 3pi/4 (radians) > > current angle = -pi/4 > > angle after "twist" = pi/2 (upwards!?) > > (it just gets worse from here - you estimate a distance upwards, and the > > step forward using the current velocity doesn't get you back to y=0.) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100206/7baff9af/attachment.htm From nexiim at googlemail.com Sat Feb 6 07:09:50 2010 From: nexiim at googlemail.com (Nexii Malthus) Date: Sat, 6 Feb 2010 15:09:50 +0000 Subject: [opensource-dev] Client-side prediction In-Reply-To: References: <824c8ab71002051354o4b908399l27a2e0f8e21b3fa8@mail.gmail.com> <824c8ab71002051429i324ba3a3q144dfab2b0d3afa7@mail.gmail.com> <824c8ab71002051922m4b8438e2tc5afc96e5a882ea0@mail.gmail.com> Message-ID: <824c8ab71002060709w2cd744c8g61a662b5ec54114a@mail.gmail.com> Hm, I'm probably terrible with explaining it in words. I think a step-by-step picture can help show what I did. http://i45.tinypic.com/2zgx4kg.png 1. I build the lines by using the velocity vectors, the positions for their origin. 2. Then find the intersection point between these two lines and use that point as the curvature centre. 3. Find the shortest angle between the two lines. 4. Transform current position and velocity vectors by the angle difference. 5. Move this new predicted position forwards by the velocity. (You had some good calculations up there for the acceleration and such) I had messed up the blog article a bit because I tried to explain two different ideas all at once. One, the theoretical algorithm for prediction of the future position. Two, the idea for efficiency of pre-computing this future position for one second ahead when a new position update message came from the simulator/server and using this by just simply linearly interpolation between current position and future position with dt (instead of re-computing the entire algorithm at each render frame). (Best to stay on list, we might help fix any other misunderstandings of people looking here, any progress/work to improve on the prediction works in favour of everyone here, activity is pretty low anyways on-list) - Nexii On Sat, Feb 6, 2010 at 5:13 AM, Celierra Darling wrote: > I made a small mistake at the "current angle" (it should be -0.2ish radians > instead of -pi/4), which makes the angle difference close to a semicircle. > But still, if you add that, you end up with a vector pointing up and > backwards... (If you subtract, you end up just heading back left...) > > Maybe I'm just not interpreting what you mean by the "twist" correctly? > (Even when I 'visually' do it to your picture, I get the same result...) > Am I supposed to be finding the angle between the velocity vectors, or the > angle between the (position - intersection point) vectors? > > (We might want to work things out off-list, unless anyone would like to see > those details.) > > Celi > . > > On Fri, Feb 5, 2010 at 10:22 PM, Nexii Malthus wrote: > >> Ah, thanks Celierra. 3 planes, yes that makes a lot more sense. >> >> Hmm, trying to step through your calculations. I think you have to >> subtract the angle difference rather than add it on. >> I just tried visually going through your calcs and it seems to hit right >> on your perfect value p3. >> >> http://i48.tinypic.com/15x2wz8.png >> >> - Nexii >> >> >> >> On Sat, Feb 6, 2010 at 1:28 AM, Celierra Darling >> wrote: >> > I'm not sure about this -- I tried this with a free-flight parabola and >> got >> > a nonsense value out. Calculations attached at the end. >> > What is the significance of the "anchor"? It looks like you're trying >> to >> > estimate the center of the path's curvature? If you were doing that, >> you >> > want to intersect using the lines through p and *perpendicular* to v (in >> > 2D), not intersect the lines created by v. In 3D, I think you'd want to >> > intersect 3 planes, the two planes through p perpendicular to their >> > respective v and also the plane that contains both points. >> > I'm not sure how to extend that to handle torques on the object.... >> > Have you tried estimating a = (v1 - v2)/t, and extrapolating using that >> > (p_next = p_cur + v_cur*dt + 1/2*a*dt^2)? It would also extend to >> torques >> > and angular velocity using the analogous equation. (I'm sure you could >> even >> > fit a line or spline to multiple previous values of v to get something >> even >> > higher-order, if you wanted, though with diminishing returns.) >> > >> > Celi >> > The aforementioned calculation: >> > >> > dt = 0.1 >> > a = g = [0,-2] >> > initial position and velocity: >> > p1 = [0, 0] >> > v1 = [1, 0] >> > next position and velocity >> > p2 = [0.1, -0.01] >> > v2 = [1, -0.2] >> > perfect value: p3 = [0.2, -0.04] >> > lines are (p1 + s*v1) and (p2 + t*v2) >> > intersect at s = 0.05, t = -0.05, position = [0.05, 0] >> > angle change = clockwise 3pi/4 (radians) >> > current angle = -pi/4 >> > angle after "twist" = pi/2 (upwards!?) >> > (it just gets worse from here - you estimate a distance upwards, and the >> > step forward using the current velocity doesn't get you back to y=0.) >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100206/58da28ae/attachment-0001.htm From carlo at alinoe.com Sat Feb 6 07:21:48 2010 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 6 Feb 2010 16:21:48 +0100 Subject: [opensource-dev] Client-side prediction In-Reply-To: <824c8ab71002060709w2cd744c8g61a662b5ec54114a@mail.gmail.com> References: <824c8ab71002051354o4b908399l27a2e0f8e21b3fa8@mail.gmail.com> <824c8ab71002051429i324ba3a3q144dfab2b0d3afa7@mail.gmail.com> <824c8ab71002051922m4b8438e2tc5afc96e5a882ea0@mail.gmail.com> <824c8ab71002060709w2cd744c8g61a662b5ec54114a@mail.gmail.com> Message-ID: <20100206152148.GA7984@alinoe.com> On Sat, Feb 06, 2010 at 03:09:50PM +0000, Nexii Malthus wrote: > Hm, I'm probably terrible with explaining it in words. > > I think a step-by-step picture can help show what I did. > > http://i45.tinypic.com/2zgx4kg.png I don't think that predicting a rotation will be very practical. In most cases people walk straight and make sharp corners; so if you detect that an angle, I'd assume that changed direction, NOT assume that they are walking in a circle. If you want to include prediction of curved paths then I think you should add another sample (three points) and choose "circle" if the path matches the path that one would follow if one holds down the left or right arrow key while walking... but then again, not that useful. If people are walking around in mouse look, you just can't predict anything -- unless the lag is so small that rotation prediction is hardly necessary to begin with :/ -- Carlo Wood From tayra.dagostino at gmail.com Sun Feb 7 08:26:28 2010 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Sun, 7 Feb 2010 17:26:28 +0100 Subject: [opensource-dev] Snowglobe 1.3 RC1 In-Reply-To: <78f69851002051654w78fda56rafd4586805edabfd@mail.gmail.com> References: <78f69851002051654w78fda56rafd4586805edabfd@mail.gmail.com> Message-ID: <20100207172628.2c833fd4.tayra.dagostino@gmail.com> On Fri, 5 Feb 2010 16:54:16 -0800 "Philippe (Merov) Bossut" wrote: > Hi, > > With the landing of a patch for SNOW-196 (mutex locking) that was > causing freezes, hangs and crashes, we created new binaries for 1.3, > aptly named RC > 1. > > We're still unsure about that fix though so please, download, use, > test and report bugs in PJIRA when finding them (don't forget screen > shots, SLURLs and other contextual data that can help repro and > narrow the bug). > > Here are the bugs fixed since RC0 (build 3119): > * SNOW-196 Deadlock in LLTextureFetchWorker::lockWorkMutex / > LLThread::lockData / LLTextureFetch::lockQueue > * SNOW-462 Double-Click Auto-Pilot and Double-Click Teleport menu > options should be mutualy exclusive uhm.... maybe i'm in a too lagged sim but i have a large number of avatar grey, zooming very close them force viewer to begin to rez, somebody else or is a particular condition without any repro? From kamilion at gmail.com Sun Feb 7 16:47:26 2010 From: kamilion at gmail.com (Graham Cantin) Date: Sun, 7 Feb 2010 16:47:26 -0800 Subject: [opensource-dev] (no subject) In-Reply-To: <7600b1331002051659m64be4487na60ae42d0f294171@mail.gmail.com> References: <7600b1331002051659m64be4487na60ae42d0f294171@mail.gmail.com> Message-ID: Allright, who's the wiseass who signed me up to this list? I've got an inbox full of unfiltered mail and I'm very unhappy. From brickrte at odyssey.net Sun Feb 7 16:50:00 2010 From: brickrte at odyssey.net (brickrte) Date: Sun, 7 Feb 2010 19:50:00 -0500 Subject: [opensource-dev] (no subject) In-Reply-To: References: <7600b1331002051659m64be4487na60ae42d0f294171@mail.gmail.com> Message-ID: <83F9CF7A4F364D7EAB012073903E6118@lrbxps> I did it and you are not wise... -----Original Message----- From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Graham Cantin Sent: Sunday, February 07, 2010 7:47 PM To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] (no subject) Allright, who's the wiseass who signed me up to this list? I've got an inbox full of unfiltered mail and I'm very unhappy. _______________________________________________ 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 __________ Information from ESET Smart Security, version of virus signature database 4845 (20100207) __________ The message was checked by ESET Smart Security. http://www.eset.com From kamilion at gmail.com Sun Feb 7 16:59:13 2010 From: kamilion at gmail.com (Graham Cantin) Date: Sun, 7 Feb 2010 16:59:13 -0800 Subject: [opensource-dev] (no subject) In-Reply-To: <83F9CF7A4F364D7EAB012073903E6118@lrbxps> References: <7600b1331002051659m64be4487na60ae42d0f294171@mail.gmail.com> <83F9CF7A4F364D7EAB012073903E6118@lrbxps> Message-ID: You shouldn't be signing others up for mailing lists. It's rude. yeah, I just looked at the news, sldev renamed, got it, bleh. What the hell was wrong with sldev? On Sun, Feb 7, 2010 at 4:50 PM, brickrte wrote: > I did it and you are not wise... > > > -----Original Message----- > From: opensource-dev-bounces at lists.secondlife.com > [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Graham > Cantin > Sent: Sunday, February 07, 2010 7:47 PM > To: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] (no subject) > > Allright, who's the wiseass who signed me up to this list? I've got an > inbox full of unfiltered mail and I'm very unhappy. From kamilion at gmail.com Sun Feb 7 17:18:29 2010 From: kamilion at gmail.com (Graham Cantin) Date: Sun, 7 Feb 2010 17:18:29 -0800 Subject: [opensource-dev] (no subject) In-Reply-To: References: <7600b1331002051659m64be4487na60ae42d0f294171@mail.gmail.com> <83F9CF7A4F364D7EAB012073903E6118@lrbxps> Message-ID: Eh, okay. All figured out. Thanks, Soft, for the explanation! On Sun, Feb 7, 2010 at 5:15 PM, Graham Cantin wrote: > Apparently they've had a previous group asking for the listname? > Makes sense now. > > On Tue, Feb 2, 2010 at 12:11 PM, Soft Linden wrote: >> Since before the viewer went open source, Linden Lab has had an SL >> Developer program for the solution providers listed in the SL >> Developer directory at http://solutionproviders.secondlife.com . It's >> the same group that has the SLDEV and SLDEVu islands and the SLDEV >> group in-world. I don't know the history of how open source ended up >> on a list with the same name. > > On Sun, Feb 7, 2010 at 5:11 PM, Daniel wrote: >> the damn list is hosted on secondlife.com!? Its not even a third party >> service >> >> On Sun, Feb 7, 2010 at 7:09 PM, Graham Cantin wrote: >>> >>> yeah, just updated mine, read the whole arguement thread about the >>> list rename and laughed... >>> SLDev never changes. I'm just gonna be pissed off if they start up the >>> legal "we own the initials SL" bullcrap and attack my sllabs.com >>> domain again. >>> (I own and operate Secret Lair Labs, Inc since April 2002, long before >>> SL 'existed') >>> >>> On Sun, Feb 7, 2010 at 5:03 PM, Daniel wrote: >>> > lol yeah me too same thing happened to me. Only reason I saw your email >>> > is >>> > cause I havent updated my filters.? Very annoying. >>> > >>> > On Sun, Feb 7, 2010 at 7:02 PM, Graham Cantin >>> > wrote: >>> >> >>> >> Y'know, I use gmail. It filters crap. And that message? Got filtered >>> >> into !ML\SL\SL_Catchall, marked as read, and removed from the inbox. >>> >> >>> >> So now I've got a page of mail in my inbox and I've got no clue where >>> >> it's coming from, frankly don't really give a shit since I left SL in >>> >> 2007 because it still looks like vertex vomit ass. >>> >> >>> >> On Sun, Feb 7, 2010 at 4:53 PM, Daniel wrote: >>> >> > Rather than spamming the entire mailing list why don't you read the >>> >> > email >>> >> > you received called >>> >> > >>> >> > Welcome to the "opensource-dev" mailing list >>> >> > >>> >> > you might just find the answers you seek there.? The old SLDev >>> >> > mailing >>> >> > list >>> >> > was renamed.... So the 'wiseass' was ... YOU! On Sun, Feb 7, 2010 at 4:59 PM, Graham Cantin wrote: > You shouldn't be signing others up for mailing lists. It's > rude. > > > yeah, I just looked at the news, sldev renamed, got it, bleh. > > What the hell was wrong with sldev? > > On Sun, Feb 7, 2010 at 4:50 PM, brickrte wrote: >> I did it and you are not wise... >> >> >> -----Original Message----- >> From: opensource-dev-bounces at lists.secondlife.com >> [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Graham >> Cantin >> Sent: Sunday, February 07, 2010 7:47 PM >> To: opensource-dev at lists.secondlife.com >> Subject: Re: [opensource-dev] (no subject) >> >> Allright, who's the wiseass who signed me up to this list? I've got an >> inbox full of unfiltered mail and I'm very unhappy. > From rusyasoft at gmail.com Sun Feb 7 23:23:27 2010 From: rusyasoft at gmail.com (Rustam Rakhimov) Date: Mon, 8 Feb 2010 16:23:27 +0900 Subject: [opensource-dev] Through the which function is possible to stop revoking pieMenu Message-ID: <7600b1331002072323t63d0dcd4m151f83b93cce4c6e@mail.gmail.com> Through the which function is possible to stop revoking pieMenu. I wanna turn off pieMenu on some specific objects, how can I do it, I'm searching for that almost three days, and still didn't find anything. The problem is, there are a lot of handleRightMouseDown() functions, almost every class has implementation of that virtual function. IS there anyone who know how to turn off PieMenu which appearing with pushing right button of mouse -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100208/4197a642/attachment.htm From robin.cornelius at gmail.com Mon Feb 8 02:22:47 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon, 8 Feb 2010 10:22:47 +0000 Subject: [opensource-dev] Snowglobe 1.3 RC1 In-Reply-To: <20100207172628.2c833fd4.tayra.dagostino@gmail.com> References: <78f69851002051654w78fda56rafd4586805edabfd@mail.gmail.com> <20100207172628.2c833fd4.tayra.dagostino@gmail.com> Message-ID: >> Here are the bugs fixed since RC0 (build 3119): >> * SNOW-196 Deadlock in LLTextureFetchWorker::lockWorkMutex / >> LLThread::lockData / LLTextureFetch::lockQueue >> * SNOW-462 Double-Click Auto-Pilot and Double-Click Teleport menu >> options should be mutualy exclusive > > uhm.... maybe i'm in a too lagged sim but i have a large number of > avatar grey, zooming very close them force viewer to begin to rez, > somebody else or is a particular condition without any repro? I'm very keen to know if anyone else is seeing grey textures that are talking longer/never loading WRT previous snowglobe versions or if anyone is seeing any unusal entries in the log/console due to textures. My part of SNOW-196 in theory if things are not working as i expected could potentially cause some texture issues, hence the testing here. I also want to know about hard lockup deads locks, if anyone was finding snowglobe freezing solid before and now its fine for them, please also let me know here, or directly via email/in world etc. Thanks Robin From brickrte at odyssey.net Mon Feb 8 04:55:47 2010 From: brickrte at odyssey.net (brickrte) Date: Mon, 8 Feb 2010 07:55:47 -0500 Subject: [opensource-dev] Snowglobe 1.3 RC1 In-Reply-To: References: <78f69851002051654w78fda56rafd4586805edabfd@mail.gmail.com><20100207172628.2c833fd4.tayra.dagostino@gmail.com> Message-ID: <0D72459C84FD4316B16B3FCEE92EB0F6@lrbxps> Robin, I've been using it since its release and haven't had one lockup. N.B. this hasn't been any sort of regression testing, just normal use. Larry -----Original Message----- From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Robin Cornelius Sent: Monday, February 08, 2010 5:23 AM To: Tayra Dagostino Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Snowglobe 1.3 RC1 >> Here are the bugs fixed since RC0 (build 3119): >> * SNOW-196 Deadlock in LLTextureFetchWorker::lockWorkMutex / >> LLThread::lockData / LLTextureFetch::lockQueue >> * SNOW-462 Double-Click Auto-Pilot and Double-Click Teleport menu >> options should be mutualy exclusive > > uhm.... maybe i'm in a too lagged sim but i have a large number of > avatar grey, zooming very close them force viewer to begin to rez, > somebody else or is a particular condition without any repro? I'm very keen to know if anyone else is seeing grey textures that are talking longer/never loading WRT previous snowglobe versions or if anyone is seeing any unusal entries in the log/console due to textures. My part of SNOW-196 in theory if things are not working as i expected could potentially cause some texture issues, hence the testing here. I also want to know about hard lockup deads locks, if anyone was finding snowglobe freezing solid before and now its fine for them, please also let me know here, or directly via email/in world etc. Thanks 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 __________ Information from ESET Smart Security, version of virus signature database 4847 (20100208) __________ The message was checked by ESET Smart Security. http://www.eset.com From nexiim at googlemail.com Mon Feb 8 06:57:30 2010 From: nexiim at googlemail.com (Nexii Malthus) Date: Mon, 8 Feb 2010 14:57:30 +0000 Subject: [opensource-dev] Through the which function is possible to stop revoking pieMenu In-Reply-To: <7600b1331002072323t63d0dcd4m151f83b93cce4c6e@mail.gmail.com> References: <7600b1331002072323t63d0dcd4m151f83b93cce4c6e@mail.gmail.com> Message-ID: <824c8ab71002080657n4528547aye218cdb088c3eb62@mail.gmail.com> Believe it or not, but it has a pretty obvious name: lltoolpie.cpp For specific objects, via uuid or name? If via name, it may not be easily available. - Nexii On Mon, Feb 8, 2010 at 7:23 AM, Rustam Rakhimov wrote: > Through the which function is possible to stop revoking pieMenu. > > I wanna turn off pieMenu on some specific objects, how can I do it, I'm > searching for that almost three days, and still didn't find anything. > The problem is, there are a lot of handleRightMouseDown() functions, almost > every class has implementation of that virtual function. > > IS there anyone who know how to turn off PieMenu which appearing with > pushing right button of mouse > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100208/0c39dde3/attachment.htm From robertltux at gmail.com Mon Feb 8 07:24:50 2010 From: robertltux at gmail.com (Robert Martin) Date: Mon, 8 Feb 2010 10:24:50 -0500 Subject: [opensource-dev] edit appearance dialog where is the code?? Message-ID: I have an idea for a program that would just about need to reimplement the edit appearance dialog and i was wondering how self contained is the code for the dialog (bonus round question what files are used?)? I would need just the settings sliders not the thumbnails or any of the rendered views. As part of SL 2.0 is anybody doing a "White Rabbits Guide to the Codebase"? -- Robert L Martin btw im also looking for a programmer since i can barely script myself From open at autistici.org Mon Feb 8 10:54:52 2010 From: open at autistici.org (Opensource Obscure) Date: Mon, 08 Feb 2010 18:54:52 +0000 Subject: [opensource-dev] Snowglobe 1.3 RC1 In-Reply-To: References: <78f69851002051654w78fda56rafd4586805edabfd@mail.gmail.com> <20100207172628.2c833fd4.tayra.dagostino@gmail.com> Message-ID: On Mon, 8 Feb 2010 10:22:47 +0000, Robin Cornelius wrote: > I also want to know about hard lockup deads locks, if anyone was > finding snowglobe freezing solid before and now its fine for them, > please also let me know here, or directly via email/in world etc. I'm using Snowglobe 1.3 RC1 since today (Linux) - I crashed 3 times in 4 sessions, with wiewer suddenly freezing. Need to kill -9 the process to exit. This is quite new in my experience, meaning that crashes happen to me with almost any viewer, but I rarely saw freezes. I'm using official drivers from Nvidia, and I didn't change hardware recently, but I often update my system and sometimes I use experimental software - so this is not a 100% vanilla environment. I'm going to waiting for comments and more testing before filing this one. More details about viewer follow below. bye open -- http://www.avatarsunited.com/avatars/opensource-obscure Snowglobe 1.3.1 (3125) Feb 5 2010 09:41:34 (Snowglobe Release) Built with GCC version 40102 Sei a 233826.3, 335438.9, 32.1 in LOL located at sim2133.agni.lindenlab.com (216.82.56.138:13000) Second Life Server 1.34.3.143038 Note sulla versione CPU: Intel(R) Core(TM)2 CPU 6420 @ 2.13GHz Memory: 3276 MB OS Version: Linux 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 2009 i686 Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 9600 GT/PCI/SSE2 OpenGL Version: 3.0.0 NVIDIA 185.18.36 libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3.3 c-ares/1.4.0 J2C Decoder Version: KDU Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.10.622 / OpenAL Community / OpenAL Soft: PulseAudio Software Qt Webkit Version: 4.5.2 Packets Lost: 43/55053 (0.1%) From robin.cornelius at gmail.com Mon Feb 8 11:53:55 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon, 08 Feb 2010 19:53:55 +0000 Subject: [opensource-dev] Snowglobe 1.3 RC1 In-Reply-To: References: <78f69851002051654w78fda56rafd4586805edabfd@mail.gmail.com> <20100207172628.2c833fd4.tayra.dagostino@gmail.com> Message-ID: <4B706BD3.3040001@gmail.com> Opensource Obscure wrote: > I'm using Snowglobe 1.3 RC1 since today (Linux) - I crashed 3 times > in 4 sessions, with wiewer suddenly freezing. Need to kill -9 the > process to exit. Just checking that your viewer is indeed 1.3.1.3125, February 5, 2010? Certainly sounds like there is still a dead lock present, i've had a bit of feedback since saying some people have running fine now and was hoping we had cracked this for the minute, but 3 lockups does not look good. Do you do your own builds? the only way for certain to know whats up is to run the viewer under gdb (but for useful results this required your own build with debug symbols), and then when a lock up occurs to break the debugger then print the back traces of the threads involved. ;-/ Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100208/c8f9bfbe/attachment.pgp From tillie at xp2.de Mon Feb 8 12:40:47 2010 From: tillie at xp2.de (Tillie Ariantho) Date: Mon, 08 Feb 2010 21:40:47 +0100 Subject: [opensource-dev] Snowglobe 1.3 RC1 In-Reply-To: References: <78f69851002051654w78fda56rafd4586805edabfd@mail.gmail.com> <20100207172628.2c833fd4.tayra.dagostino@gmail.com> Message-ID: <4B7076CF.8030605@xp2.de> On 08.02.2010 11:22, Robin Cornelius wrote: > I'm very keen to know if anyone else is seeing grey textures that are > talking longer/never loading WRT previous snowglobe versions or if > anyone is seeing any unusal entries in the log/console due to > textures. My part of SNOW-196 in theory if things are not working as i > expected could potentially cause some texture issues, hence the > testing here. > > I also want to know about hard lockup deads locks, if anyone was > finding snowglobe freezing solid before and now its fine for them, > please also let me know here, or directly via email/in world etc. I had a very long fashion show yesterday with 38+ people in the model sim and 50-65 people in the visitor sim. I had no deadlock at all, and all the textures on the model sim (where i were too rezzed well). I only had serious trouble to get most of the textures in the visitor sim loaded, but I guess that was not related to the client version but the heavy lag on that sim. What is still a problem, but not related to the mentioned fixes, is the crash when the client has loaded a given amount of stuff. You sooner or later crash, somewhere around 1,3 GB of used memory (Win 7 64bit, but that happened on Vista 64bit and XP 32bit, too). What I see often in the log is WARNING: LLVOAvatar::getTargetAttachmentPoint: Object attachment point invalid: 128 but probably related to some avatar using Emerald with additional attachment points There are several INFO: LLSDXMLParser::Impl::parse: LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:Internal Server Error too and I see many INFO: LLCircuitData::dumpResendCountAndReset: Circuit: :12035 resent packets in the log. Tillie From open at autistici.org Mon Feb 8 12:40:50 2010 From: open at autistici.org (Opensource Obscure) Date: Mon, 08 Feb 2010 20:40:50 +0000 Subject: [opensource-dev] Snowglobe 1.3 RC1 In-Reply-To: <4B706BD3.3040001@gmail.com> References: <78f69851002051654w78fda56rafd4586805edabfd@mail.gmail.com> <20100207172628.2c833fd4.tayra.dagostino@gmail.com> <4B706BD3.3040001@gmail.com> Message-ID: <1b3d4c1e7a8d59263fffb048e6146f28@localhost> On Mon, 08 Feb 2010 19:53:55 +0000, Robin Cornelius wrote: > Just checking that your viewer is indeed 1.3.1.3125, February 5, 2010? yes. > Do you do your own builds? the only way for certain to know whats up is > to run the viewer under gdb (but for useful results this required your > own build with debug symbols), and then when a lock up occurs to break > the debugger then print the back traces of the threads involved. I can build the viewer, but I never did the gdb+debug build thing yet. I'll grab last sources, look at the docs and try - some wiki pages are a mess, so tips about how to do this would be appreciated. thanks! bye open From tayra.dagostino at gmail.com Mon Feb 8 14:21:46 2010 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Mon, 8 Feb 2010 23:21:46 +0100 Subject: [opensource-dev] Snowglobe 1.3 RC1 In-Reply-To: References: <78f69851002051654w78fda56rafd4586805edabfd@mail.gmail.com> <20100207172628.2c833fd4.tayra.dagostino@gmail.com> Message-ID: <20100208232146.88c56b7a.tayra.dagostino@gmail.com> On Mon, 8 Feb 2010 10:22:47 +0000 Robin Cornelius wrote: > I'm very keen to know if anyone else is seeing grey textures that are > talking longer/never loading WRT previous snowglobe versions or if > anyone is seeing any unusal entries in the log/console due to > textures. My part of SNOW-196 in theory if things are not working as i > expected could potentially cause some texture issues, hence the > testing here. no deadlock for me, 0 crash, no other "bad" hang/freeze, just slow to rendering textures..... From sempuki1 at gmail.com Tue Feb 9 02:02:18 2010 From: sempuki1 at gmail.com (Ryan McDougall) Date: Tue, 9 Feb 2010 12:02:18 +0200 Subject: [opensource-dev] Announce: realXtend Naali 0.1 (alpha) client viewer Message-ID: realXtend is proud to announce the first major alpha release of its groundbreaking multi-use virtual world client viewer, Naali. We are hoping this release will see widespread user testing, to help us refine and improve our work. Naali is alpha software and missing many features, but we hope, with your feedback, to make Naali the "Firefox" of virtual worlds. Demo video can be found here: http://www.youtube.com/watch?v=4iiE66hY-RU Both source code and binaries can be found on our project website: http://code.google.com/p/realxtend-naali/ Naali is released under the Apache 2.0 software license, and available for the following platforms: * Windows: Binary installer * Linux: Full source and build instructions * Mac: In progress Naali is implemented in C++ (using Qt and Ogre3D) and Python. Bindings for JavaScript are also planned. It is designed using a modular and scalable architecture, with easy repurposing for a wide variety of applications by simply dropping in new components. Naali is intended to work with any virtual world protocol through its modular architecture, however currently only support for SLUDP-based protocols through OpenSim are implemented. Naali comes with a reference server implementation called Taiga, which adds mesh-based assets, Python server-side scripting, web login with OpenID, and inventory over WebDAV. Naali is it true open-source project, which means the community has a voice in guiding the direction of the project, and commit access is available to contributors with a proven track record of quality patches. Please join us on our mailing lists: http://groups.google.com/group/realxtend http://groups.google.com/group/realxtend-dev Or on IRC, on Freenode #realxtend #realxtend-dev More information can be found on our website: http://wiki.realxtend.org/index.php/Main_Page Ryan McDougall http://www.realxtend.org From nexiim at googlemail.com Tue Feb 9 09:27:06 2010 From: nexiim at googlemail.com (Nexii Malthus) Date: Tue, 9 Feb 2010 17:27:06 +0000 Subject: [opensource-dev] Announce: realXtend Naali 0.1 (alpha) client viewer In-Reply-To: References: Message-ID: <824c8ab71002090927l25dc0558m9bc3db7106313fd2@mail.gmail.com> Impressive stuff, my praise goes to the realXtend team for their work. Going to try it out right now. - Nexii On Tue, Feb 9, 2010 at 10:02 AM, Ryan McDougall wrote: > realXtend is proud to announce the first major alpha release of its > groundbreaking multi-use virtual world client viewer, Naali. We are > hoping this release will see widespread user testing, to help us > refine and improve our work. Naali is alpha software and missing many > features, but we hope, with your feedback, to make Naali the "Firefox" > of virtual worlds. > > Demo video can be found here: http://www.youtube.com/watch?v=4iiE66hY-RU > > Both source code and binaries can be found on our project website: > http://code.google.com/p/realxtend-naali/ > > Naali is released under the Apache 2.0 software license, and available > for the following platforms: > > * Windows: Binary installer > * Linux: Full source and build instructions > * Mac: In progress > > Naali is implemented in C++ (using Qt and Ogre3D) and Python. Bindings > for JavaScript are also planned. It is designed using a modular and > scalable architecture, with easy repurposing for a wide variety of > applications by simply dropping in new components. > > Naali is intended to work with any virtual world protocol through its > modular architecture, however currently only support for SLUDP-based > protocols through OpenSim are implemented. > > Naali comes with a reference server implementation called Taiga, > which adds mesh-based assets, Python server-side scripting, web login > with OpenID, and inventory over WebDAV. > > Naali is it true open-source project, which means the community has a > voice in guiding the direction of the project, and commit access is > available to contributors with a proven track record of quality > patches. > > Please join us on our mailing lists: > http://groups.google.com/group/realxtend > http://groups.google.com/group/realxtend-dev > > Or on IRC, on Freenode > #realxtend > #realxtend-dev > > More information can be found on our website: > http://wiki.realxtend.org/index.php/Main_Page > > Ryan McDougall > http://www.realxtend.org > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100209/ad2e2e0d/attachment.htm From djfoxyslpr at gmail.com Tue Feb 9 09:34:41 2010 From: djfoxyslpr at gmail.com (Jonathan Irvin) Date: Tue, 9 Feb 2010 11:34:41 -0600 Subject: [opensource-dev] Announce: realXtend Naali 0.1 (alpha) client viewer In-Reply-To: <824c8ab71002090927l25dc0558m9bc3db7106313fd2@mail.gmail.com> References: <824c8ab71002090927l25dc0558m9bc3db7106313fd2@mail.gmail.com> Message-ID: <9f4fbd5c1002090934m3dc23778w3a19ab097541f76b@mail.gmail.com> Sounds silly, but A.) Will it work in the normal Grid and B.) Work in 64-bit linux? On Tue, Feb 9, 2010 at 11:27, Nexii Malthus wrote: > Impressive stuff, my praise goes to the realXtend team for their work. > Going to try it out right now. > > - Nexii > > > On Tue, Feb 9, 2010 at 10:02 AM, Ryan McDougall wrote: > >> realXtend is proud to announce the first major alpha release of its >> groundbreaking multi-use virtual world client viewer, Naali. We are >> hoping this release will see widespread user testing, to help us >> refine and improve our work. Naali is alpha software and missing many >> features, but we hope, with your feedback, to make Naali the "Firefox" >> of virtual worlds. >> >> Demo video can be found here: http://www.youtube.com/watch?v=4iiE66hY-RU >> >> Both source code and binaries can be found on our project website: >> http://code.google.com/p/realxtend-naali/ >> >> Naali is released under the Apache 2.0 software license, and available >> for the following platforms: >> >> * Windows: Binary installer >> * Linux: Full source and build instructions >> * Mac: In progress >> >> Naali is implemented in C++ (using Qt and Ogre3D) and Python. Bindings >> for JavaScript are also planned. It is designed using a modular and >> scalable architecture, with easy repurposing for a wide variety of >> applications by simply dropping in new components. >> >> Naali is intended to work with any virtual world protocol through its >> modular architecture, however currently only support for SLUDP-based >> protocols through OpenSim are implemented. >> >> Naali comes with a reference server implementation called Taiga, >> which adds mesh-based assets, Python server-side scripting, web login >> with OpenID, and inventory over WebDAV. >> >> Naali is it true open-source project, which means the community has a >> voice in guiding the direction of the project, and commit access is >> available to contributors with a proven track record of quality >> patches. >> >> Please join us on our mailing lists: >> http://groups.google.com/group/realxtend >> http://groups.google.com/group/realxtend-dev >> >> Or on IRC, on Freenode >> #realxtend >> #realxtend-dev >> >> More information can be found on our website: >> http://wiki.realxtend.org/index.php/Main_Page >> >> Ryan McDougall >> http://www.realxtend.org >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100209/be70059d/attachment.htm From sempuki1 at gmail.com Tue Feb 9 09:46:28 2010 From: sempuki1 at gmail.com (Ryan McDougall) Date: Tue, 9 Feb 2010 19:46:28 +0200 Subject: [opensource-dev] Announce: realXtend Naali 0.1 (alpha) client viewer In-Reply-To: <9f4fbd5c1002090934m3dc23778w3a19ab097541f76b@mail.gmail.com> References: <824c8ab71002090927l25dc0558m9bc3db7106313fd2@mail.gmail.com> <9f4fbd5c1002090934m3dc23778w3a19ab097541f76b@mail.gmail.com> Message-ID: On Tue, Feb 9, 2010 at 7:34 PM, Jonathan Irvin wrote: > Sounds silly, but A.) Will it work in the normal Grid and B.) Work in 64-bit > linux? A) It currently doesn't support region crossing, but that should be in soon. It can log into normal OpenSim regions, but doesn't support SL avatars yet. With support, we can get these features in sooner. B) I don't see any reason why it shouldn't work on 64bit linux -- although I have to admit my fedora is probably 32bit and so probably no one has even tried. Cheers, > > On Tue, Feb 9, 2010 at 11:27, Nexii Malthus wrote: >> >> Impressive stuff, my praise goes to the realXtend team for their work. >> Going to try it out right now. >> >> - Nexii >> >> On Tue, Feb 9, 2010 at 10:02 AM, Ryan McDougall >> wrote: >>> >>> realXtend is proud to announce the first major alpha release of its >>> groundbreaking multi-use virtual world client viewer, Naali. We are >>> hoping this release will see widespread user testing, to help us >>> refine and improve our work. Naali is alpha software and missing many >>> features, but we hope, with your feedback, to make Naali the "Firefox" >>> of virtual worlds. >>> >>> Demo video can be found here: http://www.youtube.com/watch?v=4iiE66hY-RU >>> >>> Both source code and binaries can be found on our project website: >>> http://code.google.com/p/realxtend-naali/ >>> >>> Naali is released under the Apache 2.0 software license, and available >>> for the following platforms: >>> >>> * Windows: Binary installer >>> * Linux: Full source and build instructions >>> * Mac: In progress >>> >>> Naali is implemented in C++ (using Qt and Ogre3D) and Python. Bindings >>> for JavaScript are also planned. It is designed using a modular and >>> scalable architecture, with easy repurposing for a wide variety of >>> applications by simply dropping in new components. >>> >>> Naali is intended to work with any virtual world protocol through its >>> modular architecture, however currently only support for SLUDP-based >>> protocols through OpenSim are implemented. >>> >>> Naali comes with a reference server implementation called Taiga, >>> which adds mesh-based assets, Python server-side scripting, web login >>> with OpenID, and inventory over WebDAV. >>> >>> Naali is it true open-source project, which means the community has a >>> voice in guiding the direction of the project, and commit access is >>> available to contributors with a proven track record of quality >>> patches. >>> >>> Please join us on our mailing lists: >>> http://groups.google.com/group/realxtend >>> http://groups.google.com/group/realxtend-dev >>> >>> Or on IRC, on Freenode >>> #realxtend >>> #realxtend-dev >>> >>> More information can be found on our website: >>> http://wiki.realxtend.org/index.php/Main_Page >>> >>> Ryan McDougall >>> http://www.realxtend.org >>> _______________________________________________ >>> 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 > > From foxsanyosuke at gmail.com Tue Feb 9 10:29:04 2010 From: foxsanyosuke at gmail.com (=?ISO-8859-1?Q?FoxSan_Yosuk=E9?=) Date: Tue, 9 Feb 2010 19:29:04 +0100 Subject: [opensource-dev] Announce: realXtend Naali 0.1 (alpha) client viewer In-Reply-To: References: <824c8ab71002090927l25dc0558m9bc3db7106313fd2@mail.gmail.com> <9f4fbd5c1002090934m3dc23778w3a19ab097541f76b@mail.gmail.com> Message-ID: WOW. JUST WOW. (and all in caps and both thumbs up!) While testing it I noticed an alpha issue ( http://www.foxsan.com/naali/alpha.jpg) but I need to be sure that it's caused by the viewer and not by me due to some wrong setting. Thank you for the work! :D FoxSan 2010/2/9 Ryan McDougall > On Tue, Feb 9, 2010 at 7:34 PM, Jonathan Irvin > wrote: > > Sounds silly, but A.) Will it work in the normal Grid and B.) Work in > 64-bit > > linux? > > A) It currently doesn't support region crossing, but that should be in > soon. It can log into normal OpenSim regions, but doesn't support SL > avatars yet. With support, we can get these features in sooner. > > B) I don't see any reason why it shouldn't work on 64bit linux -- > although I have to admit my fedora is probably 32bit and so probably > no one has even tried. > > Cheers, > > > > > On Tue, Feb 9, 2010 at 11:27, Nexii Malthus > wrote: > >> > >> Impressive stuff, my praise goes to the realXtend team for their work. > >> Going to try it out right now. > >> > >> - Nexii > >> > >> On Tue, Feb 9, 2010 at 10:02 AM, Ryan McDougall > >> wrote: > >>> > >>> realXtend is proud to announce the first major alpha release of its > >>> groundbreaking multi-use virtual world client viewer, Naali. We are > >>> hoping this release will see widespread user testing, to help us > >>> refine and improve our work. Naali is alpha software and missing many > >>> features, but we hope, with your feedback, to make Naali the "Firefox" > >>> of virtual worlds. > >>> > >>> Demo video can be found here: > http://www.youtube.com/watch?v=4iiE66hY-RU > >>> > >>> Both source code and binaries can be found on our project website: > >>> http://code.google.com/p/realxtend-naali/ > >>> > >>> Naali is released under the Apache 2.0 software license, and available > >>> for the following platforms: > >>> > >>> * Windows: Binary installer > >>> * Linux: Full source and build instructions > >>> * Mac: In progress > >>> > >>> Naali is implemented in C++ (using Qt and Ogre3D) and Python. Bindings > >>> for JavaScript are also planned. It is designed using a modular and > >>> scalable architecture, with easy repurposing for a wide variety of > >>> applications by simply dropping in new components. > >>> > >>> Naali is intended to work with any virtual world protocol through its > >>> modular architecture, however currently only support for SLUDP-based > >>> protocols through OpenSim are implemented. > >>> > >>> Naali comes with a reference server implementation called Taiga, > >>> which adds mesh-based assets, Python server-side scripting, web login > >>> with OpenID, and inventory over WebDAV. > >>> > >>> Naali is it true open-source project, which means the community has a > >>> voice in guiding the direction of the project, and commit access is > >>> available to contributors with a proven track record of quality > >>> patches. > >>> > >>> Please join us on our mailing lists: > >>> http://groups.google.com/group/realxtend > >>> http://groups.google.com/group/realxtend-dev > >>> > >>> Or on IRC, on Freenode > >>> #realxtend > >>> #realxtend-dev > >>> > >>> More information can be found on our website: > >>> http://wiki.realxtend.org/index.php/Main_Page > >>> > >>> Ryan McDougall > >>> http://www.realxtend.org > >>> _______________________________________________ > >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100209/bbb233ad/attachment.htm From aleric.inglewood at gmail.com Thu Feb 11 08:59:05 2010 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Thu, 11 Feb 2010 17:59:05 +0100 Subject: [opensource-dev] State machine class Message-ID: <1e01733d1002110859h28515fffqb1c53b1ef2859aaf@mail.gmail.com> Hi, with the eye on supporting plugins, I'd like to add a 'tool' to the viewer: A state machine. I'd add a base class from which others can derive their own classes. A new state machine would then be started by creating one or more objects of those types. It would be a class that supports a chain of asynchronous actions (and queries). The object would run in the main thread and be called under the "Idle" header (fasttimers). The object will know an 'idle' state (when it's waiting for data) during which it will use no significant CPU. The user (developer, you) would provide an enum with states for your object and switch between states by calling a method (ie, set_state(new_state)). If it is necessary to wait, you can call the idle() method, which will idle until data is available (detected elsewhere) causing the state machine to continue the current state. As an example, consider a series of actions like walking to a certain place, creating a prim there (or rezzing something) and then sitting on it. Or, wanting to do some calculation on a number of selected prims (for which you have to wait till all data of the selected prims has arrived). Well... the applications are limitless of course; just what plugins need ;). It won't be ALL that is needed for plugins, but it would be a good start, because this isn't wirrten/available before someone starts to write something for a plugin, the wheel will be reinvented over and over again. Any comments? :) Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100211/449890cd/attachment.htm From kck325 at gmail.com Thu Feb 11 13:52:05 2010 From: kck325 at gmail.com (chandra kiran kuchi) Date: Thu, 11 Feb 2010 16:52:05 -0500 Subject: [opensource-dev] [help] linux build errors. Message-ID: Hello All, I am getting the following error, with latest sl build. Please help me if any body know solution to this. [ 1%] Building CXX object llcharacter/CMakeFiles/llcharacter.dir/llanimationstates.o In file included from /usr/include/c++/4.4/ext/hash_map:59, from /media/disk-2/linux-linden/linden/indra/llcommon/llstringtable.h:54, from /media/disk-2/linux-linden/linden/indra/llcommon/string_table.h:32, from /media/disk-2/linux-linden/linden/indra/llmessage/llnamevalue.h:50, from /media/disk-2/linux-linden/linden/indra/llmessage/llassetstorage.h:41, from /media/disk-2/linux-linden/linden/indra/llaudio/audioengine.cpp:46: /usr/include/c++/4.4/backward/backward_warning.h:28:2: error: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. I am on kubuntu. -- Regards, Chandra K Kuchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100211/5fc9d994/attachment.htm From tayra.dagostino at gmail.com Thu Feb 11 14:02:41 2010 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Thu, 11 Feb 2010 23:02:41 +0100 Subject: [opensource-dev] freeze and locks Message-ID: <20100211230241.4f78510d.tayra.dagostino@gmail.com> Snowglobe 1.3.1 (3125) Feb 5 2010 09:41:34 (Snowglobe Release) putting master volume to 0 viewer hang and freeze, fps fall from 80fps to 4fps.... no valuable warnings or error in debug console... any repro? From lenglish5 at cox.net Thu Feb 11 14:35:44 2010 From: lenglish5 at cox.net (Lawson English) Date: Thu, 11 Feb 2010 15:35:44 -0700 Subject: [opensource-dev] Progress with squeak to SL media plugin (hooray) Message-ID: <4B748640.9030904@cox.net> So, now I can render OpenGL using squeak smalltalk,and do a glCopyPixels to a shared memory buffer ala the SL media plugin's. Benchmark 1000 1000x1000x4 byte glcopypixels in ~6 seconds, or roughly 160 FPS So a peer to peer plugin for a smalltalk (or other graphics) app could send data from plugin to plugin and get full native OS speed without the overhead of VNC. Realtime whiteboards with no delay. Stream the graphics to the audience via a normal html on a prim QT movie, and you have the best of both worlds: realtime collab between avatars, and unlimited numbers in the audience. With different aspects of SL exposed to such a plugin, you could have collaborative puppeteering and such, as well. Next up: drawing from Squeak to SL plugin tester. Then p2p between 2 people using the SL plugin tester. Etc. Lawson From HRuss at z-techcorp.com Thu Feb 11 14:41:01 2010 From: HRuss at z-techcorp.com (Russ, Howell) Date: Thu, 11 Feb 2010 17:41:01 -0500 Subject: [opensource-dev] freeze and locks Message-ID: <2CD219EF184F3142900E448782AB3F05021A822E@NTGEXMB04.icf-hq.icfconsulting.com> Unsubscribe ----- Original Message ----- From: opensource-dev-bounces at lists.secondlife.com To: opensource-dev at lists.secondlife.com Sent: Thu Feb 11 16:02:41 2010 Subject: [opensource-dev] freeze and locks Snowglobe 1.3.1 (3125) Feb 5 2010 09:41:34 (Snowglobe Release) putting master volume to 0 viewer hang and freeze, fps fall from 80fps to 4fps.... no valuable warnings or error in debug console... any repro? _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100211/bb9a6aa1/attachment.htm From HRuss at z-techcorp.com Thu Feb 11 14:41:17 2010 From: HRuss at z-techcorp.com (Russ, Howell) Date: Thu, 11 Feb 2010 17:41:17 -0500 Subject: [opensource-dev] [help] linux build errors. Message-ID: <2CD219EF184F3142900E448782AB3F05021A822F@NTGEXMB04.icf-hq.icfconsulting.com> Unsubscribe ________________________________ From: opensource-dev-bounces at lists.secondlife.com To: opensource-dev at lists.secondlife.com Sent: Thu Feb 11 15:52:05 2010 Subject: [opensource-dev] [help] linux build errors. Hello All, I am getting the following error, with latest sl build. Please help me if any body know solution to this. [ 1%] Building CXX object llcharacter/CMakeFiles/llcharacter.dir/llanimationstates.o In file included from /usr/include/c++/4.4/ext/hash_map:59, from /media/disk-2/linux-linden/linden/indra/llcommon/llstringtable.h:54, from /media/disk-2/linux-linden/linden/indra/llcommon/string_table.h:32, from /media/disk-2/linux-linden/linden/indra/llmessage/llnamevalue.h:50, from /media/disk-2/linux-linden/linden/indra/llmessage/llassetstorage.h:41, from /media/disk-2/linux-linden/linden/indra/llaudio/audioengine.cpp:46: /usr/include/c++/4.4/backward/backward_warning.h:28:2: error: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. I am on kubuntu. -- Regards, Chandra K Kuchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100211/2686b718/attachment.htm From HRuss at z-techcorp.com Thu Feb 11 14:42:31 2010 From: HRuss at z-techcorp.com (Russ, Howell) Date: Thu, 11 Feb 2010 17:42:31 -0500 Subject: [opensource-dev] freeze and locks Message-ID: <2CD219EF184F3142900E448782AB3F05021A8231@NTGEXMB04.icf-hq.icfconsulting.com> Unsubscribe ________________________________ From: opensource-dev-bounces at lists.secondlife.com To: tayra.dagostino at gmail.com ; opensource-dev at lists.secondlife.com Sent: Thu Feb 11 16:41:01 2010 Subject: Re: [opensource-dev] freeze and locks Unsubscribe ----- Original Message ----- From: opensource-dev-bounces at lists.secondlife.com To: opensource-dev at lists.secondlife.com Sent: Thu Feb 11 16:02:41 2010 Subject: [opensource-dev] freeze and locks Snowglobe 1.3.1 (3125) Feb 5 2010 09:41:34 (Snowglobe Release) putting master volume to 0 viewer hang and freeze, fps fall from 80fps to 4fps.... no valuable warnings or error in debug console... any repro? _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100211/37e5e257/attachment-0001.htm From HRuss at z-techcorp.com Thu Feb 11 14:42:43 2010 From: HRuss at z-techcorp.com (Russ, Howell) Date: Thu, 11 Feb 2010 17:42:43 -0500 Subject: [opensource-dev] [help] linux build errors. Message-ID: <2CD219EF184F3142900E448782AB3F05021A8232@NTGEXMB04.icf-hq.icfconsulting.com> Unsubscribe ________________________________ From: Russ, Howell To: 'kck325 at gmail.com' ; 'opensource-dev at lists.secondlife.com' Sent: Thu Feb 11 16:41:17 2010 Subject: Re: [opensource-dev] [help] linux build errors. Unsubscribe ________________________________ From: opensource-dev-bounces at lists.secondlife.com To: opensource-dev at lists.secondlife.com Sent: Thu Feb 11 15:52:05 2010 Subject: [opensource-dev] [help] linux build errors. Hello All, I am getting the following error, with latest sl build. Please help me if any body know solution to this. [ 1%] Building CXX object llcharacter/CMakeFiles/llcharacter.dir/llanimationstates.o In file included from /usr/include/c++/4.4/ext/hash_map:59, from /media/disk-2/linux-linden/linden/indra/llcommon/llstringtable.h:54, from /media/disk-2/linux-linden/linden/indra/llcommon/string_table.h:32, from /media/disk-2/linux-linden/linden/indra/llmessage/llnamevalue.h:50, from /media/disk-2/linux-linden/linden/indra/llmessage/llassetstorage.h:41, from /media/disk-2/linux-linden/linden/indra/llaudio/audioengine.cpp:46: /usr/include/c++/4.4/backward/backward_warning.h:28:2: error: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. I am on kubuntu. -- Regards, Chandra K Kuchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100211/910aed73/attachment.htm From HRuss at z-techcorp.com Thu Feb 11 14:42:53 2010 From: HRuss at z-techcorp.com (Russ, Howell) Date: Thu, 11 Feb 2010 17:42:53 -0500 Subject: [opensource-dev] freeze and locks Message-ID: <2CD219EF184F3142900E448782AB3F05021A8233@NTGEXMB04.icf-hq.icfconsulting.com> Unsubscribe ----- Original Message ----- From: Russ, Howell To: 'tayra.dagostino at gmail.com' ; 'opensource-dev at lists.secondlife.com' Sent: Thu Feb 11 16:41:01 2010 Subject: Re: [opensource-dev] freeze and locks Unsubscribe ----- Original Message ----- From: opensource-dev-bounces at lists.secondlife.com To: opensource-dev at lists.secondlife.com Sent: Thu Feb 11 16:02:41 2010 Subject: [opensource-dev] freeze and locks Snowglobe 1.3.1 (3125) Feb 5 2010 09:41:34 (Snowglobe Release) putting master volume to 0 viewer hang and freeze, fps fall from 80fps to 4fps.... no valuable warnings or error in debug console... any repro? _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100211/a561cd41/attachment.htm From HRuss at z-techcorp.com Thu Feb 11 14:42:20 2010 From: HRuss at z-techcorp.com (Russ, Howell) Date: Thu, 11 Feb 2010 17:42:20 -0500 Subject: [opensource-dev] [help] linux build errors. Message-ID: <2CD219EF184F3142900E448782AB3F05021A8230@NTGEXMB04.icf-hq.icfconsulting.com> Unsubscribe ________________________________ From: opensource-dev-bounces at lists.secondlife.com To: kck325 at gmail.com ; opensource-dev at lists.secondlife.com Sent: Thu Feb 11 16:41:17 2010 Subject: Re: [opensource-dev] [help] linux build errors. Unsubscribe ________________________________ From: opensource-dev-bounces at lists.secondlife.com To: opensource-dev at lists.secondlife.com Sent: Thu Feb 11 15:52:05 2010 Subject: [opensource-dev] [help] linux build errors. Hello All, I am getting the following error, with latest sl build. Please help me if any body know solution to this. [ 1%] Building CXX object llcharacter/CMakeFiles/llcharacter.dir/llanimationstates.o In file included from /usr/include/c++/4.4/ext/hash_map:59, from /media/disk-2/linux-linden/linden/indra/llcommon/llstringtable.h:54, from /media/disk-2/linux-linden/linden/indra/llcommon/string_table.h:32, from /media/disk-2/linux-linden/linden/indra/llmessage/llnamevalue.h:50, from /media/disk-2/linux-linden/linden/indra/llmessage/llassetstorage.h:41, from /media/disk-2/linux-linden/linden/indra/llaudio/audioengine.cpp:46: /usr/include/c++/4.4/backward/backward_warning.h:28:2: error: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. I am on kubuntu. -- Regards, Chandra K Kuchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100211/fbe80d38/attachment.htm From sempuki1 at gmail.com Fri Feb 12 01:31:08 2010 From: sempuki1 at gmail.com (Ryan McDougall) Date: Fri, 12 Feb 2010 11:31:08 +0200 Subject: [opensource-dev] Naali UI research Message-ID: We made a blog post about some of our UI research. http://realxtend.blogspot.com/2010/02/new-ui-in-development.html Short video here: http://www.youtube.com/watch?v=LbKb-jSk3zY "Ether" drop-down will replace login and teleport screens. Comments from developers/designers requested. Apologies for the cross-posting. Please don't hit "Reply All". Cheers, From djfoxyslpr at gmail.com Fri Feb 12 04:53:05 2010 From: djfoxyslpr at gmail.com (Jonathan Irvin) Date: Fri, 12 Feb 2010 06:53:05 -0600 Subject: [opensource-dev] Product Testing Message-ID: <9f4fbd5c1002120453k502a3b9co2878cdad21644227@mail.gmail.com> I'm looking for a few people to test a product of mine, maybe help with some documentation (if you want).You can get it off of XStreet for free. https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=2101874If you aren't able to get a copy (due to it running out), just let me know via email in here, or send me an IM in-world @ Jon Desmoulins. I'm mainly looking for some usability suggestions, generic testing, or whatever you are willing to do. Hell, if you just want a copy and want to throw some ideas my way, that works too. I'm also looking for some help with documentation. I find that documentation is better when the creator doesn't do it. I don't want to have that sound like a cop out, I do all my own documentation, but it's always more understandable collaborating with others. Thanks for the help guys -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100212/4eba5601/attachment.htm From robin.cornelius at gmail.com Fri Feb 12 11:59:17 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri, 12 Feb 2010 19:59:17 +0000 Subject: [opensource-dev] Snowglobe 1.3 Deadlock..again Message-ID: Oh no its still happening, thanks to Opensource Obscure for the back traces. This time its a different interaction to SNOW-196. It seems this is a less common deadlock for most people but there are a few still getting it and Opensource seems to get it very repeatably. What appears to be happening is that two worker threads are running on the same image, one is doing a LLImageDecodeThread::Responder::Complete() and the other is trying to start a new decode via LLTextureFetch::doWork(). So i guess this situation can occur after you have decoded one discard level and new data has appeared and another discard level has been achieved so a new decode has been started. When then combined with a specific test on the main thread we get a 3 way deadlock :- Thread 1 LLTextureFetch::getRequestFinished() - Locking mQueueMutex Spinning on mWorkMutex Thread 3 LLImageDecodeThread::Responder::Complete() Locking LLThread->mRunCondition Spinningon mQueueMutex Thread 5 LLTextureFetch::doWork() Locking mWorkMutex Locking mCreationMutex Spinning On LLThread->mRunCondition Threads 3 and 5 are both ending up with a LLThread that is instanced as a LLImageDecodeThread (with the same this pointer for #3 and #5) so the LLThread->mRunCondition lock is locking those two. I would have not though that threads 3 and 5 should be running at the same time on the same LLThread * ? why isn't the mRunCondition mutext locking that? Any comments? From sllists at boroon.dasgupta.ch Sat Feb 13 06:57:17 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 13 Feb 2010 15:57:17 +0100 Subject: [opensource-dev] [help] linux build errors. In-Reply-To: References: Message-ID: <4B76BDCD.6070206@boroon.dasgupta.ch> chandra kiran kuchi schrieb: > I am getting the following error, with latest sl build. Please help me > if any body know solution to this. > > [ 1%] Building CXX object > llcharacter/CMakeFiles/llcharacter.dir/llanimationstates.o > > In file included from > /usr/include/c++/4.4/ext/hash_map:59, > > from > /media/disk-2/linux-linden/linden/indra/llcommon/llstringtable.h:54, Hi Chandra what source branch and version are you using? It looks like it doesn't have the fix from https://jira.secondlife.com/browse/SNOW-195, yet. Though, both current Snowglobe trunk and current Second Life Viewer trunk both have that. cheers Boroondas From kck325 at gmail.com Sat Feb 13 08:25:54 2010 From: kck325 at gmail.com (chandra kiran kuchi) Date: Sat, 13 Feb 2010 11:25:54 -0500 Subject: [opensource-dev] [help] linux build errors. In-Reply-To: <4B76BDCD.6070206@boroon.dasgupta.ch> References: <4B76BDCD.6070206@boroon.dasgupta.ch> Message-ID: I am using latest branch of slviewer, obtained from slwiki page. I found workaround, I had this in almost every llsubdirectory, I had to add -Wno-deprecated and -Wno-parantheses flags to avoid this mistakes. Right now I am stuck up at some boost and glib2.0 related errors. Thank you. On Sat, Feb 13, 2010 at 9:57 AM, Boroondas Gupte wrote: > chandra kiran kuchi schrieb: > > I am getting the following error, with latest sl build. Please help me > > if any body know solution to this. > > > > [ 1%] Building CXX object > > llcharacter/CMakeFiles/llcharacter.dir/llanimationstates.o > > > > In file included from > > /usr/include/c++/4.4/ext/hash_map:59, > > > > from > > /media/disk-2/linux-linden/linden/indra/llcommon/llstringtable.h:54, > > Hi Chandra > > what source branch and version are you using? It looks like it doesn't > have the fix from https://jira.secondlife.com/browse/SNOW-195, yet. > Though, both current Snowglobe trunk and current Second Life Viewer > trunk both have that. > > cheers > Boroondas > -- Regards, Chandra K Kuchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100213/0dabde3a/attachment.htm From mahmoudahmedismail at gmail.com Sun Feb 14 08:44:17 2010 From: mahmoudahmedismail at gmail.com (Mahmoud Ismail) Date: Sun, 14 Feb 2010 18:44:17 +0200 Subject: [opensource-dev] retrieving scripts attached to an object Message-ID: Hi all, as a proof of concept i was creating a floater which instantiated by a button on the Pie Menu in that floater i've created a Button in which i was try to get all inventory items attached to the selected object but, i found that it gives no script items although there're two script files "Note: i didn't open these files just press on New Script" now, sometimes when i opened these files first then press my button it gives results here's my button code: InventoryObjectList inventory_list; object->getInventoryContents(inventory_list); llinfos<<"Loop on inv_objects "< obj=*inv_obj; llinfos<<"Type : "<getType() << " Name : "<getName()< References: <20100211230241.4f78510d.tayra.dagostino@gmail.com> Message-ID: <1e01733d1002140937n74c57f23kbd01eb1c87c72205@mail.gmail.com> Sounds like the same problem that I had related to http://jira.secondlife.com/browse/VWR-14914 Note my last remark there. Basically this is a bug in openal but we can work around it by not setting a volume to zero, but muting the channel instead (completely disabling it). On Thu, Feb 11, 2010 at 11:02 PM, Tayra Dagostino wrote: > Snowglobe 1.3.1 (3125) Feb 5 2010 09:41:34 (Snowglobe Release) > > putting master volume to 0 viewer hang and freeze, fps fall from 80fps > to 4fps.... no valuable warnings or error in debug console... > > any repro? > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100214/991e04a5/attachment.htm From aleric.inglewood at gmail.com Sun Feb 14 15:27:15 2010 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Mon, 15 Feb 2010 00:27:15 +0100 Subject: [opensource-dev] Fwd: State machine class In-Reply-To: <1e01733d1002141522u417edaafg49288782072cb1ec@mail.gmail.com> References: <1e01733d1002110859h28515fffqb1c53b1ef2859aaf@mail.gmail.com> <4B7444C9.50206@superliminal.com> <1e01733d1002141522u417edaafg49288782072cb1ec@mail.gmail.com> Message-ID: <1e01733d1002141527t4d5f7d47hbbdde8abcae1a168@mail.gmail.com> Ugh, seems this didn't go to the list... forwarding it there. ---------- Forwarded message ---------- From: Aleric Inglewood Date: Mon, Feb 15, 2010 at 12:22 AM Subject: Re: [opensource-dev] State machine class To: Melinda Green I am already using it :p. This proposal is the direct result of practical experience, showing me that this is needed. But before I start to write example code that uses it, allow me to stay abstract. Didn't get much (other) reactions, so I thought I'd add some more details. The idea is to have objects that go through a series of (usually) sequential states: CONSTRUCTOR | v INIT | v custom states --------. . | . | . v custom states ----->ABORT | | |<---------------' v DONE 'CONSTRUCTOR' would be an uninitialized state and never really executed (the 'state' variable during construction of the object). Obviously it would be in balance with it's destructor. 'INIT' would be the first state of the object when 'run'. If the whole finishes successfully, we end up in the state 'DONE', which cleanup in balance with INIT, and anything that is expected to be left over from going to the states successfully. The ABORT state is a state that will cleanup anything that might be left-over from an abort. The main thread ''runs' the object from it's 'Idle' state by calling gIdleCallbacks.addFunction(...) for this object. The main loop of such a StateMachine object would then look like something like: switch(mState) { case INIT: init(); set_state(WAIT_FOR_FOO); case WAIT_FOR_FOO; if (!foo()) idle(); set_state(DO_MORE); case DO_MORE: do_it(); set_state(WAIT_FOR_BAR); case WAIT_FOR_BAR: if (!bar()) idle(); set_state(DONE); case DONE: cleanup(); } As you see, this gives a compact and clear code where the flow is intuitive (top down), but asynchronus and "blocking", without actually blocking the main loop. One of the major advantages is these objects are reusable; for example, one could write an object that checks if some inventory folder exists, if not creates it, and then (or when it already exists) waits till it's contents are available. Lets call this object SyncFolder(std::string const& name). Then another StateMachine object can use it (for example) as follows: class MyStateMachine : public LLStateMachine { SyncFolder mSyncFolder; ... virtual void init(); virtual void abort(); virtual void done(); }; void MyStateMachine::init() { mSyncFolder.set_name(folder_name); } bool MyStateMachine::mainloop() { // INIT, DONE and ABORT are handled by the base class. switch(mState) { case WAIT_FOR_FOO: if (!foo()) idle(); set_state(SYNC_FOLDER); case SYNC_FOLDER: if (!mSyncFolder()) // Returns true when DONE break; case REZ_ITEM_FROM_FOLDER: do_rez(); } } One could create a large number of such objects that do simple tasks, and then use those to build objects that do more complex tasks. On Thu, Feb 11, 2010 at 6:56 PM, Melinda Green wrote: > Sounds like a solution in search of a problem. I suggest that in order to > get it incorporated as core, that you create at least one compelling > solution built on it that people want enough to incorporate the whole thing. > If you can't come up with one then it probably doesn't belong there because > without a compelling example, nobody is going to realize it's there or to > trust it or know how to use it. > > Just my L$5, > -Melinda > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100215/ff35c62a/attachment.htm From morgaine.dinova at googlemail.com Mon Feb 15 02:29:12 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Mon, 15 Feb 2010 10:29:12 +0000 Subject: [opensource-dev] State machine class In-Reply-To: <1e01733d1002110859h28515fffqb1c53b1ef2859aaf@mail.gmail.com> References: <1e01733d1002110859h28515fffqb1c53b1ef2859aaf@mail.gmail.com> Message-ID: State machines are very useful, but the use case you gave is an example of a user application that should be coded in an attached script. The fact that the viewer does not yet have attached client-side scripting is not a reason for putting the user application directly into the viewer. It's a reason for adding client-side scripting first. State-switching applications for the viewer would then become trivial to write as a user process, in any language of the user's choice. We were working on such a design for the viewer within AWG many moons ago --- some details are given here, and the many advantages listed: https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft . We were also examining that kind of structure for user scripts in Imprudence: http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png . We're long past the refactoring sell-by date for this excessively monolithic client. The viewer is buggy as a direct consequence of its size and bloat --- there is no escaping that relationship in today's seat-of-pants software methodologies. Adding more things into the main code should be avoided at all costs, unless those things are central to its operation. Anything that is not central should be factored out into attached processes, and this is particularly true in the case of any facility that does not have a high speed requirement, such as your example. It would avoid bloat and be much more flexible. The right question to be asking at this stage is why Lindens are currently designing client-side scripting *behind closed doors* in their internal Firefly project. *Secrecy in design should have no place in an open source viewer.* In this instance it impacts directly on your suggestion, since state switching is so easy to do in an attached user script. I believe that Firefly should be stripped of its sekrit internal status and the design addressed here in this opensource-dev community, where it belongs. Given client-side scripting, adding a state machine into the core code would then become moot. Morgaine. ====================================== On Thu, Feb 11, 2010 at 4:59 PM, Aleric Inglewood < aleric.inglewood at gmail.com> wrote: > Hi, with the eye on supporting plugins, I'd like to add a 'tool' to the > viewer: > A state machine. > > I'd add a base class from which others can derive their own classes. > A new state machine would then be started by creating one or more objects > of those types. > > It would be a class that supports a chain of asynchronous actions (and > queries). > The object would run in the main thread and be called under the "Idle" > header (fasttimers). > The object will know an 'idle' state (when it's waiting for data) during > which it will > use no significant CPU. > > The user (developer, you) would provide an enum with states for your object > and switch between states by calling a method (ie, set_state(new_state)). > If it is necessary to wait, you can call the idle() method, which will idle > until data is available (detected elsewhere) causing the state machine to > continue the current state. > > As an example, consider a series of actions like walking to a certain > place, > creating a prim there (or rezzing something) and then sitting on it. Or, > wanting > to do some calculation on a number of selected prims (for which you have to > wait till all data of the selected prims has arrived). Well... the > applications are > limitless of course; just what plugins need ;). > > It won't be ALL that is needed for plugins, but it would be a good start, > because > this isn't wirrten/available before someone starts to write something for a > plugin, > the wheel will be reinvented over and over again. > > Any comments? :) > > Aleric > > > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100215/2ff4e022/attachment.htm From aleric.inglewood at gmail.com Mon Feb 15 05:15:42 2010 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Mon, 15 Feb 2010 14:15:42 +0100 Subject: [opensource-dev] State machine class In-Reply-To: References: <1e01733d1002110859h28515fffqb1c53b1ef2859aaf@mail.gmail.com> Message-ID: <1e01733d1002150515t5be98649q7968a20ec8336305@mail.gmail.com> Morgaine, I *completely* agree with you! [?] One of the two main reasons, if not the only two, that we need this state machine approach *is* for client-side scripting and for plugins. Both are infinite flexible in nature and require in principle hooks into the viewer code to *control* the viewer on a level that goes way beyond a blocking function call. The best approach to look at this is the following: If we have to wait for a server packet, it blocks. Currently there is no general way to wait for server-packet-events, hence you *cannot* implement client-side scripting. The state machine is so core and so basic, it's the core at the basis of much MORE code that is needed before you can even start to implement client-side scripting. Thus, since it was always my main goal to use this for client-side scripting (and sorry, but any 'secret' work that I never heard of before from whoever is working on it on this list has to be ignored), I assume you now agree with me that this would a great thing to have, since it will make it possible, in the end to provide hooks into the viewer in The Right Way(tm) that will allow us to write a client-side scripting implementation, which in turn will allow plugins to be able to actually control the viewer. I don't HAVE client-side scripting yet, so I have written code that uses this state machine on a higher level, but that was just to get a feeling of what is needed. I think I'm now ready to write that base class. On Mon, Feb 15, 2010 at 11:29 AM, Morgaine wrote: > State machines are very useful, but the use case you gave is an example of > a user application that should be coded in an attached script. The fact > that the viewer does not yet have attached client-side scripting is not a > reason for putting the user application directly into the viewer. It's a > reason for adding client-side scripting first. > > State-switching applications for the viewer would then become trivial to > write as a user process, in any language of the user's choice. We were > working on such a design for the viewer within AWG many moons ago --- some > details are given here, and the many advantages listed: > https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft . We > were also examining that kind of structure for user scripts in Imprudence: > http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png . > We're long past the refactoring sell-by date for this excessively monolithic > client. > > The viewer is buggy as a direct consequence of its size and bloat --- there > is no escaping that relationship in today's seat-of-pants software > methodologies. Adding more things into the main code should be avoided at > all costs, unless those things are central to its operation. Anything that > is not central should be factored out into attached processes, and this is > particularly true in the case of any facility that does not have a high > speed requirement, such as your example. It would avoid bloat and be much > more flexible. > > The right question to be asking at this stage is why Lindens are currently > designing client-side scripting *behind closed doors* in their internal > Firefly project. *Secrecy in design should have no place in an open > source viewer.* In this instance it impacts directly on your suggestion, > since state switching is so easy to do in an attached user script. > > I believe that Firefly should be stripped of its sekrit internal status and > the design addressed here in this opensource-dev community, where it > belongs. Given client-side scripting, adding a state machine into the core > code would then become moot. > > > Morgaine. > > > > > ====================================== > > On Thu, Feb 11, 2010 at 4:59 PM, Aleric Inglewood < > aleric.inglewood at gmail.com> wrote: > >> Hi, with the eye on supporting plugins, I'd like to add a 'tool' to the >> viewer: >> A state machine. >> >> I'd add a base class from which others can derive their own classes. >> A new state machine would then be started by creating one or more objects >> of those types. >> >> It would be a class that supports a chain of asynchronous actions (and >> queries). >> The object would run in the main thread and be called under the "Idle" >> header (fasttimers). >> The object will know an 'idle' state (when it's waiting for data) during >> which it will >> use no significant CPU. >> >> The user (developer, you) would provide an enum with states for your >> object >> and switch between states by calling a method (ie, set_state(new_state)). >> If it is necessary to wait, you can call the idle() method, which will >> idle >> until data is available (detected elsewhere) causing the state machine to >> continue the current state. >> >> As an example, consider a series of actions like walking to a certain >> place, >> creating a prim there (or rezzing something) and then sitting on it. Or, >> wanting >> to do some calculation on a number of selected prims (for which you have >> to >> wait till all data of the selected prims has arrived). Well... the >> applications are >> limitless of course; just what plugins need ;). >> >> It won't be ALL that is needed for plugins, but it would be a good start, >> because >> this isn't wirrten/available before someone starts to write something for >> a plugin, >> the wheel will be reinvented over and over again. >> >> Any comments? :) >> >> Aleric >> >> >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100215/59e5521e/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 96 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100215/59e5521e/attachment-0001.gif From morgaine.dinova at googlemail.com Mon Feb 15 06:43:54 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Mon, 15 Feb 2010 14:43:54 +0000 Subject: [opensource-dev] State machine class In-Reply-To: <1e01733d1002150515t5be98649q7968a20ec8336305@mail.gmail.com> References: <1e01733d1002110859h28515fffqb1c53b1ef2859aaf@mail.gmail.com> <1e01733d1002150515t5be98649q7968a20ec8336305@mail.gmail.com> Message-ID: On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood < aleric.inglewood at gmail.com> wrote: > (sorry, but any 'secret' work that I never heard of before from whoever is > working on it on this list has to be ignored), Just because you haven't heard about something doesn't mean that others haven't. Lindens have mentioned their internal Firefly client-side scripting project at several of their Office Hours now, for example at Q Linden's. While the project name and purpose are known, the details are a closely guarded secret. This is highly inappropriate given that it will determine the structure of the open source viewer to which this list is dedicated. It's treating the opensource-dev community as nothing more than code and debug monkeys, dancing to the LL design tune. That's not a healthy relationship with open source communities. It's also out of step with claims that 2010 is going to see a new openness from Lindens. Firefly is a bad start. Client-side scripting is one of the most crucial features that the community should be discussing, because it will impact on almost everything about the viewer. It's massive. Morgaine. ================================== The most important aspect of any non-trivial software system is its design, since that determines everything else. On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood < aleric.inglewood at gmail.com> wrote: > Morgaine, I *completely* agree with you! [?] > > One of the two main reasons, if not the only two, that we need this state > machine approach *is* for client-side scripting and for plugins. Both are > infinite flexible in nature and require in principle hooks into the viewer > code to *control* the viewer on a level that goes way beyond a blocking > function call. > > The best approach to look at this is the following: If we have to wait for > a server packet, it blocks. Currently there is no general way to wait for > server-packet-events, hence you *cannot* implement client-side scripting. > > The state machine is so core and so basic, it's the core at the basis of > much MORE code that is needed before you can even start to implement > client-side scripting. > > Thus, since it was always my main goal to use this for client-side > scripting (and sorry, but any 'secret' work that I never heard of before > from whoever is working on it on this list has to be ignored), I assume you > now agree with me that this would a great thing to have, since it will make > it possible, in the end to provide hooks into the viewer in The Right > Way(tm) that will allow us to write a client-side scripting implementation, > which in turn will allow plugins to be able to actually control the viewer. > > I don't HAVE client-side scripting yet, so I have written code that uses > this state machine on a higher level, but that was just to get a feeling of > what is needed. I think I'm now ready to write that base class. > > > On Mon, Feb 15, 2010 at 11:29 AM, Morgaine > wrote: > >> State machines are very useful, but the use case you gave is an example of >> a user application that should be coded in an attached script. The fact >> that the viewer does not yet have attached client-side scripting is not a >> reason for putting the user application directly into the viewer. It's a >> reason for adding client-side scripting first. >> >> State-switching applications for the viewer would then become trivial to >> write as a user process, in any language of the user's choice. We were >> working on such a design for the viewer within AWG many moons ago --- some >> details are given here, and the many advantages listed: >> https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft . We >> were also examining that kind of structure for user scripts in Imprudence: >> http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png . >> We're long past the refactoring sell-by date for this excessively monolithic >> client. >> >> The viewer is buggy as a direct consequence of its size and bloat --- >> there is no escaping that relationship in today's seat-of-pants software >> methodologies. Adding more things into the main code should be avoided at >> all costs, unless those things are central to its operation. Anything that >> is not central should be factored out into attached processes, and this is >> particularly true in the case of any facility that does not have a high >> speed requirement, such as your example. It would avoid bloat and be much >> more flexible. >> >> The right question to be asking at this stage is why Lindens are currently >> designing client-side scripting *behind closed doors* in their internal >> Firefly project. *Secrecy in design should have no place in an open >> source viewer.* In this instance it impacts directly on your suggestion, >> since state switching is so easy to do in an attached user script. >> >> I believe that Firefly should be stripped of its sekrit internal status >> and the design addressed here in this opensource-dev community, where it >> belongs. Given client-side scripting, adding a state machine into the core >> code would then become moot. >> >> >> Morgaine. >> >> >> >> >> ====================================== >> >> On Thu, Feb 11, 2010 at 4:59 PM, Aleric Inglewood < >> aleric.inglewood at gmail.com> wrote: >> >>> Hi, with the eye on supporting plugins, I'd like to add a 'tool' to the >>> viewer: >>> A state machine. >>> >>> I'd add a base class from which others can derive their own classes. >>> A new state machine would then be started by creating one or more objects >>> of those types. >>> >>> It would be a class that supports a chain of asynchronous actions (and >>> queries). >>> The object would run in the main thread and be called under the "Idle" >>> header (fasttimers). >>> The object will know an 'idle' state (when it's waiting for data) during >>> which it will >>> use no significant CPU. >>> >>> The user (developer, you) would provide an enum with states for your >>> object >>> and switch between states by calling a method (ie, set_state(new_state)). >>> If it is necessary to wait, you can call the idle() method, which will >>> idle >>> until data is available (detected elsewhere) causing the state machine to >>> continue the current state. >>> >>> As an example, consider a series of actions like walking to a certain >>> place, >>> creating a prim there (or rezzing something) and then sitting on it. Or, >>> wanting >>> to do some calculation on a number of selected prims (for which you have >>> to >>> wait till all data of the selected prims has arrived). Well... the >>> applications are >>> limitless of course; just what plugins need ;). >>> >>> It won't be ALL that is needed for plugins, but it would be a good start, >>> because >>> this isn't wirrten/available before someone starts to write something for >>> a plugin, >>> the wheel will be reinvented over and over again. >>> >>> Any comments? :) >>> >>> Aleric >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100215/9b894ff7/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 96 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100215/9b894ff7/attachment.gif From mahmoudahmedismail at gmail.com Mon Feb 15 06:47:14 2010 From: mahmoudahmedismail at gmail.com (Mahmoud Ismail) Date: Mon, 15 Feb 2010 16:47:14 +0200 Subject: [opensource-dev] retrieving scripts attached to an object In-Reply-To: References: Message-ID: Hi all, as a proof of concept i was creating a floater which instantiated by a button on the Pie Menu in that floater i've created a Button in which i was try to get all inventory items attached to the selected object but, i found that it gives no script items although there're two script files "Note: i didn't open these files just press on New Script" now, sometimes when i opened these files first then press my button it gives results here's my button code: InventoryObjectList inventory_list; object->getInventoryContents(inventory_list); llinfos<<"Loop on inv_objects "< obj=*inv_obj; llinfos<<"Type : "<getType() << " Name : "<getName()< References: <1e01733d1002110859h28515fffqb1c53b1ef2859aaf@mail.gmail.com> <1e01733d1002150515t5be98649q7968a20ec8336305@mail.gmail.com> Message-ID: On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood < aleric.inglewood at gmail.com> wrote: > Morgaine, I *completely* agree with you! [?] > > One of the two main reasons, if not the only two, that we need this state > machine approach *is* for client-side scripting and for plugins. Both are > infinite flexible in nature and require in principle hooks into the viewer > code to *control* the viewer on a level that goes way beyond a blocking > function call. > > The best approach to look at this is the following: If we have to wait for > a server packet, it blocks. Currently there is no general way to wait for > server-packet-events, hence you *cannot* implement client-side scripting. > > The state machine is so core and so basic, it's the core at the basis of > much MORE code that is needed before you can even start to implement > client-side scripting. > **IFF** a state machine is required infrastructure in the viewer code before client-side scripting can be implemented, then I agree with you wholeheartedly. That claim has not yet been justified though. I would be * very* interested in seeing a design for client-side scripting that is based on a core state machine. The designs that I have been looking at do not require a state machine, because they use a stateless core. All state is maintained in the scripts themselves, and the viewer core doesn't need to be concerned with their state. It's much cleaner because the scripts can use normal blocking calls in normal languages --- all that comes for free with external processes, and benefits automatically from multiple cores. It's not the only way to skin a cat though, so I welcome discussion about alternative approaches. Assuming of course that Lindens open up the design process for client-side scripting in the first place ... Morgaine ============================================ On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood < aleric.inglewood at gmail.com> wrote: > Morgaine, I *completely* agree with you! [?] > > One of the two main reasons, if not the only two, that we need this state > machine approach *is* for client-side scripting and for plugins. Both are > infinite flexible in nature and require in principle hooks into the viewer > code to *control* the viewer on a level that goes way beyond a blocking > function call. > > The best approach to look at this is the following: If we have to wait for > a server packet, it blocks. Currently there is no general way to wait for > server-packet-events, hence you *cannot* implement client-side scripting. > > The state machine is so core and so basic, it's the core at the basis of > much MORE code that is needed before you can even start to implement > client-side scripting. > > Thus, since it was always my main goal to use this for client-side > scripting (and sorry, but any 'secret' work that I never heard of before > from whoever is working on it on this list has to be ignored), I assume you > now agree with me that this would a great thing to have, since it will make > it possible, in the end to provide hooks into the viewer in The Right > Way(tm) that will allow us to write a client-side scripting implementation, > which in turn will allow plugins to be able to actually control the viewer. > > I don't HAVE client-side scripting yet, so I have written code that uses > this state machine on a higher level, but that was just to get a feeling of > what is needed. I think I'm now ready to write that base class. > > > On Mon, Feb 15, 2010 at 11:29 AM, Morgaine > wrote: > >> State machines are very useful, but the use case you gave is an example of >> a user application that should be coded in an attached script. The fact >> that the viewer does not yet have attached client-side scripting is not a >> reason for putting the user application directly into the viewer. It's a >> reason for adding client-side scripting first. >> >> State-switching applications for the viewer would then become trivial to >> write as a user process, in any language of the user's choice. We were >> working on such a design for the viewer within AWG many moons ago --- some >> details are given here, and the many advantages listed: >> https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft . We >> were also examining that kind of structure for user scripts in Imprudence: >> http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png . >> We're long past the refactoring sell-by date for this excessively monolithic >> client. >> >> The viewer is buggy as a direct consequence of its size and bloat --- >> there is no escaping that relationship in today's seat-of-pants software >> methodologies. Adding more things into the main code should be avoided at >> all costs, unless those things are central to its operation. Anything that >> is not central should be factored out into attached processes, and this is >> particularly true in the case of any facility that does not have a high >> speed requirement, such as your example. It would avoid bloat and be much >> more flexible. >> >> The right question to be asking at this stage is why Lindens are currently >> designing client-side scripting *behind closed doors* in their internal >> Firefly project. *Secrecy in design should have no place in an open >> source viewer.* In this instance it impacts directly on your suggestion, >> since state switching is so easy to do in an attached user script. >> >> I believe that Firefly should be stripped of its sekrit internal status >> and the design addressed here in this opensource-dev community, where it >> belongs. Given client-side scripting, adding a state machine into the core >> code would then become moot. >> >> >> Morgaine. >> >> >> >> >> ====================================== >> >> On Thu, Feb 11, 2010 at 4:59 PM, Aleric Inglewood < >> aleric.inglewood at gmail.com> wrote: >> >>> Hi, with the eye on supporting plugins, I'd like to add a 'tool' to the >>> viewer: >>> A state machine. >>> >>> I'd add a base class from which others can derive their own classes. >>> A new state machine would then be started by creating one or more objects >>> of those types. >>> >>> It would be a class that supports a chain of asynchronous actions (and >>> queries). >>> The object would run in the main thread and be called under the "Idle" >>> header (fasttimers). >>> The object will know an 'idle' state (when it's waiting for data) during >>> which it will >>> use no significant CPU. >>> >>> The user (developer, you) would provide an enum with states for your >>> object >>> and switch between states by calling a method (ie, set_state(new_state)). >>> If it is necessary to wait, you can call the idle() method, which will >>> idle >>> until data is available (detected elsewhere) causing the state machine to >>> continue the current state. >>> >>> As an example, consider a series of actions like walking to a certain >>> place, >>> creating a prim there (or rezzing something) and then sitting on it. Or, >>> wanting >>> to do some calculation on a number of selected prims (for which you have >>> to >>> wait till all data of the selected prims has arrived). Well... the >>> applications are >>> limitless of course; just what plugins need ;). >>> >>> It won't be ALL that is needed for plugins, but it would be a good start, >>> because >>> this isn't wirrten/available before someone starts to write something for >>> a plugin, >>> the wheel will be reinvented over and over again. >>> >>> Any comments? :) >>> >>> Aleric >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100215/6c2fc546/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 96 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100215/6c2fc546/attachment-0001.gif From morgaine.dinova at googlemail.com Mon Feb 15 08:15:46 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Mon, 15 Feb 2010 16:15:46 +0000 Subject: [opensource-dev] Fwd: State machine class In-Reply-To: <1e01733d1002141527t4d5f7d47hbbdde8abcae1a168@mail.gmail.com> References: <1e01733d1002110859h28515fffqb1c53b1ef2859aaf@mail.gmail.com> <4B7444C9.50206@superliminal.com> <1e01733d1002141522u417edaafg49288782072cb1ec@mail.gmail.com> <1e01733d1002141527t4d5f7d47hbbdde8abcae1a168@mail.gmail.com> Message-ID: That's a very hard-wired approach, and it achieves nothing that cannot be done much more simply and safely in user scripting processes. When things go wrong with scripts, you don't want them going wrong in the core viewer. A bad script running as an external process can simply be terminated --- that's a much cleaner and safer approach. What's more, your method handles only the simplest of state scripting requirements directly, because the state switching conditions will necessarily be of limited complexity and predefined in C++ code --- the scripts themselves would have to set up more complex conditional triggers on the fly by orchestrating multiple sub-states. That is totally unnecessary, and a weak approach. If you let each script maintain its own state in the normal manner for sequential programs, and merely send it the events to which it has subscribed, then the script can implement arbitrary conditional state switching very simply using conventional programming. Morgaine. ================================ On Sun, Feb 14, 2010 at 11:27 PM, Aleric Inglewood < aleric.inglewood at gmail.com> wrote: > Ugh, seems this didn't go to the list... forwarding it there. > > ---------- Forwarded message ---------- > From: Aleric Inglewood > Date: Mon, Feb 15, 2010 at 12:22 AM > Subject: Re: [opensource-dev] State machine class > To: Melinda Green > > > I am already using it :p. > This proposal is the direct result of practical experience, showing me that > this is needed. > > But before I start to write example code that uses it, allow me to stay > abstract. > > Didn't get much (other) reactions, so I thought I'd add some more details. > > The idea is to have objects that go through a series of (usually) > sequential states: > > CONSTRUCTOR > | > v > INIT > | > v > custom states --------. > . | > . | > . v > custom states ----->ABORT > | | > |<---------------' > v > DONE > > > 'CONSTRUCTOR' would be an uninitialized state and never really executed > (the 'state' variable during construction of the object). Obviously it > would > be in balance with it's destructor. > > 'INIT' would be the first state of the object when 'run'. > If the whole finishes successfully, we end up in the state 'DONE', > which cleanup in balance with INIT, and anything that is expected > to be left over from going to the states successfully. > > The ABORT state is a state that will cleanup anything that might > be left-over from an abort. > > The main thread ''runs' the object from it's 'Idle' state by calling > gIdleCallbacks.addFunction(...) for this object. > > The main loop of such a StateMachine object would then look > like something like: > > switch(mState) > { > case INIT: > init(); > set_state(WAIT_FOR_FOO); > case WAIT_FOR_FOO; > if (!foo()) > idle(); > set_state(DO_MORE); > case DO_MORE: > do_it(); > set_state(WAIT_FOR_BAR); > case WAIT_FOR_BAR: > if (!bar()) > idle(); > set_state(DONE); > case DONE: > cleanup(); > } > > As you see, this gives a compact and clear code where the flow is intuitive > (top down), but asynchronus and "blocking", without actually blocking the > main loop. > > One of the major advantages is these objects are reusable; for example, one > could write an object that checks if some inventory folder exists, if not > creates it, and then (or when it already exists) waits till it's contents > are available. Lets call this object SyncFolder(std::string const& name). > > Then another StateMachine object can use it (for example) as follows: > > class MyStateMachine : public LLStateMachine { > SyncFolder mSyncFolder; > ... > virtual void init(); > virtual void abort(); > virtual void done(); > }; > > void MyStateMachine::init() > { > mSyncFolder.set_name(folder_name); > } > > bool MyStateMachine::mainloop() > { > // INIT, DONE and ABORT are handled by the base class. > switch(mState) > { > case WAIT_FOR_FOO: > if (!foo()) > idle(); > set_state(SYNC_FOLDER); > case SYNC_FOLDER: > if (!mSyncFolder()) // Returns true when DONE > break; > case REZ_ITEM_FROM_FOLDER: > do_rez(); > } > } > > > One could create a large number of such objects that do simple tasks, and > then use those to build > objects that do more complex tasks. > > > On Thu, Feb 11, 2010 at 6:56 PM, Melinda Green wrote: > >> Sounds like a solution in search of a problem. I suggest that in order to >> get it incorporated as core, that you create at least one compelling >> solution built on it that people want enough to incorporate the whole thing. >> If you can't come up with one then it probably doesn't belong there because >> without a compelling example, nobody is going to realize it's there or to >> trust it or know how to use it. >> >> Just my L$5, >> -Melinda >> > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100215/fabb5908/attachment.htm From carlo at alinoe.com Mon Feb 15 10:20:45 2010 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 15 Feb 2010 19:20:45 +0100 Subject: [opensource-dev] retrieving scripts attached to an object In-Reply-To: References: Message-ID: <20100215182045.GA22464@alinoe.com> Could it be that you don't select the prim? If it isn't selected, the contents aren't synced. On Mon, Feb 15, 2010 at 04:47:14PM +0200, Mahmoud Ismail wrote: > > > > Hi all, > > as a proof of concept i was creating a floater which instantiated by a button > on the Pie Menu > in that floater i've created a Button in which i was try to get all inventory > items attached to the selected object > > but, i found that it gives no script items although there're two script files > "Note: i didn't open these files just press on New Script" > now, sometimes when i opened these files first then press my button it gives > results > > here's my button code: > > InventoryObjectList inventory_list; > object->getInventoryContents(inventory_list); > llinfos<<"Loop on inv_objects "< for(InventoryObjectList::iterator inv_obj=inventory_list.begin() ;inv_obj!= > inventory_list.end();++inv_obj) > { > LLPointer obj=*inv_obj; > llinfos<<"Type : "<getType() << " Name : "< > getName()< } > > anyone could tell me why i've to open the script file in order to be known as > an inventory item for that object > > another request, if anyone have any material could help me in understanding of > the workflow of the scripting module (from creating scripts till saving) please > pass it. > > thanks in advance, > > Best Regards, > Mahmoud Ismal > > _______________________________________________ > 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 -- Carlo Wood From dragnier1428 at hotmail.com Mon Feb 15 12:47:41 2010 From: dragnier1428 at hotmail.com (james ross) Date: Mon, 15 Feb 2010 14:47:41 -0600 Subject: [opensource-dev] step by step guide to compiling snowglobe Message-ID: Is there a step by step guide to compiling. I can use any windows OS or version of .NET. Please help, James _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/201469230/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100215/9e30f24e/attachment.htm From drakth at gmail.com Mon Feb 15 17:42:30 2010 From: drakth at gmail.com (Matias Villagarcia) Date: Mon, 15 Feb 2010 22:42:30 -0300 Subject: [opensource-dev] Problems compiling snowglobe Message-ID: <4B79F806.1050309@gmail.com> Hello, Im trying to compile snowglobe with VS2005, on windows 7, first one is: "Error 1 Error result 1 returned from 'C:\WINDOWS\system32\cmd.exe'." apparently on the "lscript_compile" project. And the other error is: "Error 2 fatal error LNK1104: cannot open file '..\lscript\lscript_compile\relwithdebinfo\lscript_compile.lib' secondlife-bin" Any ideas? Thanks. From stickman at gmail.com Mon Feb 15 21:03:07 2010 From: stickman at gmail.com (Stickman) Date: Mon, 15 Feb 2010 21:03:07 -0800 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: References: Message-ID: I haven't compiled the viewer myself, but most of what I've seen on the list points to the wiki. http://wiki.secondlife.com/wiki/Compiling_and_Patching_Snowglobe_%28Linux%29 Some searching of the wiki of your own may turn up something more relevant to your interests. And I'm sure any problems you may encounter will happily be addressed by this list. -Stickman On Mon, Feb 15, 2010 at 12:47 PM, james ross wrote: > Is there a step by step guide to compiling. I can use any windows OS or > version of .NET. > > Please help, > James > > ________________________________ > Hotmail: Powerful Free email with security by Microsoft. Get it now. > _______________________________________________ > 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 > From dragnier1428 at hotmail.com Tue Feb 16 19:47:17 2010 From: dragnier1428 at hotmail.com (james ross) Date: Tue, 16 Feb 2010 21:47:17 -0600 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: References: , Message-ID: It doesn't work. This seems to be a huge issue. There are several tutorials out there but they all say I used piece of the tutorial from here and a piece of the tutorial from there. I just think it would be nice if there were a step by step tutorial that actually had all the steps in one location and when you made it to the end of the 5 hour install it would work..... If anyone knows of a fabled tutorial that actually functions, please please please let me know, James > Date: Mon, 15 Feb 2010 21:03:07 -0800 > Subject: Re: [opensource-dev] step by step guide to compiling snowglobe > From: stickman at gmail.com > To: dragnier1428 at hotmail.com > CC: opensource-dev at lists.secondlife.com > > I haven't compiled the viewer myself, but most of what I've seen on > the list points to the wiki. > > http://wiki.secondlife.com/wiki/Compiling_and_Patching_Snowglobe_%28Linux%29 > > Some searching of the wiki of your own may turn up something more > relevant to your interests. And I'm sure any problems you may > encounter will happily be addressed by this list. > > -Stickman > > On Mon, Feb 15, 2010 at 12:47 PM, james ross wrote: > > Is there a step by step guide to compiling. I can use any windows OS or > > version of .NET. > > > > Please help, > > James > > > > ________________________________ > > Hotmail: Powerful Free email with security by Microsoft. Get it now. > > _______________________________________________ > > 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 > > _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/201469230/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100216/db1ce3a0/attachment.htm From open at autistici.org Wed Feb 17 00:40:51 2010 From: open at autistici.org (Opensource Obscure) Date: Wed, 17 Feb 2010 08:40:51 +0000 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: References: , Message-ID: Me too, I think it would be nice :) but I also think nobody is going to do it right now - a new viewer is going to be released in the few next weeks. While next viewer won't be different from the compilation and building point of view, I guess most people think it's pointless to write new documentation for a viewer that won't be used anymore in a few months. Also, this is not such a *huge* issue..well, it is..for you, me and a few other people. Most people who want to compile their builds know how to work around issues without step-to-step instructions because they're programmers. It seems you can't, and for sure I couldn't either, unfortunately. But I'm pretty sure we will fix this, as there are many people here waiting for Viewer 2 code release. bye opensource obscure -- come to LOL, take my scripts, mock me: http://bit.ly/dbObNk On Tue, 16 Feb 2010 21:47:17 -0600, james ross wrote: > It doesn't work. This seems to be a huge issue. There are several > tutorials out there but they all say I used piece of the tutorial from here > and a piece of the tutorial from there. I just think it would be nice if > there were a step by step tutorial that actually had all the steps in one > location and when you made it to the end of the 5 hour install it would > work..... > > If anyone knows of a fabled tutorial that actually functions, please > please please let me know, > James > >> Date: Mon, 15 Feb 2010 21:03:07 -0800 >> Subject: Re: [opensource-dev] step by step guide to compiling snowglobe >> From: stickman at gmail.com >> To: dragnier1428 at hotmail.com >> CC: opensource-dev at lists.secondlife.com >> >> I haven't compiled the viewer myself, but most of what I've seen on >> the list points to the wiki. >> >> http://wiki.secondlife.com/wiki/Compiling_and_Patching_Snowglobe_%28Linux%29 >> >> Some searching of the wiki of your own may turn up something more >> relevant to your interests. And I'm sure any problems you may >> encounter will happily be addressed by this list. >> >> -Stickman >> >> On Mon, Feb 15, 2010 at 12:47 PM, james ross >> wrote: >> > Is there a step by step guide to compiling. I can use any windows OS or >> > version of .NET. >> > >> > Please help, >> > James >> > >> > ________________________________ >> > Hotmail: Powerful Free email with security by Microsoft. Get it now. >> > _______________________________________________ >> > 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 >> > > > _________________________________________________________________ > Hotmail: Powerful Free email with security by Microsoft. > http://clk.atdmt.com/GBL/go/201469230/direct/01/ From dragnier1428 at hotmail.com Wed Feb 17 01:52:21 2010 From: dragnier1428 at hotmail.com (james ross) Date: Wed, 17 Feb 2010 03:52:21 -0600 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: References: , , , Message-ID: Well I am at least glad to see others have the same issue. A new viewer coming out isnt going to change the fact that there is not one step-by-step tutorial out there. Without the community here making it easier for people to get involved any viewer will be under utilized (if at all). Heh and also, I've never met a programmer that didnt look for an example before trying to code it themselves :-). > To: dragnier1428 at hotmail.com > Subject: Re: [opensource-dev] step by step guide to compiling snowglobe > Date: Wed, 17 Feb 2010 08:40:51 +0000 > From: open at autistici.org > CC: stickman at gmail.com; opensource-dev at lists.secondlife.com > > > Me too, I think it would be nice :) but I also think > > nobody is going to do it right now - a new viewer > > is going to be released in the few next weeks. > > > > While next viewer won't be different from the > > compilation and building point of view, I guess > > most people think it's pointless to write new > > documentation for a viewer that won't be used > > anymore in a few months. > > > > Also, this is not such a *huge* issue..well, > > it is..for you, me and a few other people. > > Most people who want to compile their builds > > know how to work around issues without step-to-step > > instructions because they're programmers. > > > > It seems you can't, and for sure I couldn't > > either, unfortunately. But I'm pretty sure we > > will fix this, as there are many people here > > waiting for Viewer 2 code release. > > > > bye > > opensource obscure > > -- > > come to LOL, take my scripts, mock me: > > http://bit.ly/dbObNk > > > > On Tue, 16 Feb 2010 21:47:17 -0600, james ross > > wrote: > > > It doesn't work. This seems to be a huge issue. There are several > > > tutorials out there but they all say I used piece of the tutorial from > > here > > > and a piece of the tutorial from there. I just think it would be nice if > > > there were a step by step tutorial that actually had all the steps in > > one > > > location and when you made it to the end of the 5 hour install it would > > > work..... > > > > > > If anyone knows of a fabled tutorial that actually functions, please > > > please please let me know, > > > James > > > > > >> Date: Mon, 15 Feb 2010 21:03:07 -0800 > > >> Subject: Re: [opensource-dev] step by step guide to compiling snowglobe > > >> From: stickman at gmail.com > > >> To: dragnier1428 at hotmail.com > > >> CC: opensource-dev at lists.secondlife.com > > >> > > >> I haven't compiled the viewer myself, but most of what I've seen on > > >> the list points to the wiki. > > >> > > >> > > http://wiki.secondlife.com/wiki/Compiling_and_Patching_Snowglobe_%28Linux%29 > > >> > > >> Some searching of the wiki of your own may turn up something more > > >> relevant to your interests. And I'm sure any problems you may > > >> encounter will happily be addressed by this list. > > >> > > >> -Stickman > > >> > > >> On Mon, Feb 15, 2010 at 12:47 PM, james ross > > >> wrote: > > >> > Is there a step by step guide to compiling. I can use any windows OS > > or > > >> > version of .NET. > > >> > > > >> > Please help, > > >> > James > > >> > > > >> > ________________________________ > > >> > Hotmail: Powerful Free email with security by Microsoft. Get it now. > > >> > _______________________________________________ > > >> > 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 > > >> > > > > > > > _________________________________________________________________ > > > Hotmail: Powerful Free email with security by Microsoft. > > > http://clk.atdmt.com/GBL/go/201469230/direct/01/ _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/201469230/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100217/79bb656e/attachment.htm From HRuss at z-techcorp.com Wed Feb 17 04:53:53 2010 From: HRuss at z-techcorp.com (Russ, Howell) Date: Wed, 17 Feb 2010 07:53:53 -0500 Subject: [opensource-dev] Unsubscribe Message-ID: <2CD219EF184F3142900E448782AB3F05021A8281@NTGEXMB04.icf-hq.icfconsulting.com> Pls unsubscribe me ________________________________ From: opensource-dev-bounces at lists.secondlife.com To: open at autistici.org Cc: snowglobeMailingList Sent: Wed Feb 17 03:52:21 2010 Subject: Re: [opensource-dev] step by step guide to compiling snowglobe Well I am at least glad to see others have the same issue. A new viewer coming out isnt going to change the fact that there is not one step-by-step tutorial out there. Without the community here making it easier for people to get involved any viewer will be under utilized (if at all). Heh and also, I've never met a programmer that didnt look for an example before trying to code it themselves :-). > To: dragnier1428 at hotmail.com > Subject: Re: [opensource-dev] step by step guide to compiling snowglobe > Date: Wed, 17 Feb 2010 08:40:51 +0000 > From: open at autistici.org > CC: stickman at gmail.com; opensource-dev at lists.secondlife.com > > > Me too, I think it would be nice :) but I also think > > nobody is going to do it right now - a new viewer > > is going to be released in the few next weeks. > > > > While next viewer won't be different from the > > compilation and building point of view, I guess > > most people think it's pointless to write new > > documentation for a viewer that won't be used > > anymore in a few months. > > > > Also, this is not such a *huge* issue..well, > > it is..for you, me and a few other people. > > Most people who want to compile their builds > > know how to work around issues without step-to-step > > instructions because they're programmers. > > > > It seems you can't, and for sure I couldn't > > either, unfortunately. But I'm pretty sure we > > will fix this, as there are many people here > > waiting for Viewer 2 code release. > > > > bye > > opensource obscure > > -- > > come to LOL, take my scripts, mock me: > > http://bit.ly/dbObNk > > > > On Tue, 16 Feb 2010 21:47:17 -0600, james ross > > wrote: > > > It doesn't work. This seems to be a huge issue. There are several > > > tutorials out there but they all say I used piece of the tutorial from > > here > > > and a piece of the tutorial from there. I just think it would be nice if > > > there were a step by step tutorial that actually had all the steps in > > one > > > location and when you made it to the end of the 5 hour install it would > > > work..... > > > > > > If anyone knows of a fabled tutorial that actually functions, please > > > please please let me know, > > > James > > > > > >> Date: Mon, 15 Feb 2010 21:03:07 -0800 > > >> Subject: Re: [opensource-dev] step by step guide to compiling snowglobe > > >> From: stickman at gmail.com > > >> To: dragnier1428 at hotmail.com > > >> CC: opensource-dev at lists.secondlife.com > > >> > > >> I haven't compiled the viewer myself, but most of what I've seen on > > >> the list points to the wiki. > > >> > > >> > > http://wiki.secondlife.com/wiki/Compiling_and_Patching_Snowglobe_%28Linux%29 > > >> > > >> Some searching of the wiki of your own may turn up something more > > >> relevant to your interests. And I'm sure any problems you may > > >> encounter will happily be addressed by this list. > > >> > > >> -Stickman > > >> > > >> On Mon, Feb 15, 2010 at 12:47 PM, james ross > > >> wrote: > > >> > Is there a step by step guide to compiling. I can use any windows OS > > or > > >> > version of .NET. > > >> > > > >> > Please help, > > >> > James > > >> > > > >> > ________________________________ > > >> > Hotmail: Powerful Free email with security by Microsoft. Get it now. > > >> > _______________________________________________ > > >> > 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 > > >> > > > > > > > _________________________________________________________________ > > > Hotmail: Powerful Free email with security by Microsoft. > > > http://clk.atdmt.com/GBL/go/201469230/direct/01/ ________________________________ Hotmail: Powerful Free email with security by Microsoft. Get it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100217/9bec0dde/attachment-0001.htm From cjac at colliertech.org Wed Feb 17 06:41:13 2010 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Wed, 17 Feb 2010 06:41:13 -0800 Subject: [opensource-dev] Unsubscribe In-Reply-To: <2CD219EF184F3142900E448782AB3F05021A8281@NTGEXMB04.icf-hq.icfconsulting.com> References: <2CD219EF184F3142900E448782AB3F05021A8281@NTGEXMB04.icf-hq.icfconsulting.com> Message-ID: <1266417673.5965.0.camel@calcifer> Pls unsubscribe yourself: X-Mailman-Version: 2.1.9 Precedence: list List-Id: Open source development issues relating to Second Life List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 2010-02-17 at 07:53 -0500, Russ, Howell wrote: > Pls unsubscribe me > > > > ______________________________________________________________________ > > From: opensource-dev-bounces at lists.secondlife.com > > To: open at autistici.org > Cc: snowglobeMailingList > Sent: Wed Feb 17 03:52:21 2010 > Subject: Re: [opensource-dev] step by step guide to compiling > snowglobe > > > Well I am at least glad to see others have the same issue. A new > viewer coming out isnt going to change the fact that there is not one > step-by-step tutorial out there. Without the community here making it > easier for people to get involved any viewer will be under utilized > (if at all). Heh and also, I've never met a programmer that didnt look > for an example before trying to code it themselves :-). > > > To: dragnier1428 at hotmail.com > > Subject: Re: [opensource-dev] step by step guide to compiling > snowglobe > > Date: Wed, 17 Feb 2010 08:40:51 +0000 > > From: open at autistici.org > > CC: stickman at gmail.com; opensource-dev at lists.secondlife.com > > > > > > Me too, I think it would be nice :) but I also think > > > > nobody is going to do it right now - a new viewer > > > > is going to be released in the few next weeks. > > > > > > > > While next viewer won't be different from the > > > > compilation and building point of view, I guess > > > > most people think it's pointless to write new > > > > documentation for a viewer that won't be used > > > > anymore in a few months. > > > > > > > > Also, this is not such a *huge* issue..well, > > > > it is..for you, me and a few other people. > > > > Most people who want to compile their builds > > > > know how to work around issues without step-to-step > > > > instructions because they're programmers. > > > > > > > > It seems you can't, and for sure I couldn't > > > > either, unfortunately. But I'm pretty sure we > > > > will fix this, as there are many people here > > > > waiting for Viewer 2 code release. > > > > > > > > bye > > > > opensource obscure > > > > -- > > > > come to LOL, take my scripts, mock me: > > > > http://bit.ly/dbObNk > > > > > > > > On Tue, 16 Feb 2010 21:47:17 -0600, james ross > > > > > wrote: > > > > > It doesn't work. This seems to be a huge issue. There are several > > > > > tutorials out there but they all say I used piece of the tutorial > from > > > > here > > > > > and a piece of the tutorial from there. I just think it would be > nice if > > > > > there were a step by step tutorial that actually had all the steps > in > > > > one > > > > > location and when you made it to the end of the 5 hour install it > would > > > > > work..... > > > > > > > > > > If anyone knows of a fabled tutorial that actually functions, > please > > > > > please please let me know, > > > > > James > > > > > > > > > >> Date: Mon, 15 Feb 2010 21:03:07 -0800 > > > > >> Subject: Re: [opensource-dev] step by step guide to compiling > snowglobe > > > > >> From: stickman at gmail.com > > > > >> To: dragnier1428 at hotmail.com > > > > >> CC: opensource-dev at lists.secondlife.com > > > > >> > > > > >> I haven't compiled the viewer myself, but most of what I've seen > on > > > > >> the list points to the wiki. > > > > >> > > > > >> > > > > http://wiki.secondlife.com/wiki/Compiling_and_Patching_Snowglobe_% > 28Linux%29 > > > > >> > > > > >> Some searching of the wiki of your own may turn up something more > > > > >> relevant to your interests. And I'm sure any problems you may > > > > >> encounter will happily be addressed by this list. > > > > >> > > > > >> -Stickman > > > > >> > > > > >> On Mon, Feb 15, 2010 at 12:47 PM, james ross > > > > > >> wrote: > > > > >> > Is there a step by step guide to compiling. I can use any > windows OS > > > > or > > > > >> > version of .NET. > > > > >> > > > > > >> > Please help, > > > > >> > James > > > > >> > > > > > >> > ________________________________ > > > > >> > Hotmail: Powerful Free email with security by Microsoft. Get it > now. > > > > >> > _______________________________________________ > > > > >> > 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 > > > > >> > > > > > > > > > > > _________________________________________________________________ > > > > > Hotmail: Powerful Free email with security by Microsoft. > > > > > http://clk.atdmt.com/GBL/go/201469230/direct/01/ > > > ______________________________________________________________________ > > Hotmail: Powerful Free email with security by Microsoft. Get it now. > _______________________________________________ > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100217/3842562d/attachment.pgp From monkowsk at fishkill.ibm.com Wed Feb 17 07:30:41 2010 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Wed, 17 Feb 2010 10:30:41 -0500 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: References: , , , Message-ID: <4B7C0BA1.2030604@fishkill.ibm.com> Seems like you're looking for a shortcut. The main Snowglobe page says > The Get source and compile page gives general information about how to compile the source. For a quick step-by-step instruction for building on Linux, see Compiling and Patching Snowglobe (Linux). Did you look at http://wiki.secondlife.com/wiki/Get_source_and_compile james ross wrote: > Well I am at least glad to see others have the same issue. A new viewer > coming out isnt going to change the fact that there is not one > step-by-step tutorial out there. Without the community here making it > easier for people to get involved any viewer will be under utilized (if > at all). Heh and also, I've never met a programmer that didnt look for > an example before trying to code it themselves :-). From robertltux at gmail.com Wed Feb 17 09:23:58 2010 From: robertltux at gmail.com (Robert Martin) Date: Wed, 17 Feb 2010 12:23:58 -0500 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: <4B7C0BA1.2030604@fishkill.ibm.com> References: <4B7C0BA1.2030604@fishkill.ibm.com> Message-ID: On Wed, Feb 17, 2010 at 10:30 AM, Mike Monkowski wrote: > Seems like you're looking for a shortcut. ?The main Snowglobe page says >> The Get source and compile page gives general information about how to compile the source. For a quick step-by-step instruction for building on Linux, see Compiling and Patching Snowglobe (Linux). > > Did you look at http://wiki.secondlife.com/wiki/Get_source_and_compile > the biggest problem as such is some parts of the compile run seem to require chicken blood and sheep entrails. until somebody fixes the Boost Hell problem and other But we haven't updated our compile farm in the last 3 years so you have to use an old version type deals a simple this will work listing can not happen. I would be shocked and seriously doubt the skills of the LL paid programmers if SL 2.0 did not get used as an excuse to fix these problems. There should come a day when you can build a tree with all of the libs and assets invoke a "All targets -- static" command and have all the platforms done in one single (but massive) run. -- Robert L Martin From armin.weatherwax at googlemail.com Wed Feb 17 09:39:54 2010 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Wed, 17 Feb 2010 18:39:54 +0100 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: References: <4B7C0BA1.2030604@fishkill.ibm.com> Message-ID: <201002171839.54678.Armin.Weatherwax@gmail.com> Robert Martin schrieb: > the biggest problem as such is some parts of the compile run seem to > require chicken blood and sheep entrails. I personally have a 3-legged black cat, but that might be a Linux specific helper and explain little differences in mouse handling. (scnr) From dragnier1428 at hotmail.com Wed Feb 17 11:08:29 2010 From: dragnier1428 at hotmail.com (james ross) Date: Wed, 17 Feb 2010 13:08:29 -0600 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: <4B7C0BA1.2030604@fishkill.ibm.com> References: , , , , <4B7C0BA1.2030604@fishkill.ibm.com> Message-ID: I am not sure if i tried the path listed there specifically. I have tried many different paths. I hope this one works. A shortcut or something that is easy is not really required but would definately be nice. I would be extremely thrilled if anything would work :-). Thanks, James > Date: Wed, 17 Feb 2010 10:30:41 -0500 > From: monkowsk at fishkill.ibm.com > To: dragnier1428 at hotmail.com > CC: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] step by step guide to compiling snowglobe > > Seems like you're looking for a shortcut. The main Snowglobe page says > > The Get source and compile page gives general information about how to compile the source. For a quick step-by-step instruction for building on Linux, see Compiling and Patching Snowglobe (Linux). > > Did you look at http://wiki.secondlife.com/wiki/Get_source_and_compile > > > james ross wrote: > > Well I am at least glad to see others have the same issue. A new viewer > > coming out isnt going to change the fact that there is not one > > step-by-step tutorial out there. Without the community here making it > > easier for people to get involved any viewer will be under utilized (if > > at all). Heh and also, I've never met a programmer that didnt look for > > an example before trying to code it themselves :-). > _________________________________________________________________ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/201469229/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100217/d0c7e92a/attachment.htm From kow at sapinski.com Wed Feb 17 11:30:07 2010 From: kow at sapinski.com (k\o\w) Date: Wed, 17 Feb 2010 14:30:07 -0500 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: References: , , , , <4B7C0BA1.2030604@fishkill.ibm.com> Message-ID: <4B7C43BF.6010000@sapinski.com> On Windows it's as easy as double clicking develop.py. Sounds like maybe you're not ready for Linux, and should try to a more user friendly OS/IDE. Snowglobe should work out of the box with VS2005. Emerald and Imprudence are easier options if you're using VS2008. I believe the only issue with VS2008 + snowglobe is boost, and the libs from Emerald or Imprudence can be dropped in to fix that. On 2/17/2010 2:08 PM, james ross wrote: > I am not sure if i tried the path listed there specifically. I have > tried many different paths. I hope this one works. A shortcut or > something that is easy is not really required but would definately be > nice. I would be extremely thrilled if anything would work :-). > > Thanks, > James > > > > Date: Wed, 17 Feb 2010 10:30:41 -0500 > > From: monkowsk at fishkill.ibm.com > > To: dragnier1428 at hotmail.com > > CC: opensource-dev at lists.secondlife.com > > Subject: Re: [opensource-dev] step by step guide to compiling snowglobe > > > > Seems like you're looking for a shortcut. The main Snowglobe page says > > > The Get source and compile page gives general information about > how to compile the source. For a quick step-by-step instruction for > building on Linux, see Compiling and Patching Snowglobe (Linux). > > > > Did you look at http://wiki.secondlife.com/wiki/Get_source_and_compile > > > > > > james ross wrote: > > > Well I am at least glad to see others have the same issue. A new > viewer > > > coming out isnt going to change the fact that there is not one > > > step-by-step tutorial out there. Without the community here making it > > > easier for people to get involved any viewer will be under > utilized (if > > > at all). Heh and also, I've never met a programmer that didnt look > for > > > an example before trying to code it themselves :-). > > > > ------------------------------------------------------------------------ > Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up > now. > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100217/ec261e10/attachment-0001.htm From dragnier1428 at hotmail.com Wed Feb 17 11:35:25 2010 From: dragnier1428 at hotmail.com (james ross) Date: Wed, 17 Feb 2010 13:35:25 -0600 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: <4B7C0BA1.2030604@fishkill.ibm.com> References: , , , , <4B7C0BA1.2030604@fishkill.ibm.com> Message-ID: I find it difficult to answer questions when much of the information is left out of the question. So in order to help the nice people here help me I am going to document the process. I am going to try again using .NET 2005 specified here with no upgrades if at all possible. I will post my result tomorrow. This was my attempt at using .NET 2008. All information can be found at the following website: http://wiki.secondlife.com/wiki/User:Jodiah_Jensen#UPDATING_BOOST_LIBRARIES_TO_WORK_WITH_VS2008 He suggests you start with part 2 on installing the boost libraries but if you are running on a machine that doesn?t have all the extra stuff like cmake working properly, it will fail. I made it to the run the develop.py file. I opened and ran it using Python IDLE and saw an error with cmake. So I deciding starting with step 2 and then going to step one was not the path for me and went back to step 1. I am going to write my own steps to try to make the direction easier where possible 2) double check and make sure you have .NET 2008 3) Go download the Derect x development kit http://www.microsoft.com/downloads/details.aspx?FamilyId=4B78A58A-E672-4B83-A28E-72B5E93BD60A&displaylang=en#AffinityDownloads Newest so far as of Feb 2010 http://www.microsoft.com/downloads/details.aspx?FamilyID=F26B1AA4-741A-433A-9BE5-FA919850BDBF&displaylang=en 4) download windows SDK http://www.microsoft.com/downloads/details.aspx?FamilyID=F26B1AA4-741A-433A-9BE5-FA919850BDBF&displaylang=en you will probably have to burn this file to a cd and then run the cd 5) download quicktime API for windows http://developer.apple.com/quicktime/download/ 6) download cmake. Make sure you tell it to add the system path or you will have to do it manually http://www.cmake.org/files/v2.4/cmake-2.4.8-win32-x86.exe link to cmake downloads page http://www.cmake.org/cmake/resources/software.html I am trying to use version 2.8 7)download fmod http://www.fmod.org/index.php/download#FMOD3ProgrammersAPI 8)Insert from (http://wiki.secondlife.com/wiki/User:Jodiah_Jensen#UPDATING_BOOST_LIBRARIES_TO_WORK_WITH_VS2008) STEP 1 - Downloading the source code DOWNLOAD SOURCE: http://secondlife.com/developers/opensource/downloads/2008/10/slviewer-src-viewer_1-21-r99587.zip DOWNLOAD LIBS http://secondlife.com/developers/opensource/downloads/2008/10/slviewer-win32-libs-viewer_1-21-r99587.zip DOWNLOAD ARTWORK http://secondlife.com/developers/opensource/downloads/2008/10/slviewer-artwork-viewer_1-21-r99587.zip NOTE: These are the source files *I* used, there may be newer source files available by the time you read this. This page applies specifically to this version of the source (viewer version 1.21.6.0) ..._1-21-r99587 STEP 2 - Installing the source, libs, and Artwork EXTRACT ALL THREE ZIP FILES TO SAME PATH (no spaces in the path name) ie "D:\SL_SRC\" this will result in a single folder inside D:\SL_SRC\ called "linden" ("D:\SL_SRC\linden") TODO: insert directory tree here STEP 3 - Setting up your development directory tree using develop.py RUN develop.py SCRIPT run a command prompt in the "D:\SL_SRC\linden\indra" path run the script using "develop.py -G VC90" (this is for VS C++ 2008) (the attachment is picture of my command line window just for extra info) Figure: A snapshot of using the cmd line to run develop.py 9) STEP 4 - Setting up FMOD place FMOD files in proper places Copy "fmodapi375win\api\inc\fmod.h" to "linden\libraries\include" Copy "fmodapi375win\api\inc\fmod_errors.h" to "linden\libraries\include" Copy "fmodapi375win\api\lib\fmodvc.lib" to "linden\libraries\i686-win32\lib\release" and to "linden\libraries\i686-win32\lib\debug" Copy "fmodapi375win\api\fmod.dll" to "linden\indra\newview" STEP 5 - Setting up Visual Studio and compiling the source code OPEN D:\SL_SRC\linden\indra\build-VC90\secondlife.sln in VC++ set 'secondlife-bin' (in Solution Explorer) as Startup Project set the working directory to 'D:\SL_SRC\linden\indra\newview' (select secondlife-bin and use Project > Properties > Configuration Properties > Debugging) click the green arrow (start debugging) 3) run boost 1.34.1 installer in the files downloaded for Snowglobe folder Chose the first mirror site, that seems to work the best. Choose all options. It may give you file not found a couple times till it finds a mirror site that works. Expect a 1gb file. If at the end of the install it fails, choose a different mirror If your feeling lucky you could try the new version of the boost installer? http://www.boostpro.com/download --***--I was feeling lucky and tried with version 1.42.1 If your feeling EVEN more lucky you could try to download and install the libraries yourself http://sourceforge.net/projects/boost/files/boost/ --***---I wasn?t that brave! NOTE: the Boost Wiki says to use the Visual Studio command prompt instead of the regular command prompt for the following steps: cd to "boost_1_42_1\tools\jam\" Run "boost_1_42_1\tools\jam\build_dist.bat". Copy "boost_1_42_1\tools\jam\src\bin.ntx86\bjam.exe" to "boost_1_34_1\". [NOTE: found in stage directory, not src, in Boost 1.35.0 and later] For Boost 1.39, bjam is placed at "...\boost_1_39_0\tools\jam\stage\boost-jam-3.1.17-1-ntx86" (thanks to Geneko Nemeth for this ) Using the command prompt, build the static libraries: cd boost_1_42_1 set PYTHON_ROOT=C:\Python26 the path to your Python root may be different. set PYTHON_VERSION=2.6 you may be using a different version of Python. Run the command: bjam --toolset=msvc-9.0 --with-python --with-program_options --with-regex --with-signals --build-type=complete link=static stage 4) STEP 3 - Placing new libs where they belong Copy the "\boost_1_42_1\boost" folder to "\linden\libraries\include\". (these are the header files for the boost libraries) copy the following files from "boost_1_42_1\stage\lib\" to "\linden\libraries\i686-win32\lib\release\" libboost_program_options-vc90-mt-s-1_42_1.lib libboost_python-vc90-mt-s-1_42_1.lib libboost_regex-vc90-mt-s-1_42_1.lib libboost_signals-vc90-mt-s-1_42_1.lib copy the following files from "boost_1_42_1\stage\lib\" to "\linden\libraries\i686-win32\lib\debug\" libboost_program_options-vc90-mt-sgd-1_42_1.lib libboost_python-vc90-mt-sgd-1_42_1.lib libboost_regex-vc90-mt-sgd-1_42_1.lib libboost_signals-vc90-mt-sgd-1_42_1.lib got 200+ errors for not being able to find library files > Date: Wed, 17 Feb 2010 10:30:41 -0500 > From: monkowsk at fishkill.ibm.com > To: dragnier1428 at hotmail.com > CC: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] step by step guide to compiling snowglobe > > Seems like you're looking for a shortcut. The main Snowglobe page says > > The Get source and compile page gives general information about how to compile the source. For a quick step-by-step instruction for building on Linux, see Compiling and Patching Snowglobe (Linux). > > Did you look at http://wiki.secondlife.com/wiki/Get_source_and_compile > > > james ross wrote: > > Well I am at least glad to see others have the same issue. A new viewer > > coming out isnt going to change the fact that there is not one > > step-by-step tutorial out there. Without the community here making it > > easier for people to get involved any viewer will be under utilized (if > > at all). Heh and also, I've never met a programmer that didnt look for > > an example before trying to code it themselves :-). > _________________________________________________________________ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/201469229/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100217/1ea3af39/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: temp.bmp Type: image/bmp Size: 712758 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100217/1ea3af39/attachment-0001.bin From robertltux at gmail.com Wed Feb 17 12:22:53 2010 From: robertltux at gmail.com (Robert Martin) Date: Wed, 17 Feb 2010 15:22:53 -0500 Subject: [opensource-dev] SecondLife 2.0 beta download???? In-Reply-To: References: Message-ID: ive noticed that there is a link on the secondlife.com dashboard to download sl 2.0 (with a target of http://secondlife.com/beta-viewer/) is this a case of released to soon or what?? -- Robert L Martin From maggie at matrisync.com Wed Feb 17 12:25:06 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Wed, 17 Feb 2010 15:25:06 -0500 Subject: [opensource-dev] SecondLife 2.0 beta download???? In-Reply-To: References: Message-ID: On Wed, Feb 17, 2010 at 3:22 PM, Robert Martin wrote: > ?ive noticed that there is a link on the secondlife.com dashboard to > ?download sl 2.0 (with a target of http://secondlife.com/beta-viewer/) > ?is this a case of released to soon or what?? Your question cannot be answered unless you sign an NDA. :-) From tillie at xp2.de Wed Feb 17 12:28:22 2010 From: tillie at xp2.de (Tillie Ariantho) Date: Wed, 17 Feb 2010 21:28:22 +0100 Subject: [opensource-dev] SecondLife 2.0 beta download???? In-Reply-To: References: Message-ID: <4B7C5166.8020802@xp2.de> On 17.02.2010 21:25, Maggie Leber (sl: Maggie Darwin) wrote: > On Wed, Feb 17, 2010 at 3:22 PM, Robert Martin wrote: >> ive noticed that there is a link on the secondlife.com dashboard to >> download sl 2.0 (with a target of http://secondlife.com/beta-viewer/) >> is this a case of released to soon or what?? > > Your question cannot be answered unless you sign an NDA. :-) I'll sign an NDA happily if I get an answer for that and get a working download link for the 2.0 beta. ;-D Tillie From maggie at matrisync.com Wed Feb 17 12:30:29 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Wed, 17 Feb 2010 15:30:29 -0500 Subject: [opensource-dev] SecondLife 2.0 beta download???? In-Reply-To: <4B7C5166.8020802@xp2.de> References: <4B7C5166.8020802@xp2.de> Message-ID: On Wed, Feb 17, 2010 at 3:28 PM, Tillie Ariantho wrote: > On 17.02.2010 21:25, Maggie Leber (sl: Maggie Darwin) wrote: >> On Wed, Feb 17, 2010 at 3:22 PM, Robert Martin wrote: >>> ?ive noticed that there is a link on the secondlife.com dashboard to >>> ?download sl 2.0 (with a target of http://secondlife.com/beta-viewer/) >>> ?is this a case of released to soon or what?? >> Your question cannot be answered unless you sign an NDA. :-) > I'll sign an NDA happily if I get an answer for that and get a working download link for the 2.0 beta. ;-D That's a different NDA. From snowfox102 at dragonkeepcreations.com Wed Feb 17 12:36:19 2010 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Wed, 17 Feb 2010 14:36:19 -0600 Subject: [opensource-dev] SecondLife 2.0 beta download???? In-Reply-To: <4B7C5166.8020802@xp2.de> References: <4B7C5166.8020802@xp2.de> Message-ID: <4B7C5343.70509@dragonkeepcreations.com> Tillie Ariantho wrote: > On 17.02.2010 21:25, Maggie Leber (sl: Maggie Darwin) wrote: > > >> On Wed, Feb 17, 2010 at 3:22 PM, Robert Martin wrote: >> >>> ive noticed that there is a link on the secondlife.com dashboard to >>> download sl 2.0 (with a target of http://secondlife.com/beta-viewer/) >>> is this a case of released to soon or what?? >>> >> Your question cannot be answered unless you sign an NDA. :-) >> > > I'll sign an NDA happily if I get an answer for that and get a working download link for the 2.0 beta. ;-D > > Tillie > I think pretty much everybody on this group would. At any rate, if they released 2.0 today it wouldn't be "early," it would be "on time." Blog posts pointed to a February release. Also, technically it would be the BSI group that would be more likely to know this kind of thing, being the designated alpha testing group. (They weren't used for 2.0's alpha though, and the group has been silent for months, so I don't blame you. ;) ) ~Maya Remblai, still a bit pessimistic. From t at lindenlab.com Wed Feb 17 12:52:30 2010 From: t at lindenlab.com (Tom Hale) Date: Wed, 17 Feb 2010 12:52:30 -0800 Subject: [opensource-dev] SecondLife 2.0 beta download???? In-Reply-To: <4B7C5343.70509@dragonkeepcreations.com> References: <4B7C5166.8020802@xp2.de> <4B7C5343.70509@dragonkeepcreations.com> Message-ID: <2303487419589763109@unknownmsgid> Hi folks: Not ready yet! On Feb 17, 2010, at 12:36 PM, Maya Remblai wrote: > Tillie Ariantho wrote: >> On 17.02.2010 21:25, Maggie Leber (sl: Maggie Darwin) wrote: >> >> >>> On Wed, Feb 17, 2010 at 3:22 PM, Robert Martin >>> wrote: >>> >>>> ive noticed that there is a link on the secondlife.com dashboard to >>>> download sl 2.0 (with a target of http://secondlife.com/beta-viewer/ >>>> ) >>>> is this a case of released to soon or what?? >>>> >>> Your question cannot be answered unless you sign an NDA. :-) >>> >> >> I'll sign an NDA happily if I get an answer for that and get a >> working download link for the 2.0 beta. ;-D >> >> Tillie >> > I think pretty much everybody on this group would. At any rate, if > they > released 2.0 today it wouldn't be "early," it would be "on time." Blog > posts pointed to a February release. > > Also, technically it would be the BSI group that would be more > likely to > know this kind of thing, being the designated alpha testing group. > (They > weren't used for 2.0's alpha though, and the group has been silent for > months, so I don't blame you. ;) ) > > ~Maya Remblai, still a bit pessimistic. > _______________________________________________ > 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 From carlo at alinoe.com Thu Feb 18 04:36:13 2010 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 18 Feb 2010 13:36:13 +0100 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: <4B7C43BF.6010000@sapinski.com> References: <4B7C0BA1.2030604@fishkill.ibm.com> <4B7C43BF.6010000@sapinski.com> Message-ID: <20100218123613.GA32179@alinoe.com> On Wed, Feb 17, 2010 at 02:30:07PM -0500, kow wrote: > Snowglobe should work out of the box with VS2005. Emerald and Imprudence are > easier options if you're using VS2008. I believe the only issue with VS2008 + > snowglobe is boost, and the libs from Emerald or Imprudence can be dropped in > to fix that. One would wonder why Emerald can fix this, and LL can't. -- Carlo Wood From morgaine.dinova at googlemail.com Thu Feb 18 04:42:53 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Thu, 18 Feb 2010 12:42:53 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe Message-ID: I referred recently to Linden's internal project "Firefly" to add client-side scripting to SL viewers. This has been the topic of open discussion at several Office Hours with Lindens in SL, but that openness has not extended to many design details --- the Firefly design process is not open to the community. The only technical details that are being disclosed about Firefly appear to be: - "Scripts" are actually *Mono assemblies*, so that only languages that compile to Mono will be allowed. - The programs run in a *sandbox*, which means that most platform resources are not accessible to them. Please note that I quite like C# as a language, but the following remarks are about Mono use *in the SL viewer*, only, where its tradeoffs are poor. The first known detail about Firefly (mandatory Mono) is problematic on several fronts: 1. Only a tiny fraction of the world's applications, libraries and languages work on Mono, so client-side scripting will be unable to benefit from the huge mountain of resources available on the Internet. This is an extremely severe limitation, and an unnecessary restriction in the context of client-side viewer scripting. If I want to use a locally-installed package X from within my client-side script, I should be able to. What runs client-side should always be our individual choice, not someone else's. 2. Programmers want to write client-side scripts in the language that they know best, because that always yields the fastest progress and highest quality results. There was a good technical reason for forcing everyone to use LSL server-side, but there is no technical reason to impose this requirement on all client-side scripting. It is counter-productive to force CLR compatibility on client-side script developers when there is a simple alternative: define a *socket-based viewer API* for client-side scripts instead, hence usable from any language. 3. Mono runs poorly on Linux, so from being rock-solid on Linux now, the LL-derived viewers will become second-rate on this platform. 4. The viewer is already extremely bloated and a memory hog. Adding a Mono dependency will compound that horribly. 5. There is only one effective supplier of Mono: Novell. That is a very bad situation to encourage and to support in the viewer. 6. Some parties identify other reasons for avoiding Mono in general. Without getting into that subject at all, The second known detail about Firefly (mandatory sandbox) is problematic on two related fronts: 1. Sandboxes by design do not allow most platform resources to be accessed, as a security measure. This is fine and important when scripts are being downloaded from unknown places (like Javascript in web pages), but that same protection also means that client-side scripts would be powerless to do useful things for us in concert with local applications, files, devices, etc. Sandboxing client-side scripts effectively hardwires in script weakness for no reason discussed as a requirement. 2. Sandboxed applications cannot be linked with user-chosen native libraries since allowing native code breaks sandbox protection. This means no accelerators, no extensions, and no interop with other systems since sockets are inaccessible from any strong sandbox. This also means no evolution or progress outside of what the sandbox designers permit. This mailing list is concerned with development of open source viewers, in particular Snowglobe. This is heralded as a *community* viewer, embodying * community* requirements much more directly than the LL mainstream viewer. Client-side scripting will impact on every single aspect of Snowglobe bar none, yet the community is being excluded from the design of its most powerful infrastructure element. This is entirely wrong, far beyond the normal observation that secrecy in design has no place in open source. It is hard to assess things technically when the design requirements are formulated in secret. The Snowglobe community has design requirements too. Those deserve to be examined here openly, not limiting Snowglobe to a design that stems from Linden requirements alone. Morgaine. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100218/f970ce58/attachment.htm From morgaine.dinova at googlemail.com Thu Feb 18 04:57:48 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Thu, 18 Feb 2010 12:57:48 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: Message-ID: A line got lost from my post owing to finger trouble. Item 6 about Mono should have read: 6. Some parties identify other reasons for avoiding Mono in general. Without getting into that subject at all, requiring Mono for client-side scripting would make scripting unavailable to that portion of the user base. Since client-side scripting without Mono is perfectly feasible, Mono should not be made mandatory for scripting, so that the widest user base can be supported. Morgaine. ======================== On Thu, Feb 18, 2010 at 12:42 PM, Morgaine wrote: > I referred recently to Linden's internal project "Firefly" to add > client-side scripting to SL viewers. This has been the topic of open > discussion at several Office Hours with Lindens in SL, but that openness has > not extended to many design details --- the Firefly design process is not > open to the community. The only technical details that are being disclosed > about Firefly appear to be: > > > - "Scripts" are actually *Mono assemblies*, so that only languages that > compile to Mono will be allowed. > - The programs run in a *sandbox*, which means that most platform > resources are not accessible to them. > > > Please note that I quite like C# as a language, but the following remarks > are about Mono use *in the SL viewer*, only, where its tradeoffs are poor. > > The first known detail about Firefly (mandatory Mono) is problematic on > several fronts: > > 1. Only a tiny fraction of the world's applications, libraries and > languages work on Mono, so client-side scripting will be unable to benefit > from the huge mountain of resources available on the Internet. This is an > extremely severe limitation, and an unnecessary restriction in the context > of client-side viewer scripting. If I want to use a locally-installed > package X from within my client-side script, I should be able to. What runs > client-side should always be our individual choice, not someone else's. > 2. Programmers want to write client-side scripts in the language that > they know best, because that always yields the fastest progress and highest > quality results. There was a good technical reason for forcing everyone to > use LSL server-side, but there is no technical reason to impose this > requirement on all client-side scripting. It is counter-productive to force > CLR compatibility on client-side script developers when there is a simple > alternative: define a *socket-based viewer API* for client-side > scripts instead, hence usable from any language. > 3. Mono runs poorly on Linux, so from being rock-solid on Linux now, > the LL-derived viewers will become second-rate on this platform. > 4. The viewer is already extremely bloated and a memory hog. Adding a > Mono dependency will compound that horribly. > 5. There is only one effective supplier of Mono: Novell. That is a > very bad situation to encourage and to support in the viewer. > 6. Some parties identify other reasons for avoiding Mono in general. > Without getting into that subject at all, > > > The second known detail about Firefly (mandatory sandbox) is problematic on > two related fronts: > > 1. Sandboxes by design do not allow most platform resources to be > accessed, as a security measure. This is fine and important when scripts > are being downloaded from unknown places (like Javascript in web pages), but > that same protection also means that client-side scripts would be powerless > to do useful things for us in concert with local applications, files, > devices, etc. Sandboxing client-side scripts effectively hardwires in > script weakness for no reason discussed as a requirement. > 2. Sandboxed applications cannot be linked with user-chosen native > libraries since allowing native code breaks sandbox protection. This means > no accelerators, no extensions, and no interop with other systems since > sockets are inaccessible from any strong sandbox. This also means no > evolution or progress outside of what the sandbox designers permit. > > > This mailing list is concerned with development of open source viewers, in > particular Snowglobe. This is heralded as a *community* viewer, embodying > *community* requirements much more directly than the LL mainstream viewer. > Client-side scripting will impact on every single aspect of Snowglobe bar > none, yet the community is being excluded from the design of its most > powerful infrastructure element. This is entirely wrong, far beyond the > normal observation that secrecy in design has no place in open source. > > It is hard to assess things technically when the design requirements are > formulated in secret. The Snowglobe community has design requirements too. > Those deserve to be examined here openly, not limiting Snowglobe to a > design that stems from Linden requirements alone. > > > Morgaine. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100218/8f0b56a3/attachment-0001.htm From stickman at gmail.com Thu Feb 18 05:11:44 2010 From: stickman at gmail.com (Stickman) Date: Thu, 18 Feb 2010 05:11:44 -0800 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: <20100218123613.GA32179@alinoe.com> References: <4B7C0BA1.2030604@fishkill.ibm.com> <4B7C43BF.6010000@sapinski.com> <20100218123613.GA32179@alinoe.com> Message-ID: > One would wonder why Emerald can fix this, and LL can't. It's been addressed. https://lists.secondlife.com/pipermail/sldev/2009-June/014269.html "The problem is that it's not possible to provide precompiled Boost libraries that work for both VS 2005 and VS 2008. Since Linden Lab has standardized on VS 2005, that's what we provide." -Rob Later in that thread we see: https://lists.secondlife.com/pipermail/sldev/2009-June/014273.html "I will be looking into providing library packages that contain binaries for both versions shortly. Hopefully in the next week or two." -Brad Linden Obviously, that didn't happen. But I've always wondered if it's possible to bribe Lindens with confectionery. -Stickman From maggie at matrisync.com Thu Feb 18 05:22:30 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Thu, 18 Feb 2010 08:22:30 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: Message-ID: On Thu, Feb 18, 2010 at 7:42 AM, Morgaine wrote: > I referred recently to Linden's internal project "Firefly" to add > client-side scripting to SL viewers.? This has been the topic of open > discussion at several Office Hours with Lindens in SL, but that openness has > not extended to many design details --- the Firefly design process is not > open to the community... Personally, I find it difficult to escape the conclusion that the preposterous amount of secrecy now surrounding viewer development has any legitimate purpose. The argument that it is to preserve some commercial competitive advantage for Linden Research is silly. Competing solutions are constrained by their own architectures in the functions they can deliver. (I suppose it might be possible that this stealth systems design might be intended to sabotage efforts by other users of the Second Life Viewer codebase. If so, I'd be interested in the legal implications of that relative to antitrust and unfair trade practices law. But IANAL.) Most charitably, I'm left to conclude that -- like so many other activities conducted by Linden Research -- it is being done in secret with the intention of maximizing spin control of reactions of the user community until such initiatives are fait accompli. Whatever the motivation for this, I think soliciting and exploiting developer involvement and contributions from the open-source community and then turning around and treating them like mushrooms is reprehensible. Trade press reporting of statements made by Joe Linden about restrictions to be placed on third-party viewers (including implementation of mandatory technical standards that enable servers to discriminate against various viewer implementations) call for an immediate response from Linden Research that goes beyond simple ad-hominem attacks on their source to authoritative clarification, denial or confirmation. "You'l find out when it's most advantageous to us to tell you" is a deep expression of contempt for your customers and business partners. From secret.argent at gmail.com Thu Feb 18 05:45:58 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 18 Feb 2010 07:45:58 -0600 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: Message-ID: 7. 8. 9. 10. ... I'm not going to run client-side scripts if I can't eyeball them. Creating a sandbox is a huge, complex, and difficult job, even in an application designed to run untrusted content from the ground up. Putting a blind scripting environment inside something like the SL client is risky. Putting one that isn't inherently secure in there is scary. Linden Lab does not trust the Mono sandbox on the server: you can't upload Mono bytecodes like you could LSL bytecodes. And they shouldn't. LSL bytecodes are run in an inherently secure environment... they can not perform any operation outside the capabilities of the LSL runtime: security and access controls are implemented outside the interpreter. Javascript and Activescript in Flash are in the same situation: they are languages that can (and usually do) run in an interpreter that does not even implement unsafe operations. Java and Mono/.NET intermediate language can do anything native code can, they are not inherently secure, and should not be treated the same way. * Even if the entire viewer was run in a provably secure virtual machine this would not seem like a safe option to me, since the viewer has full access to all my assets and account information in Second Life. Now there are situations where this kind of assembly would be acceptable, where it's treated and presented to the user as an application, where the user has to explicitly request that it be installed, where it is made clear that installing a plugin is the same kind of risk as installing and running an application. But not when it's something that can be pushed from an untrusted source with no more than a warning dialog between you and HonestImNotInThePN ThrowawayAlt. Even if they were using an inherently safe language, accepting unexaminable binary payloads from untrusted sources and running them in the SL client in anything like its current state would raise all kinds of warning flags with me. Doing this using an internally- sandboxed interpreter just isn't something I'm prepared to do. * No, I don't use Silverlight and I have Java disabled. From maggie at matrisync.com Thu Feb 18 05:55:17 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Thu, 18 Feb 2010 08:55:17 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: Message-ID: On Thu, Feb 18, 2010 at 8:45 AM, Argent Stonecutter wrote: > Java and Mono/.NET intermediate language can do anything native code can... Quibble: I can't speak for the MSFT-proprietary platforms, but Java code runs subject to the classloader's SecurityManager. I do hear talk that Silverlight is gaining the ability to do ActiveX calls. Joy. I do worry even when I hear talk of a Flash MediaPlugin, because Adobe code is famous for being exploited through scripting. "In the first quarter of 2009, malicious PDF files made up 56% of all exploits tracked by ScanSafe. That figure climbed above 60% in the second quarter, over 70% in the third and finished at 80% in the fourth quarter..." From adam at deepthink.com.au Thu Feb 18 06:06:04 2010 From: adam at deepthink.com.au (Frisby, Adam) Date: Thu, 18 Feb 2010 09:06:04 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: Message-ID: <63FAD4F222230A4EA79DE9E8BE664735011DA9149C@winxbeus19.exchange.xchg> Look into Code Access Security (CAS) in .NET - it is a pretty damn tough security sandbox; every operation that can be called in the default libraries is security rated; everything outside that is weighted based on: - What it declares itself - What functions in the Standard Library it calls (can only be as secure as all the functions it calls) - If it uses native code (automatically 'unsafe') From bogus@does.not.exist.com Fri Feb 5 05:04:03 2010 From: bogus@does.not.exist.com () Date: Fri, 05 Feb 2010 13:04:03 -0000 Subject: No subject Message-ID: light; although I do not know how the security holds up compared to the off= icial .NET runtime; but AppDomains + CAS is a pretty rock solid sandbox on = Windows. Regards, Adam > -----Original Message----- > From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource- > dev-bounces at lists.secondlife.com] On Behalf Of Argent Stonecutter > Sent: Thursday, 18 February 2010 5:46 AM > To: Morgaine > Cc: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Client-side scripting in Snowglobe >=20 > 7. 8. 9. 10. ... I'm not going to run client-side scripts if I can't > eyeball them. Creating a sandbox is a huge, complex, and difficult > job, even in an application designed to run untrusted content from the > ground up. Putting a blind scripting environment inside something like > the SL client is risky. Putting one that isn't inherently secure in > there is scary. >=20 > Linden Lab does not trust the Mono sandbox on the server: you can't > upload Mono bytecodes like you could LSL bytecodes. And they > shouldn't. LSL bytecodes are run in an inherently secure > environment... they can not perform any operation outside the > capabilities of the LSL runtime: security and access controls are > implemented outside the interpreter. Javascript and Activescript in > Flash are in the same situation: they are languages that can (and > usually do) run in an interpreter that does not even implement unsafe > operations. Java and Mono/.NET intermediate language can do anything > native code can, they are not inherently secure, and should not be > treated the same way. * >=20 > Even if the entire viewer was run in a provably secure virtual machine > this would not seem like a safe option to me, since the viewer has > full access to all my assets and account information in Second Life. >=20 > Now there are situations where this kind of assembly would be > acceptable, where it's treated and presented to the user as an > application, where the user has to explicitly request that it be > installed, where it is made clear that installing a plugin is the same > kind of risk as installing and running an application. But not when > it's something that can be pushed from an untrusted source with no > more than a warning dialog between you and HonestImNotInThePN > ThrowawayAlt. >=20 > Even if they were using an inherently safe language, accepting > unexaminable binary payloads from untrusted sources and running them > in the SL client in anything like its current state would raise all > kinds of warning flags with me. Doing this using an internally- > sandboxed interpreter just isn't something I'm prepared to do. >=20 > * No, I don't use Silverlight and I have Java disabled. > _______________________________________________ > 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 From maggie at matrisync.com Thu Feb 18 06:34:37 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Thu, 18 Feb 2010 09:34:37 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <63FAD4F222230A4EA79DE9E8BE664735011DA9149C@winxbeus19.exchange.xchg> References: <63FAD4F222230A4EA79DE9E8BE664735011DA9149C@winxbeus19.exchange.xchg> Message-ID: On Thu, Feb 18, 2010 at 9:06 AM, Frisby, Adam wrote: > From what I understand, Mono ended up implementing a lot of that for Silverlight; although I do not know how the security holds up compared to the official .NET runtime; but AppDomains + CAS is a pretty rock solid sandbox on Windows. Last I heard, Babbage was trying to recruit volunteer labor to build a bytecode verifier so the server-side could be safely scripted in C#. I think we all can agree that a Windows-only viewer is unacceptable. And that's a fundamental weakness of embracing MSFT tech. Imagine if LL had to run the grid on licensed Windows servers to get acceptable performance...not that they're getting it now, and the Mono LSL implementation is a big part of that problem. From adam at deepthink.com.au Thu Feb 18 06:40:24 2010 From: adam at deepthink.com.au (Frisby, Adam) Date: Thu, 18 Feb 2010 09:40:24 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <63FAD4F222230A4EA79DE9E8BE664735011DA9149C@winxbeus19.exchange.xchg> Message-ID: <63FAD4F222230A4EA79DE9E8BE664735011DA914A4@winxbeus19.exchange.xchg> Actually, Windows server isn't that expensive. Look up the SPLA pricing on things, reduces the cost down to about $10/mo, which isn't bad at all compared to the other fees you pay for hosting. ;) Adam > -----Original Message----- > From: margaret.leber at gmail.com [mailto:margaret.leber at gmail.com] On > Behalf Of Maggie Leber (sl: Maggie Darwin) > Sent: Thursday, 18 February 2010 6:35 AM > To: Frisby, Adam > Cc: Argent Stonecutter; Morgaine; opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Client-side scripting in Snowglobe > > On Thu, Feb 18, 2010 at 9:06 AM, Frisby, Adam > wrote: > > > From what I understand, Mono ended up implementing a lot of that for > Silverlight; although I do not know how the security holds up compared > to the official .NET runtime; but AppDomains + CAS is a pretty rock > solid sandbox on Windows. > > Last I heard, Babbage was trying to recruit volunteer labor to build a > bytecode verifier so the server-side could be safely scripted in C#. > > I think we all can agree that a Windows-only viewer is unacceptable. > And that's a fundamental weakness of embracing MSFT tech. Imagine if > LL had to run the grid on licensed Windows servers to get acceptable > performance...not that they're getting it now, and the Mono LSL > implementation is a big part of that problem. From q at lindenlab.com Thu Feb 18 07:57:52 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Thu, 18 Feb 2010 10:57:52 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: Message-ID: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> This makes me sad. I've been trying to have an open discussion about some of the design issues in my office hours, specifically to understand the constraints and requirements of the community. But every office hour seems to be followed up by flames on this list and in other forums interpreting what was said in the worst possible way. I'm afraid the tone and direction of this discussion are making it impossible for us to talk about this project productively. Q On Feb 18, 2010, at 7:42 AM, Morgaine wrote: > I referred recently to Linden's internal project "Firefly" to add client-side scripting to SL viewers. This has been the topic of open discussion at several Office Hours with Lindens in SL, but that openness has not extended to many design details --- the Firefly design process is not open to the community. The only technical details that are being disclosed about Firefly appear to be: > > "Scripts" are actually Mono assemblies, so that only languages that compile to Mono will be allowed. > The programs run in a sandbox, which means that most platform resources are not accessible to them. > > Please note that I quite like C# as a language, but the following remarks are about Mono use in the SL viewer, only, where its tradeoffs are poor. > > The first known detail about Firefly (mandatory Mono) is problematic on several fronts: > Only a tiny fraction of the world's applications, libraries and languages work on Mono, so client-side scripting will be unable to benefit from the huge mountain of resources available on the Internet. This is an extremely severe limitation, and an unnecessary restriction in the context of client-side viewer scripting. If I want to use a locally-installed package X from within my client-side script, I should be able to. What runs client-side should always be our individual choice, not someone else's. > Programmers want to write client-side scripts in the language that they know best, because that always yields the fastest progress and highest quality results. There was a good technical reason for forcing everyone to use LSL server-side, but there is no technical reason to impose this requirement on all client-side scripting. It is counter-productive to force CLR compatibility on client-side script developers when there is a simple alternative: define a socket-based viewer API for client-side scripts instead, hence usable from any language. > Mono runs poorly on Linux, so from being rock-solid on Linux now, the LL-derived viewers will become second-rate on this platform. > The viewer is already extremely bloated and a memory hog. Adding a Mono dependency will compound that horribly. > There is only one effective supplier of Mono: Novell. That is a very bad situation to encourage and to support in the viewer. > Some parties identify other reasons for avoiding Mono in general. Without getting into that subject at all, > > The second known detail about Firefly (mandatory sandbox) is problematic on two related fronts: > Sandboxes by design do not allow most platform resources to be accessed, as a security measure. This is fine and important when scripts are being downloaded from unknown places (like Javascript in web pages), but that same protection also means that client-side scripts would be powerless to do useful things for us in concert with local applications, files, devices, etc. Sandboxing client-side scripts effectively hardwires in script weakness for no reason discussed as a requirement. > Sandboxed applications cannot be linked with user-chosen native libraries since allowing native code breaks sandbox protection. This means no accelerators, no extensions, and no interop with other systems since sockets are inaccessible from any strong sandbox. This also means no evolution or progress outside of what the sandbox designers permit. > > This mailing list is concerned with development of open source viewers, in particular Snowglobe. This is heralded as a community viewer, embodying community requirements much more directly than the LL mainstream viewer. Client-side scripting will impact on every single aspect of Snowglobe bar none, yet the community is being excluded from the design of its most powerful infrastructure element. This is entirely wrong, far beyond the normal observation that secrecy in design has no place in open source. > > It is hard to assess things technically when the design requirements are formulated in secret. The Snowglobe community has design requirements too. Those deserve to be examined here openly, not limiting Snowglobe to a design that stems from Linden requirements alone. > > > Morgaine. > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100218/01eb0a96/attachment-0001.htm From carlo at alinoe.com Thu Feb 18 08:07:46 2010 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 18 Feb 2010 17:07:46 +0100 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> References: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> Message-ID: <20100218160746.GA6952@alinoe.com> On Thu, Feb 18, 2010 at 10:57:52AM -0500, Kent Quirk (Q Linden) wrote: > This makes me sad. > > I've been trying to have an open discussion about some of the design issues in > my office hours, specifically to understand the constraints and requirements of > the community. But every office hour seems to be followed up by flames on this > list and in other forums interpreting what was said in the worst possible way. I don't have time to attend office hours at those exact moments. Not everyone lives in the States. > I'm afraid the tone and direction of this discussion are making it impossible > for us to talk about this project productively. Yeah right. I read the posts too, and they seem to be all true. This remark sounds like a poor excuse to explain why there is no open development of client-side scripting ON THIS LIST, where it belongs. I'm sorry, but I agree with the statement of Maggie that the only sane conclusion is that, as always seems to be the case, "it is being done in secret with the intention of maximizing spin control of reactions of the user community until such initiatives are fait accompli" LL is simply not willing nor interested to listen to the (open source) community; they want no discussion and want to push what they think is best. > Q -- Carlo Wood From robertltux at gmail.com Thu Feb 18 08:16:57 2010 From: robertltux at gmail.com (Robert Martin) Date: Thu, 18 Feb 2010 11:16:57 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <20100218160746.GA6952@alinoe.com> References: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> <20100218160746.GA6952@alinoe.com> Message-ID: My suggestion would be to in cases where policies and such are being decided that LL not have an office hour (or a couple office hours) but an office DAY and yes im suggesting that a linden or lindens put in a full 12 hour time where folks can discuss the subject. Even if Y'all did it tag team style where a given linden could tag out (and another linden tag in) this would help. (maybe 3 hour blocks with a 30 minute break to keep the transcript from getting to huge) -- Robert L Martin From monkowsk at fishkill.ibm.com Thu Feb 18 08:40:27 2010 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Thu, 18 Feb 2010 11:40:27 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> References: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> Message-ID: <4B7D6D7B.2010405@fishkill.ibm.com> If you were trying to have an open discussion, then you went about it quite wrong. Nothing was mentioned on this mailing list. I don't think anything was mentioned in the Open Source Meeting (which has of late become nothing more than a Snowglobe bug triage) and I don't see any transcripts on the wiki of any other office hours discussing it. On Dec 12th Babbage Linden said "there are plans, but they are a long way off" So if you rely on hearsay to communicate your ideas, don't act surprised when they are misinterpreted. I don't mean to sound harsh, but from my viewpoint, there's nothing very "open" about SL Open Source anymore. Mike Kent Quirk (Q Linden) wrote: > This makes me sad. > > I've been trying to have an open discussion about some of the design > issues in my office hours, specifically to understand the constraints > and requirements of the community. But every office hour seems to be > followed up by flames on this list and in other forums interpreting what > was said in the worst possible way. > > I'm afraid the tone and direction of this discussion are making it > impossible for us to talk about this project productively. From morgaine.dinova at googlemail.com Thu Feb 18 08:42:35 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Thu, 18 Feb 2010 16:42:35 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> References: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> Message-ID: Kent, it is true that Office Hour discussions can sometimes get a bit heated because of the format, which allows little time for careful consideration and reflection before writing, but that is not the case here. My opening post above was polite and factual, and it considered all the points that have been revealed to us. Please do not make blanket accusations about flaming as an excuse for keeping the project under wraps, when my goal in the thread is collaboration. Quite the opposite of flaming, I am trying to bring into the open here some very key issues of viewer design that will directly affect the Snowglobe community branch of the viewer in numerous far-reaching ways. That discussion belongs here, not in informal chat at Office Hours which is a completely inappropriate medium for technical design. Re your closing line: On Thu, Feb 18, 2010 at 3:57 PM, Kent Quirk (Q Linden) wrote: > I'm afraid the tone and direction of this discussion are making it > impossible for us to talk about this project productively. > The direction of this discussion is towards involving the Snowglobe community in the design process for their viewer. The tone of this discussion is (speaking for myself) polite. I see no reason why you would not wish to talk about the design of client-side scripting with us, very productively. Morgaine. ==================================== On Thu, Feb 18, 2010 at 3:57 PM, Kent Quirk (Q Linden) wrote: > This makes me sad. > > I've been trying to have an open discussion about some of the design issues > in my office hours, specifically to understand the constraints and > requirements of the community. But every office hour seems to be followed up > by flames on this list and in other forums interpreting what was said in the > worst possible way. > > I'm afraid the tone and direction of this discussion are making it > impossible for us to talk about this project productively. > > Q > > > On Feb 18, 2010, at 7:42 AM, Morgaine wrote: > > I referred recently to Linden's internal project "Firefly" to add > client-side scripting to SL viewers. This has been the topic of open > discussion at several Office Hours with Lindens in SL, but that openness has > not extended to many design details --- the Firefly design process is not > open to the community. The only technical details that are being disclosed > about Firefly appear to be: > > > - "Scripts" are actually *Mono assemblies*, so that only languages that > compile to Mono will be allowed. > - The programs run in a *sandbox*, which means that most platform > resources are not accessible to them. > > > Please note that I quite like C# as a language, but the following remarks > are about Mono use *in the SL viewer*, only, where its tradeoffs are poor. > > The first known detail about Firefly (mandatory Mono) is problematic on > several fronts: > > 1. Only a tiny fraction of the world's applications, libraries and > languages work on Mono, so client-side scripting will be unable to benefit > from the huge mountain of resources available on the Internet. This is an > extremely severe limitation, and an unnecessary restriction in the context > of client-side viewer scripting. If I want to use a locally-installed > package X from within my client-side script, I should be able to. What runs > client-side should always be our individual choice, not someone else's. > 2. Programmers want to write client-side scripts in the language that > they know best, because that always yields the fastest progress and highest > quality results. There was a good technical reason for forcing everyone to > use LSL server-side, but there is no technical reason to impose this > requirement on all client-side scripting. It is counter-productive to force > CLR compatibility on client-side script developers when there is a simple > alternative: define a *socket-based viewer API* for client-side > scripts instead, hence usable from any language. > 3. Mono runs poorly on Linux, so from being rock-solid on Linux now, > the LL-derived viewers will become second-rate on this platform. > 4. The viewer is already extremely bloated and a memory hog. Adding a > Mono dependency will compound that horribly. > 5. There is only one effective supplier of Mono: Novell. That is a > very bad situation to encourage and to support in the viewer. > 6. Some parties identify other reasons for avoiding Mono in general. > Without getting into that subject at all, > > > The second known detail about Firefly (mandatory sandbox) is problematic on > two related fronts: > > 1. Sandboxes by design do not allow most platform resources to be > accessed, as a security measure. This is fine and important when scripts > are being downloaded from unknown places (like Javascript in web pages), but > that same protection also means that client-side scripts would be powerless > to do useful things for us in concert with local applications, files, > devices, etc. Sandboxing client-side scripts effectively hardwires in > script weakness for no reason discussed as a requirement. > 2. Sandboxed applications cannot be linked with user-chosen native > libraries since allowing native code breaks sandbox protection. This means > no accelerators, no extensions, and no interop with other systems since > sockets are inaccessible from any strong sandbox. This also means no > evolution or progress outside of what the sandbox designers permit. > > > This mailing list is concerned with development of open source viewers, in > particular Snowglobe. This is heralded as a *community* viewer, embodying > *community* requirements much more directly than the LL mainstream viewer. > Client-side scripting will impact on every single aspect of Snowglobe bar > none, yet the community is being excluded from the design of its most > powerful infrastructure element. This is entirely wrong, far beyond the > normal observation that secrecy in design has no place in open source. > > It is hard to assess things technically when the design requirements are > formulated in secret. The Snowglobe community has design requirements too. > Those deserve to be examined here openly, not limiting Snowglobe to a > design that stems from Linden requirements alone. > > > Morgaine. > > _______________________________________________ > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100218/02edcb70/attachment.htm From maggie at matrisync.com Thu Feb 18 09:28:13 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Thu, 18 Feb 2010 12:28:13 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> References: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> Message-ID: On Thu, Feb 18, 2010 at 10:57 AM, Kent Quirk (Q Linden) wrote: > This makes me sad. There's lots to be sad about. I think current Linden Research policies regarding viewer design and development has severely damaged the trust relationship that should exist within an open-source developer community. That's a much bigger impact on productivity than any personal complaints about "tone". From kow at sapinski.com Thu Feb 18 10:31:43 2010 From: kow at sapinski.com (k\o\w) Date: Thu, 18 Feb 2010 13:31:43 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> Message-ID: <4B7D878F.1050505@sapinski.com> I for one agree with Q. The biggest complaints come from the most insignificant people. If LL prioritized development based on the complaints in this mailing list, they would be rewriting SL for Linux using GTK and maintaining a dozen branches for ever popular flavour of unix. But then we'd just be playing a thinly veiled OpenCroquet. Instead of making accusations and generating pages upon pages of arguments based on hearsay, why not ask a well thought out question that a developer can answer with a simple yes or no? I'd much rather Q and his coworkers spent time developing cool things than entertaining your pointless nerd rage about Mono. On 2/18/2010 12:28 PM, Maggie Leber (sl: Maggie Darwin) wrote: > On Thu, Feb 18, 2010 at 10:57 AM, Kent Quirk (Q Linden) wrote: > >> This makes me sad. >> > There's lots to be sad about. > > I think current Linden Research policies regarding viewer design and > development has severely damaged the trust relationship that should > exist within an open-source developer community. > > That's a much bigger impact on productivity than any personal > complaints about "tone". > _______________________________________________ > 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 > > From thickbrick.sleaford at gmail.com Thu Feb 18 10:34:45 2010 From: thickbrick.sleaford at gmail.com (Thickbrick Sleaford) Date: Thu, 18 Feb 2010 20:34:45 +0200 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> References: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> Message-ID: <201002182034.45584.thickbrick.sleaford@gmail.com> On Thursday 18 February 2010 17:57:52 Kent Quirk (Q Linden) wrote: > This makes me sad. > > I've been trying to have an open discussion about some of the design issues > in my office hours, specifically to understand the constraints and > requirements of the community. But every office hour seems to be followed > up by flames on this list and in other forums interpreting what was said > in the worst possible way. > > I'm afraid the tone and direction of this discussion are making it > impossible for us to talk about this project productively. > > Q I think this is a good point in this budding flamewar to bring this up: http://lwn.net/Articles/370157/ Josh Berkus' patented ten-step method on how to free a project of unwelcome community involvement. (A little) more seriously, if the current trend towards secrecy at LL is a result of 3rd party viewers based on LL code "stealing" mindshare, it should be pointed that the developers of those viewers chose that route mainly as a result of LLs past lack of involvement with open source contributors, and (again, past) opaque and SLOW process of patch submission. To move this to a more productive direction, can you give a summary of what Firefly is, for those of us who weren't at your office hour? -- Thickbrick From monkowsk at fishkill.ibm.com Thu Feb 18 10:46:33 2010 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Thu, 18 Feb 2010 13:46:33 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <4B7D878F.1050505@sapinski.com> References: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> <4B7D878F.1050505@sapinski.com> Message-ID: <4B7D8B09.1080209@fishkill.ibm.com> OK. I get it. You like fanning the fires of flame wars. Very funny. Mike k\o\w wrote: > I for one agree with Q. The biggest complaints come from the most > insignificant people. If LL prioritized development based on the > complaints in this mailing list, they would be rewriting SL for Linux > using GTK and maintaining a dozen branches for ever popular flavour of > unix. But then we'd just be playing a thinly veiled OpenCroquet. > > Instead of making accusations and generating pages upon pages of > arguments based on hearsay, why not ask a well thought out question that > a developer can answer with a simple yes or no? I'd much rather Q and > his coworkers spent time developing cool things than entertaining your > pointless nerd rage about Mono. From tayra.dagostino at gmail.com Thu Feb 18 10:53:38 2010 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Thu, 18 Feb 2010 19:53:38 +0100 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: <20100218123613.GA32179@alinoe.com> References: <4B7C0BA1.2030604@fishkill.ibm.com> <4B7C43BF.6010000@sapinski.com> <20100218123613.GA32179@alinoe.com> Message-ID: <20100218195338.2ccc8240.tayra.dagostino@gmail.com> On Thu, 18 Feb 2010 13:36:13 +0100 Carlo Wood wrote: > On Wed, Feb 17, 2010 at 02:30:07PM -0500, kow wrote: > > Snowglobe should work out of the box with VS2005. Emerald and > > Imprudence are easier options if you're using VS2008. I believe the > > only issue with VS2008 + snowglobe is boost, and the libs from > > Emerald or Imprudence can be dropped in to fix that. > > One would wonder why Emerald can fix this, and LL can't. why ppl don't understand how work a opensource community, and prefer work on own project in place to work together for a common powerfull project... From djfoxyslpr at gmail.com Thu Feb 18 11:06:54 2010 From: djfoxyslpr at gmail.com (Jonathan Irvin) Date: Thu, 18 Feb 2010 13:06:54 -0600 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: <20100218195338.2ccc8240.tayra.dagostino@gmail.com> References: <4B7C0BA1.2030604@fishkill.ibm.com> <4B7C43BF.6010000@sapinski.com> <20100218123613.GA32179@alinoe.com> <20100218195338.2ccc8240.tayra.dagostino@gmail.com> Message-ID: <9f4fbd5c1002181106g69ada390ocf853801866c6668@mail.gmail.com> That's the open-source way. Regardless of community, we're still human and us humans love ownership...whether its taking our favorite phone and customizing it with all our favorite apps or taking the concept of a viewer and releasing our own spin on it. I gotta give credit to the Emerald folks for pushing their own ideas and moving forward with it and then watch it blossom into one of the most-used 3rd-party viewers out there. Developers kill for that kind of recognition. I think they should keep on trucking on their current path and when Viewer II comes out, use the positives of it, fix the negatives, and make an Emerald II viewer. I can only imagine the possibilities! As far as SnowGlobe goes, I wish it was more modular like linux goes. To where we can add packages or remove them from the base install to grant us this or that. When one module gets updated we can just download it as needed. Also....*Hey Linden Labs, when are we going to put Second Life in linux package format so we can just link to your repo and have us be able to install and upgrade from our respective package managers, i.e Yum & Apt-Get? * On Thu, Feb 18, 2010 at 12:53, Tayra Dagostino wrote: > On Thu, 18 Feb 2010 13:36:13 +0100 > Carlo Wood wrote: > > > On Wed, Feb 17, 2010 at 02:30:07PM -0500, kow wrote: > > > Snowglobe should work out of the box with VS2005. Emerald and > > > Imprudence are easier options if you're using VS2008. I believe the > > > only issue with VS2008 + snowglobe is boost, and the libs from > > > Emerald or Imprudence can be dropped in to fix that. > > > > One would wonder why Emerald can fix this, and LL can't. > > why ppl don't understand how work a opensource community, and prefer > work on own project in place to work together for a common powerfull > project... > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100218/751b60e6/attachment.htm From dahliatrimble at gmail.com Thu Feb 18 11:07:46 2010 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 18 Feb 2010 11:07:46 -0800 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: Message-ID: I haven't been following this topic in any office hours so I hope my comments aren't too off base. Personally I'd prefer to be able to run extensions as sandboxed, and maybe have the option of running them unprotected on a per-extension basis. To me, an environment such as SL or the web in general tend to attract a few malicious developers, or more so, companies and individuals who are interested in collecting personal data and usage patterns. I'd prefer some level of control over what they can access without needing to understand the source code of any scripted extensions (if indeed source was available). Concerning Morgaine's list: while I may not fully agree with reasons 1-4, they appear to reflect valid concerns and are presented in a agreeable manner. Reasons 5 and 6 seem to imply political overtones to me, and I suspect any platform choice will carry some political burden with it. Personally I believe mono to be a reasonable choice for a scripting environment, especially given LL's experience with it in their servers. And now since I don't contribute to the LL viewer source, I'll shut up :) -d On Thu, Feb 18, 2010 at 4:57 AM, Morgaine wrote: > A line got lost from my post owing to finger trouble. Item 6 about Mono > should have read: > > > 6. Some parties identify other reasons for avoiding Mono in general. > Without getting into that subject at all, requiring Mono for client-side > scripting would make scripting unavailable to that portion of the user > base. Since client-side scripting without Mono is perfectly feasible, Mono > should not be made mandatory for scripting, so that the widest user base can > be supported. > > > Morgaine. > > > > > > ======================== > > > On Thu, Feb 18, 2010 at 12:42 PM, Morgaine > wrote: > >> I referred recently to Linden's internal project "Firefly" to add >> client-side scripting to SL viewers. This has been the topic of open >> discussion at several Office Hours with Lindens in SL, but that openness has >> not extended to many design details --- the Firefly design process is not >> open to the community. The only technical details that are being disclosed >> about Firefly appear to be: >> >> >> - "Scripts" are actually *Mono assemblies*, so that only languages >> that compile to Mono will be allowed. >> - The programs run in a *sandbox*, which means that most platform >> resources are not accessible to them. >> >> >> Please note that I quite like C# as a language, but the following remarks >> are about Mono use *in the SL viewer*, only, where its tradeoffs are >> poor. >> >> The first known detail about Firefly (mandatory Mono) is problematic on >> several fronts: >> >> 1. Only a tiny fraction of the world's applications, libraries and >> languages work on Mono, so client-side scripting will be unable to benefit >> from the huge mountain of resources available on the Internet. This is an >> extremely severe limitation, and an unnecessary restriction in the context >> of client-side viewer scripting. If I want to use a locally-installed >> package X from within my client-side script, I should be able to. What runs >> client-side should always be our individual choice, not someone else's. >> 2. Programmers want to write client-side scripts in the language that >> they know best, because that always yields the fastest progress and highest >> quality results. There was a good technical reason for forcing everyone to >> use LSL server-side, but there is no technical reason to impose this >> requirement on all client-side scripting. It is counter-productive to force >> CLR compatibility on client-side script developers when there is a simple >> alternative: define a *socket-based viewer API* for client-side >> scripts instead, hence usable from any language. >> 3. Mono runs poorly on Linux, so from being rock-solid on Linux now, >> the LL-derived viewers will become second-rate on this platform. >> 4. The viewer is already extremely bloated and a memory hog. Adding a >> Mono dependency will compound that horribly. >> 5. There is only one effective supplier of Mono: Novell. That is a >> very bad situation to encourage and to support in the viewer. >> 6. Some parties identify other reasons for avoiding Mono in general. >> Without getting into that subject at all, >> >> >> The second known detail about Firefly (mandatory sandbox) is problematic >> on two related fronts: >> >> 1. Sandboxes by design do not allow most platform resources to be >> accessed, as a security measure. This is fine and important when scripts >> are being downloaded from unknown places (like Javascript in web pages), but >> that same protection also means that client-side scripts would be powerless >> to do useful things for us in concert with local applications, files, >> devices, etc. Sandboxing client-side scripts effectively hardwires in >> script weakness for no reason discussed as a requirement. >> 2. Sandboxed applications cannot be linked with user-chosen native >> libraries since allowing native code breaks sandbox protection. This means >> no accelerators, no extensions, and no interop with other systems since >> sockets are inaccessible from any strong sandbox. This also means no >> evolution or progress outside of what the sandbox designers permit. >> >> >> This mailing list is concerned with development of open source viewers, in >> particular Snowglobe. This is heralded as a *community* viewer, >> embodying *community* requirements much more directly than the LL >> mainstream viewer. Client-side scripting will impact on every single aspect >> of Snowglobe bar none, yet the community is being excluded from the design >> of its most powerful infrastructure element. This is entirely wrong, far >> beyond the normal observation that secrecy in design has no place in open >> source. >> >> It is hard to assess things technically when the design requirements are >> formulated in secret. The Snowglobe community has design requirements too. >> Those deserve to be examined here openly, not limiting Snowglobe to a >> design that stems from Linden requirements alone. >> >> >> Morgaine. >> >> > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100218/aa78af67/attachment-0001.htm From djfoxyslpr at gmail.com Thu Feb 18 11:08:50 2010 From: djfoxyslpr at gmail.com (Jonathan Irvin) Date: Thu, 18 Feb 2010 13:08:50 -0600 Subject: [opensource-dev] Second Life Package Repo Message-ID: <9f4fbd5c1002181108q551955acibab27dcb70fc604e@mail.gmail.com> Moving this to it's own thread... Hey Linden Labs, when are we going to put Second Life in linux package format so we can just link to your repo and have us be able to install and upgrade from our respective package managers, i.e Yum & Apt-Get? This would really speed up the way we handle SnowGlobe. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100218/fd64ebc2/attachment.htm From robin.cornelius at gmail.com Thu Feb 18 11:47:38 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 18 Feb 2010 19:47:38 +0000 Subject: [opensource-dev] Second Life Package Repo In-Reply-To: <9f4fbd5c1002181108q551955acibab27dcb70fc604e@mail.gmail.com> References: <9f4fbd5c1002181108q551955acibab27dcb70fc604e@mail.gmail.com> Message-ID: On Thu, Feb 18, 2010 at 7:08 PM, Jonathan Irvin wrote: > Moving this to it's own thread... > > Hey Linden Labs, when are we going to put Second Life in linux package > format so we can just link to your repo and have us be able to install and > upgrade from our respective package managers, i.e Yum & Apt-Get?? This would > really speed up the way we handle SnowGlobe. > Well i'm not from LL, but i have been maintaining Debian and Ubuntu repositories for the more than 2 years. Originaly as a fork viewer known as omvviewer, i'm focusing on snowglobe a lot more now (on the repositories) and have the 1.3 version of snowglobe (well 1.3 SVN + patches i hope to commit to SVN) up and running for testing. So you can apt-get install snowglobe directly from my repository. I'm also a committer to snowglobe and helping with various build and cmake issues are one of the things i have done to help ensure keeping this on a resposotory is as smooth a process as possible. The basic details can be found at http://omvviewer.byteme.org.uk linking to debian and ubuntu (and others) instructions and the package. Although that page is a little out of date as it still talks mostly about omvviewer. Regards Robin From cjac at colliertech.org Thu Feb 18 11:57:38 2010 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Thu, 18 Feb 2010 11:57:38 -0800 Subject: [opensource-dev] Second Life Package Repo In-Reply-To: <9f4fbd5c1002181108q551955acibab27dcb70fc604e@mail.gmail.com> References: <9f4fbd5c1002181108q551955acibab27dcb70fc604e@mail.gmail.com> Message-ID: <1266523058.6140.167.camel@calcifer> Do we have any ubuntu folks on the list who might consider setting up a PPA? A few years ago (May 2008), I did a bit of work putting together a build system using gar called "garindra". It's totally out of date now, but I learned enough then, and I've learned enough since then about packaging stuff for debuntu, that I can probably make something go. If people care enough to warrant such an effort ;) Cheers, C.J. On Thu, 2010-02-18 at 13:08 -0600, Jonathan Irvin wrote: > Moving this to it's own thread... > > Hey Linden Labs, when are we going to put Second Life in linux package > format so we can just link to your repo and have us be able to install > and upgrade from our respective package managers, i.e Yum & Apt-Get? > This would really speed up the way we handle SnowGlobe. > _______________________________________________ > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100218/591df49e/attachment.pgp From robin.cornelius at gmail.com Thu Feb 18 12:00:57 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 18 Feb 2010 20:00:57 +0000 Subject: [opensource-dev] Second Life Package Repo In-Reply-To: <1266523058.6140.167.camel@calcifer> References: <9f4fbd5c1002181108q551955acibab27dcb70fc604e@mail.gmail.com> <1266523058.6140.167.camel@calcifer> Message-ID: On Thu, Feb 18, 2010 at 7:57 PM, C.J. Adams-Collier wrote: > Do we have any ubuntu folks on the list who might consider setting up a > PPA? > https://launchpad.net/~openmetaverse/+archive/ppa?field.series_filter=karmic But if people want to join in and help with the snowglobe building for ubuntu, you are more than welcome to come and join me. Robin From cjac at colliertech.org Thu Feb 18 12:42:25 2010 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Thu, 18 Feb 2010 12:42:25 -0800 Subject: [opensource-dev] Second Life Package Repo In-Reply-To: References: <9f4fbd5c1002181108q551955acibab27dcb70fc604e@mail.gmail.com> <1266523058.6140.167.camel@calcifer> Message-ID: <1266525745.6140.214.camel@calcifer> Does it depend on a different PPA? The following packages have unmet dependencies: snowglobe: Depends: snowglobe-data (= 1.3.1-6) but it is not going to be installed Recommends: gstreamer0.10-plugins-ffmpeg but it is not installable Recommends: gstreamer0.10-pitfdll but it is not installable Recommends: w32codecs but it is not installable On Thu, 2010-02-18 at 20:00 +0000, Robin Cornelius wrote: > On Thu, Feb 18, 2010 at 7:57 PM, C.J. Adams-Collier > wrote: > > Do we have any ubuntu folks on the list who might consider setting up a > > PPA? > > > > https://launchpad.net/~openmetaverse/+archive/ppa?field.series_filter=karmic > > But if people want to join in and help with the snowglobe building for > ubuntu, you are more than welcome to come and join me. > > Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100218/1e6cd759/attachment.pgp From robin.cornelius at gmail.com Thu Feb 18 12:50:06 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 18 Feb 2010 20:50:06 +0000 Subject: [opensource-dev] Second Life Package Repo In-Reply-To: <1266525745.6140.214.camel@calcifer> References: <9f4fbd5c1002181108q551955acibab27dcb70fc604e@mail.gmail.com> <1266523058.6140.167.camel@calcifer> <1266525745.6140.214.camel@calcifer> Message-ID: On Thu, Feb 18, 2010 at 8:42 PM, C.J. Adams-Collier wrote: > Does it depend on a different PPA? > > The following packages have unmet dependencies: > ?snowglobe: Depends: snowglobe-data (= 1.3.1-6) but it is not going to be installed > ? ? ? ? ? ? Recommends: gstreamer0.10-plugins-ffmpeg but it is not installable > ? ? ? ? ? ? Recommends: gstreamer0.10-pitfdll but it is not installable > ? ? ? ? ? ? Recommends: w32codecs but it is not installable > No snowglobe-data is a dependency and is built off the same snowglobe source? the repository should have everything that is not in a standard karmic release of ubuntu. The recommends are in the full unrestricted ubuntu repository (non-free), as thats got the various win32 codecs and other decoders that are needed if you want to play all video in world via gstreamer. Is it the recommends that are causing the issue here? Robin From morgaine.dinova at googlemail.com Thu Feb 18 14:27:30 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Thu, 18 Feb 2010 22:27:30 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: Message-ID: On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble wrote: > To me, an environment such as SL or the web in general tend to attract a > few malicious developers, or more so, companies and individuals who are > interested in collecting personal data and usage patterns. I'd prefer some > level of control over what they can access without needing to understand the > source code of any scripted extensions (if indeed source was available). > > Dahlia, I agree with part of that, to the extent where it applies: The "malicious users" argument presupposes that scripts come from 3rd parties, some of whom are malicious. When people write their own scripts, which is very common in this opensource-dev community, they are not malicious 3rd parties, and they do not generally want to be treated as such. Quite the opposite, they want all the power that scripting on their local platform can give them. Therefore the "malicious users" argument applies only to a subset of scripts, the downloaded ones, and it is perfectly valid there. However, it does not apply to one's own scripts, nor to any other power-users' scripts that one wishes to trust. This leads directly to a rather fundamental requirement: the sandbox must be optional, applying only to the use case of unknown downloaded scripts, and not applying when the user wishes her scripts to be used as an interface to local facilities. It is considerations such as this that Lindens should be exploring together with the community here, because it impacts on the future of Snowglobe directly and in a colossal way. We are all affected. Designing this behind closed doors is not adequate, nor is it appropriate in an open source community viewer. Morgaine. ========================================== On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble wrote: > I haven't been following this topic in any office hours so I hope my > comments aren't too off base. > > Personally I'd prefer to be able to run extensions as sandboxed, and maybe > have the option of running them unprotected on a per-extension basis. To me, > an environment such as SL or the web in general tend to attract a few > malicious developers, or more so, companies and individuals who are > interested in collecting personal data and usage patterns. I'd prefer some > level of control over what they can access without needing to understand the > source code of any scripted extensions (if indeed source was available). > > Concerning Morgaine's list: while I may not fully agree with reasons 1-4, > they appear to reflect valid concerns and are presented in a agreeable > manner. Reasons 5 and 6 seem to imply political overtones to me, and I > suspect any platform choice will carry some political burden with it. > Personally I believe mono to be a reasonable choice for a scripting > environment, especially given LL's experience with it in their servers. > > And now since I don't contribute to the LL viewer source, I'll shut up :) > > -d > > > On Thu, Feb 18, 2010 at 4:57 AM, Morgaine wrote: > >> A line got lost from my post owing to finger trouble. Item 6 about Mono >> should have read: >> >> >> 6. Some parties identify other reasons for avoiding Mono in general. >> Without getting into that subject at all, requiring Mono for client-side >> scripting would make scripting unavailable to that portion of the user >> base. Since client-side scripting without Mono is perfectly feasible, Mono >> should not be made mandatory for scripting, so that the widest user base can >> be supported. >> >> >> Morgaine. >> >> >> >> >> >> ======================== >> >> >> On Thu, Feb 18, 2010 at 12:42 PM, Morgaine < >> morgaine.dinova at googlemail.com> wrote: >> >>> I referred recently to Linden's internal project "Firefly" to add >>> client-side scripting to SL viewers. This has been the topic of open >>> discussion at several Office Hours with Lindens in SL, but that openness has >>> not extended to many design details --- the Firefly design process is not >>> open to the community. The only technical details that are being disclosed >>> about Firefly appear to be: >>> >>> >>> - "Scripts" are actually *Mono assemblies*, so that only languages >>> that compile to Mono will be allowed. >>> - The programs run in a *sandbox*, which means that most platform >>> resources are not accessible to them. >>> >>> >>> Please note that I quite like C# as a language, but the following remarks >>> are about Mono use *in the SL viewer*, only, where its tradeoffs are >>> poor. >>> >>> The first known detail about Firefly (mandatory Mono) is problematic on >>> several fronts: >>> >>> 1. Only a tiny fraction of the world's applications, libraries and >>> languages work on Mono, so client-side scripting will be unable to benefit >>> from the huge mountain of resources available on the Internet. This is an >>> extremely severe limitation, and an unnecessary restriction in the context >>> of client-side viewer scripting. If I want to use a locally-installed >>> package X from within my client-side script, I should be able to. What runs >>> client-side should always be our individual choice, not someone else's. >>> 2. Programmers want to write client-side scripts in the language that >>> they know best, because that always yields the fastest progress and highest >>> quality results. There was a good technical reason for forcing everyone to >>> use LSL server-side, but there is no technical reason to impose this >>> requirement on all client-side scripting. It is counter-productive to force >>> CLR compatibility on client-side script developers when there is a simple >>> alternative: define a *socket-based viewer API* for client-side >>> scripts instead, hence usable from any language. >>> 3. Mono runs poorly on Linux, so from being rock-solid on Linux now, >>> the LL-derived viewers will become second-rate on this platform. >>> 4. The viewer is already extremely bloated and a memory hog. Adding >>> a Mono dependency will compound that horribly. >>> 5. There is only one effective supplier of Mono: Novell. That is a >>> very bad situation to encourage and to support in the viewer. >>> 6. Some parties identify other reasons for avoiding Mono in general. >>> Without getting into that subject at all, >>> >>> >>> The second known detail about Firefly (mandatory sandbox) is problematic >>> on two related fronts: >>> >>> 1. Sandboxes by design do not allow most platform resources to be >>> accessed, as a security measure. This is fine and important when scripts >>> are being downloaded from unknown places (like Javascript in web pages), but >>> that same protection also means that client-side scripts would be powerless >>> to do useful things for us in concert with local applications, files, >>> devices, etc. Sandboxing client-side scripts effectively hardwires in >>> script weakness for no reason discussed as a requirement. >>> 2. Sandboxed applications cannot be linked with user-chosen native >>> libraries since allowing native code breaks sandbox protection. This means >>> no accelerators, no extensions, and no interop with other systems since >>> sockets are inaccessible from any strong sandbox. This also means no >>> evolution or progress outside of what the sandbox designers permit. >>> >>> >>> This mailing list is concerned with development of open source viewers, >>> in particular Snowglobe. This is heralded as a *community* viewer, >>> embodying *community* requirements much more directly than the LL >>> mainstream viewer. Client-side scripting will impact on every single aspect >>> of Snowglobe bar none, yet the community is being excluded from the design >>> of its most powerful infrastructure element. This is entirely wrong, far >>> beyond the normal observation that secrecy in design has no place in open >>> source. >>> >>> It is hard to assess things technically when the design requirements are >>> formulated in secret. The Snowglobe community has design requirements too. >>> Those deserve to be examined here openly, not limiting Snowglobe to a >>> design that stems from Linden requirements alone. >>> >>> >>> Morgaine. >>> >>> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100218/eea12da8/attachment.htm From robertltux at gmail.com Thu Feb 18 14:34:03 2010 From: robertltux at gmail.com (Robert Martin) Date: Thu, 18 Feb 2010 17:34:03 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: Message-ID: On Thu, Feb 18, 2010 at 5:27 PM, Morgaine wrote: > On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble > wrote: >> >> To me, an environment such as SL or the web in general tend to attract a >> few malicious developers, or more so, companies and individuals who are >> interested in collecting personal data and usage patterns. I'd prefer some >> level of control over what they can access without needing to understand the >> source code of any scripted extensions (if indeed source was available). > > Dahlia, I agree with part of that, to the extent where it applies: > > The "malicious users" argument presupposes that scripts come from 3rd > parties, some of whom are malicious.? When people write their own scripts, > which is very common in this opensource-dev community, they are not > malicious 3rd parties, and they do not generally want to be treated as such. > > Quite the opposite, they want all the power that scripting on their local > platform can give them.? Therefore the "malicious users" argument applies > only to a subset of scripts, the downloaded ones, and it is perfectly valid > there.? However, it does not apply to one's own scripts, nor to any other > power-users' scripts that one wishes to trust. > > This leads directly to a rather fundamental requirement:? the sandbox must > be optional, applying only to the use case of unknown downloaded scripts, > and not applying when the user wishes her scripts to be used as an interface > to local facilities. > > It is considerations such as this that Lindens should be exploring together > with the community here, because it impacts on the future of Snowglobe > directly and in a colossal way.? We are all affected.? Designing this behind > closed doors is not adequate, nor is it appropriate in an open source > community viewer. > > > Morgaine. > > > > and this is where languages like perl/python have a strength since the files are plain text so if you think that a script is doing something funky you can just look at the script and see. Mono/dotnet code is compiled and very easily could hide just about anything. -- Robert L Martin From poppy at lindenlab.com Thu Feb 18 14:55:31 2010 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Thu, 18 Feb 2010 14:55:31 -0800 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> References: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> Message-ID: <4B7DC563.20808@lindenlab.com> On 2/18/10 7:57 AM, Kent Quirk (Q Linden) wrote: > I've been trying to have an open discussion about some of the design > issues in my office hours, specifically to understand the constraints > and requirements of the community. But every office hour seems to be > followed up by flames on this list and in other forums interpreting what > was said in the worst possible way. Could you please post the transcripts of your office hours? The newest I see for you is http://wiki.secondlife.com/wiki/User:Q_Linden/Office_Hours/2008-01-07 Thanks! + poppy From nexisentertainment at gmail.com Thu Feb 18 21:24:24 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Thu, 18 Feb 2010 21:24:24 -0800 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: Message-ID: <1266557064.3694.4302.camel@RAGE> B-B-But what about Lua, which has already been implemented in FlexLife (http://flexlife.nexisonline.net)? :( Fred Rookstown Lead Developer On Thu, 2010-02-18 at 12:42 +0000, Morgaine wrote: > I referred recently to Linden's internal project "Firefly" to add > client-side scripting to SL viewers. This has been the topic of open > discussion at several Office Hours with Lindens in SL, but that > openness has not extended to many design details --- the Firefly > design process is not open to the community. The only technical > details that are being disclosed about Firefly appear to be: > > * "Scripts" are actually Mono assemblies, so that only languages > that compile to Mono will be allowed. > * The programs run in a sandbox, which means that most platform > resources are not accessible to them. > > Please note that I quite like C# as a language, but the following > remarks are about Mono use in the SL viewer, only, where its tradeoffs > are poor. > > The first known detail about Firefly (mandatory Mono) is problematic > on several fronts: > 1. Only a tiny fraction of the world's applications, libraries > and languages work on Mono, so client-side scripting will be > unable to benefit from the huge mountain of resources > available on the Internet. This is an extremely severe > limitation, and an unnecessary restriction in the context of > client-side viewer scripting. If I want to use a > locally-installed package X from within my client-side script, > I should be able to. What runs client-side should always be > our individual choice, not someone else's. > 2. Programmers want to write client-side scripts in the language > that they know best, because that always yields the fastest > progress and highest quality results. There was a good > technical reason for forcing everyone to use LSL server-side, > but there is no technical reason to impose this requirement on > all client-side scripting. It is counter-productive to force > CLR compatibility on client-side script developers when there > is a simple alternative: define a socket-based viewer API for > client-side scripts instead, hence usable from any language. > 3. Mono runs poorly on Linux, so from being rock-solid on Linux > now, the LL-derived viewers will become second-rate on this > platform. > 4. The viewer is already extremely bloated and a memory hog. > Adding a Mono dependency will compound that horribly. > 5. There is only one effective supplier of Mono: Novell. That > is a very bad situation to encourage and to support in the > viewer. > 6. Some parties identify other reasons for avoiding Mono in > general. Without getting into that subject at all, > > The second known detail about Firefly (mandatory sandbox) is > problematic on two related fronts: > 1. Sandboxes by design do not allow most platform resources to be > accessed, as a security measure. This is fine and important > when scripts are being downloaded from unknown places (like > Javascript in web pages), but that same protection also means > that client-side scripts would be powerless to do useful > things for us in concert with local applications, files, > devices, etc. Sandboxing client-side scripts effectively > hardwires in script weakness for no reason discussed as a > requirement. > 2. Sandboxed applications cannot be linked with user-chosen > native libraries since allowing native code breaks sandbox > protection. This means no accelerators, no extensions, and no > interop with other systems since sockets are inaccessible from > any strong sandbox. This also means no evolution or progress > outside of what the sandbox designers permit. > > This mailing list is concerned with development of open source > viewers, in particular Snowglobe. This is heralded as a community > viewer, embodying community requirements much more directly than the > LL mainstream viewer. Client-side scripting will impact on every > single aspect of Snowglobe bar none, yet the community is being > excluded from the design of its most powerful infrastructure element. > This is entirely wrong, far beyond the normal observation > that secrecy in design has no place in open source. > > It is hard to assess things technically when the design requirements > are formulated in secret. The Snowglobe community has design > requirements too. Those deserve to be examined here openly, not > limiting Snowglobe to a design that stems from Linden requirements > alone. > > > Morgaine. > > _______________________________________________ > 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 From kf6kjg at gmail.com Thu Feb 18 23:16:11 2010 From: kf6kjg at gmail.com (Ricky) Date: Thu, 18 Feb 2010 23:16:11 -0800 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: Message-ID: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> I suspect that there are two things being discussed here without distinction: Client scripting, and client extensions. Confusing the two is easy. Client-side scripting SHOULD be sandboxed, and in a controlled set of languages. For a close example think of javascript in web browsers. Client extensions, or alternatively named as "plugins", would be modules that can be plugged in and out of the client and run /as if/ they were a part of the client. Think of browser add-ons/plugins/extensions. Client side scripts could (read might be, could possibly, needs further thought, etc.) be given permission to be loaded in by worn items automatically. Other objects would likely need to request permission via a security warning. Client extensions would have to be downloaded and installed externally; not delivered in-world. These would truly be programs on your computer, and should be treated as such. Just my thoughts hoping for a clearer discussion. Ricky Cron Stardust On Thu, Feb 18, 2010 at 2:27 PM, Morgaine wrote: > On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble wrote: > >> To me, an environment such as SL or the web in general tend to attract a >> few malicious developers, or more so, companies and individuals who are >> interested in collecting personal data and usage patterns. I'd prefer some >> level of control over what they can access without needing to understand the >> source code of any scripted extensions (if indeed source was available). >> >> > Dahlia, I agree with part of that, to the extent where it applies: > > The "malicious users" argument presupposes that scripts come from 3rd > parties, some of whom are malicious. When people write their own scripts, > which is very common in this opensource-dev community, they are not > malicious 3rd parties, and they do not generally want to be treated as such. > > Quite the opposite, they want all the power that scripting on their local > platform can give them. Therefore the "malicious users" argument applies > only to a subset of scripts, the downloaded ones, and it is perfectly valid > there. However, it does not apply to one's own scripts, nor to any other > power-users' scripts that one wishes to trust. > > This leads directly to a rather fundamental requirement: the sandbox must > be optional, applying only to the use case of unknown downloaded scripts, > and not applying when the user wishes her scripts to be used as an interface > to local facilities. > > It is considerations such as this that Lindens should be exploring together > with the community here, because it impacts on the future of Snowglobe > directly and in a colossal way. We are all affected. Designing this behind > closed doors is not adequate, nor is it appropriate in an open source > community viewer. > > > Morgaine. > > > > > > ========================================== > > > On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble wrote: > >> I haven't been following this topic in any office hours so I hope my >> comments aren't too off base. >> >> Personally I'd prefer to be able to run extensions as sandboxed, and maybe >> have the option of running them unprotected on a per-extension basis. To me, >> an environment such as SL or the web in general tend to attract a few >> malicious developers, or more so, companies and individuals who are >> interested in collecting personal data and usage patterns. I'd prefer some >> level of control over what they can access without needing to understand the >> source code of any scripted extensions (if indeed source was available). >> >> Concerning Morgaine's list: while I may not fully agree with reasons 1-4, >> they appear to reflect valid concerns and are presented in a agreeable >> manner. Reasons 5 and 6 seem to imply political overtones to me, and I >> suspect any platform choice will carry some political burden with it. >> Personally I believe mono to be a reasonable choice for a scripting >> environment, especially given LL's experience with it in their servers. >> >> And now since I don't contribute to the LL viewer source, I'll shut up :) >> >> -d >> >> >> On Thu, Feb 18, 2010 at 4:57 AM, Morgaine > > wrote: >> >>> A line got lost from my post owing to finger trouble. Item 6 about Mono >>> should have read: >>> >>> >>> 6. Some parties identify other reasons for avoiding Mono in general. >>> Without getting into that subject at all, requiring Mono for client-side >>> scripting would make scripting unavailable to that portion of the user >>> base. Since client-side scripting without Mono is perfectly feasible, Mono >>> should not be made mandatory for scripting, so that the widest user base can >>> be supported. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> ======================== >>> >>> >>> On Thu, Feb 18, 2010 at 12:42 PM, Morgaine < >>> morgaine.dinova at googlemail.com> wrote: >>> >>>> I referred recently to Linden's internal project "Firefly" to add >>>> client-side scripting to SL viewers. This has been the topic of open >>>> discussion at several Office Hours with Lindens in SL, but that openness has >>>> not extended to many design details --- the Firefly design process is not >>>> open to the community. The only technical details that are being disclosed >>>> about Firefly appear to be: >>>> >>>> >>>> - "Scripts" are actually *Mono assemblies*, so that only languages >>>> that compile to Mono will be allowed. >>>> - The programs run in a *sandbox*, which means that most platform >>>> resources are not accessible to them. >>>> >>>> >>>> Please note that I quite like C# as a language, but the following >>>> remarks are about Mono use *in the SL viewer*, only, where its >>>> tradeoffs are poor. >>>> >>>> The first known detail about Firefly (mandatory Mono) is problematic on >>>> several fronts: >>>> >>>> 1. Only a tiny fraction of the world's applications, libraries and >>>> languages work on Mono, so client-side scripting will be unable to benefit >>>> from the huge mountain of resources available on the Internet. This is an >>>> extremely severe limitation, and an unnecessary restriction in the context >>>> of client-side viewer scripting. If I want to use a locally-installed >>>> package X from within my client-side script, I should be able to. What runs >>>> client-side should always be our individual choice, not someone else's. >>>> 2. Programmers want to write client-side scripts in the language >>>> that they know best, because that always yields the fastest progress and >>>> highest quality results. There was a good technical reason for forcing >>>> everyone to use LSL server-side, but there is no technical reason to impose >>>> this requirement on all client-side scripting. It is counter-productive to >>>> force CLR compatibility on client-side script developers when there is a >>>> simple alternative: define a *socket-based viewer API* for >>>> client-side scripts instead, hence usable from any language. >>>> 3. Mono runs poorly on Linux, so from being rock-solid on Linux now, >>>> the LL-derived viewers will become second-rate on this platform. >>>> 4. The viewer is already extremely bloated and a memory hog. Adding >>>> a Mono dependency will compound that horribly. >>>> 5. There is only one effective supplier of Mono: Novell. That is a >>>> very bad situation to encourage and to support in the viewer. >>>> 6. Some parties identify other reasons for avoiding Mono in general. >>>> Without getting into that subject at all, >>>> >>>> >>>> The second known detail about Firefly (mandatory sandbox) is problematic >>>> on two related fronts: >>>> >>>> 1. Sandboxes by design do not allow most platform resources to be >>>> accessed, as a security measure. This is fine and important when scripts >>>> are being downloaded from unknown places (like Javascript in web pages), but >>>> that same protection also means that client-side scripts would be powerless >>>> to do useful things for us in concert with local applications, files, >>>> devices, etc. Sandboxing client-side scripts effectively hardwires in >>>> script weakness for no reason discussed as a requirement. >>>> 2. Sandboxed applications cannot be linked with user-chosen native >>>> libraries since allowing native code breaks sandbox protection. This means >>>> no accelerators, no extensions, and no interop with other systems since >>>> sockets are inaccessible from any strong sandbox. This also means no >>>> evolution or progress outside of what the sandbox designers permit. >>>> >>>> >>>> This mailing list is concerned with development of open source viewers, >>>> in particular Snowglobe. This is heralded as a *community* viewer, >>>> embodying *community* requirements much more directly than the LL >>>> mainstream viewer. Client-side scripting will impact on every single aspect >>>> of Snowglobe bar none, yet the community is being excluded from the design >>>> of its most powerful infrastructure element. This is entirely wrong, far >>>> beyond the normal observation that secrecy in design has no place in open >>>> source. >>>> >>>> It is hard to assess things technically when the design requirements are >>>> formulated in secret. The Snowglobe community has design requirements too. >>>> Those deserve to be examined here openly, not limiting Snowglobe to a >>>> design that stems from Linden requirements alone. >>>> >>>> >>>> Morgaine. >>>> >>>> >>> >>> _______________________________________________ >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100218/6276874e/attachment-0001.htm From carlo at alinoe.com Fri Feb 19 04:42:38 2010 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 19 Feb 2010 13:42:38 +0100 Subject: [opensource-dev] step by step guide to compiling snowglobe In-Reply-To: <9f4fbd5c1002181106g69ada390ocf853801866c6668@mail.gmail.com> References: <4B7C0BA1.2030604@fishkill.ibm.com> <4B7C43BF.6010000@sapinski.com> <20100218123613.GA32179@alinoe.com> <20100218195338.2ccc8240.tayra.dagostino@gmail.com> <9f4fbd5c1002181106g69ada390ocf853801866c6668@mail.gmail.com> Message-ID: <20100219124238.GA13534@alinoe.com> On Thu, Feb 18, 2010 at 01:06:54PM -0600, Jonathan Irvin wrote: > As far as SnowGlobe goes, I wish it was more modular like linux goes.? To where > we can add packages or remove them from the base install to grant us this or > that.? When one module gets updated we can just download it as needed. I would like that too, but... as long as "we" want to stay in sync with the "official" viewer of Linden Lab (or they with us), we cannot make any large changes. I consider this a very bad thing personally, so I'm not in favour of staying in sync. I think Snowglobe would benefit to let go of trying to be merge-able with the "official viewer" and start to really allow BIG changes. > Also....Hey Linden Labs, when are we going to put Second Life in linux package > format so we can just link to your repo and have us be able to install and > upgrade from our respective package managers, i.e Yum & Apt-Get? Actually, that is the task of linux distributors. For example, in the case of debian, of volunteers that become "package manager" for a specific packet. In our case, that would be Robin Cornelius. It's not fair to look at Linden Lab for making linux packages for every distribution out there. However, they *should* listen to package managers with some kind of priority. If those request a bug fix that only LL can fix, then that is backed up by a very large number of users and should get high priority. -- Carlo Wood From carlo at alinoe.com Fri Feb 19 05:17:17 2010 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 19 Feb 2010 14:17:17 +0100 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <4B7D878F.1050505@sapinski.com> References: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> <4B7D878F.1050505@sapinski.com> Message-ID: <20100219131717.GB13534@alinoe.com> On Thu, Feb 18, 2010 at 01:31:43PM -0500, kow wrote: > I for one agree with Q. You're not really stating what you agree with here... but lets assume you mean that: - It's ok that nothing was communicated on this list about anything prior to some decisions made by LL about client-side scripting. - People shouldn't whine or flame about not being taken seriously when we tell them what has been decided behind closed doors. > The biggest complaints come from the most insignificant people. That is a flame, and pretty personal one too. But I'll try to read between the lines and make something of it; you probably mean that you didn't see any comments yet from the most active opensource coders of snowglobe yet. Those people are intelligent, of course, and have had close(r) communication with a handful of Lindens than the others, getting to know them a lot better than the average office hour visitor. Those people understand that the decisions being communicated by THOSE Lindens are not the decision of those Lindens personally (at least, I hope not, or they DO deserve the flames). Most snowglobe assigned Lindens have very little influence in the whole. They are just coders with a big boss that demands apparently pretty stricty that they cannot talk about things. I'm sure that most Lindens that we have contact with are just like you and me, they just got hired by LL and are now being frustrated by the tension that LL policy as a whole is creating between the entity Linden Lab and the "open source community" that they attracted to work on snowglobe. I think that most of the really active coders think that their personal relationship with their fellow hackers inside Linden Lab is more important than venting their frustration on a public mailinglist KNOWING that it is going to be useless, since that decision has indeed already been made (they ARE going to use mono) and even the Lindens that we CAN communicate with can't do anything about it. If anything, I admite Q for not falling back to "Sorry, but it's not my decision to make", but despite the pressure from the opensource community keeps acting as-if Linden Lab has one single mind and direction (which no doubt is the policy of LL management). > If LL prioritized development based on the > complaints in this mailing list, they would be rewriting SL for Linux > using GTK and maintaining a dozen branches for ever popular flavour of > unix. But then we'd just be playing a thinly veiled OpenCroquet. When I read such proposals I didn't take them seriously either. And perhaps it IS necessary to play parent and take the decision yourself in order to protect your kid; but it can be done better by at least first have an open discussion (on this mailinglist) about the pros and cons of whatever BIG decision (like using mono). And then I mean ***NOT*** to ask for "feedback" and then sit back and read everything and then make your decision, Babbage. I mean, to actively participate in the discussion and try to convince people with logical arguments and having an open mind for ideas that are not your own. Then, in the end, I guess someone "authoritive" has to make the final decision (because in most cases not everyone will agree with the same), which could be done in a form like: - We had a meeting today with u, v, w, x, y, z and q Linden, and after careful consideration we decided to go for mono for the following reasons: * point 1 * point 2 * it's the only thing we really have the expertise for in-house * Foobar had the argument this and that, but blah blah. * Carlo was right, but we felt that over all the advantages of mono weight more heavily than his proposal, as we already discussed on the list * and so on. > Instead of making accusations and generating pages upon pages of > arguments based on hearsay, why not ask a well thought out question that > a developer can answer with a simple yes or no? I'd much rather Q and > his coworkers spent time developing cool things than entertaining your > pointless nerd rage about Mono. I applaud your speech, and again, I agree that not any of these Lindens is personally responsible, so they don't deserve any flames. However, on this route that LL as a whole is taking now, the only logical result would be that Snowglobe splits off and becomes a TRUE opensource community driven project. And that would mean, at least in the eyes of Linden Lab, that the whole opensource project has failed. -- Carlo Wood From carlo at alinoe.com Fri Feb 19 05:24:53 2010 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 19 Feb 2010 14:24:53 +0100 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <20100219131717.GB13534@alinoe.com> References: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> <4B7D878F.1050505@sapinski.com> <20100219131717.GB13534@alinoe.com> Message-ID: <20100219132453.GC13534@alinoe.com> On Fri, Feb 19, 2010 at 02:17:17PM +0100, Carlo Wood wrote: > If anything, I admite Q for not falling back to "Sorry, but admire* From morgaine.dinova at googlemail.com Fri Feb 19 05:30:28 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Fri, 19 Feb 2010 13:30:28 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> Message-ID: Ricky, I agree with you, there are indeed two different requirements being discussed here, and confusing them as a single requirement can never yield a satisfactory result. Indeed, Dahlia and I were discussing that same thing yesterday, hereand here . I would avoid your terminology though, because both kinds of script application employ "client-side scripting", both types create dynamic "extensions", and both types can be implemented as "plugins" --- your terms directly describe the technologies that can be used in both types of application and don't distinguish between the two differing requirements. It would just add to the confusion. Instead, let's call them what they are: TRUSTED APPS, and UNTRUSTED APPS. (We can happily replace "apps/applications" with "scripts", "programs", "extensions", "plugins", "code", and many other words, while still retaining exactly the desired meaning and intent --- the key differentiator is "trusted" versus "untrusted".) The big problem we have here at the moment though is that *apparently*, Lindens want to support *untrusted* apps ONLY, as evidenced by the mandatory sandbox and mandatory use of Mono. If so, this inherently means that all the myriad uses of *trusted* client-side scripting (many more of them than untrusted) are left out in the cold. LL is refusing to even discuss this twofold requirement with us, it seems, although Q may well reconsider and rejoin the discussion here today. I hope so, because yesterday's response indicated no desire to cooperate with the mailing list on this, which would be a disaster for all. It is very unfortunate that we have to guess at Linden's intentions in this area instead of being able to work openly with them on requirements and core design. I am still hopeful though. Lindens have committed to working with the community on the open source client, and unless that happens visibly and honestly, community support is going to evaporate and move to other clients. They probably realize this, so I'm hopeful that openness will prevail at LL. The present issue is a test of this, and a massively important test because client-side scripting (of both types) is such an empowering tool for the open source community. We *need* that open cooperation, just as the company needs it, so fingers crossed. (I miss Rob massively! A champion for open source at the Lab is so badly needed.) Morgaine. ========================================= On Fri, Feb 19, 2010 at 7:16 AM, Ricky wrote: > I suspect that there are two things being discussed here without > distinction: Client scripting, and client extensions. Confusing the two is > easy. > > Client-side scripting SHOULD be sandboxed, and in a controlled set of > languages. For a close example think of javascript in web browsers. > > Client extensions, or alternatively named as "plugins", would be modules > that can be plugged in and out of the client and run /as if/ they were a > part of the client. Think of browser add-ons/plugins/extensions. > > Client side scripts could (read might be, could possibly, needs further > thought, etc.) be given permission to be loaded in by worn items > automatically. Other objects would likely need to request permission via a > security warning. > > Client extensions would have to be downloaded and installed externally; not > delivered in-world. These would truly be programs on your computer, and > should be treated as such. > > Just my thoughts hoping for a clearer discussion. > > Ricky > Cron Stardust > > On Thu, Feb 18, 2010 at 2:27 PM, Morgaine wrote: > >> On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble wrote: >> >>> To me, an environment such as SL or the web in general tend to attract a >>> few malicious developers, or more so, companies and individuals who are >>> interested in collecting personal data and usage patterns. I'd prefer some >>> level of control over what they can access without needing to understand the >>> source code of any scripted extensions (if indeed source was available). >>> >>> >> Dahlia, I agree with part of that, to the extent where it applies: >> >> The "malicious users" argument presupposes that scripts come from 3rd >> parties, some of whom are malicious. When people write their own scripts, >> which is very common in this opensource-dev community, they are not >> malicious 3rd parties, and they do not generally want to be treated as such. >> >> Quite the opposite, they want all the power that scripting on their local >> platform can give them. Therefore the "malicious users" argument applies >> only to a subset of scripts, the downloaded ones, and it is perfectly valid >> there. However, it does not apply to one's own scripts, nor to any other >> power-users' scripts that one wishes to trust. >> >> This leads directly to a rather fundamental requirement: the sandbox must >> be optional, applying only to the use case of unknown downloaded scripts, >> and not applying when the user wishes her scripts to be used as an interface >> to local facilities. >> >> It is considerations such as this that Lindens should be exploring >> together with the community here, because it impacts on the future of >> Snowglobe directly and in a colossal way. We are all affected. Designing >> this behind closed doors is not adequate, nor is it appropriate in an open >> source community viewer. >> >> >> Morgaine. >> >> >> >> >> >> ========================================== >> >> >> On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble wrote: >> >>> I haven't been following this topic in any office hours so I hope my >>> comments aren't too off base. >>> >>> Personally I'd prefer to be able to run extensions as sandboxed, and >>> maybe have the option of running them unprotected on a per-extension basis. >>> To me, an environment such as SL or the web in general tend to attract a few >>> malicious developers, or more so, companies and individuals who are >>> interested in collecting personal data and usage patterns. I'd prefer some >>> level of control over what they can access without needing to understand the >>> source code of any scripted extensions (if indeed source was available). >>> >>> Concerning Morgaine's list: while I may not fully agree with reasons 1-4, >>> they appear to reflect valid concerns and are presented in a agreeable >>> manner. Reasons 5 and 6 seem to imply political overtones to me, and I >>> suspect any platform choice will carry some political burden with it. >>> Personally I believe mono to be a reasonable choice for a scripting >>> environment, especially given LL's experience with it in their servers. >>> >>> And now since I don't contribute to the LL viewer source, I'll shut up :) >>> >>> -d >>> >>> >>> On Thu, Feb 18, 2010 at 4:57 AM, Morgaine < >>> morgaine.dinova at googlemail.com> wrote: >>> >>>> A line got lost from my post owing to finger trouble. Item 6 about Mono >>>> should have read: >>>> >>>> >>>> 6. Some parties identify other reasons for avoiding Mono in general. >>>> Without getting into that subject at all, requiring Mono for client-side >>>> scripting would make scripting unavailable to that portion of the user >>>> base. Since client-side scripting without Mono is perfectly feasible, Mono >>>> should not be made mandatory for scripting, so that the widest user base can >>>> be supported. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> >>>> ======================== >>>> >>>> >>>> On Thu, Feb 18, 2010 at 12:42 PM, Morgaine < >>>> morgaine.dinova at googlemail.com> wrote: >>>> >>>>> I referred recently to Linden's internal project "Firefly" to add >>>>> client-side scripting to SL viewers. This has been the topic of open >>>>> discussion at several Office Hours with Lindens in SL, but that openness has >>>>> not extended to many design details --- the Firefly design process is not >>>>> open to the community. The only technical details that are being disclosed >>>>> about Firefly appear to be: >>>>> >>>>> >>>>> - "Scripts" are actually *Mono assemblies*, so that only languages >>>>> that compile to Mono will be allowed. >>>>> - The programs run in a *sandbox*, which means that most platform >>>>> resources are not accessible to them. >>>>> >>>>> >>>>> Please note that I quite like C# as a language, but the following >>>>> remarks are about Mono use *in the SL viewer*, only, where its >>>>> tradeoffs are poor. >>>>> >>>>> The first known detail about Firefly (mandatory Mono) is problematic on >>>>> several fronts: >>>>> >>>>> 1. Only a tiny fraction of the world's applications, libraries and >>>>> languages work on Mono, so client-side scripting will be unable to benefit >>>>> from the huge mountain of resources available on the Internet. This is an >>>>> extremely severe limitation, and an unnecessary restriction in the context >>>>> of client-side viewer scripting. If I want to use a locally-installed >>>>> package X from within my client-side script, I should be able to. What runs >>>>> client-side should always be our individual choice, not someone else's. >>>>> 2. Programmers want to write client-side scripts in the language >>>>> that they know best, because that always yields the fastest progress and >>>>> highest quality results. There was a good technical reason for forcing >>>>> everyone to use LSL server-side, but there is no technical reason to impose >>>>> this requirement on all client-side scripting. It is counter-productive to >>>>> force CLR compatibility on client-side script developers when there is a >>>>> simple alternative: define a *socket-based viewer API* for >>>>> client-side scripts instead, hence usable from any language. >>>>> 3. Mono runs poorly on Linux, so from being rock-solid on Linux >>>>> now, the LL-derived viewers will become second-rate on this platform. >>>>> 4. The viewer is already extremely bloated and a memory hog. >>>>> Adding a Mono dependency will compound that horribly. >>>>> 5. There is only one effective supplier of Mono: Novell. That is >>>>> a very bad situation to encourage and to support in the viewer. >>>>> 6. Some parties identify other reasons for avoiding Mono in >>>>> general. Without getting into that subject at all, >>>>> >>>>> >>>>> The second known detail about Firefly (mandatory sandbox) is >>>>> problematic on two related fronts: >>>>> >>>>> 1. Sandboxes by design do not allow most platform resources to be >>>>> accessed, as a security measure. This is fine and important when scripts >>>>> are being downloaded from unknown places (like Javascript in web pages), but >>>>> that same protection also means that client-side scripts would be powerless >>>>> to do useful things for us in concert with local applications, files, >>>>> devices, etc. Sandboxing client-side scripts effectively hardwires in >>>>> script weakness for no reason discussed as a requirement. >>>>> 2. Sandboxed applications cannot be linked with user-chosen native >>>>> libraries since allowing native code breaks sandbox protection. This means >>>>> no accelerators, no extensions, and no interop with other systems since >>>>> sockets are inaccessible from any strong sandbox. This also means no >>>>> evolution or progress outside of what the sandbox designers permit. >>>>> >>>>> >>>>> This mailing list is concerned with development of open source viewers, >>>>> in particular Snowglobe. This is heralded as a *community* viewer, >>>>> embodying *community* requirements much more directly than the LL >>>>> mainstream viewer. Client-side scripting will impact on every single aspect >>>>> of Snowglobe bar none, yet the community is being excluded from the design >>>>> of its most powerful infrastructure element. This is entirely wrong, far >>>>> beyond the normal observation that secrecy in design has no place in open >>>>> source. >>>>> >>>>> It is hard to assess things technically when the design requirements >>>>> are formulated in secret. The Snowglobe community has design requirements >>>>> too. Those deserve to be examined here openly, not limiting Snowglobe to a >>>>> design that stems from Linden requirements alone. >>>>> >>>>> >>>>> Morgaine. >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100219/03e804e9/attachment-0001.htm From carlo at alinoe.com Fri Feb 19 05:50:03 2010 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 19 Feb 2010 14:50:03 +0100 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> Message-ID: <20100219135003.GA15879@alinoe.com> On Fri, Feb 19, 2010 at 01:30:28PM +0000, Morgaine wrote: > I would avoid your terminology though, because both kinds of script application > employ "client-side scripting", both types create dynamic "extensions", and > both types can be implemented as "plugins" --- your terms directly describe the > technologies that can be used in both types of application and don't > distinguish between the two differing requirements. It would just add to the > confusion. Plugins are inheritly unsafe and will have access to anything a normal process has. If client-side scripting is going to be provided on a plugin with the same access to the system, then it's still a plugin. Hence, I see no problem talking about "plugins" for "trusted" applications and not even mention scripting in that case (for now). Then we can reserve the word client-side-scripting for third party / downloaded scripts. -- Carlo Wood From morgaine.dinova at googlemail.com Fri Feb 19 06:41:56 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Fri, 19 Feb 2010 14:41:56 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <20100219135003.GA15879@alinoe.com> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <20100219135003.GA15879@alinoe.com> Message-ID: You can make a plugin part of the process space of its host app or a separate process, it's up to you. The "same process space" architecture is merely the simplest one, and so it's the most common, but now that we're in the age of multicore, that is changing rapidly because it is so easy to harness more cores with separate processes, and it avoids the many pitfalls of concurrent thread programming with shared state. When separate processes are used for plugins (typically communicating with the host via socket), they can be either totally disjoint or they can share one or memory segments, the term is quite generic. When we were designing the client-side scripting plugins for Imprudence, we used the separate process space architecture. LL uses the same approach in their media plugins (Plugin-API), they're external to the host viewer as well. This is going to become a very common architecture for plugins, in part because of the strong safety and security of process separation. Internal or external is really an implementation detail for plugins. Since plugin systems of both types are in common use, the term "plugin" is not useful to us when differentiating between *trusted* scripts and * untrusted* scripts. (Sandboxes can be in internal memory space or external process space too.) At this stage we're just trying to raise a discussion with Lindens about the two quite distinct requirements, trusted and untrusted, both of which are extremely important and both of which need to be supported. Discussing the process design architecture will be highly interesting and important too of course, but it's all rather academic if we can't get Lindens to even discuss the requirements. While I appreciate your earlier suggestion that Snowglobe could go independent if community needs are not met, I have not yet lost hope that Lindens will decide to work with the open source community on client-side scripting. It's only day #2 of this after all. :-) Morgaine. ======================================= On Fri, Feb 19, 2010 at 1:50 PM, Carlo Wood wrote: > On Fri, Feb 19, 2010 at 01:30:28PM +0000, Morgaine wrote: > > I would avoid your terminology though, because both kinds of script > application > > employ "client-side scripting", both types create dynamic "extensions", > and > > both types can be implemented as "plugins" --- your terms directly > describe the > > technologies that can be used in both types of application and don't > > distinguish between the two differing requirements. It would just add to > the > > confusion. > > Plugins are inheritly unsafe and will have access to anything a normal > process has. If client-side scripting is going to be provided on a plugin > with the same access to the system, then it's still a plugin. > > Hence, I see no problem talking about "plugins" for "trusted" applications > and not even mention scripting in that case (for now). > > Then we can reserve the word client-side-scripting for third party / > downloaded scripts. > > -- > Carlo Wood > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100219/1b0fbf94/attachment.htm From morgaine.dinova at googlemail.com Fri Feb 19 07:23:53 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Fri, 19 Feb 2010 15:23:53 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <1266557064.3694.4302.camel@RAGE> References: <1266557064.3694.4302.camel@RAGE> Message-ID: Indeed Rob! Lua is a brilliant language for adding scripting to existing applications --- it's designed expressly for embedding and extending, it has a clean syntax, it is linguistically very powerful, it is very tiny (the whole thing can add under 100KB to your application), it can run sandboxed or not as desired, and it is one of the fastest pure scripting languages currently available, a lot faster than say Python. It is no surprise then that game developers worldwide flocked to it in droves, and now it's one of the most common scripting languages found embedded in games. WoW fans use it daily as an intrinsic part of their WoW client, and a huge community has grown up around Lua-powered interfaces for that game. So yes, I'm with you on the importance of Lua for client-side scripting of the viewer. However, advocating Lua as the sole means of scripting viewers would be just as bad a mistake as advocating C# or CLR-targetted languages only. It would support only one part of the scripting community directly, while discriminating against everyone else. This is not necessary. Instead, defining a socket-based API interface would allow effectively any language to be used for scripting the viewer, since virtually all languages today have socket capabilities. That would certainly include Lua and C# and Python and Perl and Java and Clojure and C/C++ and ObjectiveC and Smalltalk, to name a few languages that this community uses regularly. The only thing that we would have to agree on would be the set of messages that cross the socket interface, and the set of functions and callbacks that the messages would engage in the viewer. That's the kind of productive technical discussion we could be having with Lindens, if their design process for client-side scripting were open. It needs to be. Morgaine. =========================== On Fri, Feb 19, 2010 at 5:24 AM, Rob Nelson wrote: > B-B-But what about Lua, which has already been implemented in FlexLife > (http://flexlife.nexisonline.net)? :( > > Fred Rookstown > Lead Developer > > On Thu, 2010-02-18 at 12:42 +0000, Morgaine wrote: > > I referred recently to Linden's internal project "Firefly" to add > > client-side scripting to SL viewers. This has been the topic of open > > discussion at several Office Hours with Lindens in SL, but that > > openness has not extended to many design details --- the Firefly > > design process is not open to the community. The only technical > > details that are being disclosed about Firefly appear to be: > > > > * "Scripts" are actually Mono assemblies, so that only languages > > that compile to Mono will be allowed. > > * The programs run in a sandbox, which means that most platform > > resources are not accessible to them. > > > > Please note that I quite like C# as a language, but the following > > remarks are about Mono use in the SL viewer, only, where its tradeoffs > > are poor. > > > > The first known detail about Firefly (mandatory Mono) is problematic > > on several fronts: > > 1. Only a tiny fraction of the world's applications, libraries > > and languages work on Mono, so client-side scripting will be > > unable to benefit from the huge mountain of resources > > available on the Internet. This is an extremely severe > > limitation, and an unnecessary restriction in the context of > > client-side viewer scripting. If I want to use a > > locally-installed package X from within my client-side script, > > I should be able to. What runs client-side should always be > > our individual choice, not someone else's. > > 2. Programmers want to write client-side scripts in the language > > that they know best, because that always yields the fastest > > progress and highest quality results. There was a good > > technical reason for forcing everyone to use LSL server-side, > > but there is no technical reason to impose this requirement on > > all client-side scripting. It is counter-productive to force > > CLR compatibility on client-side script developers when there > > is a simple alternative: define a socket-based viewer API for > > client-side scripts instead, hence usable from any language. > > 3. Mono runs poorly on Linux, so from being rock-solid on Linux > > now, the LL-derived viewers will become second-rate on this > > platform. > > 4. The viewer is already extremely bloated and a memory hog. > > Adding a Mono dependency will compound that horribly. > > 5. There is only one effective supplier of Mono: Novell. That > > is a very bad situation to encourage and to support in the > > viewer. > > 6. Some parties identify other reasons for avoiding Mono in > > general. Without getting into that subject at all, > > > > The second known detail about Firefly (mandatory sandbox) is > > problematic on two related fronts: > > 1. Sandboxes by design do not allow most platform resources to be > > accessed, as a security measure. This is fine and important > > when scripts are being downloaded from unknown places (like > > Javascript in web pages), but that same protection also means > > that client-side scripts would be powerless to do useful > > things for us in concert with local applications, files, > > devices, etc. Sandboxing client-side scripts effectively > > hardwires in script weakness for no reason discussed as a > > requirement. > > 2. Sandboxed applications cannot be linked with user-chosen > > native libraries since allowing native code breaks sandbox > > protection. This means no accelerators, no extensions, and no > > interop with other systems since sockets are inaccessible from > > any strong sandbox. This also means no evolution or progress > > outside of what the sandbox designers permit. > > > > This mailing list is concerned with development of open source > > viewers, in particular Snowglobe. This is heralded as a community > > viewer, embodying community requirements much more directly than the > > LL mainstream viewer. Client-side scripting will impact on every > > single aspect of Snowglobe bar none, yet the community is being > > excluded from the design of its most powerful infrastructure element. > > This is entirely wrong, far beyond the normal observation > > that secrecy in design has no place in open source. > > > > It is hard to assess things technically when the design requirements > > are formulated in secret. The Snowglobe community has design > > requirements too. Those deserve to be examined here openly, not > > limiting Snowglobe to a design that stems from Linden requirements > > alone. > > > > > > Morgaine. > > > > _______________________________________________ > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100219/e9cbe2c9/attachment-0001.htm From morgaine.dinova at googlemail.com Fri Feb 19 07:38:10 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Fri, 19 Feb 2010 15:38:10 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <1266557064.3694.4302.camel@RAGE> Message-ID: Not forgetting Erlang, Ruby, LISP, Javascript, and Bourne shell of course. :-) But here's the fun one, for some value of "fun" ... Someone would undoubtedly write an LSL binding to the socket-based API too. And however much we screw up our noses at LSL, I have no doubt that a large number of SL users who know no other language would be very happy to see it. :-) Providing a socket-based interface to the viewer would be a hugely all-embracing approach to client-side scripting, supporting everyone's needs. I think it deserves consideration. Morgaine. =================================== On Fri, Feb 19, 2010 at 3:23 PM, Morgaine wrote: > Indeed Rob! > > Lua is a brilliant language for adding scripting to existing applications > --- it's designed expressly for embedding and extending, it has a clean > syntax, it is linguistically very powerful, it is very tiny (the whole thing > can add under 100KB to your application), it can run sandboxed or not as > desired, and it is one of the fastest pure scripting languages currently > available, a lot faster than say Python. > > It is no surprise then that game developers worldwide flocked to it in > droves, and now it's one of the most common scripting languages found > embedded in games. WoW fans use it daily as an intrinsic part of their WoW > client, and a huge community has grown up around Lua-powered interfaces for > that game. > > So yes, I'm with you on the importance of Lua for client-side scripting of > the viewer. > > However, advocating Lua as the sole means of scripting viewers would be > just as bad a mistake as advocating C# or CLR-targetted languages only. It > would support only one part of the scripting community directly, while > discriminating against everyone else. This is not necessary. > > Instead, defining a socket-based API interface would allow effectively any > language to be used for scripting the viewer, since virtually all languages > today have socket capabilities. That would certainly include Lua and C# and > Python and Perl and Java and Clojure and C/C++ and ObjectiveC and Smalltalk, > to name a few languages that this community uses regularly. > > The only thing that we would have to agree on would be the set of messages > that cross the socket interface, and the set of functions and callbacks that > the messages would engage in the viewer. That's the kind of productive > technical discussion we could be having with Lindens, if their design > process for client-side scripting were open. It needs to be. > > > Morgaine. > > > > > > =========================== > > > On Fri, Feb 19, 2010 at 5:24 AM, Rob Nelson wrote: > >> B-B-But what about Lua, which has already been implemented in FlexLife >> (http://flexlife.nexisonline.net)? :( >> >> Fred Rookstown >> Lead Developer >> >> On Thu, 2010-02-18 at 12:42 +0000, Morgaine wrote: >> > I referred recently to Linden's internal project "Firefly" to add >> > client-side scripting to SL viewers. This has been the topic of open >> > discussion at several Office Hours with Lindens in SL, but that >> > openness has not extended to many design details --- the Firefly >> > design process is not open to the community. The only technical >> > details that are being disclosed about Firefly appear to be: >> > >> > * "Scripts" are actually Mono assemblies, so that only languages >> > that compile to Mono will be allowed. >> > * The programs run in a sandbox, which means that most platform >> > resources are not accessible to them. >> > >> > Please note that I quite like C# as a language, but the following >> > remarks are about Mono use in the SL viewer, only, where its tradeoffs >> > are poor. >> > >> > The first known detail about Firefly (mandatory Mono) is problematic >> > on several fronts: >> > 1. Only a tiny fraction of the world's applications, libraries >> > and languages work on Mono, so client-side scripting will be >> > unable to benefit from the huge mountain of resources >> > available on the Internet. This is an extremely severe >> > limitation, and an unnecessary restriction in the context of >> > client-side viewer scripting. If I want to use a >> > locally-installed package X from within my client-side script, >> > I should be able to. What runs client-side should always be >> > our individual choice, not someone else's. >> > 2. Programmers want to write client-side scripts in the language >> > that they know best, because that always yields the fastest >> > progress and highest quality results. There was a good >> > technical reason for forcing everyone to use LSL server-side, >> > but there is no technical reason to impose this requirement on >> > all client-side scripting. It is counter-productive to force >> > CLR compatibility on client-side script developers when there >> > is a simple alternative: define a socket-based viewer API for >> > client-side scripts instead, hence usable from any language. >> > 3. Mono runs poorly on Linux, so from being rock-solid on Linux >> > now, the LL-derived viewers will become second-rate on this >> > platform. >> > 4. The viewer is already extremely bloated and a memory hog. >> > Adding a Mono dependency will compound that horribly. >> > 5. There is only one effective supplier of Mono: Novell. That >> > is a very bad situation to encourage and to support in the >> > viewer. >> > 6. Some parties identify other reasons for avoiding Mono in >> > general. Without getting into that subject at all, >> > >> > The second known detail about Firefly (mandatory sandbox) is >> > problematic on two related fronts: >> > 1. Sandboxes by design do not allow most platform resources to be >> > accessed, as a security measure. This is fine and important >> > when scripts are being downloaded from unknown places (like >> > Javascript in web pages), but that same protection also means >> > that client-side scripts would be powerless to do useful >> > things for us in concert with local applications, files, >> > devices, etc. Sandboxing client-side scripts effectively >> > hardwires in script weakness for no reason discussed as a >> > requirement. >> > 2. Sandboxed applications cannot be linked with user-chosen >> > native libraries since allowing native code breaks sandbox >> > protection. This means no accelerators, no extensions, and no >> > interop with other systems since sockets are inaccessible from >> > any strong sandbox. This also means no evolution or progress >> > outside of what the sandbox designers permit. >> > >> > This mailing list is concerned with development of open source >> > viewers, in particular Snowglobe. This is heralded as a community >> > viewer, embodying community requirements much more directly than the >> > LL mainstream viewer. Client-side scripting will impact on every >> > single aspect of Snowglobe bar none, yet the community is being >> > excluded from the design of its most powerful infrastructure element. >> > This is entirely wrong, far beyond the normal observation >> > that secrecy in design has no place in open source. >> > >> > It is hard to assess things technically when the design requirements >> > are formulated in secret. The Snowglobe community has design >> > requirements too. Those deserve to be examined here openly, not >> > limiting Snowglobe to a design that stems from Linden requirements >> > alone. >> > >> > >> > Morgaine. >> > >> > _______________________________________________ >> > 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 >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100219/8a530a71/attachment.htm From kow at sapinski.com Fri Feb 19 07:47:51 2010 From: kow at sapinski.com (k\o\w) Date: Fri, 19 Feb 2010 10:47:51 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <1266557064.3694.4302.camel@RAGE> Message-ID: <4B7EB2A7.3070108@sapinski.com> RLVa, supports something like this, and can be found in most 3rd party viewers: http://rlva.catznip.com/blog/ http://wiki.secondlife.com/wiki/RestrainedLifeAPI On 2/19/2010 10:38 AM, Morgaine wrote: > Not forgetting Erlang, Ruby, LISP, Javascript, and Bourne shell of > course. :-) > > But here's the fun one, for some value of "fun" ... Someone would > undoubtedly write an LSL binding to the socket-based API too. And > however much we screw up our noses at LSL, I have no doubt that a > large number of SL users who know no other language would be very > happy to see it. :-) > > Providing a socket-based interface to the viewer would be a hugely > all-embracing approach to client-side scripting, supporting everyone's > needs. I think it deserves consideration. > > > Morgaine. > > > > > =================================== > > On Fri, Feb 19, 2010 at 3:23 PM, Morgaine > > wrote: > > Indeed Rob! > > Lua is a brilliant language for adding scripting to existing > applications --- it's designed expressly for embedding and > extending, it has a clean syntax, it is linguistically very > powerful, it is very tiny (the whole thing can add under 100KB to > your application), it can run sandboxed or not as desired, and it > is one of the fastest pure scripting languages currently > available, a lot faster than say Python. > > It is no surprise then that game developers worldwide flocked to > it in droves, and now it's one of the most common scripting > languages found embedded in games. WoW fans use it daily as an > intrinsic part of their WoW client, and a huge community has grown > up around Lua-powered interfaces for that game. > > So yes, I'm with you on the importance of Lua for client-side > scripting of the viewer. > > However, advocating Lua as the sole means of scripting viewers > would be just as bad a mistake as advocating C# or CLR-targetted > languages only. It would support only one part of the scripting > community directly, while discriminating against everyone else. > This is not necessary. > > Instead, defining a socket-based API interface would allow > effectively any language to be used for scripting the viewer, > since virtually all languages today have socket capabilities. > That would certainly include Lua and C# and Python and Perl and > Java and Clojure and C/C++ and ObjectiveC and Smalltalk, to name a > few languages that this community uses regularly. > > The only thing that we would have to agree on would be the set of > messages that cross the socket interface, and the set of functions > and callbacks that the messages would engage in the viewer. > That's the kind of productive technical discussion we could be > having with Lindens, if their design process for client-side > scripting were open. It needs to be. > > > Morgaine. > > > > > > =========================== > > > On Fri, Feb 19, 2010 at 5:24 AM, Rob Nelson > > wrote: > > B-B-But what about Lua, which has already been implemented in > FlexLife > (http://flexlife.nexisonline.net)? :( > > Fred Rookstown > Lead Developer > > On Thu, 2010-02-18 at 12:42 +0000, Morgaine wrote: > > I referred recently to Linden's internal project "Firefly" > to add > > client-side scripting to SL viewers. This has been the > topic of open > > discussion at several Office Hours with Lindens in SL, but that > > openness has not extended to many design details --- the Firefly > > design process is not open to the community. The only technical > > details that are being disclosed about Firefly appear to be: > > > > * "Scripts" are actually Mono assemblies, so that only > languages > > that compile to Mono will be allowed. > > * The programs run in a sandbox, which means that most > platform > > resources are not accessible to them. > > > > Please note that I quite like C# as a language, but the > following > > remarks are about Mono use in the SL viewer, only, where its > tradeoffs > > are poor. > > > > The first known detail about Firefly (mandatory Mono) is > problematic > > on several fronts: > > 1. Only a tiny fraction of the world's applications, > libraries > > and languages work on Mono, so client-side scripting > will be > > unable to benefit from the huge mountain of resources > > available on the Internet. This is an extremely severe > > limitation, and an unnecessary restriction in the > context of > > client-side viewer scripting. If I want to use a > > locally-installed package X from within my > client-side script, > > I should be able to. What runs client-side should > always be > > our individual choice, not someone else's. > > 2. Programmers want to write client-side scripts in the > language > > that they know best, because that always yields the > fastest > > progress and highest quality results. There was a good > > technical reason for forcing everyone to use LSL > server-side, > > but there is no technical reason to impose this > requirement on > > all client-side scripting. It is counter-productive > to force > > CLR compatibility on client-side script developers > when there > > is a simple alternative: define a socket-based > viewer API for > > client-side scripts instead, hence usable from any > language. > > 3. Mono runs poorly on Linux, so from being rock-solid > on Linux > > now, the LL-derived viewers will become second-rate > on this > > platform. > > 4. The viewer is already extremely bloated and a memory > hog. > > Adding a Mono dependency will compound that horribly. > > 5. There is only one effective supplier of Mono: > Novell. That > > is a very bad situation to encourage and to support > in the > > viewer. > > 6. Some parties identify other reasons for avoiding Mono in > > general. Without getting into that subject at all, > > > > The second known detail about Firefly (mandatory sandbox) is > > problematic on two related fronts: > > 1. Sandboxes by design do not allow most platform > resources to be > > accessed, as a security measure. This is fine and > important > > when scripts are being downloaded from unknown > places (like > > Javascript in web pages), but that same protection > also means > > that client-side scripts would be powerless to do useful > > things for us in concert with local applications, files, > > devices, etc. Sandboxing client-side scripts > effectively > > hardwires in script weakness for no reason discussed > as a > > requirement. > > 2. Sandboxed applications cannot be linked with user-chosen > > native libraries since allowing native code breaks > sandbox > > protection. This means no accelerators, no > extensions, and no > > interop with other systems since sockets are > inaccessible from > > any strong sandbox. This also means no evolution or > progress > > outside of what the sandbox designers permit. > > > > This mailing list is concerned with development of open source > > viewers, in particular Snowglobe. This is heralded as a > community > > viewer, embodying community requirements much more directly > than the > > LL mainstream viewer. Client-side scripting will impact on > every > > single aspect of Snowglobe bar none, yet the community is being > > excluded from the design of its most powerful infrastructure > element. > > This is entirely wrong, far beyond the normal observation > > that secrecy in design has no place in open source. > > > > It is hard to assess things technically when the design > requirements > > are formulated in secret. The Snowglobe community has design > > requirements too. Those deserve to be examined here openly, not > > limiting Snowglobe to a design that stems from Linden > requirements > > alone. > > > > > > Morgaine. > > > > _______________________________________________ > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100219/588df2cc/attachment-0001.htm From ronfesta at docs.rutgers.edu Fri Feb 19 10:31:01 2010 From: ronfesta at docs.rutgers.edu (Ron Festa) Date: Fri, 19 Feb 2010 13:31:01 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <4B7EB2A7.3070108@sapinski.com> References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> Message-ID: <3c59673d1002191031v3b754473k28f1e51281d60e41@mail.gmail.com> To be honest the arguments I've been seeing about not using MONO seem to be forgetting something. There are multiple languages that can be compiled/interpreted in MONO with the appropriate addon, not just C#. Just to name a few we have Python, Boo (which resembles Python and seems to come with MONO now), Lua, Java, JavaScript, VisualBasic.NET, Pascal, PHP, and with the work LL has done to the server we now have LSL. With MONO you have options both in the language choice and what OS it can run on. The generated code (whether compiled or interpreted) should be compatible with LL's server sided script engine and should be compatible with OpenSIM. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100219/415815c7/attachment.htm From lenglish5 at cox.net Fri Feb 19 10:40:43 2010 From: lenglish5 at cox.net (Lawson English) Date: Fri, 19 Feb 2010 11:40:43 -0700 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <3c59673d1002191031v3b754473k28f1e51281d60e41@mail.gmail.com> References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> <3c59673d1002191031v3b754473k28f1e51281d60e41@mail.gmail.com> Message-ID: <4B7EDB2B.4010009@cox.net> Ron Festa wrote: > To be honest the arguments I've been seeing about not using MONO seem > to be forgetting something. There are multiple languages that can be > compiled/interpreted in MONO with the appropriate addon, not just C#. > Just to name a few we have Python, Boo (which resembles Python and > seems to come with MONO now), Lua, Java, JavaScript, VisualBasic.NET, > Pascal, PHP, and with the work LL has done to the server we now have > LSL. With MONO you have options both in the language choice and what > OS it can run on. The generated code (whether compiled or interpreted) > should be compatible with LL's server sided script engine and should > be compatible with OpenSIM. > There's more to a language then just the syntax. CLR-based Smalltalk is NOT real smalltalk, for example. There's no way except perhaps via F# to get something approaching smalltalk programming out of a CLR-based system. Lawson From robin.cornelius at gmail.com Fri Feb 19 10:53:14 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri, 19 Feb 2010 18:53:14 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <4B7EDB2B.4010009@cox.net> References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> <3c59673d1002191031v3b754473k28f1e51281d60e41@mail.gmail.com> <4B7EDB2B.4010009@cox.net> Message-ID: On Fri, Feb 19, 2010 at 6:40 PM, Lawson English wrote: >> > There's more to a language then just the syntax. CLR-based Smalltalk is > NOT real smalltalk, for example. > > There's no way except perhaps via F# to get something approaching > smalltalk programming out of a CLR-based system. > Well Morgaine's socket based idea could over come this very easily. If the API was exposed via a socket, LL could provide a plugin loader much as they do for the MediaAPI now, if they want, this pluginloader could be CLR based and the default LL implementation of plugins could be mono assemblies. So the plugin loader could be directly used by any language that can produce CLR binaries. If someone else comes along who does not use CLR, they could just directly use the socket API with what ever lanuaguage they wanted either directly, or via another plugin loader, but importantly, in their lanugage of choice. Sandboxing could easily be provided by the default LL pluginloader so that out of the box implementation provides a save environment for any downloaded scripts. But someone else who wants to call native functions can from, again, any thing they like if it supports sockets. I think something along these lines could provide something close to maximum flexibilty. Regards Robin From lenglish5 at cox.net Fri Feb 19 11:07:35 2010 From: lenglish5 at cox.net (Lawson English) Date: Fri, 19 Feb 2010 12:07:35 -0700 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> <3c59673d1002191031v3b754473k28f1e51281d60e41@mail.gmail.com> <4B7EDB2B.4010009@cox.net> Message-ID: <4B7EE177.50707@cox.net> Robin Cornelius wrote: > On Fri, Feb 19, 2010 at 6:40 PM, Lawson English wrote: > >> There's more to a language then just the syntax. CLR-based Smalltalk is >> NOT real smalltalk, for example. >> >> There's no way except perhaps via F# to get something approaching >> smalltalk programming out of a CLR-based system. >> >> > > Well Morgaine's socket based idea could over come this very easily. If > the API was exposed via a socket, LL could provide a plugin loader > much as they do for the MediaAPI now, if they want, this pluginloader > could be CLR based and the default LL implementation of plugins could > be mono assemblies. So the plugin loader could be directly used by any > language that can produce CLR binaries. > > If someone else comes along who does not use CLR, they could just > directly use the socket API with what ever lanuaguage they wanted > either directly, or via another plugin loader, but importantly, in > their lanugage of choice. > > Sandboxing could easily be provided by the default LL pluginloader so > that out of the box implementation provides a save environment for any > downloaded scripts. But someone else who wants to call native > functions can from, again, any thing they like if it supports sockets. > > I think something along these lines could provide something close to > maximum flexibilty. > > Regards > > Robin > _______________________________________________ > Sure. ANd in that case, I have no real objections. There's durned little difference between having a command parser written in C#, C++, or whatever and if one can use CLR scripts directly but still be able to evoke the internals of the system via a socket interface, that's fine. Personally, if I ever wrote a Mac-only client, I'd use fscript as the internal scripting language because that is far, FAR slicker than anything CLR-based, but I'm a Mac fanboi. Lawson From maggie at matrisync.com Fri Feb 19 11:29:16 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Fri, 19 Feb 2010 14:29:16 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <4B7EE177.50707@cox.net> References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> <3c59673d1002191031v3b754473k28f1e51281d60e41@mail.gmail.com> <4B7EDB2B.4010009@cox.net> <4B7EE177.50707@cox.net> Message-ID: The socket-based approach has the advantages of being OS-platform-neutral, which CLR is not. A JVM-based scripting system leveraging JSR-223 tech would be more platform-neutral, but is certainly not what anybody could call "lightweight". But either of those approaches (as well as others) could be implemented up against Morgaine's suggestion, and scriptwriters could choose what dependencies they cared to embrace. I seem to recall not long ago Philip had a project to implement camera-based facial expression recognition whose design included a socket based viewer interface. (Of course, any client-side scripting will face an outcry from certain well-known users who rail against making inherent capabilities of the viewer/server system easier to access or automate as an "invasion of privacy".) I think asking the question "what would you *do* with scripting in the client?" is premature until you identify what client functionality you can or should expose to scripting. This is an issue I'm currently wrestling with in working with Project Wonderland ( http://www.projectwonderland.com ), where the scripting architectures (doesn't have to be restricted to only one implementation) are still essentially greenfields and the underlying architecture is capable of operating both on client and server-side objects. From edward.artaud at gmail.com Fri Feb 19 11:49:10 2010 From: edward.artaud at gmail.com (Edward Artaud) Date: Fri, 19 Feb 2010 11:49:10 -0800 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> Message-ID: Smartest point made on the topic, and it really makes sense to stop conflating the two, there are distinct untrusted script and trusted plug-in problems. For client-side scripts to be something worth prioritizing implementing in mainstream viewers, their usage must be based on the assumption that some large percentage (80+% maybe) of attachment scripts, for example, would be running client-side, and possibly even allowing in-world objects to specify that specific scripts as meant to run viewer-side as well. The analogy would be that of web browsers, most of which have javascript enabled by default and any single browser user is downloading and running *thousands* of scripts over the course of a day with no awareness or explicit permission given. Getting a similar system to work in the viewer is a big problem in and of itself to solve, and the one that would have the most direct impact in the in-world experience of the most users in the shortest period of time. Plug-ins would be great, but then we get into the questions of the whole process of how installation works, is there an auto-installer ala IE or some form of manual mechanism that will be prone to user error. If there isn't a way that a very large number of users would have easy access to trusted plug-ins, it's hard to imagine it would be a highly prioritized feature. On Thu, Feb 18, 2010 at 11:16 PM, Ricky wrote: > I suspect that there are two things being discussed here without > distinction: Client scripting, and client extensions. ?Confusing the two is > easy. > Client-side scripting SHOULD be sandboxed, and in a controlled set of > languages. ?For a close example think of javascript in web browsers. > Client extensions, or alternatively named as "plugins", would be modules > that can be plugged in and out of the client and run /as if/ they were a > part of the client. ?Think of browser add-ons/plugins/extensions. > Client side scripts could (read might be, could possibly, needs further > thought, etc.) be given permission to be loaded in by worn items > automatically. ?Other objects would likely need to request permission via a > security warning. > Client extensions would have to be downloaded and installed externally; not > delivered in-world. ?These would truly be programs on your computer, and > should be treated as such. > Just my thoughts hoping for a clearer discussion. > Ricky > Cron Stardust From maggie at matrisync.com Fri Feb 19 11:54:42 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Fri, 19 Feb 2010 14:54:42 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> Message-ID: On Fri, Feb 19, 2010 at 2:49 PM, Edward Artaud wrote: > ?For client-side scripts to be something worth > prioritizing implementing in mainstream viewers, their usage must be > based on the assumption that some large percentage (80+% maybe) of > attachment scripts, for example, would be running client-side... Uh...I didn't really see viewer-side scripting as something that would make any significant dent in what's done today with scripted objects serverside except in the case of some HUD objects. I was thinking of this as new function, and only incidentally providing some marginal performance relief for LLs servers in limited cases...such as how Emerald's avatar radar reduces or eliminates avatar radar HUDs. Love to hear other views on this... From morgaine.dinova at googlemail.com Fri Feb 19 12:05:33 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Fri, 19 Feb 2010 20:05:33 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <4B7EB2A7.3070108@sapinski.com> References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> Message-ID: RLVa is a very notable user-defined API that has far transcended its original purpose, and is now in extensive use wherever enhancements for accessibility are required. It really highlights how user-defined functionality should have been in the viewer from the beginning. Client-side scripting will undoubtedly take accessibility to the next level, and I would fully expect RLV itself to become a common binding for many client-side scripting languages. Accessibility provides many good examples to illustrate how client-side scripting would work over a socket-based API in the viewer. Let's look at a simple example that is of huge interest and benefit not only to the visually impaired but to anyone who doesn't particularly enjoy reading scrolling text: ----------------------------- SIMPLE TALKER SCRIPT 1) The user either executes the talker script manually (just like any conventional program), or else the script launches automatically on viewer startup, or else the script is launched from the viewer's script manager if there is one. If there are special accessibility issues to consider, this step can be complicated, and tailored to the individual needs of the user. 2) The script immediately connects to a predefined port on the same machine as the viewer, on which the viewer is listening for incoming script connections. The viewer's connection listener accepts the connection and sets up the appropriate TCP channel and messaging command interface for communicating with the script. 3) The script sends the viewer a message to register a callback for the NewCommunicateTabOpened event, in order to be notified of new channels of communication appearing in the viewer. 4) The viewer registers the callback for this script. (Note that any number of attached scripts could register interest in the same callback.) 5) Someone starts a personal IM to this user or sends an IM to one of the user's groups, and a new Communications tab pops up in the viewer. Since the script has registered for the corresponding event, a message of the appropriate type and naming the channel that has just appeared is sent by the viewer to the script through the socket. 6) The script responds to the incoming event, and sends back a message to register a callback for the ChatMessageReceived event, parametrized with N, the number of old chat messages desired (1, if only the message that opened the chat tab is wanted). 7) The viewer registers the callback and sends the requested N chat lines, one per message of the appropriate type, parametrized with the channel identifier and carrying the chat line as payload. The types could be different for personal and group IM, vicinity chat, system messages, etc. 8) The script receives each incoming chat event message and sends it to the local text-to-speech program on the user's machine, which could be a commercial package or an open source one such as Festival. Note that the script could apply transformations to each line to increase listenability, including assigning gender or tiny voices as desired, or filtering out undesired types of message such as graphic spam. 9) When no more chat talking is desired, the script can simply be killed. The viewer will note the TCP socket closing and will remove all registered callbacks for this script and tidy up appropriately. END ----- It is very important to note that client-side scripts written for accessibility purposes are very often interfaces to local resources or applications, and cannot be sandboxed, since those resources or applications would not be accessible from within a strong-walled sandbox. This is why a sandboxed CLR environment is not enough for a generic client-side scripting system --- it doesn't meet a very large set of crucial use cases. Both sandboxed and not sandboxed script environments are required, to cater for untrusted and trusted scripts respectively. Morgaine. =========================================== On Fri, Feb 19, 2010 at 3:47 PM, k\o\w wrote: > RLVa, supports something like this, and can be found in most 3rd party > viewers: > http://rlva.catznip.com/blog/ > http://wiki.secondlife.com/wiki/RestrainedLifeAPI > > > On 2/19/2010 10:38 AM, Morgaine wrote: > > Not forgetting Erlang, Ruby, LISP, Javascript, and Bourne shell of course. > :-) > > But here's the fun one, for some value of "fun" ... Someone would > undoubtedly write an LSL binding to the socket-based API too. And however > much we screw up our noses at LSL, I have no doubt that a large number of SL > users who know no other language would be very happy to see it. :-) > > Providing a socket-based interface to the viewer would be a hugely > all-embracing approach to client-side scripting, supporting everyone's > needs. I think it deserves consideration. > > > Morgaine. > > > > > =================================== > > On Fri, Feb 19, 2010 at 3:23 PM, Morgaine wrote: > >> Indeed Rob! >> >> Lua is a brilliant language for adding scripting to existing applications >> --- it's designed expressly for embedding and extending, it has a clean >> syntax, it is linguistically very powerful, it is very tiny (the whole thing >> can add under 100KB to your application), it can run sandboxed or not as >> desired, and it is one of the fastest pure scripting languages currently >> available, a lot faster than say Python. >> >> It is no surprise then that game developers worldwide flocked to it in >> droves, and now it's one of the most common scripting languages found >> embedded in games. WoW fans use it daily as an intrinsic part of their WoW >> client, and a huge community has grown up around Lua-powered interfaces for >> that game. >> >> So yes, I'm with you on the importance of Lua for client-side scripting of >> the viewer. >> >> However, advocating Lua as the sole means of scripting viewers would be >> just as bad a mistake as advocating C# or CLR-targetted languages only. It >> would support only one part of the scripting community directly, while >> discriminating against everyone else. This is not necessary. >> >> Instead, defining a socket-based API interface would allow effectively any >> language to be used for scripting the viewer, since virtually all languages >> today have socket capabilities. That would certainly include Lua and C# and >> Python and Perl and Java and Clojure and C/C++ and ObjectiveC and Smalltalk, >> to name a few languages that this community uses regularly. >> >> The only thing that we would have to agree on would be the set of messages >> that cross the socket interface, and the set of functions and callbacks that >> the messages would engage in the viewer. That's the kind of productive >> technical discussion we could be having with Lindens, if their design >> process for client-side scripting were open. It needs to be. >> >> >> Morgaine. >> >> >> >> >> >> =========================== >> >> >> On Fri, Feb 19, 2010 at 5:24 AM, Rob Nelson > > wrote: >> >>> B-B-But what about Lua, which has already been implemented in FlexLife >>> (http://flexlife.nexisonline.net)? :( >>> >>> Fred Rookstown >>> Lead Developer >>> >>> On Thu, 2010-02-18 at 12:42 +0000, Morgaine wrote: >>> > I referred recently to Linden's internal project "Firefly" to add >>> > client-side scripting to SL viewers. This has been the topic of open >>> > discussion at several Office Hours with Lindens in SL, but that >>> > openness has not extended to many design details --- the Firefly >>> > design process is not open to the community. The only technical >>> > details that are being disclosed about Firefly appear to be: >>> > >>> > * "Scripts" are actually Mono assemblies, so that only languages >>> > that compile to Mono will be allowed. >>> > * The programs run in a sandbox, which means that most platform >>> > resources are not accessible to them. >>> > >>> > Please note that I quite like C# as a language, but the following >>> > remarks are about Mono use in the SL viewer, only, where its tradeoffs >>> > are poor. >>> > >>> > The first known detail about Firefly (mandatory Mono) is problematic >>> > on several fronts: >>> > 1. Only a tiny fraction of the world's applications, libraries >>> > and languages work on Mono, so client-side scripting will be >>> > unable to benefit from the huge mountain of resources >>> > available on the Internet. This is an extremely severe >>> > limitation, and an unnecessary restriction in the context of >>> > client-side viewer scripting. If I want to use a >>> > locally-installed package X from within my client-side script, >>> > I should be able to. What runs client-side should always be >>> > our individual choice, not someone else's. >>> > 2. Programmers want to write client-side scripts in the language >>> > that they know best, because that always yields the fastest >>> > progress and highest quality results. There was a good >>> > technical reason for forcing everyone to use LSL server-side, >>> > but there is no technical reason to impose this requirement on >>> > all client-side scripting. It is counter-productive to force >>> > CLR compatibility on client-side script developers when there >>> > is a simple alternative: define a socket-based viewer API for >>> > client-side scripts instead, hence usable from any language. >>> > 3. Mono runs poorly on Linux, so from being rock-solid on Linux >>> > now, the LL-derived viewers will become second-rate on this >>> > platform. >>> > 4. The viewer is already extremely bloated and a memory hog. >>> > Adding a Mono dependency will compound that horribly. >>> > 5. There is only one effective supplier of Mono: Novell. That >>> > is a very bad situation to encourage and to support in the >>> > viewer. >>> > 6. Some parties identify other reasons for avoiding Mono in >>> > general. Without getting into that subject at all, >>> > >>> > The second known detail about Firefly (mandatory sandbox) is >>> > problematic on two related fronts: >>> > 1. Sandboxes by design do not allow most platform resources to be >>> > accessed, as a security measure. This is fine and important >>> > when scripts are being downloaded from unknown places (like >>> > Javascript in web pages), but that same protection also means >>> > that client-side scripts would be powerless to do useful >>> > things for us in concert with local applications, files, >>> > devices, etc. Sandboxing client-side scripts effectively >>> > hardwires in script weakness for no reason discussed as a >>> > requirement. >>> > 2. Sandboxed applications cannot be linked with user-chosen >>> > native libraries since allowing native code breaks sandbox >>> > protection. This means no accelerators, no extensions, and no >>> > interop with other systems since sockets are inaccessible from >>> > any strong sandbox. This also means no evolution or progress >>> > outside of what the sandbox designers permit. >>> > >>> > This mailing list is concerned with development of open source >>> > viewers, in particular Snowglobe. This is heralded as a community >>> > viewer, embodying community requirements much more directly than the >>> > LL mainstream viewer. Client-side scripting will impact on every >>> > single aspect of Snowglobe bar none, yet the community is being >>> > excluded from the design of its most powerful infrastructure element. >>> > This is entirely wrong, far beyond the normal observation >>> > that secrecy in design has no place in open source. >>> > >>> > It is hard to assess things technically when the design requirements >>> > are formulated in secret. The Snowglobe community has design >>> > requirements too. Those deserve to be examined here openly, not >>> > limiting Snowglobe to a design that stems from Linden requirements >>> > alone. >>> > >>> > >>> > Morgaine. >>> > >>> > _______________________________________________ >>> > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100219/826fa497/attachment-0001.htm From domino at dominodesigns.info Fri Feb 19 12:08:23 2010 From: domino at dominodesigns.info (Domino Marama) Date: Fri, 19 Feb 2010 20:08:23 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> Message-ID: <1266610103.4589.11.camel@domino-laptop> On Fri, 2010-02-19 at 14:54 -0500, Maggie Leber (sl: Maggie Darwin) wrote: > I was thinking of this as new function, and only incidentally > providing some marginal performance relief for LLs servers in limited > cases...such as how Emerald's avatar radar reduces or eliminates > avatar radar HUDs. > > Love to hear other views on this... I'd hope things like attachment sizing scripts would move to client side scripts. There's also things like advanced vehicle scripts, I wrote an engine script that did an approximate handling of torque and grip. It was fairly math intensive and I never implemented it fully as I judged the sim load to be too great. If I can move that client side and just send it's output to the server side physics script driving the vehicle, then not only does it become a feasible approach, it'd possibly be lighter on the sim than some current vehicle scripts. From sllists at boroon.dasgupta.ch Fri Feb 19 12:13:30 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 19 Feb 2010 21:13:30 +0100 Subject: [opensource-dev] Community created interfaces already in use (was: Client-side scripting in Snowglobe) In-Reply-To: References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> Message-ID: <4B7EF0EA.9060501@boroon.dasgupta.ch> I guess https://jira.secondlife.com/browse/SNOW-375 is using a similar protocol. cheers Boroondas From maggie at matrisync.com Fri Feb 19 12:57:40 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Fri, 19 Feb 2010 15:57:40 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <1266610103.4589.11.camel@domino-laptop> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <1266610103.4589.11.camel@domino-laptop> Message-ID: On Fri, Feb 19, 2010 at 3:08 PM, Domino Marama wrote: > I'd hope things like attachment sizing scripts would move to client side > scripts. I guess that would be nice, but the data that would have to flow to the attached hair prims would be substantial....and the prims would still have to be scripted. I wouldn't expect to see much savings from that. > There's also things like advanced vehicle scripts, I wrote an engine > script that did an approximate handling of torque and grip. It was > fairly math intensive and I never implemented it fully as I judged the > sim load to be too great. If I can move that client side and just send > it's output to the server side physics script driving the vehicle, then > not only does it become a feasible approach, it'd possibly be lighter on > the sim than some current vehicle scripts. Might just want to use a SpaceNavigator for that. From domino at dominodesigns.info Fri Feb 19 13:35:52 2010 From: domino at dominodesigns.info (Domino Marama) Date: Fri, 19 Feb 2010 21:35:52 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <1266610103.4589.11.camel@domino-laptop> Message-ID: <1266615352.4589.36.camel@domino-laptop> On Fri, 2010-02-19 at 15:57 -0500, Maggie Leber (sl: Maggie Darwin) wrote: > On Fri, Feb 19, 2010 at 3:08 PM, Domino Marama > wrote: > > > I'd hope things like attachment sizing scripts would move to client side > > scripts. > > I guess that would be nice, but the data that would have to flow to > the attached hair prims would be substantial....and the prims would > still have to be scripted. I wouldn't expect to see much savings from > that. Depends on implementation. I'm assuming client side scripts won't need transferring sim to sim on teleports, so scripts such as these that don't need to be active on the sim seem like good candidates to me. If anything I'd have thought the data flow with the vehicle scripts would be more of an issue as that'd be constant messaging between the client and server parts. It would need careful testing to make sure that moving the maths client side was more efficient. Even without my crazy ideas on doing torque based acceleration curves, it's likely that people will overdo messaging (if it's a feature) with stuff like client hud speedos for vehicles.. From lenglish5 at cox.net Fri Feb 19 14:29:16 2010 From: lenglish5 at cox.net (Lawson English) Date: Fri, 19 Feb 2010 15:29:16 -0700 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> Message-ID: <4B7F10BC.2020104@cox.net> Maggie Leber (sl: Maggie Darwin) wrote: > On Fri, Feb 19, 2010 at 2:49 PM, Edward Artaud wrote: > >> For client-side scripts to be something worth >> prioritizing implementing in mainstream viewers, their usage must be >> based on the assumption that some large percentage (80+% maybe) of >> attachment scripts, for example, would be running client-side... >> > > Uh...I didn't really see viewer-side scripting as something that would > make any significant dent in what's done today with scripted objects > serverside except in the case of some HUD objects. > > I was thinking of this as new function, and only incidentally > providing some marginal performance relief for LLs servers in limited > cases...such as how Emerald's avatar radar reduces or eliminates > avatar radar HUDs. > > Love to hear other views on this... > Depends on what is being done with it of course. a squeak interface (say) tied to the socket/shared memory connection could prototype just about any kind of extension/facility (as long as it used already existing events). Suppose, for example, there was a way to use the media plugin's shared memory as a sculpty map rather than simply as a texture to be painted on a prim. One could manipulate the vertices of the sculpy via a plugin and have the changes show up in the client without putting extra strain on the sim. The state might be shared via p2p connections between clients' plugins, or collaborative clients could share state 2 ways via a server (or p2p), while an audience could subscribe to a one-way connection of some kind, or the animation could be cached in a distributed file, or it might not be shared at all if someone were working on a test of a new animation and wanted to see what it would look like in-world before distribution. One could have high-end content creation tools hooked into the client this way and manipulate anything from a prim or texture all the way to the full scenegraph. physics could be modded the same way. Likewise with custom scriptable objects. This is basically a hybridization of the croquet/cobalt strategy for virtual worlds and the VWRAP strategy so anything you could do with either should be possible this way. Lawson From morgaine.dinova at googlemail.com Fri Feb 19 14:49:00 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Fri, 19 Feb 2010 22:49:00 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <1266615352.4589.36.camel@domino-laptop> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <1266610103.4589.11.camel@domino-laptop> <1266615352.4589.36.camel@domino-laptop> Message-ID: The client-side scripts that we are talking about in this thread are not related to in-world LSL scripts in any way. They always execute client-side, isolated in their respective processes, and they only talk directly to the client and sometimes also to local PC resources, such as the text-to-speech example I described earlier. Of course, if one of the viewer's script API functions provides communication with the world, then indirectly the client-side script would be able to interact with the world too, but that is indirect, by invoking a viewer API function through a message. It is entirely up to the viewer to define which messages are accepted from a script and which API functions are invoked by that message. Because scripts can interact with the viewer only through the messaging interface, they cannot do anything to the viewer or to the world that the viewer does not permit. Nothing would happen to a client-side script directly when you change regions. However, the script could receive LeavingRegion and EnteringRegion events from the viewer if it registered its interest in callbacks for them. Also, a script could register interest in CurrentPosition events, which the viewer would send to the script periodically with a requested time interval, or maybe with a requested spatial resolution granularity. TRAVEL LOGGER Add the region callbacks and position callbacks together and you have the basis for a very simple *travel logger* script, logging your travels to your local machine. This could even play back its voyage and send you around the world revisiting old places again. That's another nice use case for client-side scripting, and very simple to do. Morgaine. ====================================== On Fri, Feb 19, 2010 at 9:35 PM, Domino Marama wrote: > On Fri, 2010-02-19 at 15:57 -0500, Maggie Leber (sl: Maggie Darwin) > wrote: > > On Fri, Feb 19, 2010 at 3:08 PM, Domino Marama > > wrote: > > > > > I'd hope things like attachment sizing scripts would move to client > side > > > scripts. > > > > I guess that would be nice, but the data that would have to flow to > > the attached hair prims would be substantial....and the prims would > > still have to be scripted. I wouldn't expect to see much savings from > > that. > > Depends on implementation. I'm assuming client side scripts won't need > transferring sim to sim on teleports, so scripts such as these that > don't need to be active on the sim seem like good candidates to me. > > If anything I'd have thought the data flow with the vehicle scripts > would be more of an issue as that'd be constant messaging between the > client and server parts. It would need careful testing to make sure that > moving the maths client side was more efficient. Even without my crazy > ideas on doing torque based acceleration curves, it's likely that people > will overdo messaging (if it's a feature) with stuff like client hud > speedos for vehicles.. > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100219/87a00d3b/attachment.htm From edward.artaud at gmail.com Fri Feb 19 14:50:13 2010 From: edward.artaud at gmail.com (Edward Artaud) Date: Fri, 19 Feb 2010 14:50:13 -0800 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <4B7F10BC.2020104@cox.net> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <4B7F10BC.2020104@cox.net> Message-ID: I'm certainly not against a general API for trusted plug-ins (certainly all my emails to this list have been plug-in related), and it would be awesome for tools to be built without everyone having to create a viewer fork. My assumption, however, is that client-side script capability is meant to go hand in hand with the server-side script memory limits, where if the script developer marks the script as "run on client", they're able to run without the same memory limits as running on the server. If the client-side scripting project isn't part of the same initiative as the server-side script memory restrictions, it certainly should be, since one is the elegant solution to the other. On Fri, Feb 19, 2010 at 2:29 PM, Lawson English wrote: > Maggie Leber (sl: Maggie Darwin) wrote: >> >> On Fri, Feb 19, 2010 at 2:49 PM, Edward Artaud >> wrote: >> >>> >>> ?For client-side scripts to be something worth >>> prioritizing implementing in mainstream viewers, their usage must be >>> based on the assumption that some large percentage (80+% maybe) of >>> attachment scripts, for example, would be running client-side... >>> >> >> Uh...I didn't really see viewer-side scripting as something that would >> make any significant dent in what's done today with scripted objects >> serverside except in the case of some HUD objects. >> >> I was thinking of this as new function, and only incidentally >> providing some marginal performance relief for LLs servers in limited >> cases...such as how Emerald's avatar radar reduces or eliminates >> avatar radar HUDs. >> >> Love to hear other views on this... >> > > Depends on what is being done with it of course. a squeak interface (say) > tied to the socket/shared memory connection could prototype just about any > kind of extension/facility (as long as it used already existing events). > > Suppose, for example, there was a way to use the media plugin's shared > memory as ?a sculpty map rather than simply as a texture to be painted on a > prim. ?One could manipulate the vertices of the sculpy via a plugin and have > the changes show up in the client without putting extra strain on the sim. > The state might be shared via p2p connections between clients' plugins, ?or > collaborative clients could share state 2 ways via a server (or p2p), while > an audience could subscribe to a one-way connection of some kind, or the > animation could be cached in a distributed file, or it might not be shared > at all if someone were working on a test of a new animation and wanted to > see what it would look like in-world before distribution. > > One could have high-end content creation tools hooked into the client this > way and manipulate anything from a prim or texture all the way to the full > scenegraph. physics could be modded the same way. Likewise with custom > scriptable objects. > > This is basically a hybridization of the croquet/cobalt strategy for virtual > worlds and the VWRAP strategy so anything you could do with either should be > possible this way. > > Lawson > > > > > > > > > > > > > > From monkowsk at fishkill.ibm.com Fri Feb 19 15:00:29 2010 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Fri, 19 Feb 2010 18:00:29 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <1266615352.4589.36.camel@domino-laptop> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <1266610103.4589.11.camel@domino-laptop> <1266615352.4589.36.camel@domino-laptop> Message-ID: <4B7F180D.5090204@fishkill.ibm.com> Client-side scripts can only operate on data that is client-side. It means that they do not operated directly on in-world objects. They only access the client's representation of those objects. Any actions performed by a client-side script would only be visible to that particular client. So attachment scripts and vehicle scripts are not candidates for client-side scripting. Before worrying about what language the scripts should be written in, someone has to figure out functions that can operate on the client data model. So anything related to chat is fair game, as is anything related to polygons and meshes, although any modifications to these would be visible only locally (like beacons). Anything related to the UI could be scripted client-side. Accessibility extensions could be client-side. Emerald uses a lot of information in the local avatars data model for its radar. Those kinds of things would be available for defining getter functions. But expect that most functions that operate server-side (most LSL functions) will not be able to operate client-side. You can't just offload those functions to the client. It would be like talking to your television and expecting the characters on the screen to hear you. If the capability doesn't exist in the client-to-server messages now, a client-side script could not communicate it to the servers, where all assets reside. Mike Domino Marama wrote: > On Fri, 2010-02-19 at 15:57 -0500, Maggie Leber (sl: Maggie Darwin) > wrote: > >>On Fri, Feb 19, 2010 at 3:08 PM, Domino Marama >> wrote: >> >> >>>I'd hope things like attachment sizing scripts would move to client side >>>scripts. >> >>I guess that would be nice, but the data that would have to flow to >>the attached hair prims would be substantial....and the prims would >>still have to be scripted. I wouldn't expect to see much savings from >>that. > > > Depends on implementation. I'm assuming client side scripts won't need > transferring sim to sim on teleports, so scripts such as these that > don't need to be active on the sim seem like good candidates to me. > > If anything I'd have thought the data flow with the vehicle scripts > would be more of an issue as that'd be constant messaging between the > client and server parts. It would need careful testing to make sure that > moving the maths client side was more efficient. Even without my crazy > ideas on doing torque based acceleration curves, it's likely that people > will overdo messaging (if it's a feature) with stuff like client hud > speedos for vehicles.. From morgaine.dinova at googlemail.com Fri Feb 19 15:10:16 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Fri, 19 Feb 2010 23:10:16 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <4B7F10BC.2020104@cox.net> Message-ID: No Edward, client-side scripting is not related to in-world scripting at all. It's scripting OF THE CLIENT, and it has the sole purpose of extending the functionality of the client, on a personal basis. While it's nice to hypothesize about in-world scripts being off-loadable to the client, that is merely a conceptual idea without any concrete suggestion for how it could be implemented. It's not what we've been talking about here. Morgaine. =================================== On Fri, Feb 19, 2010 at 10:50 PM, Edward Artaud wrote: > I'm certainly not against a general API for trusted plug-ins > (certainly all my emails to this list have been plug-in related), and > it would be awesome for tools to be built without everyone having to > create a viewer fork. My assumption, however, is that client-side > script capability is meant to go hand in hand with the server-side > script memory limits, where if the script developer marks the script > as "run on client", they're able to run without the same memory limits > as running on the server. If the client-side scripting project isn't > part of the same initiative as the server-side script memory > restrictions, it certainly should be, since one is the elegant > solution to the other. > > On Fri, Feb 19, 2010 at 2:29 PM, Lawson English wrote: > > Maggie Leber (sl: Maggie Darwin) wrote: > >> > >> On Fri, Feb 19, 2010 at 2:49 PM, Edward Artaud > > >> wrote: > >> > >>> > >>> For client-side scripts to be something worth > >>> prioritizing implementing in mainstream viewers, their usage must be > >>> based on the assumption that some large percentage (80+% maybe) of > >>> attachment scripts, for example, would be running client-side... > >>> > >> > >> Uh...I didn't really see viewer-side scripting as something that would > >> make any significant dent in what's done today with scripted objects > >> serverside except in the case of some HUD objects. > >> > >> I was thinking of this as new function, and only incidentally > >> providing some marginal performance relief for LLs servers in limited > >> cases...such as how Emerald's avatar radar reduces or eliminates > >> avatar radar HUDs. > >> > >> Love to hear other views on this... > >> > > > > Depends on what is being done with it of course. a squeak interface (say) > > tied to the socket/shared memory connection could prototype just about > any > > kind of extension/facility (as long as it used already existing events). > > > > Suppose, for example, there was a way to use the media plugin's shared > > memory as a sculpty map rather than simply as a texture to be painted on > a > > prim. One could manipulate the vertices of the sculpy via a plugin and > have > > the changes show up in the client without putting extra strain on the > sim. > > The state might be shared via p2p connections between clients' plugins, > or > > collaborative clients could share state 2 ways via a server (or p2p), > while > > an audience could subscribe to a one-way connection of some kind, or the > > animation could be cached in a distributed file, or it might not be > shared > > at all if someone were working on a test of a new animation and wanted to > > see what it would look like in-world before distribution. > > > > One could have high-end content creation tools hooked into the client > this > > way and manipulate anything from a prim or texture all the way to the > full > > scenegraph. physics could be modded the same way. Likewise with custom > > scriptable objects. > > > > This is basically a hybridization of the croquet/cobalt strategy for > virtual > > worlds and the VWRAP strategy so anything you could do with either should > be > > possible this way. > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100219/a3f19d13/attachment.htm From latifer at streamgrid.net Fri Feb 19 15:14:20 2010 From: latifer at streamgrid.net (Latif Khalifa) Date: Sat, 20 Feb 2010 00:14:20 +0100 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <1266610103.4589.11.camel@domino-laptop> <1266615352.4589.36.camel@domino-laptop> Message-ID: <5ebce2ec1002191514p6db30185g9b69886e1df8e7bf@mail.gmail.com> People seem to be confusing two different things: client side scripting, and client extensions or plugins. 1. Client side scripting Think web browsers. They all support execution of client side scripts in one language in sandboxed environment. So the way original post describes proposed design for client side scripting fits neatly in this scenario. Having a unified platform that scripts can depend on existing in the client (say viewer 2.3 and up support it) would allow all sort of new and innovative content to be created. 2. Plugins Think Firefox extensions/plugins. Like Flash, Java applets, etc. This is entirely different concept. In-world content cannot depend on these being present, and have to allow for situation where some users have some plugins installed, while other do not. Both of these concepts would be a welcome addition to the viewer. I would imagine that the needed internal changes to the viewer could be, at least partially, used for implementation of both. If the first step is to implement client side scripting as described above, we should be talking about it, and separate plugin discussion into a different thread. From tateru.nino at gmail.com Fri Feb 19 15:56:12 2010 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat, 20 Feb 2010 10:56:12 +1100 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <5ebce2ec1002191514p6db30185g9b69886e1df8e7bf@mail.gmail.com> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <1266610103.4589.11.camel@domino-laptop> <1266615352.4589.36.camel@domino-laptop> <5ebce2ec1002191514p6db30185g9b69886e1df8e7bf@mail.gmail.com> Message-ID: <4B7F251C.3010700@weblogsinc.com> When I think of client-side scripting for the viewer, I'm definitely thinking of the latter, not the former. Inworld objects sending limited scripted tasks to the viewer? Doesn't even seem all that useful or desirable, though surely there must be *some* use-cases. On the other hand, being able to plug scripts of my own (or others') devising in to the viewer to improve accessibility and customize usability? Huge win. I've got endless numbers of invoicing and communication tasks that would benefit from being able to build my own data-pipelines or just save myself clicks and keystrokes every time around. On 20/02/2010 10:14 AM, Latif Khalifa wrote: > People seem to be confusing two different things: client side > scripting, and client extensions or plugins. > > 1. Client side scripting > > Think web browsers. They all support execution of client side scripts > in one language in sandboxed environment. So the way original post > describes proposed design for client side scripting fits neatly in > this scenario. > > Having a unified platform that scripts can depend on existing in the > client (say viewer 2.3 and up support it) would allow all sort of new > and innovative content to be created. > > 2. Plugins > > Think Firefox extensions/plugins. Like Flash, Java applets, etc. This > is entirely different concept. In-world content cannot depend on these > being present, and have to allow for situation where some users have > some plugins installed, while other do not. > > Both of these concepts would be a welcome addition to the viewer. I > would imagine that the needed internal changes to the viewer could be, > at least partially, used for implementation of both. If the first step > is to implement client side scripting as described above, we should be > talking about it, and separate plugin discussion into a different > thread. > _______________________________________________ > 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 > > -- Tateru Nino Contributing Editor http://massively.com/ From morgaine.dinova at googlemail.com Fri Feb 19 16:34:17 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Sat, 20 Feb 2010 00:34:17 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <5ebce2ec1002191514p6db30185g9b69886e1df8e7bf@mail.gmail.com> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <1266610103.4589.11.camel@domino-laptop> <1266615352.4589.36.camel@domino-laptop> <5ebce2ec1002191514p6db30185g9b69886e1df8e7bf@mail.gmail.com> Message-ID: That's not a good choice of terms, Latif, as it doesn't distinguish between the two cases: one in which the script is untrusted and hence sandboxed, and the other in which the script is trusted and can freely hook into platform facilities. On Fri, Feb 19, 2010 at 11:14 PM, Latif Khalifa wrote: > People seem to be confusing two different things: client side > scripting, and client extensions or plugins. > > 1. Client side scripting > > Both our cases use scripts, and in both cases the scripts run client-side. Therefore both cases are examples of *client-side scripting*. This is not a good phrase for distinguishing between the two cases. > Think web browsers. They all support execution of client side scripts > in one language in sandboxed environment. So the way original post > describes proposed design for client side scripting fits neatly in > this scenario. > > Having a unified platform that scripts can depend on existing in the > client (say viewer 2.3 and up support it) would allow all sort of new > and innovative content to be created. > > 2. Plugins > > "Plugin" denotes a mechanism for adding some programmed functionality, but that applies to both our cases. Plugins can be autoloaded on demand, and if they're untrusted and run in a sandbox then this doesn't even need any user confirmation. Again, this mechanism word doesn't distinguish between the untrusted+sandboxed case and the trusted one. Both could be implemented as plugins, and the word really means too many things to help us. For example, plugins that load into the host application address space are common, but plugins that run in a separate process are also available, and becoming more common because of multicore. This word doesn't help us disambiguate our two cases. > Think Firefox extensions/plugins. Like Flash, Java applets, etc. This > is entirely different concept. In-world content cannot depend on these > being present, and have to allow for situation where some users have > some plugins installed, while other do not. > > Both of these concepts would be a welcome addition to the viewer. I > would imagine that the needed internal changes to the viewer could be, > at least partially, used for implementation of both. If the first step > is to implement client side scripting as described above, we should be > talking about it, and separate plugin discussion into a different > thread. > While I think we both agree on the nature of the two cases, it seems hard to find good labels to describe them concisely yet correctly. :-) Morgaine. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100220/3eebc4ed/attachment-0001.htm From nexisentertainment at gmail.com Fri Feb 19 16:51:45 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Fri, 19 Feb 2010 16:51:45 -0800 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <4B7EB2A7.3070108@sapinski.com> References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> Message-ID: <1266627105.3694.4320.camel@RAGE> My main problem with Socket-based thing is that it opens up all kinds of problems, ranging from outside apps screwing with the socket and doing stuff that the user has not authorized, to simple security concerns (I'm sure as hell going to trust a readable Lua/LSL/shell/anything-other-than-LISP script more than a binary executable or shared library), to platform issues (opening local listeners may piss off certain software firewall implementations), not to mention the sheer amount of data that must be converted to and from UDP/TCP and transferred over a connection, which could cause latency. Having an embedded scripting engine is simply easier for script-writers, too. All a user needs to know is what functions to use and where to put the sourcecode, whereas a socket-based solution means that a networking API must be present, and the user must maintain a constant connection to SL's process, requiring them to either have a provided API that supports their language (consider the sheer amount of maintenance this would require), or have TCP/IP experience and functions. I'm all for having a way to dynamically load a scripting engine DLL/SO/DYLIB, but I'm not very comfortable forcing users to use sockets in order to interface with their client. There are other ways that aren't as risky, complex, and laggy, and trust me, I'm having enough trouble integrating Lua with SL. The huge level of maintenance and dependency-juggling that just two language APIs would present could overwhelm even the Emerald dev team. On Fri, 2010-02-19 at 10:47 -0500, k\o\w wrote: > RLVa, supports something like this, and can be found in most 3rd party > viewers: > http://rlva.catznip.com/blog/ > http://wiki.secondlife.com/wiki/RestrainedLifeAPI > > On 2/19/2010 10:38 AM, Morgaine wrote: > > Not forgetting Erlang, Ruby, LISP, Javascript, and Bourne shell of > > course. :-) > > > > But here's the fun one, for some value of "fun" ... Someone would > > undoubtedly write an LSL binding to the socket-based API too. And > > however much we screw up our noses at LSL, I have no doubt that a > > large number of SL users who know no other language would be very > > happy to see it. :-) > > > > Providing a socket-based interface to the viewer would be a hugely > > all-embracing approach to client-side scripting, supporting > > everyone's needs. I think it deserves consideration. > > > > > > Morgaine. > > > > > > > > > > =================================== > > > > On Fri, Feb 19, 2010 at 3:23 PM, Morgaine > > wrote: > > Indeed Rob! > > > > Lua is a brilliant language for adding scripting to existing > > applications --- it's designed expressly for embedding and > > extending, it has a clean syntax, it is linguistically very > > powerful, it is very tiny (the whole thing can add under > > 100KB to your application), it can run sandboxed or not as > > desired, and it is one of the fastest pure scripting > > languages currently available, a lot faster than say Python. > > > > It is no surprise then that game developers worldwide > > flocked to it in droves, and now it's one of the most common > > scripting languages found embedded in games. WoW fans use > > it daily as an intrinsic part of their WoW client, and a > > huge community has grown up around Lua-powered interfaces > > for that game. > > > > So yes, I'm with you on the importance of Lua for > > client-side scripting of the viewer. > > > > However, advocating Lua as the sole means of scripting > > viewers would be just as bad a mistake as advocating C# or > > CLR-targetted languages only. It would support only one > > part of the scripting community directly, while > > discriminating against everyone else. This is not > > necessary. > > > > Instead, defining a socket-based API interface would allow > > effectively any language to be used for scripting the > > viewer, since virtually all languages today have socket > > capabilities. That would certainly include Lua and C# and > > Python and Perl and Java and Clojure and C/C++ and > > ObjectiveC and Smalltalk, to name a few languages that this > > community uses regularly. > > > > The only thing that we would have to agree on would be the > > set of messages that cross the socket interface, and the set > > of functions and callbacks that the messages would engage in > > the viewer. That's the kind of productive technical > > discussion we could be having with Lindens, if their design > > process for client-side scripting were open. It needs to > > be. > > > > > > Morgaine. > > > > > > > > > > > > =========================== > > > > > > On Fri, Feb 19, 2010 at 5:24 AM, Rob Nelson > > wrote: > > B-B-But what about Lua, which has already been > > implemented in FlexLife > > (http://flexlife.nexisonline.net)? :( > > > > Fred Rookstown > > Lead Developer > > > > On Thu, 2010-02-18 at 12:42 +0000, Morgaine wrote: > > > I referred recently to Linden's internal project > > "Firefly" to add > > > client-side scripting to SL viewers. This has > > been the topic of open > > > discussion at several Office Hours with Lindens in > > SL, but that > > > openness has not extended to many design details > > --- the Firefly > > > design process is not open to the community. The > > only technical > > > details that are being disclosed about Firefly > > appear to be: > > > > > > * "Scripts" are actually Mono assemblies, so > > that only languages > > > that compile to Mono will be allowed. > > > * The programs run in a sandbox, which means > > that most platform > > > resources are not accessible to them. > > > > > > Please note that I quite like C# as a language, > > but the following > > > remarks are about Mono use in the SL viewer, only, > > where its tradeoffs > > > are poor. > > > > > > The first known detail about Firefly (mandatory > > Mono) is problematic > > > on several fronts: > > > > > 1. Only a tiny fraction of the world's > > applications, libraries > > > and languages work on Mono, so client-side > > scripting will be > > > unable to benefit from the huge mountain > > of resources > > > available on the Internet. This is an > > extremely severe > > > limitation, and an unnecessary restriction > > in the context of > > > client-side viewer scripting. If I want > > to use a > > > locally-installed package X from within my > > client-side script, > > > I should be able to. What runs > > client-side should always be > > > our individual choice, not someone else's. > > > > > 2. Programmers want to write client-side > > scripts in the language > > > that they know best, because that always > > yields the fastest > > > progress and highest quality results. > > There was a good > > > technical reason for forcing everyone to > > use LSL server-side, > > > but there is no technical reason to impose > > this requirement on > > > all client-side scripting. It is > > counter-productive to force > > > CLR compatibility on client-side script > > developers when there > > > is a simple alternative: define a > > socket-based viewer API for > > > client-side scripts instead, hence usable > > from any language. > > > > > 3. Mono runs poorly on Linux, so from being > > rock-solid on Linux > > > now, the LL-derived viewers will become > > second-rate on this > > > platform. > > > > > 4. The viewer is already extremely bloated > > and a memory hog. > > > Adding a Mono dependency will compound > > that horribly. > > > > > 5. There is only one effective supplier of > > Mono: Novell. That > > > is a very bad situation to encourage and > > to support in the > > > viewer. > > > > > 6. Some parties identify other reasons for > > avoiding Mono in > > > general. Without getting into that > > subject at all, > > > > > > The second known detail about Firefly (mandatory > > sandbox) is > > > problematic on two related fronts: > > > > > 1. Sandboxes by design do not allow most > > platform resources to be > > > accessed, as a security measure. This is > > fine and important > > > when scripts are being downloaded from > > unknown places (like > > > Javascript in web pages), but that same > > protection also means > > > that client-side scripts would be > > powerless to do useful > > > things for us in concert with local > > applications, files, > > > devices, etc. Sandboxing client-side > > scripts effectively > > > hardwires in script weakness for no reason > > discussed as a > > > requirement. > > > > > 2. Sandboxed applications cannot be linked > > with user-chosen > > > native libraries since allowing native > > code breaks sandbox > > > protection. This means no accelerators, > > no extensions, and no > > > interop with other systems since sockets > > are inaccessible from > > > any strong sandbox. This also means no > > evolution or progress > > > outside of what the sandbox designers > > permit. > > > > > > This mailing list is concerned with development of > > open source > > > viewers, in particular Snowglobe. This is > > heralded as a community > > > viewer, embodying community requirements much more > > directly than the > > > LL mainstream viewer. Client-side scripting will > > impact on every > > > single aspect of Snowglobe bar none, yet the > > community is being > > > excluded from the design of its most powerful > > infrastructure element. > > > This is entirely wrong, far beyond the normal > > observation > > > that secrecy in design has no place in open > > source. > > > > > > It is hard to assess things technically when the > > design requirements > > > are formulated in secret. The Snowglobe community > > has design > > > requirements too. Those deserve to be examined > > here openly, not > > > limiting Snowglobe to a design that stems from > > Linden requirements > > > alone. > > > > > > > > > Morgaine. > > > > > > > > _______________________________________________ > > > 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 From kow at sapinski.com Fri Feb 19 17:24:34 2010 From: kow at sapinski.com (k\o\w) Date: Fri, 19 Feb 2010 20:24:34 -0500 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <1266627105.3694.4320.camel@RAGE> References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> <1266627105.3694.4320.camel@RAGE> Message-ID: <4B7F39D2.7010301@sapinski.com> According to the latest Emerald change log they've removed LUA altogether. Regardless of where the scripts are executed, I think it's safe to assume that LL will deliver a robust, well protected system that provides very limited (but very useful) access to the viewer and thus minimizes exploit vectors. Look at LSL, prims, avatars, sculpts, the coming mesh models, etc. Everything in SL is the textbook definition of proprietary, and for very good reason. Without these constraints we would have a lot of broken and laggy content, and exploits much worse than what is being abused currently. There is no reason to think that Linden would provide something that could pose a real security risk to your system. It is guaranteed that their implementation will be an invaluable addition to SL, will allow you to plaster penises all over the viewer, and will be abused for years to come by griffers. On 2/19/2010 7:51 PM, Rob Nelson wrote: > My main problem with Socket-based thing is that it opens up all kinds of > problems, ranging from outside apps screwing with the socket and doing > stuff that the user has not authorized, to simple security concerns (I'm > sure as hell going to trust a readable > Lua/LSL/shell/anything-other-than-LISP script more than a binary > executable or shared library), to platform issues (opening local > listeners may piss off certain software firewall implementations), not > to mention the sheer amount of data that must be converted to and from > UDP/TCP and transferred over a connection, which could cause latency. > > Having an embedded scripting engine is simply easier for script-writers, > too. All a user needs to know is what functions to use and where to put > the sourcecode, whereas a socket-based solution means that a networking > API must be present, and the user must maintain a constant connection to > SL's process, requiring them to either have a provided API that supports > their language (consider the sheer amount of maintenance this would > require), or have TCP/IP experience and functions. > > I'm all for having a way to dynamically load a scripting engine > DLL/SO/DYLIB, but I'm not very comfortable forcing users to use sockets > in order to interface with their client. There are other ways that > aren't as risky, complex, and laggy, and trust me, I'm having enough > trouble integrating Lua with SL. The huge level of maintenance and > dependency-juggling that just two language APIs would present could > overwhelm even the Emerald dev team. > > On Fri, 2010-02-19 at 10:47 -0500, k\o\w wrote: > >> RLVa, supports something like this, and can be found in most 3rd party >> viewers: >> http://rlva.catznip.com/blog/ >> http://wiki.secondlife.com/wiki/RestrainedLifeAPI >> >> On 2/19/2010 10:38 AM, Morgaine wrote: >> >>> Not forgetting Erlang, Ruby, LISP, Javascript, and Bourne shell of >>> course. :-) >>> >>> But here's the fun one, for some value of "fun" ... Someone would >>> undoubtedly write an LSL binding to the socket-based API too. And >>> however much we screw up our noses at LSL, I have no doubt that a >>> large number of SL users who know no other language would be very >>> happy to see it. :-) >>> >>> Providing a socket-based interface to the viewer would be a hugely >>> all-embracing approach to client-side scripting, supporting >>> everyone's needs. I think it deserves consideration. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> =================================== >>> >>> On Fri, Feb 19, 2010 at 3:23 PM, Morgaine >>> wrote: >>> Indeed Rob! >>> >>> Lua is a brilliant language for adding scripting to existing >>> applications --- it's designed expressly for embedding and >>> extending, it has a clean syntax, it is linguistically very >>> powerful, it is very tiny (the whole thing can add under >>> 100KB to your application), it can run sandboxed or not as >>> desired, and it is one of the fastest pure scripting >>> languages currently available, a lot faster than say Python. >>> >>> It is no surprise then that game developers worldwide >>> flocked to it in droves, and now it's one of the most common >>> scripting languages found embedded in games. WoW fans use >>> it daily as an intrinsic part of their WoW client, and a >>> huge community has grown up around Lua-powered interfaces >>> for that game. >>> >>> So yes, I'm with you on the importance of Lua for >>> client-side scripting of the viewer. >>> >>> However, advocating Lua as the sole means of scripting >>> viewers would be just as bad a mistake as advocating C# or >>> CLR-targetted languages only. It would support only one >>> part of the scripting community directly, while >>> discriminating against everyone else. This is not >>> necessary. >>> >>> Instead, defining a socket-based API interface would allow >>> effectively any language to be used for scripting the >>> viewer, since virtually all languages today have socket >>> capabilities. That would certainly include Lua and C# and >>> Python and Perl and Java and Clojure and C/C++ and >>> ObjectiveC and Smalltalk, to name a few languages that this >>> community uses regularly. >>> >>> The only thing that we would have to agree on would be the >>> set of messages that cross the socket interface, and the set >>> of functions and callbacks that the messages would engage in >>> the viewer. That's the kind of productive technical >>> discussion we could be having with Lindens, if their design >>> process for client-side scripting were open. It needs to >>> be. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> =========================== >>> >>> >>> On Fri, Feb 19, 2010 at 5:24 AM, Rob Nelson >>> wrote: >>> B-B-But what about Lua, which has already been >>> implemented in FlexLife >>> (http://flexlife.nexisonline.net)? :( >>> >>> Fred Rookstown >>> Lead Developer >>> >>> On Thu, 2010-02-18 at 12:42 +0000, Morgaine wrote: >>> > I referred recently to Linden's internal project >>> "Firefly" to add >>> > client-side scripting to SL viewers. This has >>> been the topic of open >>> > discussion at several Office Hours with Lindens in >>> SL, but that >>> > openness has not extended to many design details >>> --- the Firefly >>> > design process is not open to the community. The >>> only technical >>> > details that are being disclosed about Firefly >>> appear to be: >>> > >>> > * "Scripts" are actually Mono assemblies, so >>> that only languages >>> > that compile to Mono will be allowed. >>> > * The programs run in a sandbox, which means >>> that most platform >>> > resources are not accessible to them. >>> > >>> > Please note that I quite like C# as a language, >>> but the following >>> > remarks are about Mono use in the SL viewer, only, >>> where its tradeoffs >>> > are poor. >>> > >>> > The first known detail about Firefly (mandatory >>> Mono) is problematic >>> > on several fronts: >>> >>> > 1. Only a tiny fraction of the world's >>> applications, libraries >>> > and languages work on Mono, so client-side >>> scripting will be >>> > unable to benefit from the huge mountain >>> of resources >>> > available on the Internet. This is an >>> extremely severe >>> > limitation, and an unnecessary restriction >>> in the context of >>> > client-side viewer scripting. If I want >>> to use a >>> > locally-installed package X from within my >>> client-side script, >>> > I should be able to. What runs >>> client-side should always be >>> > our individual choice, not someone else's. >>> >>> > 2. Programmers want to write client-side >>> scripts in the language >>> > that they know best, because that always >>> yields the fastest >>> > progress and highest quality results. >>> There was a good >>> > technical reason for forcing everyone to >>> use LSL server-side, >>> > but there is no technical reason to impose >>> this requirement on >>> > all client-side scripting. It is >>> counter-productive to force >>> > CLR compatibility on client-side script >>> developers when there >>> > is a simple alternative: define a >>> socket-based viewer API for >>> > client-side scripts instead, hence usable >>> from any language. >>> >>> > 3. Mono runs poorly on Linux, so from being >>> rock-solid on Linux >>> > now, the LL-derived viewers will become >>> second-rate on this >>> > platform. >>> >>> > 4. The viewer is already extremely bloated >>> and a memory hog. >>> > Adding a Mono dependency will compound >>> that horribly. >>> >>> > 5. There is only one effective supplier of >>> Mono: Novell. That >>> > is a very bad situation to encourage and >>> to support in the >>> > viewer. >>> >>> > 6. Some parties identify other reasons for >>> avoiding Mono in >>> > general. Without getting into that >>> subject at all, >>> > >>> > The second known detail about Firefly (mandatory >>> sandbox) is >>> > problematic on two related fronts: >>> >>> > 1. Sandboxes by design do not allow most >>> platform resources to be >>> > accessed, as a security measure. This is >>> fine and important >>> > when scripts are being downloaded from >>> unknown places (like >>> > Javascript in web pages), but that same >>> protection also means >>> > that client-side scripts would be >>> powerless to do useful >>> > things for us in concert with local >>> applications, files, >>> > devices, etc. Sandboxing client-side >>> scripts effectively >>> > hardwires in script weakness for no reason >>> discussed as a >>> > requirement. >>> >>> > 2. Sandboxed applications cannot be linked >>> with user-chosen >>> > native libraries since allowing native >>> code breaks sandbox >>> > protection. This means no accelerators, >>> no extensions, and no >>> > interop with other systems since sockets >>> are inaccessible from >>> > any strong sandbox. This also means no >>> evolution or progress >>> > outside of what the sandbox designers >>> permit. >>> > >>> > This mailing list is concerned with development of >>> open source >>> > viewers, in particular Snowglobe. This is >>> heralded as a community >>> > viewer, embodying community requirements much more >>> directly than the >>> > LL mainstream viewer. Client-side scripting will >>> impact on every >>> > single aspect of Snowglobe bar none, yet the >>> community is being >>> > excluded from the design of its most powerful >>> infrastructure element. >>> > This is entirely wrong, far beyond the normal >>> observation >>> > that secrecy in design has no place in open >>> source. >>> > >>> > It is hard to assess things technically when the >>> design requirements >>> > are formulated in secret. The Snowglobe community >>> has design >>> > requirements too. Those deserve to be examined >>> here openly, not >>> > limiting Snowglobe to a design that stems from >>> Linden requirements >>> > alone. >>> > >>> > >>> > Morgaine. >>> > >>> >>> > _______________________________________________ >>> > 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 >> > > > From lenglish5 at cox.net Fri Feb 19 17:48:27 2010 From: lenglish5 at cox.net (Lawson English) Date: Fri, 19 Feb 2010 18:48:27 -0700 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <4B7F180D.5090204@fishkill.ibm.com> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <1266610103.4589.11.camel@domino-laptop> <1266615352.4589.36.camel@domino-laptop> <4B7F180D.5090204@fishkill.ibm.com> Message-ID: <4B7F3F6B.1040504@cox.net> Mike Monkowski wrote: > Client-side scripts can only operate on data that is client-side. It > means that they do not operated directly on in-world objects. They only > access the client's representation of those objects. Any actions > performed by a client-side script would only be visible to that > particular client. So attachment scripts and vehicle scripts are not > candidates for client-side scripting. > Not using the current server-centric model of SL, true. But a packet injector based on grid-proxy could easily inject an object the sim doesn't know about and control its behavior independently of what the sim says to do. In fact, that is how the puppeteering code worked to a certain extent, although I remain confused as to whether or not feedback for the UI manipulations was cllientside or sent back to the server first and then sent to the originating client as part of the general broadcast to everyone in the sim. Either strategy would have advantages and disadvantages I suspect and either one might make more sense in certain contexts. There's been some talk of client-side physics being extended. Obviously, once you start doing that, the sim has less and less control over what goes on. The ultimate form would be p2p-ish physics where the sim doesn't participate at all in anything but sending geometry updates and all calculations are shared between clients, either in a cobalt fashion, or using a separate physics server (or hybrid). > Before worrying about what language the scripts should be written in, > someone has to figure out functions that can operate on the client data > model. So anything related to chat is fair game, as is anything related > to polygons and meshes, although any modifications to these would be > visible only locally (like beacons). Anything related to the UI could > be scripted client-side. Accessibility extensions could be client-side. > > if you think of the teatime object server used in cobalt as a distributed state server, you could see a scenario where all manipulation is done using smalltalk TObjects and distributed to a teatime server which then passes the updates back down to everyone (including the client originating the UI manipulations). SL client => UI plugin => teatime service <= UI plugin <= SL client V V SL client <= xx-plugin <= teatime service => xx=plugin => SL client > Emerald uses a lot of information in the local avatars data model for > its radar. Those kinds of things would be available for defining getter > functions. > > But expect that most functions that operate server-side (most LSL > functions) will not be able to operate client-side. You can't just > offload those functions to the client. It would be like talking to your > television and expecting the characters on the screen to hear you. If > the capability doesn't exist in the client-to-server messages now, a > client-side script could not communicate it to the servers, where all > assets reside. > > Except NEW behavior that is passed back and forth between clients independently of the sim, or passed back to the sim as an afterthought to an audience that isn't participating in the race/combat/whatever, so they don't need the custom physics/etc packets. Lawson From lenglish5 at cox.net Fri Feb 19 17:52:13 2010 From: lenglish5 at cox.net (Lawson English) Date: Fri, 19 Feb 2010 18:52:13 -0700 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <4B7F10BC.2020104@cox.net> Message-ID: <4B7F404D.7000501@cox.net> Morgaine wrote: > No Edward, client-side scripting is not related to in-world scripting > at all. It's scripting OF THE CLIENT, and it has the sole purpose of > extending the functionality of the client, on a personal basis. > > While it's nice to hypothesize about in-world scripts being > off-loadable to the client, that is merely a conceptual idea without > any concrete suggestion for how it could be implemented. It's not > what we've been talking about here. > Its not NOT what we're talking about, either. ;-) Plugins/scripting could include client-side services to replace/augment services currently provided by the sim, either for display locally, or via caps shared between clients or through external servers or whatever to allow for shared experiences without overwhelming the sim with new stuff. Lawson From secret.argent at gmail.com Fri Feb 19 18:59:11 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 19 Feb 2010 20:59:11 -0600 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: Message-ID: > and this is where languages like perl/python have a strength since the > files are plain text > so if you think that a script is doing something funky you can just > look at the script and see. Mono/dotnet code is compiled and very > easily could hide just about anything. I think using anything but Lua or Javascript (each of which has sandboxed implementations and a community of people already familiar with client-side scripting like this) for any kind of server-pushed client side scripting needs an exceptional justification. The only case I can se for using Mono here is to allow people to write client- side scripts that can not be easily eyeballed by the users. There is of course a community in SL which would consider this an important goal, but given the state of the client and the security model (and I'd be happy to discuss that offlist) I don't think that's a reasonable design goal. From secret.argent at gmail.com Fri Feb 19 19:00:48 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 19 Feb 2010 21:00:48 -0600 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> Message-ID: <1FB10A27-174C-4250-93B7-C56D350A0A20@gmail.com> On 2010-02-19, at 01:16, Ricky wrote: > I suspect that there are two things being discussed here without > distinction: Client scripting, and client extensions. Confusing the > two is easy. > > Client-side scripting SHOULD be sandboxed, and in a controlled set > of languages. For a close example think of javascript in web > browsers. > > Client extensions, or alternatively named as "plugins", would be > modules that can be plugged in and out of the client and run /as if/ > they were a part of the client. Think of browser add-ons/plugins/ > extensions. > > Client side scripts could (read might be, could possibly, needs > further thought, etc.) be given permission to be loaded in by worn > items automatically. Other objects would likely need to request > permission via a security warning. > > Client extensions would have to be downloaded and installed > externally; not delivered in-world. These would truly be programs > on your computer, and should be treated as such. > > Just my thoughts hoping for a clearer discussion. A very good summary. Thank you. From tateru.nino at gmail.com Fri Feb 19 19:06:25 2010 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat, 20 Feb 2010 14:06:25 +1100 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <1FB10A27-174C-4250-93B7-C56D350A0A20@gmail.com> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <1FB10A27-174C-4250-93B7-C56D350A0A20@gmail.com> Message-ID: <4B7F51B1.3040600@gmail.com> Okay, so which one of these is the Lab thinking about, then? That'll settle a lot of debate right there. On 20/02/2010 2:00 PM, Argent Stonecutter wrote: > On 2010-02-19, at 01:16, Ricky wrote: > > >> I suspect that there are two things being discussed here without >> distinction: Client scripting, and client extensions. Confusing the >> two is easy. >> >> Client-side scripting SHOULD be sandboxed, and in a controlled set >> of languages. For a close example think of javascript in web >> browsers. >> >> Client extensions, or alternatively named as "plugins", would be >> modules that can be plugged in and out of the client and run /as if/ >> they were a part of the client. Think of browser add-ons/plugins/ >> extensions. >> >> Client side scripts could (read might be, could possibly, needs >> further thought, etc.) be given permission to be loaded in by worn >> items automatically. Other objects would likely need to request >> permission via a security warning. >> >> Client extensions would have to be downloaded and installed >> externally; not delivered in-world. These would truly be programs >> on your computer, and should be treated as such. >> >> Just my thoughts hoping for a clearer discussion. >> > A very good summary. Thank you. > > _______________________________________________ > 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 > > -- Tateru Nino http://dwellonit.taterunino.net/ From secret.argent at gmail.com Fri Feb 19 19:07:45 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 19 Feb 2010 21:07:45 -0600 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> <3c59673d1002191031v3b754473k28f1e51281d60e41@mail.gmail.com> <4B7EDB2B.4010009@cox.net> Message-ID: On 2010-02-19, at 12:53, Robin Cornelius wrote: > Well Morgaine's socket based idea could over come this very easily. If > the API was exposed via a socket, LL could provide a plugin loader > much as they do for the MediaAPI now, if they want, this pluginloader > could be CLR based and the default LL implementation of plugins could > be mono assemblies. So the plugin loader could be directly used by any > language that can produce CLR binaries. I suggested a socket based extension mechanism some years ago and was knocked down because you couldn't do things that required high performance access to textures, shaders, and so on. If that overhead is acceptable, then the socket mechanism would be completely language- agnostic, and it might even act as a legal firewall between the GPLed client and extensions. From secret.argent at gmail.com Fri Feb 19 19:12:57 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 19 Feb 2010 21:12:57 -0600 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <1266627105.3694.4320.camel@RAGE> References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> <1266627105.3694.4320.camel@RAGE> Message-ID: <8F6C221D-FAFB-4F16-A356-C5C2685315E5@gmail.com> On 2010-02-19, at 18:51, Rob Nelson wrote: > My main problem with Socket-based thing is that it opens up all > kinds of > problems, ranging from outside apps screwing with the socket and doing > stuff that the user has not authorized, If the socket is bound to 127.0.0.1 then only applications on the local machine can connect to and register with it. > to simple security concerns (I'm > sure as hell going to trust a readable > Lua/LSL/shell/anything-other-than-LISP script more than a binary > executable or shared library), This mechanism would allow your script to be written in Perl, Python, Seamonkey (standalone javascript), Lisp, VBscript, Applescript, Tcl, Lua, Icon, even shell. They would not need to be binaries. From morgaine.dinova at googlemail.com Fri Feb 19 20:36:22 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Sat, 20 Feb 2010 04:36:22 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <4B7F51B1.3040600@gmail.com> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <1FB10A27-174C-4250-93B7-C56D350A0A20@gmail.com> <4B7F51B1.3040600@gmail.com> Message-ID: I'll try to answer your question, Tateru. Judging by the only two facts that have been been divulged to us (Mono, and sandbox), it seems a reasonable *guess* (important word) that they're intending to support distributed CLR binaries that run "safely" (important quotes) in a sandbox, and hence cannot interface to any user facilities outside of the sandbox. As will be clear to even the most modest of "power users", this is wholly inadequate on numerous fronts, which I enumerated in the thread starter article. It doesn't support the most important aspect of client-side scripting by far, which is to empower the user in any way she sees fit through full-power local scripting, often interfacing to local facilities which cannot be done from a sandbox. Supporting accessibility requires this. The choice of Mono/CLR is also inadequate, for reasons already given, but it gets worse. Mono in the client should have Lindens screaming away in horror, given the support nightmare that this will create. This will be a major new language subsystem to fail, with bugs arising for every binding that they will have to support. It contrasts extremely badly with the comparatively tiny task of supporting some API functions and callbacks plus a very small socket interface. It's just my guess though. And that's the travesty of this. Why the blazes is a major design for an open source viewer, in a project expressly set up to foster cooperation with the open source community, being done in secret? Why do we have to guess? Why is this not being designed with the community, openly, in the same spirit as they expect the community to help them find and fix bugs? It's really not right. Morgaine. ======================================= On Sat, Feb 20, 2010 at 3:06 AM, Tateru Nino wrote: > Okay, so which one of these is the Lab thinking about, then? That'll > settle a lot of debate right there. > > On 20/02/2010 2:00 PM, Argent Stonecutter wrote: > > On 2010-02-19, at 01:16, Ricky wrote: > > > > > >> I suspect that there are two things being discussed here without > >> distinction: Client scripting, and client extensions. Confusing the > >> two is easy. > >> > >> Client-side scripting SHOULD be sandboxed, and in a controlled set > >> of languages. For a close example think of javascript in web > >> browsers. > >> > >> Client extensions, or alternatively named as "plugins", would be > >> modules that can be plugged in and out of the client and run /as if/ > >> they were a part of the client. Think of browser add-ons/plugins/ > >> extensions. > >> > >> Client side scripts could (read might be, could possibly, needs > >> further thought, etc.) be given permission to be loaded in by worn > >> items automatically. Other objects would likely need to request > >> permission via a security warning. > >> > >> Client extensions would have to be downloaded and installed > >> externally; not delivered in-world. These would truly be programs > >> on your computer, and should be treated as such. > >> > >> Just my thoughts hoping for a clearer discussion. > >> > > A very good summary. Thank you. > > > > _______________________________________________ > > 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 > > > > > > -- > Tateru Nino > http://dwellonit.taterunino.net/ > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100220/4f718b9d/attachment-0001.htm From lenglish5 at cox.net Fri Feb 19 22:27:17 2010 From: lenglish5 at cox.net (Lawson English) Date: Fri, 19 Feb 2010 23:27:17 -0700 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> <3c59673d1002191031v3b754473k28f1e51281d60e41@mail.gmail.com> <4B7EDB2B.4010009@cox.net> Message-ID: <4B7F80C5.5000200@cox.net> Argent Stonecutter wrote: > On 2010-02-19, at 12:53, Robin Cornelius wrote: > >> Well Morgaine's socket based idea could over come this very easily. If >> the API was exposed via a socket, LL could provide a plugin loader >> much as they do for the MediaAPI now, if they want, this pluginloader >> could be CLR based and the default LL implementation of plugins could >> be mono assemblies. So the plugin loader could be directly used by any >> language that can produce CLR binaries. >> > > I suggested a socket based extension mechanism some years ago and was > knocked down because you couldn't do things that required high > performance access to textures, shaders, and so on. If that overhead > is acceptable, then the socket mechanism would be completely language- > agnostic, and it might even act as a legal firewall between the GPLed > client and extensions. > > "Socket" can be another term for "IPC" in this context. I can create a shared memory buffer using FFI calls in squeak, then draw to it using squeak calls to OPenGL. Same would apply using pure smalltalk drawing commands. The next step is to grab the shared buffer that the SL media plugin API creates and draw to that instead. At that point, anything drawn via squeak becomes a local SL texture ala the media plugin. Share those drawing commands between squeak instances over the internet and you have automatic updates to any participating client in a collaborative whiteboard scenario (any OOP object in squeak can be based off of TObject instead of Object, so the full P2P collaborative semantics of croquet can be used for anythign from a full blown virtual world, to a single realtime drawing on the side of a SL prim). For efficiency with people who don't need collaboration you can instead-of/in-addition-to stream the updated texture to a quicktime or other media server and use the current SL mechanisms to show a read-only version of your whiteboarded texture ala html/QT on a prim. Same would apply for any other kind of collaboration from building to scripting to sculpties to [fill in the blank with something no-one has thought of yet]. Variations of this strategy using other collaborative services and languages besides squeak smalltalk could be used instead of/in addition to. I'm just prototyping things in squeak because of the realtime nature of smalltalk development plus the already existing resources that exist in the TeaTime P2P client-server architecture as implemented in croquet. So "socket" IS being embraced officially in the SnowGlobe client via the media plugin (there is provision in the plugin design for mouse/keyboard events to be sent to/from the plugin via genuine socket IPC rather than shared memory) and the model can be extended as above to handle literally ANYTHING if you want to, assuming the internal events/API are exposed to the outside world. Morgaine and I advocate that EVERYTHING be exposed in principle with sandboxing done via registration of external event handlers on a per-plugin basis. By default every event handler permission is turned off, and you must both manually install the plugin and enable it to register event handlers using some currently undefined process (check boxes/white lists/etc) that the plugins can't bypass. This gives scripting languages and plugins the ability, in theory, to modify the behavior of the client in literally any conceivable way as long as the event handlers are explicitly enabled. "Events" might include raw packets ala what can be injected via gridproxy, or GUI events (button press/mouse movement) or human-like commands (teleport to new world/sim ) or physics calculations or new kinds of IM messaging or custom building controls, etc., etc. Adding entirely new features might require a lower level access which may or may not be scriptable, but client-side "scripting" at the level Morgaine and I are talking about can interact with literally any existing function and blur the distinction between "scripting" and many plugins. As to how these events are handled internally, and whether or not some language framework (mono/.net) is given a first amongst peers status, that's another question, but what *I* am hoping for is that the external socket/IPC/plugin interface be given a first class citizenship, even if there's an extra layer for non CLR languages and systems. And smalltalk syntax may work with the CLR, but the smalltalk IDE is incompatible with CLR, so there must be a level of indirection for a smalltalk based plugin to work. Lawson Lawson Lawson From sllists at boroon.dasgupta.ch Sat Feb 20 05:13:56 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 20 Feb 2010 14:13:56 +0100 Subject: [opensource-dev] [IDEA] SNOW-495: CMake flag for producing distributable binaries Message-ID: <4B7FE014.4020507@boroon.dasgupta.ch> http://jira.secondlife.com/browse/SNOW-495 Comments, edits, implementation suggestions, patches ... all welcome over at the pJIRA. cheers Boroondas From sldev at catznip.com Sat Feb 20 06:36:55 2010 From: sldev at catznip.com (Kitty) Date: Sat, 20 Feb 2010 15:36:55 +0100 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <1266557064.3694.4302.camel@RAGE><4B7EB2A7.3070108@sapinski.com> Message-ID: >RLVa is a very notable user-defined API that has far transcended its original purpose, >and is now in extensive use wherever enhancements for accessibility are required. >It really highlights how user-defined functionality should have been in the viewer from the beginning. Slight little correction here: RLVa is solely an (alternate) implementation of the RLV API. While I am responsible for coding RLVa, Marine is responsible for her original RLV implementation and more fitting for this topic she's responsible for the actual RLV API/specification. Since it's used here to refer to the actual API it would be the "RLV API" rather than "RLVa API". Silly for most anyone I'd imagine, but little things like that tend to obscure the origin and credit should go where the credit is due so I just wanted to clear that up :) . Kitty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100220/0fa32a3c/attachment.htm From marinekelley at gmail.com Sat Feb 20 07:57:06 2010 From: marinekelley at gmail.com (Marine Kelley) Date: Sat, 20 Feb 2010 16:57:06 +0100 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> Message-ID: <9e52a8c11002200757q38a9ca3aj6a33dec3229123b1@mail.gmail.com> Thank you Kitty, I appreciate it :) On 20 February 2010 15:36, Kitty wrote: > >RLVa is a very notable user-defined API that has far transcended its > original purpose, > >and is now in extensive use wherever enhancements for accessibility are > required. > >It really highlights how user-defined functionality should have been in > the viewer from the beginning. > > Slight little correction here: RLVa is solely an (alternate) implementation > of the RLV API. While I am responsible for coding RLVa, Marine is > responsible for her original RLV implementation and more fitting for this > topic she's responsible for the actual RLV API/specification. > > Since it's used here to refer to the actual API it would be the "RLV API" > rather than "RLVa API". > > Silly for most anyone I'd imagine, but little things like that tend to > obscure the origin and credit should go where the credit is due so I just > wanted to clear that up :) . > > Kitty > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100220/a72bbd39/attachment.htm From morgaine.dinova at googlemail.com Sat Feb 20 08:01:08 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Sat, 20 Feb 2010 16:01:08 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> Message-ID: Thanks Kitty for that correction. :-) Accurate naming and attribution may not be world-shattering issues, but that's no reason for getting them wrong, and I am glad you took the time to put the record straight. :D /me waves to Kitty and Marine :-) Morgaine. ================================== I certainly had no intention of misrepresenting anything, and mistakenly assumed that the 'a' of RLVa actually referred to "API" rather than "alternate". On Sat, Feb 20, 2010 at 2:36 PM, Kitty wrote: > >RLVa is a very notable user-defined API that has far transcended its > original purpose, > >and is now in extensive use wherever enhancements for accessibility are > required. > >It really highlights how user-defined functionality should have been in > the viewer from the beginning. > > Slight little correction here: RLVa is solely an (alternate) implementation > of the RLV API. While I am responsible for coding RLVa, Marine is > responsible for her original RLV implementation and more fitting for this > topic she's responsible for the actual RLV API/specification. > > Since it's used here to refer to the actual API it would be the "RLV API" > rather than "RLVa API". > > Silly for most anyone I'd imagine, but little things like that tend to > obscure the origin and credit should go where the credit is due so I just > wanted to clear that up :) . > > Kitty > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100220/5d2c34fb/attachment.htm From morgaine.dinova at googlemail.com Sat Feb 20 17:37:30 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Sun, 21 Feb 2010 01:37:30 +0000 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <4B7F80C5.5000200@cox.net> References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> <3c59673d1002191031v3b754473k28f1e51281d60e41@mail.gmail.com> <4B7EDB2B.4010009@cox.net> <4B7F80C5.5000200@cox.net> Message-ID: Argent, I'll just add one specific point to Lawson's broader treatment. In the fully factored out Multi-Process Client designthat we were working on back in the days when AWG did such things, the various processes were attached by sockets and communicated by messaging because that provides the largest amount of decoupling between modules, harnesses the power of multicore with minimal effort, and avoids almost all the pitfalls of concurrent programming with mutable shared state. It's also easy to debug. Although local sockets are easily fast enough for the majority of scripting uses within a VW client, there are a few areas where you want to hit the metal at the fastest possible rate, such as rendering. To cater for this, the design allowed "Facility optimization" or "accelerators" to be defined: in most cases this would mean that two communicating processes would negotiate a shared memory segment for their private use, and eliminate any communication bottleneck between them by using direct memory reference. This approach avoids *premature optimization*: you add an accelerator to a socket link only when profiling tells you that a particular task is suffering from socket throughput or latency issues. In addition, it provides a reference model for functionality: your accelerator should modify only the *speed* of interactions between two processes, and not the semantics. Any unit tests that worked through sockets alone should continue to work with the accelerator enabled, just faster. Transparent acceleration gives you a huge development win. That said, the Multi-Process Client is only vaguely related to the design that we're discussing for client-side scripting in this thread. The viewer is not being redesigned from scratch (as far as we know), and hence a full decomposition along these lines is not in the realm of possibilities. Instead, we have in mind a rather minimalist messaging interface within the viewer, the bare minimum that would allow a message sent by a scripting process to activate a function in the viewer, plus the inverse operation, viewer callbacks that respond to viewer events by sending a message to any script process interested in the event. Despite the minimalism, it is worth noting that the "accelerator" approach of the Multi-Process Client still applies here. There is no reason why an attached script process could not open a dedicated shared memory segment and cooperate with the viewer in very high speed operations, including graphics rendering. It is interesting to hear that you also had this kind of communications architecture in mind. I think perhaps it's an applications model whose time has finally arrived, the age of multicore. Morgaine. ================================= On Sat, Feb 20, 2010 at 6:27 AM, Lawson English wrote: > Argent Stonecutter wrote: > > On 2010-02-19, at 12:53, Robin Cornelius wrote: > > > >> Well Morgaine's socket based idea could over come this very easily. If > >> the API was exposed via a socket, LL could provide a plugin loader > >> much as they do for the MediaAPI now, if they want, this pluginloader > >> could be CLR based and the default LL implementation of plugins could > >> be mono assemblies. So the plugin loader could be directly used by any > >> language that can produce CLR binaries. > >> > > > > I suggested a socket based extension mechanism some years ago and was > > knocked down because you couldn't do things that required high > > performance access to textures, shaders, and so on. If that overhead > > is acceptable, then the socket mechanism would be completely language- > > agnostic, and it might even act as a legal firewall between the GPLed > > client and extensions. > > > > > > "Socket" can be another term for "IPC" in this context. I can create a > shared memory buffer using FFI calls in squeak, then draw to it using > squeak calls to OPenGL. Same would apply using pure smalltalk drawing > commands. The next step is to grab the shared buffer that the SL media > plugin API creates and draw to that instead. At that point, anything > drawn via squeak becomes a local SL texture ala the media plugin. > > Share those drawing commands between squeak instances over the internet > and you have automatic updates to any participating client in a > collaborative whiteboard scenario (any OOP object in squeak can be based > off of TObject instead of Object, so the full P2P collaborative > semantics of croquet can be used for anythign from a full blown virtual > world, to a single realtime drawing on the side of a SL prim). For > efficiency with people who don't need collaboration you can > instead-of/in-addition-to stream the updated texture to a quicktime or > other media server and use the current SL mechanisms to show a read-only > version of your whiteboarded texture ala html/QT on a prim. Same would > apply for any other kind of collaboration from building to scripting to > sculpties to [fill in the blank with something no-one has thought of > yet]. Variations of this strategy using other collaborative services > and languages besides squeak smalltalk could be used instead of/in > addition to. > > I'm just prototyping things in squeak because of the realtime nature of > smalltalk development plus the already existing resources that exist in > the TeaTime P2P client-server architecture as implemented in croquet. > > > So "socket" IS being embraced officially in the SnowGlobe client via the > media plugin (there is provision in the plugin design for mouse/keyboard > events to be sent to/from the plugin via genuine socket IPC rather than > shared memory) and the model can be extended as above to handle > literally ANYTHING if you want to, assuming the internal events/API are > exposed to the outside world. Morgaine and I advocate that EVERYTHING be > exposed in principle with sandboxing done via registration of external > event handlers on a per-plugin basis. By default every event handler > permission is turned off, and you must both manually install the plugin > and enable it to register event handlers using some currently undefined > process (check boxes/white lists/etc) that the plugins can't bypass. > > > This gives scripting languages and plugins the ability, in theory, to > modify the behavior of the client in literally any conceivable way as > long as the event handlers are explicitly enabled. "Events" might > include raw packets ala what can be injected via gridproxy, or GUI > events (button press/mouse movement) or human-like commands (teleport to > new world/sim ) or physics calculations or new kinds of IM messaging or > custom building controls, etc., etc. > > Adding entirely new features might require a lower level access which > may or may not be scriptable, but client-side "scripting" at the level > Morgaine and I are talking about can interact with literally any > existing function and blur the distinction between "scripting" and many > plugins. As to how these events are handled internally, and whether or > not some language framework (mono/.net) is given a first amongst peers > status, that's another question, but what *I* am hoping for is that the > external socket/IPC/plugin interface be given a first class citizenship, > even if there's an extra layer for non CLR languages and systems. > > > And smalltalk syntax may work with the CLR, but the smalltalk IDE is > incompatible with CLR, so there must be a level of indirection for a > smalltalk based plugin to work. > > Lawson > > > > > > Lawson > > > > > > > > > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100221/e485d820/attachment.htm From secret.argent at gmail.com Sat Feb 20 18:42:48 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 20 Feb 2010 20:42:48 -0600 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: References: <1266557064.3694.4302.camel@RAGE> <4B7EB2A7.3070108@sapinski.com> <3c59673d1002191031v3b754473k28f1e51281d60e41@mail.gmail.com> <4B7EDB2B.4010009@cox.net> <4B7F80C5.5000200@cox.net> Message-ID: <03A77A78-2A14-4404-B553-155CDC950AAD@gmail.com> On 2010-02-20, at 19:37, Morgaine wrote: > > It is interesting to hear that you also had this kind of > communications architecture in mind. I think perhaps it's an > applications model whose time has finally arrived, the age of > multicore. It's a fairly natural model. It was really first introduced around 1970 in UNIX... it's called the "pipe". Even on a single-core system it provides a significant performance improvement for a large class of problems where I/O and throughput matter. Of course as multi-CPU UNIX servers became common in the '80s and the norm in the '90s it just got better and better. From carlo at alinoe.com Sun Feb 21 02:45:27 2010 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 21 Feb 2010 11:45:27 +0100 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe Message-ID: <20100221104527.GA29762@alinoe.com> It seems to me that most people still talk about untrusted, portable, and grid-wide supported downloadable scripts when talking about Client-side scripting (sorry Morgaine). So, I propose to go with that, and call anything else "Client-extensions". --- The remainder of this post is about Client-extensions. I sense consensus on the following layered design: [current code base] + lots of hooks to be written | | V C++ API [1] | | V IPC API [2] | | V Plugin(s) One or more plugins then could provide a client-side scripting engine; either for trusted for any language, or a secure API for an engine running the mono bytecode that LL is working on (or whatever). - A scripting engine for language XYZ. [1] Ie, based on the yet to be written LLStateMachine class. [2] Ie, a socket. What is more important is the protocol that is being used here. I can imagine that this will be LLSD, or something simular. -- Carlo Wood PS Note that personally I'm against using mono for clientside scripting... From dzonatas at gmail.com Sun Feb 21 07:46:35 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Sun, 21 Feb 2010 07:46:35 -0800 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> References: <9E76DC5E-A3E3-4A44-9CAE-7E80D83FF46A@lindenlab.com> Message-ID: <4B81555B.50804@gmail.com> It is really sad. When people in the open source community have dedicated there life to help build open source products for the viewer suddenly find out that Linden Lab has totally ignored all that work already put into projects done by the open source community. Consider that I have personally logged the idea of client-side scripting back in April 2007: http://jira.secondlife.com/browse/SVC-98 I find it hard to believe that LL wouldn't want to work with anybody that has done such work. Since I don't want to believe that, then what conclusion can we come to if LL continues to leave us out in the cold. It appears as if LL takes the ideas under their wing, but only the idea. When will LL also take up those that obviously have the idea and have already spent a lot of time invested in this that would be a solid benefit to LL to have them on the team. For LL to completely do it from scratch without the others means even a greater cost to the investors of LL. It means LL employees has to spends the hours of time to comes up with the exact same design conclusions that we have come up with already. Obviously our attempt to join the team at LL isn't anything about being not productive, we just think it saves the investors money on productivity we've already done. I would like to contact the investors of Linden Lab and ask them personally their decision on the matter. Dz Kent Quirk (Q Linden) wrote: > This makes me sad. > > I've been trying to have an open discussion about some of the design > issues in my office hours, specifically to understand the constraints > and requirements of the community. But every office hour seems to be > followed up by flames on this list and in other forums interpreting > what was said in the worst possible way. > > I'm afraid the tone and direction of this discussion are making it > impossible for us to talk about this project productively. > > Q > > > On Feb 18, 2010, at 7:42 AM, Morgaine wrote: > >> I referred recently to Linden's internal project "Firefly" to add >> client-side scripting to SL viewers. This has been the topic of open >> discussion at several Office Hours with Lindens in SL, but that >> openness has not extended to many design details --- the Firefly >> design process is not open to the community. The only technical >> details that are being disclosed about Firefly appear to be: >> >> * "Scripts" are actually *Mono assemblies*, so that only >> languages that compile to Mono will be allowed. >> * The programs run in a *sandbox*, which means that most platform >> resources are not accessible to them. >> >> >> Please note that I quite like C# as a language, but the following >> remarks are about Mono use */in the SL viewer/*, only, where its >> tradeoffs are poor. >> >> The first known detail about Firefly (mandatory Mono) is problematic >> on several fronts: >> >> 1. Only a tiny fraction of the world's applications, libraries and >> languages work on Mono, so client-side scripting will be unable >> to benefit from the huge mountain of resources available on the >> Internet. This is an extremely severe limitation, and an >> unnecessary restriction in the context of client-side viewer >> scripting. If I want to use a locally-installed package X from >> within my client-side script, I should be able to. What runs >> client-side should always be our individual choice, not someone >> else's. >> 2. Programmers want to write client-side scripts in the language >> that they know best, because that always yields the fastest >> progress and highest quality results. There was a good >> technical reason for forcing everyone to use LSL server-side, >> but there is no technical reason to impose this requirement on >> all client-side scripting. It is counter-productive to force >> CLR compatibility on client-side script developers when there >> is a simple alternative: define a *socket-based viewer API* >> for client-side scripts instead, hence usable from any language. >> 3. Mono runs poorly on Linux, so from being rock-solid on Linux >> now, the LL-derived viewers will become second-rate on this >> platform. >> 4. The viewer is already extremely bloated and a memory hog. >> Adding a Mono dependency will compound that horribly. >> 5. There is only one effective supplier of Mono: Novell. That is >> a very bad situation to encourage and to support in the viewer. >> 6. Some parties identify other reasons for avoiding Mono in >> general. Without getting into that subject at all, >> >> >> The second known detail about Firefly (mandatory sandbox) is >> problematic on two related fronts: >> >> 1. Sandboxes by design do not allow most platform resources to be >> accessed, as a security measure. This is fine and important >> when scripts are being downloaded from unknown places (like >> Javascript in web pages), but that same protection also means >> that client-side scripts would be powerless to do useful things >> for us in concert with local applications, files, devices, >> etc. Sandboxing client-side scripts effectively hardwires in >> script weakness for no reason discussed as a requirement. >> 2. Sandboxed applications cannot be linked with user-chosen native >> libraries since allowing native code breaks sandbox protection. >> This means no accelerators, no extensions, and no interop with >> other systems since sockets are inaccessible from any strong >> sandbox. This also means no evolution or progress outside of >> what the sandbox designers permit. >> >> >> This mailing list is concerned with development of open source >> viewers, in particular Snowglobe. This is heralded as a /community/ >> viewer, embodying /community/ requirements much more directly than >> the LL mainstream viewer. Client-side scripting will impact on every >> single aspect of Snowglobe bar none, yet the community is being >> excluded from the design of its most powerful infrastructure element. >> This is entirely wrong, far beyond the normal observation >> that secrecy in design has no place in open source. >> >> It is hard to assess things technically when the design requirements >> are formulated in secret. The Snowglobe community has design >> requirements too. Those deserve to be examined here openly, not >> limiting Snowglobe to a design that stems from Linden requirements alone. >> >> >> Morgaine. >> >> _______________________________________________ >> 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 From kf6kjg at gmail.com Sun Feb 21 08:29:23 2010 From: kf6kjg at gmail.com (Ricky) Date: Sun, 21 Feb 2010 08:29:23 -0800 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: <20100221104527.GA29762@alinoe.com> References: <20100221104527.GA29762@alinoe.com> Message-ID: <3bb9647e1002210829u13820b9dh3747d9ae2b04b351@mail.gmail.com> Look good to me. As you said, a scripting engine (or three) could be written as a plugin. Then we'd only have to decide which plugin(s) get shipped with the client by default. A much more fruitful discussion I think. Ricky Cron Stardust On Sunday, February 21, 2010, Carlo Wood wrote: > It seems to me that most people still talk about untrusted, > portable, and grid-wide supported downloadable scripts when > talking about Client-side scripting (sorry Morgaine). > > So, I propose to go with that, and call anything else > "Client-extensions". > > --- > > The remainder of this post is about Client-extensions. > > I sense consensus on the following layered design: > > [current code base] > > ?+ lots of hooks to be written > > ?| > ?| > ?V > > C++ API [1] > > ?| > ?| > ?V > > IPC API [2] > > ?| > ?| > ?V > > Plugin(s) > > > One or more plugins then could provide a client-side > scripting engine; either for trusted for any language, > or a secure API for an engine running the mono bytecode > that LL is working on (or whatever). > > - A scripting engine for language XYZ. > > [1] Ie, based on the yet to be written LLStateMachine class. > [2] Ie, a socket. What is more important is the protocol > ? ?that is being used here. I can imagine that this will > ? ?be LLSD, or something simular. > > -- > Carlo Wood > > PS Note that personally I'm against using mono for > ? clientside scripting... > > _______________________________________________ > 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 > From maggie at matrisync.com Sun Feb 21 08:58:50 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Sun, 21 Feb 2010 11:58:50 -0500 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: <3bb9647e1002210829u13820b9dh3747d9ae2b04b351@mail.gmail.com> References: <20100221104527.GA29762@alinoe.com> <3bb9647e1002210829u13820b9dh3747d9ae2b04b351@mail.gmail.com> Message-ID: On Sun, Feb 21, 2010 at 11:29 AM, Ricky wrote: > Look good to me. ?As you said, a scripting engine (or three) could be > written as a plugin. ?Then we'd only have to decide which plugin(s) > get shipped with the client by default. And a well-written JSR-223 plug-in could give you all the JSR-223 Java scripting languages in one shot. From morgaine.dinova at googlemail.com Sun Feb 21 14:53:27 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Sun, 21 Feb 2010 22:53:27 +0000 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: <20100221104527.GA29762@alinoe.com> References: <20100221104527.GA29762@alinoe.com> Message-ID: Carlo, I agree completely with you on the principle of the implementation. On the terminology, not only are you not being logical in your naming, but you also immediately contradict yourself and demonstrate beautifully how your suggested naming makes no sense at all, not even to yourself. Let me demonstrate: On Sun, Feb 21, 2010 at 10:45 AM, Carlo Wood wrote: > It seems to me that most people still talk about untrusted, > portable, and grid-wide supported downloadable scripts when > talking about Client-side scripting (sorry Morgaine). > > So, I propose to go with that, and call anything else > "Client-extensions". > > So here you've said that "Client-extensions" are not "Client-side scripting". And then you follow that with: > The remainder of this post is about Client-extensions. > ... > Plugin(s) > > > One or more plugins then could provide a client-side > scripting engine; either for trusted for any language, > or a secure API for an engine running the mono bytecode > that LL is working on (or whatever). > And here you've said that Plugin(s) provide a "client-side scripting engine", in other words, an engine that does client-side scripting. Thank you for showing so clearly that both types are "client-side scripting". :-))))))) As I've been saying all along, anything that does scripting on the client is "client-side scripting". Any other interpretation is going to confuse the hell out of newbies, and as you've shown yourself, even the experts will not be immune to the confusion it creates. :D We can of course choose a couple of different words to disambiguate between the two types. That would be useful. I like the phrase "Client Extensions" for the trusted installed scripts a lot! But you can't say that one of them isn't "client-side scripting", when in both cases the scripts run on the client. What's more, those of us who will be writing our extensions will be scripting our clients. You can't eliminate that phrase, it won't work. I really don't want to belabor this point any further, because it's getting silly. But on the implementation side, yes, this is a good topic, and you're describing a model similar to the one that Argent and Dzonatas and Sai and I and others have proposed. Morgaine. ================================ On Sun, Feb 21, 2010 at 10:45 AM, Carlo Wood wrote: > It seems to me that most people still talk about untrusted, > portable, and grid-wide supported downloadable scripts when > talking about Client-side scripting (sorry Morgaine). > > So, I propose to go with that, and call anything else > "Client-extensions". > > --- > > The remainder of this post is about Client-extensions. > > I sense consensus on the following layered design: > > [current code base] > > + lots of hooks to be written > > | > | > V > > C++ API [1] > > | > | > V > > IPC API [2] > > | > | > V > > Plugin(s) > > > One or more plugins then could provide a client-side > scripting engine; either for trusted for any language, > or a secure API for an engine running the mono bytecode > that LL is working on (or whatever). > > - A scripting engine for language XYZ. > > [1] Ie, based on the yet to be written LLStateMachine class. > [2] Ie, a socket. What is more important is the protocol > that is being used here. I can imagine that this will > be LLSD, or something simular. > > -- > Carlo Wood > > PS Note that personally I'm against using mono for > clientside scripting... > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100221/979c5c8f/attachment.htm From dzonatas at gmail.com Sun Feb 21 16:57:18 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Sun, 21 Feb 2010 16:57:18 -0800 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: References: <20100221104527.GA29762@alinoe.com> Message-ID: <4B81D66E.7040902@gmail.com> Morgaine wrote: > Carlo, I agree completely with you on the principle of the implementation. > > On the terminology, not only are you not being logical in your naming, > but you also immediately contradict yourself and demonstrate > beautifully how your suggested naming makes no sense at all, not even > to yourself.? Let me demonstrate: > > One of Linden Lab's disqualifiers on attempts to be hired had to do with a coin placed on any surface and the game of prediction of who would win based on who placed the last coin on the surface where there was room left over. They go through a bunch of different kinds of objects, so I won't name them off so they can still use the fair ones. However, there was one they were beautifully wrong about: the sphere. They even called people "stupid" on the spot who couldn't figure out the sphere ended up with even amount of moves. Long story short about... stupid. We could challenge this since somehow it became more than personal, or maybe it was meant to be challenged eventually. It wasn't their standard procedure whatever it was. If we take a perfect sphere with a perfect surface, there is an obvious flaw that wouldn't allow it to be even in number of moves. When LL said "here is a sphere the size of a quarter in diameter... 1 2 3 4 5 6" as one points top, bottom, left, right, back, front. And says "Stupid" with a superiority look. Obviously the person that was challenged, the one to be hired, said "Odd." If you know if it is "even" or "odd" then you know who gets the last move, and wins. Further on the surface about a perfect sphere, if it diameter is perfect no matter what tangent coordinate picked out on the surface, then the surface could be eventually said it is infinite. There would be infinite possibilities of any location on the surface that could be tangent coordinated. If that is true, which gave the possibility of infinite surface, then one could also put another perfect sphere nearby the first perfect sphere. Here is the beauty of this, if the first perfect sphere has an infinite surface and the second perfect sphere has an infinite surface, then they are both the same infinite surface. The rules of this game never specified where to put the next perfect sphere. Now if left some space in between the two spheres, then it should still be "Even" number of moves if we continue with this one. What we put the sphere tangent or in union with the first one. It's the same surface, and the game was about the surface. If it is plainly tangent, then there would be one less coin to put on the surface, and it would be "Odd." No? Not convinced, yet? You say that would be two less coins? And you claim "Even?" Let's add another perfect sphere... Same infinite surface. When do we stop? From morgaine.dinova at googlemail.com Sun Feb 21 20:51:20 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Mon, 22 Feb 2010 04:51:20 +0000 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: <4B81D66E.7040902@gmail.com> References: <20100221104527.GA29762@alinoe.com> <4B81D66E.7040902@gmail.com> Message-ID: Dzon: Nice parable. :-) The moral of the story as it pertains to our topic is that when the superset is ambiguous as in our case (all scripts running client-side are naturally "client-side scripts"), then the ambiguity won't stop until you subset the space into disjoint subsets so that you can discuss each subset separately without confusion. That's what I've been trying to do, because "client-side script" is a universal term that naturally denotes all scripts running in the client by simple plain English, so you can't call just one subset of the scripts by that name without creating ambiguity. To remove the ambiguity, I split the space of all scripts that run client-side into two disjoint sets (note that we are using "scripts" and "programs" interchangeably here): - *Trusted / Installed / Not-sandboxed*: These are scripts which you trust enough to install on your machine, and which typically act as interfaces between the viewer and your local resources, such as your files, applications, I/O devices, and so on. Because they interface to local resources, these scripts cannot run in a sandbox. In general, these scripts are for user empowerment --- they can do anything the user wants them to do, and therefore a very good term for them is "*client extensions*". A large number of accessibility scripts fall into this category, as well as scripts for implementing new detached windows such as multi-screen chat and inventories stored on the PC. - *Untrusted / Not-installed / Sandboxed*: These are scripts which you do not trust because they arrived by some automatic mechanism, possibly from in-world. They are never installed, but run in a protective sandbox while needed, and disappear automatically when no longer needed. Because they run in a sandbox to (hopefully) protect your machine from malicious code, these scripts can never access your local resources, as that would be extremely dangerous. In general, these scripts are not for user empowerment, but for enhancing or assisting the displayed content from the current virtual world in some way. A possible term for them is therefore "*world extensions*". This kind of script can implement interesting HUDs using in-world data obtained from the viewer, or new in-viewer windows, menus and improved viewer inventory. A separate question is whether it is wise to allow untrusted scripts to run on your client at all, given that there will always be bugs and protection failures, especially in the first few years. But that is a topic for a later discussion I think, given that currently we have not yet managed to open a dialogue with Lindens about client-side scripting at all. Morgaine. =========================================== On Mon, Feb 22, 2010 at 12:57 AM, Dzonatas Sol wrote: > Morgaine wrote: > >> Carlo, I agree completely with you on the principle of the implementation. >> >> On the terminology, not only are you not being logical in your naming, but >> you also immediately contradict yourself and demonstrate beautifully how >> your suggested naming makes no sense at all, not even to yourself.? Let me >> demonstrate: >> >> >> > One of Linden Lab's disqualifiers on attempts to be hired had to do with a > coin placed on any surface and the game of prediction of who would win based > on who placed the last coin on the surface where there was room left over. > > They go through a bunch of different kinds of objects, so I won't name them > off so they can still use the fair ones. > > However, there was one they were beautifully wrong about: the sphere. > > They even called people "stupid" on the spot who couldn't figure out the > sphere ended up with even amount of moves. Long story short about... stupid. > > We could challenge this since somehow it became more than personal, or > maybe it was meant to be challenged eventually. It wasn't their standard > procedure whatever it was. > > If we take a perfect sphere with a perfect surface, there is an obvious > flaw that wouldn't allow it to be even in number of moves. > > When LL said "here is a sphere the size of a quarter in diameter... 1 2 3 4 > 5 6" as one points top, bottom, left, right, back, front. And says "Stupid" > with a superiority look. > > Obviously the person that was challenged, the one to be hired, said "Odd." > > If you know if it is "even" or "odd" then you know who gets the last move, > and wins. > > Further on the surface about a perfect sphere, if it diameter is perfect no > matter what tangent coordinate picked out on the surface, then the surface > could be eventually said it is infinite. There would be infinite > possibilities of any location on the surface that could be tangent > coordinated. > > If that is true, which gave the possibility of infinite surface, then one > could also put another perfect sphere nearby the first perfect sphere. > > Here is the beauty of this, if the first perfect sphere has an infinite > surface and the second perfect sphere has an infinite surface, then they are > both the same infinite surface. > > The rules of this game never specified where to put the next perfect > sphere. > > Now if left some space in between the two spheres, then it should still be > "Even" number of moves if we continue with this one. > > What we put the sphere tangent or in union with the first one. It's the > same surface, and the game was about the surface. > > If it is plainly tangent, then there would be one less coin to put on the > surface, and it would be "Odd." > > No? Not convinced, yet? You say that would be two less coins? And you claim > "Even?" > > Let's add another perfect sphere... > > Same infinite surface. > > When do we stop? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100222/69ec4baf/attachment-0001.htm From lists.secondlife.com at trap.wereanimal.net Sun Feb 21 21:48:09 2010 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com at trap.wereanimal.net) Date: Mon, 22 Feb 2010 00:48:09 -0500 Subject: [opensource-dev] Second Life Package Repo In-Reply-To: <9f4fbd5c1002181108q551955acibab27dcb70fc604e@mail.gmail.com> References: <9f4fbd5c1002181108q551955acibab27dcb70fc604e@mail.gmail.com> Message-ID: <201002220048.09374.lists.secondlife.com@trap.wereanimal.net> I've been maintaining a gentoo overlay. Just got done doing some updates to it now. While there is a secondlife client in portage, it lacks voice support on 64-bit systems, spacenav joystick support, etc. I managed to re-verce engineer LL build process on my own and develop a much better ebuild. While its is more complex, its has full voice/spacenav support and is actually more flexible then the one supplied by portage. Because I've been doing this, I submitted several patches to fix the builds of problems that I have encountered. --Techwolf Lupindo gentoo.techwolf.net From tigrospottystripes at gmail.com Mon Feb 22 00:06:32 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 22 Feb 2010 05:06:32 -0300 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: References: <20100221104527.GA29762@alinoe.com> <4B81D66E.7040902@gmail.com> Message-ID: <4B823B07.2050500@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 i think that instead of separating the scripts, we should have a table with script names, some info, like creator etc, and a bunch of checkboxes to give or deny permission for the script to do stuff, with a way for client scripts to trigger a permission request dialog. Among the permissions would be a permission to remember permissions, and another to save the script locally/with the account. On 22/2/2010 01:51, Morgaine wrote: > Dzon: Nice parable. :-) > > The moral of the story as it pertains to our topic is that when the > superset is ambiguous as in our case (all scripts running client-side > are naturally "client-side scripts"), then the ambiguity won't stop > until you subset the space into disjoint subsets so that you can discuss > each subset separately without confusion. > > That's what I've been trying to do, because "client-side script" is a > universal term that naturally denotes all scripts running in the client > by simple plain English, so you can't call just one subset of the > scripts by that name without creating ambiguity. > > To remove the ambiguity, I split the space of all scripts that run > client-side into two disjoint sets (note that we are using "scripts" and > "programs" interchangeably here): > > * *Trusted / Installed / Not-sandboxed*: These are scripts which > you trust enough to install on your machine, and which typically > act as interfaces between the viewer and your local resources, > such as your files, applications, I/O devices, and so on. Because > they interface to local resources, these scripts cannot run in a > sandbox. In general, these scripts are for user empowerment --- > they can do anything the user wants them to do, and therefore a > very good term for them is "*client extensions*". A large number > of accessibility scripts fall into this category, as well as > scripts for implementing new detached windows such as multi-screen > chat and inventories stored on the PC. > > > * *Untrusted / Not-installed / Sandboxed*: These are scripts which > you do not trust because they arrived by some automatic mechanism, > possibly from in-world. They are never installed, but run in a > protective sandbox while needed, and disappear automatically when > no longer needed. Because they run in a sandbox to (hopefully) > protect your machine from malicious code, these scripts can never > access your local resources, as that would be extremely > dangerous. In general, these scripts are not for user > empowerment, but for enhancing or assisting the displayed content > from the current virtual world in some way. A possible term for > them is therefore "*world extensions*". This kind of script can > implement interesting HUDs using in-world data obtained from the > viewer, or new in-viewer windows, menus and improved viewer > inventory. > > > > A separate question is whether it is wise to allow untrusted scripts to > run on your client at all, given that there will always be bugs and > protection failures, especially in the first few years. But that is a > topic for a later discussion I think, given that currently we have not > yet managed to open a dialogue with Lindens about client-side scripting > at all. > > > Morgaine. > > > > > > =========================================== > > On Mon, Feb 22, 2010 at 12:57 AM, Dzonatas Sol > wrote: > > Morgaine wrote: > > Carlo, I agree completely with you on the principle of the > implementation. > > On the terminology, not only are you not being logical in your > naming, but you also immediately contradict yourself and > demonstrate beautifully how your suggested naming makes no sense > at all, not even to yourself.? Let me demonstrate: > > > > One of Linden Lab's disqualifiers on attempts to be hired had to do > with a coin placed on any surface and the game of prediction of who > would win based on who placed the last coin on the surface where > there was room left over. > > They go through a bunch of different kinds of objects, so I won't > name them off so they can still use the fair ones. > > However, there was one they were beautifully wrong about: the sphere. > > They even called people "stupid" on the spot who couldn't figure out > the sphere ended up with even amount of moves. Long story short > about... stupid. > > We could challenge this since somehow it became more than personal, > or maybe it was meant to be challenged eventually. It wasn't their > standard procedure whatever it was. > > If we take a perfect sphere with a perfect surface, there is an > obvious flaw that wouldn't allow it to be even in number of moves. > > When LL said "here is a sphere the size of a quarter in diameter... > 1 2 3 4 5 6" as one points top, bottom, left, right, back, front. > And says "Stupid" with a superiority look. > > Obviously the person that was challenged, the one to be hired, said > "Odd." > > If you know if it is "even" or "odd" then you know who gets the last > move, and wins. > > Further on the surface about a perfect sphere, if it diameter is > perfect no matter what tangent coordinate picked out on the surface, > then the surface could be eventually said it is infinite. There > would be infinite possibilities of any location on the surface that > could be tangent coordinated. > > If that is true, which gave the possibility of infinite surface, > then one could also put another perfect sphere nearby the first > perfect sphere. > > Here is the beauty of this, if the first perfect sphere has an > infinite surface and the second perfect sphere has an infinite > surface, then they are both the same infinite surface. > > The rules of this game never specified where to put the next perfect > sphere. > > Now if left some space in between the two spheres, then it should > still be "Even" number of moves if we continue with this one. > > What we put the sphere tangent or in union with the first one. It's > the same surface, and the game was about the surface. > > If it is plainly tangent, then there would be one less coin to put > on the surface, and it would be "Odd." > > No? Not convinced, yet? You say that would be two less coins? And > you claim "Even?" > > Let's add another perfect sphere... > > Same infinite surface. > > When do we stop? > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuCOvEACgkQ8ZFfSrFHsmWb5QCeI7FKwFFU/B42Eo3oDnDa3/2+ cpoAn1yPvCFTv0qFw4y0Ug9yqZr94/bh =Z9Lb -----END PGP SIGNATURE----- From tigrospottystripes at gmail.com Mon Feb 22 01:13:51 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 22 Feb 2010 06:13:51 -0300 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <4B7F3F6B.1040504@cox.net> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <1266610103.4589.11.camel@domino-laptop> <1266615352.4589.36.camel@domino-laptop> <4B7F180D.5090204@fishkill.ibm.com> <4B7F3F6B.1040504@cox.net> Message-ID: <4B824ACF.8020102@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 the other day i was reading about how the Unreal engine works, they have the client predicting the physics and sending control events tot he server. During a lag spike the client continues to simulate the motion by itself, and then whent he server starts talking again the server sends the position, speed, rotation etc of stuff and the client adjusts it's local simulation to match On 19/2/2010 22:48, Lawson English wrote: > > > There's been some talk of client-side physics being extended. > Obviously, once you start doing that, the sim has less and less control > over what goes on. The ultimate form would be p2p-ish physics where the > sim doesn't participate at all in anything but sending geometry updates > and all calculations are shared between clients, either in a cobalt > fashion, or using a separate physics server (or hybrid). > > > > 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuCSs0ACgkQ8ZFfSrFHsmWijwCggPXvBR2irNWxIZv6sqlrjtop lQkAn0cLUUQJkf3E6GR7wI4HxDlPO5Ht =se9S -----END PGP SIGNATURE----- From belxjander at gmail.com Mon Feb 22 02:53:22 2010 From: belxjander at gmail.com (Kajikawa Jeremy) Date: Mon, 22 Feb 2010 19:53:22 +0900 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: <4B823B07.2050500@Gmail.com> References: <20100221104527.GA29762@alinoe.com> <4B81D66E.7040902@gmail.com> <4B823B07.2050500@Gmail.com> Message-ID: <4880eb1a1002220253w6738be44w20185b1d9b5602be@mail.gmail.com> Client-Side-Scripting Examples, Javascript / LindenScript / VBscript / Python, The source and result program are one and the same, Client-Side Extensions, Dynamic Link Libraries / Adobe Flash Player / Java / Mono The distributed program is NOT the original source -- Using the former expands on needing security, Using the latter devolves the client and seperates parts into own program modules. An Example of using Both is the Firefox Browser / Thunderbird Email and similar tools... Can something similar to that be done? Use plugins for secure extension of the client from sandboxed scripts? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100222/9d951369/attachment.htm From secret.argent at gmail.com Mon Feb 22 03:18:37 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon, 22 Feb 2010 05:18:37 -0600 Subject: [opensource-dev] Client-side scripting in Snowglobe In-Reply-To: <4B824ACF.8020102@Gmail.com> References: <3bb9647e1002182316x5d254de5nbfad7c3f943924ae@mail.gmail.com> <1266610103.4589.11.camel@domino-laptop> <1266615352.4589.36.camel@domino-laptop> <4B7F180D.5090204@fishkill.ibm.com> <4B7F3F6B.1040504@cox.net> <4B824ACF.8020102@Gmail.com> Message-ID: <15F29979-FCA3-4DED-BE0A-26211D9556CF@gmail.com> On 2010-02-22, at 03:13, Tigro Spottystripes wrote: > the other day i was reading about how the Unreal engine works, they > have > the client predicting the physics and sending control events tot he > server. During a lag spike the client continues to simulate the motion > by itself, and then whent he server starts talking again the server > sends the position, speed, rotation etc of stuff and the client > adjusts > it's local simulation to match That's pretty much what the SL client does, it just has a particularly simplistic physics (no collisions, no gravity, everything moves in straight lines). From dzonatas at gmail.com Mon Feb 22 12:43:44 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Mon, 22 Feb 2010 12:43:44 -0800 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: References: <20100221104527.GA29762@alinoe.com> <4B81D66E.7040902@gmail.com> Message-ID: <4B82EC80.6080003@gmail.com> Morgaine wrote: > Dzon: Nice parable. :-) Thank you. Unfortunately, some still challenge it as if they know the only answer, yet they should read up on Proton Exchange Membranes, especially Zero-Emission, for proof. For a business to use patented method in their employment process was quite remarkable.Sometimes people get jurassically blindsided by... scale. > > To remove the ambiguity, I split the space of all scripts that run > client-side into two disjoint sets (note that we are using "scripts" > and "programs" interchangeably here): I would go with three. Call the third one: "*Transient Scripts & **Transient **Array*s", or something similar with the word "transient" being significant.More successful designs have included this third area. Basically, in the transient area, you wouldn't want the responsibility of the existence any particular script to fall upon the corporal location of such script, not that the corporal is entirely excluded from being responsible.There is a balance that is needed, and it is best to keep the nature of the balance away from the two other areas you described. > > * *Trusted / Installed / Not-sandboxed*: These are scripts which > you trust enough to install on your machine, and which typically > act as interfaces between the viewer and your local resources, > such as your files, applications, I/O devices, and so on. > Because they interface to local resources, these scripts cannot > run in a sandbox. In general, these scripts are for user > empowerment --- they can do anything the user wants them to do, > and therefore a very good term for them is "*client > extensions*". A large number of accessibility scripts fall > into this category, as well as scripts for implementing new > detached windows such as multi-screen chat and inventories > stored on the PC. > Good. I would think extensions might confuse what direction they extend from, however. If we are to maintain balance, and responsibility, then we need to know that direction. The scripts on the client side may have nothing to do with the client viewer. These same scripts may also seem like a server. Easiest to consider these as "processes," yet that has been confused by the organically evolved chipsets and thread technology. What the "world" only needs to know from the "world" viewpoint are the transfer devices, or membranes. Then we have scripts that can and cannot be exchanged through the membrane. Those that can't get through the membrane, we call "brains" on one scale and "protons" on another scale. That'll work for now. > > * *Untrusted / Not-installed / Sandboxed*: These are scripts > which you do not trust because they arrived by some automatic > mechanism, possibly from in-world. They are never installed, > but run in a protective sandbox while needed, and disappear > automatically when no longer needed. Because they run in a > sandbox to (hopefully) protect your machine from malicious code, > these scripts can never access your local resources, as that > would be extremely dangerous. In general, these scripts are not > for user empowerment, but for enhancing or assisting the > displayed content from the current virtual world in some way. A > possible term for them is therefore "*world extensions*". This > kind of script can implement interesting HUDs using in-world > data obtained from the viewer, or new in-viewer windows, menus > and improved viewer inventory. > > > > A separate question is whether it is wise to allow untrusted scripts > to run on your client at all, given that there will always be bugs and > protection failures, especially in the first few years. But that is a > topic for a later discussion I think, given that currently we have not > yet managed to open a dialogue with Lindens about client-side > scripting at all. That is what the transient area handles. The only way really possible for completely untrusted scripts and arrays to compute on the client side as "world extensions" would be to make a complete copy of the original on the other-side of the membrane. That isn't always true, yet on the scale of "brains" it's a good idea of where to start, not where they would have lost control so easily. 20 years of "fighting" about all this has really set us back.Would have been easier if "trust" was actually accepted rather than some paper masquerade. From carlo at alinoe.com Mon Feb 22 15:51:22 2010 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 23 Feb 2010 00:51:22 +0100 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: <4B81D66E.7040902@gmail.com> References: <20100221104527.GA29762@alinoe.com> <4B81D66E.7040902@gmail.com> Message-ID: <20100222235122.GA19219@alinoe.com> On Sun, Feb 21, 2010 at 04:57:18PM -0800, Dzonatas Sol wrote: > When LL said "here is a sphere the size of a quarter in diameter... > 1 2 3 4 5 6" as one points top, bottom, left, right, back, front. > And says "Stupid" with a superiority look. > > Obviously the person that was challenged, the one to be hired, said "Odd." > > If you know if it is "even" or "odd" then you know who gets the last > move, and wins. This is clearly a way to measure someones spatial insight. Now note that if it's a game, and coins are not allowed to be moved around once they are placed, then it's very unlikely that you will be able to place 6 coins on the surface of that sphere (with diameter equal to the coin), because the one who'd put down the fifth coin would not put it such that you can put down the sixth coin, but somewhere in the middle of the left-over surface, leaving no spot for the sixth coin. Calling people stupid over this game surprises me however (because I happen to have a extremely large spatial insight, officially measured mind you (although, they couldn't actually graph it in their graph because I scored not just out of the graph but even off the paper that the graph outline was printed on)), because I'm having a hardtime to quickly guess if you CAN put five coins on the sphere... It seems not unlikely that only four coins will make it... which would mean that the one that begins will try to leave open as much space as possible when putting down the third coin. The person to move second would try to use as much space as possible. So, first goes on top say, second on grounds of symmetry probably on the bottom, then again forced to play without any strategy, the third coin just goes on the side, and the fourth coin, wanting to be last, takes the exact opposite of that, leaving two places free: Oh hell... that way you STILL end up with six coins being placed, even though both tried to screw the other with strategy. The only freedom that still exists would be the one placing the second coin: by not placing it exactly on the opposite side, you'll likely end up with only five coins. However, since putting it on the exact opposite side caused this player to win, he has little reason to play it elsewhere. Hence, due to perfect symmetry, the first player has no real choice, ever. And the second one, who wins, can control the game completely; hence 6 coins. Not THAT simple however. -- Carlo Wood From carlo at alinoe.com Mon Feb 22 15:56:43 2010 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 23 Feb 2010 00:56:43 +0100 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: References: <20100221104527.GA29762@alinoe.com> <4B81D66E.7040902@gmail.com> Message-ID: <20100222235643.GB19219@alinoe.com> There is no need for A != B. Why not define the words A and B such that A includes B? B \in A Then you can still talk about the subject, since there is still a C = A \not B, such that the intersection of B and C is empty. In other words, yes Client-Extensions include plugins that implement Client-side scripting, but it won't give confusion because if someone means that, they will say "Client-side scripting", so if they DON'T say that, they probably mean something else, either something broader (including client-side script plugins) or something entirely different even. On Mon, Feb 22, 2010 at 04:51:20AM +0000, Morgaine wrote: > The moral of the story as it pertains to our topic is that when the superset is > ambiguous as in our case (all scripts running client-side are naturally > "client-side scripts"), then the ambiguity won't stop until you subset the > space into disjoint subsets so that you can discuss each subset separately > without confusion. > > That's what I've been trying to do, because "client-side script" is a universal > term that naturally denotes all scripts running in the client by simple plain > English, so you can't call just one subset of the scripts by that name without > creating ambiguity. -- Carlo Wood From soft at lindenlab.com Mon Feb 22 17:28:57 2010 From: soft at lindenlab.com (Soft Linden) Date: Mon, 22 Feb 2010 19:28:57 -0600 Subject: [opensource-dev] New mailing list for aditi (beta) simulator releases Message-ID: Curious what changes come with a new simulator? Want to know when something new is landing on aditi? New server-beta mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/server-beta Release notes will always be linked here: http://bit.ly/ADITI_notes In-world group: Second Life Beta Also Oskar Linden, the owner of the new list, holds QA office hours with an eye toward aditi. Check past notices or ask in the Second Life Beta group to learn when and where. From colin.kern at gmail.com Mon Feb 22 21:55:58 2010 From: colin.kern at gmail.com (Colin Kern) Date: Tue, 23 Feb 2010 00:55:58 -0500 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: <20100222235122.GA19219@alinoe.com> References: <20100221104527.GA29762@alinoe.com> <4B81D66E.7040902@gmail.com> <20100222235122.GA19219@alinoe.com> Message-ID: <77c421f01002222155o41ee097cnce5d476d9cfbf65f@mail.gmail.com> On Mon, Feb 22, 2010 at 6:51 PM, Carlo Wood wrote: > On Sun, Feb 21, 2010 at 04:57:18PM -0800, Dzonatas Sol wrote: >> When LL said "here is a sphere the size of a quarter in diameter... >> 1 2 3 4 5 6" as one points top, bottom, left, right, ?back, front. >> And says "Stupid" with a superiority look. >> >> Obviously the person that was challenged, the one to be hired, said "Odd." >> >> If you know if it is "even" or "odd" then you know who gets the last >> move, and wins. > > This is clearly a way to measure someones spatial insight. > > Now note that if it's a game, and coins are not allowed to be moved > around once they are placed, then it's very unlikely that you will > be able to place 6 coins on the surface of that sphere (with diameter > equal to the coin), because the one who'd put down the fifth coin > would not put it such that you can put down the sixth coin, but > somewhere in the middle of the left-over surface, leaving no spot > for the sixth coin. Calling people stupid over this game surprises > me however (because I happen to have a extremely large spatial > insight, officially measured mind you (although, they couldn't > actually graph it in their graph because I scored not just out of > the graph but even off the paper that the graph outline was printed > on)), because I'm having a hardtime to quickly guess if you CAN put > five coins on the sphere... It seems not unlikely that only four > coins will make it... which would mean that the one that begins > will try to leave open as much space as possible when putting > down the third coin. The person to move second would try to use > as much space as possible. So, first goes on top say, second on > grounds of symmetry probably on the bottom, then again forced to > play without any strategy, the third coin just goes on the side, > and the fourth coin, wanting to be last, takes the exact > opposite of that, leaving two places free: Oh hell... that > way you STILL end up with six coins being placed, even though > both tried to screw the other with strategy. The only freedom > that still exists would be the one placing the second coin: by > not placing it exactly on the opposite side, you'll likely end > up with only five coins. However, since putting it on the exact > opposite side caused this player to win, he has little reason > to play it elsewhere. Hence, due to perfect symmetry, the first > player has no real choice, ever. And the second one, who wins, > can control the game completely; hence 6 coins. > > Not THAT simple however. > There's really no way to figure it out without information about either of the player's strategies. It seems like what the interview was really asking is what the maximum number of coins that could be fit on that surface was, or he should have specified that these two players were perfect and playing optimally. Colin From marinekelley at gmail.com Mon Feb 22 23:33:59 2010 From: marinekelley at gmail.com (Marine Kelley) Date: Tue, 23 Feb 2010 08:33:59 +0100 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: <77c421f01002222155o41ee097cnce5d476d9cfbf65f@mail.gmail.com> References: <20100221104527.GA29762@alinoe.com> <4B81D66E.7040902@gmail.com> <20100222235122.GA19219@alinoe.com> <77c421f01002222155o41ee097cnce5d476d9cfbf65f@mail.gmail.com> Message-ID: <13FE0FC9-9E72-424D-81AF-2B55070BDE0C@gmail.com> Exactly my thinking too, the problem us not clear whether the players are cooperative or in competition. It totally changes the result. But I guess that the real goal of this challenge is to call you "stupid" and to gauge your reaction. If you yell or punch the recruiter, you're dismissed. If you say "my bad, you're right", you're dismissed. But if you argue and explain your theory clearly, calmly and with the objective of solving the problem instead of just defending yourself, you prove that you're someone who can integrate a team that works on a system that is both technical and social. On 23 f?vr. 2010, at 06:55, Colin Kern wrote: > On Mon, Feb 22, 2010 at 6:51 PM, Carlo Wood wrote: >> On Sun, Feb 21, 2010 at 04:57:18PM -0800, Dzonatas Sol wrote: >>> When LL said "here is a sphere the size of a quarter in diameter... >>> 1 2 3 4 5 6" as one points top, bottom, left, right, back, front. >>> And says "Stupid" with a superiority look. >>> >>> Obviously the person that was challenged, the one to be hired, >>> said "Odd." >>> >>> If you know if it is "even" or "odd" then you know who gets the last >>> move, and wins. >> >> This is clearly a way to measure someones spatial insight. >> >> Now note that if it's a game, and coins are not allowed to be moved >> around once they are placed, then it's very unlikely that you will >> be able to place 6 coins on the surface of that sphere (with diameter >> equal to the coin), because the one who'd put down the fifth coin >> would not put it such that you can put down the sixth coin, but >> somewhere in the middle of the left-over surface, leaving no spot >> for the sixth coin. Calling people stupid over this game surprises >> me however (because I happen to have a extremely large spatial >> insight, officially measured mind you (although, they couldn't >> actually graph it in their graph because I scored not just out of >> the graph but even off the paper that the graph outline was printed >> on)), because I'm having a hardtime to quickly guess if you CAN put >> five coins on the sphere... It seems not unlikely that only four >> coins will make it... which would mean that the one that begins >> will try to leave open as much space as possible when putting >> down the third coin. The person to move second would try to use >> as much space as possible. So, first goes on top say, second on >> grounds of symmetry probably on the bottom, then again forced to >> play without any strategy, the third coin just goes on the side, >> and the fourth coin, wanting to be last, takes the exact >> opposite of that, leaving two places free: Oh hell... that >> way you STILL end up with six coins being placed, even though >> both tried to screw the other with strategy. The only freedom >> that still exists would be the one placing the second coin: by >> not placing it exactly on the opposite side, you'll likely end >> up with only five coins. However, since putting it on the exact >> opposite side caused this player to win, he has little reason >> to play it elsewhere. Hence, due to perfect symmetry, the first >> player has no real choice, ever. And the second one, who wins, >> can control the game completely; hence 6 coins. >> >> Not THAT simple however. >> > > There's really no way to figure it out without information about > either of the player's strategies. It seems like what the interview > was really asking is what the maximum number of coins that could be > fit on that surface was, or he should have specified that these two > players were perfect and playing optimally. > > Colin > _______________________________________________ > 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 From dzonatas at gmail.com Tue Feb 23 04:22:11 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Tue, 23 Feb 2010 04:22:11 -0800 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: <13FE0FC9-9E72-424D-81AF-2B55070BDE0C@gmail.com> References: <20100221104527.GA29762@alinoe.com> <4B81D66E.7040902@gmail.com> <20100222235122.GA19219@alinoe.com> <77c421f01002222155o41ee097cnce5d476d9cfbf65f@mail.gmail.com> <13FE0FC9-9E72-424D-81AF-2B55070BDE0C@gmail.com> Message-ID: <4B83C873.8010902@gmail.com> Marine Kelley wrote: > Exactly my thinking too, the problem us not clear whether the players > are cooperative or in competition. It totally changes the result. > > But I guess that the real goal of this challenge is to call you > "stupid" and to gauge your reaction. If you yell or punch the > recruiter, you're dismissed. If you say "my bad, you're right", you're > dismissed. But if you argue and explain your theory clearly, calmly > and with the objective of solving the problem instead of just > defending yourself, you prove that you're someone who can integrate a > team that works on a system that is both technical and social. > > > > Hmm. Let's think about this for a few... The players are imperfect... One is the recruiter that knows nothing about the recruitee... The recruiter calls the recruitee "stupid" In the reality of the recruitee, kids are missing (as in stolen), undergoing unknown symptoms of major depression, blisters on feet from working more than 40 hours a week, on up to 80 hours a week to keep family together for more than a year, pressured to work more due to legal problems, almost on the street due to leftover money not meeting needs, etc etc (this is not made up) If the recruitor has no knowledge of this, which they shouldn't because of employment laws, then to call the recruitee "stupid" and for the recruitee to act any bit calm would be a major ability to stay calm under such hardship... even if the recruitee just simply said "my bad, your right" just to pass up an unfair question and explain anything now going on in the mind of the recruitee. Major Depression Disorder is a disability that would be exploited by such question, and this recruitee would never get hired due to this disability, which is against law to not hire someone because of a disability. The reruitee states the obvious and the recruiter takes it as a legal threat, which questions the ability of how this ever will work as a team on a system that is both technical and social... where both win. Long story short... but one is still losing, so when does the "fighting" stop? From morgaine.dinova at googlemail.com Tue Feb 23 07:10:55 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Tue, 23 Feb 2010 15:10:55 +0000 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: <20100222235643.GB19219@alinoe.com> References: <20100221104527.GA29762@alinoe.com> <4B81D66E.7040902@gmail.com> <20100222235643.GB19219@alinoe.com> Message-ID: On Mon, Feb 22, 2010 at 11:56 PM, Carlo Wood wrote: > There is no need for A != B. > > Why not define the words A and B such that A includes B? B \in A > > Then you can still talk about the subject, since there is still a C = A > \not B, > such that the intersection of B and C is empty. > For the simple reason that in our case there is no C = A \not B, because A is the set of all scripts that execute client-side, and that includes all the possible types of scripting/programming that we are discussing here: they are all subsets of A. > > In other words, yes Client-Extensions include plugins that implement > Client-side scripting, but it won't give confusion because if someone means > that, they will say "Client-side scripting", so if they DON'T say that, > they probably mean something else, either something broader (including > client-side script plugins) or something entirely different even. Except that there is no possibility of avoiding confusion your way, because when people write scripts that execute in the client, they will unavoidably call it client-side scripting. It's totally unavoidable because it's normal use of English. It's also normal use of the word "scripting" in numerous language communities --- for example, Lua and Perl and shell programmers always talk about their Lua scripts and Perl scripts and shell scripts, regardless of the application, and it's doubly prevalent when the scripting language is used embedded in a host application because then it distinguishes the script program from the host program. This use of "scripting" is pervasive throughout computing's many language communities. That's not going to change, so rather than trying to sweep back the tide and stopping people saying that they're doing client-side scripting when they're programming client extensions, it's easier to accept that people will always call scripting "scripting" wherever it is being applied, and invent two new disjoint terms instead. It's also worth adding to this Tigro Spottystripe's observationthat a control panel that provides information and control over script properties, resourcing, protection, and so on, is applicable to all kinds of scripts, regardless of where they come from and what role they play. Even just thinking about such practical areas alone, there is a push for commonality. It's not even totally black and white that there *are* two separate categories. One could easily envisage a system where the user controls what local facilities are made accessible to a sandbox per script, so that it's not "all or nothing" like we've been describing up to now. Even trust is not a black and white thing, and nor is installation --- scripts loaded automatically could be cached for longer-lived retention, or even retained forever. Tigro's suggestion is interesting. There really is a continuum here. Morgaine. =================================== On Mon, Feb 22, 2010 at 11:56 PM, Carlo Wood wrote: > There is no need for A != B. > > Why not define the words A and B such that A includes B? B \in A > > Then you can still talk about the subject, since there is still a C = A > \not B, > such that the intersection of B and C is empty. > > In other words, yes Client-Extensions include plugins that implement > Client-side scripting, but it won't give confusion because if someone means > that, they will say "Client-side scripting", so if they DON'T say that, > they probably mean something else, either something broader (including > client-side script plugins) or something entirely different even. > > On Mon, Feb 22, 2010 at 04:51:20AM +0000, Morgaine wrote: > > The moral of the story as it pertains to our topic is that when the > superset is > > ambiguous as in our case (all scripts running client-side are naturally > > "client-side scripts"), then the ambiguity won't stop until you subset > the > > space into disjoint subsets so that you can discuss each subset > separately > > without confusion. > > > > That's what I've been trying to do, because "client-side script" is a > universal > > term that naturally denotes all scripts running in the client by simple > plain > > English, so you can't call just one subset of the scripts by that name > without > > creating ambiguity. > > -- > Carlo Wood > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/d8ecd142/attachment.htm From howard at lindenlab.com Tue Feb 23 11:42:43 2010 From: howard at lindenlab.com (Howard Look) Date: Tue, 23 Feb 2010 11:42:43 -0800 Subject: [opensource-dev] Snowglobe 2 and Open Source Message-ID: Hi Open Source devs, As you probably saw, we just launched Viewer 2 to public Beta. We've been dark for a long time, but it is for good reason: We needed to do a total overhaul of our user experience and that's not something best done by a large group. Honestly, there are times when we had an awful lot of cooks in the kitchen just with our internal team! We also today are launching Snowglobe 2, the Open Source package of Viewer 2.0. Merov has been working really hard to make this happen on the same day that we launched the Viewer 2 Public Beta, so please send him lots of love. As I type, Merov is pushing the svn repository and updating the Snowglobe wiki. We've been completely consumed with getting Viewer 2.0 out the door, which is why you've heard so little from us about where we plan to go from here. But I want to reiterate: We are committed to open source and to supporting the open development community. We embrace the notion that this community develops viewers that serve the needs of a wide range of Residents while we pursue a broader consumer market. I realize that it frustrates some that we are not a completely "open development" project, i.e. we do not do our internal development in a public repository. I do not expect this change in the near future. Over time, we hope that core components of our code can be developed in the open, while the functionality that we wish to keep proprietary can be developed internally. I expect us to evolve to a model that is less like Firefox, and more like Safari+WebKit, where the core engine is an open development project but the high level app is proprietary. Unfortunately, we're not there yet. Our code is not yet modular enough to support that model. There have been many wonderful ideas here recently regarding viewer scriptability, and that's definitely an area we intend to pursue. It goes hand-in-hand with making a more modular code base. The time hasn't been right for us to engage deeply in this conversation; again, we've been quite busy getting 2.0 out the door. Once the dust settles from the 2.0 launch and we're on track to deliver 2.1 in short order, we'll be back and very interested in engaging on this topic. Thanks for your support and patience. Regards, Howard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/20008a5d/attachment.htm From gigstaggart at gmail.com Tue Feb 23 12:16:44 2010 From: gigstaggart at gmail.com (Gigs) Date: Tue, 23 Feb 2010 15:16:44 -0500 Subject: [opensource-dev] Third party viewer policy Message-ID: <4B8437AC.30004@gmail.com> http://secondlife.com/corporate/tpv.php You all realize this is massively incompatible with the GPL, right? From mike.dickson at hp.com Tue Feb 23 12:21:24 2010 From: mike.dickson at hp.com (Mike Dickson) Date: Tue, 23 Feb 2010 14:21:24 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B8437AC.30004@gmail.com> References: <4B8437AC.30004@gmail.com> Message-ID: <4B8438C4.6090702@hp.com> On 02/23/2010 02:16 PM, Gigs wrote: > http://secondlife.com/corporate/tpv.php > > You all realize this is massively incompatible with the GPL, right? > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > Not at all. They're not restricting access to the code. They're restricting access to their service. And defining the terms under which that service is provided. Mike From soft at lindenlab.com Tue Feb 23 12:31:17 2010 From: soft at lindenlab.com (Soft Linden) Date: Tue, 23 Feb 2010 14:31:17 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B8438C4.6090702@hp.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: 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. From robin.cornelius at gmail.com Tue Feb 23 12:37:13 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue, 23 Feb 2010 20:37:13 +0000 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden wrote: > Mike's correct. > > If you see any wording that's ambiguous about that, let us know. > _______________________________________________ Well you seem to have spelled the end of my debian/ubuntu project, I can not meet the tems of the third party viewer policy:- "On your software download page or in another location that a user must visit before installing the Third-Party Viewer, you must disclose the following:" I cannot do this with an apt-repository, the user can bypass every possible webpage or description field. and the fact the policy says this is a MUST. The only possible way to do this is to create a custom program that displays a screen during the install hook of the package and aborts the package install. This can no longer be accepted in to the main debian or ubuntu repositories. Also it appears that i cannot use the snowglobe logo or name, even though i'm basicly building from almost prestine source. I though this was the entire point of the snowglobe rebranding, but now we are exactly where we were with secondlife 12 months ago. Robin From gigstaggart at gmail.com Tue Feb 23 12:42:42 2010 From: gigstaggart at gmail.com (Gigs) Date: Tue, 23 Feb 2010 15:42:42 -0500 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: <4B843DC2.4000102@gmail.com> Soft Linden wrote: > On Tue, Feb 23, 2010 at 2:21 PM, Mike Dickson wrote: >> On 02/23/2010 02:16 PM, Gigs wrote: >>> http://secondlife.com/corporate/tpv.php >>> >>> You all realize this is massively incompatible with the GPL, right? >>> >> Not at all. They're not restricting access to the code. They're >> restricting access to their service. And defining the terms under which >> that service is provided. > > Mike's correct. > > If you see any wording that's ambiguous about that, let us know. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > Nearly all of it? I don't see how it would be possible to make a viewer that does not fall under this policy. From brent.tubbs at gmail.com Tue Feb 23 12:45:01 2010 From: brent.tubbs at gmail.com (Brent Tubbs) Date: Tue, 23 Feb 2010 12:45:01 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: <769bb4301002231245x17272f34h88eca06115b8a406@mail.gmail.com> For a while I've been batting around the idea of creating an SVN-bot to enable much-improved version control for inworld scripts; a must-have when you're developing as part of a team. The same-creator policy on content export would seem to prohibit that though. I realize that you probably don't want to have different rules for each different content type, but the one-size-fits-all rule in the current policy doesn't fit scripts well at all. On Tue, Feb 23, 2010 at 12:37 PM, Robin Cornelius wrote: > On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden wrote: > > Mike's correct. > > > > If you see any wording that's ambiguous about that, let us know. > > _______________________________________________ > > > Well you seem to have spelled the end of my debian/ubuntu project, I > can not meet the tems of the third party viewer policy:- > > "On your software download page or in another location that a user > must visit before installing the Third-Party Viewer, you must disclose > the following:" > > I cannot do this with an apt-repository, the user can bypass every > possible webpage or description field. and the fact the policy says > this is a MUST. The only possible way to do this is to create a custom > program that displays a screen during the install hook of the package > and aborts the package install. This can no longer be accepted in to > the main debian or ubuntu repositories. > > Also it appears that i cannot use the snowglobe logo or name, even > though i'm basicly building from almost prestine source. I though this > was the entire point of the snowglobe rebranding, but now we are > exactly where we were with secondlife 12 months ago. > > Robin > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/5e5fbb9d/attachment.htm From soft at lindenlab.com Tue Feb 23 12:58:20 2010 From: soft at lindenlab.com (Soft Linden) Date: Tue, 23 Feb 2010 14:58:20 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: On Tue, Feb 23, 2010 at 2:37 PM, Robin Cornelius wrote: > On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden wrote: >> Mike's correct. >> >> If you see any wording that's ambiguous about that, let us know. >> _______________________________________________ > > > Well you seem to have spelled the end of my debian/ubuntu project, I > can not meet the tems of the third party viewer policy:- > > "On your software download page or in another location that a user > must visit before installing the Third-Party Viewer, you must disclose > the following:" I'll pass this back for discussion. Something like an extra dialog the first time a user connects to the SL grid would probably be a reasonable alternative. I'll find out for sure. From monkowsk at fishkill.ibm.com Tue Feb 23 12:58:40 2010 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Tue, 23 Feb 2010 15:58:40 -0500 Subject: [opensource-dev] Snowglobe 2 and Open Source In-Reply-To: References: Message-ID: <4B844180.2010903@fishkill.ibm.com> Howard Look wrote: > from here. But I want to reiterate: *We are committed to open source and > to supporting the open development community.* We embrace the notion > that this community develops viewers that serve the needs of a wide > range of Residents while we pursue a broader consumer market. I think you meant to say "a *narrower* consumer market," but no matter. I can find the Snowglobe 2.0 source download, but not the beta viewer source download. have you created a new place to put it? Mike From ambroff at lindenlab.com Tue Feb 23 13:16:18 2010 From: ambroff at lindenlab.com (Ambroff Linden) Date: Tue, 23 Feb 2010 13:16:18 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: <14adf3371002231316n6092e40ahde237fa7d3e760bd@mail.gmail.com> On Tue, Feb 23, 2010 at 12:37 PM, Robin Cornelius wrote: > On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden wrote: > > Mike's correct. > > > > If you see any wording that's ambiguous about that, let us know. > > _______________________________________________ > > > Well you seem to have spelled the end of my debian/ubuntu project, I > can not meet the tems of the third party viewer policy:- > > "On your software download page or in another location that a user > must visit before installing the Third-Party Viewer, you must disclose > the following:" > > I cannot do this with an apt-repository, the user can bypass every > possible webpage or description field. and the fact the policy says > this is a MUST. The only possible way to do this is to create a custom > program that displays a screen during the install hook of the package > and aborts the package install. This can no longer be accepted in to > the main debian or ubuntu repositories. > You can certainly do this using debconf, see the source for the sun-java6-bin[1] package in 9.10 for an example. That package uses debconf to present localized and frontend agnostic dialogs to prompt the user to accept a special license. This is the same technique used by exim, postfix, mysql-server, and loads of other packages to accept user input during installation to perform some configuration tasks. http://www.fifi.org/doc/debconf-doc/tutorial.html -Ambroff [1] Relevant code is in sun-java5-1.5.0-14/debian/JB-jdk.preinst.in -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/8a454ee2/attachment-0001.htm From robin.cornelius at gmail.com Tue Feb 23 13:43:50 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue, 23 Feb 2010 21:43:50 +0000 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden wrote: > Mike's correct. > > If you see any wording that's ambiguous about that, let us know. Well there are many other issues another couple are :- 1h "Central to Second Life is the principle of shared experience. The services we provide through our viewers, for example, our Land Store, the LindeX exchange, and the Xstreet SL marketplace, are designed to enhance Residents? shared experience. We may ask you to make changes to your Third-Party Viewer if it disables certain of our services, or if we believe it is inconsistent with the principle of shared experience or otherwise negatively affects the Second Life user experience. If we do, you agree to make the changes we request." This kind of blocks text viewers as well, of which i author one, as clearly a text only viewer does not share the same experience as a full 3d viewer. Also any one using mono with libomv has an issue as that cannot get the adaptor mac address and passes a NULL mac address, in the past LL have allowed a null mac address as they knew of this problem, clearly now though thats a breach of 2c part i. Robin From cjac at colliertech.org Tue Feb 23 14:21:06 2010 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Tue, 23 Feb 2010 14:21:06 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B8437AC.30004@gmail.com> References: <4B8437AC.30004@gmail.com> Message-ID: <1266963666.5756.0.camel@calcifer> Are you sure? I'd think that denying connection to their services would not be limited in any way by the GPL. But IANAL. On Tue, 2010-02-23 at 15:16 -0500, Gigs wrote: > http://secondlife.com/corporate/tpv.php > > You all realize this is massively incompatible with the GPL, right? > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/9a5788cd/attachment.pgp From cjac at colliertech.org Tue Feb 23 14:23:01 2010 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Tue, 23 Feb 2010 14:23:01 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: <1266963781.5756.1.camel@calcifer> The Debian (Sun) Java runtime package has such an agreement requirement or did at one point. On Tue, 2010-02-23 at 20:37 +0000, Robin Cornelius wrote: > On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden wrote: > > Mike's correct. > > > > If you see any wording that's ambiguous about that, let us know. > > _______________________________________________ > > > Well you seem to have spelled the end of my debian/ubuntu project, I > can not meet the tems of the third party viewer policy:- > > "On your software download page or in another location that a user > must visit before installing the Third-Party Viewer, you must disclose > the following:" > > I cannot do this with an apt-repository, the user can bypass every > possible webpage or description field. and the fact the policy says > this is a MUST. The only possible way to do this is to create a custom > program that displays a screen during the install hook of the package > and aborts the package install. This can no longer be accepted in to > the main debian or ubuntu repositories. > > Also it appears that i cannot use the snowglobe logo or name, even > though i'm basicly building from almost prestine source. I though this > was the entire point of the snowglobe rebranding, but now we are > exactly where we were with secondlife 12 months ago. > > Robin > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/6a296f3e/attachment.pgp From gigstaggart at gmail.com Tue Feb 23 14:27:34 2010 From: gigstaggart at gmail.com (Gigs) Date: Tue, 23 Feb 2010 17:27:34 -0500 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: <4B845656.9000202@gmail.com> Robin Cornelius wrote: > On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden wrote: >> Mike's correct. >> >> If you see any wording that's ambiguous about that, let us know. > > > Well there are many other issues another couple are :- > There are many many other issues. * It gives Linden Lab the ability to delete your private data: "You agree to update or delete at our request any data that you have received from Second Life " * It includes vague terms that are open ended: "You must not violate or promote violation of any law or the rights of any individual or entity" Any law? Including Muslim law? I guess depictions of homosexuality or women wearing normal clothes are right out. "if you are a Developer, you are also responsible for all Third-Party Viewers that you develop or distribute." Responsible in what way? No one is going to accept liability for what their users do with the viewer software. The GPL specifically allows developers to disclaim responsibility. Here you give it back to them. "Expose Second Life users, Linden Lab, or third parties to legal liability or harm as determined by us in our sole discretion." How the hell are we supposed to prevent our users from exposing themselves to legal liability or harm? The Internet is a big dangerous place. We can't be responsible for what users do. Period. "we may request that you add, modify, or remove features, functionality, code or content, and you agree to comply with the request within a reasonable timeframe specified by Linden Lab." The remedy should be solely limited to termination of access to the Second Life service. Linden Lab should not be able to "assign work" to open source developers. *No* developer should subject themselves to the terms of this draconian "policy". We are going to need to know how we can "opt-out" of this and prevent our viewers from connecting to the Second Life service while remaining protocol compatible. The way that it's written, you apparently wind up bound by it if your users connect to Second Life even if you don't want them to. From vexstreeter at gmail.com Tue Feb 23 14:40:45 2010 From: vexstreeter at gmail.com (Vex Streeter) Date: Tue, 23 Feb 2010 17:40:45 -0500 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: <4B84596D.5090707@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/f1b0b6b5/attachment.htm From lenglish5 at cox.net Tue Feb 23 15:05:57 2010 From: lenglish5 at cox.net (Lawson English) Date: Tue, 23 Feb 2010 16:05:57 -0700 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B84596D.5090707@gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> Message-ID: <4B845F55.7070808@cox.net> Vex Streeter wrote: > Soft Linden wrote: >> On Tue, Feb 23, 2010 at 2:21 PM, Mike Dickson wrote: >> >>> On 02/23/2010 02:16 PM, Gigs wrote: >>> >>>> http://secondlife.com/corporate/tpv.php >>>> >>>> You all realize this is massively incompatible with the GPL, right? >>>> >>>> >>> Not at all. They're not restricting access to the code. They're >>> restricting access to their service. And defining the terms under which >>> that service is provided. >>> >> >> Mike's correct. >> >> If you see any wording that's ambiguous about that, let us know. >> > Section 1c unambiguously imposes a GPL-incompatible download and/or > installation requirement that is unrelated to the use of the software > with the SL grid(s). The preamble specifically states that the policy only applies to viewers meant to be used by SL. In essence, LL reserves the right to deny access to viewers that don meet their requirements. MY concern is about prototyping viewers. I can certainly add a thing to timestamp a version string during login, but with smalltalk, I'm constantly tweaking the code *while* I'm connected to SL. Does this mean I have to log out every time I modify something in my squeak client just so I can change the version string? Even if I don't change the SL viewer code, but only something else in the Squeak image, its still part of the same application due to how Smalltalk works. So any time I'm connected to SL using smalltalk, and I play with the workspace to test a new one-liner, I'm effectively changing the viewer code, and must log out and back in with a new version string... Only partly joking here. Taking this policy to its extreme may sound silly, but people are correct: its poorly worded. Lawson From vector at leafpile.com Tue Feb 23 15:07:43 2010 From: vector at leafpile.com (Vector Hastings) Date: Tue, 23 Feb 2010 15:07:43 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: <00cb01cab4dd$019981d0$04cc8570$@com> I love the text only viewers. Would hate to see them disappear. How about SLIM? I realize that can probably be categorized as a separate service that's not a "viewer," but you could also see it as a "chat only" viewer. Could a third-party text-only viewer be considered compliant with 1h if it matches SLIM's functionality? Vector -----Original Message----- From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Robin Cornelius Sent: Tuesday, February 23, 2010 1:44 PM To: Soft Linden Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Third party viewer policy On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden wrote: > Mike's correct. > > If you see any wording that's ambiguous about that, let us know. Well there are many other issues another couple are :- 1h "Central to Second Life is the principle of shared experience. The services we provide through our viewers, for example, our Land Store, the LindeX exchange, and the Xstreet SL marketplace, are designed to enhance Residents' shared experience. We may ask you to make changes to your Third-Party Viewer if it disables certain of our services, or if we believe it is inconsistent with the principle of shared experience or otherwise negatively affects the Second Life user experience. If we do, you agree to make the changes we request." This kind of blocks text viewers as well, of which i author one, as clearly a text only viewer does not share the same experience as a full 3d viewer. Also any one using mono with libomv has an issue as that cannot get the adaptor mac address and passes a NULL mac address, in the past LL have allowed a null mac address as they knew of this problem, clearly now though thats a breach of 2c part i. Robin _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges From domino at dominodesigns.info Tue Feb 23 15:24:56 2010 From: domino at dominodesigns.info (Domino Marama) Date: Tue, 23 Feb 2010 23:24:56 +0000 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: <1266967496.27085.13.camel@domino-laptop> > We may ask you to make changes > to your Third-Party Viewer if it disables certain of our services, or > if we believe it is inconsistent with the principle of shared > experience or otherwise negatively affects the Second Life user > experience. If we do, you agree to make the changes we request. I guess I can cross making an offline rendering client for machinima off my todo list :) More seriously, the policy as it stands would make me cross anything that remotely resembles a client off my todo list. Gigs nailed the major reasons why.. From latifer at streamgrid.net Tue Feb 23 15:28:25 2010 From: latifer at streamgrid.net (Latif Khalifa) Date: Wed, 24 Feb 2010 00:28:25 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B8437AC.30004@gmail.com> References: <4B8437AC.30004@gmail.com> Message-ID: <5ebce2ec1002231528s53b233a1y143a6d6811af9a24@mail.gmail.com> It also means that now I need to hire a lawyer in order to continue to make and distribute my text viewer (Radegast), with special features aimed at people with disabilities. The terms mandate that I need to have an official privacy policy published, and I also need to to show SL ToS to users (and I have no idea where would I get it, and how to tell if it's updated). "Shared experience" clause doesn't even deserve spending time on it. On Tue, Feb 23, 2010 at 9:16 PM, Gigs wrote: > http://secondlife.com/corporate/tpv.php > > You all realize this is massively incompatible with the GPL, right? > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From lenglish5 at cox.net Tue Feb 23 15:37:24 2010 From: lenglish5 at cox.net (Lawson English) Date: Tue, 23 Feb 2010 16:37:24 -0700 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <5ebce2ec1002231528s53b233a1y143a6d6811af9a24@mail.gmail.com> References: <4B8437AC.30004@gmail.com> <5ebce2ec1002231528s53b233a1y143a6d6811af9a24@mail.gmail.com> Message-ID: <4B8466B4.8090907@cox.net> Latif Khalifa wrote: > It also means that now I need to hire a lawyer in order to continue to > make and distribute my text viewer (Radegast), with special features > aimed at people with disabilities. The terms mandate that I need to > have an official privacy policy published, and I also need to to show > SL ToS to users (and I have no idea where would I get it, and how to > tell if it's updated). "Shared experience" clause doesn't even deserve > spending time on it. > If a media plugin provides collaboration between participating viewers and doesn't update the sim, or only updates the sim with a view-only version of what people are working on, does this violate the "shared experience" clause? What about musicians sharing sound data between themselves via client plugins and doing mixing before uploading the sound to the sim? And what about the VWRAP proposal to let clients establish connections for external services via capabilities? Such a capability could easily violate the new policy. Lots of vague stuff in this policy. L. > On Tue, Feb 23, 2010 at 9:16 PM, Gigs wrote: > >> http://secondlife.com/corporate/tpv.php >> >> You all realize this is massively incompatible with the GPL, right? >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > > From dragnier1428 at hotmail.com Tue Feb 23 15:46:31 2010 From: dragnier1428 at hotmail.com (james ross) Date: Tue, 23 Feb 2010 17:46:31 -0600 Subject: [opensource-dev] Trying to compile the viewer, what does this mean? In-Reply-To: References: Message-ID: I am still trying to compile the viewer by trying every tutorial I can find. I pasted the link to the wiki site below in which I am having issues. I am currently in the proccess of downloading a copy of .NET 2003 from the MSDNA so that I can open the Apache files without them corrupting on me. I made it to this section on OpenSSL and hit a wall. I tried downloading the OpenSSL and noticed that it is a tarball......I found a WIN-32 Openssl but cannot locate this fabled 'perl Configure VC-WIN32' command. Also the cd %PATH% gives me a file path is to long error. If someone could explain this OPENSSL step I would appreciate it. WebSiteLink: http://wiki.secondlife.com/wiki/Compiling_the_viewer_libraries_%28MSVS_2003%29#Boost OpenSSL Download and extract: http://www.openssl.org/source/ Using the command prompt, build the static libraries: cd %PATH% perl Configure VC-WIN32 ms\do_masm Edit openssl-X.X.Xy\ms\nt.mak Change /MD to /MT in CFLAGS back in the command prompt: "C:\Program Files\Microsoft Visual Studio .net 2003\Common7\Tools\vsvars32.bat" nmake -f ms\nt.mak copy all the ".lib" files from "openssl-X.X.Xy\out32" to "libraries\i686-win32\lib_release" Thanks, James _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/201469230/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/8bb5f200/attachment.htm From nexisentertainment at gmail.com Tue Feb 23 16:40:09 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Tue, 23 Feb 2010 16:40:09 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B8437AC.30004@gmail.com> References: <4B8437AC.30004@gmail.com> Message-ID: <1266972009.3694.4327.camel@RAGE> Thanks LL, you killed my viewer that I have developed alone for two years and was probably a week away from releasing, due to one stupid copyright enfarcement rule: No "Life" in the name. Do you realize how much documentation, sourcecode, licensing, subdomains, bug trackers, wiki, images, logos, google code/SVN repo, etc that I, a one-man development team with other things on his mind have to change? Did you even consider all of this prior to releasing this policy? If I do resume development, AGNI will not be a grid my users will be able to connect to. I hope others with the same problem will also boycott your grid because of this. All I wanted to do was develop some software that would maybe be helpful to people, or perhaps improve the user experience. Now no one can use it. Thanks a lot. I've tried hard over the last year to On Tue, 2010-02-23 at 15:16 -0500, Gigs wrote: > http://secondlife.com/corporate/tpv.php > > You all realize this is massively incompatible with the GPL, right? > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From I_really_needed_a_new_mailbox at gmx.de Tue Feb 23 16:43:57 2010 From: I_really_needed_a_new_mailbox at gmx.de (Zai Lynch) Date: Wed, 24 Feb 2010 01:43:57 +0100 Subject: [opensource-dev] Smoke test plans for viewer 2 available? Message-ID: Hi here! I was pondering: Could existing test plans for viewer 2 be published in the public wiki? It would certainly be cool to have these, since localization teams are now asked to provide bug reports for localized versions. Having some kind of step by step plan to cover all viewer parts would certainly be a benefit for that. Would also be good for Snowglobe 2.0. zai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100224/fbb5f760/attachment.htm From robertltux at gmail.com Tue Feb 23 17:08:13 2010 From: robertltux at gmail.com (Robert Martin) Date: Tue, 23 Feb 2010 20:08:13 -0500 Subject: [opensource-dev] question on SL/SG 2.0 avatar backend Message-ID: ive been trying to get somebody to code an editor for SL clothing and one of the things ive found is a file deep somewhere in the tree that has the parameters of the avatar in a nice neat list. The question is since i seem to have dumped the original could somebody remind me where this file is in the source tree (i would like to see the changes that 2.0 has done to this file). -- Robert L Martin oh and a side note to be flipped to the docs team specs for the tattoo and alpha layer would be nifty From nyx at lindenlab.com Tue Feb 23 17:18:17 2010 From: nyx at lindenlab.com (Nyx Linden) Date: Tue, 23 Feb 2010 20:18:17 -0500 Subject: [opensource-dev] question on SL/SG 2.0 avatar backend In-Reply-To: References: Message-ID: <4B847E59.9090104@lindenlab.com> I believe you're referring to avatar_lad.xml, which is stored in the character subdirectory of your client's install directory. If you have any specific questions on it, please let me know! -Nyx Robert Martin wrote: > ive been trying to get somebody to code an editor for SL clothing and > one of the things ive found is a file deep somewhere in the tree that > has the parameters of the avatar in a nice neat list. > The question is since i seem to have dumped the original could > somebody remind me where this file is in the source tree > (i would like to see the changes that 2.0 has done to this file). > > From malachi at tamzap.com Tue Feb 23 17:34:52 2010 From: malachi at tamzap.com (malachi) Date: Tue, 23 Feb 2010 20:34:52 -0500 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <1266972009.3694.4327.camel@RAGE> References: <4B8437AC.30004@gmail.com> <1266972009.3694.4327.camel@RAGE> Message-ID: <4B84823C.5060700@tamzap.com> im curious as to how this will apply to clients and bots that seem to have the ability to not only gather agents ip addresses but by obtaining this information raid those agents computers searching for data... particularly the new copybot detection system by an unmentioned developer. The fact that Linden Lab has allowed this product to be released implements Linden Lab in possible legal actions. This is a violation of not only the Second Life Terms of Service but various other Internet related Laws and policies. I for one would like to know if this bot system will be removed and its creators rights to the Second Life grid be revoked or if they will be allowed to continue to hack into residents computers looking for information regarding 3rd party clients being installed on the machines. If they are allowed to continue then i would like for Linden Lab to hand over all Real life information on its creator for a possible Law Suit. Because for one i never authorized anyone at Linden Lab much less anyone that simply just plays Second Life to have access to my computer and my data. thus the ability of a resident to retrieve such information is a violation of my privacy. point blank. From thomas.shikami at online.de Tue Feb 23 18:11:00 2010 From: thomas.shikami at online.de (Thomas Shikami) Date: Wed, 24 Feb 2010 03:11:00 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B84823C.5060700@tamzap.com> References: <4B8437AC.30004@gmail.com> <1266972009.3694.4327.camel@RAGE> <4B84823C.5060700@tamzap.com> Message-ID: <4B848AB4.4030909@online.de> malachi schrieb: > im curious as to how this will apply to clients and bots that seem to > have the ability to not only gather agents ip addresses but by obtaining > this information raid those agents computers searching for data... > particularly the new copybot detection system by an unmentioned > developer. The fact that Linden Lab has allowed this product to be > released implements Linden Lab in possible legal actions. This is a > violation of not only the Second Life Terms of Service but various other > Internet related Laws and policies. Sills bot system doesn't do anything illegal in activity. It does not scan the users computers as can be verified by intrusion detection software. Also an IP address is not neccessary to fingerprint a used viewer. There is enough information publicly available from SL servers alone that allows detection of the viewer being used. > I for one would like to know if this > bot system will be removed and its creators rights to the Second Life > grid be revoked or if they will be allowed to continue to hack into > residents computers looking for information regarding 3rd party clients > being installed on the machines. If they are allowed to continue then i > would like for Linden Lab to hand over all Real life information on its > creator for a possible Law Suit. > Pretty much a flame post. Don't feed the trolls. > Because for one i never authorized anyone at Linden Lab much less anyone > that simply just plays Second Life to have access to my computer and my > data. thus the ability of a resident to retrieve such information is a > violation of my privacy. point blank. Troll post. From trilobyte550m at gmail.com Tue Feb 23 18:19:37 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Tue, 23 Feb 2010 18:19:37 -0800 Subject: [opensource-dev] Snowglobe 2 and Open Source In-Reply-To: References: Message-ID: <46D25999-07A5-416A-B653-A0CC1FF4861A@gmail.com> Awesome to see something posted so quickly (though huge shame that testing resources like this group and BSI weren't utilized). Can't help but notice we've lost some functionality from Snowglobe 1.3.... namely the drop down to choose the user name on login, and panning around the mini-map. What else from recent builds may have been lost/skipped/thrown away? TriloByte Zanzibar On Feb 23, 2010, at 11:42 AM, Howard Look wrote: > Hi Open Source devs, > > As you probably saw, we just launched Viewer 2 to public Beta. We've been dark for a long time, but it is for good reason: We needed to do a total overhaul of our user experience and that's not something best done by a large group. Honestly, there are times when we had an awful lot of cooks in the kitchen just with our internal team! > > We also today are launching Snowglobe 2, the Open Source package of Viewer 2.0. Merov has been working really hard to make this happen on the same day that we launched the Viewer 2 Public Beta, so please send him lots of love. As I type, Merov is pushing the svn repository and updating the Snowglobe wiki. > > We've been completely consumed with getting Viewer 2.0 out the door, which is why you've heard so little from us about where we plan to go from here. But I want to reiterate: We are committed to open source and to supporting the open development community. We embrace the notion that this community develops viewers that serve the needs of a wide range of Residents while we pursue a broader consumer market. > > I realize that it frustrates some that we are not a completely "open development" project, i.e. we do not do our internal development in a public repository. I do not expect this change in the near future. Over time, we hope that core components of our code can be developed in the open, while the functionality that we wish to keep proprietary can be developed internally. I expect us to evolve to a model that is less like Firefox, and more like Safari+WebKit, where the core engine is an open development project but the high level app is proprietary. Unfortunately, we're not there yet. Our code is not yet modular enough to support that model. > > There have been many wonderful ideas here recently regarding viewer scriptability, and that's definitely an area we intend to pursue. It goes hand-in-hand with making a more modular code base. The time hasn't been right for us to engage deeply in this conversation; again, we've been quite busy getting 2.0 out the door. Once the dust settles from the 2.0 launch and we're on track to deliver 2.1 in short order, we'll be back and very interested in engaging on this topic. > > Thanks for your support and patience. > > Regards, > Howard > >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/a19c4dd9/attachment-0001.htm From malachi at tamzap.com Tue Feb 23 18:40:23 2010 From: malachi at tamzap.com (malachi) Date: Tue, 23 Feb 2010 21:40:23 -0500 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B848AB4.4030909@online.de> References: <4B8437AC.30004@gmail.com> <1266972009.3694.4327.camel@RAGE> <4B84823C.5060700@tamzap.com> <4B848AB4.4030909@online.de> Message-ID: <4B849197.1090607@tamzap.com> sorry thomas but the idea that a person can be detected by skills system while running LL's client on a name that is new today and never been logged in on any other client... shows that the information used to detect if a person has 'ever' used a bad client is coming from the persons computer. and the fact that one of the admins over skills system tells you that in order to run a bad client and not be detected by the system is to install vmware and run the client there tells me that the system is in fact gather information from your computer. the fact that the system in not installed on my computer leads me to believe its HACKING. you can protect your friends all you want thomas but Linden Lab needs to address that fact that this system is a HUGE violation of the terms of service and various local state and governmental laws. On 2/23/2010 9:11 PM, Thomas Shikami wrote: > malachi schrieb: > >> im curious as to how this will apply to clients and bots that seem to >> have the ability to not only gather agents ip addresses but by obtaining >> this information raid those agents computers searching for data... >> particularly the new copybot detection system by an unmentioned >> developer. The fact that Linden Lab has allowed this product to be >> released implements Linden Lab in possible legal actions. This is a >> violation of not only the Second Life Terms of Service but various other >> Internet related Laws and policies. >> > Sills bot system doesn't do anything illegal in activity. It does not > scan the users computers as can be verified by intrusion detection > software. Also an IP address is not neccessary to fingerprint a used > viewer. There is enough information publicly available from SL servers > alone that allows detection of the viewer being used. > >> I for one would like to know if this >> bot system will be removed and its creators rights to the Second Life >> grid be revoked or if they will be allowed to continue to hack into >> residents computers looking for information regarding 3rd party clients >> being installed on the machines. If they are allowed to continue then i >> would like for Linden Lab to hand over all Real life information on its >> creator for a possible Law Suit. >> >> > Pretty much a flame post. Don't feed the trolls. > >> Because for one i never authorized anyone at Linden Lab much less anyone >> that simply just plays Second Life to have access to my computer and my >> data. thus the ability of a resident to retrieve such information is a >> violation of my privacy. point blank. >> > Troll post. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From thomas.shikami at online.de Tue Feb 23 19:07:35 2010 From: thomas.shikami at online.de (Thomas Shikami) Date: Wed, 24 Feb 2010 04:07:35 +0100 Subject: [opensource-dev] Flames about CDS (was: Re: Third party viewer policy) In-Reply-To: <4B849197.1090607@tamzap.com> References: <4B8437AC.30004@gmail.com> <1266972009.3694.4327.camel@RAGE> <4B84823C.5060700@tamzap.com> <4B848AB4.4030909@online.de> <4B849197.1090607@tamzap.com> Message-ID: <4B8497F7.8080503@online.de> malachi schrieb: > sorry thomas but the idea that a person can be detected by skills system > while running LL's client on a name that is new today and never been > logged in on any other client... shows that the information used to > detect if a person has 'ever' used a bad client is coming from the > persons computer. and the fact that one of the admins over skills system > tells you that in order to run a bad client and not be detected by the > system is to install vmware and run the client there tells me that the > system is in fact gather information from your computer. the fact that > the system in not installed on my computer leads me to believe its > HACKING. you can protect your friends all you want thomas but Linden Lab > needs to address that fact that this system is a HUGE violation of the > terms of service and various local state and governmental laws. > Hardware based packet loggers don't lie about that. (Those that you plug between computer and internet) What I see is that you are crying about her system and that you want it removed. Spreading unverifiable rumors about how her system works in your eyes. Because she put your client on the banlist because your client supports griefing or copybotting? Come on, mature. Just don't spread false informations that can easily be prooven being wrong. The system is detecting indeed if you used a griefer client, it does this pretty well. (it takes a while until the fingerprinting is changed to the currently used viewer and not guaranteed to be completely reverted, so relogging from a banned to a legit viewer and teleporting to a CDS enabled area will likely detect that you used that banned viewer on your last login. This effect can even last for multiple logins. So better not use a banned viewer ever.) Do us a favour and take it up with LL and Skills. This mailing list is not for spreading of misinformation and slander. From morgaine.dinova at googlemail.com Tue Feb 23 20:30:46 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Wed, 24 Feb 2010 04:30:46 +0000 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B8437AC.30004@gmail.com> References: <4B8437AC.30004@gmail.com> Message-ID: Gigs is totally right that http://secondlife.com/corporate/tpv.php is completely incompatible with the GPL. Specifically, TPV clause 1c is incompatible with GPLv2 clause 6. GPLv2 has a FAQ that elaborates on this point, highlighting from clause 6 that: - "*You may not impose any further restrictions on the recipients' exercise of the rights granted herein.*" TPV 1c adds massive further restrictions on Developers that fall under the condition of "*If you are a Developer who distributes Third-Party Viewers to others".* Please note the word "*distributes*" in the condition above, because it is crucial. GPLv2 is a *distribution license*, in other words it triggers at the point of distribution of GPL-licensed code. The freedoms that GPLv2 grants apply at that specific point in time, allowing a developer to *distribute* his code freely downstream to the next recipient, who can then modify the code again and *distribute* it to others downstream, and so on. It is this distribution that TPV 1c specifically entangles with a mass of restrictions. This cannot be done with the GPL of any version. TPV is dramatically GLPv2 non-compliant. I fully expect that LL did not intend to make TPV 1c apply so broadly and to be GPL non-compliant. Rather than this being intentional, it's more likely (I think) that the document was drafted by someone not very good at legal language and ignorant of the GPL. Unfortunately, the words stand as written, so unless they are rewritten, no Linden-derived viewer will be distributable under GPL. GPL cannot be used to grant fewer freedoms than the GPL specifies. Lindens are of course entirely within their rights to determine how their service is used. What they cannot do is use the GPLv2 license while at the same time imposing on the developer "*further restrictions on the recipients' exercise of the rights granted herein.*" Morgaine. ======================================= On Tue, Feb 23, 2010 at 8:16 PM, Gigs wrote: > http://secondlife.com/corporate/tpv.php > > You all realize this is massively incompatible with the GPL, right? > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100224/a81c9f10/attachment.htm From vexstreeter at gmail.com Tue Feb 23 20:44:12 2010 From: vexstreeter at gmail.com (Vex Streeter) Date: Tue, 23 Feb 2010 23:44:12 -0500 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B845F55.7070808@cox.net> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> Message-ID: <4B84AE9C.3080902@gmail.com> On 2/23/2010 6:05 PM, Lawson English wrote: > Vex Streeter wrote: >> Soft Linden wrote: >>> On Tue, Feb 23, 2010 at 2:21 PM, Mike Dickson >>> wrote: >>>> On 02/23/2010 02:16 PM, Gigs wrote: >>>>> http://secondlife.com/corporate/tpv.php >>>>> >>>>> You all realize this is massively incompatible with the GPL, right? >>>>> >>>> Not at all. They're not restricting access to the code. They're >>>> restricting access to their service. And defining the terms under >>>> which >>>> that service is provided. >>> >>> Mike's correct. >>> >>> If you see any wording that's ambiguous about that, let us know. >> Section 1c unambiguously imposes a GPL-incompatible download and/or >> installation requirement that is unrelated to the use of the software >> with the SL grid(s). > > > > The preamble specifically states that the policy only applies to > viewers meant to be used by SL. In essence, LL reserves the right to > deny access to viewers that don meet their requirements. But that isn't what the policy says: 1. Required Functionality and Disclosures If you are a Developer of Third-Party Viewers, we require the following of all Third-Party Viewers: ... c. On your software download page or in another location that a user must visit before installing the Third-Party Viewer, you must disclose the following: [1.c.i - 1.c.v contents don't matter at all to the GPL] These are constraints which explicitly place new unconditional restrictions on the _delivery_of_software_ (derivative works of the SL viewer codebase) by third party developers to end-users and downstream developers, *not* constraints on connecting to LL's services. This is one of the mechanisms (if not the content) of constraint that FSF carefully designed GPL to discourage. > MY concern is about prototyping viewers. I can certainly add a thing > to timestamp a version string during login, but with smalltalk, I'm > constantly tweaking the code *while* I'm connected to SL. Does this > mean I have to log out every time I modify something in my squeak > client just so I can change the version string? > > Even if I don't change the SL viewer code, but only something else in > the Squeak image, its still part of the same application due to how > Smalltalk works. So any time I'm connected to SL using smalltalk, and > I play with the workspace to test a new one-liner, I'm effectively > changing the viewer code, and must log out and back in with a new > version string... > > Only partly joking here. Taking this policy to its extreme may sound > silly, but people are correct: its poorly worded. heh - then client-side scripting (of whichever varieties) will be generally problematic, as will any users of the media api. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/e2df914e/attachment.htm From merov at lindenlab.com Tue Feb 23 20:57:30 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 23 Feb 2010 20:57:30 -0800 Subject: [opensource-dev] Snowglobe 2 and Open Source In-Reply-To: <46D25999-07A5-416A-B653-A0CC1FF4861A@gmail.com> References: <46D25999-07A5-416A-B653-A0CC1FF4861A@gmail.com> Message-ID: <78f69851002232057s51ebf305j989ed5c99e771c77@mail.gmail.com> On Tue, Feb 23, 2010 at 6:19 PM, Trilo Byte wrote: > Awesome to see something posted so quickly (though huge shame that testing > resources like this group and BSI weren't utilized). > > Can't help but notice we've lost some functionality from Snowglobe 1.3.... > namely the drop down to choose the user name on login, and panning around > the mini-map. What else from recent builds may have been > lost/skipped/thrown away? > Well, we "lost" more than that (SOCKS5 support, translator and OGP-Login are *big* on my todo list), but they are not lost really: I haven't had time to merge *everything*, especially the trickiest / UI related features. The plan though is to get those in there too! Just hang in there... Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/8b5445f5/attachment.htm From imaze.rhiano at gmail.com Tue Feb 23 21:08:06 2010 From: imaze.rhiano at gmail.com (Imaze Rhiano) Date: Wed, 24 Feb 2010 07:08:06 +0200 Subject: [opensource-dev] So what happens if.... Message-ID: <4B84B436.4050609@gmail.com> First I want to thank LL from efforts to create ethical guidelines for respectable viewers. Unfortunately I don't think that these rules are going to work in reality where we are living.(And as others have already pointed out - there might be incompatible with GPL and other licenses.) Let's imagine one moment that instead of being ebil bitch I would be respectable software developer and create my own viewer that fully confirms policy. I would register my viewer to your viewer directory. Now - one of following scenarios would happen - what I should do - and what would be LL's reaction: 1) My viewer is open sourced. Some evil person(s) take source code and add functionality that breaks policy. They don't bother to change viewer's id or other identification data. 2) My viewer have plugin framework that allows 3rd party developers to create their own plugins. One evil person then writes plugin that is breaking rules of viewer policy. 3) Evil persons will develop proxy or software hook that will steal data directly from data stream between client and LL servers - or - communications between viewer's host module and DLLs. Proxy / hook is completely transparent - neither client or server can detect it. 4) I will develop closed source viewer and evil persons will develop their own evil viewer. Then they decide to fake my viewer's identification data so that server thinks that their evil viewer is my viewer. From nexisentertainment at gmail.com Tue Feb 23 21:37:37 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Tue, 23 Feb 2010 21:37:37 -0800 Subject: [opensource-dev] So what happens if.... In-Reply-To: <4B84B436.4050609@gmail.com> References: <4B84B436.4050609@gmail.com> Message-ID: <1266989857.3694.4330.camel@RAGE> >From my reading, you get banned in all four cases, since you automatically take responsibility for the users' activities (Section 7 3PVP). On Wed, 2010-02-24 at 07:08 +0200, Imaze Rhiano wrote: > First I want to thank LL from efforts to create ethical guidelines for > respectable viewers. Unfortunately I don't think that these rules are > going to work in reality where we are living.(And as others have already > pointed out - there might be incompatible with GPL and other licenses.) > > Let's imagine one moment that instead of being ebil bitch I would be > respectable software developer and create my own viewer that fully > confirms policy. I would register my viewer to your viewer directory. > Now - one of following scenarios would happen - what I should do - and > what would be LL's reaction: > > 1) My viewer is open sourced. Some evil person(s) take source code and > add functionality that breaks policy. They don't bother to change > viewer's id or other identification data. > > 2) My viewer have plugin framework that allows 3rd party developers to > create their own plugins. One evil person then writes plugin that is > breaking rules of viewer policy. > > 3) Evil persons will develop proxy or software hook that will steal data > directly from data stream between client and LL servers - or - > communications between viewer's host module and DLLs. Proxy / hook is > completely transparent - neither client or server can detect it. > > 4) I will develop closed source viewer and evil persons will develop > their own evil viewer. Then they decide to fake my viewer's > identification data so that server thinks that their evil viewer is my > viewer. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From merov at lindenlab.com Tue Feb 23 21:45:56 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 23 Feb 2010 21:45:56 -0800 Subject: [opensource-dev] Snowglobe 2 update Message-ID: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> Hi, So, Snowglobe 2 is out there and ready to build/hack. Well, almost. What we have today is basically the Viewer 2.0 beta source code + all the Snowglobe branding on top of it but lots of Snowglobe specific features are still missing. Before I go into the details of what's left to be done (and where you can help), some pointers to orient yourself: - svn : the code is available off : https://svn.secondlife.com/svn/linden/projects/2010/snowglobe/trunk I choose svn over hg uniquely for practical reasons: we needed to go through an export script anyway so rewriting the export for hg while keeping the rest unchanged was a time saver. It'll also make merge from Snowglobe 1.3 based trunk easier (svn to svn merge). - bundles: they are posted on : http://wiki.secondlife.com/wiki/Source_downloads The usual stuff, no change from the old 1.3 code base (artwork, libs and source tarballs if you don't like svn) At that point, building should be no different from before. If you use develop.py, it should be a piece of cake. For the sake of completeness though, I'm doing right now a build "from scratch" on Mac so I'll catch anything that I may have missed in the svn commit this afternoon. Since I had to work around some unexpected svn crashes, I did some commit manually and may have missed something. Let me know if you see something going awry on Windows or Linux. For those of you compiling standalone and/or on Linux 64: I have *not* done *any* build using those configurations. I did merge some of the build changes when doing the branding merge but, without building myself, I'm sure I missed some important things. For those issues, please discuss here or, better, log a PJIRA and discuss there or attach a patch (please set "Affect version" to "Snowglobe 2.0"). You'll see that, though lots of files are new, most of the structure of the code base hasn't changed that much. - What needs to be done Now we have the code out, what's next? 2 categories of things: - Scripts and build: I still have unfinished or hacky scripts on the internal side of things that I need to polish and push to the main trunk so that updates are easier. In particular, I need to make sure the automated build on the public branch works again. - Snowglobe features merge: I haven't merged all the things we've been doing in 2009. Lots of those biggest things we did in Snowglobe though are now in Viewer 2.0 so won't need to be merged. Some of the big features though are: - OGP-Login: Pixelq already volunteered to help merge that back - SOCKS5: here, Robin volunteered - Chat translator: for that one, that would be nice if someone would volunteer to do the merge - Login drop down: same I think I can take care of the other small fixes especially since I have access to the internal JIRA that details which ones have been merged in the Viewer 2.0. It's a little tedious work but not fundamentally hard. I think it'll take me a couple of weeks to get all that in (that plus finishing the script) - How you can help As usual: testing, building and submitting patches :) PJIRA is open. Please set "Affect version" to "Snowglobe 2.0" for bugs found on that code base. Snowglobe 2.0 and Viewer 2.0 are still very much young and starting and need our collective care. I'm very happy personally to have Snowglobe now tracking the main viewer (and getting out of the business of doing cherry pick merges of huge feature sets...) so that our effort here can get to the main viewer faster while we still maintain the freedom to experiment. I'm really looking forward for more innovative Snowglobe developments now we're back tracking the main code base. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/d5c6f717/attachment.htm From tigrospottystripes at gmail.com Tue Feb 23 21:46:11 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 24 Feb 2010 02:46:11 -0300 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B84AE9C.3080902@gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> Message-ID: <4B84BD23.8080009@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 is the policy just a set of requisites for a client to be included in the list LL will have on their site or to be allowed to connect to Agni at all? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuEvRgACgkQ8ZFfSrFHsmU1iwCfdWe7xzvnegSrZm1ApcPiR13C 2CIAn2ho4G5QXImDU5R8aiYqp5g7U9vE =7GmR -----END PGP SIGNATURE----- From marinekelley at gmail.com Tue Feb 23 23:50:54 2010 From: marinekelley at gmail.com (Marine Kelley) Date: Wed, 24 Feb 2010 08:50:54 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B84BD23.8080009@Gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100224/a415d34c/attachment.htm From gareth at garethnelson.com Tue Feb 23 23:57:08 2010 From: gareth at garethnelson.com (Gareth Nelson) Date: Wed, 24 Feb 2010 07:57:08 +0000 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B84BD23.8080009@Gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> Message-ID: <4ebfc1101002232357v606f3915tbbd55358c09b413a@mail.gmail.com> I have a strong urge to produce a viewer which violates this policy, relying solely on the rights granted by the existing GPL. I will never use this viewer myself to login to SL, and thus reject any of these terms. Any developers who object to this policy should follow suit. A few questions: If I distribute a viewer which violates this policy but refuses to login to any LL-owned grids, and one of my users modifies it to do so, would you attempt to hold me liable? If I was to close all my SL accounts today (probably won't actually, but it's a thought experiment) and distribute a viewer that breaks this policy, would you attempt to hold me liable? I say "attempt", because I see no way LL could do so without the TOS binding me (the only possible way this policy could be enforced - and even then some lawyer type may be able to make a case against it). Should be fine though, the policy states at the top that it essentially only matters for people using the viewer to connect. My question is if I develop a policy-breaking viewer for use on other grids and simply neglect to add an if(grid=='agni') refuse_connection() statement, will you be holding my users liable or me? Assuming I never use it myself to connect to an LL-owned grid On Wed, Feb 24, 2010 at 5:46 AM, Tigro Spottystripes wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > is the policy just a set of requisites for a client to be included in > the list LL will have on their site or to be allowed to connect to Agni > at all? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.12 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkuEvRgACgkQ8ZFfSrFHsmU1iwCfdWe7xzvnegSrZm1ApcPiR13C > 2CIAn2ho4G5QXImDU5R8aiYqp5g7U9vE > =7GmR > -----END PGP SIGNATURE----- > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > -- ?Lanie, I?m going to print more printers. Lots more printers. One for everyone. That?s worth going to jail for. That?s worth anything.? - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From skidz.tweak at gmail.com Wed Feb 24 00:06:33 2010 From: skidz.tweak at gmail.com (Skidz Tweak) Date: Wed, 24 Feb 2010 02:06:33 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B8437AC.30004@gmail.com> References: <4B8437AC.30004@gmail.com> Message-ID: <4b84de0e.0d0bca0a.6fba.4143@mx.google.com> 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-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Gigs Sent: Tuesday, February 23, 2010 2:17 PM To: opensource-dev at 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 From sempuki1 at gmail.com Wed Feb 24 00:08:38 2010 From: sempuki1 at gmail.com (Ryan McDougall) Date: Wed, 24 Feb 2010 10:08:38 +0200 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> Message-ID: 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, From thomas.shikami at online.de Wed Feb 24 00:26:12 2010 From: thomas.shikami at online.de (Thomas Shikami) Date: Wed, 24 Feb 2010 09:26:12 +0100 Subject: [opensource-dev] Snowglobe 2 update In-Reply-To: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> References: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> Message-ID: <4B84E2A4.7080708@online.de> 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 From lenglish5 at cox.net Wed Feb 24 00:43:58 2010 From: lenglish5 at cox.net (Lawson English) Date: Wed, 24 Feb 2010 01:43:58 -0700 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> Message-ID: <4B84E6CE.3040600@cox.net> 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 From dahliatrimble at gmail.com Wed Feb 24 00:48:59 2010 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 24 Feb 2010 00:48:59 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B84E6CE.3040600@cox.net> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <4B84E6CE.3040600@cox.net> Message-ID: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100224/efa0fc69/attachment.htm From Lance.Corrimal at eregion.de Wed Feb 24 00:51:50 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 24 Feb 2010 09:51:50 +0100 Subject: [opensource-dev] Snowglobe 2 update In-Reply-To: <4B84E2A4.7080708@online.de> References: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> <4B84E2A4.7080708@online.de> Message-ID: <201002240951.50605.Lance.Corrimal@eregion.de> 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 From Lance.Corrimal at eregion.de Wed Feb 24 00:52:08 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 24 Feb 2010 09:52:08 +0100 Subject: [opensource-dev] "Resposibility" - Third party viewer policy Message-ID: <201002240952.08231.Lance.Corrimal@eregion.de> 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 From marinekelley at gmail.com Wed Feb 24 01:00:44 2010 From: marinekelley at gmail.com (Marine Kelley) Date: Wed, 24 Feb 2010 10:00:44 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <4B84E6CE.3040600@cox.net> Message-ID: <2957FB50-619A-4116-8730-34F14A98FDA8@gmail.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100224/6d84ee86/attachment.htm From dahliatrimble at gmail.com Wed Feb 24 01:03:40 2010 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 24 Feb 2010 01:03:40 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <2957FB50-619A-4116-8730-34F14A98FDA8@gmail.com> References: <4B8437AC.30004@gmail.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <4B84E6CE.3040600@cox.net> <2957FB50-619A-4116-8730-34F14A98FDA8@gmail.com> Message-ID: 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 < > lenglish5 at 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100224/f7136c02/attachment-0001.htm From robin.cornelius at gmail.com Wed Feb 24 01:06:20 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed, 24 Feb 2010 09:06:20 +0000 Subject: [opensource-dev] Snowglobe 2 and Open Source In-Reply-To: <46D25999-07A5-416A-B653-A0CC1FF4861A@gmail.com> References: <46D25999-07A5-416A-B653-A0CC1FF4861A@gmail.com> Message-ID: 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 From Lance.Corrimal at eregion.de Wed Feb 24 01:14:13 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 24 Feb 2010 10:14:13 +0100 Subject: [opensource-dev] Snowglobe 2 and Open Source In-Reply-To: References: <46D25999-07A5-416A-B653-A0CC1FF4861A@gmail.com> Message-ID: <201002241014.13857.Lance.Corrimal@eregion.de> 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 From Lance.Corrimal at eregion.de Wed Feb 24 01:18:54 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 24 Feb 2010 10:18:54 +0100 Subject: [opensource-dev] Snowglobe 2 update In-Reply-To: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> References: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> Message-ID: <201002241018.54455.Lance.Corrimal@eregion.de> 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 From robin.cornelius at gmail.com Wed Feb 24 01:43:53 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed, 24 Feb 2010 09:43:53 +0000 Subject: [opensource-dev] Snowglobe 2 update In-Reply-To: <201002241018.54455.Lance.Corrimal@eregion.de> References: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> <201002241018.54455.Lance.Corrimal@eregion.de> Message-ID: 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 From sempuki1 at gmail.com Wed Feb 24 02:58:11 2010 From: sempuki1 at gmail.com (Ryan McDougall) Date: Wed, 24 Feb 2010 12:58:11 +0200 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: 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, From thomas.shikami at online.de Wed Feb 24 03:10:56 2010 From: thomas.shikami at online.de (Thomas Shikami) Date: Wed, 24 Feb 2010 12:10:56 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: <4B850940.70503@online.de> 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. From sempuki1 at gmail.com Wed Feb 24 03:16:28 2010 From: sempuki1 at gmail.com (Ryan McDougall) Date: Wed, 24 Feb 2010 13:16:28 +0200 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B850940.70503@online.de> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B850940.70503@online.de> Message-ID: 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, From lenglish5 at cox.net Wed Feb 24 03:17:09 2010 From: lenglish5 at cox.net (Lawson English) Date: Wed, 24 Feb 2010 04:17:09 -0700 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: <4B850AB5.2000205@cox.net> 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 From secret.argent at gmail.com Wed Feb 24 03:49:01 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 24 Feb 2010 05:49:01 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> 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. From secret.argent at gmail.com Wed Feb 24 04:11:01 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 24 Feb 2010 06:11:01 -0600 Subject: [opensource-dev] Snowglobe 2 update In-Reply-To: <4B84E2A4.7080708@online.de> References: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> <4B84E2A4.7080708@online.de> Message-ID: <20400C19-E4F1-402E-995D-EAC3CC2480CE@gmail.com> 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. From maggie at matrisync.com Wed Feb 24 06:12:24 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Wed, 24 Feb 2010 09:12:24 -0500 Subject: [opensource-dev] So what happens if.... In-Reply-To: <4B84B436.4050609@gmail.com> References: <4B84B436.4050609@gmail.com> Message-ID: 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. From smcculley at gmail.com Wed Feb 24 06:28:23 2010 From: smcculley at gmail.com (Scott McCulley) Date: Wed, 24 Feb 2010 08:28:23 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> Message-ID: <1D44A821-0C91-4DB2-A39C-4D839ADD7DE4@gmail.com> 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. From dzonatas at gmail.com Wed Feb 24 06:46:03 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Wed, 24 Feb 2010 06:46:03 -0800 Subject: [opensource-dev] DRM vs TOS Was: Third party viewer policy In-Reply-To: <4B850AB5.2000205@cox.net> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B850AB5.2000205@cox.net> Message-ID: <4B853BAB.2050204@gmail.com> 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. From anders at arnholm.se Wed Feb 24 06:33:20 2010 From: anders at arnholm.se (Anders Arnholm) Date: Wed, 24 Feb 2010 15:33:20 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <1D44A821-0C91-4DB2-A39C-4D839ADD7DE4@gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <1D44A821-0C91-4DB2-A39C-4D839ADD7DE4@gmail.com> Message-ID: <4B8538B0.50706@arnholm.se> -----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. From gigstaggart at gmail.com Wed Feb 24 06:34:34 2010 From: gigstaggart at gmail.com (Gigs) Date: Wed, 24 Feb 2010 09:34:34 -0500 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B850AB5.2000205@cox.net> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B850AB5.2000205@cox.net> Message-ID: <4B8538FA.6010806@gmail.com> 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. From gareth at garethnelson.com Wed Feb 24 07:24:30 2010 From: gareth at garethnelson.com (Gareth Nelson) Date: Wed, 24 Feb 2010 15:24:30 +0000 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B8538FA.6010806@gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B850AB5.2000205@cox.net> <4B8538FA.6010806@gmail.com> Message-ID: <4ebfc1101002240724u39005ddfse8c5c44aaa7b9f0d@mail.gmail.com> 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 From gigstaggart at gmail.com Wed Feb 24 07:27:50 2010 From: gigstaggart at gmail.com (Gigs) Date: Wed, 24 Feb 2010 10:27:50 -0500 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses Message-ID: <4B854576.6050006@gmail.com> 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. From gareth at garethnelson.com Wed Feb 24 07:28:15 2010 From: gareth at garethnelson.com (Gareth Nelson) Date: Wed, 24 Feb 2010 15:28:15 +0000 Subject: [opensource-dev] So what happens if.... In-Reply-To: References: <4B84B436.4050609@gmail.com> Message-ID: <4ebfc1101002240728w5fb2fb2ene56949bc73f3f366@mail.gmail.com> 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 From vexstreeter at gmail.com Wed Feb 24 07:35:07 2010 From: vexstreeter at gmail.com (Vex Streeter) Date: Wed, 24 Feb 2010 10:35:07 -0500 Subject: [opensource-dev] "Resposibility" - Third party viewer policy In-Reply-To: <201002240952.08231.Lance.Corrimal@eregion.de> References: <201002240952.08231.Lance.Corrimal@eregion.de> Message-ID: <4B85472B.5020804@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100224/0de50e4d/attachment.htm From matrice64 at gmail.com Wed Feb 24 07:49:29 2010 From: matrice64 at gmail.com (Matrice64) Date: Wed, 24 Feb 2010 09:49:29 -0600 Subject: [opensource-dev] Snowglobe 2 update In-Reply-To: <20400C19-E4F1-402E-995D-EAC3CC2480CE@gmail.com> References: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> <4B84E2A4.7080708@online.de> <20400C19-E4F1-402E-995D-EAC3CC2480CE@gmail.com> Message-ID: 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 > From tigrospottystripes at gmail.com Wed Feb 24 08:21:15 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 24 Feb 2010 13:21:15 -0300 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <1D44A821-0C91-4DB2-A39C-4D839ADD7DE4@gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <1D44A821-0C91-4DB2-A39C-4D839ADD7DE4@gmail.com> Message-ID: <4B8551FB.8060206@Gmail.com> -----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----- From gigstaggart at gmail.com Wed Feb 24 09:07:17 2010 From: gigstaggart at gmail.com (Gigs) Date: Wed, 24 Feb 2010 12:07:17 -0500 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <4B8553EC.7060707@tpg.com.au> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> Message-ID: <4B855CC5.1060504@gmail.com> 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. From mike.dickson at hp.com Wed Feb 24 09:24:48 2010 From: mike.dickson at hp.com (Mike Dickson) Date: Wed, 24 Feb 2010 11:24:48 -0600 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <4B855CC5.1060504@gmail.com> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> Message-ID: <4B8560E0.7060306@hp.com> 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 From lenglish5 at cox.net Wed Feb 24 09:30:14 2010 From: lenglish5 at cox.net (Lawson English) Date: Wed, 24 Feb 2010 10:30:14 -0700 Subject: [opensource-dev] DRM vs TOS Was: Third party viewer policy In-Reply-To: <4B853BAB.2050204@gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B850AB5.2000205@cox.net> <4B853BAB.2050204@gmail.com> Message-ID: <4B856226.50404@cox.net> 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 From gigstaggart at gmail.com Wed Feb 24 09:40:10 2010 From: gigstaggart at gmail.com (Gigs) Date: Wed, 24 Feb 2010 12:40:10 -0500 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <4B8560E0.7060306@hp.com> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> <4B8560E0.7060306@hp.com> Message-ID: <4B85647A.1030301@gmail.com> 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 From soft at lindenlab.com Wed Feb 24 11:07:38 2010 From: soft at lindenlab.com (Soft Linden) Date: Wed, 24 Feb 2010 13:07:38 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: 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. From soft at lindenlab.com Wed Feb 24 11:16:45 2010 From: soft at lindenlab.com (Soft Linden) Date: Wed, 24 Feb 2010 13:16:45 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> Message-ID: 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. From soft at lindenlab.com Wed Feb 24 11:18:20 2010 From: soft at lindenlab.com (Soft Linden) Date: Wed, 24 Feb 2010 13:18:20 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: 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. From soft at lindenlab.com Wed Feb 24 11:23:06 2010 From: soft at lindenlab.com (Soft Linden) Date: Wed, 24 Feb 2010 13:23:06 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: 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. From dzonatas at gmail.com Wed Feb 24 11:46:48 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Wed, 24 Feb 2010 11:46:48 -0800 Subject: [opensource-dev] DRM vs TOS Was: Third party viewer policy In-Reply-To: <4B856226.50404@cox.net> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B850AB5.2000205@cox.net> <4B853BAB.2050204@gmail.com> <4B856226.50404@cox.net> Message-ID: <4B858228.6030602@gmail.com> 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. From tigrospottystripes at gmail.com Wed Feb 24 11:38:49 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 24 Feb 2010 16:38:49 -0300 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: <4B858049.5060004@Gmail.com> -----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----- From soft at lindenlab.com Wed Feb 24 11:40:46 2010 From: soft at lindenlab.com (Soft Linden) Date: Wed, 24 Feb 2010 13:40:46 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: 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. From schlenk at uni-oldenburg.de Wed Feb 24 11:57:55 2010 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Wed, 24 Feb 2010 20:57:55 +0100 Subject: [opensource-dev] Snowglobe 2 update In-Reply-To: <201002240951.50605.Lance.Corrimal@eregion.de> References: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> <4B84E2A4.7080708@online.de> <201002240951.50605.Lance.Corrimal@eregion.de> Message-ID: <57A14FE6-1763-4136-AE01-C640A0EA29E6@uni-oldenburg.de> 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 From malachi at tamzap.com Wed Feb 24 12:21:47 2010 From: malachi at tamzap.com (malachi) Date: Wed, 24 Feb 2010 15:21:47 -0500 Subject: [opensource-dev] Request for help on compiling Snowglobe In-Reply-To: <57A14FE6-1763-4136-AE01-C640A0EA29E6@uni-oldenburg.de> References: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> <4B84E2A4.7080708@online.de> <201002240951.50605.Lance.Corrimal@eregion.de> <57A14FE6-1763-4136-AE01-C640A0EA29E6@uni-oldenburg.de> Message-ID: <4B858A5B.9060605@tamzap.com> 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. From sempuki1 at gmail.com Wed Feb 24 12:46:11 2010 From: sempuki1 at gmail.com (Ryan McDougall) Date: Wed, 24 Feb 2010 22:46:11 +0200 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: 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, From marinekelley at gmail.com Wed Feb 24 12:47:09 2010 From: marinekelley at gmail.com (Marine Kelley) Date: Wed, 24 Feb 2010 21:47:09 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> Message-ID: <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100224/8160665e/attachment.htm From soft at lindenlab.com Wed Feb 24 13:21:45 2010 From: soft at lindenlab.com (Soft Linden) Date: Wed, 24 Feb 2010 15:21:45 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> Message-ID: 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. From cjac at colliertech.org Tue Feb 23 14:21:06 2010 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Tue, 23 Feb 2010 14:21:06 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B8437AC.30004@gmail.com> References: <4B8437AC.30004@gmail.com> Message-ID: <1266963666.5756.0.camel@calcifer> Are you sure? I'd think that denying connection to their services would not be limited in any way by the GPL. But IANAL. On Tue, 2010-02-23 at 15:16 -0500, Gigs wrote: > http://secondlife.com/corporate/tpv.php > > You all realize this is massively incompatible with the GPL, right? > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/9a5788cd/attachment-0002.pgp From cjac at colliertech.org Tue Feb 23 14:23:01 2010 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Tue, 23 Feb 2010 14:23:01 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: <1266963781.5756.1.camel@calcifer> The Debian (Sun) Java runtime package has such an agreement requirement or did at one point. On Tue, 2010-02-23 at 20:37 +0000, Robin Cornelius wrote: > On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden wrote: > > Mike's correct. > > > > If you see any wording that's ambiguous about that, let us know. > > _______________________________________________ > > > Well you seem to have spelled the end of my debian/ubuntu project, I > can not meet the tems of the third party viewer policy:- > > "On your software download page or in another location that a user > must visit before installing the Third-Party Viewer, you must disclose > the following:" > > I cannot do this with an apt-repository, the user can bypass every > possible webpage or description field. and the fact the policy says > this is a MUST. The only possible way to do this is to create a custom > program that displays a screen during the install hook of the package > and aborts the package install. This can no longer be accepted in to > the main debian or ubuntu repositories. > > Also it appears that i cannot use the snowglobe logo or name, even > though i'm basicly building from almost prestine source. I though this > was the entire point of the snowglobe rebranding, but now we are > exactly where we were with secondlife 12 months ago. > > Robin > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/6a296f3e/attachment-0002.pgp From morgaine.dinova at googlemail.com Wed Feb 24 14:30:52 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Wed, 24 Feb 2010 22:30:52 +0000 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> Message-ID: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100224/f5f9d63c/attachment-0001.htm From tayra.dagostino at gmail.com Wed Feb 24 15:13:24 2010 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Thu, 25 Feb 2010 00:13:24 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> Message-ID: <20100225001324.8d6fa7db.tayra.dagostino@gmail.com> On Wed, 24 Feb 2010 22:30:52 +0000 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... From tshephard at gmail.com Wed Feb 24 15:17:07 2010 From: tshephard at gmail.com (Tim Shephard) Date: Wed, 24 Feb 2010 15:17:07 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <20100225001324.8d6fa7db.tayra.dagostino@gmail.com> References: <4B8437AC.30004@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> <20100225001324.8d6fa7db.tayra.dagostino@gmail.com> Message-ID: <3b19a501002241517l207eaa0fs5af207c7999960e6@mail.gmail.com> > i'm not a lawyer.... but restriction are about Linden services... not > viewer source code.. Yes, that's how I read it as well. From Lance.Corrimal at eregion.de Wed Feb 24 15:17:45 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 25 Feb 2010 00:17:45 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> Message-ID: <201002250017.46036.Lance.Corrimal@eregion.de> 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 From dale at daleglass.net Wed Feb 24 15:21:20 2010 From: dale at daleglass.net (Dale Glass) Date: Thu, 25 Feb 2010 02:21:20 +0300 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> Message-ID: <201002250221.20676.dale@daleglass.net> ? ????????? ?? ??????? 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. From sldev at free.fr Wed Feb 24 15:34:17 2010 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 25 Feb 2010 00:34:17 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> Message-ID: <20100225003417.b0e52a55.sldev@free.fr> 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. From danteferret at gmail.com Wed Feb 24 15:35:04 2010 From: danteferret at gmail.com (Peter Leonard/Dante) Date: Wed, 24 Feb 2010 18:35:04 -0500 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <201002250221.20676.dale@daleglass.net> References: <4B8437AC.30004@gmail.com> <201002250221.20676.dale@daleglass.net> Message-ID: <4d211a611002241535v2d46b1ecoe6da80df957709ce@mail.gmail.com> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100224/67a1415b/attachment.htm From soft at lindenlab.com Wed Feb 24 15:58:21 2010 From: soft at lindenlab.com (Soft Linden) Date: Wed, 24 Feb 2010 17:58:21 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> Message-ID: 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. From carlo at alinoe.com Wed Feb 24 16:00:57 2010 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 25 Feb 2010 01:00:57 +0100 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: References: <20100221104527.GA29762@alinoe.com> <4B81D66E.7040902@gmail.com> <20100222235643.GB19219@alinoe.com> Message-ID: <20100225000057.GA9728@alinoe.com> On Tue, Feb 23, 2010 at 03:10:55PM +0000, 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 From soft at lindenlab.com Wed Feb 24 16:12:04 2010 From: soft at lindenlab.com (Soft Linden) Date: Wed, 24 Feb 2010 18:12:04 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> Message-ID: 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. From carlo at alinoe.com Wed Feb 24 16:12:46 2010 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 25 Feb 2010 01:12:46 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <769bb4301002231245x17272f34h88eca06115b8a406@mail.gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <769bb4301002231245x17272f34h88eca06115b8a406@mail.gmail.com> Message-ID: <20100225001246.GB9728@alinoe.com> 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 From carlo at alinoe.com Wed Feb 24 16:16:01 2010 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 25 Feb 2010 01:16:01 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <14adf3371002231316n6092e40ahde237fa7d3e760bd@mail.gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <14adf3371002231316n6092e40ahde237fa7d3e760bd@mail.gmail.com> Message-ID: <20100225001601.GC9728@alinoe.com> 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 From gigstaggart at gmail.com Wed Feb 24 16:23:36 2010 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed, 24 Feb 2010 19:23:36 -0500 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> Message-ID: <4B85C308.8030101@gmail.com> 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 From gigstaggart at gmail.com Wed Feb 24 16:27:52 2010 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed, 24 Feb 2010 19:27:52 -0500 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <201002250221.20676.dale@daleglass.net> References: <4B8437AC.30004@gmail.com> <201002250221.20676.dale@daleglass.net> Message-ID: <4B85C408.3050201@gmail.com> 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 From snowfox102 at dragonkeepcreations.com Wed Feb 24 16:27:57 2010 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Wed, 24 Feb 2010 18:27:57 -0600 Subject: [opensource-dev] Viewer 2.0 JIRA - Classic UI option Message-ID: <4B85C40D.6080607@dragonkeepcreations.com> 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 From gigstaggart at gmail.com Wed Feb 24 16:31:12 2010 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed, 24 Feb 2010 19:31:12 -0500 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <20100225001246.GB9728@alinoe.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <769bb4301002231245x17272f34h88eca06115b8a406@mail.gmail.com> <20100225001246.GB9728@alinoe.com> Message-ID: <4B85C4D0.50607@gmail.com> 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 From soft at lindenlab.com Wed Feb 24 16:32:24 2010 From: soft at lindenlab.com (Soft Linden) Date: Wed, 24 Feb 2010 18:32:24 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B85C308.8030101@gmail.com> References: <4B8437AC.30004@gmail.com> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> <4B85C308.8030101@gmail.com> Message-ID: 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. From carlo at alinoe.com Wed Feb 24 16:43:25 2010 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 25 Feb 2010 01:43:25 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B845F55.7070808@cox.net> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> Message-ID: <20100225004325.GD9728@alinoe.com> 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 From tigrospottystripes at gmail.com Wed Feb 24 16:56:37 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 24 Feb 2010 21:56:37 -0300 Subject: [opensource-dev] Fwd: Third party viewer policy Message-ID: <4B85CAC5.3030504@Gmail.com> -----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----- From darmath at tpg.com.au Wed Feb 24 17:10:23 2010 From: darmath at tpg.com.au (Darmath) Date: Thu, 25 Feb 2010 12:10:23 +1100 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <4B85C980.5050900@tpg.com.au> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> <4B85C980.5050900@tpg.com.au> Message-ID: <4B85CDFF.9070902@tpg.com.au> 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 > > > > > > From darmath at tpg.com.au Wed Feb 24 17:33:09 2010 From: darmath at tpg.com.au (Darmath) Date: Thu, 25 Feb 2010 12:33:09 +1100 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <4B85CDFF.9070902@tpg.com.au> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> <4B85C980.5050900@tpg.com.au> <4B85CDFF.9070902@tpg.com.au> Message-ID: <4B85D355.3050608@tpg.com.au> 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 >> >> >> >> >> >> >> > > _______________________________________________ > 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 > > From gigstaggart at gmail.com Wed Feb 24 17:53:50 2010 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed, 24 Feb 2010 20:53:50 -0500 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <4B85D355.3050608@tpg.com.au> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> <4B85C980.5050900@tpg.com.au> <4B85CDFF.9070902@tpg.com.au> <4B85D355.3050608@tpg.com.au> Message-ID: <4B85D82E.3080203@gmail.com> 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. From gigstaggart at gmail.com Wed Feb 24 17:57:40 2010 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed, 24 Feb 2010 20:57:40 -0500 Subject: [opensource-dev] Summary of TPV concerns Message-ID: <4B85D914.9050705@gmail.com> 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. From darmath at tpg.com.au Wed Feb 24 17:55:29 2010 From: darmath at tpg.com.au (Darmath) Date: Thu, 25 Feb 2010 12:55:29 +1100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> Message-ID: <4B85D891.1030706@tpg.com.au> 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 From latifer at streamgrid.net Wed Feb 24 18:19:04 2010 From: latifer at streamgrid.net (Latif Khalifa) Date: Thu, 25 Feb 2010 03:19:04 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> Message-ID: <5ebce2ec1002241819x31d0e7dbj574feaa3292d4ccb@mail.gmail.com> 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. From brent.tubbs at gmail.com Wed Feb 24 18:24:18 2010 From: brent.tubbs at gmail.com (Brent Tubbs) Date: Wed, 24 Feb 2010 18:24:18 -0800 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <4B85D82E.3080203@gmail.com> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> <4B85C980.5050900@tpg.com.au> <4B85CDFF.9070902@tpg.com.au> <4B85D355.3050608@tpg.com.au> <4B85D82E.3080203@gmail.com> Message-ID: <769bb4301002241824v79d46247p344a457dc5ab3522@mail.gmail.com> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100224/deff87a3/attachment.htm From dzonatas at gmail.com Wed Feb 24 18:41:52 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Wed, 24 Feb 2010 18:41:52 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B85C308.8030101@gmail.com> References: <4B8437AC.30004@gmail.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> <4B85C308.8030101@gmail.com> Message-ID: <4B85E370.6070400@gmail.com> 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. From darmath at tpg.com.au Wed Feb 24 18:55:04 2010 From: darmath at tpg.com.au (Darmath) Date: Thu, 25 Feb 2010 13:55:04 +1100 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <769bb4301002241824v79d46247p344a457dc5ab3522@mail.gmail.com> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> <4B85C980.5050900@tpg.com.au> <4B85CDFF.9070902@tpg.com.au> <4B85D355.3050608@tpg.com.au> <4B85D82E.3080203@gmail.com> <769bb4301002241824v79d46247p344a457dc5ab3522@mail.gmail.com> Message-ID: <4B85E688.8060306@tpg.com.au> 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 constitute a contract is to consider the position of the licensee where the licensor of the copyright content decided that they would repudiate the license agreement unlawfully. Are you going to try and suggest to me that the licensee has no legal recourse? No i dont think you will. And if you accept that the licensee must have a legal recourse than ask yourself what will the basis of their action be? Well surely that to me sounds like an action based upon the legal agreement that the licensee and licensor entered into that gave the licensee the rights to act in relation to the property? If it wasn't a contract there would be no legal recourse at all. In otherwords why is it that the transfer of rights to act with respect to the property was effective at all. Sure the legislation of the relevant jurisidiction creates certain statutory licenses but the type of license, that we are discussing is not one, as I understand it, is not one that could be regarded as a statutory license of any sort. Kind regards Darren From gigstaggart at gmail.com Wed Feb 24 19:27:58 2010 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed, 24 Feb 2010 22:27:58 -0500 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <4B85E688.8060306@tpg.com.au> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> <4B85C980.5050900@tpg.com.au> <4B85CDFF.9070902@tpg.com.au> <4B85D355.3050608@tpg.com.au> <4B85D82E.3080203@gmail.com> <769bb4301002241824v79d46247p344a457dc5ab3522@mail.gmail.com> <4B85E688.8060306@tpg.com.au> Message-ID: <4B85EE3E.7020906@gmail.com> 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. From vector at leafpile.com Wed Feb 24 20:02:41 2010 From: vector at leafpile.com (Vector Hastings) Date: Wed, 24 Feb 2010 20:02:41 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> Message-ID: <00ce01cab5cf$60b19930$2214cb90$@com> 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-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Soft Linden Sent: Wednesday, February 24, 2010 4:12 PM To: Morgaine Cc: opensource-dev at 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 From tigrospottystripes at gmail.com Wed Feb 24 20:05:28 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 25 Feb 2010 01:05:28 -0300 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <4B85EE3E.7020906@gmail.com> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> <4B85C980.5050900@tpg.com.au> <4B85CDFF.9070902@tpg.com.au> <4B85D355.3050608@tpg.com.au> <4B85D82E.3080203@gmail.com> <769bb4301002241824v79d46247p344a457dc5ab3522@mail.gmail.com> <4B85E688.8060306@tpg.com.au> <4B85EE3E.7020906@gmail.com> Message-ID: <4B85F708.2050103@Gmail.com> -----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----- From boy.lane at yahoo.com Wed Feb 24 20:18:46 2010 From: boy.lane at yahoo.com (Boy Lane) Date: Thu, 25 Feb 2010 12:18:46 +0800 Subject: [opensource-dev] Third party viewer policy Message-ID: <001801cab5d1$a1206e90$7a00a8c0@hp> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100225/aca4977e/attachment.htm From gigstaggart at gmail.com Wed Feb 24 20:28:21 2010 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed, 24 Feb 2010 23:28:21 -0500 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <4B85F708.2050103@Gmail.com> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> <4B85C980.5050900@tpg.com.au> <4B85CDFF.9070902@tpg.com.au> <4B85D355.3050608@tpg.com.au> <4B85D82E.3080203@gmail.com> <769bb4301002241824v79d46247p344a457dc5ab3522@mail.gmail.com> <4B85E688.8060306@tpg.com.au> <4B85EE3E.7020906@gmail.com> <4B85F708.2050103@Gmail.com> Message-ID: <4B85FC65.7080808@gmail.com> 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". From tigrospottystripes at gmail.com Wed Feb 24 20:38:04 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 25 Feb 2010 01:38:04 -0300 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <4B85FC65.7080808@gmail.com> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> <4B85C980.5050900@tpg.com.au> <4B85CDFF.9070902@tpg.com.au> <4B85D355.3050608@tpg.com.au> <4B85D82E.3080203@gmail.com> <769bb4301002241824v79d46247p344a457dc5ab3522@mail.gmail.com> <4B85E688.8060306@tpg.com.au> <4B85EE3E.7020906@gmail.com> <4B85F708.2050103@Gmail.com> <4B85FC65.7080808@gmail.com> Message-ID: <4B85FEAC.8010509@Gmail.com> -----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----- From morgaine.dinova at googlemail.com Wed Feb 24 21:04:16 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Thu, 25 Feb 2010 05:04:16 +0000 Subject: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe In-Reply-To: <20100225000057.GA9728@alinoe.com> References: <20100221104527.GA29762@alinoe.com> <4B81D66E.7040902@gmail.com> <20100222235643.GB19219@alinoe.com> <20100225000057.GA9728@alinoe.com> Message-ID: 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 +0000, 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100225/80c59bb2/attachment-0001.htm From morgaine.dinova at googlemail.com Wed Feb 24 21:59:30 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Thu, 25 Feb 2010 05:59:30 +0000 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <001801cab5d1$a1206e90$7a00a8c0@hp> References: <001801cab5d1$a1206e90$7a00a8c0@hp> Message-ID: 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100225/1df5b7cd/attachment.htm From lenglish5 at cox.net Wed Feb 24 22:48:38 2010 From: lenglish5 at cox.net (Lawson English) Date: Wed, 24 Feb 2010 23:48:38 -0700 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <20100225001246.GB9728@alinoe.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <769bb4301002231245x17272f34h88eca06115b8a406@mail.gmail.com> <20100225001246.GB9728@alinoe.com> Message-ID: <4B861D46.7090506@cox.net> 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 From morgaine.dinova at googlemail.com Wed Feb 24 22:55:41 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Thu, 25 Feb 2010 06:55:41 +0000 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> Message-ID: 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100225/88de7fa5/attachment.htm From bishopj at bishopphillips.com Wed Feb 24 23:05:35 2010 From: bishopj at bishopphillips.com (Jonathan Bishop) Date: Thu, 25 Feb 2010 18:05:35 +1100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <001801cab5d1$a1206e90$7a00a8c0@hp> References: <001801cab5d1$a1206e90$7a00a8c0@hp> Message-ID: <038039041B7F47ECBE709E6B49780F31@neptune.priv> --------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 bishopj at bishopphillips.com | www.bishopphillips.com _____ From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Boy Lane Sent: Thursday, 25 February 2010 3:19 PM To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Third party viewer policy 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100225/bab5974e/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2614 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100225/bab5974e/attachment-0001.gif From Lance.Corrimal at eregion.de Wed Feb 24 23:39:24 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 25 Feb 2010 08:39:24 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> Message-ID: <201002250839.24377.Lance.Corrimal@eregion.de> 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 From sldev at free.fr Thu Feb 25 01:54:13 2010 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 25 Feb 2010 10:54:13 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B85D891.1030706@tpg.com.au> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> <4B85D891.1030706@tpg.com.au> Message-ID: <20100225105413.6ab1abf6.sldev@free.fr> On Thu, 25 Feb 2010 12:55:29 +1100, Darmath wrote: > 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. Because you can actually know who are *all* the real persons behind *any* Open Source project ?... You know, people do use pseudonyms a lot, on Internet... Anyway, no where in the GPL will you find that a developper *must* disclose their true identity. SL raises a further concern for developpers: as an adult role-playing game (yes, I know, some people think SL is not game, but it is for many), being able to put a real name behind an avatar means that you can discover the most intimate kinks of a real person. This would be a huge, unacceptable breach in this person's privacy. Henri. From darmath at tpg.com.au Thu Feb 25 02:10:21 2010 From: darmath at tpg.com.au (Darren Gansberg) Date: Thu, 25 Feb 2010 21:10:21 +1100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <20100225105413.6ab1abf6.sldev@free.fr> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> <4B85D891.1030706@tpg.com.au> <20100225105413.6ab1abf6.sldev@free.fr> Message-ID: <4B864C8D.6010503@tpg.com.au> Henri Beauchamp wrote: > > Because you can actually know who are *all* the real persons behind *any* > Open Source project ?... You know, people do use pseudonyms a lot, on > Internet... Anyway, no where in the GPL will you find that a developper > *must* disclose their true identity No of course you can't. Additionally the developer shouldn't be forced to disclose their identity. What i was taking exception with was the view that the identity of the developer is no one's business. As i said it's the users business. But the appropriate solution to the user not knowing the identity of the person responsible for writing a piece of code is for the user not to install and use that program on their system if they arent comfortable of knowing its source. That said i don't think it's necessarily a great attitude to take that your not prepared to put your identity to your own doings. And i adopt that view to all manner of things software development aside. Darren From marinekelley at gmail.com Thu Feb 25 02:33:58 2010 From: marinekelley at gmail.com (Marine Kelley) Date: Thu, 25 Feb 2010 11:33:58 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B864C8D.6010503@tpg.com.au> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> <4B85D891.1030706@tpg.com.au> <20100225105413.6ab1abf6.sldev@free.fr> <4B864C8D.6010503@tpg.com.au> Message-ID: <8FEB1EEB-1AD2-45F8-8CDE-57C396E334D7@gmail.com> Usually development and publishing companies have an anonymous contact page on their website, and no easy way of getting to know the identity of any of their employees (besides the executives). And this is for privacy and competition reasons. It should not be any different for hobbyist developers who cannot afford to throw their name in the open. Anyway there should be no question of that since you have signed up for an account or more to LL in agreement to their privacy policies in the first place. Besides, you can't find the full name of a Linden Lab employee unless they disclose it themselves (I think, maybe there is a public register somewhere or something). I don't see why we, the developers who work partly for LL at improving their platform for free, would have less rights to privacy than the people who are paid by them and who are protected. This is a non-issue anyway, most people will not agree to expose their RL identity on LL's website just to list a piece of work of theirs, unless said piece of work is required to be listed in order to be accepted on their grid. And I have not read anything anywhere that was even remotely implying such a thing. If this was required, expect most viewers to be stopped dead in their tracks. On 25 f?vr. 2010, at 11:10, Darren Gansberg wrote: > Henri Beauchamp wrote: >> >> Because you can actually know who are *all* the real persons behind >> *any* >> Open Source project ?... You know, people do use pseudonyms a lot, on >> Internet... Anyway, no where in the GPL will you find that a >> developper >> *must* disclose their true identity > No of course you can't. Additionally the developer shouldn't be forced > to disclose their identity. What i was taking exception with was the > view that the identity of the developer is no one's business. As i > said > it's the users business. But the appropriate solution to the user not > knowing the identity of the person responsible for writing a piece of > code is for the user not to install and use that program on their > system > if they arent comfortable of knowing its source. That said i don't > think > it's necessarily a great attitude to take that your not prepared to > put > your identity to your own doings. And i adopt that view to all > manner of > things software development aside. > > 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 From sldev at free.fr Thu Feb 25 02:38:19 2010 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 25 Feb 2010 11:38:19 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B864C8D.6010503@tpg.com.au> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> <4B85D891.1030706@tpg.com.au> <20100225105413.6ab1abf6.sldev@free.fr> <4B864C8D.6010503@tpg.com.au> Message-ID: <20100225113819.45d3d308.sldev@free.fr> On Thu, 25 Feb 2010 21:10:21 +1100, Darren Gansberg wrote: > Henri Beauchamp wrote: > > > > Because you can actually know who are *all* the real persons behind *any* > > Open Source project ?... You know, people do use pseudonyms a lot, on > > Internet... Anyway, no where in the GPL will you find that a developper > > *must* disclose their true identity > > No of course you can't. Additionally the developer shouldn't be forced > to disclose their identity. What i was taking exception with was the > view that the identity of the developer is no one's business. As i said > it's the users business. But the appropriate solution to the user not > knowing the identity of the person responsible for writing a piece of > code is for the user not to install and use that program on their system > if they arent comfortable of knowing its source. Knowing the source doesn't mean knowing the real person. Even an avatar got a reputation, which is directly linked to the nature of the true person behind it: users will know that this or that avatar have a good reputaion or not, and can be trusted or not, based on what their player already did under this avatar's name. Anyway, knowing the real name of a source won't give you more guarantee about this person's "trustability". With Open Source software, the guarantee comes from the fact the sources are published (making it it possible to spot malicious code), and that you can also verify (by rebuilding the porject yourself from those sources) that no additional, secret/malevolent code was inserted in the published binaries. > That said i don't think it's necessarily a great attitude to take that > your not prepared to put your identity to your own doings. And i adopt > that view to all manner of things software development aside. Even novel writers often use pseudonyms... The problem is not about not being "prepared to put your identity to your own doings", it's all about the cross referencing that search engines such as Google allow: if I put my true name behind the Cool SL Viewer, then it also means that anyone Googling that true name could find out what are my kinks (profiles are also Googled), then who I am in Real Life, what's my job, where I live, etc, etc... Would *you* be ready for this to happen to *you* ? I'm not ! Henri. From Lance.Corrimal at eregion.de Thu Feb 25 02:57:21 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 25 Feb 2010 11:57:21 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <20100225113819.45d3d308.sldev@free.fr> References: <4B8437AC.30004@gmail.com> <4B864C8D.6010503@tpg.com.au> <20100225113819.45d3d308.sldev@free.fr> Message-ID: <201002251157.21630.Lance.Corrimal@eregion.de> Am Donnerstag, 25. Februar 2010 11:38:19 schrieb Henri Beauchamp: > The problem is not about not being "prepared to put your identity to your > own doings", it's all about the cross referencing that search engines such > as Google allow: if I put my true name behind the Cool SL Viewer, then it > also means that anyone Googling that true name could find out what are my > kinks (profiles are also Googled), then who I am in Real Life, what's my > job, where I live, etc, etc... Would *you* be ready for this to happen to > *you* ? I'm not ! given the great work that you deliver with the cool viewer, me and a few sixpacks of beer wouldnt mind being able to google your RL location ;) From sldev at free.fr Thu Feb 25 03:18:23 2010 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 25 Feb 2010 12:18:23 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <201002251157.21630.Lance.Corrimal@eregion.de> References: <4B8437AC.30004@gmail.com> <4B864C8D.6010503@tpg.com.au> <20100225113819.45d3d308.sldev@free.fr> <201002251157.21630.Lance.Corrimal@eregion.de> Message-ID: <20100225121823.e44c3216.sldev@free.fr> On Thu, 25 Feb 2010 11:57:21 +0100, Lance Corrimal wrote: > Am Donnerstag, 25. Februar 2010 11:38:19 schrieb Henri Beauchamp: > > > The problem is not about not being "prepared to put your identity to your > > own doings", it's all about the cross referencing that search engines such > > as Google allow: if I put my true name behind the Cool SL Viewer, then it > > also means that anyone Googling that true name could find out what are my > > kinks (profiles are also Googled), then who I am in Real Life, what's my > > job, where I live, etc, etc... Would *you* be ready for this to happen to > > *you* ? I'm not ! > > given the great work that you deliver with the cool viewer, me and a few > sixpacks of beer wouldnt mind being able to google your RL location ;) But then it is *my* decision to give away my true identity to people *I* trust... and possibly invite them to drink those beers at my home. ;-) It's very different from allowing "BigBrotheresque" things to happen by giving away each and every most intimate detail about yourself for anyone with an Internet connection to see you "naked" on the internet... I know it's very much popular for now to open blogs where you say to the world how bad you were constipated during the last week, or all sorts of immensely interesting stuff like that, and that "social networks" (actually a good way for commercial companies and even government intelligence agencies to gather tons of data about you) where you give up all sorts of details about your life are very popular, but I, for one would never do such an irresponsible thing. My guess is that we will soon hear about discriminations based on private info gathered on Internet (Employee: "oh, why can't I get this job, sir ?" - Employer: "Because you use your avatar in SL to rolepay BDSM, you sicko !"). Again, feel free to call me paranoid, but I'm better be safe than sorry... Henri. From Lance.Corrimal at eregion.de Thu Feb 25 03:31:13 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 25 Feb 2010 12:31:13 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <20100225121823.e44c3216.sldev@free.fr> References: <4B8437AC.30004@gmail.com> <201002251157.21630.Lance.Corrimal@eregion.de> <20100225121823.e44c3216.sldev@free.fr> Message-ID: <201002251231.13769.Lance.Corrimal@eregion.de> Am Donnerstag, 25. Februar 2010 12:18:23 schrieb Henri Beauchamp: > My guess is that we will soon hear about discriminations based on > private info gathered on Internet (Employee: "oh, why can't I get this > job, sir ?" - Employer: "Because you use your avatar in SL to rolepay > BDSM, you sicko !"). given how MANY people are really kinky on SL I'd expect that to turn out the other way: "You're hired but only if you tie me to this cross and take me from behind you stud you! I KNOW You like that stuff!" From sldev at free.fr Thu Feb 25 03:40:28 2010 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 25 Feb 2010 12:40:28 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <201002251231.13769.Lance.Corrimal@eregion.de> References: <4B8437AC.30004@gmail.com> <201002251157.21630.Lance.Corrimal@eregion.de> <20100225121823.e44c3216.sldev@free.fr> <201002251231.13769.Lance.Corrimal@eregion.de> Message-ID: <20100225124028.54f7e4ce.sldev@free.fr> On Thu, 25 Feb 2010 12:31:13 +0100, Lance Corrimal wrote: > Am Donnerstag, 25. Februar 2010 12:18:23 schrieb Henri Beauchamp: > > > My guess is that we will soon hear about discriminations based on > > private info gathered on Internet (Employee: "oh, why can't I get this > > job, sir ?" - Employer: "Because you use your avatar in SL to rolepay > > BDSM, you sicko !"). > > > given how MANY people are really kinky on SL I'd expect that to turn out the > other way: > > "You're hired but only if you tie me to this cross and take me from behind you > stud you! I KNOW You like that stuff!" Lol ! I'll consider that option... From carlo at alinoe.com Thu Feb 25 04:53:35 2010 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 25 Feb 2010 13:53:35 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <20100225003417.b0e52a55.sldev@free.fr> References: <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> <20100225003417.b0e52a55.sldev@free.fr> Message-ID: <20100225125335.GA829@alinoe.com> On Thu, Feb 25, 2010 at 12:34:17AM +0100, Henri Beauchamp wrote: > 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). Same here. As some people know, I have a large background with IRC. Admins and IRC operators that used their Real Life name (mostly through email), have been known to be called at home on their private phone with death threats to their kids. If LL demands the RL info of developers to be published, then please make an example by starting with listing all the Real Life names and addresses of the Linden employees. -- Carlo Wood From carlo at alinoe.com Thu Feb 25 05:12:05 2010 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 25 Feb 2010 14:12:05 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B861D46.7090506@cox.net> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <769bb4301002231245x17272f34h88eca06115b8a406@mail.gmail.com> <20100225001246.GB9728@alinoe.com> <4B861D46.7090506@cox.net> Message-ID: <20100225131205.GB829@alinoe.com> On Wed, Feb 24, 2010 at 11:48:38PM -0700, Lawson English wrote: > 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. So ok, the entry in the TPV Policy has to be changed then. Note that is also makes the 'Save to RAW terrain file' illegal in most cases (it's almost never the owner of the sim that created the terrain all by himself alone). Are we going to remove this function from the viewer? -- Carlo Wood From sldev at free.fr Thu Feb 25 05:28:49 2010 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 25 Feb 2010 14:28:49 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> Message-ID: <20100225142849.c8107c2e.sldev@free.fr> On Wed, 24 Feb 2010 05:49:01 -0600, Argent Stonecutter wrote: > 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. And today, LL seems to have pulled the plug off already for clients not prociding the MAC address on connection. Here is a copy of the ticket I just opened (I propose that everyone on this list using a text client opens the same kind of ticket): Summary: I cannot login any more using Mono-based, text only clients Details: Today I cannot connect any more when using text only "viewers" (clients) which are written in C# (Mono), such as OMV-light and Radegast. I get the following error: "Second Life cannot be accessed from this computer." but I can still connect from the same computer using either an official or full fledged third parties viewer. I therefore deduce, that you just disallowed the connection for clients not transmitting the MAC address of the Ethernet card the viewers are connected through (Mono/C# won't allow to retrieve such info). While LL has the right to change their policy about which client can connect or not to their service, I think it would be only normal to let a reasonable amount of time for the developers of third parties viewers/clients to adapt their software and make it compliant before such a policy is enforced. Seeing how the TPV policy was published only a couple of days ago, I don't see how OMV-light and Radegast developers could adapt fast enough ! Please note also that not all network interfaces got a MAC address (for example, an USB ADSL MODEM could or could not have such an address, depending entirely on its driver, and PPP links via MODEMs don't have a MAC address either), so basically, you are denying connection to SL to any resident not using a Ethernet card to connect to Internet !... This is pretty unreasonable too... Please, allow again the connection via text only clients (the only way to stay in contact all day long with your customers without having to run a viewer which eats up half of your memory and CPU power !). From carlo at alinoe.com Thu Feb 25 05:29:20 2010 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 25 Feb 2010 14:29:20 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <8FEB1EEB-1AD2-45F8-8CDE-57C396E334D7@gmail.com> References: <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> <4B85D891.1030706@tpg.com.au> <20100225105413.6ab1abf6.sldev@free.fr> <4B864C8D.6010503@tpg.com.au> <8FEB1EEB-1AD2-45F8-8CDE-57C396E334D7@gmail.com> Message-ID: <20100225132920.GC829@alinoe.com> On Thu, Feb 25, 2010 at 11:33:58AM +0100, Marine Kelley wrote: > This is a non-issue anyway, most people will not agree to expose their > RL identity on LL's website just to list a piece of work of theirs, > unless said piece of work is required to be listed in order to be > accepted on their grid. And I have not read anything anywhere that was > even remotely implying such a thing. If this was required, expect most > viewers to be stopped dead in their tracks. Very true. This list is going to stay empty, nobody is going to add their real name, and if it was required in order to get a viewer to connect at all they will just stop developing it; or spoof the indentification of the viewer. It's too ridiculous for words. And what exactly is the use of all this, except to make the life of honest users harder? Rogue viewers/developers will just spoof the indentification anyway; they are not interested in being listed or following the TPV policy. Seems to me that Linden Lab is planning for a follow up with more enforcement, as soon as most popular viewers are actually on that list for a while. I therefore think it's better for all of us if that list stays entirely empty :/ [to clarify: that is better for progress and development than when in the end you need some digital signature binary-only plugin in order to connect]. -- Carlo Wood From gareth at garethnelson.com Thu Feb 25 06:17:49 2010 From: gareth at garethnelson.com (Gareth Nelson) Date: Thu, 25 Feb 2010 14:17:49 +0000 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B85D891.1030706@tpg.com.au> References: <4B8437AC.30004@gmail.com> <4B84596D.5090707@gmail.com> <4B845F55.7070808@cox.net> <4B84AE9C.3080902@gmail.com> <4B84BD23.8080009@Gmail.com> <9e52a8c11002241247s3f6fdeedw730d69d65a4a31dc@mail.gmail.com> <4B85D891.1030706@tpg.com.au> Message-ID: <4ebfc1101002250617q4c40d881q68d1848c74a880de@mail.gmail.com> There's a warranty disclaimer in the GPL, while that doesn't protect developers from liability for active malice on their part, it does protect them from any harm caused by bugs. Personally, I wouldn't dream of releasing any code if I was required to warrant it against all possible damages, as the damages with freely distributable software can be effectively infinite. Of course, nothing stops anyone who wants it from contracting with a developer for a support contract or warranty, and the warranty disclaimer doesn't allow people to GPL a virus and disclaim criminal liability. For the record, anyone who wants to buy a support contract for any code I might release should feel free to contact me so we can talk. On Thu, Feb 25, 2010 at 1:55 AM, Darmath wrote: > 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 > -- ?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 From gareth at garethnelson.com Thu Feb 25 06:28:03 2010 From: gareth at garethnelson.com (Gareth Nelson) Date: Thu, 25 Feb 2010 14:28:03 +0000 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <20100225142849.c8107c2e.sldev@free.fr> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <20100225142849.c8107c2e.sldev@free.fr> Message-ID: <4ebfc1101002250628k34adf06y6eba4b7711660af2@mail.gmail.com> I wonder what the official LL response would be if you gave a randomly generated MAC in these situations, or some kind of hash from other aspects of the hardware -any lindens wish to comment? The other thing of course is defining what "this computer" means for those of us who like to fiddle with our hardware. Personally i'm often swapping components out of my desktop including harddrives and ethernet cards. On Thu, Feb 25, 2010 at 1:28 PM, Henri Beauchamp wrote: > On Wed, 24 Feb 2010 05:49:01 -0600, Argent Stonecutter wrote: > >> 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. > > And today, LL seems to have pulled the plug off already for clients not > prociding the MAC address on connection. Here is a copy of the ticket I > just opened (I propose that everyone on this list using a text client > opens the same kind of ticket): > > Summary: I cannot login any more using Mono-based, text only clients > > Details: > > Today I cannot connect any more when using text only "viewers" (clients) > which are written in C# (Mono), such as OMV-light and Radegast. > > I get the following error: > "Second Life cannot be accessed from this computer." > but I can still connect from the same computer using either an official > or full fledged third parties viewer. > > I therefore deduce, that you just disallowed the connection for clients > not transmitting the MAC address of the Ethernet card the viewers are > connected through (Mono/C# won't allow to retrieve such info). > While LL has the right to change their policy about which client can > connect or not to their service, I think it would be only normal to let > a reasonable amount of time for the developers of third parties > viewers/clients to adapt their software and make it compliant before such > a policy is enforced. > > Seeing how the TPV policy was published only a couple of days ago, I don't > see how OMV-light and Radegast developers could adapt fast enough ! > > Please note also that not all network interfaces got a MAC address (for > example, an USB ADSL MODEM could or could not have such an address, > depending entirely on its driver, and PPP links via MODEMs don't have a > MAC address either), so basically, you are denying connection to SL to > any resident not using a Ethernet card to connect to Internet !... > This is pretty unreasonable too... > > Please, allow again the connection via text only clients (the only way to > stay in contact all day long with your customers without having to run a > viewer which eats up half of your memory and CPU power !). > _______________________________________________ > 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 From gareth at garethnelson.com Thu Feb 25 06:29:25 2010 From: gareth at garethnelson.com (Gareth Nelson) Date: Thu, 25 Feb 2010 14:29:25 +0000 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4ebfc1101002250628k34adf06y6eba4b7711660af2@mail.gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <20100225142849.c8107c2e.sldev@free.fr> <4ebfc1101002250628k34adf06y6eba4b7711660af2@mail.gmail.com> Message-ID: <4ebfc1101002250629p6a246d08ke49e3bb25a91b510@mail.gmail.com> I can confirm that my installation of libomv's TestClient still connects fine - version 0.6.3 On Thu, Feb 25, 2010 at 2:28 PM, Gareth Nelson wrote: > I wonder what the official LL response would be if you gave a randomly > generated MAC in these situations, or some kind of hash from other > aspects of the hardware -any lindens wish to comment? > > The other thing of course is defining what "this computer" means for > those of us who like to fiddle with our hardware. Personally i'm often > swapping components out of my desktop including harddrives and > ethernet cards. > > On Thu, Feb 25, 2010 at 1:28 PM, Henri Beauchamp wrote: >> On Wed, 24 Feb 2010 05:49:01 -0600, Argent Stonecutter wrote: >> >>> 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. >> >> And today, LL seems to have pulled the plug off already for clients not >> prociding the MAC address on connection. Here is a copy of the ticket I >> just opened (I propose that everyone on this list using a text client >> opens the same kind of ticket): >> >> Summary: I cannot login any more using Mono-based, text only clients >> >> Details: >> >> Today I cannot connect any more when using text only "viewers" (clients) >> which are written in C# (Mono), such as OMV-light and Radegast. >> >> I get the following error: >> "Second Life cannot be accessed from this computer." >> but I can still connect from the same computer using either an official >> or full fledged third parties viewer. >> >> I therefore deduce, that you just disallowed the connection for clients >> not transmitting the MAC address of the Ethernet card the viewers are >> connected through (Mono/C# won't allow to retrieve such info). >> While LL has the right to change their policy about which client can >> connect or not to their service, I think it would be only normal to let >> a reasonable amount of time for the developers of third parties >> viewers/clients to adapt their software and make it compliant before such >> a policy is enforced. >> >> Seeing how the TPV policy was published only a couple of days ago, I don't >> see how OMV-light and Radegast developers could adapt fast enough ! >> >> Please note also that not all network interfaces got a MAC address (for >> example, an USB ADSL MODEM could or could not have such an address, >> depending entirely on its driver, and PPP links via MODEMs don't have a >> MAC address either), so basically, you are denying connection to SL to >> any resident not using a Ethernet card to connect to Internet !... >> This is pretty unreasonable too... >> >> Please, allow again the connection via text only clients (the only way to >> stay in contact all day long with your customers without having to run a >> viewer which eats up half of your memory and CPU power !). >> _______________________________________________ >> 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 > -- ?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 From sldev at free.fr Thu Feb 25 06:35:06 2010 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 25 Feb 2010 15:35:06 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4ebfc1101002250629p6a246d08ke49e3bb25a91b510@mail.gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <20100225142849.c8107c2e.sldev@free.fr> <4ebfc1101002250628k34adf06y6eba4b7711660af2@mail.gmail.com> <4ebfc1101002250629p6a246d08ke49e3bb25a91b510@mail.gmail.com> Message-ID: <20100225153506.1996b711.sldev@free.fr> On Thu, 25 Feb 2010 14:29:25 +0000, Gareth Nelson wrote: > I can confirm that my installation of libomv's TestClient still > connects fine - version 0.6.3 In fact, I just tried and yes, it's working again... In the mean time i also got a reply from the support, here it is, just for you to see how much LL cares about such matters: "Hello Henri, Thank you for contacting us regarding your issue. I am sorry but we can only offer support on issues with the official SL viewer. We do not support any thrd party viewer as we are not responsible for their software. If you experience the issue with the official viewer then we will assist to the best of our ability. Please feel free to contact us again in the future if you have any further problems/queries. Kind Regards," So, they apparently allowed again the connections but are denying any support, even though I pointed out in my ticket how this could affect their own viewer... Weird ! From gareth at garethnelson.com Thu Feb 25 06:40:30 2010 From: gareth at garethnelson.com (Gareth Nelson) Date: Thu, 25 Feb 2010 14:40:30 +0000 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <20100225153506.1996b711.sldev@free.fr> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <20100225142849.c8107c2e.sldev@free.fr> <4ebfc1101002250628k34adf06y6eba4b7711660af2@mail.gmail.com> <4ebfc1101002250629p6a246d08ke49e3bb25a91b510@mail.gmail.com> <20100225153506.1996b711.sldev@free.fr> Message-ID: <4ebfc1101002250640t7b6377e0pd6431ddbf4ec5701@mail.gmail.com> Let's try an experiment........ Proxying the login request and dropping the request results in: error executing RPC 'login_to_simulator' Died at /local/www/login.agni.lindenlab.com/cgi-bin/login.cgi line 1802 Looks like the login script can't handle not having a mac address On Thu, Feb 25, 2010 at 2:35 PM, Henri Beauchamp wrote: > On Thu, 25 Feb 2010 14:29:25 +0000, Gareth Nelson wrote: > >> I can confirm that my installation of libomv's TestClient still >> connects fine - version 0.6.3 > > In fact, I just tried and yes, it's working again... In the mean > time i also got a reply from the support, here it is, just for > you to see how much LL cares about such matters: > > "Hello Henri, > > Thank you for contacting us regarding your issue. > > I am sorry but we can only offer support on issues with the official > SL viewer. > > We do not support any thrd party viewer as we are not responsible > for their software. > > If you experience the issue with the official viewer then we will > assist to the best of our ability. > > Please feel free to contact us again in the future if you have any > further problems/queries. > > Kind Regards," > > So, they apparently allowed again the connections but are denying any > support, even though I pointed out in my ticket how this could affect > their own viewer... Weird ! > _______________________________________________ > 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 From gigstaggart at gmail.com Thu Feb 25 08:45:29 2010 From: gigstaggart at gmail.com (Gigs) Date: Thu, 25 Feb 2010 11:45:29 -0500 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <20100225153506.1996b711.sldev@free.fr> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <20100225142849.c8107c2e.sldev@free.fr> <4ebfc1101002250628k34adf06y6eba4b7711660af2@mail.gmail.com> <4ebfc1101002250629p6a246d08ke49e3bb25a91b510@mail.gmail.com> <20100225153506.1996b711.sldev@free.fr> Message-ID: <4B86A929.5010203@gmail.com> Henri Beauchamp wrote: > Thank you for contacting us regarding your issue. > > I am sorry but we can only offer support on issues with the official > SL viewer. This sort of response is completely unacceptable. You weren't asking for support for your viewer, you were asking for support related to the server's behavior. From da5idkronfeld at gmail.com Thu Feb 25 09:31:52 2010 From: da5idkronfeld at gmail.com (Da5id Kronfeld) Date: Thu, 25 Feb 2010 09:31:52 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <20100225142849.c8107c2e.sldev@free.fr> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <20100225142849.c8107c2e.sldev@free.fr> Message-ID: <440A3F24-07A4-4A3B-A91A-6A0C0D26392B@gmail.com> On 2010-02-25, at 5:28 AM, Henri Beauchamp wrote: > On Wed, 24 Feb 2010 05:49:01 -0600, Argent Stonecutter wrote: > > > And today, LL seems to have pulled the plug off already for clients not > prociding the MAC address on connection. Here is a copy of the ticket I > just opened (I propose that everyone on this list using a text client > opens the same kind of ticket): > > Summary: I cannot login any more using Mono-based, text only clients > > Details: > > Today I cannot connect any more when using text only "viewers" (clients) > which are written in C# (Mono), such as OMV-light and Radegast. Radegast still works for me. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100225/4aa2a392/attachment.htm From secret.argent at gmail.com Thu Feb 25 09:31:56 2010 From: secret.argent at gmail.com (Argent) Date: Thu, 25 Feb 2010 11:31:56 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <1D44A821-0C91-4DB2-A39C-4D839ADD7DE4@gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <1D44A821-0C91-4DB2-A39C-4D839ADD7DE4@gmail.com> Message-ID: <16309a041002250931s6f48074bg3943a2bae01fcaf2@mail.gmail.com> Sorry for not editing this in detail, Opera is SLOW as hell in a thread this long in gmail. I understand why they're asking for a MAC address. I'm pointing out that a viewer may be running on a device that HAS NO MAC ADDRESS. On Wed, Feb 24, 2010 at 8:28 AM, 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. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100225/2bbcbe4d/attachment.htm From bogus@does.not.exist.com Fri Feb 5 05:04:03 2010 From: bogus@does.not.exist.com () Date: Fri, 05 Feb 2010 13:04:03 -0000 Subject: No subject Message-ID: ot seen when crossing a router to a new network. So, therer is no way to se= e 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 r= ead your mac address locally, then send it along to LL to be used to identi= fy 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 s= erver, 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 compl= etely 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 <secret.argent at gmail.com> 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.

--00504502cc39d2b27804807028d6-- From cjac at colliertech.org Tue Feb 23 14:21:06 2010 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Tue, 23 Feb 2010 14:21:06 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B8437AC.30004@gmail.com> References: <4B8437AC.30004@gmail.com> Message-ID: <1266963666.5756.0.camel@calcifer> Are you sure? I'd think that denying connection to their services would not be limited in any way by the GPL. But IANAL. On Tue, 2010-02-23 at 15:16 -0500, Gigs wrote: > http://secondlife.com/corporate/tpv.php > > You all realize this is massively incompatible with the GPL, right? > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/9a5788cd/attachment-0004.pgp From cjac at colliertech.org Tue Feb 23 14:23:01 2010 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Tue, 23 Feb 2010 14:23:01 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> Message-ID: <1266963781.5756.1.camel@calcifer> The Debian (Sun) Java runtime package has such an agreement requirement or did at one point. On Tue, 2010-02-23 at 20:37 +0000, Robin Cornelius wrote: > On Tue, Feb 23, 2010 at 8:31 PM, Soft Linden wrote: > > Mike's correct. > > > > If you see any wording that's ambiguous about that, let us know. > > _______________________________________________ > > > Well you seem to have spelled the end of my debian/ubuntu project, I > can not meet the tems of the third party viewer policy:- > > "On your software download page or in another location that a user > must visit before installing the Third-Party Viewer, you must disclose > the following:" > > I cannot do this with an apt-repository, the user can bypass every > possible webpage or description field. and the fact the policy says > this is a MUST. The only possible way to do this is to create a custom > program that displays a screen during the install hook of the package > and aborts the package install. This can no longer be accepted in to > the main debian or ubuntu repositories. > > Also it appears that i cannot use the snowglobe logo or name, even > though i'm basicly building from almost prestine source. I though this > was the entire point of the snowglobe rebranding, but now we are > exactly where we were with secondlife 12 months ago. > > Robin > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100223/6a296f3e/attachment-0004.pgp From tateru.nino at gmail.com Thu Feb 25 09:35:04 2010 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri, 26 Feb 2010 04:35:04 +1100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <16309a041002250931s6f48074bg3943a2bae01fcaf2@mail.gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <1D44A821-0C91-4DB2-A39C-4D839ADD7DE4@gmail.com> <16309a041002250931s6f48074bg3943a2bae01fcaf2@mail.gmail.com> Message-ID: <4B86B4C8.9000406@weblogsinc.com> If I was running on the equipment provided by my ISP, rather than assembling my own kit, I wouldn't have a MAC address either. On 26/02/2010 4:31 AM, Argent wrote: > Sorry for not editing this in detail, Opera is SLOW as hell in a > thread this long in gmail. > > I understand why they're asking for a MAC address. I'm pointing out > that a viewer may be running on a device that HAS NO MAC ADDRESS. > > On Wed, Feb 24, 2010 at 8:28 AM, 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 -- Tateru Nino Contributing Editor http://massively.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100226/09a000d8/attachment-0001.htm From maggie at matrisync.com Thu Feb 25 09:37:34 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Thu, 25 Feb 2010 12:37:34 -0500 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B86A929.5010203@gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <20100225142849.c8107c2e.sldev@free.fr> <4ebfc1101002250628k34adf06y6eba4b7711660af2@mail.gmail.com> <4ebfc1101002250629p6a246d08ke49e3bb25a91b510@mail.gmail.com> <20100225153506.1996b711.sldev@free.fr> <4B86A929.5010203@gmail.com> Message-ID: On Thu, Feb 25, 2010 at 11:45 AM, Gigs wrote: > Henri Beauchamp wrote: >> Thank you for contacting us regarding your issue. >> I am sorry but we can only offer support on issues with the official >> SL viewer. > This sort of response is completely unacceptable. ?You weren't asking > for support for your viewer, you were asking for support related to the > server's behavior. I've been blown off with that excuse too. Read http://jira.secondlife.com/browse/SVC-5357 for my trail-of-tears support experience. Sure glad I went premium, I got this nifty free house... From kow at sapinski.com Thu Feb 25 09:45:48 2010 From: kow at sapinski.com (k\o\w) Date: Thu, 25 Feb 2010 12:45:48 -0500 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <16309a041002250931s6f48074bg3943a2bae01fcaf2@mail.gmail.com> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <1D44A821-0C91-4DB2-A39C-4D839ADD7DE4@gmail.com> <16309a041002250931s6f48074bg3943a2bae01fcaf2@mail.gmail.com> Message-ID: <4B86B74C.50904@sapinski.com> The hashed MAC and id0 sent upon login is just a bonus. Linden collect much more sensitive data from your PC using the viewerstats cap, which includes unhashed MAC, id0, CPU serial, and a pretty thorough breakdown of all your PC specs. I can confirm that this has been used to track griefers and custom clients that spoof the login hashes to circumvent bans. I think everyones approach to the new policy is a bit hostile.... have you folks even read the original policies you agreed to? You've all given up more rights than the new policies try to take away :) The simple act of logging into SL can and has been classified as "Disturbing the peace" and is grounds for account closure. These new policies are nothing new, do not represent how 99% of the Lab will act when dealing with "abuse", and were probably written by lawyers who were tasked with making existing policies more legally binding because of all those lawsuits LL has lost. In any case, I'm going to go with Carlo Wood here and continue using my own common sense. The default behaviour of my viewer will loosely follow LLs guidelines, and will have plenty of options for spoofing, disabling, and circumventing "features" that get in my way. Meerkat already obfuscates a lot of sensitive info like mac and id0, allows the export of full perm content, and so far I haven't had any complaints, just praise. *crosses fingers*. Linden haven't banned cryolife, vlife, neillife, and the majority of the copybot viewers out there that DO identify uniquely upon login. You'll probably have to burn a pretty big bridge for them to take action against your client. On 2/25/2010 12:31 PM, Argent wrote: > Sorry for not editing this in detail, Opera is SLOW as hell in a > thread this long in gmail. > > I understand why they're asking for a MAC address. I'm pointing out > that a viewer may be running on a device that HAS NO MAC ADDRESS. > > On Wed, Feb 24, 2010 at 8:28 AM, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100225/906f3699/attachment.htm From colin.kern at gmail.com Thu Feb 25 10:30:48 2010 From: colin.kern at gmail.com (Colin Kern) Date: Thu, 25 Feb 2010 13:30:48 -0500 Subject: [opensource-dev] "Resposibility" - Third party viewer policy In-Reply-To: <4B85472B.5020804@gmail.com> References: <201002240952.08231.Lance.Corrimal@eregion.de> <4B85472B.5020804@gmail.com> Message-ID: <77c421f01002251030m11717108xe97bc3aa48d8c2a0@mail.gmail.com> On Wed, Feb 24, 2010 at 10:35 AM, Vex Streeter wrote: > > 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. > Nothing in the TPV contradicts or violates the GPL, because the GPL is all about distribution of software, and the TPV is about whether or not LL will allow a viewer to connect to their servers, not whether you'll be allowed to distribute it. Colin From matrice64 at gmail.com Thu Feb 25 10:31:05 2010 From: matrice64 at gmail.com (Matrice64) Date: Thu, 25 Feb 2010 12:31:05 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <20100225142849.c8107c2e.sldev@free.fr> <4ebfc1101002250628k34adf06y6eba4b7711660af2@mail.gmail.com> <4ebfc1101002250629p6a246d08ke49e3bb25a91b510@mail.gmail.com> <20100225153506.1996b711.sldev@free.fr> <4B86A929.5010203@gmail.com> Message-ID: well put k\o\w :-) On Thu, Feb 25, 2010 at 11:37 AM, Maggie Leber (sl: Maggie Darwin) < maggie at matrisync.com> wrote: > On Thu, Feb 25, 2010 at 11:45 AM, Gigs wrote: > > Henri Beauchamp wrote: > >> Thank you for contacting us regarding your issue. > >> I am sorry but we can only offer support on issues with the official > >> SL viewer. > > This sort of response is completely unacceptable. You weren't asking > > for support for your viewer, you were asking for support related to the > > server's behavior. > > I've been blown off with that excuse too. > > Read http://jira.secondlife.com/browse/SVC-5357 for my trail-of-tears > support experience. > > Sure glad I went premium, I got this nifty free house... > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100225/5fddc94a/attachment.htm From dzonatas at gmail.com Thu Feb 25 11:05:40 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 25 Feb 2010 11:05:40 -0800 Subject: [opensource-dev] TPV & opensim Message-ID: <4B86CA04.3030501@gmail.com> I thought this was quite of interest for viewer developers that might ever be interested to attach a simulator to their viewer in order to dispel latency. --- snip --- If one opensim box connects to another opensim box, that is, technically, peer to peer. So, are you saying an opensim box cannot run a client at the same time? >Melanie wrote: >Hi, >peer to peer simulation is not practical for many different reasons. >Latency being the chief one. > >OpenSim is not going to be a peer to peer system, therefore your >suggestion is off topic. Opensim doesn't need another TLD, and it is >not what you are envisioning. OpenSim firmly embraces the concept of >SERVER SIDE simulation, therefore every sim will always have a >central server. > >I believe this has gone as far as it will go and if there is any >more name calling, well, we'll just have to moderate some people, >won't we? > >Melanie >(Core) -------------- next part -------------- An embedded message was scrubbed... From: Dzonatas Sol Subject: Re: [Opensim-dev] Suggested in-world DNS: .sim Date: Thu, 25 Feb 2010 10:50:55 -0800 Size: 1430 Url: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100225/58d70e64/attachment.eml From dahliatrimble at gmail.com Thu Feb 25 11:08:06 2010 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 25 Feb 2010 11:08:06 -0800 Subject: [opensource-dev] TPV & opensim In-Reply-To: <4B86CA04.3030501@gmail.com> References: <4B86CA04.3030501@gmail.com> Message-ID: I have been experimenting with combining and/or offloading physics simulations on physics capable clients (not LL based) with OpenSim, but nothing has been released as open source as of yet. It's not clear to me how a new TLD would affect this though, or why it might be required. -Dahlia (Core) On Thu, Feb 25, 2010 at 11:05 AM, Dzonatas Sol wrote: > I thought this was quite of interest for viewer developers that might ever > be interested to attach a simulator to their viewer in order to dispel > latency. > > --- snip --- > > If one opensim box connects to another opensim box, that is, technically, > peer to peer. > > So, are you saying an opensim box cannot run a client at the same time? > > >Melanie wrote: > >Hi, > > >peer to peer simulation is not practical for many different reasons. > >Latency being the chief one. > > > >OpenSim is not going to be a peer to peer system, therefore your > >suggestion is off topic. Opensim doesn't need another TLD, and it is > >not what you are envisioning. OpenSim firmly embraces the concept of > >SERVER SIDE simulation, therefore every sim will always have a > >central server. > > > >I believe this has gone as far as it will go and if there is any > >more name calling, well, we'll just have to moderate some people, > >won't we? > > > >Melanie > >(Core) > > If one opensim box connects to another opensim box, that is, technically, > peer to peer. > > So, are you saying an opensim box cannot run a client at the same time? > > Melanie wrote: > >> Hi, >> >> peer to peer simulation is not practical for many different reasons. >> Latency being the chief one. >> >> OpenSim is not going to be a peer to peer system, therefore your >> suggestion is off topic. Opensim doesn't need another TLD, and it is >> not what you are envisioning. OpenSim firmly embraces the concept of >> SERVER SIDE simulation, therefore every sim will always have a >> central server. >> >> I believe this has gone as far as it will go and if there is any >> more name calling, well, we'll just have to moderate some people, >> won't we? >> >> Melanie >> (Core) >> >> >> >> > > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100225/06a7a374/attachment-0001.htm From dzonatas at gmail.com Thu Feb 25 11:37:47 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 25 Feb 2010 11:37:47 -0800 Subject: [opensource-dev] TPV & opensim In-Reply-To: References: <4B86CA04.3030501@gmail.com> Message-ID: <4B86D18B.8060107@gmail.com> Given this setup. It would look like this: [ viewer <-> opensim ] <-> [ opensim <-> viewer ] That's peer to peer. Let's say somebody wants to setup a 3D website inside one. They don't want to go through ICANN because it's "virtual" just like "virtual linden" currency. They want "http://media.on.a.prim.region.open.sim" as their website. They point and click, create object, select media prefs, enter website address, they get the TLD automatically, no hassle to reg with ICANN for every prim they create. And, no need to have a static server, any other simulator may connect to their simulator and find their website. That way someone may "buy" their prim, take it to another world, and use it there, and the website still works and knows how to resolve addresses. Dahlia Trimble wrote: > I have been experimenting with combining and/or offloading physics > simulations on physics capable clients (not LL based) with OpenSim, > but nothing has been released as open source as of yet. It's not clear > to me how a new TLD would affect this though, or why it might be > required. > > -Dahlia > (Core) > > On Thu, Feb 25, 2010 at 11:05 AM, Dzonatas Sol > wrote: > > I thought this was quite of interest for viewer developers that > might ever be interested to attach a simulator to their viewer in > order to dispel latency. > > --- snip --- > > If one opensim box connects to another opensim box, that is, > technically, peer to peer. > > So, are you saying an opensim box cannot run a client at the same > time? > > >Melanie wrote: > >Hi, > > >peer to peer simulation is not practical for many different reasons. > >Latency being the chief one. > > > >OpenSim is not going to be a peer to peer system, therefore your > >suggestion is off topic. Opensim doesn't need another TLD, and it is > >not what you are envisioning. OpenSim firmly embraces the concept of > >SERVER SIDE simulation, therefore every sim will always have a > >central server. > > > >I believe this has gone as far as it will go and if there is any > >more name calling, well, we'll just have to moderate some people, > >won't we? > > > >Melanie > >(Core) > > If one opensim box connects to another opensim box, that is, > technically, peer to peer. > > So, are you saying an opensim box cannot run a client at the same > time? > > Melanie wrote: > > Hi, > > peer to peer simulation is not practical for many different > reasons. > Latency being the chief one. > > OpenSim is not going to be a peer to peer system, therefore your > suggestion is off topic. Opensim doesn't need another TLD, and > it is > not what you are envisioning. OpenSim firmly embraces the > concept of > SERVER SIDE simulation, therefore every sim will always have a > central server. > > I believe this has gone as far as it will go and if there is any > more name calling, well, we'll just have to moderate some people, > won't we? > > Melanie > (Core) > > > ? > > > > > _______________________________________________ > 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 > > From lenglish5 at cox.net Thu Feb 25 12:01:17 2010 From: lenglish5 at cox.net (Lawson English) Date: Thu, 25 Feb 2010 13:01:17 -0700 Subject: [opensource-dev] realxtend retreating from SL support... ? Message-ID: <4B86D70D.9030509@cox.net> realxtend list: http://groups.google.com/group/realxtend [ thread: Naali will never run on Second Life? How can you guys claim to be working on interop with IETF when suddenly no independent implementation of the viewer works with the SL protocols and your new viewer policy is scaring everyone away from working on interop? So much for "2 independent implementations": word is that even the libomv text viewers aren't working any more. Lawson (sheesh) From dzonatas at gmail.com Thu Feb 25 12:40:27 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 25 Feb 2010 12:40:27 -0800 Subject: [opensource-dev] TPV & opensim & physics prediction In-Reply-To: References: <4B86CA04.3030501@gmail.com> Message-ID: <4B86E03B.1090901@gmail.com> If there is no need for a grid server, then there would be no need for a TOS that would try to control a TPV. I see the issue of opensim that wants to say "can only connect client to a grid server as supported by opensim" no different than Linden Lab's new TOS in attempts to control TPVs. If we modify LL's official viewer and add client-side simulation to help dispel latency, with physics prediction, then their TOS says "no," you have to register your special viewer to connect. Melanie stated that opensim is grid server only (like a TOS), which in essence, is logical equivalent to say, "you can't modify opensim in order to add a viewer and connect to our grid server" One obvious question is: who's grid server? With physics prediction being equal peer to peer, why would there ever need to be a grid server, or a TOS? >>> You're confusing the architecture of the software with what people want to do with it. So, are they saying they don't want physics prediction? Robert A. Knop Jr. wrote: > On Thu, Feb 25, 2010 at 10:34:08AM -0800, Dzonatas Sol wrote: > >> If everything is peer-2-peer where each client runs it's own simulator, >> there would be no need for a grid server. It's foolish and stupid to >> consider people would only want to connect to a grid server. That's >> certainly not how reality works, so it would be stupid to expect that >> when simulated. >> > > ...and, in OpenSim right now, there's no need for a "grid server". You > run a standalone region, and you've got your region without having some > grid server. > > But it's not purely peer-to-peer, because the viewer software and the > server software are two different pieces of software. > > It's just like how I can run Apache (web server) on my desktop, and use > Firefox (web client) on my desktop to look at HTML documents served by > Apache on my desktop. It's all on my machine, and I don't have to rely > on any web hosting provider or any such to complete the transaction. > But it's not p2p in the sense that it's still a client-server > architecture. > > You're confusing the architecture of the software with what people want > to do with it. Things don't have to have a peer-to-peer architecture > for everybody to be able to roll their own. There are advantages and > disadvantages to different architectures for different problems. But > the fact is that OpenSim is a client/server architecture, and that's how > it is. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > From dzonatas at gmail.com Thu Feb 25 13:12:54 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 25 Feb 2010 13:12:54 -0800 Subject: [opensource-dev] TPV & opensim & physics prediction In-Reply-To: <20100225203234.GA8991@caliban.tmnwh.net> References: <4B86CA04.3030501@gmail.com> <4B86E03B.1090901@gmail.com> <20100225203234.GA8991@caliban.tmnwh.net> Message-ID: <4B86E7D6.2000303@gmail.com> I had this question but didn't see a response to it at all: "So, are they saying they don't want physics prediction? " To me, a direct protocol, with a TLD, like "opens.im" , would help enable physics prediction where two or more simulator share the same dataset for a single region. There are exponential reasons why, so I only have avoided to describe all potential possibilities. The issue of latency seems like a major concern for ALL users, not just those who invest in a grid server. As I started this conversion, I brought up the UUCP domain, as it traditionally shows the foundation of p2p networks and how to share datasets with simple copy programs. Look at all the traffic on USENET that was still delivered to all nodes even on what we would consider now the slowest of computers and data connections. People used a similar VIEWER<->UUCP<->UUCP<->VIEWER to read news and distribute all the datasets. It worked. It is still free and open. All what we really want to do is add a 3D renderer and physics simulator. Everything else is already open source, patented, RFC'd, and etc. Also, since "prims" are in-world, we also just want to add an "in-world DNS" that is not controlled by a "out-of-world IANA" -- I don't think this was acknowledged. Some can simply think of an LSL script in-world that acted as the DNS program, if that helps clarify. Robert A. Knop Jr. wrote: > On Thu, Feb 25, 2010 at 12:40:27PM -0800, Dzonatas Sol wrote: > >> If there is no need for a grid server, then there would be no need >> for a TOS that would try to control a TPV. >> > > ...and OpenSim has no such TOS. > > >> If we modify LL's official viewer and add client-side simulation to >> help dispel latency, with physics prediction, then their TOS says >> "no," you have to register your special viewer to connect. >> > > ...to *Second Life*. Not to connect in general. > > You're confusing Second Life, which is a single proprietary service run > by a single company, with OpenSim, which is a software platform that can > be deployed by anybody. > > >> Melanie stated that opensim is grid server only (like a TOS), which >> in essence, is logical equivalent to say, "you can't modify opensim >> in order to add a viewer and connect to our grid server" >> > > Wrong. > > From jay_reynolds_freeman at mac.com Thu Feb 25 13:37:15 2010 From: jay_reynolds_freeman at mac.com (Jay Reynolds Freeman) Date: Thu, 25 Feb 2010 13:37:15 -0800 Subject: [opensource-dev] "Second-Party" viewer policy (was: Third party viewer policy) Message-ID: <012E4081-AC93-43A9-89C2-65CAC87EFFCF@mac.com> All the heated discussion about the new third-party viewer policy sent me scurrying in terror to find a nice rock to hide under, but unfortunately there is a question I need to ask, so I must now peek out and speak up: LL defines "third-party viewers" only in terms of "third-party software clients" (Policy section 9.c, which also provides some examples for elaboration). I am not a lawyer and do not play one in SL, but I gather that the "first party" in such a case is LL, and that the "second party" would be whoever is actually using the viewer to access SL. But what if there is no "third party"? What if I develop a modified version of the SL viewer all by myself, and use it to log in to the SL servers, but do not distribute either source or binary for it? Since there is no additional, "third" party involved in the creation and use of this viewer, it would appear that nothing in the "Linden Lab Policy on Third-Party Viewers" applies to it or to me. My viewer might more properly be described as a "second-party" viewer. (I of course must comply with other LL terms of service and abide by many other legal, moral and ethical considerations.) This is a real issue for me, not an attempt to pick nits: I do have a personal, slightly modified version of the SL viewer that I use occasionally, for a hobby project, and I have no intention of distributing it in any form. (And I indeed believe that I am in full compliance with the LL terms of service, et cetera. My project is not malicious: I will be happy to tell LL or anyone else about it, but it is off-topic for this group and this thread, so send me private EMail if you wish.) What I need to know is whether I can ignore the present "Linden Lab Policy on Third-Party Viewers" and keep fussing with my own "second-party" viewer as I have been, or whether I need to take steps to comply with a policy which probably was not developed with folks like me in mind. Sorry to put another log on the pyre, er, fire ... :-) -- Jay Reynolds Freeman (CeeJay Tigerpaw in Second Life) --------------------- Jay_Reynolds_Freeman at mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) From lenglish5 at cox.net Thu Feb 25 14:17:10 2010 From: lenglish5 at cox.net (Lawson English) Date: Thu, 25 Feb 2010 15:17:10 -0700 Subject: [opensource-dev] TPV & opensim In-Reply-To: <4B86D18B.8060107@gmail.com> References: <4B86CA04.3030501@gmail.com> <4B86D18B.8060107@gmail.com> Message-ID: <4B86F6E6.6060401@cox.net> Dzonatas Sol wrote: > Given this setup. It would look like this: > > [ viewer <-> opensim ] <-> [ opensim <-> viewer ] > > That's peer to peer. > Another variation of peer to peer is: [ viewer ] <=> server <=> [ viewer ] ...\.........................../ ....\........................./ .....<=======================> The viewers talk to each other or to a remote server separately from the sim server and share content via that channel instead/as well. "Content" could be prims, physics, etc. Lawson From dzonatas at gmail.com Thu Feb 25 14:42:16 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 25 Feb 2010 14:42:16 -0800 Subject: [opensource-dev] TPV & opensim In-Reply-To: <4B86F6E6.6060401@cox.net> References: <4B86CA04.3030501@gmail.com> <4B86D18B.8060107@gmail.com> <4B86F6E6.6060401@cox.net> Message-ID: <4B86FCC8.3060903@gmail.com> Lawson English wrote: > Dzonatas Sol wrote: > >> Given this setup. It would look like this: >> >> [ viewer <-> opensim ] <-> [ opensim <-> viewer ] >> >> That's peer to peer. >> >> > > Another variation of peer to peer is: > > [ viewer ] <=> server <=> [ viewer ] > ...\.........................../ > ....\........................./ > .....<=======================> > > > In X11 terms, it would be [ server ] <=> client <=> [ server ] ...\.........................../ ....\........................./ .....<=======================> Hmm, it is the server that renders the world, so the "client" is in () parens here: [ viewer <-> ( opensim ] <-> [ opensim ) <-> viewer ] From soft at lindenlab.com Thu Feb 25 14:29:14 2010 From: soft at lindenlab.com (Soft Linden) Date: Thu, 25 Feb 2010 16:29:14 -0600 Subject: [opensource-dev] "Second-Party" viewer policy (was: Third party viewer policy) In-Reply-To: <012E4081-AC93-43A9-89C2-65CAC87EFFCF@mac.com> References: <012E4081-AC93-43A9-89C2-65CAC87EFFCF@mac.com> Message-ID: On Thu, Feb 25, 2010 at 3:37 PM, Jay Reynolds Freeman wrote: > > But what if there is no "third party"? ?What if I develop a modified version of the SL viewer all by myself, and use it to log in to the SL servers, but do not distribute either source or binary for it? ?Since there is no additional, "third" party involved in the creation and use of this viewer, it would appear that nothing in the "Linden Lab Policy on Third-Party Viewers" applies to it or to me. > The FAQ and revised TPV, coming soon, will address this directly. There are some terms in there that don't apply if you aren't putting the viewer in the registry, and they will be identified as such. Most apply to any third-party viewer however, even if you aren't distributing it. From nexisentertainment at gmail.com Thu Feb 25 15:08:11 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Thu, 25 Feb 2010 15:08:11 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <4B8437AC.30004@gmail.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <20100225142849.c8107c2e.sldev@free.fr> <4ebfc1101002250628k34adf06y6eba4b7711660af2@mail.gmail.com> <4ebfc1101002250629p6a246d08ke49e3bb25a91b510@mail.gmail.com> <20100225153506.1996b711.sldev@free.fr> <4B86A929.5010203@gmail.com> Message-ID: <1267139291.3694.4342.camel@RAGE> My estate's prototype land management/group invite bot was banned last night ("Second Life cannot be accessed from this computer, please email us at our non-working support email so we can laugh at you") but it works this morning. Looks like they got too many support emails and had to reverse that ban. On Thu, 2010-02-25 at 12:31 -0600, Matrice64 wrote: > well put k\o\w :-) > > On Thu, Feb 25, 2010 at 11:37 AM, Maggie Leber (sl: Maggie Darwin) > wrote: > On Thu, Feb 25, 2010 at 11:45 AM, Gigs > wrote: > > Henri Beauchamp wrote: > >> Thank you for contacting us regarding your issue. > >> I am sorry but we can only offer support on issues with the > official > >> SL viewer. > > This sort of response is completely unacceptable. You > weren't asking > > for support for your viewer, you were asking for support > related to the > > server's behavior. > > > I've been blown off with that excuse too. > > Read http://jira.secondlife.com/browse/SVC-5357 for my > trail-of-tears > support experience. > > Sure glad I went premium, I got this nifty free house... > > _______________________________________________ > 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 From erikba at odysseus.anderson.name Thu Feb 25 15:18:34 2010 From: erikba at odysseus.anderson.name (Erik Anderson) Date: Thu, 25 Feb 2010 15:18:34 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <1267139291.3694.4342.camel@RAGE> References: <4B8437AC.30004@gmail.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <20100225142849.c8107c2e.sldev@free.fr> <4ebfc1101002250628k34adf06y6eba4b7711660af2@mail.gmail.com> <4ebfc1101002250629p6a246d08ke49e3bb25a91b510@mail.gmail.com> <20100225153506.1996b711.sldev@free.fr> <4B86A929.5010203@gmail.com> <1267139291.3694.4342.camel@RAGE> Message-ID: <56c0988e1002251518w2bb32712mce02eae2d2c98e3b@mail.gmail.com> From bogus@does.not.exist.com Fri Feb 5 05:04:03 2010 From: bogus@does.not.exist.com () Date: Fri, 05 Feb 2010 13:04:03 -0000 Subject: No subject Message-ID: ill-timed bug and that someone probably has egg on their face from messing up the production login server while in the middle of some rather delicate negotiations here regarding said server. Amazon did something similar with dropping books several months back, so it might be good to take a breather in all of this... On Thu, Feb 25, 2010 at 3:08 PM, Rob Nelson wrote: > My estate's prototype land management/group invite bot was banned last > night ("Second Life cannot be accessed from this computer, please email > us at our non-working support email so we can laugh at you") but it > works this morning. Looks like they got too many support emails and had > to reverse that ban. > > On Thu, 2010-02-25 at 12:31 -0600, Matrice64 wrote: > > well put k\o\w :-) > > > > On Thu, Feb 25, 2010 at 11:37 AM, Maggie Leber (sl: Maggie Darwin) > > wrote: > > On Thu, Feb 25, 2010 at 11:45 AM, Gigs > > wrote: > > > Henri Beauchamp wrote: > > >> Thank you for contacting us regarding your issue. > > >> I am sorry but we can only offer support on issues with the > > official > > >> SL viewer. > > > This sort of response is completely unacceptable. You > > weren't asking > > > for support for your viewer, you were asking for support > > related to the > > > server's behavior. > > > > > > I've been blown off with that excuse too. > > > > Read http://jira.secondlife.com/browse/SVC-5357 for my > > trail-of-tears > > support experience. > > > > Sure glad I went premium, I got this nifty free house... > > > > _______________________________________________ > > 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 > --0016e64ce5b2a940300480750194 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable From soft at lindenlab.com Thu Feb 25 15:31:20 2010 From: soft at lindenlab.com (Soft Linden) Date: Thu, 25 Feb 2010 17:31:20 -0600 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <56c0988e1002251518w2bb32712mce02eae2d2c98e3b@mail.gmail.com> References: <4B8437AC.30004@gmail.com> <20100225142849.c8107c2e.sldev@free.fr> <4ebfc1101002250628k34adf06y6eba4b7711660af2@mail.gmail.com> <4ebfc1101002250629p6a246d08ke49e3bb25a91b510@mail.gmail.com> <20100225153506.1996b711.sldev@free.fr> <4B86A929.5010203@gmail.com> <1267139291.3694.4342.camel@RAGE> <56c0988e1002251518w2bb32712mce02eae2d2c98e3b@mail.gmail.com> Message-ID: There have been no bans related to the TPV policy release. I know there's been some work on migrating some servers to a data center with better connectivity to the other sims, etc. There was also a login problem lasting a couple minutes yesterday around 19:30 Pacific. I wouldn't be surprised if it was related to one of these. On Thu, Feb 25, 2010 at 5:18 PM, Erik Anderson wrote: > From Gareth's analysis, I'm guessing that the "ban" today was a rather > ill-timed bug and that someone probably has egg on their face from messing > up the production login server while in the middle of some rather delicate > negotiations here regarding said server.? Amazon did something similar with > dropping books several months back, so it might be good to take a breather > in all of this... > > On Thu, Feb 25, 2010 at 3:08 PM, Rob Nelson > wrote: >> >> My estate's prototype land management/group invite bot was banned last >> night ("Second Life cannot be accessed from this computer, please email >> us at our non-working support email so we can laugh at you") but it >> works this morning. ?Looks like they got too many support emails and had >> to reverse that ban. >> >> On Thu, 2010-02-25 at 12:31 -0600, Matrice64 wrote: >> > well put k\o\w :-) >> > >> > On Thu, Feb 25, 2010 at 11:37 AM, Maggie Leber (sl: Maggie Darwin) >> > wrote: >> > ? ? ? ? On Thu, Feb 25, 2010 at 11:45 AM, Gigs >> > ? ? ? ? wrote: >> > ? ? ? ? > Henri Beauchamp wrote: >> > ? ? ? ? >> Thank you for contacting us regarding your issue. >> > ? ? ? ? >> I am sorry but we can only offer support on issues with the >> > ? ? ? ? official >> > ? ? ? ? >> SL viewer. >> > ? ? ? ? > This sort of response is completely unacceptable. ?You >> > ? ? ? ? weren't asking >> > ? ? ? ? > for support for your viewer, you were asking for support >> > ? ? ? ? related to the >> > ? ? ? ? > server's behavior. >> > >> > >> > ? ? ? ? I've been blown off with that excuse too. >> > >> > ? ? ? ? Read http://jira.secondlife.com/browse/SVC-5357 for my >> > ? ? ? ? trail-of-tears >> > ? ? ? ? support experience. >> > >> > ? ? ? ? Sure glad I went premium, I got this nifty free house... >> > >> > ? ? ? ? _______________________________________________ >> > ? ? ? ? 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 > From carlo at alinoe.com Thu Feb 25 16:45:49 2010 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 26 Feb 2010 01:45:49 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <20100225153506.1996b711.sldev@free.fr> References: <4B8437AC.30004@gmail.com> <4B8438C4.6090702@hp.com> <3A4CB1F2-B4A1-4E2D-B12A-AC77CA96A094@gmail.com> <20100225142849.c8107c2e.sldev@free.fr> <4ebfc1101002250628k34adf06y6eba4b7711660af2@mail.gmail.com> <4ebfc1101002250629p6a246d08ke49e3bb25a91b510@mail.gmail.com> <20100225153506.1996b711.sldev@free.fr> Message-ID: <20100226004549.GA21514@alinoe.com> On Thu, Feb 25, 2010 at 03:35:06PM +0100, Henri Beauchamp wrote: > "Hello Henri, > > Thank you for contacting us regarding your issue. > > I am sorry but we can only offer support on issues with the official > SL viewer. > > We do not support any third party viewer as we are not responsible > for their software. > > If you experience the issue with the official viewer then we will > assist to the best of our ability. The only reasonable response to THIS, is faking a random MAC address in order to connect (if that is really the problem here). If they don't want to help, then you gotta help yourself. Seriously though, ... I imagine a not-so-smart person reading your technical support request and having no idea what you talk about. "MAC address? What is that? libomv light? Uh uh". Fortunately the phrase "text-only viewer" got through and brought a smile back on her face: pull-down menu, default response *click*. NEXT! "Oh, I'm so good at my work; dealing with like 5 requests per minute!". -- Carlo Wood From carlo at alinoe.com Thu Feb 25 16:49:38 2010 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 26 Feb 2010 01:49:38 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <20100225142849.c8107c2e.sldev@free.fr> <4ebfc1101002250628k34adf06y6eba4b7711660af2@mail.gmail.com> <4ebfc1101002250629p6a246d08ke49e3bb25a91b510@mail.gmail.com> <20100225153506.1996b711.sldev@free.fr> <4B86A929.5010203@gmail.com> <1267139291.3694.4342.camel@RAGE> <56c0988e1002251518w2bb32712mce02eae2d2c98e3b@mail.gmail.com> Message-ID: <20100226004938.GB21514@alinoe.com> On Thu, Feb 25, 2010 at 05:31:20PM -0600, Soft Linden wrote: > There have been no bans related to the TPV policy release. > > I know there's been some work on migrating some servers to a data > center with better connectivity to the other sims, etc. There was also > a login problem lasting a couple minutes yesterday around 19:30 > Pacific. I wouldn't be surprised if it was related to one of these. Instead of a "Sorry, we don't help you", support would better answer with "Sorry, we have not disabled null-MAC's yet, so it probably was a temporary problem, or should be. Can you still login with the normal viewer?" -- Carlo Wood From sldev at free.fr Thu Feb 25 16:58:11 2010 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 26 Feb 2010 01:58:11 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <20100226004938.GB21514@alinoe.com> References: <20100225142849.c8107c2e.sldev@free.fr> <4ebfc1101002250628k34adf06y6eba4b7711660af2@mail.gmail.com> <4ebfc1101002250629p6a246d08ke49e3bb25a91b510@mail.gmail.com> <20100225153506.1996b711.sldev@free.fr> <4B86A929.5010203@gmail.com> <1267139291.3694.4342.camel@RAGE> <56c0988e1002251518w2bb32712mce02eae2d2c98e3b@mail.gmail.com> <20100226004938.GB21514@alinoe.com> Message-ID: <20100226015811.79b1d1f1.sldev@free.fr> On Fri, 26 Feb 2010 01:49:38 +0100, Carlo Wood wrote: > On Thu, Feb 25, 2010 at 05:31:20PM -0600, Soft Linden wrote: > > There have been no bans related to the TPV policy release. > > > > I know there's been some work on migrating some servers to a data > > center with better connectivity to the other sims, etc. There was also > > a login problem lasting a couple minutes yesterday around 19:30 > > Pacific. I wouldn't be surprised if it was related to one of these. > > Instead of a "Sorry, we don't help you", support would better > answer with "Sorry, we have not disabled null-MAC's yet, so it > probably was a temporary problem, or should be. Can you still > login with the normal viewer?" Yes, and the answer to the latter question was already in my ticket... I did write in it that I was still able to login with a full fledged viewer (either official or third party) but not with text-only clients based on Mono... Which also makes me doubt very much it was just a glitch of the login server due to a migration or whatnot. Anyway... Whatever the cause or whoever the culprit, things are back to normal, and that's what counts, after all, even if the support is still as lame as ever. Henri. From aleric.inglewood at gmail.com Thu Feb 25 17:26:32 2010 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Fri, 26 Feb 2010 02:26:32 +0100 Subject: [opensource-dev] Snowglobe 2 update In-Reply-To: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> References: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> Message-ID: <1e01733d1002251726v7b26053fl7eb5e8a0be40d7c8@mail.gmail.com> On Wed, Feb 24, 2010 at 6:45 AM, Philippe (Merov) Bossut < merov at lindenlab.com> wrote: > I'm very happy personally to have Snowglobe now tracking the main viewer > (and getting out of the business of doing cherry pick merges of huge feature > sets...) so that our effort here can get to the main viewer faster while we > still maintain the freedom to experiment. > Do you mean that each individual commit to the internal 2.0 viewer will also result in a commit to snowglobe 2.0? No more monthly 100 kB merges that makes us lose all overview? > I'm really looking forward for more innovative Snowglobe developments now > we're back tracking the main code base. > I gotz some ideas }:-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100226/2a73f767/attachment.htm From carlo at alinoe.com Thu Feb 25 17:34:33 2010 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 26 Feb 2010 02:34:33 +0100 Subject: [opensource-dev] Request for help on compiling Snowglobe In-Reply-To: <4B858A5B.9060605@tamzap.com> References: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> <4B84E2A4.7080708@online.de> <201002240951.50605.Lance.Corrimal@eregion.de> <57A14FE6-1763-4136-AE01-C640A0EA29E6@uni-oldenburg.de> <4B858A5B.9060605@tamzap.com> Message-ID: <20100226013433.GC21514@alinoe.com> Linden Lab neither supports standalone nor 64bit. (Snowglobe is often broken for standalone because it's never tested by LL when they make changes). On top of that, almost non of the opensource developers that volunteer here use windows natively (I don't know of any). I know that Robin did some work on windows, but in a virtual machine I imagine? And he's really a debian guy, swamped with lots of work. I wish I could help, I haven't touched windows in my life :p Hopefully I'm wrong and some windows expert will jump out of nowhere, but otherwise I'm afraid that YOU will have to become our windows standalone-build expert. On Wed, Feb 24, 2010 at 03:21:47PM -0500, malachi wrote: > 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 -- Carlo Wood From carlo at alinoe.com Thu Feb 25 17:57:49 2010 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 26 Feb 2010 02:57:49 +0100 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <4B85F708.2050103@Gmail.com> References: <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> <4B85C980.5050900@tpg.com.au> <4B85CDFF.9070902@tpg.com.au> <4B85D355.3050608@tpg.com.au> <4B85D82E.3080203@gmail.com> <769bb4301002241824v79d46247p344a457dc5ab3522@mail.gmail.com> <4B85E688.8060306@tpg.com.au> <4B85EE3E.7020906@gmail.com> <4B85F708.2050103@Gmail.com> Message-ID: <20100226015749.GD21514@alinoe.com> On Thu, Feb 25, 2010 at 01:05:28AM -0300, 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? I'm not using textures, I'm just using UUID's. I'd like to see how law stops me from creating a new asset with the same UUID's as another asset. Long story short: it isn't about civil law. It's about LL letting as know what is their policy, what might cause them to stop viewers from connecting (or users from connecting) to their service. LL is not going to sue anyone for copyright infringment if you export a GPL script or a CSS texture, or when you write a viewer that allows all kinds of nasty things. They can't, since all of that is legal. I'm not a lawyer, but my understanding is that even if someone made some art, a photo of that art and then uploads that texture to SL, then by the act of uploading (due to the TOS) they can't sue LL or anyone else if they download that texture and view it in a viewer. What a "viewer" is is rather vague; but ok, lets say that then someone not only exports this texture but prints in a book and sells that book; then imho only the original copyright holder can sue that person, and still not LL; it's simply non of their business (although they might decide to ban the author of that book, but they can do that anyway, also without reason). -- Carlo Wood From secret.argent at gmail.com Thu Feb 25 18:50:24 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 25 Feb 2010 20:50:24 -0600 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <4B85647A.1030301@gmail.com> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> <4B8560E0.7060306@hp.com> <4B85647A.1030301@gmail.com> Message-ID: <5FA3CB11-8E57-4751-97E7-463102D1C701@gmail.com> Gigs... I think what you're looking at is akin to Tivoization, and providing an external source for Tivoized content is compatible with GPL2 (and is one reason for the GPL3). From sheet.spotter at gmail.com Thu Feb 25 20:58:16 2010 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Thu, 25 Feb 2010 22:58:16 -0600 Subject: [opensource-dev] Build problems with Snowglobe 2 source In-Reply-To: References: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com><4B84E2A4.7080708@online.de><20400C19-E4F1-402E-995D-EAC3CC2480CE@gmail.com> Message-ID: <2DDFCB8668454BC6BC9A4F7EDAD46EAE@kenb> After commenting out the entire "if (LL_TESTS)" section at the bottom of "indra/newview/CMakeLists.txt" the linker still had unresolved symbols. It's my guess that "llcapabilitylistener.cpp" should be added to the "CMakeLists.txt" section that starts with "set(viewer_SOURCE_FILES". Manually adding the "llcapabilitylistener.cpp" source file to the VS2005 project allowed me to compile and run again, but there are still some build issues. The "package" project produces the following output: 1>Processing ../win_crash_logger/RelWithDebInfo/windows-crash-logger.exe => win_crash_logger.exe ... 1 files 1>Processing ../win_updater/RelWithDebInfo/windows-updater.exe => updater.exe ... 1 files 1>Traceback (most recent call last): 1> File "C:/SLSource/SnowglobeV2/indra/newview/viewer_manifest.py", line 999, in 1> main() 1> File "C:/SLSource/SnowglobeV2/indra/newview\../lib/python/indra/util\llmanifest.p y", line 237, in main 1> wm.do(*args['actions']) 1> File "C:/SLSource/SnowglobeV2/indra/newview\../lib/python/indra/util\llmanifest.p y", line 664, in do 1> method() 1> File "C:/SLSource/SnowglobeV2/indra/newview/viewer_manifest.py", line 563, in package_finish 1> self.run_command('"' + proper_windows_path(NSIS_path) + '" ' + self.dst_path_of(tempfile)) 1>TypeError: cannot concatenate 'str' and 'NoneType' objects 1>Project : error PRJ0019: A tool returned an error code from "Generating RelWithDebInfo/touched.bat" I guess it's possible this build problem is self inflicted by the edits I made to "CMakeLists.txt". Sheet Spotter -----Original Message----- From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Matrice64 Sent: February 24, 2010 9:49 AM To: Argent Stonecutter Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Snowglobe 2 update 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 From kow at sapinski.com Thu Feb 25 21:07:22 2010 From: kow at sapinski.com (k\o\w) Date: Fri, 26 Feb 2010 00:07:22 -0500 Subject: [opensource-dev] Build problems with Snowglobe 2 source In-Reply-To: <2DDFCB8668454BC6BC9A4F7EDAD46EAE@kenb> References: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com><4B84E2A4.7080708@online.de><20400C19-E4F1-402E-995D-EAC3CC2480CE@gmail.com> <2DDFCB8668454BC6BC9A4F7EDAD46EAE@kenb> Message-ID: <4B87570A.1040700@sapinski.com> 1>Project : error PRJ0019: A tool returned an error code from "Generating RelWithDebInfo/touched.bat" go to build -> configuration manager and uncheck package (or invoke develop.py with -DPACKAGE:BOOL=OFF) to get rid of the above error. On 2/25/2010 11:58 PM, Sheet Spotter wrote: > After commenting out the entire "if (LL_TESTS)" section at the bottom of > "indra/newview/CMakeLists.txt" the linker still had unresolved symbols. > > It's my guess that "llcapabilitylistener.cpp" should be added to the > "CMakeLists.txt" section that starts with "set(viewer_SOURCE_FILES". > > Manually adding the "llcapabilitylistener.cpp" source file to the VS2005 > project allowed me to compile and run again, but there are still some build > issues. The "package" project produces the following output: > > 1>Processing ../win_crash_logger/RelWithDebInfo/windows-crash-logger.exe => > win_crash_logger.exe ... 1 files > 1>Processing ../win_updater/RelWithDebInfo/windows-updater.exe => > updater.exe ... 1 files > 1>Traceback (most recent call last): > 1> File "C:/SLSource/SnowglobeV2/indra/newview/viewer_manifest.py", line > 999, in > 1> main() > 1> File > "C:/SLSource/SnowglobeV2/indra/newview\../lib/python/indra/util\llmanifest.p > y", line 237, in main > 1> wm.do(*args['actions']) > 1> File > "C:/SLSource/SnowglobeV2/indra/newview\../lib/python/indra/util\llmanifest.p > y", line 664, in do > 1> method() > 1> File "C:/SLSource/SnowglobeV2/indra/newview/viewer_manifest.py", line > 563, in package_finish > 1> self.run_command('"' + proper_windows_path(NSIS_path) + '" ' + > self.dst_path_of(tempfile)) > 1>TypeError: cannot concatenate 'str' and 'NoneType' objects > 1>Project : error PRJ0019: A tool returned an error code from "Generating > RelWithDebInfo/touched.bat" > > I guess it's possible this build problem is self inflicted by the edits I > made to "CMakeLists.txt". > > > Sheet Spotter > > > -----Original Message----- > From: opensource-dev-bounces at lists.secondlife.com > [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Matrice64 > Sent: February 24, 2010 9:49 AM > To: Argent Stonecutter > Cc: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Snowglobe 2 update > > 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 > > _______________________________________________ > 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 > > From merov at lindenlab.com Thu Feb 25 21:22:58 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Thu, 25 Feb 2010 21:22:58 -0800 Subject: [opensource-dev] Snowglobe 2 update In-Reply-To: <78f69851002252122oba9aae9xc5d6d624aadd1d98@mail.gmail.com> References: <78f69851002232145s4d200655ga375dba83223e9ed@mail.gmail.com> <1e01733d1002251726v7b26053fl7eb5e8a0be40d7c8@mail.gmail.com> <78f69851002252122oba9aae9xc5d6d624aadd1d98@mail.gmail.com> Message-ID: <78f69851002252122k6a5deb9dx34b09ee43db26c4b@mail.gmail.com> Ooops... Meant to the list. There... :) - Merov On Thu, Feb 25, 2010 at 9:22 PM, Philippe (Merov) Bossut < merov at lindenlab.com> wrote: > Hi Aleric, > > On Thu, Feb 25, 2010 at 5:26 PM, Aleric Inglewood < > aleric.inglewood at gmail.com> wrote: > >> >> Do you mean that each individual commit to the internal 2.0 viewer will >> also result in a commit to snowglobe 2.0? No more monthly 100 kB merges >> that makes us lose all overview? >> > > No right now unfortunately because of the hg->svn export :/ We'll get that > granularity of history when we switch to hg completely but we need some > internal hg repo surgery before we can get there. It's a sizable project but > one we're taking in. > > In the meantime I need to finish my current script and push it > (literally...) to the main so that the export is as frequent as we > need/wish. Daily would be good. > > >> >>> I'm really looking forward for more innovative Snowglobe developments now >>> we're back tracking the main code base. >>> >> >> I gotz some ideas }:-) >> > > Bring it on! :) > > Cheers, > - Merov > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100225/ca4dc4dc/attachment.htm From bryon at slearth.com Thu Feb 25 22:01:48 2010 From: bryon at slearth.com (Bryon Ruxton) Date: Thu, 25 Feb 2010 22:01:48 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: Message-ID: A name suggestion for viewers: "A viewer that connect to a virtual world that can't be name for risks of being objected to by a company with aggressive lawyers who like to come up with unconscionable terms of services, or who make illegitimate attempts of one's right to forbid the usage of words they do not have trademark rights over" > "Unfortunately they maintain that we put our trademark at risk without consistent enforcement. They can't budge." Soft, they ought to consider that abusive overreach on their part could on the other end, put LL at risk of being liable once again of lawsuits being translated in court to unconscionable terms of services. Sounds familiar? As far I recall LL has the trademark over "SL" and "Second Life". So perhaps your lawyers could suck the "Life" out of their jurisdictions? I get the fact that they had to go an extra unusual mile with brand name protection due the nature of the company's name. But there was also an attempt to trademark the word "grid" alone, in the past. That speaks a lot! I don't see a need for concessions here, but for your lawyers to re-evaluate their legitimate rights to such claim to begin with. I just don't see it. If I was your marketing department. I would be equally concerned as to the repercussions of such restrictions for impeding the ability for Linden Research to promote its Second Life name and market itself as a grid. "Stop shooting yourself in the foot. It could impede your ability to walk." On 2/24/10 11:16 AM, "Soft Linden" wrote: > 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 > > From nexisentertainment at gmail.com Thu Feb 25 22:56:53 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Thu, 25 Feb 2010 22:56:53 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: Message-ID: <1267167413.3694.4721.camel@RAGE> I (obviously) agree. I highly doubt that trying to claim copyright on "Life" or "Second" in court would make the judge take the case seriously. What's next, claiming copyright on "primitive", "avatar", "lab", and "simulator"? Sending C&Ds to people who write viewers called Slick or Slanderous? Sending C&Ds to people who write programs that have nothing to do with Linden Lab whatsoever? Also, can anyone confirm/deny whether "Living" is also a forbidden term? RLV's developer blog has posted that "Living" was also rejected by Linden staff, but I'd like to hear it from the horse's mouth. If so, I might as well move my viewer over to OpenSim exclusively, and not have to bother with overbearing regulations and rabid lawyers at all. When you spend so much time harassing legitimate viewers, and so little time going after the people who are actually damaging you, you need to re-check your priorities. People who write Copybots and NeilLife-like viewers are your enemies (they're certainly not going to spend much money), so go after them instead of having everyone else jump through hoops that the copybotters are going to ignore anyway. All you're doing is making it harder for legitimate people to create content and applications for your grid. Also, are we going to see enforcement of this, or is it going to quietly disappear after about a week like all of the other Copybot/Content theft-related promises we've heard on the blog? Rob Nelson Lead Developer Luna Viewer (http://luna-viewer.googlecode.com) On Thu, 2010-02-25 at 22:01 -0800, Bryon Ruxton wrote: > A name suggestion for viewers: "A viewer that connect to a virtual world > that can't be name for risks of being objected to by a company with > aggressive lawyers who like to come up with unconscionable terms of > services, or who make illegitimate attempts of one's right to forbid the > usage of words they do not have trademark rights over" > > > "Unfortunately they maintain that we put our trademark at risk without > consistent enforcement. They can't budge." > Soft, they ought to consider that abusive overreach on their part could on > the other end, put LL at risk of being liable once again of lawsuits being > translated in court to unconscionable terms of services. Sounds familiar? > > As far I recall LL has the trademark over "SL" and "Second Life". > So perhaps your lawyers could suck the "Life" out of their jurisdictions? > > I get the fact that they had to go an extra unusual mile with brand name > protection due the nature of the company's name. But there was also an > attempt to trademark the word "grid" alone, in the past. That speaks a lot! > > I don't see a need for concessions here, but for your lawyers to re-evaluate > their legitimate rights to such claim to begin with. I just don't see it. > > If I was your marketing department. I would be equally concerned as to the > repercussions of such restrictions for impeding the ability for Linden > Research to promote its Second Life name and market itself as a grid. > > "Stop shooting yourself in the foot. It could impede your ability to walk." > > > On 2/24/10 11:16 AM, "Soft Linden" wrote: > > > 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 > > > > > > > _______________________________________________ > 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 From Lance.Corrimal at eregion.de Thu Feb 25 23:24:32 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 26 Feb 2010 08:24:32 +0100 Subject: [opensource-dev] Third party viewer policy Message-ID: <201002260824.32466.Lance.Corrimal@eregion.de> 250% ACK! Am Freitag 26 Februar 2010 schrieb Rob Nelson: > I (obviously) agree. > > I highly doubt that trying to claim copyright on "Life" or "Second" > in court would make the judge take the case seriously. What's > next, claiming copyright on "primitive", "avatar", "lab", and > "simulator"? Sending C&Ds to people who write viewers called Slick > or Slanderous? Sending C&Ds to people who write programs that have > nothing to do with Linden Lab whatsoever? > > Also, can anyone confirm/deny whether "Living" is also a forbidden > term? RLV's developer blog has posted that "Living" was also > rejected by Linden staff, but I'd like to hear it from the horse's > mouth. If so, I might as well move my viewer over to OpenSim > exclusively, and not have to bother with overbearing regulations > and rabid lawyers at all. > > When you spend so much time harassing legitimate viewers, and so > little time going after the people who are actually damaging you, > you need to re-check your priorities. People who write Copybots > and NeilLife-like viewers are your enemies (they're certainly not > going to spend much money), so go after them instead of having > everyone else jump through hoops that the copybotters are going to > ignore anyway. All you're doing is making it harder for > legitimate people to create content and applications for your > grid. > > Also, are we going to see enforcement of this, or is it going to > quietly disappear after about a week like all of the other > Copybot/Content theft-related promises we've heard on the blog? > > Rob Nelson > Lead Developer > Luna Viewer (http://luna-viewer.googlecode.com) > > On Thu, 2010-02-25 at 22:01 -0800, Bryon Ruxton wrote: > > A name suggestion for viewers: "A viewer that connect to a > > virtual world that can't be name for risks of being objected to > > by a company with aggressive lawyers who like to come up with > > unconscionable terms of services, or who make illegitimate > > attempts of one's right to forbid the usage of words they do not > > have trademark rights over" > > > > > "Unfortunately they maintain that we put our trademark at risk > > > without > > > > consistent enforcement. They can't budge." > > Soft, they ought to consider that abusive overreach on their part > > could on the other end, put LL at risk of being liable once again > > of lawsuits being translated in court to unconscionable terms of > > services. Sounds familiar? > > > > As far I recall LL has the trademark over "SL" and "Second Life". > > So perhaps your lawyers could suck the "Life" out of their > > jurisdictions? > > > > I get the fact that they had to go an extra unusual mile with > > brand name protection due the nature of the company's name. But > > there was also an attempt to trademark the word "grid" alone, in > > the past. That speaks a lot! > > > > I don't see a need for concessions here, but for your lawyers to > > re-evaluate their legitimate rights to such claim to begin with. > > I just don't see it. > > > > If I was your marketing department. I would be equally concerned > > as to the repercussions of such restrictions for impeding the > > ability for Linden Research to promote its Second Life name and > > market itself as a grid. > > > > "Stop shooting yourself in the foot. It could impede your ability > > to walk." > > > > On 2/24/10 11:16 AM, "Soft Linden" wrote: > > > 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 > > > > _______________________________________________ > > 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 > From Lance.Corrimal at eregion.de Fri Feb 26 00:51:53 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 26 Feb 2010 09:51:53 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <4B8437AC.30004@gmail.com> References: <4B8437AC.30004@gmail.com> Message-ID: <201002260951.53411.Lance.Corrimal@eregion.de> from the slu forum: (posted by ceera murakami) Guess what? All of LL's own clients violate the new rules for 3rd party clients. Because they allow you to export a full-perms texture that you did NOT create, and to re-upload it as created by you, changing the metadata! From sldev at free.fr Fri Feb 26 00:53:23 2010 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 26 Feb 2010 09:53:23 +0100 Subject: [opensource-dev] Third party viewer policy In-Reply-To: <1267167413.3694.4721.camel@RAGE> References: <1267167413.3694.4721.camel@RAGE> Message-ID: <20100226095323.901407a5.sldev@free.fr> On Thu, 25 Feb 2010 22:56:53 -0800, Rob Nelson wrote: > I (obviously) agree. > > I highly doubt that trying to claim copyright on "Life" or "Second" in > court would make the judge take the case seriously. What's next, > claiming copyright on "primitive", "avatar", "lab", and "simulator"? > Sending C&Ds to people who write viewers called Slick or Slanderous? > Sending C&Ds to people who write programs that have nothing to do with > Linden Lab whatsoever? Completely seconded... For a start, trademarking a single, common word is illegal in many countries (EU countries fall under this case). Second, I want to point out that following Lince Lab's (r)(c)(tm) own trademark policy, the use of "Life" in a name is not forbidden. Please, see: http://secondlife.com/corporate/brand/trademark/unauthorized.php So, what exactly is all this fuss about ??? Soft, care to try and explain us ?... Or perhaps one of the LL's lawyers could post on this list to explain their exact stance on this matter ? Henri. From sldev at free.fr Fri Feb 26 00:57:16 2010 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 26 Feb 2010 09:57:16 +0100 Subject: [opensource-dev] Third party viewer policy Message-ID: <20100226095716.5fa48201.sldev@free.fr> I wrote: > Second, I want to point out that following Lince Lab's (r)(c)(tm) Please, read "Linden Lab" (typing too fast, sometimes...) And I'll add a question too: Are OpenLife folks going to be sued by Linden Labd for using "Life" in their name ??? Henri. From morgaine.dinova at googlemail.com Fri Feb 26 02:14:11 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Fri, 26 Feb 2010 10:14:11 +0000 Subject: [opensource-dev] "Resposibility" - Third party viewer policy In-Reply-To: <77c421f01002251030m11717108xe97bc3aa48d8c2a0@mail.gmail.com> References: <201002240952.08231.Lance.Corrimal@eregion.de> <4B85472B.5020804@gmail.com> <77c421f01002251030m11717108xe97bc3aa48d8c2a0@mail.gmail.com> Message-ID: Colin, there is a problem in the way that you are reading the TPV. You are using commonsense. That is not how law works. It deals in what is actually written down. And what is written down is not commonsense. The actual words in the TPV, separate from any sane person's interpretation of what they SHOULD refer to, *explicitly state* that a developer must do X, Y, Z in order to be allowed to distribute her modified GPL program, and that is incompatible with GPLv2 (in fact, with all versions of GPL). One Linden defined the problem very well in group chat yesterday: The TPV talks about developers and users *simultaneously*, which causes confusion, and as a result of that confusion there are restrictions imposed on developers which should apply only to users. It is those restrictions, which are very sensible when applied to users, that are not GPL compatible when applied to developers, because they are an additional restriction on the GPL-granted freedoms to modify and distribute a GPL program. Such additional restrictions are expressly forbidden by GPLv2 clause 6. Apparently those restrictions on developers were not intentional. The TPV should never have been written by someone who doesn't understand deeply the details of the GPL and who does not have a good command of legal-type language, which requires high precision in wording. They didn't even understand the meaning of "NO WARRANTY", written in capital letters in the GPLv2 license. Allegedly that's the only problem with the TPV, an incompetently written document, not evil intent. Of course there is also the insanity of Linden Lab trying to claim trademark domain over the word "Life". For that, the Linden lawyers deserve nothing but a good kicking. (Do it now!) Just because lawyers throughout the US behave like idiots doesn't mean that Linden lawyers must follow in the footsteps of idiocy. Morgaine. =================================== On Thu, Feb 25, 2010 at 6:30 PM, Colin Kern wrote: > On Wed, Feb 24, 2010 at 10:35 AM, Vex Streeter > wrote: > > > > 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. > > > > Nothing in the TPV contradicts or violates the GPL, because the GPL is > all about distribution of software, and the TPV is about whether or > not LL will allow a viewer to connect to their servers, not whether > you'll be allowed to distribute it. > > Colin > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100226/bfb437c3/attachment.htm From Lance.Corrimal at eregion.de Fri Feb 26 02:31:24 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 26 Feb 2010 11:31:24 +0100 Subject: [opensource-dev] "Resposibility" - Third party viewer policy In-Reply-To: References: <201002240952.08231.Lance.Corrimal@eregion.de> <77c421f01002251030m11717108xe97bc3aa48d8c2a0@mail.gmail.com> Message-ID: <201002261131.24836.Lance.Corrimal@eregion.de> Am Freitag, 26. Februar 2010 11:14:11 schrieb Morgaine: > The TPV should never have been written by someone who doesn't understand > deeply the details of the GPL and who does not have a good command of > legal-type language, which requires high precision in wording. They didn't > even understand the meaning of "NO WARRANTY", written in capital letters in > the GPLv2 license. You are (wrongly?) assuming that those people (I don't dare call them lawyers because I get a strong odor of "no clue about licensing law at all" here) actually read the GPL. > Of course there is also the insanity of Linden Lab trying to claim > trademark domain over the word "Life". For that, the Linden lawyers > deserve nothing but a good kicking. (Do it now!) Just because lawyers > throughout the US behave like idiots doesn't mean that Linden lawyers must > follow in the footsteps of idiocy. Again, what makes anyone sure that those guys are real lawyers? From morgaine.dinova at googlemail.com Fri Feb 26 02:37:46 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Fri, 26 Feb 2010 10:37:46 +0000 Subject: [opensource-dev] "Second-Party" viewer policy (was: Third party viewer policy) In-Reply-To: References: <012E4081-AC93-43A9-89C2-65CAC87EFFCF@mac.com> Message-ID: Careful with the wording, Soft. :-) [Bad wording is the reason for much of this thread, sadly.] You didn't actually mean, I hope: "Most apply to any third-party viewer however, even if you aren't distributing it." What you meant was, I hope: "Most apply to any third-party viewer when that viewer connects to the SL service, even if you aren't distributing it." Legally, there is a world of difference. The original wording applies also when the third party viewer is used to connect to Opensim, for example, which you have no legal power nor community-friendly reason to restrict. We don't usually need to speak with mind-numbing precision, and can rely on context for brevity, but that absolutely does not work in the current subject with its legal ramifications. These dratted words, they're such a pain. Instead of saying what we mean, they say what they say. :D Morgaine. ===================================== On Thu, Feb 25, 2010 at 10:29 PM, Soft Linden wrote: > On Thu, Feb 25, 2010 at 3:37 PM, Jay Reynolds Freeman > wrote: > > > > But what if there is no "third party"? What if I develop a modified > version of the SL viewer all by myself, and use it to log in to the SL > servers, but do not distribute either source or binary for it? Since there > is no additional, "third" party involved in the creation and use of this > viewer, it would appear that nothing in the "Linden Lab Policy on > Third-Party Viewers" applies to it or to me. > > > > The FAQ and revised TPV, coming soon, will address this directly. > There are some terms in there that don't apply if you aren't putting > the viewer in the registry, and they will be identified as such. Most > apply to any third-party viewer however, even if you aren't > distributing 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100226/3d7efceb/attachment.htm From morgaine.dinova at googlemail.com Fri Feb 26 02:53:34 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Fri, 26 Feb 2010 10:53:34 +0000 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <5FA3CB11-8E57-4751-97E7-463102D1C701@gmail.com> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> <4B8560E0.7060306@hp.com> <4B85647A.1030301@gmail.com> <5FA3CB11-8E57-4751-97E7-463102D1C701@gmail.com> Message-ID: Argent, now that you mention GPLv3, it's worth pointing out that if LL relicensed their sources to GPLv3 then they would be prevented from suing GPL developers for patent infringement (under fear of loss of GPL rights), because of GPLv3's patent retaliation clause. That would remove one source of worry that projects like Opensim currently believe they have. Morgaine. ==================================== On Fri, Feb 26, 2010 at 2:50 AM, Argent Stonecutter wrote: > Gigs... I think what you're looking at is akin to Tivoization, and > providing an external source for Tivoized content is compatible with > GPL2 (and is one reason for the GPL3). > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100226/5299769d/attachment-0001.htm From techiedavid at gmail.com Fri Feb 26 03:27:07 2010 From: techiedavid at gmail.com (David Simmons) Date: Fri, 26 Feb 2010 03:27:07 -0800 Subject: [opensource-dev] "Second-Party" viewer policy (was: Third party viewer policy) In-Reply-To: References: <012E4081-AC93-43A9-89C2-65CAC87EFFCF@mac.com> Message-ID: <3a164ef31002260327x2a4d0005o2286ddcc56ce502f@mail.gmail.com> The common sense rules apply. If you are not connecting to the LL grid, Linden Lab can't make any policy regarding what you do. They don't need a policy saying that they can't make a policy telling you what to do on another grid. They are just trying to put into policy what LL has expressed in one way or other over the years. Remember policy are not written for those that are honest, but for those that are dishonest and having a way to enforce it. For example; in my workplace we have an 1/2 hour lunch. I have yet to see a supervisor watch the clock on anyone, but if someone decides to take off for 2 hours and call it lunch, they will be in trouble. On Fri, Feb 26, 2010 at 2:37 AM, Morgaine wrote: > Careful with the wording, Soft. :-)? [Bad wording is the reason for much of > this thread, sadly.] > > You didn't actually mean, I hope: "Most apply to any third-party viewer > however, even if you aren't distributing it." > > What you meant was, I hope: "Most apply to any third-party viewer when that > viewer connects to the SL service, even if you aren't distributing it." > > Legally, there is a world of difference.? The original wording applies also > when the third party viewer is used to connect to Opensim, for example, > which you have no legal power nor community-friendly reason to restrict. > > We don't usually need to speak with mind-numbing precision, and can rely on > context for brevity, but that absolutely does not work in the current > subject with its legal ramifications. > > These dratted words, they're such a pain.? Instead of saying what we mean, > they say what they say. :D > > > Morgaine. > > > > ===================================== > > On Thu, Feb 25, 2010 at 10:29 PM, Soft Linden wrote: >> >> On Thu, Feb 25, 2010 at 3:37 PM, Jay Reynolds Freeman >> wrote: >> > >> > But what if there is no "third party"? ?What if I develop a modified >> > version of the SL viewer all by myself, and use it to log in to the SL >> > servers, but do not distribute either source or binary for it? ?Since there >> > is no additional, "third" party involved in the creation and use of this >> > viewer, it would appear that nothing in the "Linden Lab Policy on >> > Third-Party Viewers" applies to it or to me. >> > >> >> The FAQ and revised TPV, coming soon, will address this directly. >> There are some terms in there that don't apply if you aren't putting >> the viewer in the registry, and they will be identified as such. Most >> apply to any third-party viewer however, even if you aren't >> distributing 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 > > > _______________________________________________ > 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 > -- ?The greatest danger in modern technology isn't that machines will begin to think like people, but that people will begin to think like machines? Unknown http://www.google.com/profiles/techiedavid From lenglish5 at cox.net Fri Feb 26 06:04:30 2010 From: lenglish5 at cox.net (Lawson English) Date: Fri, 26 Feb 2010 07:04:30 -0700 Subject: [opensource-dev] "Second-Party" viewer policy (was: Third party viewer policy) In-Reply-To: <3a164ef31002260327x2a4d0005o2286ddcc56ce502f@mail.gmail.com> References: <012E4081-AC93-43A9-89C2-65CAC87EFFCF@mac.com> <3a164ef31002260327x2a4d0005o2286ddcc56ce502f@mail.gmail.com> Message-ID: <4B87D4EE.1010400@cox.net> David Simmons wrote: > The common sense rules apply. If you are not connecting to the LL > grid, Linden Lab can't make any policy regarding what you do. They > don't need a policy saying that they can't make a policy telling you > what to do on another grid. > They are just trying to put into policy what LL has expressed in one > way or other over the years. Remember policy are not written for those > that are honest, but for those that are dishonest and having a way to > enforce it. For example; in my workplace we have an 1/2 hour lunch. I > have yet to see a supervisor watch the clock on anyone, but if someone > decides to take off for 2 hours and call it lunch, they will be in > trouble. > > > You have nice supervisors who don't hold a grudge against anyone, or whose superiors don't hold a grudge against anyone. Lawson > > > From gigstaggart at gmail.com Fri Feb 26 07:38:48 2010 From: gigstaggart at gmail.com (Gigs) Date: Fri, 26 Feb 2010 10:38:48 -0500 Subject: [opensource-dev] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses In-Reply-To: <5FA3CB11-8E57-4751-97E7-463102D1C701@gmail.com> References: <4B854576.6050006@gmail.com> <4B8553EC.7060707@tpg.com.au> <4B855CC5.1060504@gmail.com> <4B8560E0.7060306@hp.com> <4B85647A.1030301@gmail.com> <5FA3CB11-8E57-4751-97E7-463102D1C701@gmail.com> Message-ID: <4B87EB08.7090706@gmail.com> Argent Stonecutter wrote: > Gigs... I think what you're looking at is akin to Tivoization, and > providing an external source for Tivoized content is compatible with > GPL2 (and is one reason for the GPL3). > CC-SA has no external source provision, and specifically forbids any copy protection being applied to the content. If people are free to turn CC-SA content non-free by uploading it to a service that requires every user to agree not to exercise their rights under CC-SA, then CC-SA is fundamentally flawed. -Jason From sllists at boroon.dasgupta.ch Fri Feb 26 07:42:52 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 26 Feb 2010 16:42:52 +0100 Subject: [opensource-dev] Questions about Second Life Viewer Contribution Agreement In-Reply-To: <4AEB7187.60900@boroon.dasgupta.ch> References: <20462232.1255627195311.JavaMail.root@lindenlab1> <4AEB7187.60900@boroon.dasgupta.ch> Message-ID: <4B87EBFC.7080100@boroon.dasgupta.ch> Hi all Robin said on #opensl she thinks I should become a committer. However I don't feel able to sign the Contribution Agreement, as some questions I have about it still aren't answered. I have sent them to contributions at lindenlab.com back in October, and still haven't received a reply. I talked to Merov back then and he asked legal several times about it, but apparently they were "busy". Here's my original mail to contributions at lindenlab.com: > Dear Sir or Madam > > at > http://jira.secondlife.com/browse/SNOW-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=140775#action_140775 > I was asked to file a contribution agreement. The agreement itself > says, in part: >> If you have questions about these terms, please contact us at >> contributions at lindenlab.com. > > As I actually do have some questions, that's what I'm doing herewith. > I'll quote the relevant parts of the agreement. Any emphasis was added > by me. > >> 3. You hereby grant to Linden Lab, and to any party who >> receives Your Contribution, a perpetual, >> irrevocable, non-exclusive, worldwide, no-charge, royalty-free, >> license under any patents owned by or licensable by >> You at any time without payment to third parties, to make, have made, >> use, sell, offer to sell, import and otherwise >> transfer Your Contribution *in whole or in part, alone or in >> combination with or included in any product, work or >> materials* arising out of the SL Viewer Project, and to sublicense >> the foregoing rights to third parties through >> multiple tiers of sublicensees or other licensing mechanisms at >> Linden Lab's option. > I understand that this demands, that I grant licences to my present > and future patents on any technology that my contributions introduce. > I.e. when the Second Life Viewer (hereafter "the Viewer") prior to my > contribution didn't have the patented technology, but the Viewer (as > it was at the time the respective contribution was made) combined with > my contribution has it, then I must grant the licences. > > What's unclear to me is if I have to also grant patent licences in the > following cases: > > * The Viewer (at the time of contribution) combined with my > contribution isn't affected by my patents, then someone else > (Linden Lab or a third party) adds (on top of my contribution) > something that is affected by my patents. > * The Viewer combined with my contribution isn't affected by my > patents, but someone else takes my contribution and combines it > with another (e.g. their own) work such that this combination is > affected by my patents. (Obviously, this can only be the case > for contributions that implement different technologies when > combined with different works, which -- while possible in theory > -- might be rather hypothetical in practice. Though one never > knows, so I want to make sure.) > * The Viewer combined with my contribution isn't affected by my > patents, but someone takes my contribution and combines it with > another (e.g. their own) work which was affected by my patents > already without my contribution. > > >> 5. You represent and warrant that You are legally entitled to >> grant the above assignment and licenses. [...] You represent and >> warrant *that the Contribution is Your original work of authorship*, >> and to the best >> of Your knowledge, does not violate any other party's copyrights, >> trademarks, patents or other intellectual property >> rights, and that no other person claims, or has the right to claim, >> any right in any invention or patent related to the >> Contribution. > What about contributions based on other people's contributions to the > Second Life Viewer project, when those contributions haven't (yet) > been accepted and integrated and so aren't (yet) available under GPL > (except the original contributor said so)? (E.g. my > http://jira.secondlife.com/secure/attachment/28350/VWR-5370_rediffed_for_SNOW.patch > is heavily based on Latif Khalifa's > http://jira.secondlife.com/secure/attachment/20869/v2_llfloaterchatterbox.h.patch > which is still in QA) > > I'm looking forward to your answers to these concerns, so I can > hopefully sign and submit the agreement. > > (inworld: Boroondas Gupte) later I followed up with this: > Dear Sir or Madam > > As I haven't heard back from you for two weeks about my questions (cited > below), I'd like to make clear that I'm not seeking legal advice, which > I know you can only give to employees. I'd just like to know what you > meant (applied to the cases I listed in my questions) when you wrote the > agreement. > > If you feel you cannot answer (some of) the questions, please tell me > about that. If it was because of unclearly formulated questions or > cases, I might be able to clarify. If the answers just aren't known, > that'd be useful to know, too. > > Yours faithfully, > (inworld: Boroondas Gupte) > > > I'm not really looking for IANAL answers from this list, but I thought it might be good to make my questions public, as others might have the same or similar ones. I'd still appreciate any authoritative answers. cheers Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100226/1f9a0804/attachment.htm From tigrospottystripes at gmail.com Fri Feb 26 10:44:04 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 26 Feb 2010 15:44:04 -0300 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <012E4081-AC93-43A9-89C2-65CAC87EFFCF@mac.com> Message-ID: <4B881674.3080003@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Soft, i think perhaps it would be better if there were separated documents each focusing on one single target (developers who distribute, developers who don't, users, content creators etc), having it all mixed together makes the risk of misinterpretation much higher. On 25/2/2010 19:29, Soft Linden wrote: > On Thu, Feb 25, 2010 at 3:37 PM, Jay Reynolds Freeman > wrote: >> >> But what if there is no "third party"? What if I develop a modified version of the SL viewer all by myself, and use it to log in to the SL servers, but do not distribute either source or binary for it? Since there is no additional, "third" party involved in the creation and use of this viewer, it would appear that nothing in the "Linden Lab Policy on Third-Party Viewers" applies to it or to me. >> > > The FAQ and revised TPV, coming soon, will address this directly. > There are some terms in there that don't apply if you aren't putting > the viewer in the registry, and they will be identified as such. Most > apply to any third-party viewer however, even if you aren't > distributing 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuIFlcACgkQ8ZFfSrFHsmWwXwCbBLfNMbJubJ7Nd5QXEFbdlGfw ng4An3tH7kT1S2KDkld3/qnVjKIlHb36 =eJkb -----END PGP SIGNATURE----- From techiedavid at gmail.com Fri Feb 26 10:59:12 2010 From: techiedavid at gmail.com (David Simmons) Date: Fri, 26 Feb 2010 10:59:12 -0800 Subject: [opensource-dev] Third party viewer policy In-Reply-To: References: <001801cab5d1$a1206e90$7a00a8c0@hp> Message-ID: <3a164ef31002261059m50435377q800d0c0bfa276deb@mail.gmail.com> I think the ideal they have is that you shouldn't create a viewer that can do content thief, grieving or whatever is the next abuse method is and claim that you can't control how people use the viewer. Especially since we have already seen viewers designed already to abuse the grid. Another interesting things is that LL don't take any liability of what the residents do in the grid but want a developer to is kinda crazy. A better approach might be for the developer to agree patch any abuses that LL has identify due to user actions. On Wed, Feb 24, 2010 at 9:59 PM, Morgaine wrote: > 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 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 > > > _______________________________________________ > 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 > -- ?The greatest danger in modern technology isn't that machines will begin to think like people, but that people will begin to think like machines? Unknown http://www.google.com/profiles/techiedavid From lenglish5 at cox.net Fri Feb 26 13:33:31 2010 From: lenglish5 at cox.net (Lawson English) Date: Fri, 26 Feb 2010 14:33:31 -0700 Subject: [opensource-dev] [Fwd: [realXtend] Presentation of naali viewer and realXtend to AW Groupies...] Message-ID: <4B883E2B.8050406@cox.net> For anyone who has an interest in SL viewers that are not part of the Linden Lab GPL tree, we've invited developers from the realXtend project to make a presentation to the AW Groupies this Tuesday at 8:30 AM SLT (to allow for a rather large time zone difference). http://www.realxtend.org/ We are hoping to have a large, technically minded (for the most part) audience who are prepared to ask tough questions. Non-techies are certainly welcome to come and ask questions as well. The topic should be about both programming and non-programming issues. IM me, Saijanai Kuhn, in-world sometime before the meeting in order to get a group invite to get to the island. Zha generally opens the island to non-members during these presentations, but in case something goes wrong, its easier to be part of the group, at least during the meeting. That way you can participate in the group chatter as well. That will be 8:30AM SLT this coming Tuesday. 6:30 PM EET. at http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/129/24 This was sent to the realXtend list: Toni has said he can make it to the Groupies meeting this coming Tuesday at 8:30 AM SLT (6:30 PM EET I believe) and Zha Ewry says she can ensure it will be available at that time. It would certainly be great to have more than one person there from realXtend. When we invited the Open Cobalt team, we ended up asking enough questions to overwhelm just one person. Also, whoever comes should understand that the range of questions is HUGE: we have people who use SL for education and handicap-access that might be attending. Likewise, the metanomics team sometimes attends. Other viewer developers are often around, as well as Lindens and contributors to OpenSim from IBM and so on. If I work on it, I can probably fill up the sim (80 avatars) with interested people with enough background to ask decent questions, both about the programming and your long-term plans for how realxtend might be used. So anyone who wants to attend and help answer questions about naali and realxtend should feel free to give me (Saijanai Kuhn) an IM in Second Life so I can invite you to the island for the presentation. That will be 8:30AM SLT this coming Tuesday. 6:30 PM EET. at http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/129/24 Hope to see you all there. Lawson English (Saijanai Kuhn in Second Life) -- http://groups.google.com/group/realxtend http://www.realxtend.org -------------- next part -------------- An embedded message was scrubbed... From: Lawson English Subject: [realXtend] Presentation of naali and realXtend to AW Groupies... Date: Fri, 26 Feb 2010 14:24:24 -0700 Size: 6978 Url: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100226/d3c0749f/attachment.eml From missannotoole at yahoo.com Fri Feb 26 18:40:30 2010 From: missannotoole at yahoo.com (Ann Otoole) Date: Fri, 26 Feb 2010 18:40:30 -0800 (PST) Subject: [opensource-dev] Third party viewer policy In-Reply-To: <20100225124028.54f7e4ce.sldev@free.fr> References: <4B8437AC.30004@gmail.com> <201002251157.21630.Lance.Corrimal@eregion.de> <20100225121823.e44c3216.sldev@free.fr> <201002251231.13769.Lance.Corrimal@eregion.de> <20100225124028.54f7e4ce.sldev@free.fr> Message-ID: <279674.84644.qm@web59105.mail.re1.yahoo.com> I've already learned the hard way time spent in or around Second Life is a career death sentence. It doesn't matter what happens down the road. The taint is permanent. Second Life cannot be mentioned in public. Time in this business is lost years. ________________________________ From: Henri Beauchamp To: opensource-dev at lists.secondlife.com Sent: Thu, February 25, 2010 6:40:28 AM Subject: Re: [opensource-dev] Third party viewer policy On Thu, 25 Feb 2010 12:31:13 +0100, Lance Corrimal wrote: > Am Donnerstag, 25. Februar 2010 12:18:23 schrieb Henri Beauchamp: > > > My guess is that we will soon hear about discriminations based on > > private info gathered on Internet (Employee: "oh, why can't I get this > > job, sir ?" - Employer: "Because you use your avatar in SL to rolepay > > BDSM, you sicko !"). > > > given how MANY people are really kinky on SL I'd expect that to turn out the > other way: > > "You're hired but only if you tie me to this cross and take me from behind you > stud you! I KNOW You like that stuff!" Lol ! I'll consider that option... _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100226/8e01902d/attachment.htm From soft at lindenlab.com Fri Feb 26 19:14:52 2010 From: soft at lindenlab.com (Soft Linden) Date: Fri, 26 Feb 2010 21:14:52 -0600 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy Message-ID: There's now a FAQ for the Linden Lab Policy on Third Party Viewers: http://bit.ly/caedse This addresses many of the questions and concerns made in opensource-dev and elsewhere. An updated version of the TPV doc itself is also coming, but expect this within a couple weeks. Go visit the FAQ, or read on for the TPV doc update details... I know that the member of the legal team who owns the policy doc is still working over the final version. Linden Lab has approached outside legal experts with your feedback, and one of these experts is a lawyer who specializes in open source license compliance issues. Based on these experts' feedback and further internal review, our legal department will incorporate any required changes. In the meantime, while it helps to start making changes now, parts of the policy are not yet in effect. See the tail of the FAQ for dates and the portions affected. From tigrospottystripes at gmail.com Fri Feb 26 19:32:12 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 27 Feb 2010 00:32:12 -0300 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <4B88923C.304@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 sounds promising, thanx :) On 27/2/2010 00:14, Soft Linden wrote: > There's now a FAQ for the Linden Lab Policy on Third Party Viewers: > http://bit.ly/caedse > > This addresses many of the questions and concerns made in > opensource-dev and elsewhere. An updated version of the TPV doc itself > is also coming, but expect this within a couple weeks. Go visit the > FAQ, or read on for the TPV doc update details... > > I know that the member of the legal team who owns the policy doc is > still working over the final version. Linden Lab has approached > outside legal experts with your feedback, and one of these experts is > a lawyer who specializes in open source license compliance issues. > Based on these experts' feedback and further internal review, our > legal department will incorporate any required changes. > > In the meantime, while it helps to start making changes now, parts of > the policy are not yet in effect. See the tail of the FAQ for dates > and the portions affected. > _______________________________________________ > 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/ iEYEARECAAYFAkuIkh4ACgkQ8ZFfSrFHsmXhjwCdHY0gOyC0ZVUfPfZKjzT+dU54 nzUAn1nKikPcBK9Y3JiuT40ugNWCHdMs =SGo+ -----END PGP SIGNATURE----- From nexisentertainment at gmail.com Fri Feb 26 19:55:21 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Fri, 26 Feb 2010 19:55:21 -0800 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <1267242921.3694.4778.camel@RAGE> Two months to make changes? I was told we had 3 months. On Fri, 2010-02-26 at 21:14 -0600, Soft Linden wrote: > There's now a FAQ for the Linden Lab Policy on Third Party Viewers: > http://bit.ly/caedse > > This addresses many of the questions and concerns made in > opensource-dev and elsewhere. An updated version of the TPV doc itself > is also coming, but expect this within a couple weeks. Go visit the > FAQ, or read on for the TPV doc update details... > > I know that the member of the legal team who owns the policy doc is > still working over the final version. Linden Lab has approached > outside legal experts with your feedback, and one of these experts is > a lawyer who specializes in open source license compliance issues. > Based on these experts' feedback and further internal review, our > legal department will incorporate any required changes. > > In the meantime, while it helps to start making changes now, parts of > the policy are not yet in effect. See the tail of the FAQ for dates > and the portions affected. > _______________________________________________ > 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 From soft at lindenlab.com Fri Feb 26 19:59:20 2010 From: soft at lindenlab.com (Soft Linden) Date: Fri, 26 Feb 2010 21:59:20 -0600 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <1267242921.3694.4778.camel@RAGE> References: <1267242921.3694.4778.camel@RAGE> Message-ID: That was specifically for viewer naming - 5.b. If you run up against that date and need more time, ping me with the viewer name. I'll remind legal that they previously granted 3 months. On Fri, Feb 26, 2010 at 9:55 PM, Rob Nelson wrote: > Two months to make changes? ?I was told we had 3 months. > > On Fri, 2010-02-26 at 21:14 -0600, Soft Linden wrote: >> There's now a FAQ for the Linden Lab Policy on Third Party Viewers: >> http://bit.ly/caedse >> >> This addresses many of the questions and concerns made in >> opensource-dev and elsewhere. An updated version of the TPV doc itself >> is also coming, but expect this within a couple weeks. Go visit the >> FAQ, or read on for the TPV doc update details... >> >> I know that the member of the legal team who owns the policy doc is >> still working over the final version. Linden Lab has approached >> outside legal experts with your feedback, and one of these experts is >> a lawyer who specializes in open source license compliance issues. >> Based on these experts' feedback and further internal review, our >> legal department will incorporate any required changes. >> >> In the meantime, while it helps to start making changes now, parts of >> the policy are not yet in effect. See the tail of the FAQ for dates >> and the portions affected. >> _______________________________________________ >> 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 > > > From jessesa at gmail.com Fri Feb 26 20:03:50 2010 From: jessesa at gmail.com (Jesse Barnett) Date: Fri, 26 Feb 2010 23:03:50 -0500 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: Thank you for the hard work there Soft. It answers all of the questions I have except for this section: "What is the meaning of the Viewer Directory eligibility requirement that "your Second Life accounts must be in good standing, must not be suspended, and must never have been permanently banned or terminated"? This requirement means that if on or after the policy's publication date, on February 23, 2010, any of your Second Life accounts are not in good standing, are suspended, or are permanently banned or terminated, then you and your viewers are ineligible for the Viewer Directory." So someone that has had an account banned is not eligible for the directory. What about a team with one or more members who have had their accounts banned? In case of a team dev with a support@ email going to the team and meeting the support requirements, then who's contact info has to be supplied? And if a team is eligible then couldn't a single person or small team just replace the front person to be eligible? In other words; Being a dev requires a very inquisitive mind. This same trait can get a person into trouble when they first enter our world. You do have some people who have gone to tremendous lengths to help the Second Life community at large who have been suspended at some point when they were first here. If they are helping then why the limitation? Is it really necessary that I remind everyone who sold and profited from the Hacked God Mode viewer a couple of years ago? Are you saying he would not be welcome? Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100226/536d108a/attachment.htm From jessesa at gmail.com Fri Feb 26 20:16:32 2010 From: jessesa at gmail.com (Jesse Barnett) Date: Fri, 26 Feb 2010 23:16:32 -0500 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: Guess I could word that better. We have had people who have had their accounts terminated for lesser infractions then people who violated the TOS but were given a pass by Linden Labs. And once a gain you have teams that have multiple devs that have been banned but they are given a pass as opposed to a single person project where the dev has been helping the community but is not forbidden under these rules. Jesse Barnett On Fri, Feb 26, 2010 at 11:03 PM, Jesse Barnett wrote: > Thank you for the hard work there Soft. It answers all of the questions I > have except for this section: > > "What is the meaning of the Viewer Directory eligibility requirement that > "your Second Life accounts must be in good standing, must not be suspended, > and must never have been permanently banned or terminated"? > > This requirement means that if on or after the policy's publication date, > on February 23, 2010, any of your Second Life accounts are not in good > standing, are suspended, or are permanently banned or terminated, then you > and your viewers are ineligible for the Viewer Directory." > > So someone that has had an account banned is not eligible for the > directory. > > What about a team with one or more members who have had their accounts > banned? > > In case of a team dev with a support@ email going to the team and meeting > the support requirements, then who's contact info has to be supplied? > > And if a team is eligible then couldn't a single person or small team just > replace the front person to be eligible? > > In other words; Being a dev requires a very inquisitive mind. This same > trait can get a person into trouble when they first enter our world. You do > have some people who have gone to tremendous lengths to help the Second Life > community at large who have been suspended at some point when they were > first here. If they are helping then why the limitation? > > Is it really necessary that I remind everyone who sold and profited from > the Hacked God Mode viewer a couple of years ago? Are you saying he would > not be welcome? > > Jesse Barnett > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100226/85c95da4/attachment.htm From soft at lindenlab.com Fri Feb 26 20:29:43 2010 From: soft at lindenlab.com (Soft Linden) Date: Fri, 26 Feb 2010 22:29:43 -0600 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: I know the question of how to resolve a ban when multiple people are behind the viewer is in legal's pile. I'm surprised it didn't make the FAQ, so I'll send a reminder about that ambiguity. There are checkered histories for some existing viewer developers, yes. It's not our policy to talk about specific governance issues -- we might not even be allowed to do so. But in the general case, people didn't have healthy project teams to attach to in the past. Now that those exist, we hope that's the new place that curious people go. The era of second chances for serious violations is definitely over, though. There's no question on this. Part of the reason for having legal draft this policy is so that in the future, legal can be directly involved where we see repeated willful violations. On Fri, Feb 26, 2010 at 10:03 PM, Jesse Barnett wrote: > Thank you for the hard work there Soft. It answers all of the questions I > have except for this section: > > "What is the meaning of the Viewer Directory eligibility requirement that > "your Second Life accounts must be in good standing, must not be suspended, > and must never have been permanently banned or terminated"? > > This requirement means that if on or after the policy's publication date, on > February 23, 2010, any of your Second Life accounts are not in good > standing, are suspended, or are permanently banned or terminated, then you > and your viewers are ineligible for the Viewer Directory." > > So someone that has had an account banned is not eligible for the directory. > > What about a team with one or more members who have had their accounts > banned? > > In case of a team dev with a support@ email going to the team and meeting > the support requirements, then who's contact info has to be supplied? > > And if a team is eligible then couldn't a single person or small team just > replace the front person to be eligible? > > In other words; Being a dev requires a very inquisitive mind. This same > trait can get a person into trouble when they first enter our world. You do > have some people who have gone to tremendous lengths to help the Second Life > community at large who have been suspended at some point when they were > first here. If they are helping then why the limitation? From tigrospottystripes at gmail.com Fri Feb 26 20:50:07 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 27 Feb 2010 01:50:07 -0300 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <4B88A47F.2050808@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Btw, talking about checkered histories, hypotheticly, if someone has had their account suspended for a time because of unfounded accusations of being underage, would that prevent the person from being authorized to offer a client that connects to LL's grid? On 27/2/2010 01:29, Soft Linden wrote: > I know the question of how to resolve a ban when multiple people are > behind the viewer is in legal's pile. I'm surprised it didn't make the > FAQ, so I'll send a reminder about that ambiguity. > > There are checkered histories for some existing viewer developers, > yes. It's not our policy to talk about specific governance issues -- > we might not even be allowed to do so. But in the general case, people > didn't have healthy project teams to attach to in the past. Now that > those exist, we hope that's the new place that curious people go. > > The era of second chances for serious violations is definitely over, > though. There's no question on this. Part of the reason for having > legal draft this policy is so that in the future, legal can be > directly involved where we see repeated willful violations. > > > On Fri, Feb 26, 2010 at 10:03 PM, Jesse Barnett wrote: >> Thank you for the hard work there Soft. It answers all of the questions I >> have except for this section: >> >> "What is the meaning of the Viewer Directory eligibility requirement that >> "your Second Life accounts must be in good standing, must not be suspended, >> and must never have been permanently banned or terminated"? >> >> This requirement means that if on or after the policy's publication date, on >> February 23, 2010, any of your Second Life accounts are not in good >> standing, are suspended, or are permanently banned or terminated, then you >> and your viewers are ineligible for the Viewer Directory." >> >> So someone that has had an account banned is not eligible for the directory. >> >> What about a team with one or more members who have had their accounts >> banned? >> >> In case of a team dev with a support@ email going to the team and meeting >> the support requirements, then who's contact info has to be supplied? >> >> And if a team is eligible then couldn't a single person or small team just >> replace the front person to be eligible? >> >> In other words; Being a dev requires a very inquisitive mind. This same >> trait can get a person into trouble when they first enter our world. You do >> have some people who have gone to tremendous lengths to help the Second Life >> community at large who have been suspended at some point when they were >> first here. If they are helping then why the limitation? > _______________________________________________ > 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/ iEYEARECAAYFAkuIpHsACgkQ8ZFfSrFHsmV9WQCeIlAWNVRTRar/XhNf4zNTfsBs WawAnAo7Yd2CxZzQkXTQ0IhOhus0mcfN =FUKa -----END PGP SIGNATURE----- From soft at lindenlab.com Fri Feb 26 21:10:42 2010 From: soft at lindenlab.com (Soft Linden) Date: Fri, 26 Feb 2010 23:10:42 -0600 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: I feel I should add too - this isn't all stick, as my below speculation about legal's intent might have suggested. Remember that we're creating the Viewer Directory to promote other viewer projects, so complying with the TPV terms offers up a pretty good carrot. However, I think legal also knows we'd be making trouble for ourselves if we gave even the whiff of an endorsement to a tool that hurt our resis or the Lab. So, legal needed to offer some objective rules before we could promote any projects. I hope this is helping. I worried that one of the most frustrating parts of the TPV might be that it was landing with a big "what" without enough "why" behind it. Most people react pretty badly to anything that looks like control for control's own sake. On Fri, Feb 26, 2010 at 10:29 PM, Soft Linden wrote: > I know the question of how to resolve a ban when multiple people are > behind the viewer is in legal's pile. I'm surprised it didn't make the > FAQ, so I'll send a reminder about that ambiguity. > > There are checkered histories for some existing viewer developers, > yes. It's not our policy to talk about specific governance issues -- > we might not even be allowed to do so. But in the general case, people > didn't have healthy project teams to attach to in the past. Now that > those exist, we hope that's the new place that curious people go. > > The era of second chances for serious violations is definitely over, > though. There's no question on this. Part of the reason for having > legal draft this policy is so that in the future, legal can be > directly involved where we see repeated willful violations. > > > On Fri, Feb 26, 2010 at 10:03 PM, Jesse Barnett wrote: >> Thank you for the hard work there Soft. It answers all of the questions I >> have except for this section: >> >> "What is the meaning of the Viewer Directory eligibility requirement that >> "your Second Life accounts must be in good standing, must not be suspended, >> and must never have been permanently banned or terminated"? >> >> This requirement means that if on or after the policy's publication date, on >> February 23, 2010, any of your Second Life accounts are not in good >> standing, are suspended, or are permanently banned or terminated, then you >> and your viewers are ineligible for the Viewer Directory." >> >> So someone that has had an account banned is not eligible for the directory. >> >> What about a team with one or more members who have had their accounts >> banned? >> >> In case of a team dev with a support@ email going to the team and meeting >> the support requirements, then who's contact info has to be supplied? >> >> And if a team is eligible then couldn't a single person or small team just >> replace the front person to be eligible? >> >> In other words; Being a dev requires a very inquisitive mind. This same >> trait can get a person into trouble when they first enter our world. You do >> have some people who have gone to tremendous lengths to help the Second Life >> community at large who have been suspended at some point when they were >> first here. If they are helping then why the limitation? > From soft at lindenlab.com Fri Feb 26 21:17:22 2010 From: soft at lindenlab.com (Soft Linden) Date: Fri, 26 Feb 2010 23:17:22 -0600 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4B88A47F.2050808@Gmail.com> References: <4B88A47F.2050808@Gmail.com> Message-ID: Absolutely not. Anyone who governance clears as having been wrongly accused is off the hook, and accounts even get noted that way so it's the first thing in front of any Linden who brings up an account. Don't worry that the Viewer Directory's going to become so automated that human evaluation falls out of the picture. There just aren't that many projects. On Fri, Feb 26, 2010 at 10:50 PM, Tigro Spottystripes wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Btw, talking about checkered histories, hypotheticly, if someone has had > their account suspended for a time because of unfounded accusations of > being underage, would that prevent the person from being authorized to > offer a client that connects to LL's grid? > > On 27/2/2010 01:29, Soft Linden wrote: >> I know the question of how to resolve a ban when multiple people are >> behind the viewer is in legal's pile. I'm surprised it didn't make the >> FAQ, so I'll send a reminder about that ambiguity. >> >> There are checkered histories for some existing viewer developers, >> yes. It's not our policy to talk about specific governance issues -- >> we might not even be allowed to do so. But in the general case, people >> didn't have healthy project teams to attach to in the past. Now that >> those exist, we hope that's the new place that curious people go. >> >> The era of second chances for serious violations is definitely over, >> though. There's no question on this. Part of the reason for having >> legal draft this policy is so that in the future, legal can be >> directly involved where we see repeated willful violations. >> >> >> On Fri, Feb 26, 2010 at 10:03 PM, Jesse Barnett wrote: >>> Thank you for the hard work there Soft. It answers all of the questions I >>> have except for this section: >>> >>> "What is the meaning of the Viewer Directory eligibility requirement that >>> "your Second Life accounts must be in good standing, must not be suspended, >>> and must never have been permanently banned or terminated"? >>> >>> This requirement means that if on or after the policy's publication date, on >>> February 23, 2010, any of your Second Life accounts are not in good >>> standing, are suspended, or are permanently banned or terminated, then you >>> and your viewers are ineligible for the Viewer Directory." >>> >>> So someone that has had an account banned is not eligible for the directory. >>> >>> What about a team with one or more members who have had their accounts >>> banned? >>> >>> In case of a team dev with a support@ email going to the team and meeting >>> the support requirements, then who's contact info has to be supplied? >>> >>> And if a team is eligible then couldn't a single person or small team just >>> replace the front person to be eligible? >>> >>> In other words; Being a dev requires a very inquisitive mind. This same >>> trait can get a person into trouble when they first enter our world. You do >>> have some people who have gone to tremendous lengths to help the Second Life >>> community at large who have been suspended at some point when they were >>> first here. If they are helping then why the limitation? >> _______________________________________________ >> 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/ > > iEYEARECAAYFAkuIpHsACgkQ8ZFfSrFHsmV9WQCeIlAWNVRTRar/XhNf4zNTfsBs > WawAnAo7Yd2CxZzQkXTQ0IhOhus0mcfN > =FUKa > -----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 > From morgaine.dinova at googlemail.com Fri Feb 26 22:47:04 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Sat, 27 Feb 2010 06:47:04 +0000 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: Soft, this is quite a good FAQ (particularly compared to TPV #1:P) as it clears up a large number of points. I thought it might resolve the earlier problems re GPL compliance, particularly since it addresses the GPL directly. But when I examined it more closely it still has holes and confusion on the key points. Take FAQ.2 for example: Q2: Does the policy limit *use* of the viewer source code that Linden Lab makes available under the GPL? A2: No, the policy is not intended to and does not place any restriction on modification or *use* of our viewer source code that we make available under the GPL. 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. This looks great at first glance as it appears to make the separation between developers and users that caused so much confusion in TPV v1. But notice that the answer says "does not place any restriction on modification or *use*", and then goes on to say "Rather, the policy sets out requirements for *connecting".* Well connecting *IS* use, it couldn't be anything else, so the answer contradicts itself in one and the same paragraph. Such ambiguities need to be removed. The sentence was probably intended to say "does not place any restriction on modification or *distribution*", in order to clear the hurdle of GPLv2 clause 6. That clause *explicitly* requires freedom of *modification* and * distribution*. Nothing else will do, so if you want to be clear about GPL compliance, those words had better be there in A2. :-) Unfortunately, the question itself is confusing because it refers to *use*of the source code, and the GPL is completely unconcerned about use. Really the question should ask: - Q2: Does the policy limit *modification* and *distribution* of the viewer source code that Linden Lab makes available under the GPL? If that were the question then it would make sense in the context of addressing GPLv2 clause 6 directly, and it would match the corrected answer I gave above. Next, FAQ.12: - Q12: I develop for a Linux distribution where there is no opportunity to present users with the disclosures required under section 1.c before the user downloads and installs the software. How can I comply with section 1.c of the policy? - A12: For Linux distributions where there is no opportunity to provide the section 1.c disclosures before installation of the software, *you can comply with the requirement by having your software client present the required disclosures or a link to them in a dialogue box that the user must close before logging into Second Life for the first time through your software*. You can't require that of developers of GPL software. It's a restriction on a GPL developer's "*freedom to modify and distribute*", and is explicitly prohibited in GPLv2 clause 6. Please check the GPLv2 FAQfor the example of the original BSD advertising clause, which was incompatible with the GPL. That advertising clause had to be removed from GPL programs before they could be licensed using GPL, because it was an *additional restriction* on the freedom to modify and distribute. Your requirement is similar but much more onerous. It is a very clear additional restriction on the freedom to modify and distribute: for example, it restricts removal of the disclosure or dialogue box. Such an additional restriction is not permitted under GPL. Indeed, no additional restrictions on the freedom to modify and distribute are permitted at all. And finally, FAQ.15 (in the context of licenses permitting free distribution): - Q15: Do the limitations of section 2.b on content export apply to content that is full permissions? - A15: Yes, they do. Residents retain intellectual property rights in the content they create in Second Life and it is important for you to respect those rights. By setting content to "full permissions" using the Second Life permissions system, a content creator merely indicates that the content may be copied, modified, and transferred *within* Second Life. Setting content to "full permissions" does not provide any permission to use the content outside of Second Life. This is fine (surprise, surprise :P), but incomplete. It doesn't address the quite common scenario of full-perm content created by Open Source or Creative Commons developers *using 100% personal textures*, and accompanied by a GPL, BSD, CC or other open source license which declares that the content may be freely copied, modified, and transferred *anywhere*, not only within Second Life. As is written in the answer A15, "Residents retain intellectual property rights in the content they create in Second Life and *it is important for you to respect those rights*." Respecting their rights in this case requires you to to allow that content to be exported as its creator desires. Therefore you either need to extend A15 with this additional case, or add another FAQ Q+A (preferably immediately after #15) to address it. I'm limiting my interest to the open source / licensing aspects of TPV and FAQ so some of the Q+As I've skimmed only superficially, but they seem fairly reasonable. There are also some entries that refer to the forthcoming TPV document, so substantive comment now would not make sense. FAQ.3 is worrying though --- it hints that the TPV may list further restrictions on the GPL developer's freedom to modify and distribute, again in direct contravention of GPLv2 clause 6. Morgaine. ================================= On Sat, Feb 27, 2010 at 3:14 AM, Soft Linden wrote: > There's now a FAQ for the Linden Lab Policy on Third Party Viewers: > http://bit.ly/caedse > > This addresses many of the questions and concerns made in > opensource-dev and elsewhere. An updated version of the TPV doc itself > is also coming, but expect this within a couple weeks. Go visit the > FAQ, or read on for the TPV doc update details... > > I know that the member of the legal team who owns the policy doc is > still working over the final version. Linden Lab has approached > outside legal experts with your feedback, and one of these experts is > a lawyer who specializes in open source license compliance issues. > Based on these experts' feedback and further internal review, our > legal department will incorporate any required changes. > > In the meantime, while it helps to start making changes now, parts of > the policy are not yet in effect. See the tail of the FAQ for dates > and the portions affected. > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100227/be3a48c9/attachment.htm From morgaine.dinova at googlemail.com Fri Feb 26 22:56:25 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Sat, 27 Feb 2010 06:56:25 +0000 Subject: [opensource-dev] [Fwd: [realXtend] Presentation of naali viewer and realXtend to AW Groupies...] In-Reply-To: <4B883E2B.8050406@cox.net> References: <4B883E2B.8050406@cox.net> Message-ID: This is great, Lawson. Many thanks for setting it up! Morgaine. ============================== On Fri, Feb 26, 2010 at 9:33 PM, Lawson English wrote: > For anyone who has an interest in SL viewers that are not part of the > Linden Lab GPL tree, we've invited developers from the realXtend project to > make a presentation to the AW Groupies this Tuesday at 8:30 AM SLT (to allow > for a rather large time zone difference). > > http://www.realxtend.org/ > > > We are hoping to have a large, technically minded (for the most part) > audience who are prepared to ask tough questions. Non-techies are certainly > welcome to come and ask questions as well. The topic should be about both > programming and non-programming issues. > > IM me, Saijanai Kuhn, in-world sometime before the meeting in order to get > a group invite to get to the island. Zha generally opens the island to > non-members during these presentations, but in case something goes wrong, > its easier to be part of the group, at least during the meeting. That way > you can participate in the group chatter as well. > > > That will be 8:30AM SLT this coming Tuesday. 6:30 PM EET. > > at http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/129/24 > > > > > This was sent to the realXtend list: > > Toni has said he can make it to the Groupies meeting this coming Tuesday at > 8:30 AM SLT (6:30 PM EET I believe) and Zha Ewry says she can ensure it will > be available at that time. > > It would certainly be great to have more than one person there from > realXtend. When we invited the Open Cobalt team, we ended up asking enough > questions to overwhelm just one person. > > Also, whoever comes should understand that the range of questions is HUGE: > we have people who use SL for education and handicap-access that might be > attending. Likewise, the metanomics team sometimes attends. Other viewer > developers are often around, as well as Lindens and contributors to OpenSim > from IBM and so on. If I work on it, I can probably fill up the sim (80 > avatars) with interested people with enough background to ask decent > questions, both about the programming and your long-term plans for how > realxtend might be used. > > > > So anyone who wants to attend and help answer questions about naali and > realxtend should feel free to give me (Saijanai Kuhn) an IM in Second Life > so I can invite you to the island for the presentation. > > > That will be 8:30AM SLT this coming Tuesday. 6:30 PM EET. > > at http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/129/24 > > > Hope to see you all there. > > > Lawson English (Saijanai Kuhn in Second Life) > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org > > Toni has said he can make it to the Groupies meeting this coming Tuesday at > 8:30 AM SLT (6:30 PM EET I believe) and Zha Ewry says she can ensure it will > be available at that time. > > It would certainly be great to have more than one person there from > realXtend. When we invited the Open Cobalt team, we ended up asking enough > questions to overwhelm just one person. > > Also, whoever comes should understand that the range of questions is HUGE: > we have people who use SL for education and handicap-access that might be > attending. Likewise, the metanomics team sometimes attends. Other viewer > developers are often around, as well as Lindens and contributors to OpenSim > from IBM and so on. If I work on it, I can probably fill up the sim (80 > avatars) with interested people with enough background to ask decent > questions, both about the programming and your long-term plans for how > realxtend might be used. > > > > So anyone who wants to attend and help answer questions about naali and > realxtend should feel free to give me (Saijanai Kuhn) an IM in Second Life > so I can invite you to the island for the presentation. > > > That will be 8:30AM SLT this coming Tuesday. 6:30 PM EET. > > at http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/129/24 > > > Hope to see you all there. > > > Lawson English (Saijanai Kuhn in Second Life) > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100227/e7bc7649/attachment.htm From latifer at streamgrid.net Sat Feb 27 00:32:44 2010 From: latifer at streamgrid.net (Latif Khalifa) Date: Sat, 27 Feb 2010 09:32:44 +0100 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <5ebce2ec1002270032k372d8cc3na583309c5290cadb@mail.gmail.com> Hi Soft, I'm very pleased too see that some of our biggest concerns were taken into account. For me especially the FAQ states that provision 1.h about "shared experience" is going to be removed, as it would be impossible to bring Radegast into compliance with the policy if that clause were to stay in it. Kudos! Latif On Sat, Feb 27, 2010 at 4:14 AM, Soft Linden wrote: > There's now a FAQ for the Linden Lab Policy on Third Party Viewers: > http://bit.ly/caedse > > This addresses many of the questions and concerns made in > opensource-dev and elsewhere. An updated version of the TPV doc itself > is also coming, but expect this within a couple weeks. Go visit the > FAQ, or read on for the TPV doc update details... > > I know that the member of the legal team who owns the policy doc is > still working over the final version. Linden Lab has approached > outside legal experts with your feedback, and one of these experts is > a lawyer who specializes in open source license compliance issues. > Based on these experts' feedback and further internal review, our > legal department will incorporate any required changes. > > In the meantime, while it helps to start making changes now, parts of > the policy are not yet in effect. See the tail of the FAQ for dates > and the portions affected. > _______________________________________________ > 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 > From sldev at free.fr Sat Feb 27 01:32:31 2010 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 27 Feb 2010 10:32:31 +0100 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <20100227103231.22d26e14.sldev@free.fr> On Fri, 26 Feb 2010 21:14:52 -0600, Soft Linden wrote: > There's now a FAQ for the Linden Lab Policy on Third Party Viewers: > http://bit.ly/caedse Very good job, Soft, thank you ! :-) However, there are a couple of points that I think should be addressed or precised in this FAQ: 1. The trademarking rules as presented in the TPV are in contradiction with Linden Lab's own trademark policy. In particular: 5.b.i You must not have a Third-Party Viewer name that is ?________ Life? where ?________? is a term or series of terms. Is in contracdiction with: http://secondlife.com/corporate/brand/trademark/unauthorized.php in which we see that "[anything] Life" is not forbidden as long as [anything] does not contain "Second". I would call such a trademarking a "domain trademarking" (like a domain name for an Internet site address"), but I doubt very much such a rule would be legal, even in USA... 2. in the FAQ, to the question "I do not want a publicly available listing in the Viewer Directory to disclose my own name or contact information. Is it possible for the public listing page to show just the brand name of my third-party viewer?", the answer states that name and contact info must be provided to Linden Lab, however the type of "contact information" is not precised. An email from an ISP account (not an anonymous Yahoo/Hotmail/Google/whatnot account, of course) *is* a contact information that is sufficient to legally identify the developper in case of any action against them. But right now, the full snail mail address is required, which is in violation with some international laws protecting user privacy (notably the French law "Informatique et Libert?"). I hope to see these two points addressed. Many thanks in advance ! Henri. From tigrospottystripes at gmail.com Sat Feb 27 03:21:35 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 27 Feb 2010 08:21:35 -0300 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <20100227103231.22d26e14.sldev@free.fr> References: <20100227103231.22d26e14.sldev@free.fr> Message-ID: <4B89003F.20009@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 why it doesn't feel like LL is this connected to us with lots of stuff most of the time? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuJADIACgkQ8ZFfSrFHsmXvUQCfTL9vHkCCP00uHnfczFnXi4Wq SCgAn1nHBFZ3QDKYmGaDJtfAeO4QyQGz =QZJI -----END PGP SIGNATURE----- From marinekelley at gmail.com Sat Feb 27 03:27:22 2010 From: marinekelley at gmail.com (Marine Kelley) Date: Sat, 27 Feb 2010 12:27:22 +0100 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <20100227103231.22d26e14.sldev@free.fr> References: <20100227103231.22d26e14.sldev@free.fr> Message-ID: <9e52a8c11002270327n54bc13b5h21cafd041bb5d7f1@mail.gmail.com> I don't know much about it, but what about the data that most of us already entered when signing up to SL ? LL should have these data stored somewhere, why do we have to enter them all again ? If the data to be entered to sign in to the viewer directory is not linked to it, what gives LL the certainty that they are accurate, where are they stored, and what is the privacy policy ? The TPV says "may be published", but there is no way to be sure... And moreso, the FAQ says that listing in the directory might become mandatory. With such vague terms it is impossible to comply to these requirements, which are way too intrusive for a hobbyist. Sorry about this, it seems that publishing a Frequently Asked Questions page brings even more questions ! It is always like this. lol. On 27 February 2010 10:32, Henri Beauchamp wrote: > On Fri, 26 Feb 2010 21:14:52 -0600, Soft Linden wrote: > > > There's now a FAQ for the Linden Lab Policy on Third Party Viewers: > > http://bit.ly/caedse > > Very good job, Soft, thank you ! :-) > > However, there are a couple of points that I think should be addressed > or precised in this FAQ: > > 1. The trademarking rules as presented in the TPV are in contradiction > with Linden Lab's own trademark policy. In particular: > 5.b.i You must not have a Third-Party Viewer name that is > ?________ Life? where ?________? is a term or series > of terms. > Is in contracdiction with: > http://secondlife.com/corporate/brand/trademark/unauthorized.php > in which we see that "[anything] Life" is not forbidden as long > as [anything] does not contain "Second". > I would call such a trademarking a "domain trademarking" (like > a domain name for an Internet site address"), but I doubt very much > such a rule would be legal, even in USA... > > 2. in the FAQ, to the question "I do not want a publicly available > listing in the Viewer Directory to disclose my own name or contact > information. Is it possible for the public listing page to show > just the brand name of my third-party viewer?", the answer states > that name and contact info must be provided to Linden Lab, however > the type of "contact information" is not precised. An email from > an ISP account (not an anonymous Yahoo/Hotmail/Google/whatnot > account, of course) *is* a contact information that is sufficient > to legally identify the developper in case of any action against > them. But right now, the full snail mail address is required, > which is in violation with some international laws protecting user > privacy (notably the French law "Informatique et Libert?"). > > I hope to see these two points addressed. > > Many thanks in advance ! > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100227/ed63b3fc/attachment.htm From gareth at garethnelson.com Sat Feb 27 05:10:10 2010 From: gareth at garethnelson.com (Gareth Nelson) Date: Sat, 27 Feb 2010 13:10:10 +0000 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <9e52a8c11002270327n54bc13b5h21cafd041bb5d7f1@mail.gmail.com> References: <20100227103231.22d26e14.sldev@free.fr> <9e52a8c11002270327n54bc13b5h21cafd041bb5d7f1@mail.gmail.com> Message-ID: <4ebfc1101002270510s4cd26228k1d87d62b8405ccd7@mail.gmail.com> A few queries I have: Sometimes I code random small scripts to do quick inworld tasks - do I have to have 100% compliance for these scripts? I have a bot which comes in 2 parts - SL interface and AI engine, the SL interface being a simple protocol handler - how does the policy affect my AI engine if at all? If only the SL interface need be compliant, isn't this a major loophole in that the AI engine could use it to perform various malicious deeds? If I code a viewer which is designed for use with other grids, does not comply with the policy and is not intended for use on SL, but one of my users connects to SL with it anyway , how does that reflect on me? In general, I have to agree with those who say that this will only burden legit developers - griefers will just ignore the policy and spoof the official viewer On Sat, Feb 27, 2010 at 11:27 AM, Marine Kelley wrote: > I don't know much about it, but what about the data that most of us already > entered when signing up to SL ? LL should have these data stored somewhere, > why do we have to enter them all again ? If the data to be entered to sign > in to the viewer directory is not linked to it, what gives LL the certainty > that they are accurate, where are they stored, and what is the privacy > policy ? The TPV says "may be published", but there is no way to be sure... > And moreso, the FAQ says that listing in the directory might become > mandatory. With such vague terms it is impossible to comply to these > requirements, which are way too intrusive for a hobbyist. > > Sorry about this, it seems that publishing a Frequently Asked Questions page > brings even more questions ! It is always like this. lol. > > > On 27 February 2010 10:32, Henri Beauchamp wrote: >> >> On Fri, 26 Feb 2010 21:14:52 -0600, Soft Linden wrote: >> >> > There's now a FAQ for the Linden Lab Policy on Third Party Viewers: >> > http://bit.ly/caedse >> >> Very good job, Soft, thank you ! :-) >> >> However, there are a couple of points that I think should be addressed >> or precised in this FAQ: >> >> 1. The trademarking rules as presented in the TPV are in contradiction >> ? with Linden Lab's own trademark policy. In particular: >> ? ? ?5.b.i You must not have a Third-Party Viewer name that is >> ? ? ? ? ? ? ? ? ? ? ? ?________ Life? where ?________? is a term or series >> of terms. >> ? Is in contracdiction with: >> ? http://secondlife.com/corporate/brand/trademark/unauthorized.php >> ? in which we see that "[anything] Life" is not forbidden as long >> ? as [anything] does not contain "Second". >> ? I would call such a trademarking a "domain trademarking" (like >> ? a domain name for an Internet site address"), but I doubt very much >> ? such a rule would be legal, even in USA... >> >> 2. in the FAQ, to the question "I do not want a publicly available >> ? listing in the Viewer Directory to disclose my own name or contact >> ? information. ?Is it possible for the public listing page to show >> ? just the brand name of my third-party viewer?", the answer states >> ? that name and contact info must be provided to Linden Lab, however >> ? the type of "contact information" is not precised. An email from >> ? an ISP account (not an anonymous Yahoo/Hotmail/Google/whatnot >> ? account, of course) *is* a contact information that is sufficient >> ? to legally identify the developper in case of any action against >> ? them. But right now, the full snail mail address is required, >> ? which is in violation with some international laws protecting user >> ? privacy (notably the French law "Informatique et Libert?"). >> >> I hope to see these two points addressed. >> >> Many thanks in advance ! >> >> 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 > -- ?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 From dzonatas at gmail.com Sat Feb 27 06:39:30 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Sat, 27 Feb 2010 06:39:30 -0800 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <4B892EA2.2080703@gmail.com> Soft Linden wrote: >> Remember that we're creating the Viewer Directory to promote other viewer projects, so complying with the TPV terms offers up a pretty good carrot. However, I think legal also knows we'd be making trouble for ourselves if we gave even the whiff of an endorsement to a tool that hurt our resis or the Lab. So, legal needed to offer some objective rules before we could promote any projects. *looks like a rabbit that hops around with a timeclock on paw* "One Sim Per Avatar" Of course, these can work perfectly while Linden Lab's distributes their simulator software as closed sourced, as a module, to open source. I can only suggest to lean towards GPLv3 for the final movement on such connection. Then it certainly won't look like control for control purposes. However, *winks* at rabbit(s) From carlo at alinoe.com Sat Feb 27 07:40:59 2010 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 27 Feb 2010 16:40:59 +0100 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <20100227154059.GA27175@alinoe.com> Imho, one major source of confusion is still there. There is a huge difference between Legal Ramifications (ie, being sued and brought before court etc), and just having ones Second Life account banned. The difference between these two is completely lacking in the TPVP as well as in the FAQ. While it is clear that Linden Lab can terminate anyones account (at least, that's what I think-- maybe this TPVP is needed in order to allow that?), before you can *sue* a developer is whole different ball game. It is this major difference that needs to be clarified: * You cannot legally stop anyone from making modifications, and distributing viewer code (based on LL's GPL-ed source tree). * You cannot hold anyone, with the law in hand, responsible for what others do with that source code; EVEN if the source code in question is breaking every TPV rule. The way the TPV Policy is formulated now, it's extremely unclear if Linden Lab intents to (try to) bring developers for court if their distributed viewer does not comply with the demands in the TPV. The FAQ does not clearify this. Actually, I'm not even sure if it is possible to sue users that use a viewer to break a rule of the TPV (mostly 'content theft' I'd imagine, but also griefing), much less a user that uses a viewer that allows users to do so, without that they actually do it. Basically this question needs to be added to the FAQ: * Will Linden Lab ever take legal actions against any of it's users, or even developers of Third-Party viewers, with regard to the rules in the TPV Policy document? The answer should be: No, because breaking any of the rules isn't really illegal in the sense of the Law. The only action LL will take is reserve the right to terminate accounts and withhold people from using the Second Life service anymore. -- Carlo Wood From sldev at free.fr Sat Feb 27 07:42:33 2010 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 27 Feb 2010 16:42:33 +0100 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <9e52a8c11002270327n54bc13b5h21cafd041bb5d7f1@mail.gmail.com> References: <20100227103231.22d26e14.sldev@free.fr> <9e52a8c11002270327n54bc13b5h21cafd041bb5d7f1@mail.gmail.com> Message-ID: <20100227164233.e454532c.sldev@free.fr> On Sat, 27 Feb 2010 12:27:22 +0100, Marine Kelley wrote: > I don't know much about it, but what about the data that most of us already > entered when signing up to SL ? LL should have these data stored somewhere, > why do we have to enter them all again ? There should be no connection other than the avatar name, between the residents database (the one used to connect and manage accounts), the billing info database (where the actual, accurate info such as real life name, credit card or Paypal into are held), and the developpers database (license agreements, TPV directory, etc). At least, this is how things would be if Linden Lab was based in France (the law "Informatique et Libert?" would force them to ask for permission to open any nominative database and would forbid any merging between their different nominative database). But I do hope it is also what Linden Lab is doing after the data theft they (and therefore their customers) were the victim of in September 2006 (a database holding plaint text Avatar names, real life names and addresses, and encrypted credit card info was stolen). See the full story here: http://www.bit-tech.net/news/gaming/2006/09/12/Second_Life_servers_hacked/1 So, I find it only normal that Linden Lab requests the info again for the TPV directory (Linden Lab's employees dealing with TPV do not need and should not have access to billing info, so they can't get your RL name from the billing info database). What I don't find normal, is that the snail mail address is required to register to the TPV directory (it's of no need at all, and unneeded info shall not be demanded). Henri. From carlo at alinoe.com Sat Feb 27 07:58:30 2010 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 27 Feb 2010 16:58:30 +0100 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4ebfc1101002270510s4cd26228k1d87d62b8405ccd7@mail.gmail.com> References: <20100227103231.22d26e14.sldev@free.fr> <9e52a8c11002270327n54bc13b5h21cafd041bb5d7f1@mail.gmail.com> <4ebfc1101002270510s4cd26228k1d87d62b8405ccd7@mail.gmail.com> Message-ID: <20100227155830.GB27175@alinoe.com> On Sat, Feb 27, 2010 at 01:10:10PM +0000, Gareth Nelson wrote: > In general, I have to agree with those who say that this will only > burden legit developers - griefers will just ignore the policy and > spoof the official viewer +1 Especially the clear intend of Linden Lab to make being listed in the Third Party Directory mandatory, but also the fact that once you are listed you are vulnerable to being spoofed by all the REALLY bad guys out there, makes me believe that it is in anyone's interest to not be listed in the TPV directory and cross your fingers that nobody will so that it stays empty. In that case the ball is in LL's garden again with a lot less chance they will start banning your viewer because it's not listed. I don't believe that this whole TPV policy thing is doing ANYTHING except make the lives of honest developers harder. I am sure that everyone on this list that is trying to honestly create a nice viewer and make things Better will agree with me that so far all of this has only brought them frustration and they wished this never happened. At the same time, the Bad Guys will not care at ALL. They were ALREADY doing things that are reason for a ban. Not complying to the TPV policy doesn't increase their risk a bit, and they will just ignore it. After all, the only result of not following TPV policy is a termination of SL accounts. Imho, it is not possible that the existance of this TPV policy suddenly opens up the possibility to bring those Bad developers before court; it's impossible to make them responsible for what users do with their code. I'm not a lawyer, clearly, but something that comes to mind is the fact that copying movies is highly illegal, yet nobody even tried to sue the developers of azureus/vuze. -- Carlo Wood From fleep513 at gmail.com Sat Feb 27 08:32:27 2010 From: fleep513 at gmail.com (Fleep Tuque) Date: Sat, 27 Feb 2010 11:32:27 -0500 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: (Sending for like the 4th time I hope this one gets through and sorry if I've spammed) Regarding Morgaine's comments about FAQ 15 - I fully agree that this must be the case: On Sat, Feb 27, 2010 at 1:47 AM, Morgaine wrote: > And finally, FAQ.15 (in the context of licenses permitting free > distribution): > > > - Q15: Do the limitations of section 2.b on content export apply to > content that is full permissions? > - A15: Yes, they do. Residents retain intellectual property rights in > the content they create in Second Life and it is important for you to > respect those rights. By setting content to "full permissions" using the > Second Life permissions system, a content creator merely indicates that the > content may be copied, modified, and transferred *within* Second Life. > Setting content to "full permissions" does not provide any permission to > use the content outside of Second Life. > > > This is fine (surprise, surprise :P), but incomplete. It doesn't address > the quite common scenario of full-perm content created by Open Source or > Creative Commons developers *using 100% personal textures*, and > accompanied by a GPL, BSD, CC or other open source license which declares > that the content may be freely copied, modified, and transferred *anywhere > *, not only within Second Life. > > As is written in the answer A15, "Residents retain intellectual property > rights in the content they create in Second Life and *it is important for > you to respect those rights*." Respecting their rights in this case > requires you to to allow that content to be exported as its creator > desires. Therefore you either need to extend A15 with this additional case, > or add another FAQ Q+A (preferably immediately after #15) to address it. > > The free content I create for education is intended to be fully free, fully permissioned, and fully exportable to other grids. Beyond the Second Life permissions, I keep hoping for checkboxes on the Edit menu with common licenses or a space to put a link to the user's specified license that is kept with the object info just like creator name. In any case, when I include Creative Commons licensing with my educational tools, and explicitly say users have my permission to explore the content to other grids, then I expect that to be respected by Linden Lab as well! Sincerely, - Chris/Fleep Chris M. Collins (SL: Fleep Tuque) Project Manager, UC Second Life Second Life Ambassador, Ohio Learning Network UCit Instructional & Research Computing University of Cincinnati 406E Zimmer Hall PO Box 210088 Cincinnati, OH 45221-0088 (513)556-3018 chris.collins at uc.edu UC Second Life: http://homepages.uc.edu/secondlife OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100227/41911a52/attachment.htm From morgaine.dinova at googlemail.com Sat Feb 27 12:02:02 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Sat, 27 Feb 2010 20:02:02 +0000 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: Fleep, you give an excellent example highlighting the needs of Education in this area. Given the huge interest in educational content both in SL and in Opensim-based grids such as Science Sim, this is certain to be of major and growing interest. Perhaps the FAQ could add a *new* clause FAQ.16 (renumbering the old FAQ.16 and all subsequent ones down) which reads something like this: - Q16: Are the rights of open source or open content providers respected? - A16: Yes. To further protect the rights of content creators beyond FAQ.15, Linden Lab also respects the wishes of creators who release their content under open source or open content licenses to make their content freely exportable. (Typical licenses are GPL, BSD, or Creative Commons.) The responsibility for ensuring that such content does not contravene FAQ.15 rests entirely with the licensor, who must ensure that all parts either comply with FAQ.15 or have been released under an open license by their respective creators. That works remarkably well in conjunction with FAQ.15, because 15 covers everything that is not open content, and so neatly dumps the responsibility for full compliance in the lap of each licensor in 16. And I particularly like the word "Yes", and the phrasing "Linden Lab also respects the wishes of creators who release their content under open source or open content licenses to make their content freely exportable." It would show good intentions directly, and without any fudging. Morgaine. ================================== On Sat, Feb 27, 2010 at 4:32 PM, Fleep Tuque wrote: > (Sending for like the 4th time I hope this one gets through and sorry if > I've spammed) > > Regarding Morgaine's comments about FAQ 15 - I fully agree that this must > be the case: > > > On Sat, Feb 27, 2010 at 1:47 AM, Morgaine > wrote: > >> And finally, FAQ.15 (in the context of licenses permitting free >> distribution): >> >> >> >> - Q15: Do the limitations of section 2.b on content export apply to >> content that is full permissions? >> - A15: Yes, they do. Residents retain intellectual property rights in >> the content they create in Second Life and it is important for you to >> respect those rights. By setting content to "full permissions" using the >> Second Life permissions system, a content creator merely indicates that the >> content may be copied, modified, and transferred *within* Second Life. >> Setting content to "full permissions" does not provide any permission to >> use the content outside of Second Life. >> >> >> This is fine (surprise, surprise :P), but incomplete. It doesn't address >> the quite common scenario of full-perm content created by Open Source or >> Creative Commons developers *using 100% personal textures*, and >> accompanied by a GPL, BSD, CC or other open source license which declares >> that the content may be freely copied, modified, and transferred * >> anywhere*, not only within Second Life. >> >> As is written in the answer A15, "Residents retain intellectual property >> rights in the content they create in Second Life and *it is important for >> you to respect those rights*." Respecting their rights in this case >> requires you to to allow that content to be exported as its creator >> desires. Therefore you either need to extend A15 with this additional case, >> or add another FAQ Q+A (preferably immediately after #15) to address it. >> >> > > The free content I create for education is intended to be fully free, fully > permissioned, and fully exportable to other grids. Beyond the Second Life > permissions, I keep hoping for checkboxes on the Edit menu with common > licenses or a space to put a link to the user's specified license that is > kept with the object info just like creator name. > > In any case, when I include Creative Commons licensing with my educational > tools, and explicitly say users have my permission to explore the content to > other grids, then I expect that to be respected by Linden Lab as well! > > Sincerely, > > - Chris/Fleep > > > Chris M. Collins (SL: Fleep Tuque) > Project Manager, UC Second Life > Second Life Ambassador, Ohio Learning Network > UCit Instructional & Research Computing > University of Cincinnati > 406E Zimmer Hall > PO Box 210088 > Cincinnati, OH 45221-0088 > (513)556-3018 > chris.collins at uc.edu > > UC Second Life: http://homepages.uc.edu/secondlife > OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100227/efcb6f2d/attachment.htm From zha.ewry at gmail.com Sat Feb 27 12:24:57 2010 From: zha.ewry at gmail.com (Zha Ewry) Date: Sat, 27 Feb 2010 15:24:57 -0500 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <920d7d851002271224x4dc21aefka42151439a8dfd7b@mail.gmail.com> Usual I am not a lawyer comments apply. One thing to keep in mind is that if you own the content, nothing requires you to distribute it exclusively via Linden Lab's service. If you have a set of textures which you hold rights to, putting them on Second Life doesn't remove your rights to use and distribute those textures as you see fit. While it would be nice if Second Life could distinguish between free use within Second Life and Free use globally, at the moment such mechanisms are absent. It's pretty straight forward to place textures on standard web servers and make them available under the appropriate license. I think the terms as written don't prohibit you from downloading things you created, so again, it should be fine for you to distribute them via other channels. ~ Zha On Sat, Feb 27, 2010 at 3:02 PM, Morgaine wrote: > Fleep, you give an excellent example highlighting the needs of Education in > this area. > > Given the huge interest in educational content both in SL and in > Opensim-based grids such as Science Sim, this is certain to be of major and > growing interest. > > Perhaps the FAQ could add a new clause FAQ.16 (renumbering the old FAQ.16 > and all subsequent ones down) which reads something like this: > > Q16: Are the rights of open source or open content providers respected? > A16: Yes.? To further protect the rights of content creators beyond FAQ.15, > Linden Lab also respects the wishes of creators who release their content > under open source or open content licenses to make their content freely > exportable.? (Typical licenses are GPL, BSD, or Creative Commons.)? The > responsibility for ensuring that such content does not contravene FAQ.15 > rests entirely with the licensor, who must ensure that all parts either > comply with FAQ.15 or have been released under an open license by their > respective creators. > > That works remarkably well in conjunction with FAQ.15, because 15 covers > everything that is not open content, and so neatly dumps the responsibility > for full compliance in the lap of each licensor in 16. > > And I particularly like the word "Yes", and the phrasing "Linden Lab also > respects the wishes of creators who release their content under open source > or open content licenses to make their content freely exportable."? It would > show good intentions directly, and without any fudging. > > > > Morgaine. > > > > > > ================================== > > On Sat, Feb 27, 2010 at 4:32 PM, Fleep Tuque wrote: >> >> (Sending for like the 4th time I hope this one gets through and sorry if >> I've spammed) >> Regarding Morgaine's comments about FAQ 15 - I fully agree that this must >> be the case: >> >> On Sat, Feb 27, 2010 at 1:47 AM, >> Morgaine??wrote: >>> >>> And finally, FAQ.15 (in the context of licenses permitting free >>> distribution): >>> >>> Q15:?Do the limitations of section 2.b on content export apply to content >>> that is full permissions? >>> A15: Yes, they do.? Residents retain intellectual property rights in the >>> content they create in Second Life and it is important for you to respect >>> those rights.? By setting content to "full permissions" using the Second >>> Life permissions system, a content creator merely indicates that the content >>> may be copied, modified, and transferred?within?Second Life. ?Setting >>> content to "full permissions" does not provide any permission to use the >>> content outside of Second Life. >>> >>> This is fine (surprise, surprise :P), but incomplete.? It doesn't address >>> the quite common scenario of full-perm content created by Open Source or >>> Creative Commons developers?using 100% personal textures, and accompanied by >>> a GPL, BSD, CC or other open source license which declares that the content >>> may be freely?copied, modified, and transferred?anywhere, not only within >>> Second Life. >>> >>> As is written in the answer A15, "Residents retain intellectual property >>> rights in the content they create in Second Life and?it is important for you >>> to respect those rights."? Respecting their rights in this case requires you >>> to to allow that content to be exported as its creator desires.? Therefore >>> you either need to extend A15 with this additional case, or add another FAQ >>> Q+A (preferably immediately after #15) to address it. >>> >> >> >> The free content I create for education is intended to be fully free, >> fully permissioned, and fully exportable to other grids. ?Beyond the Second >> Life permissions, I keep hoping for checkboxes on the Edit menu with common >> licenses or a space to put a link to the user's specified license that is >> kept with the object info just like creator name. >> In any case, when I include Creative Commons licensing with my educational >> tools, and?explicitly?say users have my permission to explore the content to >> other grids, then I expect that to be respected by Linden Lab as well! >> Sincerely, >> - Chris/Fleep >> >> Chris M. Collins (SL: Fleep Tuque) >> Project Manager, UC Second Life >> Second Life Ambassador, Ohio Learning Network >> UCit Instructional & Research Computing >> University of Cincinnati >> 406E Zimmer Hall >> PO Box 210088 >> Cincinnati, OH 45221-0088 >> (513)556-3018 >> chris.collins at uc.edu >> UC Second Life: ??http://homepages.uc.edu/secondlife >> OLN Second Life:?http://www.oln.org/emerging_technologies/emtech.php >> >> _______________________________________________ >> 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 > From fleep513 at gmail.com Sat Feb 27 12:36:27 2010 From: fleep513 at gmail.com (Fleep Tuque) Date: Sat, 27 Feb 2010 15:36:27 -0500 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <920d7d851002271224x4dc21aefka42151439a8dfd7b@mail.gmail.com> References: <920d7d851002271224x4dc21aefka42151439a8dfd7b@mail.gmail.com> Message-ID: I'm not a lawyer either of course, and while that's certainly true Zha, that you can make textures and such available via another site or source, the fact is that Second Life and XStreet are the most common distribution points for content developed for SL and OpenSim platforms. If someone finds my shop in Chilbo and gets an object that they want to export using SecondInventory or a 3rd party viewer, I as the creator have no problem with that and don't want to have to send them to a SECOND place to get the same content just so the transaction doesn't take place in or through SL. I'd think from a strategic perspective, having Second Life as a central marketplace for all related grids would be a good thing? I dunno, maybe I'm missing something in that regard, but I'm hoping LL's policy won't restrict my rights as a creator to license my goods for other grids. I fully support the intent to protect creators rights, of course, but that includes allowing them off grid as well as keeping them on the main grid. Respectfully, - Chris/Fleep Chris M. Collins (SL: Fleep Tuque) Project Manager, UC Second Life Second Life Ambassador, Ohio Learning Network UCit Instructional & Research Computing University of Cincinnati 406E Zimmer Hall PO Box 210088 Cincinnati, OH 45221-0088 (513)556-3018 chris.collins at uc.edu UC Second Life: http://homepages.uc.edu/secondlife OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php On Sat, Feb 27, 2010 at 3:24 PM, Zha Ewry wrote: > Usual I am not a lawyer comments apply. > > One thing to keep in mind is that if you own the content, nothing requires > you to distribute it exclusively via Linden Lab's service. If you have a > set of textures which you hold rights to, putting them on Second Life > doesn't remove your rights to use and distribute those textures as you > see fit. > > While it would be nice if Second Life could distinguish between > free use within Second Life and Free use globally, at the moment > such mechanisms are absent. It's pretty straight forward to place > textures on standard web servers and make them available under the > appropriate license. I think the terms as written don't prohibit you from > downloading things you created, so again, it should be fine for you > to distribute them via other channels. > > > ~ Zha > > > > On Sat, Feb 27, 2010 at 3:02 PM, Morgaine > wrote: > > Fleep, you give an excellent example highlighting the needs of Education > in > > this area. > > > > Given the huge interest in educational content both in SL and in > > Opensim-based grids such as Science Sim, this is certain to be of major > and > > growing interest. > > > > Perhaps the FAQ could add a new clause FAQ.16 (renumbering the old FAQ.16 > > and all subsequent ones down) which reads something like this: > > > > Q16: Are the rights of open source or open content providers respected? > > A16: Yes. To further protect the rights of content creators beyond > FAQ.15, > > Linden Lab also respects the wishes of creators who release their content > > under open source or open content licenses to make their content freely > > exportable. (Typical licenses are GPL, BSD, or Creative Commons.) The > > responsibility for ensuring that such content does not contravene FAQ.15 > > rests entirely with the licensor, who must ensure that all parts either > > comply with FAQ.15 or have been released under an open license by their > > respective creators. > > > > That works remarkably well in conjunction with FAQ.15, because 15 covers > > everything that is not open content, and so neatly dumps the > responsibility > > for full compliance in the lap of each licensor in 16. > > > > And I particularly like the word "Yes", and the phrasing "Linden Lab also > > respects the wishes of creators who release their content under open > source > > or open content licenses to make their content freely exportable." It > would > > show good intentions directly, and without any fudging. > > > > > > > > Morgaine. > > > > > > > > > > > > ================================== > > > > On Sat, Feb 27, 2010 at 4:32 PM, Fleep Tuque wrote: > >> > >> (Sending for like the 4th time I hope this one gets through and sorry if > >> I've spammed) > >> Regarding Morgaine's comments about FAQ 15 - I fully agree that this > must > >> be the case: > >> > >> On Sat, Feb 27, 2010 at 1:47 AM, > >> Morgaine wrote: > >>> > >>> And finally, FAQ.15 (in the context of licenses permitting free > >>> distribution): > >>> > >>> Q15: Do the limitations of section 2.b on content export apply to > content > >>> that is full permissions? > >>> A15: Yes, they do. Residents retain intellectual property rights in > the > >>> content they create in Second Life and it is important for you to > respect > >>> those rights. By setting content to "full permissions" using the > Second > >>> Life permissions system, a content creator merely indicates that the > content > >>> may be copied, modified, and transferred within Second Life. Setting > >>> content to "full permissions" does not provide any permission to use > the > >>> content outside of Second Life. > >>> > >>> This is fine (surprise, surprise :P), but incomplete. It doesn't > address > >>> the quite common scenario of full-perm content created by Open Source > or > >>> Creative Commons developers using 100% personal textures, and > accompanied by > >>> a GPL, BSD, CC or other open source license which declares that the > content > >>> may be freely copied, modified, and transferred anywhere, not only > within > >>> Second Life. > >>> > >>> As is written in the answer A15, "Residents retain intellectual > property > >>> rights in the content they create in Second Life and it is important > for you > >>> to respect those rights." Respecting their rights in this case > requires you > >>> to to allow that content to be exported as its creator desires. > Therefore > >>> you either need to extend A15 with this additional case, or add another > FAQ > >>> Q+A (preferably immediately after #15) to address it. > >>> > >> > >> > >> The free content I create for education is intended to be fully free, > >> fully permissioned, and fully exportable to other grids. Beyond the > Second > >> Life permissions, I keep hoping for checkboxes on the Edit menu with > common > >> licenses or a space to put a link to the user's specified license that > is > >> kept with the object info just like creator name. > >> In any case, when I include Creative Commons licensing with my > educational > >> tools, and explicitly say users have my permission to explore the > content to > >> other grids, then I expect that to be respected by Linden Lab as well! > >> Sincerely, > >> - Chris/Fleep > >> > >> Chris M. Collins (SL: Fleep Tuque) > >> Project Manager, UC Second Life > >> Second Life Ambassador, Ohio Learning Network > >> UCit Instructional & Research Computing > >> University of Cincinnati > >> 406E Zimmer Hall > >> PO Box 210088 > >> Cincinnati, OH 45221-0088 > >> (513)556-3018 > >> chris.collins at uc.edu > >> UC Second Life: http://homepages.uc.edu/secondlife > >> OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php > >> > >> _______________________________________________ > >> 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100227/22b1592e/attachment-0001.htm From missannotoole at yahoo.com Sat Feb 27 12:43:14 2010 From: missannotoole at yahoo.com (Ann Otoole) Date: Sat, 27 Feb 2010 12:43:14 -0800 (PST) Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <893903.84310.qm@web59102.mail.re1.yahoo.com> So basically I cannot grant export for use in other grids licenses and must instead use some sort of a tool to export the assemblies myself and market them outside of SL as import packages. That seems to be problematic but more so it appears LL is attempting to deny the right to export any of your own work, licensed for intergrid use, for use elsewhere. We need the authorized viewer exports to include the texture binaries for textures and sculpties, that we uploaded ourselves, in the exports so the import packages will be complete and not dependent upon the LL asset system via UUID. And I expect the textures sold in SL intended for download and modification to be made in world use only and texture sellers will have to begin distribution of textures for derivative use outside SL. The question arises why should texture artists sell in SL or on xstreet at all at this point. LL is going to cut off revenue sources. ________________________________ From: Morgaine To: Soft Linden Cc: opensource-dev at lists.secondlife.com Sent: Sat, February 27, 2010 1:47:04 AM Subject: Re: [opensource-dev] FAQ posted for Third Party Viewer Policy Soft, this is quite a good FAQ (particularly compared to TPV #1:P) as it clears up a large number of points. I thought it might resolve the earlier problems re GPL compliance, particularly since it addresses the GPL directly. But when I examined it more closely it still has holes and confusion on the key points. Take FAQ.2 for example: Q2: Does the policy limit use of the viewer source code that Linden Lab makes available under the GPL? A2: No, the policy is not intended to and does not place any restriction on modification or use of our viewer source code that we make available under the GPL. 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. This looks great at first glance as it appears to make the separation between developers and users that caused so much confusion in TPV v1. But notice that the answer says "does not place any restriction on modification or use", and then goes on to say "Rather, the policy sets out requirements for connecting". Well connecting IS use, it couldn't be anything else, so the answer contradicts itself in one and the same paragraph. Such ambiguities need to be removed. The sentence was probably intended to say "does not place any restriction on modification or distribution", in order to clear the hurdle of GPLv2 clause 6. That clause explicitly requires freedom of modification and distribution. Nothing else will do, so if you want to be clear about GPL compliance, those words had better be there in A2. :-) Unfortunately, the question itself is confusing because it refers to use of the source code, and the GPL is completely unconcerned about use. Really the question should ask: * Q2: Does the policy limit modification and distribution of the viewer source code that Linden Lab makes available under the GPL? If that were the question then it would make sense in the context of addressing GPLv2 clause 6 directly, and it would match the corrected answer I gave above. Next, FAQ.12: * Q12: I develop for a Linux distribution where there is no opportunity to present users with the disclosures required under section 1.c before the user downloads and installs the software. How can I comply with section 1.c of the policy? * A12: For Linux distributions where there is no opportunity to provide the section 1.c disclosures before installation of the software, you can comply with the requirement by having your software client present the required disclosures or a link to them in a dialogue box that the user must close before logging into Second Life for the first time through your software. You can't require that of developers of GPL software. It's a restriction on a GPL developer's "freedom to modify and distribute", and is explicitly prohibited in GPLv2 clause 6. Please check the GPLv2 FAQ for the example of the original BSD advertising clause, which was incompatible with the GPL. That advertising clause had to be removed from GPL programs before they could be licensed using GPL, because it was an additional restriction on the freedom to modify and distribute. Your requirement is similar but much more onerous. It is a very clear additional restriction on the freedom to modify and distribute: for example, it restricts removal of the disclosure or dialogue box. Such an additional restriction is not permitted under GPL. Indeed, no additional restrictions on the freedom to modify and distribute are permitted at all. And finally, FAQ.15 (in the context of licenses permitting free distribution): * Q15: Do the limitations of section 2.b on content export apply to content that is full permissions? * A15: Yes, they do. Residents retain intellectual property rights in the content they create in Second Life and it is important for you to respect those rights. By setting content to "full permissions" using the Second Life permissions system, a content creator merely indicates that the content may be copied, modified, and transferred within Second Life. Setting content to "full permissions" does not provide any permission to use the content outside of Second Life. This is fine (surprise, surprise :P), but incomplete. It doesn't address the quite common scenario of full-perm content created by Open Source or Creative Commons developers using 100% personal textures, and accompanied by a GPL, BSD, CC or other open source license which declares that the content may be freely copied, modified, and transferred anywhere, not only within Second Life. As is written in the answer A15, "Residents retain intellectual property rights in the content they create in Second Life and it is important for you to respect those rights." Respecting their rights in this case requires you to to allow that content to be exported as its creator desires. Therefore you either need to extend A15 with this additional case, or add another FAQ Q+A (preferably immediately after #15) to address it. I'm limiting my interest to the open source / licensing aspects of TPV and FAQ so some of the Q+As I've skimmed only superficially, but they seem fairly reasonable. There are also some entries that refer to the forthcoming TPV document, so substantive comment now would not make sense. FAQ.3 is worrying though --- it hints that the TPV may list further restrictions on the GPL developer's freedom to modify and distribute, again in direct contravention of GPLv2 clause 6. Morgaine. ================================= On Sat, Feb 27, 2010 at 3:14 AM, Soft Linden wrote: There's now a FAQ for the Linden Lab Policy on Third Party Viewers: >http://bit.ly/caedse > >>This addresses many of the questions and concerns made in >>opensource-dev and elsewhere. An updated version of the TPV doc itself >>is also coming, but expect this within a couple weeks. Go visit the >>FAQ, or read on for the TPV doc update details... > >>I know that the member of the legal team who owns the policy doc is >>still working over the final version. Linden Lab has approached >>outside legal experts with your feedback, and one of these experts is >>a lawyer who specializes in open source license compliance issues. >>Based on these experts' feedback and further internal review, our >>legal department will incorporate any required changes. > >>In the meantime, while it helps to start making changes now, parts of >>the policy are not yet in effect. See the tail of the FAQ for dates >>and the portions affected. >>_______________________________________________ >>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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100227/43c38f99/attachment.htm From morgaine.dinova at googlemail.com Sat Feb 27 13:00:53 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Sat, 27 Feb 2010 21:00:53 +0000 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <920d7d851002271224x4dc21aefka42151439a8dfd7b@mail.gmail.com> References: <920d7d851002271224x4dc21aefka42151439a8dfd7b@mail.gmail.com> Message-ID: You only covered textures there, Zha. Items made in Second Life are composite objects that encapsulate geometry, textures, notecards, and often scripting, and it is the whole composite unit that is being licensed as open content in the scenario being discussed here. What's more, it may include items that other open developers have released in SL under an open license as well, not only self-made components. (The suggested new FAQ.16 addresses this.) Clearly none of this is captured by putting textures on a website. What's more, putting the composite objects on a website cannot be done until after you export them, so it's a chicken and egg situation, and this is why a clause permitting open-licensed exports is required in the first place. Finally, your website idea reduces the opportunity for content sharing at which SL is so good. Open content creators should not be discouraged from building and learning with other people's open content by keeping it off-world on websites. Such content is already in-world in SL today (lots of it) under appropriate licenses. Note that I have carefully and explicitly placed the responsibility for compliance with FAQ.15 and with open licensing on the shoulders of the licensor. You mention that mechanisms to handle this do not exist within SL, but none are needed --- they don't exist in RL either, so it is handled in RL by enclosing a license. That works perfectly well here too, and it is already being done today. It needs to be covered in the TPV+FAQ. Morgaine. ================================= On Sat, Feb 27, 2010 at 8:24 PM, Zha Ewry wrote: > Usual I am not a lawyer comments apply. > > One thing to keep in mind is that if you own the content, nothing requires > you to distribute it exclusively via Linden Lab's service. If you have a > set of textures which you hold rights to, putting them on Second Life > doesn't remove your rights to use and distribute those textures as you > see fit. > > While it would be nice if Second Life could distinguish between > free use within Second Life and Free use globally, at the moment > such mechanisms are absent. It's pretty straight forward to place > textures on standard web servers and make them available under the > appropriate license. I think the terms as written don't prohibit you from > downloading things you created, so again, it should be fine for you > to distribute them via other channels. > > > ~ Zha > > > > On Sat, Feb 27, 2010 at 3:02 PM, Morgaine > wrote: > > Fleep, you give an excellent example highlighting the needs of Education > in > > this area. > > > > Given the huge interest in educational content both in SL and in > > Opensim-based grids such as Science Sim, this is certain to be of major > and > > growing interest. > > > > Perhaps the FAQ could add a new clause FAQ.16 (renumbering the old FAQ.16 > > and all subsequent ones down) which reads something like this: > > > > Q16: Are the rights of open source or open content providers respected? > > A16: Yes. To further protect the rights of content creators beyond > FAQ.15, > > Linden Lab also respects the wishes of creators who release their content > > under open source or open content licenses to make their content freely > > exportable. (Typical licenses are GPL, BSD, or Creative Commons.) The > > responsibility for ensuring that such content does not contravene FAQ.15 > > rests entirely with the licensor, who must ensure that all parts either > > comply with FAQ.15 or have been released under an open license by their > > respective creators. > > > > That works remarkably well in conjunction with FAQ.15, because 15 covers > > everything that is not open content, and so neatly dumps the > responsibility > > for full compliance in the lap of each licensor in 16. > > > > And I particularly like the word "Yes", and the phrasing "Linden Lab also > > respects the wishes of creators who release their content under open > source > > or open content licenses to make their content freely exportable." It > would > > show good intentions directly, and without any fudging. > > > > > > > > Morgaine. > > > > > > > > > > > > ================================== > > > > On Sat, Feb 27, 2010 at 4:32 PM, Fleep Tuque wrote: > >> > >> (Sending for like the 4th time I hope this one gets through and sorry if > >> I've spammed) > >> Regarding Morgaine's comments about FAQ 15 - I fully agree that this > must > >> be the case: > >> > >> On Sat, Feb 27, 2010 at 1:47 AM, > >> Morgaine wrote: > >>> > >>> And finally, FAQ.15 (in the context of licenses permitting free > >>> distribution): > >>> > >>> Q15: Do the limitations of section 2.b on content export apply to > content > >>> that is full permissions? > >>> A15: Yes, they do. Residents retain intellectual property rights in > the > >>> content they create in Second Life and it is important for you to > respect > >>> those rights. By setting content to "full permissions" using the > Second > >>> Life permissions system, a content creator merely indicates that the > content > >>> may be copied, modified, and transferred within Second Life. Setting > >>> content to "full permissions" does not provide any permission to use > the > >>> content outside of Second Life. > >>> > >>> This is fine (surprise, surprise :P), but incomplete. It doesn't > address > >>> the quite common scenario of full-perm content created by Open Source > or > >>> Creative Commons developers using 100% personal textures, and > accompanied by > >>> a GPL, BSD, CC or other open source license which declares that the > content > >>> may be freely copied, modified, and transferred anywhere, not only > within > >>> Second Life. > >>> > >>> As is written in the answer A15, "Residents retain intellectual > property > >>> rights in the content they create in Second Life and it is important > for you > >>> to respect those rights." Respecting their rights in this case > requires you > >>> to to allow that content to be exported as its creator desires. > Therefore > >>> you either need to extend A15 with this additional case, or add another > FAQ > >>> Q+A (preferably immediately after #15) to address it. > >>> > >> > >> > >> The free content I create for education is intended to be fully free, > >> fully permissioned, and fully exportable to other grids. Beyond the > Second > >> Life permissions, I keep hoping for checkboxes on the Edit menu with > common > >> licenses or a space to put a link to the user's specified license that > is > >> kept with the object info just like creator name. > >> In any case, when I include Creative Commons licensing with my > educational > >> tools, and explicitly say users have my permission to explore the > content to > >> other grids, then I expect that to be respected by Linden Lab as well! > >> Sincerely, > >> - Chris/Fleep > >> > >> Chris M. Collins (SL: Fleep Tuque) > >> Project Manager, UC Second Life > >> Second Life Ambassador, Ohio Learning Network > >> UCit Instructional & Research Computing > >> University of Cincinnati > >> 406E Zimmer Hall > >> PO Box 210088 > >> Cincinnati, OH 45221-0088 > >> (513)556-3018 > >> chris.collins at uc.edu > >> UC Second Life: http://homepages.uc.edu/secondlife > >> OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php > >> > >> _______________________________________________ > >> 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100227/96f66704/attachment-0001.htm From tayra.dagostino at gmail.com Sat Feb 27 15:23:21 2010 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Sun, 28 Feb 2010 00:23:21 +0100 Subject: [opensource-dev] latest SG1.3.2 Message-ID: <20100228002321.4806e478.tayra.dagostino@gmail.com> 2010-02-27T23:19:47Z INFO: LLViewerMedia::getCurrentUserAgent: SecondLife/1.3.2.3219 (Snowglobe Release; default skin) pid:24128: (media plugin) grab_gst_syms:91: Found DSO: libgstreamer-0.10.so.0 pid:24128: (media plugin) grab_gst_syms:105: Found DSO: libgstvideo-0.10.so.0 2010-02-27T23:19:47Z INFO: fetchDescendents: agent/inventory not on AD, checking fallback to region 2010-02-27T23:19:47Z INFO: fetchDescendents: WebFetchInventoryDescendents or agent/inventory capability not found. Using deprecated UDP message. pid:24128: (media plugin) MediaPluginGStreamer010:165: MediaPluginGStreamer010 constructor - my PID=24128 pid:24128: (media plugin) receiveMessage:943: GStreamer010 media instance failed to set up 2010-02-27T23:19:47Z INFO: LLPluginProcessParent::receiveMessage: plugin version string: GStreamer010 media plugin, GStreamer version 0.10.26.0 (runtime), 0.10.6.0 (headers) 2010-02-27T23:19:47Z INFO: LLPluginProcessParent::receiveMessage: message class: base -> version: 1.0 2010-02-27T23:19:47Z INFO: LLPluginProcessParent::receiveMessage: message class: media -> version: 1.0 2010-02-27T23:19:47Z INFO: LLPluginProcessParent::receiveMessage: message class: media_time -> version: 1.0 pid:24128: (media plugin) receiveMessage:997: MediaPluginGStreamer010::receiveMessage: shared memory added, name: /LL24094_2, size: 8, address: 0xb74cf000 pid:24128: (media plugin) receiveMessage:1048: ---->Got size change instruction from application with shm name: /LL24094_2 - size is 1 x 1 pid:24128: (media plugin) receiveMessage:1064: *** Got size change with matching shm, new size is 1 x 1 pid:24128: (media plugin) receiveMessage:1065: *** Got size change with matching shm, texture size size is 1 x 1 pid:24128: (media plugin) receiveMessage:1157: MediaPluginGStreamer010::receiveMessage: unknown message class: media_browser (:24128): GStreamer-CRITICAL **: gst_element_set_state: assertion `GST_IS_ELEMENT (element)' failed somebody else notice this on a lenny+backports? From soft at lindenlab.com Sat Feb 27 17:31:40 2010 From: soft at lindenlab.com (Soft Linden) Date: Sat, 27 Feb 2010 19:31:40 -0600 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: On Sat, Feb 27, 2010 at 12:47 AM, Morgaine wrote: > > Q2: Does the policy limit use of the viewer source code that Linden Lab > makes available under the GPL? > A2: No, the policy is not intended to and does not place any restriction on > modification or use of our viewer source code that we make available under > the GPL. ?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. > > This looks great at first glance as it appears to make the separation > between developers and users that caused so much confusion in TPV v1. > > But notice that the answer says "does not place any restriction on > modification or use", and then goes on to say "Rather, the policy sets out > requirements for connecting".? Well connecting IS use, it couldn't be > anything else, so the answer contradicts itself in one and the same > paragraph. Such ambiguities need to be removed. It's important to understand that one can discontinue use of Second Life at any point. On doing so, there are no further obligations imposed by the TPV policy. The legal consults cleared this as a resolution to all free license issues. This agreement makes no restrictions on what anyone can do with the source. The GPL makes no restrictions on connecting to Second Life. These are two separate agreements, and don't need to be reconciled in such a way that each permits everything allowed by the other. That said, Linden Lab intends to keep the viewer platform under an open source license. If anyone ever received a request to alter the viewer in a way that would violate the GPL, point that out. Odds are the request isn't being communicated properly, or somebody didn't know of the implications. Again though - any request is just that. A change isn't required if the viewer author chooses to instead stop using it to connect to the service and withdraws it from the Viewer Directory. > Next, FAQ.12: > > Q12:? I develop for a Linux distribution where there is no opportunity to > present users with the disclosures required under section 1.c before the > user downloads and installs the software. ?How can I comply with section 1.c > of the policy? > A12: For Linux distributions where there is no opportunity to provide the > section 1.c disclosures before installation of the software, you can comply > with the requirement by having your software client present the required > disclosures or a link to them in a dialogue box that the user must close > before logging into Second Life for the first time through your software. > > You can't require that of developers of GPL software.? It's a restriction on > a GPL developer's "freedom to modify and distribute", and is explicitly > prohibited in GPLv2 clause 6.? Please check the GPLv2 FAQ for the example of > the original BSD advertising clause, which was incompatible with the GPL. > That advertising clause had to be removed from GPL programs before they > could be licensed using GPL, because it was an additional restriction on the > freedom to modify and distribute. Anyone can make a derivative viewer that doesn't comply with the policy. That version of the viewer would not be eligible for inclusion in the Viewer Directory. The situation here is similar. Nothing is prohibited in terms of use of the GPL licensed code. The restriction is strictly placed on participation in the Viewer Directory. > And finally, FAQ.15 (in the context of licenses permitting free > distribution): > > Q15: Do the limitations of section 2.b on content export apply to content > that is full permissions? > A15: Yes, they do.? Residents retain intellectual property rights in the > content they create in Second Life and it is important for you to respect > those rights.? By setting content to "full permissions" using the Second > Life permissions system, a content creator merely indicates that the content > may be copied, modified, and transferred within Second Life. ?Setting > content to "full permissions" does not provide any permission to use the > content outside of Second Life. > > This is fine (surprise, surprise :P), but incomplete.? It doesn't address > the quite common scenario of full-perm content created by Open Source or > Creative Commons developers using 100% personal textures, and accompanied by > a GPL, BSD, CC or other open source license which declares that the content > may be freely?copied, modified, and transferred anywhere, not only within > Second Life. > > As is written in the answer A15, "Residents retain intellectual property > rights in the content they create in Second Life and it is important for you > to respect those rights."? Respecting their rights in this case requires you > to to allow that content to be exported as its creator desires.? Therefore > you either need to extend A15 with this additional case, or add another FAQ > Q+A (preferably immediately after #15) to address it. That might be material for the FAQ. But because there is no export permission bit, it's not possible to add export capability for these cases without enabling violation of others' content. At this point, I couldn't see that affecting the TPV policy. From soft at lindenlab.com Sat Feb 27 17:45:05 2010 From: soft at lindenlab.com (Soft Linden) Date: Sat, 27 Feb 2010 19:45:05 -0600 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <5ebce2ec1002270032k372d8cc3na583309c5290cadb@mail.gmail.com> References: <5ebce2ec1002270032k372d8cc3na583309c5290cadb@mail.gmail.com> Message-ID: Yes. Removing 1.h will be the biggest change made to the TPV policy. The rest will be much smaller tweaks. There wasn't a good, unambiguous way to state the intent of that provision. There were really two parts to it: 1) SL shouldn't just be used as a blind data conduit. We shouldn't be footing the bill and responsibility for big file exchanges, gaming that don't even make it possible to access SL's world, or anything else fundamentally unrelated to virtual world interaction. 2) Important features shouldn't be removed gratuitously. But that's difficult to write, since many minimal viewers don't benefit by having those features, or adding them would create a huge barrier. When it gets to policing the intent behind a feature's omission, things get squishy fast. On Sat, Feb 27, 2010 at 2:32 AM, Latif Khalifa wrote: > Hi Soft, I'm very pleased too see that some of our biggest concerns > were taken into account. For me especially the FAQ states that > provision 1.h about "shared experience" is going to be removed, as it > would be impossible to bring Radegast into compliance with the policy > if that clause were to stay in it. Kudos! > > Latif > > On Sat, Feb 27, 2010 at 4:14 AM, Soft Linden wrote: >> There's now a FAQ for the Linden Lab Policy on Third Party Viewers: >> http://bit.ly/caedse >> >> This addresses many of the questions and concerns made in >> opensource-dev and elsewhere. An updated version of the TPV doc itself >> is also coming, but expect this within a couple weeks. Go visit the >> FAQ, or read on for the TPV doc update details... >> >> I know that the member of the legal team who owns the policy doc is >> still working over the final version. Linden Lab has approached >> outside legal experts with your feedback, and one of these experts is >> a lawyer who specializes in open source license compliance issues. >> Based on these experts' feedback and further internal review, our >> legal department will incorporate any required changes. >> >> In the meantime, while it helps to start making changes now, parts of >> the policy are not yet in effect. See the tail of the FAQ for dates >> and the portions affected. >> _______________________________________________ >> 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 >> > From soft at lindenlab.com Sat Feb 27 17:53:42 2010 From: soft at lindenlab.com (Soft Linden) Date: Sat, 27 Feb 2010 19:53:42 -0600 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <20100227103231.22d26e14.sldev@free.fr> References: <20100227103231.22d26e14.sldev@free.fr> Message-ID: On Sat, Feb 27, 2010 at 3:32 AM, Henri Beauchamp wrote: > On Fri, 26 Feb 2010 21:14:52 -0600, Soft Linden wrote: > >> There's now a FAQ for the Linden Lab Policy on Third Party Viewers: >> http://bit.ly/caedse > > Very good job, Soft, thank you ! :-) Ah, I didn't write it! I only pointed out that it exists. > However, there are a couple of points that I think should be addressed > or precised in this FAQ: > > 1. The trademarking rules as presented in the TPV are in contradiction > ? with Linden Lab's own trademark policy. In particular: > ? ? ?5.b.i You must not have a Third-Party Viewer name that is > ? ? ? ? ? ? ? ? ? ? ? ?________ Life? where ?________? is a term or series of terms. > ? Is in contracdiction with: > ? http://secondlife.com/corporate/brand/trademark/unauthorized.php > ? in which we see that "[anything] Life" is not forbidden as long > ? as [anything] does not contain "Second". > ? I would call such a trademarking a "domain trademarking" (like > ? a domain name for an Internet site address"), but I doubt very much > ? such a rule would be legal, even in USA... It's not in contradiction. It's more explicit on what's "confusingly similar to a Linden Lab trademark" in point 1 or an "adaptation" in point 5. It didn't list these word substitution examples specifically, but the page also said it wasn't limited to the examples given. I think that page was written before they knew what adaptations people might use. > 2. in the FAQ, to the question "I do not want a publicly available > ? listing in the Viewer Directory to disclose my own name or contact > ? information. ?Is it possible for the public listing page to show > ? just the brand name of my third-party viewer?", the answer states > ? that name and contact info must be provided to Linden Lab, however > ? the type of "contact information" is not precised. An email from > ? an ISP account (not an anonymous Yahoo/Hotmail/Google/whatnot > ? account, of course) *is* a contact information that is sufficient > ? to legally identify the developper in case of any action against > ? them. But right now, the full snail mail address is required, > ? which is in violation with some international laws protecting user > ? privacy (notably the French law "Informatique et Libert?"). > > I hope to see these two points addressed. I know the identity requirement will remain, and I expect there will be a form that's more explicit about what information is required, if there isn't already. If you know of any law that makes it illegal to require email as a condition of being listed in an optional directory, it would be helpful to tell me where to find it so I can pass it on to legal. From soft at lindenlab.com Sat Feb 27 17:58:21 2010 From: soft at lindenlab.com (Soft Linden) Date: Sat, 27 Feb 2010 19:58:21 -0600 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <9e52a8c11002270327n54bc13b5h21cafd041bb5d7f1@mail.gmail.com> References: <20100227103231.22d26e14.sldev@free.fr> <9e52a8c11002270327n54bc13b5h21cafd041bb5d7f1@mail.gmail.com> Message-ID: On Sat, Feb 27, 2010 at 5:27 AM, Marine Kelley wrote: > I don't know much about it, but what about the data that most of us already > entered when signing up to SL ? LL should have these data stored somewhere, > why do we have to enter them all again ? If the data to be entered to sign > in to the viewer directory is not linked to it, what gives LL the certainty > that they are accurate, where are they stored, and what is the privacy > policy ? The TPV says "may be published", but there is no way to be sure... > And moreso, the FAQ says that listing in the directory might become > mandatory. With such vague terms it is impossible to comply to these > requirements, which are way too intrusive for a hobbyist. > > Sorry about this, it seems that publishing a Frequently Asked Questions page > brings even more questions ! It is always like this. lol. I'll ask to be certain, but I expect that if the viewer changed from opt-in identity disclosure to mandatory identity disclosure, every participant would be given the option to be listed or be dropped. Without a response, we would drop the listing. It would be totally unreasonable for us to just add the names one day. From soft at lindenlab.com Sat Feb 27 18:09:57 2010 From: soft at lindenlab.com (Soft Linden) Date: Sat, 27 Feb 2010 20:09:57 -0600 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4ebfc1101002270510s4cd26228k1d87d62b8405ccd7@mail.gmail.com> References: <20100227103231.22d26e14.sldev@free.fr> <9e52a8c11002270327n54bc13b5h21cafd041bb5d7f1@mail.gmail.com> <4ebfc1101002270510s4cd26228k1d87d62b8405ccd7@mail.gmail.com> Message-ID: On Sat, Feb 27, 2010 at 7:10 AM, Gareth Nelson wrote: > A few queries I have: > > Sometimes I code random small scripts to do quick inworld tasks - do I > have to have 100% compliance for these scripts? > I have a bot which comes in 2 parts - SL interface and AI engine, the > SL interface being a simple protocol handler - how does the policy > affect my AI engine if at all? If only the SL interface need be > compliant, isn't this a major loophole in that the AI engine could use > it to perform various malicious deeds? If the scripted bit was causing the viewer to do something in violation of SL terms, I'm pretty sure it (and the author) would be handled as with any other non ToS-compliant content. If the viewer has legitimate use, it shouldn't be affected. > If I code a viewer which is designed for use with other grids, does > not comply with the policy and is not intended for use on SL, but one > of my users connects to SL with it anyway , how does that reflect on > me? The viewer wouldn't be eligible for inclusion in the Viewer Directory, and only the people connecting with that viewer would be in violation. From soft at lindenlab.com Sat Feb 27 18:24:57 2010 From: soft at lindenlab.com (Soft Linden) Date: Sat, 27 Feb 2010 20:24:57 -0600 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: On Sat, Feb 27, 2010 at 10:32 AM, Fleep Tuque wrote: > > The free content I create for education is intended to be fully free, fully > permissioned, and fully exportable to other grids. ?Beyond the Second Life > permissions, I keep hoping for checkboxes on the Edit menu with common > licenses or a space to put a link to the user's specified license that is > kept with the object info just like creator name. > In any case, when I include Creative Commons licensing with my educational > tools, and?explicitly?say users have my permission to explore the content to > other grids, then I expect that to be respected by Linden Lab as well! As someone else pointed out in this thread, you're able to host your content outside of Second Life if you want to ensure people are able to import it again. You're not restricted to using Second Life for content distribution, and with an external site you can present your full license, not just half a byte's worth of permission data. For a great example of how you might spread your content, see the script library at http://secondlife.mitsi.com/cgi/llscript.plx From merov at lindenlab.com Sat Feb 27 22:07:48 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Sat, 27 Feb 2010 22:07:48 -0800 Subject: [opensource-dev] Snowglobe 1.3 RC2 Message-ID: <78f69851002272207r386f5c15h77153a17ffac938b@mail.gmail.com> Hi, We finally nailed those last 2 show stoppers and got the build machines running again so, here we go with Snowglobe 1.3 RC 2 (1.3.2) which is likely the last of 1.3 serie. The last few weeks of testing have been pretty good and folks have been reporting better stability with the 1.3 branch so we're pretty confident this is the one. If no show stopper is reported between now and the next Hippo meeting (Thursday), we'll declare that one the official Snowglobe download. Then, onward to complete Snowglobe 2.0! Here are the bugs fixed since RC1 (build 3125): * SNOW-485 Fix deadlock in LLTextureFetchWorker * SNOW-431 Fix the boost libraries for Mac and Linux * SNOW-488 Fix animation decode issue by improving check when comparing S32 with U32 for for array access safety. * SNOW-484 Prevent recursive animation/emote loops * SNOW-196 More on Deadlock in LLTextureFetchWorker::lockWorkMutex / LLThread::lockData / LLTextureFetch::lockQueue Downloads: Windows: http://secondlife.com/developers/opensource/downloads/2010/1.3/3219/Snowglobe_1-3-2-3219_Setup.exe Darwin: http://secondlife.com/developers/opensource/downloads/2010/1.3/3219/Snowglobe_1_3_2_3219.dmg Linux: http://secondlife.com/developers/opensource/downloads/2010/1.3/3219/Snowglobe-i686-1.3.2.3219.tar.bz2 Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100227/21a29a8c/attachment-0001.htm From sldev at free.fr Sun Feb 28 00:30:19 2010 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 28 Feb 2010 09:30:19 +0100 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: <20100227103231.22d26e14.sldev@free.fr> Message-ID: <20100228093019.83ba2eed.sldev@free.fr> On Sat, 27 Feb 2010 19:53:42 -0600, Soft Linden wrote: > On Sat, Feb 27, 2010 at 3:32 AM, Henri Beauchamp wrote: > > On Fri, 26 Feb 2010 21:14:52 -0600, Soft Linden wrote: > > > >> There's now a FAQ for the Linden Lab Policy on Third Party Viewers: > >> http://bit.ly/caedse > > > > Very good job, Soft, thank you ! :-) > > Ah, I didn't write it! I only pointed out that it exists. But you played the role of the "negociator", and without your work, this FAQ won't exist, so... :-) > > However, there are a couple of points that I think should be addressed > > or precised in this FAQ: > > > > 1. The trademarking rules as presented in the TPV are in contradiction > > ? with Linden Lab's own trademark policy. In particular: > > ? ? ?5.b.i You must not have a Third-Party Viewer name that is > > ? ? ? ? ? ?________ Life? where ?________? is a term or series > > of terms. > > ? Is in contracdiction with: > > ? http://secondlife.com/corporate/brand/trademark/unauthorized.php > > ? in which we see that "[anything] Life" is not forbidden as long > > ? as [anything] does not contain "Second". > > ? I would call such a trademarking a "domain trademarking" (like > > ? a domain name for an Internet site address"), but I doubt very much > > ? such a rule would be legal, even in USA... > > It's not in contradiction. It's more explicit on what's "confusingly > similar to a Linden Lab trademark" in point 1 or an "adaptation" in > point 5. It didn't list these word substitution examples specifically, > but the page also said it wasn't limited to the examples given. I > think that page was written before they knew what adaptations people > might use. I still think this would stand as an abusive clause in a court (including for a TOS clause for connecting to SL), but I'm no lawyer... > > 2. in the FAQ, to the question "I do not want a publicly available > > ? listing in the Viewer Directory to disclose my own name or contact > > ? information. ?Is it possible for the public listing page to show > > ? just the brand name of my third-party viewer?", the answer states > > ? that name and contact info must be provided to Linden Lab, however > > ? the type of "contact information" is not precised. An email from > > ? an ISP account (not an anonymous Yahoo/Hotmail/Google/whatnot > > ? account, of course) *is* a contact information that is sufficient > > ? to legally identify the developper in case of any action against > > ? them. But right now, the full snail mail address is required, > > ? which is in violation with some international laws protecting user > > ? privacy (notably the French law "Informatique et Libert?"). > > > > I hope to see these two points addressed. > > I know the identity requirement will remain, and I expect there will > be a form that's more explicit about what information is required, if > there isn't already. For now, email and full snail mail address are required in addition to the real name. > If you know of any law that makes it illegal to require email as a > condition of being listed in an optional directory, it would be > helpful to tell me where to find it so I can pass it on to legal. Real name and (ISP hosted) email address are both OK and adequate (they provide both a mean of communication and a mean of identification, the latter in the case a legal action would be taken by Linden Lab), the only thing which is not OK as the form is right now (beside the mention that private info may be published) is the snail mail address requirement (unneeded at all, thus it shall not be a required info). Best regards, Henri. From marinekelley at gmail.com Sun Feb 28 00:34:55 2010 From: marinekelley at gmail.com (Marine Kelley) Date: Sun, 28 Feb 2010 09:34:55 +0100 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: <20100227103231.22d26e14.sldev@free.fr> <9e52a8c11002270327n54bc13b5h21cafd041bb5d7f1@mail.gmail.com> Message-ID: <9e52a8c11002280034j23453996x6429cd7b3707664b@mail.gmail.com> I had understood the same, but still am not reassured. To put it simply : - Publishing my RL name and address is out of question. Ever. - Listing the RLV in the Viewer Directory requires me to give my RL info to LL, with the hopes it will stay private. Dare I say, the people maintaining this list are NOT the people I trusted when I signed up to SL in the first place. And dare I add, I had to sign up twice : once to go Premium, and again to verify to Aristotle. Big issue number one here. - The Viewer Directory "may" (which in my book means "eventually will") require to publish the RL info of all participants on the page or be dropped. Big issue number two here. - Being listed in the Viewer Directory "may" (once again, same meaning to me) become mandatory in order to connect to the Second Life grid. What makes LL sure that a rogue viewer will not spoof the ID of a listed viewer in order to be accepted upon connection ? Big issue number three here. So, does that all mean that eventually the RLV will not be able to connect to the Second Life grid at some point, unless it becomes a rogue viewer that spoofs the identity of another listed one ? Or do I need to stop it all now to avoid losing sleep ? Or do I need to pass the project on to someone who accepts to have their data published ? Besides, this Viewer Directory is meaningless. It does not stand for a list of viewers that have been technically approved by LL, nor can it ever be. Nothing keeps a viewer dev to go totally rogue and start stealing L$, passwords and other info, and LL would have zilch to retaliate because the RL data entered would have probably been false in the first place. And no, LL does not have legally the right to officially verify someone's RL address in some countries, for instance in France, where only legal institutions have the right to do that, as Henri pointed out. Sorry, but this Viewer Directory and all its implications have me greatly worried. And the lack of assurance that it won't switch from "informational" to "whitelist" at some point, with all the requirements going along with it, is enough to make me want to drop it. I vote for not using the Viewer Directory at all. It is useless because it doesn't guarantee that its listed viewers are safe, and dangerous for the future of Second Life because it is potentially going to breach privacy. I'd like to remind people of my proposed solution, back when LL asked everyone about how to set their third party viewer policy, a few months ago. I had proposed to make it so that only viewers built on a LL-owned dedicated machine would be accepted. Such binaries would be the result of the build of committed sources, with the addition of a small code (unknown to the devs of the viewer) that would transfer a hash to the grid upon connecting (and possibly regularly afterward while online). The binaries would be hosted on LL's website, along with the sources, and everyone would have been able to consult the sources while being sure there would not be any difference between these sources and the resulting binaries (with the exception of the code I mentioned). Granted, this is an expensive solution, and potentially difficult while testing (there has to be some temporary code for that purpose, for instance a code that allows only 4 or 5 viewers using it at the same time), but the only solution that formally guarantees that Build = Source, and that the source can be reviewed, instead of testing every viewer, which takes much longer. No listing and no requirement is ever going to replace that. Marine On 28 February 2010 02:58, Soft Linden wrote: > On Sat, Feb 27, 2010 at 5:27 AM, Marine Kelley > wrote: > > I don't know much about it, but what about the data that most of us > already > > entered when signing up to SL ? LL should have these data stored > somewhere, > > why do we have to enter them all again ? If the data to be entered to > sign > > in to the viewer directory is not linked to it, what gives LL the > certainty > > that they are accurate, where are they stored, and what is the privacy > > policy ? The TPV says "may be published", but there is no way to be > sure... > > And moreso, the FAQ says that listing in the directory might become > > mandatory. With such vague terms it is impossible to comply to these > > requirements, which are way too intrusive for a hobbyist. > > > > Sorry about this, it seems that publishing a Frequently Asked Questions > page > > brings even more questions ! It is always like this. lol. > > I'll ask to be certain, but I expect that if the viewer changed from > opt-in identity disclosure to mandatory identity disclosure, every > participant would be given the option to be listed or be dropped. > Without a response, we would drop the listing. It would be totally > unreasonable for us to just add the names one day. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100228/c484e0fd/attachment.htm From Lance.Corrimal at eregion.de Sun Feb 28 01:06:43 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 28 Feb 2010 10:06:43 +0100 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <20100228093019.83ba2eed.sldev@free.fr> References: <20100228093019.83ba2eed.sldev@free.fr> Message-ID: <201002281006.43982.Lance.Corrimal@eregion.de> Am Sonntag 28 Februar 2010 schrieb Henri Beauchamp: > > I know the identity requirement will remain, and I expect there > > will be a form that's more explicit about what information is > > required, if there isn't already. > > For now, email and full snail mail address are required in addition > to the real name. > > > If you know of any law that makes it illegal to require email as > > a condition of being listed in an optional directory, it would be > > helpful to tell me where to find it so I can pass it on to legal. > > Real name and (ISP hosted) email address are both OK and adequate > (they provide both a mean of communication and a mean of > identification, the latter in the case a legal action would be > taken by Linden Lab), the only thing which is not OK as the form > is right now (beside the mention that private info may be > published) is the snail mail address requirement (unneeded at all, > thus it shall not be a required info). Right now I'm working on porting henri's cool patches to snowglobe. As it stands now, I'm not going to put it into the viewer directory, unless the requirements for any other data than my SL name and a valid, working email address are taken down. Real name is only acceptable if not publicly shown anywhere. bye, LC From sldev at free.fr Sun Feb 28 01:17:22 2010 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 28 Feb 2010 10:17:22 +0100 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <9e52a8c11002280034j23453996x6429cd7b3707664b@mail.gmail.com> References: <20100227103231.22d26e14.sldev@free.fr> <9e52a8c11002270327n54bc13b5h21cafd041bb5d7f1@mail.gmail.com> <9e52a8c11002280034j23453996x6429cd7b3707664b@mail.gmail.com> Message-ID: <20100228101722.9a7bf6be.sldev@free.fr> On Sun, 28 Feb 2010 09:34:55 +0100, Marine Kelley wrote: > I'd like to remind people of my proposed solution, back when LL asked > everyone about how to set their third party viewer policy, a few months ago. > I had proposed to make it so that only viewers built on a LL-owned dedicated > machine would be accepted. Such binaries would be the result of the build of > committed sources, This might sound good, but in fact it would be close to impossible, and would make TPV developpers unable to control the building envirnonment, something crucial. For example, I build my Linux viewers on a Mandriva 2007 distro, so that the glibc libraries are compatible even with old distros. I also have to make a lot of manual adjustements within VS2055 in order to build the Windows version of the Cool SL Viewer v1.19.2 (which is based on v1.19.0.5 LL's viewer and was originally coded to build with VS2003). This viewer also can't be built automatically like v1.23 and cmake... What also, about devs who provide PPC MacOS builds ?... I'm sorry, but this can't work for the Cool SL Viewer... > with the addition of a small code (unknown to the devs of > the viewer) that would transfer a hash to the grid upon connecting (and > possibly regularly afterward while online). This is a BIG no-no... The GPL doesn't allow this in the first place since the sources as made openly available must compile exactly to the published binary on anyone's machine. Sorry, Marine, but I vote against your proposal. Henri. From gareth at garethnelson.com Sun Feb 28 02:36:41 2010 From: gareth at garethnelson.com (Gareth Nelson) Date: Sun, 28 Feb 2010 10:36:41 +0000 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: <20100227103231.22d26e14.sldev@free.fr> <9e52a8c11002270327n54bc13b5h21cafd041bb5d7f1@mail.gmail.com> <4ebfc1101002270510s4cd26228k1d87d62b8405ccd7@mail.gmail.com> Message-ID: <4ebfc1101002280236x32696d55x4c785d4da5ed0c77@mail.gmail.com> On Sun, Feb 28, 2010 at 2:09 AM, Soft Linden wrote: > On Sat, Feb 27, 2010 at 7:10 AM, Gareth Nelson wrote: >> A few queries I have: >> >> Sometimes I code random small scripts to do quick inworld tasks - do I >> have to have 100% compliance for these scripts? >> I have a bot which comes in 2 parts - SL interface and AI engine, the >> SL interface being a simple protocol handler - how does the policy >> affect my AI engine if at all? If only the SL interface need be >> compliant, isn't this a major loophole in that the AI engine could use >> it to perform various malicious deeds? > > If the scripted bit was causing the viewer to do something in > violation of SL terms, I'm pretty sure it (and the author) would be > handled as with any other non ToS-compliant content. If the viewer has > legitimate use, it shouldn't be affected. > > >> If I code a viewer which is designed for use with other grids, does >> not comply with the policy and is not intended for use on SL, but one >> of my users connects to SL with it anyway , how does that reflect on >> me? > > The viewer wouldn't be eligible for inclusion in the Viewer Directory, > and only the people connecting with that viewer would be in violation. > Does this imply that using a viewer not in the directory is a liability for users? -- ?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 From gareth at garethnelson.com Sun Feb 28 02:49:49 2010 From: gareth at garethnelson.com (Gareth Nelson) Date: Sun, 28 Feb 2010 10:49:49 +0000 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <201002281006.43982.Lance.Corrimal@eregion.de> References: <20100228093019.83ba2eed.sldev@free.fr> <201002281006.43982.Lance.Corrimal@eregion.de> Message-ID: <4ebfc1101002280249o5d4fc9b8i8ea144c4dcb1a84f@mail.gmail.com> For myself, I'd happily give my real name and an email address - but not a postal address for public access. Anyone who would consider doing that is lucky to never have had a stalker (trust me, it's not pleasant). If the reason for requiring this information is "in case we need to sue you" then it's in no developer's interests to give it. An email address is fine for contact info, and a real name is unneeded, but shouldn't be a massive concern - personally I only use a secret alias online if i'm trying to hide. People have mentioned "kinky stuff" in SL as being a reason to hide - well, i'm perfectly happy to show everyone videos and screenshots of myself in a sex club just to prove i'm serious about "nothing to hide". Hopefully that means you can also trust me not to put nasty trojans in my code. Of course whether you'll ever use my code is dependent on contacting me directly these days - no way am I signing the contributor agreement to get patches into the main viewer. On Sun, Feb 28, 2010 at 9:06 AM, Lance Corrimal wrote: > Am Sonntag 28 Februar 2010 schrieb Henri Beauchamp: > >> > I know the identity requirement will remain, and I expect there >> > will be a form that's more explicit about what information is >> > required, if there isn't already. >> >> For now, email and full snail mail address are required in addition >> ?to the real name. >> >> > If you know of any law that makes it illegal to require email as >> > a condition of being listed in an optional directory, it would be >> > helpful to tell me where to find it so I can pass it on to legal. >> >> Real name and (ISP hosted) email address are both OK and adequate >> (they provide both a mean of communication and a mean of >> ?identification, the latter in the case a legal action would be >> ?taken by Linden Lab), the only thing which is not OK as the form >> ?is right now (beside the mention that private info may be >> ?published) is the snail mail address requirement (unneeded at all, >> ?thus it shall not be a required info). > > > Right now I'm working on porting henri's cool patches to snowglobe. > As it stands now, I'm not going to put it into the viewer directory, > unless the requirements for any other data than my SL name and a > valid, working email address are taken down. Real name is only > acceptable if not publicly shown anywhere. > > 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 > -- ?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 From marinekelley at gmail.com Sun Feb 28 02:57:22 2010 From: marinekelley at gmail.com (Marine Kelley) Date: Sun, 28 Feb 2010 11:57:22 +0100 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4ebfc1101002280249o5d4fc9b8i8ea144c4dcb1a84f@mail.gmail.com> References: <20100228093019.83ba2eed.sldev@free.fr> <201002281006.43982.Lance.Corrimal@eregion.de> <4ebfc1101002280249o5d4fc9b8i8ea144c4dcb1a84f@mail.gmail.com> Message-ID: <9e52a8c11002280257x49bcb6eeg7bf8ec86b14bbb6e@mail.gmail.com> Some people have no problem with showing their private fetishes to the world, other people like me do. I have a family, a job, and friends. I have plenty things to hide, my private life is nobody's business, and anybody who attempts to pry it open will only meet hostility. On 28 February 2010 11:49, Gareth Nelson wrote: > For myself, I'd happily give my real name and an email address - but > not a postal address for public access. Anyone who would consider > doing that is lucky to never have had a stalker (trust me, it's not > pleasant). > > If the reason for requiring this information is "in case we need to > sue you" then it's in no developer's interests to give it. An email > address is fine for contact info, and a real name is unneeded, but > shouldn't be a massive concern - personally I only use a secret alias > online if i'm trying to hide. > > People have mentioned "kinky stuff" in SL as being a reason to hide - > well, i'm perfectly happy to show everyone videos and screenshots of > myself in a sex club just to prove i'm serious about "nothing to > hide". Hopefully that means you can also trust me not to put nasty > trojans in my code. Of course whether you'll ever use my code is > dependent on contacting me directly these days - no way am I signing > the contributor agreement to get patches into the main viewer. > > On Sun, Feb 28, 2010 at 9:06 AM, Lance Corrimal > wrote: > > Am Sonntag 28 Februar 2010 schrieb Henri Beauchamp: > > > >> > I know the identity requirement will remain, and I expect there > >> > will be a form that's more explicit about what information is > >> > required, if there isn't already. > >> > >> For now, email and full snail mail address are required in addition > >> to the real name. > >> > >> > If you know of any law that makes it illegal to require email as > >> > a condition of being listed in an optional directory, it would be > >> > helpful to tell me where to find it so I can pass it on to legal. > >> > >> Real name and (ISP hosted) email address are both OK and adequate > >> (they provide both a mean of communication and a mean of > >> identification, the latter in the case a legal action would be > >> taken by Linden Lab), the only thing which is not OK as the form > >> is right now (beside the mention that private info may be > >> published) is the snail mail address requirement (unneeded at all, > >> thus it shall not be a required info). > > > > > > Right now I'm working on porting henri's cool patches to snowglobe. > > As it stands now, I'm not going to put it into the viewer directory, > > unless the requirements for any other data than my SL name and a > > valid, working email address are taken down. Real name is only > > acceptable if not publicly shown anywhere. > > > > 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 > > > > > > -- > ?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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100228/e5faf03e/attachment.htm From imaze.rhiano at gmail.com Sun Feb 28 03:37:10 2010 From: imaze.rhiano at gmail.com (Imaze Rhiano) Date: Sun, 28 Feb 2010 13:37:10 +0200 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <9e52a8c11002280034j23453996x6429cd7b3707664b@mail.gmail.com> References: <20100227103231.22d26e14.sldev@free.fr> <9e52a8c11002270327n54bc13b5h21cafd041bb5d7f1@mail.gmail.com> <9e52a8c11002280034j23453996x6429cd7b3707664b@mail.gmail.com> Message-ID: <4B8A5566.8030202@gmail.com> 28.2.2010 10:34, Marine Kelley kirjoitti: > I'd like to remind people of my proposed solution, back when LL asked > everyone about how to set their third party viewer policy, a few > months ago. I had proposed to make it so that only viewers built on a > LL-owned dedicated machine would be accepted. Such binaries would be > the result of the build of committed sources, with the addition of a > small code (unknown to the devs of the viewer) that would transfer a > hash to the grid upon connecting (and possibly regularly afterward > while online). The binaries would be hosted on LL's website, along > with the sources, and everyone would have been able to consult the > sources while being sure there would not be any difference between > these sources and the resulting binaries (with the exception of the > code I mentioned). Granted, this is an expensive solution, and > potentially difficult while testing (there has to be some temporary > code for that purpose, for instance a code that allows only 4 or 5 > viewers using it at the same time), but the only solution that > formally guarantees that Build = Source, and that the source can be > reviewed, instead of testing every viewer, which takes much longer. > This approach wouldn't work - and LL's third party viewer policy is not going to work either. There is nothing to stop skillful coder to decode this "secret hashing component", skillful hacker to write proxy that will do it's ebil things between client and server or skillful user to install one certain program that allows to access OpenGL information and gather necessary information. Moving security/DRM to client side - is not going to work. Big companies like EA have tried this approach through rootkits and such - result: total absolute failure and huge loss of PR (just google "DRM spore"). Microsoft tried to support different DRM schemas with their multimedia player - result: player that is very slow to start, media format that requires internet access, works on single computer and complex encryption/verification/obfuscation schemas. Intel and media companies introduced HDCP - result: honest customers required to upgrade their working hardware and pirates who are still releasing movies to net before their official release day without annoying "you wouldn't steal car ads" and unskippable ads (http://www.makeuseof.com/tech-fun/wp-content/uploads/2010/02/pirateddvd1.png). Next year, 28 February 2011 - assuming world doesn't end and everything is following my grand plan, 1) Nyx Linden still doesn't have bear, 2) you still need to fake bake specular lighting for latex clothes, 3) content creators are going to whine how their content was copybotted and "LL doesn't do enough to stop copybotters" and 4) there are fewer SL compatible open source viewer developers and more non-SL compatible viewer developers IMHO: Instead of wasting valuable bytes to lawyers (don't feed lawyers they are just getting bigger and more hungry) and trying to move security/DRM to client's responsibility LL should do following: 1) Organize "build Nyx's bear competition", 2) add support for clothing materials and custom avatar meshes that finally allow proper latex clothing, 3) create paranoid a server that is not hopelessly fallen love with the client and verifies client's requests and actions, 4) streamline process for posting copyright notices (it should be two click process), 5) allow content creators to post additional proof that they are creators of content (to avoid constant copyright griefing attacks), - higher resolution textures - non-watermarked textures - high polycount models - etc. 6) improve assets server so that it allows better track who uploaded/created asset, when and who are using it so that all copybotted material are instantly deleted from the server and avatars who are distributing it are banned, 7) change from passive - waiting for copyright notice - mode - to active mode, where you are actively seeking copyright violations through automatic processes and perhaps allowing other users to tip possible copyright violations, 8) make process more transparent - allow creators see inside process, give them feedback 9) make process more visible - publish reports how many you have banned, write random blogs about topic and offer rewards from copyright tips Ultimately you could someday render scene in server - and thus avoid situation where you need to transfer assets of textures and objects to client, but I guess there no users currently who are ready to pay from high cost hardware, software and bandwidth that would be needed for server side rendering. I think that third party viewer policy is great ethical guide for second life compatible viewer developers and directory gives good listing to respectable viewers and correct download addresses. But otherwise it is completely waste of time and money, going to drive some developers away from second life, gives users and builders false feeling of security, and good toilet paper, if printed to soft recyclable paper. From sllists at boroon.dasgupta.ch Sun Feb 28 03:51:42 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 28 Feb 2010 12:51:42 +0100 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <4B8A58CE.4060709@boroon.dasgupta.ch> Soft Linden schrieb: > As someone else pointed out in this thread, you're able to host your > content outside of Second Life if you want to ensure people are able > to import it again. So, if the content is licensed under any "copyleft" license (popular ones are GPL and the share-alike variants of Creative Commons), anyone distributing derivative works would be required to also host that outside of Second Life? While requiring this from the original creator of the Second Life content *might* seem reasonable (as they have either chosen the license in question themselves or have decided to use pre-existing content that requires them to license their work like that), also requiring this from residents who build upon this is unreasonable and IMHO severely against the original spirit of Second Life. > You're not restricted to using Second Life for > content distribution, and with an external site you can present your > full license, not just half a byte's worth of permission data. It's been common and accepted practice to include distribution rules that go beyond what's expressible with SL's permission systems in Notecards in the content or packaged together with it or, for modifiable scripts, in script comments. If it has to be client-enforceable (and thus machine-readable), it's not like SVC-701 and related requests are particularly new. Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100228/95d5c50c/attachment.htm From secret.argent at gmail.com Sun Feb 28 07:04:52 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 28 Feb 2010 09:04:52 -0600 Subject: [opensource-dev] TPV & opensim & physics prediction In-Reply-To: <4B86E7D6.2000303@gmail.com> References: <4B86CA04.3030501@gmail.com> <4B86E03B.1090901@gmail.com> <20100225203234.GA8991@caliban.tmnwh.net> <4B86E7D6.2000303@gmail.com> Message-ID: <5C386937-FF1A-4C05-B8AE-8211EAA5CE63@gmail.com> On 2010-02-25, at 15:12, Dzonatas Sol wrote: > [Usenet] worked. It is still free and open. It used to be. It's getting harder and harder to get feeds these days. Everyone just reads through Google Groups rather than trying to find someone with a feed. SL and OpenSim started with the equivalent of "Google Groups" already live. It wasn't even vaguely real-time. It was *OK* that the stanford- munnari link was a daily airmailed magtape, nobody cared if their newsfeed was a day behind. From missannotoole at yahoo.com Sun Feb 28 07:45:51 2010 From: missannotoole at yahoo.com (Ann Otoole) Date: Sun, 28 Feb 2010 07:45:51 -0800 (PST) Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <325879.47076.qm@web59102.mail.re1.yahoo.com> OK I have read this and in plain English it is pretty clear. So I expect Linden Lab will be terminating the ability to save full permissions textures to disk unless the person saving them uploaded them right? And since Linden Lab's viewer cannot determine license state of builds in view then Linden Lab will be removing snapshot capabilities and informing residents they are not allowed to view content unless they own the region and all content in view right? No machinima nothing. After all if it can be seen it can be "illegally screenshot". Or are these restrictions only applicable to third party viewers for the purpose of rendering them useless? ________________________________ From: Soft Linden To: Morgaine Cc: opensource-dev at lists.secondlife.com Sent: Sat, February 27, 2010 8:31:40 PM Subject: Re: [opensource-dev] FAQ posted for Third Party Viewer Policy On Sat, Feb 27, 2010 at 12:47 AM, Morgaine wrote: > ... > And finally, FAQ.15 (in the context of licenses permitting free > distribution): > > Q15: Do the limitations of section 2.b on content export apply to content > that is full permissions? > A15: Yes, they do. Residents retain intellectual property rights in the > content they create in Second Life and it is important for you to respect > those rights. By setting content to "full permissions" using the Second > Life permissions system, a content creator merely indicates that the content > may be copied, modified, and transferred within Second Life. Setting > content to "full permissions" does not provide any permission to use the > content outside of Second Life. > > This is fine (surprise, surprise :P), but incomplete. It doesn't address > the quite common scenario of full-perm content created by Open Source or > Creative Commons developers using 100% personal textures, and accompanied by > a GPL, BSD, CC or other open source license which declares that the content > may be freely copied, modified, and transferred anywhere, not only within > Second Life. > > As is written in the answer A15, "Residents retain intellectual property > rights in the content they create in Second Life and it is important for you > to respect those rights." Respecting their rights in this case requires you > to to allow that content to be exported as its creator desires. Therefore > you either need to extend A15 with this additional case, or add another FAQ > Q+A (preferably immediately after #15) to address it. That might be material for the FAQ. But because there is no export permission bit, it's not possible to add export capability for these cases without enabling violation of others' content. At this point, I couldn't see that affecting the TPV policy. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100228/c314dda0/attachment-0001.htm From morgaine.dinova at googlemail.com Sun Feb 28 07:55:43 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Sun, 28 Feb 2010 15:55:43 +0000 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: On Sun, Feb 28, 2010 at 1:31 AM, Soft Linden wrote: > > It's important to understand that one can discontinue use of Second > Life at any point. On doing so, there are no further obligations > imposed by the TPV policy. The legal consults cleared this as a > resolution to all free license issues. > It is not a resolution to all free license issues at all, not even close. They're just not reading the words of the license. GPLv2 clause 6 allows no "further restrictions" to be placed on the freedom of developers to *"modify and distribute*" whatsoever, regardless of whether the USAGE of that GPL software is constrained or not. The GPL has no interest is how software is used to connect to a service in the slightest. You can constrain USAGE of code for service access as much as you like, you can ban whomever or whatever you like, and it's completely immaterial to the GPL. The two things are entirely separate. The GPL is not a usage license. Such *usage* concerns are concerns for the *user* alone --- when a developer connects to SL then she is no longer a developer at that point, but has the role of a user. If you place constraints, requirements or restrictions on the DEVELOPER, such as a requirement for registration, self-identification or code modification at your command, then you are adding "further restrictions" to the developer's freedom to "modify and distribute" and hence you are automatically GPL non-complaint. This is unambiguous in the GPL. Make them read it again. Make them read the GPLv2 FAQ too. Restrictions on connection are perfectly acceptable! But that's not what you're doing, because your clauses directly target developers, not merely permitted usage. "A viewer may not do XYZ when it connects to the SL service" is totally fine --- the GPL couldn't care less. "A developer of this GPL code must do ABC if it is distributed" is not fine --- it's in direct conflict with the GPL's "modify and distribute" freedoms. > This agreement makes no restrictions on what anyone can do with the > source. The GPL makes no restrictions on connecting to Second Life. > These are two separate agreements, and don't need to be reconciled in > such a way that each permits everything allowed by the other. > That would be an excellent position to take, but you are not taking it. You persist in laying requirements on DEVELOPERS, in direct non-compliance with GPLv2 clause 6. And you keep mentioning "developers" when you mean "users", in reference to connection to your service. Your warning that developers who distribute their modified viewers will have to register with you is an utterly massive additional restriction on the freedom to modify and distribute that is at the heart of the GPL (all versions), as are requirements for self-identification and program modification at your request. The GPLv2 FAQ that I linked earlier gives an example of such an "additional restriction" being non-compliant, despite being a tiny restriction compared to any of yours. I think your lawyers must have little experience with the GPL, so I'm glad to hear that you're obtaining additional expert advice externally. I hope you're not going to Microsoft for that "expert advice on GPL". :P I recommend that you involve the FSF or the SFLC. This is something that you have to resolve, and it can't be resolved if you maintain your current position imposing restrictions on GPL developers. All that will happen is that your GPL non-compliance will escalate, until eventually it hits the top and you are forced to either drop the GPL or alter your restrictions to fall exclusively on users, not on GPL developers. > That said, Linden Lab intends to keep the viewer platform under an > open source license. If anyone ever received a request to alter the > viewer in a way that would violate the GPL, point that out. Odds are > the request isn't being communicated properly, or somebody didn't know > of the implications. Again though - any request is just that. A change > isn't required if the viewer author chooses to instead stop using it > to connect to the service and withdraws it from the Viewer Directory. > You're still mixing up restrictions on usage with restrictions on developers. To not fall foul of this, you really need to separate the issue into two categories: 1. Restrictions on development and distribution: none, as per the GPLv2. 2. Restrictions on connection to SL and usage of SL: anything you like. You cannot impose any *further restrictions* on GPL developers *at all*. From bogus@does.not.exist.com Fri Feb 5 05:04:03 2010 From: bogus@does.not.exist.com () Date: Fri, 05 Feb 2010 13:04:03 -0000 Subject: No subject Message-ID: - *6.* Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. *You may not impose any further restrictions on the recipients' exercise of the rights granted herein.* You are not responsible for enforcing compliance by third parties to this License. Clause 6 is not at all hard to understand, so it rather looks like your lawyers are trying desperately hard to ignore the words and intentions of the GPL license. Make them read the GPLv2 FAQ, it provides a clear example of not being allowed to impose further restrictions on developers beyond those stated in the GPL. That clause is central to preserving the developer's freedoms under the GPL. The reason why the GPL has this very clear clause is to preserve the unfettered operation of the development chain: modify-distribute, next person takes, modify-distribute, next person takes, modify-distribute, .... etc. Without this, everyone in the chain would be subject to the initial creator's usage restrictions, whether or not they actually use the program. Distro developers would not be able to fix security holes and then distribute the fixed versions. Nobody would be able to take the sources, adapt them to other uses and distribute them, for the same reason. The whole GPL ecosystem would stop working through originator-imposed restrictions on developers. This is why clause 6 is so strongly worded. You may not impose further restrictions on the developers of a GPL-license program if you want to continue using the GPL. > Next, FAQ.12: > > Q12: I develop for a Linux distribution where there is no opportunity to > present users with the disclosures required under section 1.c before the > user downloads and installs the software. How can I comply with section 1.c > of the policy? > A12: For Linux distributions where there is no opportunity to provide the > section 1.c disclosures before installation of the software, you can comply > with the requirement by having your software client present the required > disclosures or a link to them in a dialogue box that the user must close > before logging into Second Life for the first time through your software. > > You can't require that of developers of GPL software. It's a restriction on > a GPL developer's "freedom to modify and distribute", and is explicitly > prohibited in GPLv2 clause 6. Please check the GPLv2 FAQ for the example of > the original BSD advertising clause, which was incompatible with the GPL. > That advertising clause had to be removed from GPL programs before they > could be licensed using GPL, because it was an additional restriction on the > freedom to modify and distribute. Anyone can make a derivative viewer that doesn't comply with the > policy. That version of the viewer would not be eligible for inclusion > in the Viewer Directory. The situation here is similar. Nothing is > prohibited in terms of use of the GPL licensed code. The restriction > is strictly placed on participation in the Viewer Directory. > Your FAQ.4 gives clear warning that participation in the Viewer Directory "may" become a requirement for being allowed to distribute modified sources --- you would not have said that if it wasn't desired by you and hence planned. That is the first "further requirement" that conflicts with GPLv2 clause 6, and then your requirement that developers divulge personal details and modify their programs at your command are two more. As the GPLv2 FAQ shows explicitly, clause 6 doesn't even permit an advertising requirement, which is a comparatively minor "further restriction". You in contrast are going to require full-blown registration, personal identification, program modification, and so on --- that's WAAAAAAY beyond what the GPLv2 FAQ makes clear is GPL non-compliant. It's so far beyond what the GPL allows that it's funny. ;-) I think the problem stems from your advisers' inability to separate the freedom to modify and distribute the GPL viewer code (which is a right guaranteed by the GPL), from your unstated "Functional requirements on viewers that connect to Second Life". The latter is a constraint on code, and it does not have to be phrased as a restriction on GPL developers, yet you conflate the two things, and that causes the trouble. > And finally, FAQ.15 (in the context of licenses permitting free > distribution): > > Q15: Do the limitations of section 2.b on content export apply to content > that is full permissions? > A15: Yes, they do. Residents retain intellectual property rights in the > content they create in Second Life and it is important for you to respect > those rights. By setting content to "full permissions" using the Second > Life permissions system, a content creator merely indicates that the content > may be copied, modified, and transferred within Second Life. Setting > content to "full permissions" does not provide any permission to use the > content outside of Second Life. > > This is fine (surprise, surprise :P), but incomplete. It doesn't address > the quite common scenario of full-perm content created by Open Source or > Creative Commons developers using 100% personal textures, and accompanied by > a GPL, BSD, CC or other open source license which declares that the content > may be freely copied, modified, and transferred anywhere, not only within > Second Life. > > As is written in the answer A15, "Residents retain intellectual property > rights in the content they create in Second Life and it is important for you > to respect those rights." Respecting their rights in this case requires you > to to allow that content to be exported as its creator desires. Therefore > you either need to extend A15 with this additional case, or add another FAQ > Q+A (preferably immediately after #15) to address it. That might be material for the FAQ. But because there is no export > permission bit, it's not possible to add export capability for these > cases without enabling violation of others' content. At this point, I > couldn't see that affecting the TPV policy. > An export permission bit is not required before export of open-licensed content can be done. We don't have an export permission bit in RL, and yet open licensing works just fine. As Fleep pointed out earlier, SL creators are already open-licensing their products right now, since it is so important for Education. As in RL, the responsibility for applying open licenses properly rests with the licensor, since nobody else can be expected to check what the licensor is licensing. That is no different here. Nobody expects you to do any checking, and your assertion that this leads to "violation of others' content" is patently wrong when the licensor uses only her own and other people's open-licensed content. The core of the matter though is whether you believe in your own words in FAQ.15: "Residents retain intellectual property rights in the content they create in Second Life and it is important for you to respect those rights". Are you going to respect the rights of those creators who use open-licensing of their content? Or are you only going to respect the rights of those creators who shore up the walls of your walled garden? I would prefer to believe that your support is for all content creators' rights and wishes. How you respond will reveal the truth of the matter. If you make it clear that building upon the openly and legally-licensed content of others is a ToS or TPV violation, then you are not respecting the rights and wishes of open creators. My suggested new FAQ.16 or similar would let you "do the right thing" and be a good citizen of the open license community. Morgaine. ======================================= On Sun, Feb 28, 2010 at 1:31 AM, Soft Linden wrote: > On Sat, Feb 27, 2010 at 12:47 AM, Morgaine > wrote: > > > > Q2: Does the policy limit use of the viewer source code that Linden Lab > > makes available under the GPL? > > A2: No, the policy is not intended to and does not place any restriction > on > > modification or use of our viewer source code that we make available > under > > the GPL. 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. > > > > This looks great at first glance as it appears to make the separation > > between developers and users that caused so much confusion in TPV v1. > > > > But notice that the answer says "does not place any restriction on > > modification or use", and then goes on to say "Rather, the policy sets > out > > requirements for connecting". Well connecting IS use, it couldn't be > > anything else, so the answer contradicts itself in one and the same > > paragraph. Such ambiguities need to be removed. > > It's important to understand that one can discontinue use of Second > Life at any point. On doing so, there are no further obligations > imposed by the TPV policy. The legal consults cleared this as a > resolution to all free license issues. > > This agreement makes no restrictions on what anyone can do with the > source. The GPL makes no restrictions on connecting to Second Life. > These are two separate agreements, and don't need to be reconciled in > such a way that each permits everything allowed by the other. > > That said, Linden Lab intends to keep the viewer platform under an > open source license. If anyone ever received a request to alter the > viewer in a way that would violate the GPL, point that out. Odds are > the request isn't being communicated properly, or somebody didn't know > of the implications. Again though - any request is just that. A change > isn't required if the viewer author chooses to instead stop using it > to connect to the service and withdraws it from the Viewer Directory. > > > > Next, FAQ.12: > > > > Q12: I develop for a Linux distribution where there is no opportunity to > > present users with the disclosures required under section 1.c before the > > user downloads and installs the software. How can I comply with section > 1.c > > of the policy? > > A12: For Linux distributions where there is no opportunity to provide the > > section 1.c disclosures before installation of the software, you can > comply > > with the requirement by having your software client present the required > > disclosures or a link to them in a dialogue box that the user must close > > before logging into Second Life for the first time through your software. > > > > You can't require that of developers of GPL software. It's a restriction > on > > a GPL developer's "freedom to modify and distribute", and is explicitly > > prohibited in GPLv2 clause 6. Please check the GPLv2 FAQ for the example > of > > the original BSD advertising clause, which was incompatible with the GPL. > > That advertising clause had to be removed from GPL programs before they > > could be licensed using GPL, because it was an additional restriction on > the > > freedom to modify and distribute. > > Anyone can make a derivative viewer that doesn't comply with the > policy. That version of the viewer would not be eligible for inclusion > in the Viewer Directory. The situation here is similar. Nothing is > prohibited in terms of use of the GPL licensed code. The restriction > is strictly placed on participation in the Viewer Directory. > > > > And finally, FAQ.15 (in the context of licenses permitting free > > distribution): > > > > Q15: Do the limitations of section 2.b on content export apply to content > > that is full permissions? > > A15: Yes, they do. Residents retain intellectual property rights in the > > content they create in Second Life and it is important for you to respect > > those rights. By setting content to "full permissions" using the Second > > Life permissions system, a content creator merely indicates that the > content > > may be copied, modified, and transferred within Second Life. Setting > > content to "full permissions" does not provide any permission to use the > > content outside of Second Life. > > > > This is fine (surprise, surprise :P), but incomplete. It doesn't address > > the quite common scenario of full-perm content created by Open Source or > > Creative Commons developers using 100% personal textures, and accompanied > by > > a GPL, BSD, CC or other open source license which declares that the > content > > may be freely copied, modified, and transferred anywhere, not only within > > Second Life. > > > > As is written in the answer A15, "Residents retain intellectual property > > rights in the content they create in Second Life and it is important for > you > > to respect those rights." Respecting their rights in this case requires > you > > to to allow that content to be exported as its creator desires. > Therefore > > you either need to extend A15 with this additional case, or add another > FAQ > > Q+A (preferably immediately after #15) to address it. > > That might be material for the FAQ. But because there is no export > permission bit, it's not possible to add export capability for these > cases without enabling violation of others' content. At this point, I > couldn't see that affecting the TPV policy. > --0016e6d96d2846fc990480ab2a5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Feb 28, 2010 at 1:31 AM, Soft Linden <= soft at lindenlab.com> wrote:

It's important to understand that one can discontinue use of Seco= nd
Life at any point. On doing so, there are no further obligations
imposed by the TPV policy. The legal consults cleared this as a
resolution to all free license issues.


It is n= ot a resolution to all free license issues at all, not even close.=A0 They&= #39;re just not reading the words of the license.

GPLv2 clause 6 all= ows no "further restrictions" to be placed on the freedom of deve= lopers to "modify and distribute" whatsoever, regardless o= f whether the USAGE of that GPL software is constrained or not.=A0 The GPL = has no interest is how software is used to connect to a service in the slig= htest.=A0 You can constrain USAGE of code for service access as much as you= like, you can ban whomever or whatever you like, and it's completely i= mmaterial to the GPL.=A0 The two things are entirely separate.=A0 The GPL i= s not a usage license.

Such usage concerns are concerns for the user alone --- when a developer connects to SL then she is no longer a develo= per at that point, but has the role of a user.=A0 If you place constraints,= requirements or restrictions on the DEVELOPER, such as a requirement for r= egistration, self-identification or code modification at your command, then= you are adding "further restrictions" to the developer's fre= edom to "modify and distribute" and hence you are automatically G= PL non-complaint.

This is unambiguous in the GPL.=A0 Make them read it again.=A0 Make the= m read the GPLv2 FAQ too.
=A0
Restrictions on connection are perfectl= y acceptable!=A0 But that's not what you're doing, because your cla= uses directly target developers, not merely permitted usage.=A0 "A vie= wer may not do XYZ when it connects to the SL service" is totally fine= --- the GPL couldn't care less.=A0 "A developer of this GPL code = must do ABC if it is distributed" is not fine --- it's in direct c= onflict with the GPL's "modify and distribute" freedoms.



This agreement makes no restrictions on what anyone can do with the
source. The GPL makes no restrictions on connecting to Second Life.
These are two separate agreements, and don't need to be reconciled in such a way that each permits everything allowed by the other.


That would be an excellent position to take, but you are no= t taking it.=A0 You persist in laying requirements on DEVELOPERS, in direct= non-compliance with GPLv2 clause 6.=A0 And you keep mentioning "devel= opers" when you mean "users", in reference to connection to = your service.=A0 Your warning that developers who distribute their modified= viewers will have to register with you is an utterly massive additional re= striction on the freedom to modify and distribute that is at the heart of t= he GPL (all versions), as are requirements for self-identification and prog= ram modification at your request.=A0 The GPLv2 FAQ that I linked earlier gi= ves an example of such an "additional restriction" being non-comp= liant, despite being a tiny restriction compared to any of yours.

I think your lawyers must have little experience with the GPL, so I'= ;m glad to hear that you're obtaining additional expert advice external= ly.=A0 I hope you're not going to Microsoft for that "expert advic= e on GPL". :P=A0 I recommend that you involve the FSF or the SFLC.
=A0
This is something that you have to resolve, and it can't be reso= lved if you maintain your current position imposing restrictions on GPL dev= elopers.=A0 All that will happen is that your GPL non-compliance will escal= ate, until eventually it hits the top and you are forced to either drop the= GPL or alter your restrictions to fall exclusively on users, not on GPL de= velopers.


That said, Linden Lab intends to keep the viewer platform under an
open source license. If anyone ever received a request to alter the
viewer in a way that would violate the GPL, point that out. Odds are
the request isn't being communicated properly, or somebody didn't k= now
of the implications. Again though - any request is just that. A change
isn't required if the viewer author chooses to instead stop using it to connect to the service and withdraws it from the Viewer Directory.


You're still mixing up restrictions on usage wi= th restrictions on developers.=A0 To not fall foul of this, you really need= to separate the issue into two categories:
  1. Restrictions on development and distribution:=A0 none, as per the G= PLv2.
  2. Restrictions on connection to SL and usage of SL:=A0 anything= you like.

You cannot impose any further restrictions on GPL developers at all.=A0 From GPLv2:

  • 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein.<= /b> You are not responsible for enforcing compliance by third parties to this License.

Clause 6 is not at all hard to understand, so it rather looks= like your lawyers are trying desperately hard to ignore the words and inte= ntions of the GPL license.=A0 Make them read the GPLv2 FAQ, it provides a c= lear example of not being allowed to impose further restrictions on develop= ers beyond those stated in the GPL.=A0 That clause is central to preserving= the developer's freedoms under the GPL.

The reason why the GPL has this very clear clause is to preserve the un= fettered operation of the development chain:=A0 modify-distribute, next per= son takes, modify-distribute, next person takes, modify-distribute, .... et= c.=A0 Without this, everyone in the chain would be subject to the initial c= reator's usage restrictions, whether or not they actually use the progr= am.=A0 Distro developers would not be able to fix security holes and then d= istribute the fixed versions.=A0 Nobody would be able to take the sources, = adapt them to other uses and distribute them, for the same reason.=A0 The w= hole GPL ecosystem would stop working through originator-imposed restrictio= ns on developers.

This is why clause 6 is so strongly worded.=A0 You may not impose furth= er restrictions on the developers of a GPL-license program if you want to c= ontinue using the GPL.



> Next, FAQ.12:
>
> Q12:=A0 I develop for a Linux distribution where there is no opportuni= ty to
> present users with the disclosures required under section 1.c before t= he
> user downloads and installs the software. =A0How can I comply with sec= tion 1.c
> of the policy?
> A12: For Linux distributions where there is no opportunity to provide = the
> section 1.c disclosures before installation of the software, you can c= omply
> with the requirement by having your software client present the requir= ed
> disclosures or a link to them in a dialogue box that the user must clo= se
> before logging into Second Life for the first time through your softwa= re.
>
> You can't require that of developers of GPL software.=A0 It's = a restriction on
> a GPL developer's "freedom to modify and distribute", an= d is explicitly
> prohibited in GPLv2 clause 6.=A0 Please check the GPLv2 FAQ for the ex= ample of
> the original BSD advertising clause, which was incompatible with the G= PL.
> That advertising clause had to be removed from GPL programs before the= y
> could be licensed using GPL, because it was an additional restriction = on the
> freedom to modify and distribute.

Anyone can make a derivative viewer that doesn't comply with the
policy. That version of the viewer would not be eligible for inclusion
in the Viewer Directory. The situation here is similar. Nothing is
prohibited in terms of use of the GPL licensed code. The restriction
is strictly placed on participation in the Viewer Directory.


Your FAQ.4 gives clear warning that participation in the Vie= wer Directory "may" become a requirement for being allowed to dis= tribute modified sources --- you would not have said that if it wasn't = desired by you and hence planned.=A0 That is the first "further requir= ement" that conflicts with GPLv2 clause 6, and then your requirement t= hat developers divulge personal details and modify their programs at your c= ommand are two more.

As the GPLv2 FAQ shows explicitly, clause 6 doesn't even permit an = advertising requirement, which is a comparatively minor "further restr= iction".=A0 You in contrast are going to require full-blown registrati= on, personal identification, program modification, and so on --- that's= WAAAAAAY beyond what the GPLv2 FAQ makes clear is GPL non-compliant.=A0 It= 's so far beyond what the GPL allows that it's funny. ;-)

I think the problem stems from your advisers' inability to separate= the freedom to modify and distribute the GPL viewer code (which is a right= guaranteed by the GPL), from your unstated "Functional requirements o= n viewers that connect to Second Life".=A0 The latter is a constraint = on code, and it does not have to be phrased as a restriction on GPL develop= ers, yet you conflate the two things, and that causes the trouble.



> And finally, FAQ.15 (in the context of licenses permitting free
> distribution):
>
> Q15: Do the limitations of section 2.b on content export apply to cont= ent
> that is full permissions?
> A15: Yes, they do.=A0 Residents retain intellectual property rights in= the
> content they create in Second Life and it is important for you to resp= ect
> those rights.=A0 By setting content to "full permissions" us= ing the Second
> Life permissions system, a content creator merely indicates that the c= ontent
> may be copied, modified, and transferred within Second Life. =A0Settin= g
> content to "full permissions" does not provide any permissio= n to use the
> content outside of Second Life.
>
> This is fine (surprise, surprise :P), but incomplete.=A0 It doesn'= t address
> the quite common scenario of full-perm content created by Open Source = or
> Creative Commons developers using 100% personal textures, and accompan= ied by
> a GPL, BSD, CC or other open source license which declares that the co= ntent
> may be freely=A0copied, modified, and transferred anywhere, not only w= ithin
> Second Life.
>
> As is written in the answer A15, "Residents retain intellectual p= roperty
> rights in the content they create in Second Life and it is important f= or you
> to respect those rights."=A0 Respecting their rights in this case= requires you
> to to allow that content to be exported as its creator desires.=A0 The= refore
> you either need to extend A15 with this additional case, or add anothe= r FAQ
> Q+A (preferably immediately after #15) to address it.

That might be material for the FAQ. But because there is no export
permission bit, it's not possible to add export capability for these cases without enabling violation of others' content. At this point, I couldn't see that affecting the TPV policy.


An export permission bit is not required before = export of open-licensed content can be done.=A0 We don't have an export= permission bit in RL, and yet open licensing works just fine.=A0 As Fleep = pointed out earlier, SL creators are already open-lice= nsing their products right now, since it is so important for Education.

As in RL, the responsibility for applying open licenses properly rests = with the licensor, since nobody else can be expected to check what the lice= nsor is licensing.=A0 That is no different here.=A0 Nobody expects you to d= o any checking, and your assertion that this leads to "violation of ot= hers' content" is patently wrong when the licensor uses only her o= wn and other people's open-licensed content.

The core of the matter though is whether you believe in your own words = in FAQ.15: "Residents retain intellectual property rights in the conte= nt they create in Second Life and it is important for you to respect those = rights".=A0 Are you going to respect the rights of those creators who = use open-licensing of their content?

Or are you only going to respect the rights of those creators who shore= up the walls of your walled garden?=A0 I would prefer to believe that your= support is for all content creators' rights and wishes.

How you= respond will reveal the truth of the matter.=A0 If you make it clear that = building upon the openly and legally-licensed content of others is a ToS or= TPV violation, then you are not respecting the rights and wishes of open c= reators.=A0 My suggested new FAQ.16 or similar would let you "do the r= ight thing" and be a good citizen of the open license community.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

On Sun, Feb 28, 2010 at 1:31= AM, Soft Linden <soft at lindenlab.com> wrote:
On Sat, Feb 27, 2= 010 at 12:47 AM, Morgaine
> Q2: Does the policy limit use of the viewer source code tha= t Linden Lab
> makes available under the GPL?
> A2: No, the policy is not intended to and does not place any restricti= on on
> modification or use of our viewer source code that we make available u= nder
> the GPL. =A0Rather, the policy sets out requirements for connecting to= our
> Second Life service using a third-party viewer, regardless of the view= er
> source code used.
>
> This looks great at first glance as it appears to make the separation<= br> > between developers and users that caused so much confusion in TPV v1.<= br> >
> But notice that the answer says "does not place any restriction o= n
> modification or use", and then goes on to say "Rather, the p= olicy sets out
> requirements for connecting".=A0 Well connecting IS use, it could= n't be
> anything else, so the answer contradicts itself in one and the same > paragraph. Such ambiguities need to be removed.

It's important to understand that one can discontinue use of Seco= nd
Life at any point. On doing so, there are no further obligations
imposed by the TPV policy. The legal consults cleared this as a
resolution to all free license issues.

This agreement makes no restrictions on what anyone can do with the
source. The GPL makes no restrictions on connecting to Second Life.
These are two separate agreements, and don't need to be reconciled in such a way that each permits everything allowed by the other.

That said, Linden Lab intends to keep the viewer platform under an
open source license. If anyone ever received a request to alter the
viewer in a way that would violate the GPL, point that out. Odds are
the request isn't being communicated properly, or somebody didn't k= now
of the implications. Again though - any request is just that. A change
isn't required if the viewer author chooses to instead stop using it to connect to the service and withdraws it from the Viewer Directory.


> Next, FAQ.12:
>
> Q12:=A0 I develop for a Linux distribution where there is no opportuni= ty to
> present users with the disclosures required under section 1.c before t= he
> user downloads and installs the software. =A0How can I comply with sec= tion 1.c
> of the policy?
> A12: For Linux distributions where there is no opportunity to provide = the
> section 1.c disclosures before installation of the software, you can c= omply
> with the requirement by having your software client present the requir= ed
> disclosures or a link to them in a dialogue box that the user must clo= se
> before logging into Second Life for the first time through your softwa= re.
>
> You can't require that of developers of GPL software.=A0 It's = a restriction on
> a GPL developer's "freedom to modify and distribute", an= d is explicitly
> prohibited in GPLv2 clause 6.=A0 Please check the GPLv2 FAQ for the ex= ample of
> the original BSD advertising clause, which was incompatible with the G= PL.
> That advertising clause had to be removed from GPL programs before the= y
> could be licensed using GPL, because it was an additional restriction = on the
> freedom to modify and distribute.

Anyone can make a derivative viewer that doesn't comply with the<= br> policy. That version of the viewer would not be eligible for inclusion
in the Viewer Directory. The situation here is similar. Nothing is
prohibited in terms of use of the GPL licensed code. The restriction
is strictly placed on participation in the Viewer Directory.


> And finally, FAQ.15 (in the context of licenses permitting free
> distribution):
>
> Q15: Do the limitations of section 2.b on content export apply to cont= ent
> that is full permissions?
> A15: Yes, they do.=A0 Residents retain intellectual property rights in= the
> content they create in Second Life and it is important for you to resp= ect
> those rights.=A0 By setting content to "full permissions" us= ing the Second
> Life permissions system, a content creator merely indicates that the c= ontent
> may be copied, modified, and transferred within Second Life. =A0Settin= g
> content to "full permissions" does not provide any permissio= n to use the
> content outside of Second Life.
>
> This is fine (surprise, surprise :P), but incomplete.=A0 It doesn'= t address
> the quite common scenario of full-perm content created by Open Source = or
> Creative Commons developers using 100% personal textures, and accompan= ied by
> a GPL, BSD, CC or other open source license which declares that the co= ntent
> may be freely=A0copied, modified, and transferred anywhere, not only w= ithin
> Second Life.
>
> As is written in the answer A15, "Residents retain intellectual p= roperty
> rights in the content they create in Second Life and it is important f= or you
> to respect those rights."=A0 Respecting their rights in this case= requires you
> to to allow that content to be exported as its creator desires.=A0 The= refore
> you either need to extend A15 with this additional case, or add anothe= r FAQ
> Q+A (preferably immediately after #15) to address it.

That might be material for the FAQ. But because there is no export permission bit, it's not possible to add export capability for these cases without enabling violation of others' content. At this point, I couldn't see that affecting the TPV policy.

--0016e6d96d2846fc990480ab2a5a-- From rusyasoft at gmail.com Sun Feb 28 08:01:11 2010 From: rusyasoft at gmail.com (Rustam Rakhimov) Date: Mon, 1 Mar 2010 01:01:11 +0900 Subject: [opensource-dev] Is there free images in second life Message-ID: <7600b1331002280801j3d234081wf74cf618013d1d4c@mail.gmail.com> Is there free images in second life ? where I can take it. Please someone who has some image please send me, I need it for experiment. PLEASE name: rusyasoft rubanis Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100301/8b56fb3b/attachment.htm From secret.argent at gmail.com Sun Feb 28 08:08:09 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 28 Feb 2010 10:08:09 -0600 Subject: [opensource-dev] "Second-Party" viewer policy (was: Third party viewer policy) In-Reply-To: <3a164ef31002260327x2a4d0005o2286ddcc56ce502f@mail.gmail.com> References: <012E4081-AC93-43A9-89C2-65CAC87EFFCF@mac.com> <3a164ef31002260327x2a4d0005o2286ddcc56ce502f@mail.gmail.com> Message-ID: On 2010-02-26, at 05:27, David Simmons wrote: > The common sense rules apply. If you are not connecting to the LL > grid, Linden Lab can't make any policy regarding what you do. They > don't need a policy saying that they can't make a policy telling you > what to do on another grid. Is that a legal opinion? Words MEAN different things when lawyers are involved. From sllists at boroon.dasgupta.ch Sun Feb 28 08:19:39 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 28 Feb 2010 17:19:39 +0100 Subject: [opensource-dev] Is there free images in second life In-Reply-To: <7600b1331002280801j3d234081wf74cf618013d1d4c@mail.gmail.com> References: <7600b1331002280801j3d234081wf74cf618013d1d4c@mail.gmail.com> Message-ID: <4B8A979B.8080906@boroon.dasgupta.ch> Rustam Rakhimov schrieb: > Is there free images in second life ? > > where I can take it. 1. Open the inventory (Ctrl-i) 2. Go to * *Library* > *Photo Album* or * *Library* > *Textures* Or get Torley's free textures here . I hope this helps. cheers Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100228/bf818bb4/attachment.htm From secret.argent at gmail.com Sun Feb 28 08:22:47 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 28 Feb 2010 10:22:47 -0600 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: On 2010-02-27, at 20:24, Soft Linden wrote: > On Sat, Feb 27, 2010 at 10:32 AM, Fleep Tuque > wrote: >> >> The free content I create for education is intended to be fully >> free, fully >> permissioned, and fully exportable to other grids. Beyond the >> Second Life >> permissions, I keep hoping for checkboxes on the Edit menu with >> common >> licenses or a space to put a link to the user's specified license >> that is >> kept with the object info just like creator name. >> In any case, when I include Creative Commons licensing with my >> educational >> tools, and explicitly say users have my permission to explore the >> content to >> other grids, then I expect that to be respected by Linden Lab as >> well! > As someone else pointed out in this thread, you're able to host your > content outside of Second Life if you want to ensure people are able > to import it again. You're not restricted to using Second Life for > content distribution, and with an external site you can present your > full license, not just half a byte's worth of permission data. Regardless, http://jira.secondlife.com/browse/SVC-701 From maggie at matrisync.com Sun Feb 28 08:23:00 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Sun, 28 Feb 2010 11:23:00 -0500 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: It seems to me that this incessant desire to use software licencing and a "viewer whitelist" as a lever on downstream viewer developers is an attempt to reduce the costs of managing the behavior of Linden Research's customers. Obviously Linden Research management believes that doing this wholesale (by bullying developers into crippling functions in their code) rather than retail (detecting and responding to individual customer acts of ToS noncompliance) is a heck of a lot cheaper and easier. The problem with this strategy is that the GPL is specifically designed to prevent such bullying. It further seems clear to me that these policies were announced at the same time as the release of Viewer2 beta in order to distract attention from the power grab. Guess that didn't work as well as hoped. "An entirely sufficient case for open-source development rests on its engineering and economic outcomes?better quality, higher reliability, lower costs, and increased choice." --ESR, in "The Magic Cauldron". We should note that the first three benefits he cites are implicitly not available without the fourth, from which they arise. From gigstaggart at gmail.com Sun Feb 28 09:23:26 2010 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun, 28 Feb 2010 12:23:26 -0500 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <4B8AA68E.6010609@gmail.com> Soft Linden wrote: > It's important to understand that one can discontinue use of Second > Life at any point. On doing so, there are no further obligations > imposed by the TPV policy. The legal consults cleared this as a > resolution to all free license issues. Is that the case though? The policy claims to cover "viewers for logging into Second Life". It doesn't say anything about whether the developer themselves is logging into Second Life. It seems to me that you are still covered by this policy, including its requirements for making changes that LL requests, leaving out features, etc... if you just make an SL compatible viewer regardless of whether you use SL or not. > Anyone can make a derivative viewer that doesn't comply with the > policy. That version of the viewer would not be eligible for inclusion > in the Viewer Directory. The situation here is similar. Nothing is > prohibited in terms of use of the GPL licensed code. The restriction > is strictly placed on participation in the Viewer Directory. Well this is obviously not the case, most of the clauses apply whether you want into the viewer directory or not. From thomas.shikami at online.de Sun Feb 28 10:44:03 2010 From: thomas.shikami at online.de (Thomas Shikami) Date: Sun, 28 Feb 2010 19:44:03 +0100 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <4B8AB973.2020207@online.de> Morgaine schrieb: > GPLv2 clause 6 allows no "further restrictions" to be placed on the > freedom of developers to /"modify and distribute/" whatsoever, > regardless of whether the USAGE of that GPL software is constrained or > not. The GPL has no interest is how software is used to connect to a > service in the slightest. You can constrain USAGE of code for service > access as much as you like, you can ban whomever or whatever you like, > and it's completely immaterial to the GPL. The two things are > entirely separate. The GPL is not a usage license. > Long story short, if you want to be registered in the third party viewer registry, you have to follow the TPV policies. The registration is optional. If you don't register in the TPV, almost all rules that apply to the developer have no meaning. If you want to use your viewer with SL, you become a user of your viewer. Then the TOS and the TPV applies to you as it restricts the usage of a user. Registering with the viewer registry is voluntary and LL doesn't impose any "further restrictions" on you, because it isn't mandatory. Also you can redistribute the registered viewer according to GPLv2 without "further restrictions" on the receiver of that code. That party would have to register a derivate of that viewer as well to be restricted by the TPV as it applies on developer. If you don't use that viewer with SL, and you aren't registering the viewer, then nothing of the TPV applies to you. From morgaine.dinova at googlemail.com Sun Feb 28 10:59:20 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Sun, 28 Feb 2010 18:59:20 +0000 Subject: [opensource-dev] Mailman for opensource-dev on pipermail is slicing posts Message-ID: For the month of February, there are now 4 posts (from different people) that have been sliced into pieces and their headers-less tail fragments placed into the mailing list archive with a Subject line of "No subject". See the top of the threaded viewlisting. Could someone please request the mail sysadmins to take a look at this bug? Cheers, Morgaine. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100228/2b155993/attachment.htm From morgaine.dinova at googlemail.com Sun Feb 28 11:16:24 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Sun, 28 Feb 2010 19:16:24 +0000 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4B8AB973.2020207@online.de> References: <4B8AB973.2020207@online.de> Message-ID: You're talking commonsense, Thomas. Unfortunately, what's written down is not the commonsense interpretation that you are making of the words that are on paper. In a court of law, it is no defense to say "I was adhering to the commonsense interpretation provided by Thomas Shikami in the mailing list" (nor even quoting a Linden email). All that matters is what is written down in LL's official documents, and that is why we are taking great pains to get these words that Lindens are writing so sloppily into a suitable unambiguous form. They need to directly reflect what we all know is commonsense for user access to the SL service, and to be compliant with what is directly expressed in the GPLv2 license in respect of guaranteed developer freedoms. Our generous interpretations don't count here, only LL's official words do. And when making interpretations, you should always take the worst-case scenario, because that is what lawyers will use to hang you. Morgaine. =================================== On Sun, Feb 28, 2010 at 6:44 PM, Thomas Shikami wrote: > Morgaine schrieb: > > GPLv2 clause 6 allows no "further restrictions" to be placed on the > > freedom of developers to /"modify and distribute/" whatsoever, > > regardless of whether the USAGE of that GPL software is constrained or > > not. The GPL has no interest is how software is used to connect to a > > service in the slightest. You can constrain USAGE of code for service > > access as much as you like, you can ban whomever or whatever you like, > > and it's completely immaterial to the GPL. The two things are > > entirely separate. The GPL is not a usage license. > > > > Long story short, if you want to be registered in the third party viewer > registry, you have to follow the TPV policies. The registration is > optional. If you don't register in the TPV, almost all rules that apply > to the developer have no meaning. If you want to use your viewer with > SL, you become a user of your viewer. Then the TOS and the TPV applies > to you as it restricts the usage of a user. > > Registering with the viewer registry is voluntary and LL doesn't impose > any "further restrictions" on you, because it isn't mandatory. Also you > can redistribute the registered viewer according to GPLv2 without > "further restrictions" on the receiver of that code. That party would > have to register a derivate of that viewer as well to be restricted by > the TPV as it applies on developer. > > If you don't use that viewer with SL, and you aren't registering the > viewer, then nothing of the TPV applies to you. > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100228/31e653e8/attachment-0001.htm From gp1 at metafuturing.com Sun Feb 28 11:46:04 2010 From: gp1 at metafuturing.com (Giulio Prisco) Date: Sun, 28 Feb 2010 20:46:04 +0100 Subject: [opensource-dev] Fwd: Google Street View in Second Life In-Reply-To: <75e3d3b01002281137g6da67c25le15a13e65fa22f6f@mail.gmail.com> References: <75e3d3b01002281137g6da67c25le15a13e65fa22f6f@mail.gmail.com> Message-ID: <75e3d3b01002281146wc95f758r160f3e6262d92d48@mail.gmail.com> ---------- Forwarded message ---------- From: Giulio Prisco Date: Sun, Feb 28, 2010 at 8:37 PM Subject: Google Street View in Second Life To: "SL Educators (The SLED List)" , sldev at lists.secondlife.com Any idea on how to convert this very simple example into a working implementation of Street View in SL? Sounds doable. http://giulioprisco.blogspot.com/2010/02/google-street-view-in-second-life.html Google Street View in Second Life. A very preliminary experiment with Second Life Viewer 2.0. Watch this video on blip.tv where my Second Life avatar walks (well, sort of) in Street View's NYC. Perhaps with some clever coding we can implement Street View as a fully interactive multiuser metaverse within Second Life, by converting avatar movement (walk, rotate, look around) to clicks and drags on a surrounding Street View display. Sounds doable. -- Giulio Prisco gp at metafuturing.com (remove 1) http://metafuturing.com/ (39)3387219799 giulioprisco @ skype -- Giulio Prisco gp at metafuturing.com (remove 1) http://metafuturing.com/ (39)3387219799 giulioprisco @ skype From dzonatas at gmail.com Sun Feb 28 12:05:23 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Sun, 28 Feb 2010 12:05:23 -0800 Subject: [opensource-dev] TPV & opensim & physics prediction In-Reply-To: <5C386937-FF1A-4C05-B8AE-8211EAA5CE63@gmail.com> References: <4B86CA04.3030501@gmail.com> <4B86E03B.1090901@gmail.com> <20100225203234.GA8991@caliban.tmnwh.net> <4B86E7D6.2000303@gmail.com> <5C386937-FF1A-4C05-B8AE-8211EAA5CE63@gmail.com> Message-ID: <4B8ACC83.5030600@gmail.com> This is perfect then... If you are scheduled to meet in a sim later in the week, then why worry if all the static objects take a day to download from that sim through archaic usenet means. You would already have all the object information needed for physics and to render in a local storage. By the time everybody meets, there would be no lag to suddenly download all objects from a single host. Times that by 10,000 people... just for scalability concerns. Argent Stonecutter wrote: > On 2010-02-25, at 15:12, Dzonatas Sol wrote: >> [Usenet] worked. It is still free and open. > > It used to be. It's getting harder and harder to get feeds these days. > Everyone just reads through Google Groups rather than trying to find > someone with a feed. SL and OpenSim started with the equivalent of > "Google Groups" already live. > > It wasn't even vaguely real-time. It was *OK* that the > stanford-munnari link was a daily airmailed magtape, nobody cared if > their newsfeed was a day behind. > > From tigrospottystripes at gmail.com Sun Feb 28 12:38:08 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 28 Feb 2010 17:38:08 -0300 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4B8AB973.2020207@online.de> References: <4B8AB973.2020207@online.de> Message-ID: <4B8AD430.9030504@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 how much of the TPV is already covered by the TOS? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuK1CQACgkQ8ZFfSrFHsmX1iwCeKRfnZIQVQZ0VXFqPuOhXRQJO +18AniKNOHDHNKreFYzoQ7Hl4siRiOkp =pXFN -----END PGP SIGNATURE----- From erikba at odysseus.anderson.name Sun Feb 28 13:08:43 2010 From: erikba at odysseus.anderson.name (Erik Anderson) Date: Sun, 28 Feb 2010 13:08:43 -0800 Subject: [opensource-dev] Mailman for opensource-dev on pipermail is slicing posts In-Reply-To: References: Message-ID: <56c0988e1002281308j33a5bec2v49b3fc7af2674472@mail.gmail.com> I just was looking at the opensim-dev list last night and it looks like it's been shredding gears for a week or so now. Finally stopped logging any messages at all until a single message came through yesterday. On Sun, Feb 28, 2010 at 10:59 AM, Morgaine wrote: > For the month of February, there are now 4 posts (from different people) > that have been sliced into pieces and their headers-less tail fragments > placed into the mailing list archive with a Subject line of "No subject". > See the top of the threaded viewlisting. > > Could someone please request the mail sysadmins to take a look at this bug? > > Cheers, > > Morgaine. > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100228/fcf836e4/attachment.htm From soft at lindenlab.com Sun Feb 28 13:11:55 2010 From: soft at lindenlab.com (Soft Linden) Date: Sun, 28 Feb 2010 15:11:55 -0600 Subject: [opensource-dev] Mailman for opensource-dev on pipermail is slicing posts In-Reply-To: <56c0988e1002281308j33a5bec2v49b3fc7af2674472@mail.gmail.com> References: <56c0988e1002281308j33a5bec2v49b3fc7af2674472@mail.gmail.com> Message-ID: I'm creating a ticket for ops On Sun, Feb 28, 2010 at 3:08 PM, Erik Anderson wrote: > I just was looking at the opensim-dev list last night and it looks like it's > been shredding gears for a week or so now. ?Finally stopped logging any > messages at all until a single message came through yesterday. > > On Sun, Feb 28, 2010 at 10:59 AM, Morgaine > wrote: >> >> For the month of February, there are now 4 posts (from different people) >> that have been sliced into pieces and their headers-less tail fragments >> placed into the mailing list archive with a Subject line of "No subject". >> See the top of the threaded view listing. >> >> Could someone please request the mail sysadmins to take a look at this >> bug? From tigrospottystripes at gmail.com Sun Feb 28 13:32:53 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 28 Feb 2010 18:32:53 -0300 Subject: [opensource-dev] Is there free images in second life In-Reply-To: <4B8A979B.8080906@boroon.dasgupta.ch> References: <7600b1331002280801j3d234081wf74cf618013d1d4c@mail.gmail.com> <4B8A979B.8080906@boroon.dasgupta.ch> Message-ID: <4B8AE105.9090605@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 or simply ask a friend to hand over a full perm snapshot they make :) On 28/2/2010 13:19, Boroondas Gupte wrote: > Rustam Rakhimov schrieb: >> Is there free images in second life ? >> >> where I can take it. > > 1. Open the inventory (Ctrl-i) > 2. Go to > * *Library* > *Photo Album* > or > * *Library* > *Textures* > > Or get Torley's free textures here > . > > I hope this helps. > cheers > Boroondas > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuK4P0ACgkQ8ZFfSrFHsmV9DACdFws5ik/MGbxBd7GcFVhVvveV Xn8AoIfiP8Plj7MPOBjFahSR+ZrfKCDI =zNXM -----END PGP SIGNATURE----- From thickbrick.sleaford at gmail.com Sun Feb 28 14:37:51 2010 From: thickbrick.sleaford at gmail.com (Thickbrick Sleaford) Date: Mon, 1 Mar 2010 00:37:51 +0200 Subject: [opensource-dev] latest SG1.3.2 In-Reply-To: <20100228002321.4806e478.tayra.dagostino@gmail.com> References: <20100228002321.4806e478.tayra.dagostino@gmail.com> Message-ID: <201003010037.51705.thickbrick.sleaford@gmail.com> On Sunday 28 February 2010 01:23:21 Tayra Dagostino wrote: > receiveMessage:943: GStreamer010 media instance failed to set up ... > (:24128): GStreamer-CRITICAL **: gst_element_set_state: > assertion `GST_IS_ELEMENT (element)' failed > > somebody else notice this on a lenny+backports? Does your Audio Driver: line in Help -> About show "(noce)"? If so, I think this sounds similar to http://jira.secondlife.com/browse/SNOW-541 I think that normally when the sound device can't be opened, OpenAL will try to open first ALSA, then OSS, and only then PulseAudio. but it seems in SNOW-541 it first tried PulseAudio, even though it didn't exist, resulting in non-working sound and non-working gstreamer plugin. (This is just a guess, and I haven't seen this on my system.) -- Thickbrick From tayra.dagostino at gmail.com Sun Feb 28 15:48:56 2010 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Mon, 1 Mar 2010 00:48:56 +0100 Subject: [opensource-dev] latest SG1.3.2 In-Reply-To: <201003010037.51705.thickbrick.sleaford@gmail.com> References: <20100228002321.4806e478.tayra.dagostino@gmail.com> <201003010037.51705.thickbrick.sleaford@gmail.com> Message-ID: <20100301004856.ca218803.tayra.dagostino@gmail.com> On Mon, 1 Mar 2010 00:37:51 +0200 Thickbrick Sleaford wrote: > On Sunday 28 February 2010 01:23:21 Tayra Dagostino wrote: > > receiveMessage:943: GStreamer010 media instance failed to set up > ... > > (:24128): GStreamer-CRITICAL **: gst_element_set_state: > > assertion `GST_IS_ELEMENT (element)' failed > > > > somebody else notice this on a lenny+backports? > > Does your Audio Driver: line in Help -> About show "(noce)"? If so, I > think this sounds similar to > http://jira.secondlife.com/browse/SNOW-541 > > I think that normally when the sound device can't be opened, OpenAL > will try to open first ALSA, then OSS, and only then PulseAudio. but > it seems in SNOW-541 it first tried PulseAudio, even though it didn't > exist, resulting in non-working sound and non-working gstreamer > plugin. (This is just a guess, and I haven't seen this on my system.) uhm i don't remember a gstream update from backport, but is like mine and only now i've noticed (none) as audio engine (but i can hear sound from gestures and voice), only audio stream is affected (multimedia audio from youtube or something else like work) anyway voted.... From monkowsk at fishkill.ibm.com Sun Feb 28 15:58:17 2010 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Sun, 28 Feb 2010 18:58:17 -0500 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <4B8B0319.3080504@fishkill.ibm.com> So you've created this Third Party Viewer Directory in order to *promote* third part viewers? *That's* your "why"? Well, you needn't have bothered. You did much more to promote third party viewers by releasing Viewer 2.0. Mike Soft Linden wrote: > I feel I should add too - this isn't all stick, as my below > speculation about legal's intent might have suggested. Remember that > we're creating the Viewer Directory to promote other viewer projects, > so complying with the TPV terms offers up a pretty good carrot. > However, I think legal also knows we'd be making trouble for ourselves > if we gave even the whiff of an endorsement to a tool that hurt our > resis or the Lab. So, legal needed to offer some objective rules > before we could promote any projects. > > I hope this is helping. I worried that one of the most frustrating > parts of the TPV might be that it was landing with a big "what" > without enough "why" behind it. Most people react pretty badly to > anything that looks like control for control's own sake. From joe at lindenlab.com Sun Feb 28 16:27:06 2010 From: joe at lindenlab.com (Joe Linden) Date: Sun, 28 Feb 2010 16:27:06 -0800 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4B8B0319.3080504@fishkill.ibm.com> References: <4B8B0319.3080504@fishkill.ibm.com> Message-ID: <6b9495c41002281627u24a50c33v93cb314654356458@mail.gmail.com> Yes, Mike, we created the Third Party Viewer Directory to promote a range of viewers that allow Residents to experience Second Life and everything in it in a wide variety of ways. Since we'll be pointing to it often, it's a great way for the largest possible audience of Residents to learn about viewer alternatives that have been submitted by developers willing to certify that the viewer complies with the policy for all 3rd party viewers that connect to SL. And we haven't release Viewer 2.0 yet. It's in open beta now to take constructive feedback from (new and longtime) Residents. If it also stimulates great alternative viewers that comply with the policy, then we've accomplished several of our goals. -- joe On Sun, Feb 28, 2010 at 3:58 PM, Mike Monkowski wrote: > So you've created this Third Party Viewer Directory in order to > *promote* third part viewers? *That's* your "why"? Well, you needn't > have bothered. You did much more to promote third party viewers by > releasing Viewer 2.0. > > Mike > > Soft Linden wrote: > > I feel I should add too - this isn't all stick, as my below > > speculation about legal's intent might have suggested. Remember that > > we're creating the Viewer Directory to promote other viewer projects, > > so complying with the TPV terms offers up a pretty good carrot. > > However, I think legal also knows we'd be making trouble for ourselves > > if we gave even the whiff of an endorsement to a tool that hurt our > > resis or the Lab. So, legal needed to offer some objective rules > > before we could promote any projects. > > > > I hope this is helping. I worried that one of the most frustrating > > parts of the TPV might be that it was landing with a big "what" > > without enough "why" behind it. Most people react pretty badly to > > anything that looks like control for control's own sake. > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100228/10817e3d/attachment.htm From morgaine.dinova at googlemail.com Sun Feb 28 16:44:02 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Mon, 1 Mar 2010 00:44:02 +0000 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <6b9495c41002281627u24a50c33v93cb314654356458@mail.gmail.com> References: <4B8B0319.3080504@fishkill.ibm.com> <6b9495c41002281627u24a50c33v93cb314654356458@mail.gmail.com> Message-ID: On Mon, Mar 1, 2010 at 12:27 AM, Joe Linden wrote: > Yes, Mike, we created the Third Party Viewer Directory to promote a range > of viewers that allow Residents to experience Second Life and everything in > it in a wide variety of ways. Joe, thanks for clarifying that what you are doing with the Directory is "promotion" of Third Party Viewers. Since it's just promotion, TPV developers are free to ignore it when they excel on features and don't need promotion, and of course you will never make promotion mandatory. It's great that you clarified this, because people were mistakenly thinking that instead of promotion, what you were trying to do is to regulate 3rd party viewers and prevent them from gaining features that push the envelope and make your own viewers look poor in comparison. It's always useful when such misapprehensions are laid to rest. Have a good day, and many thanks! :-) Morgaine. ================================ On Mon, Mar 1, 2010 at 12:27 AM, Joe Linden wrote: > Yes, Mike, we created the Third Party Viewer Directory to promote a range > of viewers that allow Residents to experience Second Life and everything in > it in a wide variety of ways. Since we'll be pointing to it often, it's a > great way for the largest possible audience of Residents to learn about > viewer alternatives that have been submitted by developers willing to > certify that the viewer complies with the policy for all 3rd party viewers > that connect to SL. > > And we haven't release Viewer 2.0 yet. It's in open beta now to take > constructive feedback from (new and longtime) Residents. If it also > stimulates great alternative viewers that comply with the policy, then we've > accomplished several of our goals. > > -- joe > > > > On Sun, Feb 28, 2010 at 3:58 PM, Mike Monkowski > wrote: > >> So you've created this Third Party Viewer Directory in order to >> *promote* third part viewers? *That's* your "why"? Well, you needn't >> have bothered. You did much more to promote third party viewers by >> releasing Viewer 2.0. >> >> Mike >> >> Soft Linden wrote: >> > I feel I should add too - this isn't all stick, as my below >> > speculation about legal's intent might have suggested. Remember that >> > we're creating the Viewer Directory to promote other viewer projects, >> > so complying with the TPV terms offers up a pretty good carrot. >> > However, I think legal also knows we'd be making trouble for ourselves >> > if we gave even the whiff of an endorsement to a tool that hurt our >> > resis or the Lab. So, legal needed to offer some objective rules >> > before we could promote any projects. >> > >> > I hope this is helping. I worried that one of the most frustrating >> > parts of the TPV might be that it was landing with a big "what" >> > without enough "why" behind it. Most people react pretty badly to >> > anything that looks like control for control's own sake. >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100301/d4f73070/attachment-0001.htm From gareth at garethnelson.com Sun Feb 28 17:24:08 2010 From: gareth at garethnelson.com (Gareth Nelson) Date: Mon, 1 Mar 2010 01:24:08 +0000 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: <4B8B0319.3080504@fishkill.ibm.com> <6b9495c41002281627u24a50c33v93cb314654356458@mail.gmail.com> Message-ID: <4ebfc1101002281724g2af00e1dj1734754afe2260fb@mail.gmail.com> The policy still refers to "distribution" in general, not just those viewers in the directory. So, everyone on this list is about to violate it, sorry. This might seem incredibly silly but shows how much you can break this policy without having the viewer do anything other than merely connect. # Remember, if you read this in a mailing list post, whomever owns the listserver has distributed it # You also just distributed it possibly by downloading the email from common.libsl import * client = SecondLife() print 'You probably shouldn\'t actually login, but if you do the author disclaims any and all liability' print 'Here\'s some content that is unsuitable for a PG audience: fuck shit cock cunt wanker' print 'Remember, before you login, you have not broken the TPV policy and the above profanity is just fine' print 'By the way, this runtime environment has not got a clue on your MAC address' print 'Here\'s some encouragement to infringe upon "intellectual property": go and infringe on intellectual property, go on, do it' print 'Simplest method - view a texture, take a screenshot, download, and reupload - that is "instruction"' print 'I absolutely do NOT represent that this in full compliance with the terms of the GPL, it is in fact under a simpler license as shown below' print 'I fully encourage women to walk around in public with uncovered hair, in violation of muslim law, and I also encourage eating pork and dancing on sundays - this is in v iolation of section 7ci of the TPV policy' print 'In the US, I believe distributing this is still a DMCA violation, so by having this code you\'re exposed to legal liability: 09 f9 11 02 9d 74 e3 5b d8 41 56 c5 63 56 8 8 c0' print """ GENERAL MOCKERY LICENSE V0.1 You are hereby permitted to use and distribute this software in order to mock people. Such permission includes redistribution and modification in source or binary form with exception of any modifications requested by linden lab under section 8d of their third party viewer policy. Should such modifications be requested, you are compelled to implement a feature that would violate Second Life Terms Of Service should it be used or lose your license to redistribute this software. The author disclaims any and all liability for any uses or distribution of this software in whatever fashion. Any modified versions of this software must carry a notice stating that it has been modified. """ first = raw_input('First Name:').strip('\n') last = raw_input('Last Name:').strip('\n') pwd = raw_input('Password:').strip('\n') print 'Your IP address, the fact you ran this viewer and your login details are about to be sent to linden lab - and typing in your login details wasn\'t in itself giving cons ent, was it?' print 'Being serious - if you really do want to violate the policy, hit enter now, otherwise close this program' raw_input('Hit enter to break the policy...') client.Network.Login(first,last,pwd,'Violated Life','TPV policy infringing edition') On Mon, Mar 1, 2010 at 12:44 AM, Morgaine wrote: > On Mon, Mar 1, 2010 at 12:27 AM, Joe Linden wrote: >> >> Yes, Mike, we created the Third Party Viewer Directory to promote a range >> of viewers that allow Residents to experience Second Life and everything in >> it in a wide variety of ways. > > Joe, thanks for clarifying that what you are doing with the Directory is > "promotion" of Third Party Viewers.? Since it's just promotion, TPV > developers are free to ignore it when they excel on features and don't need > promotion, and of course you will never make promotion mandatory. > > It's great that you clarified this, because people were mistakenly thinking > that instead of promotion, what you were trying to do is to regulate 3rd > party viewers and prevent them from gaining features that push the envelope > and make your own viewers look poor in comparison. > > It's always useful when such misapprehensions are laid to rest. > > Have a good day, and many thanks! :-) > > > Morgaine. > > > > > ================================ > > On Mon, Mar 1, 2010 at 12:27 AM, Joe Linden wrote: >> >> Yes, Mike, we created the Third Party Viewer Directory to promote a range >> of viewers that allow Residents to experience Second Life and everything in >> it in a wide variety of ways.? Since we'll be pointing to it often, it's a >> great way for the largest possible audience of Residents to learn about >> viewer alternatives that have been submitted by developers willing to >> certify that the viewer complies with the policy for all 3rd party viewers >> that connect to SL. >> >> And we haven't release Viewer 2.0 yet.? It's in open beta now to take >> constructive feedback from (new and longtime) Residents.? If it also >> stimulates great alternative viewers that comply with the policy, then we've >> accomplished several of our goals. >> >> -- joe >> >> >> On Sun, Feb 28, 2010 at 3:58 PM, Mike Monkowski >> wrote: >>> >>> So you've created this Third Party Viewer Directory in order to >>> *promote* third part viewers? ?*That's* your "why"? ?Well, you needn't >>> have bothered. ?You did much more to promote third party viewers by >>> releasing Viewer 2.0. >>> >>> Mike >>> >>> Soft Linden wrote: >>> > I feel I should add too - this isn't all stick, as my below >>> > speculation about legal's intent might have suggested. Remember that >>> > we're creating the Viewer Directory to promote other viewer projects, >>> > so complying with the TPV terms offers up a pretty good carrot. >>> > However, I think legal also knows we'd be making trouble for ourselves >>> > if we gave even the whiff of an endorsement to a tool that hurt our >>> > resis or the Lab. So, legal needed to offer some objective rules >>> > before we could promote any projects. >>> > >>> > I hope this is helping. I worried that one of the most frustrating >>> > parts of the TPV might be that it was landing with a big "what" >>> > without enough "why" behind it. Most people react pretty badly to >>> > anything that looks like control for control's own sake. >>> _______________________________________________ >>> 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 > -- ?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 From gareth at garethnelson.com Sun Feb 28 17:25:07 2010 From: gareth at garethnelson.com (Gareth Nelson) Date: Mon, 1 Mar 2010 01:25:07 +0000 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4ebfc1101002281724g2af00e1dj1734754afe2260fb@mail.gmail.com> References: <4B8B0319.3080504@fishkill.ibm.com> <6b9495c41002281627u24a50c33v93cb314654356458@mail.gmail.com> <4ebfc1101002281724g2af00e1dj1734754afe2260fb@mail.gmail.com> Message-ID: <4ebfc1101002281725k4c1dac93t2f2e33607a5828db@mail.gmail.com> This is untested by the way, seriously - probably won't run in its current state, and i'd advise people not to get it running On Mon, Mar 1, 2010 at 1:24 AM, Gareth Nelson wrote: > The policy still refers to "distribution" in general, not just those > viewers in the directory. > > So, everyone on this list is about to violate it, sorry. This might > seem incredibly silly but shows how much you can break this policy > without having the viewer do anything other than merely connect. > > # Remember, if you read this in a mailing list post, whomever owns the > listserver has distributed it > # You also just distributed it possibly by downloading the email > > from common.libsl import * > > client = SecondLife() > print 'You probably shouldn\'t actually login, but if you do the > author disclaims any and all liability' > print 'Here\'s some content that is unsuitable for a PG audience: fuck > shit cock cunt wanker' > print 'Remember, before you login, you have not broken the TPV policy > and the above profanity is just fine' > print 'By the way, this runtime environment has not got a clue on your > MAC address' > print 'Here\'s some encouragement to infringe upon "intellectual > property": go and infringe on intellectual property, go on, do it' > print 'Simplest method - view a texture, take a screenshot, download, > and reupload - that is "instruction"' > print 'I absolutely do NOT represent that this in full compliance with > the terms of the GPL, it is in fact under a simpler license as shown > below' > print 'I fully encourage women to walk around in public with uncovered > hair, in violation of muslim law, and I also encourage eating pork and > dancing on sundays - this is in v > iolation of section 7ci of the TPV policy' > print 'In the US, I believe distributing this is still a DMCA > violation, so by having this code you\'re exposed to legal liability: > 09 f9 11 02 9d 74 e3 5b d8 41 56 c5 63 56 8 > 8 c0' > print """ > > ? ? ? ? ? ? ? ?GENERAL MOCKERY LICENSE V0.1 > You are hereby permitted to use and distribute this software in order > to mock people. Such permission includes redistribution > and modification in source or binary form with exception of any > modifications requested by linden lab under section 8d of their third > party viewer policy. Should such modifications be requested, you are > compelled to implement a feature that would violate Second Life Terms > Of Service should it be used or lose your license to redistribute this > software. > > The author disclaims any and all liability for any uses or > distribution of this software in whatever fashion. > > Any modified versions of this software must carry a notice stating > that it has been modified. > """ > first = raw_input('First Name:').strip('\n') > last ?= raw_input('Last Name:').strip('\n') > pwd ? = raw_input('Password:').strip('\n') > > print 'Your IP address, the fact you ran this viewer and your login > details are about to be sent to linden lab - and typing in your login > details wasn\'t in itself giving cons > ent, was it?' > > print 'Being serious - if you really do want to violate the policy, > hit enter now, otherwise close this program' > > raw_input('Hit enter to break the policy...') > client.Network.Login(first,last,pwd,'Violated Life','TPV policy > infringing edition') > > > > On Mon, Mar 1, 2010 at 12:44 AM, Morgaine > wrote: >> On Mon, Mar 1, 2010 at 12:27 AM, Joe Linden wrote: >>> >>> Yes, Mike, we created the Third Party Viewer Directory to promote a range >>> of viewers that allow Residents to experience Second Life and everything in >>> it in a wide variety of ways. >> >> Joe, thanks for clarifying that what you are doing with the Directory is >> "promotion" of Third Party Viewers.? Since it's just promotion, TPV >> developers are free to ignore it when they excel on features and don't need >> promotion, and of course you will never make promotion mandatory. >> >> It's great that you clarified this, because people were mistakenly thinking >> that instead of promotion, what you were trying to do is to regulate 3rd >> party viewers and prevent them from gaining features that push the envelope >> and make your own viewers look poor in comparison. >> >> It's always useful when such misapprehensions are laid to rest. >> >> Have a good day, and many thanks! :-) >> >> >> Morgaine. >> >> >> >> >> ================================ >> >> On Mon, Mar 1, 2010 at 12:27 AM, Joe Linden wrote: >>> >>> Yes, Mike, we created the Third Party Viewer Directory to promote a range >>> of viewers that allow Residents to experience Second Life and everything in >>> it in a wide variety of ways.? Since we'll be pointing to it often, it's a >>> great way for the largest possible audience of Residents to learn about >>> viewer alternatives that have been submitted by developers willing to >>> certify that the viewer complies with the policy for all 3rd party viewers >>> that connect to SL. >>> >>> And we haven't release Viewer 2.0 yet.? It's in open beta now to take >>> constructive feedback from (new and longtime) Residents.? If it also >>> stimulates great alternative viewers that comply with the policy, then we've >>> accomplished several of our goals. >>> >>> -- joe >>> >>> >>> On Sun, Feb 28, 2010 at 3:58 PM, Mike Monkowski >>> wrote: >>>> >>>> So you've created this Third Party Viewer Directory in order to >>>> *promote* third part viewers? ?*That's* your "why"? ?Well, you needn't >>>> have bothered. ?You did much more to promote third party viewers by >>>> releasing Viewer 2.0. >>>> >>>> Mike >>>> >>>> Soft Linden wrote: >>>> > I feel I should add too - this isn't all stick, as my below >>>> > speculation about legal's intent might have suggested. Remember that >>>> > we're creating the Viewer Directory to promote other viewer projects, >>>> > so complying with the TPV terms offers up a pretty good carrot. >>>> > However, I think legal also knows we'd be making trouble for ourselves >>>> > if we gave even the whiff of an endorsement to a tool that hurt our >>>> > resis or the Lab. So, legal needed to offer some objective rules >>>> > before we could promote any projects. >>>> > >>>> > I hope this is helping. I worried that one of the most frustrating >>>> > parts of the TPV might be that it was landing with a big "what" >>>> > without enough "why" behind it. Most people react pretty badly to >>>> > anything that looks like control for control's own sake. >>>> _______________________________________________ >>>> 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 >> > > > > -- > ?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 > -- ?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 From bryon at slearth.com Sun Feb 28 17:30:39 2010 From: bryon at slearth.com (Bryon Ruxton) Date: Sun, 28 Feb 2010 17:30:39 -0800 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: Message-ID: Morgaine, I think your statement is a misunderstanding on your part. It?s not ?just promotion?. You don?t have a choice but to be be listed AND comply if you want to legitimately connect to the grid with your viewer. As originally intended by LL. They are not exclusive as currently implemented and described, unless they change that: ?agree to our Policy on Third-Party Viewers and the Second Life Terms of Service. If you do not agree, you are ineligible for the Viewer Directory, and you do not have permission to access Second Life using a third-party viewer.? i.e. You either comply AND feature in the "viewer registry". OR ignore it, as you said and you?d be in breach of the TOS as such: ?5.6 You will indemnify Linden lab from claims arising from breach of this Agreement by you, from your use of Second Life, from loss of Content due to your actions, or from alleged infringement by you?. And I don?t think opting out of the "viewer registry" should or ever will be an option. On 2/28/10 4:44 PM, "Morgaine" wrote: > Joe, thanks for clarifying that what you are doing with the Directory is > "promotion" of Third Party Viewers.? Since it's just promotion, TPV developers > are free to ignore it when they excel on features and don't need promotion, > and of course you will never make promotion mandatory. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100228/f83b7aff/attachment.htm From joe at lindenlab.com Sun Feb 28 17:36:47 2010 From: joe at lindenlab.com (Joe Linden) Date: Sun, 28 Feb 2010 17:36:47 -0800 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: <4B8B0319.3080504@fishkill.ibm.com> <6b9495c41002281627u24a50c33v93cb314654356458@mail.gmail.com> Message-ID: <6b9495c41002281736u6647f0d6v57f2572bd53c6bd2@mail.gmail.com> TPV developers may choose to list their viewers in the Directory for the value of receiving a wider awareness than they may be able to create themselves, or not. That's entirely up to the developer. All viewers that connect to the SL grids will need to abide by the TPV Policy regardless of their choice to list in the Directory. And, since we're only talking about conditions that apply when a TPV connects to Linden Lab's grid(s), we reserve the right to add, subtract, or otherwise modify those conditions at any point in the future. -- joe On Sun, Feb 28, 2010 at 4:44 PM, Morgaine wrote: > > ... Since it's just promotion, TPV developers are free to ignore it when > they excel on features and don't need promotion, and of course you will > never make promotion mandatory. > > Morgaine. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100228/9734c643/attachment.htm From missannotoole at yahoo.com Sun Feb 28 17:50:19 2010 From: missannotoole at yahoo.com (Ann Otoole) Date: Sun, 28 Feb 2010 17:50:19 -0800 (PST) Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <722515.9577.qm@web59107.mail.re1.yahoo.com> The 5.6 is obviously LL shifting liability for "bad viewer" users to the person that wrote it. Can't blame them for that. Only problem is the "bad viewer" writers never cared and will keep right on doing what they do and the counterfeiters and shoplifters will keep right on doing what they do using throw away accounts unimpeded. So the net effect of this is nill except future lawsuits will have to be filed against the people that wrote the "bad viewers". Naturally I would love to see the "bad viewer" writers identities exposed as part of public record in legal proceedings. But I don't see it happening anytime soon. The ripping off will continue. useful backup features will be removed from good viewers. Since Joe Linden is reading and participating I must ask if LL will be correcting their viewers' non compliance by implementing creator only controls on full permissions texture save to disk or just removing the feature since the creator already has the texture on disk? Because if LL leaves it in then that constitutes export of full permissions textures regardless of creator which means full permissions exports should be allowed. Given Linden Lab is in an odd position to be making licenses for the artists like that I am curious. Which will it be? Is LL going to get into compliance with their own TOS or change the TOS? Oh and what about snapshots and machinima since there might be licensing issues if content not created by the filmer/photographer is in view? ________________________________ From: Bryon Ruxton To: Morgaine ; Joe Linden Cc: opensource-dev at lists.secondlife.com Sent: Sun, February 28, 2010 8:30:39 PM Subject: Re: [opensource-dev] FAQ posted for Third Party Viewer Policy Re: [opensource-dev] FAQ posted for Third Party Viewer Policy Morgaine, I think your statement is a misunderstanding on your part. It?s not ?just promotion?. You don?t have a choice but to be be listed AND comply if you want to legitimately connect to the grid with your viewer. As originally intended by LL. They are not exclusive as currently implemented and described, unless they change that: ?agree to our Policy on Third-Party Viewers and the Second Life Terms of Service. If you do not agree, you are ineligible for the Viewer Directory, and you do not have permission to access Second Life using a third-party viewer.? i.e. You either comply AND feature in the "viewer registry". OR ignore it, as you said and you?d be in breach of the TOS as such: ?5.6 You will indemnify Linden lab from claims arising from breach of this Agreement by you, from your use of Second Life, from loss of Content due to your actions, or from alleged infringement by you?. And I don?t think opting out of the "viewer registry" should or ever will be an option. On 2/28/10 4:44 PM, "Morgaine" wrote: Joe, thanks for clarifying that what you are doing with the Directory is "promotion" of Third Party Viewers. Since it's just promotion, TPV developers are free to ignore it when they excel on features and don't need promotion, and of course you will never make promotion mandatory. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100228/fe04078a/attachment-0001.htm From maggie at matrisync.com Sun Feb 28 17:53:26 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Sun, 28 Feb 2010 20:53:26 -0500 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: On Sun, Feb 28, 2010 at 8:30 PM, Bryon Ruxton wrote: > And I don?t think opting out of the "viewer registry" should or ever will be > an option. I haven't heard anybody official say that the registry was mandatory. Yet. From tateru.nino at gmail.com Sun Feb 28 18:02:23 2010 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon, 01 Mar 2010 13:02:23 +1100 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <6b9495c41002281736u6647f0d6v57f2572bd53c6bd2@mail.gmail.com> References: <4B8B0319.3080504@fishkill.ibm.com> <6b9495c41002281627u24a50c33v93cb314654356458@mail.gmail.com> <6b9495c41002281736u6647f0d6v57f2572bd53c6bd2@mail.gmail.com> Message-ID: <4B8B202F.1090408@gmail.com> Ah, I'm starting to see now. Developers are only subject to the TPV policy if they want to be listed in the directory. Users are subject to the policy should they choose to use a TPV to connect to a Linden-operated grid, rather than an alternative (like OpenSim) Makes sense, but that would really mean that the TPV policies should be a part of the Terms of Service, wouldn't it> Doesn't make much sense to have them separated. On 1/03/2010 12:36 PM, Joe Linden wrote: > TPV developers may choose to list their viewers in the Directory for > the value of receiving a wider awareness than they may be able to > create themselves, or not. That's entirely up to the developer. All > viewers that connect to the SL grids will need to abide by the TPV > Policy regardless of their choice to list in the Directory. > > And, since we're only talking about conditions that apply when a TPV > connects to Linden Lab's grid(s), we reserve the right to add, > subtract, or otherwise modify those conditions at any point in the future. > > -- joe > > On Sun, Feb 28, 2010 at 4:44 PM, Morgaine > > wrote: > > > ... Since it's just promotion, TPV developers are free to ignore > it when they excel on features and don't need promotion, and of > course you will never make promotion mandatory. > > Morgaine. > > > _______________________________________________ > 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 -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100301/fceeee66/attachment.htm From joe at lindenlab.com Sun Feb 28 18:08:14 2010 From: joe at lindenlab.com (Joe Linden) Date: Sun, 28 Feb 2010 18:08:14 -0800 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <722515.9577.qm@web59107.mail.re1.yahoo.com> References: <722515.9577.qm@web59107.mail.re1.yahoo.com> Message-ID: <6b9495c41002281808r15c71e2awb047ff674ef614d6@mail.gmail.com> Ann, I'll let the text from the policy speak for itself on this question: "You must not use or provide any functionality that Linden Lab?s viewers do not have for exporting content from Second Life unless the functionality verifies that the content to be exported was created by the Second Life user who is using the Third-Party Viewer." -- joe On Sun, Feb 28, 2010 at 5:50 PM, Ann Otoole wrote: > > Since Joe Linden is reading and participating I must ask if LL will be > correcting their viewers' non compliance by implementing creator only > controls on full permissions texture save to disk or just removing the > feature since the creator already has the texture on disk? Because if LL > leaves it in then that constitutes export of full permissions textures > regardless of creator which means full permissions exports should be > allowed. Given Linden Lab is in an odd position to be making licenses for > the artists like that I am curious. Which will it be? Is LL going to get > into compliance with their own TOS or change the TOS? Oh and what about > snapshots and machinima since there might be licensing issues if content not > created by the filmer/photographer is in view? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100228/77a96cb4/attachment.htm From morgaine.dinova at googlemail.com Sun Feb 28 18:27:14 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Mon, 1 Mar 2010 02:27:14 +0000 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: Byron, your personal interpretation is at odds with Joe's words. Plus, Joe has just confirmed what he said earlier regarding "promotion" anyway, and it's exactly as he wrote the 1st time around, so it's your understanding that is flawed. Having your viewer listed in the TPV Directory is a developer's *choice*. Read Joe's words: On Mon, Mar 1, 2010 at 1:36 AM, Joe Linden wrote: > TPV developers may *choose* to list their viewers in the Directory for the > value of receiving a wider awareness than they may be able to create > themselves, or not. *That's entirely up to the developer.* All *viewers > that connect* to the SL grids will need to *abide* by the TPV Policy > regardless of their choice to list in the Directory. > > And, since we're only talking about conditions that apply when a TPV > connects to Linden Lab's grid(s), we reserve the right to add, subtract, or > otherwise modify those conditions at any point in the future. Unlike the language in the TPV and in most of the FAQ, Joe's words here are crystal clear, unambiguous, and make perfect sense. The choice of listing is a developer's choice, and Joe confirms that it's for "receiving a wider awareness than they may be able to create themselves, or not" --- ie. optional *promotion*, for the developer's benefit, and genuinely not mandatory. There is not a hint of coercion against developer's freedom to modify and distribute in Joe's words. [And hurrah for that, because that's one less hurdle towards compliance with GPLv2 clause 6.] And then, separately, Joe points out that it is *viewers* (not developers) which connect to SL that need to comply with LL's policy requirements when connected, which makes perfect sense. Joe underlines that point even more strongly: "*we're only talking about conditions that apply when a TPV connects to Linden Lab's grid(s)*". That's an extremely strong disclaimer --- LL has no interest in what developers do, nor in what viewers outside of SL do, but only in what viewers do when they are connected to SL. It's totally sensible. And your interpretation, Byron, bears no relation to it whatsoever. Morgaine. ================================== On Mon, Mar 1, 2010 at 1:30 AM, Bryon Ruxton wrote: > Morgaine, I think your statement is a misunderstanding on your part. It?s > not ?just promotion?. > > You don?t have a choice but to be be listed AND comply if you want to > legitimately connect to the grid with your viewer. As originally intended by > LL. They are not exclusive as currently implemented and described, unless > they change that: ?agree to our Policy on Third-Party Viewers and the Second > Life Terms of Service. If you do not agree, you are ineligible for the > Viewer Directory, and you do not have permission to access Second Life using > a third-party viewer.? > > i.e. You either comply AND feature in the "viewer registry". OR ignore it, > as you said and you?d be in breach of the TOS as such: ?5.6 You will > indemnify Linden lab from claims arising from breach of this Agreement by > you, from your use of Second Life, from loss of Content due to your actions, > or from alleged infringement by you?. > > And I don?t think opting out of the "viewer registry" should or ever will > be an option. > > > On 2/28/10 4:44 PM, "Morgaine" wrote: > > Joe, thanks for clarifying that what you are doing with the Directory is > "promotion" of Third Party Viewers. Since it's just promotion, TPV > developers are free to ignore it when they excel on features and don't need > promotion, and of course you will never make promotion mandatory. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100301/043e9e99/attachment.htm From tigrospottystripes at gmail.com Sun Feb 28 18:30:31 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 28 Feb 2010 23:30:31 -0300 Subject: [opensource-dev] Fwd: Is there free images in second life Message-ID: <4B8B26C7.9030109@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (just bouncing back tot he list) - -------- Original Message -------- Subject: Re: [opensource-dev] Is there free images in second life Date: Mon, 1 Mar 2010 11:10:02 +0900 From: Rustam Rakhimov To: Tigro Spottystripes Yes you are right Tigro, So is there any one who can donate image for free ??? 2010/3/1 Tigro Spottystripes > or simply ask a friend to hand over a full perm snapshot they make :) On 28/2/2010 13:19, Boroondas Gupte wrote: > Rustam Rakhimov schrieb: >> Is there free images in second life ? >> >> where I can take it. > 1. Open the inventory (Ctrl-i) > 2. Go to > * *Library* > *Photo Album* > or > * *Library* > *Textures* > Or get Torley's free textures here > . > I hope this helps. > cheers > Boroondas > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ 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 - -- Rustam Rakhimov Igorevich Graduate student Department of Computer Science and Engineering, DMS Lab, Room 1109 New Millennium Hall, Konkuk University 1,Hwayang-dong,Gwangin-Gu Seoul, Republic of Korea. Pin: 143701 Mobile: +82-10-5811-4263 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuLJsQACgkQ8ZFfSrFHsmW25gCfQkMvavr/iSIXd1mYV4I2bFWd QbIAmgMjwVnLx4MzZ2eo8uupwyfadJph =RMtr -----END PGP SIGNATURE----- From bryon at slearth.com Sun Feb 28 18:38:45 2010 From: bryon at slearth.com (Bryon Ruxton) Date: Sun, 28 Feb 2010 18:38:45 -0800 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <6b9495c41002281736u6647f0d6v57f2572bd53c6bd2@mail.gmail.com> Message-ID: Sorry Morgaine, I stand corrected by having read the FAQs afterwards. I thought registration was required to connect to the grid... Joe, I agree with others that it?s not enough to guard against intellectual property infringement and protect residents. Is there a plan to allow inworld residents to detect unidentified/unregistered Viewer names or Identifiers as least? Without that, I don?t see how the current policy would actually fulfill goals of the policy and program from actual rogue viewers. It?s a good step but that leaves security loopholes without such enforcement abilities. An LSL function somewhere to identify viewers would help. Leave then to us the ability to make inworld tools to control who gets in or not. Bryon On 2/28/10 5:36 PM, "Joe Linden" wrote: > TPV developers may choose to list their viewers in the Directory for the value > of receiving a wider awareness than they may be able to create themselves, or > not.? That's entirely up to the developer.? All viewers that connect to the SL > grids will need to abide by the TPV Policy regardless of their choice to list > in the Directory. > > And, since we're only talking about conditions that apply when a TPV connects > to Linden Lab's grid(s), we reserve the right to add, subtract, or otherwise > modify those conditions at any point in the future. > > -- joe > > On Sun, Feb 28, 2010 at 4:44 PM, Morgaine > wrote: >> >> ... Since it's just promotion, TPV developers are free to ignore it when they >> excel on features and don't need promotion, and of course you will never make >> promotion mandatory. >> >> Morgaine. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100228/dc45d2c1/attachment-0001.htm From maggie at matrisync.com Sun Feb 28 19:15:28 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Sun, 28 Feb 2010 22:15:28 -0500 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: <6b9495c41002281736u6647f0d6v57f2572bd53c6bd2@mail.gmail.com> Message-ID: On Sun, Feb 28, 2010 at 9:38 PM, Bryon Ruxton wrote: > An LSL function somewhere to identify viewers would help. > Leave then to us the ability to make inworld tools to control who gets in or > not. Your attention is directed to SVC-4636. I'm sure your support would be welcomed by some. Others know such a move would only increase the incentive for spoofing any identifier that might be used, regardless of what the ToS might say. Someone who's engaged in content copying is unlikely to be deterred by committing one more ToS violation. There is already at least one viewer developer who is also selling a product claiming to identify (by some secret proprietary means) avatars running "bad" viewers and ban them. From tigrospottystripes at gmail.com Sun Feb 28 19:15:26 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 01 Mar 2010 00:15:26 -0300 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <4B8B314E.7000501@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Last i've heard, if you know what you're doing, it's quite easy to mask your viewer as being another viewer; any detection system would only be able to catch viewers made by unskilled people (and viewers that intentionally tell the truth). On 28/2/2010 23:38, Bryon Ruxton wrote: > Sorry Morgaine, I stand corrected by having read the FAQs afterwards. > I thought registration was required to connect to the grid... > > Joe, > I agree with others that it?s not enough to guard against intellectual > property infringement and protect residents. > > Is there a plan to allow inworld residents to detect > unidentified/unregistered Viewer names or Identifiers as least? Without > that, I don?t see how the current policy would actually fulfill goals of > the policy and program from actual rogue viewers. It?s a good step but > that leaves security loopholes without such enforcement abilities. > > An LSL function somewhere to identify viewers would help. > Leave then to us the ability to make inworld tools to control who gets > in or not. > > Bryon > > On 2/28/10 5:36 PM, "Joe Linden" wrote: > > TPV developers may choose to list their viewers in the Directory for > the value of receiving a wider awareness than they may be able to > create themselves, or not. That's entirely up to the developer. > All viewers that connect to the SL grids will need to abide by the > TPV Policy regardless of their choice to list in the Directory. > > And, since we're only talking about conditions that apply when a TPV > connects to Linden Lab's grid(s), we reserve the right to add, > subtract, or otherwise modify those conditions at any point in the > future. > > -- joe > > On Sun, Feb 28, 2010 at 4:44 PM, Morgaine > <_morgaine.dinova at googlemail.com_> wrote: > > > ... Since it's just promotion, TPV developers are free to ignore > it when they excel on features and don't need promotion, and of > course you will never make promotion mandatory. > > Morgaine. > > > > _______________________________________________ > 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/ iEYEARECAAYFAkuLMUwACgkQ8ZFfSrFHsmX5+ACeMIHHNufVUEWEnhCMsRD1klQ+ LMMAnjoC5BfK0oqdCnVyzLIshQZRN+ed =ElGi -----END PGP SIGNATURE----- From tigrospottystripes at gmail.com Sun Feb 28 19:20:01 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 01 Mar 2010 00:20:01 -0300 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: <6b9495c41002281736u6647f0d6v57f2572bd53c6bd2@mail.gmail.com> Message-ID: <4B8B3261.2010308@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 AFAIK it doesn't claim to be able to detect them all the time, nor to be able to detect all clients that might be out there; it shouldn't be possible to do it, if he does make claims opposite to that he would be lying. On 1/3/2010 00:15, Maggie Leber (sl: Maggie Darwin) wrote: > On Sun, Feb 28, 2010 at 9:38 PM, Bryon Ruxton wrote: > >> An LSL function somewhere to identify viewers would help. >> Leave then to us the ability to make inworld tools to control who gets in or >> not. > > Your attention is directed to SVC-4636. I'm sure your support would > be welcomed by some. > > Others know such a move would only increase the incentive for spoofing > any identifier that might be used, regardless of what the ToS might > say. Someone who's engaged in content copying is unlikely to be > deterred by committing one more ToS violation. > > There is already at least one viewer developer who is also selling a > product claiming to identify (by some secret proprietary means) > avatars running "bad" viewers and ban them. > _______________________________________________ > 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/ iEYEARECAAYFAkuLMmAACgkQ8ZFfSrFHsmWT9ACfTPfLWjbbPEp0x+yhK/OZqsIs GEMAnRccx3iOX1kGRlb2lXNi15dHJpmf =DKex -----END PGP SIGNATURE----- From morgaine.dinova at googlemail.com Sun Feb 28 19:21:30 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Mon, 1 Mar 2010 03:21:30 +0000 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4B8B202F.1090408@gmail.com> References: <4B8B0319.3080504@fishkill.ibm.com> <6b9495c41002281627u24a50c33v93cb314654356458@mail.gmail.com> <6b9495c41002281736u6647f0d6v57f2572bd53c6bd2@mail.gmail.com> <4B8B202F.1090408@gmail.com> Message-ID: On Mon, Mar 1, 2010 at 2:02 AM, Tateru Nino wrote: > Ah, I'm starting to see now. Developers are only subject to the TPV policy > if they want to be listed in the directory. Users are subject to the policy > should they choose to use a TPV to connect to a Linden-operated grid, rather > than an alternative (like OpenSim) > > It's getting better, isn't it, logic is finally creeping in. :-) Joe's two posts above are the first to cleanly separate developers, viewers and users connecting to SL, and to discuss each one separately in their individual spheres without conflating them. If Joe were to write the whole TPV, we could probably all go home early. ;-) > Makes sense, but that would really mean that the TPV policies should be a > part of the Terms of Service, wouldn't it> Doesn't make much sense to have > them separated. > > Yes, you're right. Since the only thing that is regulated is the behavior of viewers within SL, it's all about Terms of Service. Indeed, a document imposing restrictions on something outside of LL's service makes no sense at all anyway, as well as wreaking havoc with GPLv2's clause 6. Joe has unpicked what was previously a bundle of spaghetti and made it comprehensible. [Kudos for that!] We're not home yet though. Apparently the wishes and rights of open-license content creators are going to be ignored and dismissed. This is unnecessary, unconscionable, and quite possibly illegal. And it's simply not right either. Before planting the mast at that spot, I suggest a little extra thought, because this is very bad on multiple fronts, and any gains that LL thinks it might make from it will probably be less than the damage. And the cost of doing The Right Thing is almost nil, because these legal rights are being exercised already, and all that's missing is a corresponding clause in TPV and FAQ. Morgaine. ======================================== On Mon, Mar 1, 2010 at 2:02 AM, Tateru Nino wrote: > Ah, I'm starting to see now. Developers are only subject to the TPV policy > if they want to be listed in the directory. Users are subject to the policy > should they choose to use a TPV to connect to a Linden-operated grid, rather > than an alternative (like OpenSim) > > Makes sense, but that would really mean that the TPV policies should be a > part of the Terms of Service, wouldn't it> Doesn't make much sense to have > them separated. > > > On 1/03/2010 12:36 PM, Joe Linden wrote: > > TPV developers may choose to list their viewers in the Directory for the > value of receiving a wider awareness than they may be able to create > themselves, or not. That's entirely up to the developer. All viewers that > connect to the SL grids will need to abide by the TPV Policy regardless of > their choice to list in the Directory. > > And, since we're only talking about conditions that apply when a TPV > connects to Linden Lab's grid(s), we reserve the right to add, subtract, or > otherwise modify those conditions at any point in the future. > > -- joe > > On Sun, Feb 28, 2010 at 4:44 PM, Morgaine wrote: > >> >> ... Since it's just promotion, TPV developers are free to ignore it when >> they excel on features and don't need promotion, and of course you will >> never make promotion mandatory. >> >> Morgaine. >> >> > _______________________________________________ > 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 > > > -- > Tateru Ninohttp://dwellonit.taterunino.net/ > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100301/0e309bde/attachment.htm From miro.collas at gmail.com Sun Feb 28 19:30:35 2010 From: miro.collas at gmail.com (Miro) Date: Sun, 28 Feb 2010 22:30:35 -0500 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4B8B3261.2010308@Gmail.com> References: <6b9495c41002281736u6647f0d6v57f2572bd53c6bd2@mail.gmail.com> <4B8B3261.2010308@Gmail.com> Message-ID: <4B8B34DB.5080602@gmail.com> You might wish to make time to read this (very long) thread, if you have not already: https://blogs.secondlife.com/thread/10467 Some research has been done into how the device works. Apparently it exploits a vulnerability in QuickTime to access users' computers and "mine" information about what software is, or was, installed on them. [I say "apparently" because I have not done the research myself and so cannot verify what others have written.] On 02/28/2010 10:20 PM, Tigro Spottystripes wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > AFAIK it doesn't claim to be able to detect them all the time, nor to be > able to detect all clients that might be out there; it shouldn't be > possible to do it, if he does make claims opposite to that he would be > lying. > > On 1/3/2010 00:15, Maggie Leber (sl: Maggie Darwin) wrote: >> On Sun, Feb 28, 2010 at 9:38 PM, Bryon Ruxton wrote: >> >>> An LSL function somewhere to identify viewers would help. >>> Leave then to us the ability to make inworld tools to control who gets in or >>> not. >> >> Your attention is directed to SVC-4636. I'm sure your support would >> be welcomed by some. >> >> Others know such a move would only increase the incentive for spoofing >> any identifier that might be used, regardless of what the ToS might >> say. Someone who's engaged in content copying is unlikely to be >> deterred by committing one more ToS violation. >> >> There is already at least one viewer developer who is also selling a >> product claiming to identify (by some secret proprietary means) >> avatars running "bad" viewers and ban them. >> _______________________________________________ >> 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/ > > iEYEARECAAYFAkuLMmAACgkQ8ZFfSrFHsmWT9ACfTPfLWjbbPEp0x+yhK/OZqsIs > GEMAnRccx3iOX1kGRlb2lXNi15dHJpmf > =DKex > -----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 > -- Co-owner, Animations Rising: http://tinyurl.com/l959f2 Digital art by Miro: http://tinyurl.com/lwtw3q From morgaine.dinova at googlemail.com Sun Feb 28 19:33:50 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Mon, 1 Mar 2010 03:33:50 +0000 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: Reposting part of last response to Soft, which the list's Mailman/pipermail sliced off. ================ >> As is written in the answer A15, "Residents retain intellectual property >> rights in the content they create in Second Life and it is important for you >> to respect those rights." Respecting their rights in this case requires you >> to to allow that content to be exported as its creator desires. Therefore >> you either need to extend A15 with this additional case, or add another FAQ >> Q+A (preferably immediately after #15) to address it. >> > > That might be material for the FAQ. But because there is no export > > permission bit, it's not possible to add export capability for these > > cases without enabling violation of others' content. At this point, I > > couldn't see that affecting the TPV policy. > An export permission bit is not required before export of open-licensed content can be done. We don't have an export permission bit in RL, and yet open licensing works just fine. As Fleep pointed out earlier, SL creators are already open-licensing their products right now, since it is so important for Education. As in RL, the responsibility for applying open licenses properly rests with the licensor, since nobody else can be expected to check what the licensor is licensing. That is no different here. Nobody expects you to do any checking, and your assertion that this leads to "violation of others' content" is patently wrong when the licensor uses only her own and other people's open-licensed content. Indeed, if you did do checking then you would not be able to disclaim liability for infringements. The core of the matter though is whether you believe in your own words in FAQ.15: "Residents retain intellectual property rights in the content they create in Second Life and it is important for you to respect those rights". Are you going to respect the rights of those creators who use open-licensing of their content? Or, ungenerously, are you only going to respect the rights of those creators who shore up the walls of your walled garden? I would prefer to believe that your support is for all content creators' rights and wishes. How you respond will reveal the truth of the matter. If you make it clear that building upon the openly and legally-licensed content of others is a ToS or TPV violation, then you are not respecting the rights and wishes of open creators, and it may not even be legal. My suggested new FAQ.16 or similar would let you "do the right thing" and be a good citizen of the open license community. Morgaine. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100301/57e8750f/attachment-0001.htm From maggie at matrisync.com Sun Feb 28 19:36:04 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Sun, 28 Feb 2010 22:36:04 -0500 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4B8B34DB.5080602@gmail.com> References: <6b9495c41002281736u6647f0d6v57f2572bd53c6bd2@mail.gmail.com> <4B8B3261.2010308@Gmail.com> <4B8B34DB.5080602@gmail.com> Message-ID: On Sun, Feb 28, 2010 at 10:30 PM, Miro wrote: > Some research has been done into how the device works. Apparently it > exploits a vulnerability in QuickTime to access users' computers and > "mine" information about what software is, or was, installed on them. With the advent of Viewer2 and promiscuous loading of media we all need to be more vigilant about such vulnerabilities. Such a practice is a criminal violation in some jurisdictions. From tigrospottystripes at gmail.com Sun Feb 28 19:49:18 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 01 Mar 2010 00:49:18 -0300 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4B8B34DB.5080602@gmail.com> References: <6b9495c41002281736u6647f0d6v57f2572bd53c6bd2@mail.gmail.com> <4B8B3261.2010308@Gmail.com> <4B8B34DB.5080602@gmail.com> Message-ID: <4B8B393E.3030706@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hm, i didn't thought he did collect IP addresses, but even if the system does catch IP addresses (which isn't such a big deal if you keep your machine safe) an IP address wouldn't be of any help identifying malicious clients, unless the malicious clients in question routed stuff thru a known proxy. Btw, gathering IPs has nothing to do with Quicktime, or at least it isn't restricted to Quicktime, any sort of data hosted on a server with some sort of monitorament(sp?) in the server will do. LL knows how the system work, and in the past they were quite fast to pull the plug on Quicktime when there was a security hole related to it. On 1/3/2010 00:30, Miro wrote: > You might wish to make time to read this (very long) thread, if you have > not already: > > https://blogs.secondlife.com/thread/10467 > > Some research has been done into how the device works. Apparently it > exploits a vulnerability in QuickTime to access users' computers and > "mine" information about what software is, or was, installed on them. > > [I say "apparently" because I have not done the research myself and so > cannot verify what others have written.] > > On 02/28/2010 10:20 PM, Tigro Spottystripes wrote: > AFAIK it doesn't claim to be able to detect them all the time, nor to be > able to detect all clients that might be out there; it shouldn't be > possible to do it, if he does make claims opposite to that he would be > lying. > > On 1/3/2010 00:15, Maggie Leber (sl: Maggie Darwin) wrote: >>>> On Sun, Feb 28, 2010 at 9:38 PM, Bryon Ruxton wrote: >>>> >>>>> An LSL function somewhere to identify viewers would help. >>>>> Leave then to us the ability to make inworld tools to control who gets in or >>>>> not. >>>> >>>> Your attention is directed to SVC-4636. I'm sure your support would >>>> be welcomed by some. >>>> >>>> Others know such a move would only increase the incentive for spoofing >>>> any identifier that might be used, regardless of what the ToS might >>>> say. Someone who's engaged in content copying is unlikely to be >>>> deterred by committing one more ToS violation. >>>> >>>> There is already at least one viewer developer who is also selling a >>>> product claiming to identify (by some secret proprietary means) >>>> avatars running "bad" viewers and ban them. >>>> _______________________________________________ >>>> 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/ iEYEARECAAYFAkuLOToACgkQ8ZFfSrFHsmXwrQCeO/VCLVcpsXu2tKVGVZ2GTno2 yHYAnjDfIbZ2ShyMgYuriSV3XozxY1sD =VPzF -----END PGP SIGNATURE----- From bryon at slearth.com Sun Feb 28 19:55:57 2010 From: bryon at slearth.com (Bryon Ruxton) Date: Sun, 28 Feb 2010 19:55:57 -0800 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4B8B314E.7000501@Gmail.com> Message-ID: Of course, I know that Tigro. But just like any web site can detect a user-agent and block it, I'd like to be able to detect the viewer agent, (perhaps via llGetAgentInfo) of the avatar getting on my land anyway. Such would be useful for various other reasons such a compatibility checks, analysis of traffic sources, who you visitors are etc... On 2/28/10 7:15 PM, "Tigro Spottystripes" wrote: > > Last i've heard, if you know what you're doing, it's quite easy to mask > your viewer as being another viewer; any detection system would only be > able to catch viewers made by unskilled people (and viewers that > intentionally tell the truth). > From maggie at matrisync.com Sun Feb 28 19:58:50 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Sun, 28 Feb 2010 22:58:50 -0500 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4B8B393E.3030706@Gmail.com> References: <6b9495c41002281736u6647f0d6v57f2572bd53c6bd2@mail.gmail.com> <4B8B3261.2010308@Gmail.com> <4B8B34DB.5080602@gmail.com> <4B8B393E.3030706@Gmail.com> Message-ID: On Sun, Feb 28, 2010 at 10:49 PM, Tigro Spottystripes wrote: > hm, i didn't thought he did collect IP addresses, but even if the system > does catch IP addresses (which isn't such a big deal if you keep your > machine safe) an IP address wouldn't be of any help identifying > malicious clients, unless the malicious clients in question routed stuff > thru a known proxy. Sounds to me like we're talking about a lot more than IP address. There have been both remote file system reading and arbitrary code execution vulnerabilities in Quicktime in the past. From tigrospottystripes at gmail.com Sun Feb 28 19:59:09 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 01 Mar 2010 00:59:09 -0300 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: Message-ID: <4B8B3B8D.5070208@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 An user agent string for the client would indeed be useful, but would be useless to catch all but the lamest malicious clients. On 1/3/2010 00:55, Bryon Ruxton wrote: > Of course, I know that Tigro. But just like any web site can detect a > user-agent and block it, I'd like to be able to detect the viewer agent, > (perhaps via llGetAgentInfo) of the avatar getting on my land anyway. > Such would be useful for various other reasons such a compatibility checks, > analysis of traffic sources, who you visitors are etc... > > On 2/28/10 7:15 PM, "Tigro Spottystripes" > wrote: > >> >> Last i've heard, if you know what you're doing, it's quite easy to mask >> your viewer as being another viewer; any detection system would only be >> able to catch viewers made by unskilled people (and viewers that >> intentionally tell the truth). >> > > > _______________________________________________ > 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/ iEYEARECAAYFAkuLO4gACgkQ8ZFfSrFHsmUIZgCfaqweE1vHnRkU0dC774sjn0DD 904An2VJ/Iqf7vQ4N3X8jkEaJJlrQZl9 =Swst -----END PGP SIGNATURE----- From tigrospottystripes at gmail.com Sun Feb 28 20:02:38 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 01 Mar 2010 01:02:38 -0300 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: References: <6b9495c41002281736u6647f0d6v57f2572bd53c6bd2@mail.gmail.com> <4B8B3261.2010308@Gmail.com> <4B8B34DB.5080602@gmail.com> <4B8B393E.3030706@Gmail.com> Message-ID: <4B8B3C5E.7020308@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So, all that the scriptkiddies out there need to do to evade the all mighty Gemini CDS malicious client user detection system is to not have Quicktime installed? And LL is letting all their users run around with their machines open to attack by anyone? That doesn't sound plausible at all... On 1/3/2010 00:58, Maggie Leber (sl: Maggie Darwin) wrote: > On Sun, Feb 28, 2010 at 10:49 PM, Tigro Spottystripes > wrote: >> hm, i didn't thought he did collect IP addresses, but even if the system >> does catch IP addresses (which isn't such a big deal if you keep your >> machine safe) an IP address wouldn't be of any help identifying >> malicious clients, unless the malicious clients in question routed stuff >> thru a known proxy. > > Sounds to me like we're talking about a lot more than IP address. > There have been both remote file system reading and arbitrary code > execution vulnerabilities in Quicktime in the past. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuLPFsACgkQ8ZFfSrFHsmUq9wCePU6qZ/B/9jnj2LiKp6eFu4/U fOEAnjyVKfKPB0S0BoJWo6t/pLCEGCnw =v4/s -----END PGP SIGNATURE----- From maggie at matrisync.com Sun Feb 28 20:05:19 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Sun, 28 Feb 2010 23:05:19 -0500 Subject: [opensource-dev] Fwd: FAQ posted for Third Party Viewer Policy In-Reply-To: References: <4B8B3B8D.5070208@Gmail.com> Message-ID: ---------- Forwarded message ---------- From: Maggie Leber (sl: Maggie Darwin) Date: Sun, Feb 28, 2010 at 11:04 PM Subject: Re: [opensource-dev] FAQ posted for Third Party Viewer Policy To: Tigro Spottystripes On Sun, Feb 28, 2010 at 10:59 PM, Tigro Spottystripes wrote: > An user agent string for the client would indeed be useful, but would be > useless to catch all but the lamest malicious clients. Well, I though that's what the required "unique channel" is for. From tigrospottystripes at gmail.com Sun Feb 28 20:06:40 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 01 Mar 2010 01:06:40 -0300 Subject: [opensource-dev] Fwd: FAQ posted for Third Party Viewer Policy In-Reply-To: References: <4B8B3B8D.5070208@Gmail.com> Message-ID: <4B8B3D50.2070808@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 but scripts are oblivious to that data, no? On 1/3/2010 01:05, Maggie Leber (sl: Maggie Darwin) wrote: > ---------- Forwarded message ---------- > From: Maggie Leber (sl: Maggie Darwin) > Date: Sun, Feb 28, 2010 at 11:04 PM > Subject: Re: [opensource-dev] FAQ posted for Third Party Viewer Policy > To: Tigro Spottystripes > > > On Sun, Feb 28, 2010 at 10:59 PM, Tigro Spottystripes > wrote: >> An user agent string for the client would indeed be useful, but would be >> useless to catch all but the lamest malicious clients. > > Well, I though that's what the required "unique channel" is for. > _______________________________________________ > 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/ iEYEARECAAYFAkuLPU4ACgkQ8ZFfSrFHsmXaOQCgigHiCnfoOEJdmFA3irHh9Qna yJIAn293Sxriwby4ReCxiov5QqKX+xqp =AF/a -----END PGP SIGNATURE----- From morgaine.dinova at googlemail.com Sun Feb 28 20:13:21 2010 From: morgaine.dinova at googlemail.com (Morgaine) Date: Mon, 1 Mar 2010 04:13:21 +0000 Subject: [opensource-dev] Fwd: FAQ posted for Third Party Viewer Policy In-Reply-To: References: <4B8B3B8D.5070208@Gmail.com> Message-ID: Back in the old days of Philip's SL, Lindens often proclaimed the futility of entering an arms race, and the channel concept stems from that --- self-identification as a choice, in the knowledge that stronger measures will always be countered anyway. It seems that those days are long gone though. Anyone wanting a solid business for the next few years might consider selling brooms to SL protectionists. There's a lot of tide to sweep back. ;-) Morgaine. =================================== On Mon, Mar 1, 2010 at 4:05 AM, Maggie Leber (sl: Maggie Darwin) < maggie at matrisync.com> wrote: > ---------- Forwarded message ---------- > From: Maggie Leber (sl: Maggie Darwin) > Date: Sun, Feb 28, 2010 at 11:04 PM > Subject: Re: [opensource-dev] FAQ posted for Third Party Viewer Policy > To: Tigro Spottystripes > > > On Sun, Feb 28, 2010 at 10:59 PM, Tigro Spottystripes > wrote: > > An user agent string for the client would indeed be useful, but would be > > useless to catch all but the lamest malicious clients. > > Well, I though that's what the required "unique channel" is for. > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100301/ffd3c16b/attachment-0001.htm From tigrospottystripes at gmail.com Sun Feb 28 20:43:48 2010 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 01 Mar 2010 01:43:48 -0300 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4B8B43EE.3090606@gmail.com> References: <6b9495c41002281736u6647f0d6v57f2572bd53c6bd2@mail.gmail.com> <4B8B3261.2010308@Gmail.com> <4B8B34DB.5080602@gmail.com> <4B8B393E.3030706@Gmail.com> <4B8B3C5E.7020308@Gmail.com> <4B8B43EE.3090606@gmail.com> Message-ID: <4B8B4604.9070803@Gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Without proofs that might have just as well have come from the butt of Neil or some other person pissed at Skills for catching their customers using malicious clients. On 1/3/2010 01:34, Miro wrote: > I urge you to read the thread. There are details there. To quote on > poster... > https://blogs.secondlife.com/message/111885#111885 > > "I've learned from sources "close to the developer" just HOW this system > works, Via your Media stream access, it accesses your computers AppData > folder, searching for installations of identified "copybot" capable > viewers, exploiting a function used by programs like flash player, > quicktime, and others such as that, that check to see which version is > on your system, telling you when you need to update. YOU DONT HAVE TO BE > ON THE VIEWER TO BE DETECTED, ONLY HAVE TO HAVE INSTALLED IT AT ONE > POINT..." > > And another > https://blogs.secondlife.com/message/112121#112121 > > "IN the meantime, a few tests have been conducted that suggest abuse of > port 80 via Quicktime and the Windows filesystem. > > 1) Disabling media and uninstalling quicktime seems to completely shut > this system down, in regards to detecting alts. Existing avatar keys > are still banned, but its "mysterious alt detection" begins to fail. > > 2) Only some hacked viewers are being detected, and fewer when in Linux. > Further, whereas in Windows if you use a normal viewer but have a > hacked one installed, it seems to pick you up (thus eliminating the > bouncer analogy, unless you think it's also OK for the bouncer to go to > your house and beat up your family), in Linux that function ceases to work. > > 3) Alternative plugins that can handle quicktime functions, when forced > to work on a fresh compile of a viewer build, seem to completely block > all functions other than being added to the database while using a > viewer that announces itself as Cryolife, Streetlife, etc. > > These all indicate scanning of Windows Application Data, app_data, or > even Windows Registry entries without consent. Additionally, all of > this explains why vanilla SL users using Mac OS are getting banned by > the system; Mac OS handles the version updates for Quicktime rather than > it having that capability enabled on itself, thus making it impossible > for this system to function properly against the Mac OS. So, to > prevent that from being noticed, Skills made all Mac OS users get the > kill signal because their computers wont allow her/his/its Gemini system > to access data on the machine. This way, Skills can just assert the > person was "obviously" using a malicious viewer, defaming them to hide > the inefficacy of the system itself." > > On 02/28/2010 11:02 PM, Tigro Spottystripes wrote: > So, all that the scriptkiddies out there need to do to evade the all > mighty Gemini CDS malicious client user detection system is to not have > Quicktime installed? And LL is letting all their users run around with > their machines open to attack by anyone? That doesn't sound plausible at > all... > > On 1/3/2010 00:58, Maggie Leber (sl: Maggie Darwin) wrote: >>>> On Sun, Feb 28, 2010 at 10:49 PM, Tigro Spottystripes >>>> wrote: >>>>> hm, i didn't thought he did collect IP addresses, but even if the >>>>> system >>>>> does catch IP addresses (which isn't such a big deal if you keep your >>>>> machine safe) an IP address wouldn't be of any help identifying >>>>> malicious clients, unless the malicious clients in question routed >>>>> stuff >>>>> thru a known proxy. >>>> >>>> Sounds to me like we're talking about a lot more than IP address. >>>> There have been both remote file system reading and arbitrary code >>>> execution vulnerabilities in Quicktime in the past. >>>> _______________________________________________ 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/ iEYEARECAAYFAkuLRf8ACgkQ8ZFfSrFHsmXijgCfR8yqNqXT9st0W3lYIK5gOLp+ MyMAnjOcJ9xf/CkwIPKnHgH0/K6XLXRa =NL2i -----END PGP SIGNATURE----- From techiedavid at gmail.com Sun Feb 28 21:29:07 2010 From: techiedavid at gmail.com (David Simmons) Date: Sun, 28 Feb 2010 21:29:07 -0800 Subject: [opensource-dev] "Second-Party" viewer policy (was: Third party viewer policy) In-Reply-To: References: <012E4081-AC93-43A9-89C2-65CAC87EFFCF@mac.com> <3a164ef31002260327x2a4d0005o2286ddcc56ce502f@mail.gmail.com> Message-ID: <3a164ef31002282129o17ccb603n4bab3ee05c20acde@mail.gmail.com> This is what LL say: 8e We may enforce this Policy in our sole discretion, including but not limited to by removing a Third-Party Viewer from the Viewer Directory and suspending or terminating the Second Life accounts of Developers or users of a Third-Party Viewer. We further reserve the right to take any and all technological measures we deem appropriate to block a Third-Party Viewer from accessing Second Life, and to pursue any and all legal and equitable remedies. Don't see how any of that enforcement can be applied to another grid other than SL. On Sun, Feb 28, 2010 at 8:08 AM, Argent Stonecutter wrote: > On 2010-02-26, at 05:27, David Simmons wrote: >> The common sense rules apply. If you are not connecting to the LL >> grid, Linden Lab can't make any policy regarding what you do. They >> don't need a policy saying that they can't make a policy telling you >> what to do on another grid. > > Is that a legal opinion? > > Words MEAN different things when lawyers are involved. > _______________________________________________ > 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 > -- ?The greatest danger in modern technology isn't that machines will begin to think like people, but that people will begin to think like machines? Unknown http://www.google.com/profiles/techiedavid From maggie at matrisync.com Sun Feb 28 22:25:04 2010 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Mon, 1 Mar 2010 01:25:04 -0500 Subject: [opensource-dev] FAQ posted for Third Party Viewer Policy In-Reply-To: <4B8B4604.9070803@Gmail.com> References: <6b9495c41002281736u6647f0d6v57f2572bd53c6bd2@mail.gmail.com> <4B8B3261.2010308@Gmail.com> <4B8B34DB.5080602@gmail.com> <4B8B393E.3030706@Gmail.com> <4B8B3C5E.7020308@Gmail.com> <4B8B43EE.3090606@gmail.com> <4B8B4604.9070803@Gmail.com> Message-ID: On Sun, Feb 28, 2010 at 11:43 PM, Tigro Spottystripes wrote: > Without proofs that might have just as well have come from the butt of > Neil or some other person pissed at Skills for catching their customers > using malicious clients. Since the methods are secret, we have only the vendor's word that they are legitimate and legal. From xotmid at gmail.com Sun Feb 28 23:02:25 2010 From: xotmid at gmail.com (Brandon Husbands) Date: Mon, 1 Mar 2010 01:02:25 -0600 Subject: [opensource-dev] Doxygen For SnowGlobe 2.0 Message-ID: http://dimentox.com/sg2dox/ snowglobe2 doxygen full zip http://www.dimentox.com/html.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100301/4b611890/attachment.htm From bogus@does.not.exist.com Fri Feb 5 05:04:03 2010 From: bogus@does.not.exist.com () Date: Fri, 05 Feb 2010 13:04:03 -0000 Subject: No subject Message-ID: some ambiguity) is definitely that binaries will be pushed to our clients and executed, even if this involves some action in-world. Whatever the mechanism of transfer, these binaries are inherently untrusted and untrustworthy by inspection. If you choose to assign your trust to them, that is your own personal lookout. Note that this situation is *NOT* like on the Web, where Javascript is sent to browsers as *source code* which is available for inspection by anyone who cares to do it. Because of the possibility of inspection, the Web enjoys the "many eyeballs" effect that allows browsers to flag sites as malicious. There will be no such protections here, because the distributed binaries are opaque. The mere idea that opaque binaries are being sent to people and executed locally on their PCs should be enough to send shivers down everyone's spine, even if they're only minimally aware of security. From our technical and open source perspective here, which is after all what opensource-dev is all about, it's just completely unacceptable. Designing script execution to run on LL's servers is wholly within Linden rights to do in secret. Designing script execution to run *on OUR private machines* is NOT within Linden rights to do in secret at all. Morgaine. ================================== On Wed, Mar 17, 2010 at 6:45 PM, Argent Stonecutter wrote: > On 2010-03-17, at 12:31, Dzonatas Sol wrote: > > You install a program on your computer, and you either trust it or > > you don't. It comes down to that, so it doesn't matter if it is .NET > > or Java or some binary made by company XYZZY. > > The quotes from the office hours make it seem like they're talking > about having in-world content pushing stuff onto your client, not > explicitly installing 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 > --0016e6d77e12e45e7404820510e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Argent is exactly right.

From sitting in on these OHs, the intention= that has come across (but with some ambiguity) is definitely that binaries= will be pushed to our clients and executed, even if this involves some act= ion in-world.=A0 Whatever the mechanism of transfer, these binaries are inh= erently untrusted and untrustworthy by inspection.=A0 If you choose to assi= gn your trust to them, that is your own personal lookout.

Note that this situation is NOT like on the Web, where Javascrip= t is sent to browsers as source code which is available for i= nspection by anyone who cares to do it.=A0 Because of the possibility of in= spection, the Web enjoys the "many eyeballs" effect that allows b= rowsers to flag sites as malicious.=A0 There will be no such protections he= re, because the distributed binaries are opaque.

The mere idea that opaque binaries are being sent to people and execute= d locally on their PCs should be enough to send shivers down everyone's= spine, even if they're only minimally aware of security.=A0 From our t= echnical and open source perspective here, which is after all what opensour= ce-dev is all about, it's just completely unacceptable.

Designing script execution to run on LL's servers is wholly within = Linden rights to do in secret.=A0 Designing script execution to run o= n OUR private machines is NOT within Linden rights to do in secret = at all.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Wed, Mar 17, 2010 at 6:45 PM, Argent Stonec= utter <secr= et.argent at gmail.com> wrote:
On 2010-03-17, at 12:31, Dzonatas Sol wrote:
> You install a program on your computer, and you either trust it or
> you don't. It comes down to that, so it doesn't matter if it i= s .NET
> or Java or some binary made by company XYZZY.

The quotes from the office hours make it seem like they're talkin= g
about having in-world content pushing stuff onto your client, not
explicitly installing 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 privile= ges

--0016e6d77e12e45e7404820510e0-- From bogus@does.not.exist.com Fri Feb 5 05:04:03 2010 From: bogus@does.not.exist.com () Date: Fri, 05 Feb 2010 13:04:03 -0000 Subject: No subject Message-ID: some ambiguity) is definitely that binaries will be pushed to our clients and executed, even if this involves some action in-world. Whatever the mechanism of transfer, these binaries are inherently untrusted and untrustworthy by inspection. If you choose to assign your trust to them, that is your own personal lookout. Note that this situation is *NOT* like on the Web, where Javascript is sent to browsers as *source code* which is available for inspection by anyone who cares to do it. Because of the possibility of inspection, the Web enjoys the "many eyeballs" effect that allows browsers to flag sites as malicious. There will be no such protections here, because the distributed binaries are opaque. The mere idea that opaque binaries are being sent to people and executed locally on their PCs should be enough to send shivers down everyone's spine, even if they're only minimally aware of security. From our technical and open source perspective here, which is after all what opensource-dev is all about, it's just completely unacceptable. Designing script execution to run on LL's servers is wholly within Linden rights to do in secret. Designing script execution to run *on OUR private machines* is NOT within Linden rights to do in secret at all. Morgaine. > > > > > > ================================== > > > On Wed, Mar 17, 2010 at 6:45 PM, Argent Stonecutter < > secret.argent at gmail.com> wrote: > >> On 2010-03-17, at 12:31, Dzonatas Sol wrote: >> > You install a program on your computer, and you either trust it or >> > you don't. It comes down to that, so it doesn't matter if it is .NET >> > or Java or some binary made by company XYZZY. >> >> The quotes from the office hours make it seem like they're talking >> about having in-world content pushing stuff onto your client, not >> explicitly installing 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 >> > > --0016e6d464cc1682ef0482052b12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [Mailmain/pipermail is slicing up posts again in the M/L archive.=A0 I'= ll try a repost.]


Argent is exactly r= ight.

From sitting in on these OHs, the intention that has come acro= ss (but with some ambiguity) is definitely that binaries will be pushed to = our clients and executed, even if this involves some action in-world.=A0 Wh= atever the mechanism of transfer, these binaries are inherently untrusted a= nd untrustworthy by inspection.=A0 If you choose to assign your trust to th= em, that is your own personal lookout.

Note that this situation is NOT like on the Web, where Javascrip= t is sent to browsers as source code which is available for i= nspection by anyone who cares to do it.=A0 Because of the possibility of in= spection, the Web enjoys the "many eyeballs" effect that allows b= rowsers to flag sites as malicious.=A0 There will be no such protections he= re, because the distributed binaries are opaque.

The mere idea that opaque binaries are being sent to people and execute= d locally on their PCs should be enough to send shivers down everyone's= spine, even if they're only minimally aware of security.=A0 From our t= echnical and open source perspective here, which is after all what opensour= ce-dev is all about, it's just completely unacceptable.

Designing script execution to run on LL's servers is wholly within = Linden rights to do in secret.=A0 Designing script execution to run o= n OUR private machines is NOT within Linden rights to do in secret = at all.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


On Wed, Mar 17, = 2010 at 6:45 PM, Argent Stonecutter <secret.argent at gmail.com>= wrote:
On 2010-03-1= 7, at 12:31, Dzonatas Sol wrote:
> You install a program on your computer, and you either trust it or
> you don't. It comes down to that, so it doesn't matter if it i= s .NET
> or Java or some binary made by company XYZZY.

The quotes from the office hours make it seem like they're talkin= g
about having in-world content pushing stuff onto your client, not
explicitly installing 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 privile= ges


--0016e6d464cc1682ef0482052b12-- From bogus@does.not.exist.com Fri Feb 5 05:04:03 2010 From: bogus@does.not.exist.com () Date: Fri, 05 Feb 2010 13:04:03 -0000 Subject: No subject Message-ID: are currently - at least code-wise - able to arbitrarily "stack" wearables in a user-defined order. So if you currently have a pair of pants on the pants layer and a pair of tights where one part is on the pants layer as well then you can choose to wear the tights "pants" *underneath* the pants "pants". I went a *little* bit crazy once I realized it was simple to nudge the official beta into letting you wear multiple items per wearable type and wore three tattoos on the underpants layer and then had fun stacking three different colours of tights on the underpants layer on top of them to see how the colours would blend to create different shades and it worked out just fine :). Personally what I would like best would be: ... Wear (= "Wearable Wear", replaces all items on the type) Wear Add / (wear top) (= "Wearable Add" on the top of the stack) Name of worn item 1 (= "Wearable Replace" on item 1) (wear between) (= "Wearable Add" in between two others) Name of worn item 2 (wear bottom) (= "Wearable Add" on the bottom of the stack) If it's the underpants layer then item 2 could be a tattoo (worn underneath anything else) and item 1 could be panties. If you want to add tights you'd pick the empty slot at the top and they'll render on top of the other two, if you want to add garters you'd pick the empty slot in the middle and they'll render in between the other two. If you want to wear a different tattoo, panties, ... then you just pick the option that corresponds to what you want to have replaced. There will probably be a need for a more fancy ("user-friendly") panel with up and down click button arrows to allow rearranging the items around but for just getting dressed I'd far prefer having the option of how to stack right on the context menu for the inventory item so getting dressed doesn't involve constant back-and-forth side-trips in the side bar. Kitty