[opensource-dev] Announce: realXtend Naali 0.1 (alpha) client viewer
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
Re: [opensource-dev] Announce: realXtend Naali 0.1 (alpha) client viewer
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
[opensource-dev] Naali UI research
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, ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Third party viewer policy
As far as I can tell, LL provides a *service* called SL; and they can choose to deny access to that service to whomever they please for whatever reason they please. So long as they control the server software and grid infrastructure this will always be the case. Having an "open" viewer to closed palace garden is *meaningless*. Even now, the viewer is becoming more closed (see Merov's Firefox v. WebKit comparison). What is the point of having an "open" core, missing all the value-added features, connecting to a black box, over non-standard (in any sense) protocol, governed by the legal policies of a single company? Google used WebKit to make Chrome. Does anyone here think someone is really going to turn Snow Globe into an independent application (any more)? Luckily there *are* truly open, free for any use implementations available. But they're alpha software, and will require much love before giving a real challenge to the professionally developed SL. As developers why continue to support the thing you rail against? Why not lend a hand to the small number of people trying to give you what you're looking for? Cheers, ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Third party viewer policy
On Tue, Feb 23, 2010 at 10:31 PM, Soft Linden wrote: > > If you see any wording that's ambiguous about that, let us know. Section 3.b.iii says that Third-party viewers must comply with the GPL license. What if the view is not licensed under the GPL at all -- say Apache 2.0? Cheers, ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Third party viewer policy
On Wed, Feb 24, 2010 at 1:10 PM, Thomas Shikami wrote: > Ryan McDougall schrieb: >> On Tue, Feb 23, 2010 at 10:31 PM, Soft Linden wrote: >> >>> If you see any wording that's ambiguous about that, let us know. >>> >> >> Section 3.b.iii says that Third-party viewers must comply with the GPL >> license. >> >> What if the view is not licensed under the GPL at all -- say Apache 2.0? >> >> Cheers, > It says, that Third-Party Viewers deriving from LL's GPLed viewer source > must comply with the GPL license. That doesn't apply to libomv based > viewers or pygop based ones or smalltalk or a complete reimplementation > of it. Actually it doesn't. "By “Third-Party Viewer,” we mean any third-party software client on any device that logs into our servers that support Second Life. Third-Party Viewers include software for viewing Second Life, any chat clients, utilities, bots, and proxies as well as applications that may not be listed in our Viewer Directory." Cheers, ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Third party viewer policy
On Wed, Feb 24, 2010 at 9:40 PM, Soft Linden wrote: > On Wed, Feb 24, 2010 at 1:18 PM, Soft Linden wrote: >> On Wed, Feb 24, 2010 at 4:58 AM, Ryan McDougall wrote: >>> On Tue, Feb 23, 2010 at 10:31 PM, Soft Linden wrote: >>>> >>>> If you see any wording that's ambiguous about that, let us know. >>> >>> Section 3.b.iii says that Third-party viewers must comply with the GPL >>> license. >>> >>> What if the view is not licensed under the GPL at all -- say Apache 2.0? >> >> This only applies to viewers based on our GPL'd viewer source. I'll >> point that out to legal - I know the intent was to make that specific, >> and this was an oversight. > > I just checked before writing to legal, and this phrase is already > included in 3.b.iii: > "if you have based your application on the official Second Life > viewer, which we have made available under the GPL" > > So this guy's already covered. > Not sure how I missed that -- or maybe I am (too much legalese text). Can you also clarify what the penalties are for non-compliance? Cheers, ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Fwd: Request for comments about llSetAgentEnvironment / SVC-5520
On Sun, Mar 14, 2010 at 7:25 PM, Soft Linden wrote: > On Fri, Mar 12, 2010 at 7:26 PM, Maggie Leber (sl: Maggie Darwin) > wrote: >> On Fri, Mar 12, 2010 at 2:31 PM, Soft Linden wrote: >> >>> A totally healthy open source project usually can be developed >>> completely in the open, and in a way that's aligned with everybody's >>> interests. But that takes an active commitment on all sides... >> >> True enough. But I think there's widespread perception that the Second >> Life Viewer is already not a "totally healthy open-source project", >> and I don't think that perception can't be laid at the door of >> "obstructionism". > > When discussions are poisoned to the point where folks are > name-calling and ascribing twisted motives to others on the list, the > people doing that are obstructive. That very much weighs against a > Linden's decision as to whether their work would benefit from open > development. I can also confidently say that the horrible signal to > noise ratio of feedback to developers has been the biggest barrier to > open development, prior to the viewer 2.0 development cycle. > > >> If that's the case, are you threating even less cooperation with the >> open source project unless people stop "obstructing" by becoming >> cheerleaders for an agenda that you haven't even disclosed? > > I'm not threatening anything. I'm pointing out that if you work with a > dev, they're more likely to want to work with you. If you work against > them, they're not going to make an effort to include you. This comes > down to individual Linden and team decisions on how they can be the > most effective. > > Even sections of the Linux kernel, the open source flagship, have been > developed in private and then taken back for submission. That's > happened when the community stopped being productive. Sometimes that's > even lead to nice projects, like the new scheduler. > > The implication that every last person has to have a say in every last > aspect of development for something to be an open source project is > false. That level of involvement is earned by merit. And demonizing > Linden Lab and its developers or otherwise getting in the way > certainly pisses away whatever developer karma one might have > accumulated. LL unilaterally designs and implements code behind closed doors, where it is accepted and merged then deployed -- all without any outside participation. In the linux kernel, design is discussed in the open, occasionally implemented behind closed doors, then discussed again for inclusion in Linus's kernel. The only nod to "open" is the GPL source, this impotent mailing list, and an equally ignored wiki. The community is "poisoned" from the cognitive dissonance caused by not yet realizing they don't even exist. Let's face facts here: LL as an organization doesn't know how to do open source, and those who even *like* open source are limited to a handful stalwarts like Soft who mostly end up regretting their forays here. Community contributions, beyond some free labor donated to a for-profit company as bug fixes, will never be relevant. Open source is a meritocracy where those who make the code, make the decisions. Since the code of contributors is not welcome (outside of free QA), decision-makers are nowhere to be found, and what you're left with is whingers, bike-shedders, and blow-hards ruminating the same stale cud thread-in and thread-out. When will the lobster quadrille end? If you like SL use SL. If you like doing free QA for SL, do free QA for SL. If you want to fork SL viewer, join that party. If you want a real open source community, those exist and *want* your help! Why stay here an piss in the wind? Even monkeys learn after repetition. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] oh give me a break
On Sun, Mar 14, 2010 at 9:09 PM, Kent Quirk (Q Linden) wrote: > > On Mar 14, 2010, at 2:41 PM, Marine Kelley wrote: > >> However it is true that LL has delivered a bad message recently, by >> publishing the TPV and the closed-source SL 2.0 the SAME day. The TPV >> burdens us developers while freeing LL's hands, and the viewer 2.0 is going >> to be adopted by newcomers, so it will eventually get a broader audience >> than the rest. It could very easily be seen as competition. It looks very >> close to some "fire-and-motion" technique. They suppress open-source >> development by laying unbelievably heavy requirements upon the devs, while >> moving forward and releasing their own viewer which is not subject to said >> requirements. I do hope I'm wrong and this is not the message that LL wanted >> to send to us. But one can understand why so many teeth are gritting now. >> > > What's frustrating about this for many of the Lindens is that we as an > organization pushed hard -- and Merov in particular worked nights and > weekends -- to get the Snowglobe source out on the same day that beta was > released, rather than waiting for our usual export process to work itself out > while we figure out how to make a new source control system (mercurial) work > for export. > > We actually believed we were doing something the community would really > appreciate -- getting the source out there the same day as beta. And yet > somehow that became something bad. People keep repeating that "it's closed > source". Here's a thought: why not *ask* them. In the "open". It absolves you of the need to guess. Cheers, > Despite the negative reaction, we're still working on the export process, as > Soft indicated, so that we can publish without the snowglobe patches added. > I'll also soon be posting our branching strategy we've been working out for > some weeks now. Sorry if it's not fast enough for some, but we've kind of > been focused on getting viewer 2 out. > > The TPV, as has been repeatedly stated, is about protecting our servers and > establishing the framework within which we can protect user content. I simply > don't see what the "heavy" requirements are. We ask viewer developers for > little more than good citizenship. That doesn't seem particularly burdensome. > > So yes, I think you're wrong about our motivations and intent. If we wanted > to kill our open source market we'd simply stop publishing it, rather than > creating a TPV that allows us to promote it. And considering the amount of > flak we've been getting, it would be easier. And yet, we're still here. > > Q > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Fwd: Request for comments about llSetAgentEnvironment / SVC-5520
On Sun, Mar 14, 2010 at 9:13 PM, Soft Linden wrote: > On Sun, Mar 14, 2010 at 11:32 AM, Ryan McDougall wrote: >> >> LL unilaterally designs and implements code behind closed doors, where >> it is accepted and merged then deployed -- all without any outside >> participation. In the linux kernel, design is discussed in the open, >> occasionally implemented behind closed doors, then discussed again for >> inclusion in Linus's kernel. >> >> The only nod to "open" is the GPL source, this impotent mailing list, > > The only nod to open source is the open source? Perfect example of where your understanding is misplaced: no, open source license != open source project. An open source license only requires source code drops. A true community requires equal participation. It's the difference between apartheid and democracy. Let me know if you'd like a deeper elucidation. Cheers, > >> and an equally ignored wiki. The community is "poisoned" from the >> cognitive dissonance caused by not yet realizing they don't even >> exist. >> >> Let's face facts here: LL as an organization doesn't know how to do >> open source, and those who even *like* open source are limited to a >> handful stalwarts like Soft who mostly end up regretting their forays >> here. Community contributions, beyond some free labor donated to a >> for-profit company as bug fixes, will never be relevant. > > This is wrong. Lip sync, mini map features, additional language > support, the first pass on flexible sculpties (not yet out in the main > viewer, but not dropped), double-click teleport, 64-bit build support, > stand-alone build support, strong debit permission warnings, the list > goes on. Many non-bug-fix changes have come from the community. I > agree that the process has been painful and slow, and not as many > patches have come in as most would wish, though. That's the reason > Snowglobe was created. Much faster iteration and proving of patches. > Don't call that a failure before you've seen the last bits of the > viewer 2.0 development cycle put to rest. > > What I'm trying really hard to get across here is that keeping > discussions civil, focused and constructive will help foster community > involvement. Q is working really hard to make sure that a feature held > in the dark for business reasons will never hold the rest of the > project hostage again. I can't see a reason why another Viewer 2.0 > style dev cycle will happen again. > > We're also working on restructuring the project so we're working in > peer code bases rather than doing one-way exports and manual patch > imports. That's going to make us better still about bringing outside > work in. But these efforts are going to be wasted if the teams are > still put off of working with the community because of the garbage > hostility that's been a frequent part of the list since very early on. > > >> Open source is a meritocracy where those who make the code, make the >> decisions. Since the code of contributors is not welcome (outside of >> free QA), decision-makers are nowhere to be found, and what you're >> left with is whingers, bike-shedders, and blow-hards ruminating the >> same stale cud thread-in and thread-out. When will the lobster >> quadrille end? > > For a good example: Read back on the list for the kind of responses > the render team was happening in the open. The render branches were > published continuously, and the developers were quite public-facing > for most of a year. > > The result? There were some morsels of great feedback, almost none of > them via this list. But there was also an overwhelming volume of > griping about not supporting year-old video cards, people crediting > other projects for Linden work, grousing about that not being the most > important thing to work on, grief about the state of Windlight, > insistence that we abandon our own engine entirely, stumping for other > projects, folks from this list blogging Runitai's comments out of > context, on and on. > > Tons of counterproductive chaos when someone wasn't getting his way, > some good QA feedback, a couple good tech suggestions, and almost zero > code contributions. That's what we've gotten when the decision makers > are out in the open - you can't say it hasn't been done. > > The render guys still want to get their work out and in the open > again, because they happen to be fairly bad ass and have thick skins. > They think the QA and bits of good feedback are worth more than the > cost of that chaos. > > Other teams will be able to make that choice again now,
Re: [opensource-dev] Fwd: Request for comments about llSetAgentEnvironment / SVC-5520
On Sun, Mar 14, 2010 at 9:59 PM, Soft Linden wrote: > On Sun, Mar 14, 2010 at 12:30 PM, Ryan McDougall wrote: >> >> Perfect example of where your understanding is misplaced: no, open >> source license != open source project. An open source license only >> requires source code drops. A true community requires equal >> participation. It's the difference between apartheid and democracy. >> >> Let me know if you'd like a deeper elucidation. > > Of everything in the post you quoted, you single out the chance to > take a swipe at semantics. No, I take a shot at the heart of the problem: making opened code drops is not developing software in an open manner. > Okay, first: you're wrong. open source refers to availability of the > source for an end product. This is a well-defined term, and an open > source project is open. Many, but not all open source projects have > open design and/or open development as characteristics of the project. > These are also well-understood terms. Opened source code is a necessary but not sufficient condition to meet the commonly understood meanings of open source *software* or open source *projects* or open source *communities*. If you really want semantics, consider "opened" is perfect tense, while "open" is imperfect. Snowglobe is a Bantustan. Considering all the trouble you've had with your project, it's a little awkward being lectured on openness from LL. > Second, read the rest of the post and see if you can spot the irony. > The deeper elucidation you're offering is on what I'm trying to > advance by explaining the benefits of constructive, meaningful > discussion. I'm trying to tell you how you can encourage more open > design and open development. If you want equal participation, you gain > it by merit - by acting as an equal. We're working to provide every > kind of opportunity for you to participate as a peer, and what you do > with that opportunity will be up to you. Open source isn't a choice to be open or closed. The fact that you think the community has to beg developers to stop being exclusionary is dumbfounding. LL has had years to figure out how to make a community, and it's inability to do so has cost other people real time and real money. If you read my email, I'm not interested in how to humbly coax LL's good will on bended knee -- I'm wondering why the heck any even hangs around waiting for the leopard to change it's spots! People looking for open design and development should really have learned their lesson by now. > This isn't even an "us" vs "them" thing. If a Linden tried to involve > himself in a project by taking pot shots and grousing instead of > furthering the project, it wouldn't get him any closer to peer > participation either. If one of the offices became notorious for > laying grief on projects, a Linden would do best to distance himself > from that office or to help fix things in that office instead of > defending its behavior to the hilt. > > What's your choice? > My choice is to work a real open source community, taking contributions, making software, now. Your choice is perpetuate a dishonesty that sometime in the distant future, if everyone plays nice enough, their contributions *might* be relevant LL. The real choice here is for the undecided. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Fwd: Request for comments about llSetAgentEnvironment / SVC-5520
On Sun, Mar 14, 2010 at 11:01 PM, Soft Linden wrote: > On Sun, Mar 14, 2010 at 1:32 PM, Ryan McDougall wrote: >> >> I'm not interested in how to humbly coax LL's >> good will on bended knee > > And that's not what has been asked of you. The rest of your post hangs > on that mischaracterization. The entirety of your emails hang on the mischaracterization that if people "remain civil and encourage participation", LL way one day actually allow real participation. It's necessary but not sufficient for a community. If frustrated and jaded people is what you have left, it's because you made it that way. > When you're on the realxtend list, you're civil and encourage > participation. I assume that's because you know that's what's involved > in making a project work. I'm asking for a similar baseline here if > you want to remain 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
Re: [opensource-dev] Third party viewer policy: commencement date
The policy deeply confuses users and developers together, making it appear to me that "users" can place "developers" in violation of your policy against their will. Let me explain: Let's say I develop a client expressly designed to log into OpenSim for example. Because of protocol compatibility, this client is incidentally capable of logging into SL. If a user decides to to just that, he is *clearly* a "User of Third Party Viewer". However, has he just made me a "Developer of Third Party Viewer"? I see no language that protects me from your policy. I've no interest in using LL's servers or enabling LL's business model. I don't want to agree to the TVP. Has OpenSim's historical choice of protocol placed it under LL's legal domain? If not, what section of your policy protects me? Sincerely, On Sat, Mar 20, 2010 at 6:21 PM, Joe Linden wrote: > The updated version of the Third Party Viewer Policy was posted here about a > week ago: > http://secondlife.com/corporate/tpv.php > > As stated in the FAQ, the policy will be in full force and effect on April > 30, 2010. > > -- Joe > > On Sat, Mar 20, 2010 at 7:20 AM, Boy Lane wrote: >> >> We are approacing one month after the initial 3rd party viewer policy has >> been announced. Nobody from Linden Lab has answered the question I've >> raised >> 2 weeks ago. So let me repeat it one more time: >> >> What is the status of the Third Party Viewer Policy? Do we have to assume >> that the current version is binding and/or when will an updated version be >> available? >> >> Thanks for your kind attention. Hopefully... >> >> >> - Original Message - >> From: "Boy Lane" >> To: >> Sent: Tuesday, March 09, 2010 10:11 PM >> Subject: Third party viewer policy: commencement date >> >> >> > It has been 14 days since the initial draft of the 3PVP was published >> > and >> > we were told it will be reworked to include comments, concerns and >> > suggestions. Two weeks have passed since and besides a FAQ that also >> > says >> > the policy is being worked on there have been no news. >> > >> > As this is a mission critical question for everybody involved in client >> > development: >> > What is the status of the Third Party Viewer Policy? Do we have to >> > assume >> > that the current version is binding and/or when will an updated version >> > be >> > available? >> > >> > Thanks! >> >> >> ___ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Third party viewer policy: commencement date
So you understand how LL employing such specialists, working a language the community "can't even understand", so admittedly protect their own self-interest (because it's a business), might create a a skewed balance of power that might cause the disadvantaged party to be mistrustful... right? People understand the GPL, or BSD. People don't understand your policies. I've never known a popular open source project with such legalistic encumbrances. Cheers, On Sun, Mar 21, 2010 at 7:24 PM, Kent Quirk (Q Linden) wrote: > I'm emphatically not a lawyer and I don't speak for our legal team. But: > > * Legalese is a specialized language. It's not strictly English, and it's not > always amenable to "common sense" interpretation. Think of lawyers as people > who write code in an underspecified language for a buggy compiler, and you > begin to understand why legalese is the way it is. There's a lot of law that > isn't stated, but is actually implied by the context of the existing settled > law. What that means is that if you're not a lawyer, you probably shouldn't > be attempting to interpret legal documents -- especially not for other > people. Similarly, if you're not a programmer, attempting to interpret > program source code is a risky business. Programmers are especially > susceptible to trying to interpret legal documents using a normal dictionary > because they're logical thinkers. That doesn't always work. If you have legal > questions about the implication of documents, you should ask a lawyer, not a > mailing list. > > * Similarly, any comment by one of Linden's lawyers in this forum or any > other could possibly be treated as legally binding. That also goes for Linden > employees, especially those with any seniority. So you're unlikely to get > further remarks or "clarifications", except general statements that don't > address specific questions. The policy was revised based on comments on this > list and elsewhere. That's probably a pretty good indication that Linden > Lab's lawyers now think it's clear enough to state its intent and to stand up > in court if they need it to. > > Q > > On Mar 21, 2010, at 12:55 PM, Carlo Wood wrote: > >> On Sun, Mar 21, 2010 at 05:04:58PM +0100, Tayra Dagostino wrote: >>> maybe we cannot sync this isn't a restriction against development >>> based on GPL, is a restriction against ability to connect LL grid with >>> a 3rd party viewer... >> >> No it's not. If that were the case it would say "User", not "Developer". >> Also, I don't read "you will not be able to connect", I read "you will >> be liable for any damages". Quite a different thing. > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Third party viewer policy: commencement date
So any software that implements SLUDP is a TPV, and subject to you policy? Because if it *can* log into SL, and someone *does* one day log into SL, then it's "any third-party software client on any device that logs into our servers"? If so, in effect, the TPV policy governs all SL protocols? Cheers, On Sun, Mar 21, 2010 at 8:46 PM, Joe Linden wrote: > I'll have a longer reply for several responses here tomorrow, but please > note the definition of a Third Party Viewer in the policy document states > "By “Third-Party Viewer,” we mean any third-party software client on any > device that logs into our servers that support Second Life." There is no > restriction on the GPL implied or intended. > > -- joe > > On Sun, Mar 21, 2010 at 11:39 AM, Argent Stonecutter > wrote: >> >> On 2010-03-21, at 11:04, Tayra Dagostino wrote: >> > >> > maybe we cannot sync this isn't a restriction against development >> > based on GPL, is a restriction against ability to connect LL grid with >> > a 3rd party viewer... >> >> Then it should say "you can not connect to the grid with a viewer that >> does XYZ", not "you can not distribute a viewer that does XYZ". >> >> ___ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Third party viewer policy: commencement date
So for any malicious viewer developer, all he needs to do to avoid sanction under the TPV policy is claim his viewer has no intention of connecting to SL? Or are you admitting that you cannot create a terms of use/service policy that somehow obligates viewer developers to jump though your hoops? You should separate the obligations of users and developers, and make clear the punishments for non-compliance for each. As it is, one would be prudent to assume LL reserves the right to take direct legal action against developers, which is quite frankly scary for small open source developers. Cheers, On Sun, Mar 21, 2010 at 9:19 PM, Joe Linden wrote: > No, it only governs viewers that actually do connect to the SL grid, not > those that are capable of doing so (but don't.) > > On Sun, Mar 21, 2010 at 11:59 AM, Ryan McDougall wrote: >> >> If so, in effect, the TPV policy governs all SL protocols? >> > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Third party viewer policy: commencement date
On Sun, Mar 21, 2010 at 9:53 PM, Joe Linden wrote: > As I've stated repeatedly, the TPV policy governs viewers that connect to Law cannot govern viewers, only humans; in this case developers and users. Mashing them up together and repeating the same thing doesn't make you any more clear. > the SL grid. The policy document as worded is explicit about the > requirements for developers and for users of TPVs that connect to the SL > grid. Developers don't connect to grids, viewers do at the behest of users. As it stands (your previous email withstanding) developers are legally responsible for their users when implementing SLUDP. Explicitness is apparently no evidence of clarity. > That probably sums up what I have to say about it today, so I'm only > admitting that I'm going to use the rest of this Sunday to get some fresh > air. Enjoy the weather. Cheers, > Cheers, > -- joe > > On Sun, Mar 21, 2010 at 12:47 PM, Ryan McDougall wrote: >> >> So for any malicious viewer developer, all he needs to do to avoid >> sanction under the TPV policy is claim his viewer has no intention of >> connecting to SL? >> >> Or are you admitting that you cannot create a terms of use/service >> policy that somehow obligates viewer developers to jump though your >> hoops? >> >> You should separate the obligations of users and developers, and make >> clear the punishments for non-compliance for each. >> >> As it is, one would be prudent to assume LL reserves the right to take >> direct legal action against developers, which is quite frankly scary >> for small open source developers. >> >> Cheers, >> >> On Sun, Mar 21, 2010 at 9:19 PM, Joe Linden wrote: >> > No, it only governs viewers that actually do connect to the SL grid, not >> > those that are capable of doing so (but don't.) >> > >> > On Sun, Mar 21, 2010 at 11:59 AM, Ryan McDougall >> > wrote: >> >> >> >> If so, in effect, the TPV policy governs all SL protocols? >> >> >> > > > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Third party viewer policy: commencement date
Although the text of the TPV policy doesn't mention this, to protect developers who don't want their viewer to be subject to the unnamed penalties of said policy, Joe himself has said the following: "[The TPV policy] only governs viewers that actually do connect to the SL grid, not those that are capable of doing so (but don't.)" I'm not sure how reassured I should be. The thing I don't get is why LL gets to use all these fancy legalisms to protect themselves, but when we get nervous about it, they reply "hey, don't be suspicious -- assume we mean well!" Sorry but when you play the legalism game, drawing lines in the sand, saying "we have to protect ourselves" -- it cuts both ways. This should have been a consultation process to begin with, not a big ol' lawyering up, then push it out the door effective Apr 30th. Cheers, On Mon, Mar 22, 2010 at 1:44 PM, Carlo Wood wrote: > I'd like to see this question answered, too. > > On Sun, Mar 21, 2010 at 06:08:58PM +0200, Ryan McDougall wrote: >> The policy deeply confuses users and developers together, making it >> appear to me that "users" can place "developers" in violation of your >> policy against their will. >> >> Let me explain: >> >> Let's say I develop a client expressly designed to log into OpenSim >> for example. Because of protocol compatibility, this client is >> incidentally capable of logging into SL. If a user decides to to just >> that, he is *clearly* a "User of Third Party Viewer". However, has he >> just made me a "Developer of Third Party Viewer"? I see no language >> that protects me from your policy. >> >> I've no interest in using LL's servers or enabling LL's business >> model. I don't want to agree to the TVP. Has OpenSim's historical >> choice of protocol placed it under LL's legal domain? If not, what >> section of your policy protects me? >> >> Sincerely, >> Ryan > > -- > Carlo Wood > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Third party viewer policy: commencement date
, even if that means ones viewer starts a nuclear war >>>> against former Soviet Russia or China or both. That clause is included in >>>> every single file of sourcecode (not the part about the Russians or Chinese >>>> ). LL explicitely disclaims any liability themselves for the resulting >>>> world >>>> war but then puts exactly that liability back on the shoulders of anyone >>>> developing a viewer. >>>> >>>> Not only that, by complying to their TPV a developer would also accept >>>> universal responsibility for all and everything "viewer". To be exact, as a >>>> developer "You assume all risks, expenses, and defects of any Third-Party >>>> Viewers that you use, develop, or distribute." A viewer does not even need >>>> to be able or connect to SL for that. >>>> >>>> In this regard it does not matter if a JohnDoe Linden comments on a >>>> mailing list or if a legally not binding FAQ tells us that this would be >>>> only for usage by connecting to the SL grid. It is not. TPV in it's current >>>> form says "I'm responsible (read: guilty) for using, developing or >>>> distributing any 3rd party viewer". >>>> >>>> Already by simply developing I'm assuming full responsibility for >>>> everything. I could take the official LL sources and compile and distribute >>>> a sourcewise identical "official" viewer, without changing a single line of >>>> code; but with all the bugs and vulnerabilities *made by LL*. Guilty by >>>> TPV. >>>> It's really ridiculous. >>>> >>>> This is a clear violation of the in the first place by LL required GPL >>>> licensing. It puts further restrictions on developers GPL explicitly >>>> prohibits. >>>> >>>> Another point of concern, putting up the RL details (which is pointless >>>> as LL has them already and require them by ToS) is required for a listing >>>> in >>>> the viewer directory. The details of the two guinea pigs who registered >>>> (Kirsten's, Metabolt) were promptly published for a day before someone in >>>> LL >>>> pressed the emergency button. But that was not the first time that LL >>>> distributed private details. >>>> >>>> In summary, the policy is legal-technical flawed and not acceptable by >>>> any dev in their right mind. What it will achieve is the destruction of any >>>> *legal* 3rd party viewer; which probably is the (by some welcomed) goal of >>>> LL to close-source the viewer. It will not do anything to stop malicious >>>> clients to flourish, the Neils give a shit on policies or licenses. >>>> >>>> The consequence is that no 3rd party developer that uses LL's GPLed >>>> sources (including already registered KLee or famed Emerald) can produce a >>>> legitimate viewer that is either compliant to GPL and/or violates TPV >>>> (which >>>> says it must be GPL compliant). Both are mutually exclusive and LL created >>>> a >>>> nice legal chicken and egg scenario. >>>> >>>> In my opinion there are only 3 possible solutions: >>>> 1) use LL's code and violate TPV >>>> 2) create a viewer from scratch using BSD or another license and comply >>>> to TPV >>>> 3) stop developing 3rd party viewers >>>> >>>> Linden Lab already said they do not plan to update their policy again. >>>> Therefore only option 3 remains. >>>> >>>> Luv, >>>> Boy >>>> >>>> >>>> >>>> - Original Message - >>>> From: Joe Linden >>>> To: Ryan McDougall >>>> Cc: Argent Stonecutter ; Boy Lane ; opensource-dev@lists.secondlife.com >>>> Sent: Monday, March 22, 2010 3:53 AM >>>> Subject: Re: [opensource-dev] Third party viewer policy: commencement >>>> date >>>> As I've stated repeatedly, the TPV policy governs viewers that connect >>>> to the SL grid. The policy document as worded is explicit about the >>>> requirements for developers and for users of TPVs that connect to the SL >>>> grid. >>>> >>>> That probably sums up what I have to say about it today, so I'm only >>>> admitting that I'm going to use the rest of this Sunday to get some fresh >>>> air. >>>> >>>> Cheers, >>>> -- joe >>>> >>>> On Sun, Mar 21, 2010 at 12:47 PM, Ryan McDougall >>>> wrote: >>>>> >>>>> So for any malicious viewer developer, all he needs to do to avoid >>>>> sanction under the TPV policy is claim his viewer has no intention of >>>>> connecting to SL? >>>>> >>>>> Or are you admitting that you cannot create a terms of use/service >>>>> policy that somehow obligates viewer developers to jump though your >>>>> hoops? >>>>> >>>>> You should separate the obligations of users and developers, and make >>>>> clear the punishments for non-compliance for each. >>>>> >>>>> As it is, one would be prudent to assume LL reserves the right to take >>>>> direct legal action against developers, which is quite frankly scary >>>>> for small open source developers. >>>>> >>>>> Cheers, >>>>> >>>>> On Sun, Mar 21, 2010 at 9:19 PM, Joe Linden wrote: >>>>> > No, it only governs viewers that actually do connect to the SL grid, >>>>> > not >>>>> > those that are capable of doing so (but don't.) >>>>> > >>>>> > On Sun, Mar 21, 2010 at 11:59 AM, Ryan McDougall >>>>> > wrote: >>>>> >> >>>>> >> If so, in effect, the TPV policy governs all SL protocols? >>>>> >> >>>>> > >>>> >>>> >>>> ___ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>> >> > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] A note on preserving "NO WARRANTY" for SL TPV developers
You're out of your mind if you recommend people spend their spare time working on something under no more protection than "good faith". LL has lawyered themselves up nicely; who's legal advice are you taking? SCO was unable to destroy linux because Novell got their rights written down quite clearly and unambiguously. Even then, with the weight of evidence so *clearly* in Novell's favor, the fight itself has cost Novell millions and literally destroyed SCO. And that's the sort of liability you want individuals to bear? Get bent. Seriously. I look forward to you establishing a legal defense fund for TPV developers. Until then... On Wed, Mar 31, 2010 at 10:51 PM, Dirk Moerenhout wrote: > Any written words can be read with good or bad faith. Obviously > several of you want to find the most damning interpretation of the TPV > regardless of whether it's actually plausible or not that any court > would accept such an interpretation. If you look at it that way > there'll never be a good way of wording it, all words can be twisted > and misinterpreted. > > Let's take one of the most used examples: > "You assume all risks, expenses, and defects of any Third-Party > Viewers that you use, develop, or distribute. Linden Lab shall not be > responsible or liable for any Third-Party Viewers." > > According to many this supposedly implies that you are responsible for > what people do with your viewer even in extreme conditions. > > First off I'm a bit disappointed by the fact that some quote only the > first sentence and not the second. It should be clear that they are a > union regardless of the dot inbetween. The goal is clear: LL wants to > assure they are not liable for the Third-Party Viewers. Now let's go > on and see how you can "fix" the issues you see. > > For starters if we go back to the first sentence it already states > that you are responsible for the third-party viewers you use. So > you're freed already (as a developer) from any risks, expenses and > defects that impact the use of your third-party viewer by others. It's > literally there, isn't it? > > Furthermore the fact that you assume the risks, expenses and defects > and accept LL is not liable does not restrict you in passing it on. As > we've already seen it's clearly in the TPV that the user assumes all > risks, expenses and defects when he's using the client anyway. So if > you want to be really sure you just have to refer the user to the TPV > and make clear he understands he has assumed all risks, expenses and > defects as a user. > > So to get back to a recent example. Ron states: > "Also if some black hat alters for example Imprudence's or Emerald's > Import/Export feature to ignore ownership the developer team can be > held legally responsible because even though the Import/Export feature > was altered, it was still their code at the core and by the TPVP > agreed to take on that liability." > > I fail to see where you got that: > - You did not develop it as the code in its original form is ok > - You did not distribute it > - You did not use it > > Even in the far fetched situation somebody would try to push for > misinterpretation you must realise that the TPV supports the correct > interpretation by discussing the prohibited features and > functionalities. In that part of the TPV they detail clear enough how > an export function can work without breaking any rules. As such if you > do follow those rules there's little reason to believe that you face > liabilities as you can easily prove that your functionality was > considered to be fine for the TPV. > > I think some of you would've had great careers back when witch hunting > was a popular sport ... > > Best Regards, > > Dirk > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] new TOS - TPV "legally" binding. :/
On Thu, Apr 1, 2010 at 12:29 PM, Lawson English wrote: > Gareth Nelson wrote: >> You're always welcome to not accept the TOS and thus lose all >> your inworld assets >> >> On Wed, Mar 31, 2010 at 4:58 PM, Lawson English wrote: >> >>> Lance Corrimal wrote: >>> just had a little popup shoving the new TOS under my nose, and behold, with accepting the TOS you also accept the TPV. ___ >>> I wonder if that's even legal... >>> >>> >>> > Well, my point is that a click-through agreement with side-effects that > no-one understands doesn't sound like a particularly binding agreement > or even an agreement at all. > > I mean, LL could put in: "when you agree to this you are agreeing to the > provision that your First Born will be sacrificed to FSM at our > convenience," if they wanted to, or any other reference to any other > future situation that has no relevance to the main intent of the EULA... > > > This doesn't sound sufficiently focused to stand up in a court of law. > > > Lawson Right, we could argue about LL's "good will" or whether which clauses would stand up in court -- the point is do *you* want to be the one to put your life on hold to test your legal theories out? Even if you're right you're screwed! This is the clearest signal yet that there is no SL "ecosystem" nor will there ever be, and anyone not directly contributing to LL's business model should develop for OpenSim. Cheers, ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Can you legally agree to incomprehensible conditions?
On Fri, Apr 2, 2010 at 3:44 AM, Kent Quirk (Q Linden) wrote: > 1) The first line of my comment is that I don't speak for Linden legal. Right. > 2) What I said was that if you want to understand legalese, you should talk > to a lawyer. That's it. Seriously, how many developers can realistically to do that? That said, I find the language TPVP itself is pretty clear. The only confusing part is how you can make it apply to *developers* somehow. Totally unprecedented; the GPL applies to the source, and the TOS apply to anyone who connects to SL -- what on earth has LL legal given birth to here? FUD own-goal. > > Q Cheers, > > > On Apr 1, 2010, at 4:54 AM, Gareth Nelson wrote: > >> An interesting point: >> If a member of staff at LL is basically saying "none of you can >> comprehend this policy", then that surely means none of us can >> actually consent to agree to it. >> >> Q - you may have just provided some "fuel" for use in any future court case >> >> On Thu, Apr 1, 2010 at 8:42 AM, Morgaine >> wrote: >>> On 21st March, Q Linden explained to us that legalese is not a language >>> amenable to "common sense" interpretation, and more specifically, that >>> programmers like ourselves should not expect to understand this Linden TPV >>> policy document using our normal logic and our normal dictionary. I'll >>> repeat his words here for clarity: >>> >>> >>> Kent Quirk (Q Linden) q at lindenlab.com >>> Sun Mar 21 10:24:13 PDT 2010 >>> >>> I'm emphatically not a lawyer and I don't speak for our legal team. But: >>> >>> Legalese is a specialized language. It's not strictly English, and it's not >>> always amenable to "common sense" interpretation. Think of lawyers as people >>> who write code in an underspecified language for a buggy compiler, and you >>> begin to understand why legalese is the way it is. There's a lot of law that >>> isn't stated, but is actually implied by the context of the existing settled >>> law. What that means is that if you're not a lawyer, you probably shouldn't >>> be attempting to interpret legal documents -- especially not for other >>> people. Similarly, if you're not a programmer, attempting to interpret >>> program source code is a risky business. Programmers are especially >>> susceptible to trying to interpret legal documents using a normal dictionary >>> because they're logical thinkers. That doesn't always work. If you have >>> legal questions about the implication of documents, you should ask a lawyer, >>> not a mailing list. >>> >>> Similarly, any comment by one of Linden's lawyers in this forum or any other >>> could possibly be treated as legally binding. That also goes for Linden >>> employees, especially those with any seniority. So you're unlikely to get >>> further remarks or "clarifications", except general statements that don't >>> address specific questions. The policy was revised based on comments on this >>> list and elsewhere. That's probably a pretty good indication that Linden >>> Lab's lawyers now think it's clear enough to state its intent and to stand >>> up in court if they need it to. >>> >>> Q >>> >>> >>> I've been thinking about this extraordinary post and its relationship to our >>> ongoing saga about the TPV, and I fail to see how any rational person could >>> agree to something unknown, except under duress. Is it even legal to be >>> required to agree to the incomprehensible? Does anyone know how the law >>> works in this area? >>> >>> The GPL license was written by FSF lawyers specifically to be understood by >>> programmers, so it's no surprise that the large majority of people here >>> understand it. Given that Lindens claim that they are issuing a valid GPL >>> license, perhaps one might accept that at face value, and assume that GPLv2 >>> clauses 6, 7, 11 and 12 remain intact and valid. Therefore there are no >>> "further restrictions" imposed on SL TPV developers (clause 6), and the "NO >>> WARRANTY" clause (11-12) continues to protect developers from downstream >>> liability, and no "conditions are imposed on you that contradict the >>> conditions of this License" thus making the license valid (clause 7). >>> >>> Given the forgoing, the officially incomprehensible TPV document then no >>> longer matters to SL TPV developers, because their rights and freedoms and >>> lack of liability are determined entirely by the GPL. (It could be no other >>> way anyway, since we are told that we cannot understand the TPV.) >>> >>> That leaves only the matter of users of TPVs behaving responsibly when they >>> use TPV clients in SL, with which I'm sure every person on this list is >>> happy to agree. (Note that developers become users when they connect to SL, >>> and are bound by the same requirements as users.) When users do something >>> bad with a TPV client, or indeed with a Linden client, then naturally they >>> are personally responsible for their actions. >>> >>> In the absence of a TPV document that we can comprehend, pe
