[opensource-dev] A note on preserving "NO WARRANTY" for SL TPV developers
I think I have read a different TPV policy than most people here. I do not see how clauses 11 and 12 are being overridden. Both clauses stipulate that the GPL cannot be used to violate the law. So when you use a TPV and connect to the SL grid and then steal content that you did not create or disrupt Linden Lab's service, those clauses no longer apply 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
Re: [opensource-dev] New TOS - Compulsory patent licensing gone?
Could be wrong but I read the new ToS as lumping patent rights under Intelectual Property Rights and then compelling the user to grant a license under IPR (and therefore also patent rights). Under section 4.1 it defines IPR as: "Intellectual Property Rights" means copyrights, trademarks, service marks, trade dress, publicity rights, database rights, *patent rights*, and other intellectual property rights or proprietary rights recognized by law. Then under section 7.1: You retain any and all *Intellectual Property Rights* you already hold under applicable law in Content you upload, publish, and submit to or through the Servers, Websites, and other areas of the Service, subject to the rights, licenses, and other terms of this Agreement, including any underlying rights of other users or Linden Lab in Content that you may use or modify. Then under 7.2: You agree that by uploading, publishing, or submitting any Content to or through the Servers, Websites, or other areas of the Service, you hereby automatically grant Linden Lab a non-exclusive, worldwide, royalty-free, sublicenseable, and transferable license to use, reproduce, distribute, prepare derivative works of, display, and perform the Content solely for the purposes of providing and promoting the Service. ___ Policies 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] Brown-bag meeting to continue dialog on TVPV
Create an alt account for the sole purpose of attending the Brown-Bag meetings, then cancel the account on April 29, 2010 before the ToS/TPVP become effective. ___ Policies 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] Brown-bag meeting to continue dialog on TVPV
ยง7.7 makes the TPVP effective with the ToS. ___ Policies 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] Brown-bag meeting to continue dialog on TVPV
Why does creating an alt mean your jumping on LL's side? Why are there sides anyway? If it is an important enough issue to you, you should find a way. ___ Policies 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] Brown-bag meeting to continue dialog on TVPV
I understand it, the ToS and associated policies are by account, every alt account you sign in with has to accept them individually. ___ Policies 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] Malicious payloads in third-party viewers: is the policy worth anything?
The login screen and this attack happened before you select the grid. On Sun, Aug 22, 2010 at 8:22 AM, Ann Otoole wrote: > I hate replying to a policy thread here but will make this one time > exception for my humble input for LL's consideration: > > What I think LL should consider is something in the TPV policy that > prohibits any tpv from connecting to any non LL server for any reason when a > LL grid is selected for login. This simple policy, if correctly followed, > would have prevented the incident. It would also eliminate a tpv team from > monitoring logins and usage but then where exactly did they get to do that > in the first place? It is a missed policy bullet. There is no reason a > client should connect to anything except an LL server when an LL grid is > selected. LL needs to be totally security conscious about the login process > and what rigid requirements must be met for connecting to the LL grids. > > I.e.; I watch my port activity. Everyone should. But not everyone would > know what they are looking at. But had they been watching I bet they would > have been wanting to know what all those connections to that host were all > about right away. Had I been using Emerald and saw thirty something > connections to iheartanime dot com appear I would have been raising hell > immediately. What you connect to on the internet can be and is monitored > sometimes and being open to forced connections to something really bad would > be extremely unfortunate for many that have tom be squeaky clean. > > I use Kirstens and I don't even care much for it's connection for motd. > However it does tell me when the latest release is available and that is > very useful information. Maybe there is a way for LL to provide motd bullets > for tpvs so they can get the word out about updates or something. > > There has to be a better way. > > Regards > > Ann Otoole InSL > > -- > *From:* Brian McGroarty > *To:* Thomas Grimshaw > *Cc:* opensource-dev@lists.secondlife.com > *Sent:* Sat, August 21, 2010 10:33:52 AM > > *Subject:* Re: [opensource-dev] Malicious payloads in third-party viewers: > is the policy worth anything? > > On Sat, Aug 21, 2010 at 7:04 AM, Thomas Grimshaw > wrote: > > Loading 1mb of content per user is hardly a denial of service attack. > > Crosslinking occurs everywhere on the web, this is simply nothing but > > paranoid bull. > > "Crosslinking" drops the context of hiding gibberish requests to a > critic's website in a hidden frame that will never be revealed to the > user. This isn't a mere hyperlink to another page or naively stealing > someone else's image hosting. > > My read (but I'm no lawyer) is that this looks like 2.d.iii of > http://secondlife.com/corporate/tpv.php and we're already having that > discussion. If anyone can come up with specific reasons why this might > have had legitimate reason to be there, or how this one could be yet > another oversight or mistake, that would be helpful. I sure haven't > heard any to date. > > -- > Brian McGroarty | Linden Lab > Sent from my Newton MP2100 via acoustic coupler > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies 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] Malicious payloads in third-party viewers: is the policy worth anything?
On Sat, Aug 21, 2010 at 7:48 PM, Phox wrote: > (Since then, all additional metadata information has been removed from > emkdu). > The change in encryption was simply a result of inertia being able to > decode the viewer window title information. > It is my understanding that the emku was placing the hidden viewer window title information into the baked textures. So in one sentence you are saying the information was removed. And in the next you are saying it is still there just encrypted better so others cannot decode it and out you. Which is 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
