Re: [opensource-dev] Client-side scripting in Snowglobe
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 ___ Policies 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 topic: Snowglobe 2.0 way forward?
I agree, the new UI needs a LOT of work before I consider it mainstream worthy. As was said the old UI was pretty much tailored by developers for developers. This new UI seems to be tailored in the opposite direction making the viewer barely usable for those of us accustomed to the old UI and content developers. The tweaks found at http://wiki.secondlife.com/wiki/Viewer_2_Tweaks definitely improve things, but we really need a middle ground for end users and developers instead of a UI tailored for either extreme. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Wed, Mar 10, 2010 at 1:20 PM, Mike Monkowski wrote: > Except for Merov's contributions, I don't think Snowglobe ever had a > planned direction. The direction was just the sum of the contributions > people made to it. And I expect it will continue that way. If someone > thinks that chat needs to be fixed and they have the time to fix it, > then they probably will. The real question is whether such a > contribution would be accepted. I happen to think it would be dangerous > to reject such a contribution. > > Mike > > Argent Stonecutter wrote: > > Where is Snowglobe 2.0 going with this? Where SHOUDL it go? Should it > > simplify the interface (or allow it to be simplified), restoring the > > sim name and location to the title bar, cleaning up the chat and > > message boxes, and so on? > ___ > Policies 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 topic: Snowglobe 2.0 way forward?
To be honest the MonoVida does it right. If you're gonna detach the UI from the world it should be completely detached not just over lapping the world. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Wed, Mar 10, 2010 at 4:47 PM, Martin Spernau wrote: > Am 10.03.2010 um 22:35 schrieb Tigro Spottystripes: > > IMO, windows that are on top of the view like a Heads Up Display feel > > more like they're part of the world, like they are in the same place > > as > > i am, while a bar that makes the world view smaller makes it feel like > > the world view is just a screen showing images on a panel with a bunch > > of controls in it. > > It's interesting then that many of the alternate metaverse viewers try > to fully decouple the UI (chat boxes, imventory etc) completly from > the world view window to the point where they are separate windows > (while the Sl viewer still has it 'all in one wndow'). > Seen with this view of 'immersion' that seem like not so good an idea... > Thanks for bringing this up, it got me thinking about a few concepts I > had. > > -Martin > ___ > Policies 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] Snowglobe 2.0^H^H^H1.3 way forward?
You've pretty much hit the nail on the head. Though personally I think the sidebar could work if it was actually multiple smaller side bars that didn't change the aspect ratio every time you opened vs one big one that changes everything. After all I don't need access to my profile and other controls when I'm just trying to check my friends list. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Fri, Mar 12, 2010 at 12:25 PM, Argent Stonecutter < secret.arg...@gmail.com> wrote: > On 2010-03-12, at 10:59, Soft Linden wrote: > > Porting the desired parts of the old UI forward to 2.x would be a lot > > easier than porting ongoing 2.x features backward to 1.3. I wouldn't > > be surprised if you found there were just a couple dialogs you really > > wanted back. Bring the old communicate window back and embed the > > sidebar items in stand-alone floaters? You might even be able to get > > the latter part into Snowglobe if it's minimally invasive and done as > > a preference option. > > The only thing that worries me about this approach is that there's a > lot of fine-tuning in the UI details of the old interface, like the > focus behavior of the chat bar, that seem to be hard to make work > consistently moving forward without a lot of hacking... based on how > easily it seems to be to break it. This isn't just a feature, it's an > all-over behavior. > > Here's things I consider pretty much key: > > * chat bar focus > * chat bar size > * simple chat overlay (single background element, no badges, etc) > * Location *on title bar* so you can get rid of the browser-style bars > * IMs in a window. REALY in a window. > * chat bar on chat floater > * No sidebar > > What have I missed? > ___ > Policies 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] Snowglobe Mecurial Repository
Then why Hg over Git? Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Fri, Mar 19, 2010 at 8:19 AM, Jonathan Irvin wrote: > If I'm not mistaken, Hg is distributed like Git. > > Jonathan Irvin > > > > On Fri, Mar 19, 2010 at 05:12, Carlo Wood wrote: > >> What is the advantage again of hg (over svn)? (why the move) >> >> On Thu, Mar 18, 2010 at 05:18:54PM -0700, Dzonatas Sol wrote: >> >It would >> > be the wrong impression, further, to assume the same committers will >> > take on the extra load to help move to hg. >> >> -- >> 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 >> > > > ___ > Policies 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
Actually a TPV is GPL code. The core of the viewer and all additions to the code are subject to the GPLv2. Your comment in that regards doesn't make much sense. The TPV Policy is about what can and can't connect the the grids owned and operated by Linden Lab, more so then in-world content as we can all agree that the sections on Prohibited Features and IP Rights are No Brainer clauses all of us for the most part respect. Also I don't understand what you mean by uploading broken content. The problem those of us who contribute to TPV's (I contributed to Meerkat and now Imprudence if you wanted to dispute whether or not I actually contribute anything) is basically what was summarized by the Imprudence Viewer team: http://bit.ly/d2KxvI . If we agree with the TPVP we pretty much have to alter our TPV at the Lindens' whims for whatever reason they can find. 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. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Wed, Mar 31, 2010 at 1:28 PM, Dzonatas Sol wrote: > Since the updated TPV, there doesn't seem any indication that LL wants > to restrict or take away rights granted by the GPL. In fact, it > compliments the GPL to further narrow the difference in liabilities > between content and software. > > LL doesn't seem to want to be liable for an obvious non-GPL written > program that connects to the SL grid. A non-GPL program is obviously a TPV. > > Why should anybody want a TPV that uploads broken content to SL grid? > So, to not connect to SL grid and only connect to other worlds is the > answer some concluded on how to not upload broken content to SL grid. > > L. Christopher Bird wrote: > > On Wed, Mar 31, 2010 at 10:06 AM, Gareth Nelson > > mailto:gar...@garethnelson.com>> wrote: > > > > > > LL as copyright holder (or joint holder) can change the GPL with > extra > > restrictions as much as they like - so long as they make it clear. > > > > > > Sure they can, but they must call this license something OTHER than > > GPL. If they want to restrict freedoms granted by the GPL, then it > > ceases to be GPL and becomes a new beast. Licensing under GPL which LL > > has done in the past gives developers certain rights in the use of > > that code.� Some freedoms and rights that the TPV curtails. > > > > LL is free to license their code however they want. What they can't do > > is gut the parts of GPL they disagree with and still call it GPL. > > > > By licensing the viewer under GPL and the preamble to the TPV seems to > > indicate this is their desire to continue to do so, implies a certain > > promise to allow certain things to be done with the software.� If LL > > wants to restrict or take away rights granted by the GPL THEY MUST NOT > > CALL THEIR LICENSE GPL OR USE THE GPL PREAMBLE IN THEIR LICENSE. > > > > http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL > > > > �-- ZenMondo > > > > > > > > ___ > > Policies 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] Brown-bag meeting to continue dialog on TVPV
I'm afraid that won't work. The ToS is an agreement between you (the user) and Linden Lab, not your avatar and LL. Personally I think a meeting such as this where many won't be involved due to the wording of the ToS and TPVP are preventing major TPV devs from entering this discussion would be better suited on a non-LL controlled grid. Maybe one of the other opensim grids would be a better choice. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Fri, Apr 9, 2010 at 8:43 AM, Simon Disk wrote: > 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 > ___ Policies 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] Viewers in the directory are being impersonated already
Whether or not these tools are long term effective is irrelevant. The fact these tools exist is simply the point Dale was trying to make. The whole TPVP is a "Feel Good" Policy to delude residents into believing Linden Lab can prevent the criminal element from having the tools to grief or violate IP/CopyRight and keep them out. Despite the fact copybot and proxy hacks like God Mode have been around longer then the OS viewer, many residents blame the OS viewer for making such acts possible which all of us old timers who paid attention and all of us OS developers/contributors know isn't the case. As Real Life has proven over and over again, no Law or Policy will prevent criminals from obtaining the tools they need to commit crime and only hurt legitimate residents in the end. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Mon, Apr 12, 2010 at 11:00 PM, Rob Nelson wrote: > Certain griefer viewers already bypass this form of profiling. I won't > detail how. > > Fred Rookstown > > On Mon, 2010-04-12 at 16:03 -0700, Erik Anderson wrote: > > Yah, but it might start looking a bit suspicious if it looks like > > you're using computers as one-time pads, always using a different > > system for each connection for a certain account? Might not be as > > easily detectable for the short-term accounts that get banned within > > minutes, but anything with history would stick out fairly obviously. > > > > On Mon, Apr 12, 2010 at 2:07 PM, Dale Glass > > wrote: > > В сообщении от Вторник 13 апреля 2010 00:52:48 вы написали: > > > There's still other facets. For example, the approved > > viewers get some > > > publicity and reputation by being on the approved viewers > > page, and it > > > makes people think that much harder about using sketchy > > viewers to do > > > sketchy things. (And yeah, they have to do one extra > > sketchy thing, as > > > Thomas mentions.) > > > > I don't think it makes a big difference. > > > > I'm talking about a group with a "FOR THE LULZ!" motto. I > > don't think they > > care much about keeping any account of theirs for very long. > > > > > > > > (As an aside, connecting from the same account and/or same > > IP with random > > > MACs seems pretty obviously strange and detectable. There's > > a few more > > > hoops left to jump through there.) > > > > That will take some work though. At my house there are 5 > > computers that could > > run a SL client, that's 5 MACs, all behind the same NATed IP > > address. Schools, > > workplaces, cafes, etc could have hundreds of legitimate ones. > > > > > > ___ > > Policies 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
Re: [opensource-dev] Viewers in the directory are being impersonated already
That is correct. Phillip Linden made the same arguments when he was still CEO/President of the Lab when people like Prokofy cried and demanded LL take action to proactively prevent criminal activity on the grid especially when it involves IP rights. Its a truth that Phillip recognized that authority figures like Linden Lab can only *react to criminal activity as it happens and its impossible to truly prevent it.* The TPVP is more or less an example of a clear cut distinction between M's and Phillip's management styles. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Tue, Apr 13, 2010 at 2:06 PM, Erik Anderson < eri...@odysseus.anderson.name> wrote: > I've heard Linden Labs make this exact same argument multiple times in the > past in response to resident reaction over this, so I'm fairly sure that > they are very fully aware of this fact. > > 2010/4/13 Ron Festa > > Whether or not these tools are long term effective is irrelevant. The fact >> these tools exist is simply the point Dale was trying to make. The whole >> TPVP is a "Feel Good" Policy to delude residents into believing Linden Lab >> can prevent the criminal element from having the tools to grief or violate >> IP/CopyRight and keep them out. Despite the fact copybot and proxy hacks >> like God Mode have been around longer then the OS viewer, many residents >> blame the OS viewer for making such acts possible which all of us old timers >> who paid attention and all of us OS developers/contributors know isn't the >> case. As Real Life has proven over and over again, no Law or Policy will >> prevent criminals from obtaining the tools they need to commit crime and >> only hurt legitimate residents in the end. >> >> Ron Festa >> Virtual Worlds Admin >> Division of Continuing Studies at Rutgers University >> PGP key: http://bit.ly/b1ZyhY >> Phone: 732-474-8583 >> >> > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Requesting Linden Response: Please move TPVP Topics to a different mailing list
I feel your frustration, however, this is the *opensource-dev* mailing list *not* the *snowglobe-dev* mailing list. Both SnowGlobe and TPV's are open source viewers based on Linden Lab's mainline viewer the only difference is Snowglobe is distributed by LL. Discussion on policies that effect open source development should be encouraged. If you only want to see stuff relating to SnowGlobe then either encourage LL create a snowglobe-dev list or configure your mail filters to only allow email related to snowglobe to enter your inbox from this list. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Wed, Apr 14, 2010 at 8:52 AM, Jonathan Irvin wrote: > To Whom It May Concern: > > I'm requesting Linden Lab's response to this inquiry due to the recent > influx of new topic related...or should I say unrelated to the development > of the SnowGlobe viewer. Lately, when I open my email, I get 5-10 different > topics and responses daily to the recent changes for the Third Party Viewer > policy and I feel that this is not related to SnowGlobe or related > development at all. > > To "clear the pipes", can we please move these discussions to a different > forum or list so valid OpenSource development questions are not lost in the > flames, complaints, and discussions related to this specific topic? > > I do not feel it is valid in this forum to talk about which Third-Party > Viewers in the directory were already impersonated or which part of the > third party viewer policy they do not like. > > Linden Labs, if you can please isolate this to another forum, I bet those > who are truly interested in the opensource development of the Second Life > viewer would be more in tuned to staying here rather than wake up to read > yet another unproductive "I hate LL and the TPVP lets get together and share > our misery post". > > Respectfully & Best Regards, > > Jonathan Irvin > SL Resident of 5 Years. > > ___ > Policies 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] Fwd: [gnu.org #566095] Possible Licensing Conflict
Since people wanted to see it here it is right from the Free Software Foundation. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 -- Forwarded message -- From: Brett Smith via RT Date: Tue, Apr 20, 2010 at 1:00 PM Subject: [gnu.org #566095] Possible Licensing Conflict To: ronfe...@docs.rutgers.edu > [ronfe...@docs.rutgers.edu - Thu Apr 15 12:02:18 2010]: > > Company name: Linden Research, Inc > Product: Second Life Viewer > Contact Info: http://lindenlab.com/contact > > <http://lindenlab.com/contact>Possible Violation: The Second Life Viewer is > released completely under the GPLv2 with exception to the commercial binary > blobs which have been replaced with opensource equivalents. Recently they > have released a Third Party Viewer Policy (TPVP) in regards to viewers made > from their source code that connect to their service. In this policy, > section 7a appears to be in conflict with sections 11 & 12 of the GPLv2 in > which their source code is licensed under. Ron, Thanks for getting in touch with us with your concerns. It's always good to know that people like you take the GPL seriously enough to ask these sorts of questions. My understanding is that Linden Labs' Third-Party Viewers Policy, despite the name, sets out policies for connecting to Second Life's own servers. Other services might call this kind of policy a Terms of Service. This statement from the policy's preamble explains their intent: "This Policy 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, and for participating in our Viewer Directory." The freedoms granted by the GPL and other free software licenses are never absolute -- they are limited by law and other legal agreements. For example, just because the license allows you to use the software for any purpose does not mean you are allowed to use it to DoS a server, or undertake other illegal activities. Linden Labs has the right to set policies for clients connecting to its servers, and that is what it has done with this policy. They do not put direct limits on the freedoms you have under the GPL: viewers that don't follow the policies could be used to connect to alternative servers as they become available, to make an entirely new game, or in completely unrelated projects. I am sympathetic to concerns that some of these policies may have chilling effects on development of third party viewer applications, but the policies are not in any inherent, direct conflict with the GPL's terms. I hope this helps clear up our position on the matter for you. If you have other concerns, please feel free to contact us. Best regards, -- Brett Smith Licensing Compliance Engineer, Free Software Foundation ___ Policies 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: [gnu.org #566095] Possible Licensing Conflict
As Joe explained in the brown bag currently going on at the time of this writing, you'd be required to end distributing the version that connects to SL. In other words you will be required to remove support for SL. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Tue, Apr 20, 2010 at 3:51 PM, Jason Giglio via RT wrote: > I don't think Brett fully considered the implications of: > > "You acknowledge and agree that we may require you to stop using or > distributing a Third-Party Viewer for accessing Second Life if we > determine that there is a violation." > > Which is clearly in conflict with the GPL. > > Ron Festa wrote: > > Since people wanted to see it here it is right from the Free Software > > Foundation. > > > > Ron Festa > > Virtual Worlds Admin > > Division of Continuing Studies at Rutgers University > > PGP key: http://bit.ly/b1ZyhY > > Phone: 732-474-8583 > > > > > > -- Forwarded message -- > > From: *Brett Smith via RT* mailto:licens...@fsf.org > >> > > Date: Tue, Apr 20, 2010 at 1:00 PM > > Subject: [gnu.org <http://gnu.org> #566095] Possible Licensing Conflict > > To: ronfe...@docs.rutgers.edu <mailto:ronfe...@docs.rutgers.edu> > > > > > > > [ronfe...@docs.rutgers.edu <mailto:ronfe...@docs.rutgers.edu> - Thu > > Apr 15 12:02:18 2010]: > > > > > > Company name: Linden Research, Inc > > > Product: Second Life Viewer > > > Contact Info: http://lindenlab.com/contact > > > > > > <http://lindenlab.com/contact>Possible Violation: The Second Life > > Viewer is > > > released completely under the GPLv2 with exception to the commercial > > binary > > > blobs which have been replaced with opensource equivalents. Recently > they > > > have released a Third Party Viewer Policy (TPVP) in regards to viewers > > made > > > from their source code that connect to their service. In this policy, > > > section 7a appears to be in conflict with sections 11 & 12 of the > > GPLv2 in > > > which their source code is licensed under. > > > > Ron, > > > > Thanks for getting in touch with us with your concerns. It's always > > good to know that people like you take the GPL seriously enough to ask > > these sorts of questions. > > > > My understanding is that Linden Labs' Third-Party Viewers Policy, > > despite the name, sets out policies for connecting to Second Life's own > > servers. Other services might call this kind of policy a Terms of > > Service. This statement from the policy's preamble explains their intent: > > > > "This Policy 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, > > and for participating in our Viewer Directory." > > > > The freedoms granted by the GPL and other free software licenses are > > never absolute -- they are limited by law and other legal agreements. > > For example, just because the license allows you to use the software > > for any purpose does not mean you are allowed to use it to DoS a > > server, or undertake other illegal activities. > > > > Linden Labs has the right to set policies for clients connecting to its > > servers, and that is what it has done with this policy. They do not put > > direct limits on the freedoms you have under the GPL: viewers that don't > > follow the policies could be used to connect to alternative servers as > > they become available, to make an entirely new game, or in completely > > unrelated projects. I am sympathetic to concerns that some of these > > policies may have chilling effects on development of third party viewer > > applications, but the policies are not in any inherent, direct conflict > > with the GPL's terms. > > > > I hope this helps clear up our position on the matter for you. If you > > have other concerns, please feel free to contact us. > > > > Best regards, > > > > -- > > Brett Smith > > Licensing Compliance Engineer, Free Software Foundation > > > > > > > > > > > > ___ > > Policies 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: [gnu.org #566095] Possible Licensing Conflict
I just noticed that the email licens...@fsf.org is being replied to. Guys please remove that email address from your ReplyToAll list to avoid spamming the FSF. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Tue, Apr 20, 2010 at 4:00 PM, Tayra Dagostino wrote: > On Tue, 20 Apr 2010 15:51:04 -0400 > Gigs wrote: > > > I don't think Brett fully considered the implications of: > > > > "You acknowledge and agree that we may require you to stop using or > > distributing a Third-Party Viewer for accessing Second Life if we > > determine that there is a violation." > > > > Which is clearly in conflict with the GPL. > > no, it is related to LL serrvices, not software license, "for accessing > second life", it si a limitation related to the use WITH LL servers > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer blacklist to replace the TPV directory ?
> > > This would be only true if LL was to *guarantee* that the listed viewer > can *actually* be trusted, which is *not* the case with the current > implementation of teh TPV directory. > > The current TPV directory is a list of certified viewers. Despite claiming the list is Self-Certified those viewers on the list still had to have their viewer reviewed by LL before being listed so really all the TPV's on the TPV Directory are Certified by LL ensuring they comply with their standards & policies. As it stands the TPV Directory is one step away from becoming a full blown White List. > Not when the blacklist in question is edited by LL themselves: you then > are sure that the listed viewers are illegal, which gives more reliable > info than an unwarranted white list... I think you missed Discrete's point. Many have interpreted the TPV Directory as a true White List, which it's not, many will think that any viewer that is *not* on the black list is then safe to use. So for example if Neil Life is on the black list and SuperGriefer Viewer 1.33.7 is not there will be folks who will think SuperGriefer Viewer 1.33.7 is safe to use despite it being a malicious viewer. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 ___ Policies 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] SL on ARM platform
Except there's many problems with the N900 that would have to be overcome. For starters its CPU clock is normally 200mhz below the minimum spec. Even though it can overclock you're going to be depending on pushing the CPU a lot more then what its suppose to operate at which will require additional cooling unless you want to shorten its lifespan. RAM is physically half of the minimum required. Yes you have 1 gig virtually using swap space, but swap is dependent on the memory card which will require a good memory card like a class 6 or better to avoid system lag due to heavy thrashing of swap space. Swap also naturally decreases the life of the memory card and such aggressive thrashing will speed that up. Finally SL is written to use OpenGL, not OpenGL ES which is a totally different beast. To successfully port SL to this device you would have to increase the efficiency of SL's code to run in a lower resource environment and adapt the rendering engine to use OpenGL ES instead otherwise you're looking at a client that would barely run if at all. Naali had the advantage of using a real game engine (ogre) and still being a young ground up project where very few things are set in stone with how it operates. If one has the time, the team, and the dedicated resources to tackle SL's shortcomings on that platform then by all means go for it and keep us updated. Personally though, I feel the Android platform with the newer phones coming out which have more CPU power and RAM would be a better choice to attempt a port (Google does have an NDK that you can use to code in C/C++). Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Wed, Jul 21, 2010 at 8:01 PM, Tigro Spottystripes < tigrospottystri...@gmail.com> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > here is an excerpt from > https://secure.wikimedia.org/wikipedia/en/wiki/Nokia_N900 : > > "The Nokia N900 is powered by a high-end OMAP 3430 ARM Cortex A8 which > is a System-on-a-chip made by Texas Instruments based on a 65-nanometer > CMOS process. The OMAP 3430 is composed of three microprocessors; the > Cortex A8 running at 600 MHz used to run the OS and applications, the > PowerVR SGX 530 GPU made by Imagination Technologies which supports > OpenGL ES 2.0 and is capable of up to 14 MPolys/s and a TMS320C64x, the > digital signal processors, running at 430 MHz used to run the image > processing (camera), audio processing (telephony) and data transmission." > > I've read people managed to overclock the processor up to about 1 GHz, > some people even made it so the clock would change depending on how much > is being demanded from the processor, not only getting better > performance but also increased battery time. > > > On 20/7/2010 14:52, Altair Sythos Memo wrote: > > On Wed, 14 Jul 2010 12:35:01 + (GMT) > > DEEPAK JAIN wrote: > > > > compile on ARM is possible, depending on which operating system you > > want to do. ARM since V4 is basically a 32bit little endian processor > > (latest version big endian 64bit too), a GCC since V2.95 can compile > > ELF binaries. > > > > Using ARM linux you can follow a generic "standalone build" how-to > > (preconf libraries aren't compiled for ARM), but the problem is only > > shifted on performance side. I've worked on Familiar Project to > > 5years ago (ex-compaq linux project on ARM devices) and about all > > application written in a good ANSI C/C++ can be compiled without too > > much pain, the step after is who do all the rendering job. A lot of > > nowadays portable devices (handhelds, smartphone, pdaphone, tablet pc) > > have a "sort of" GPU or graphic co-processor, but very few of them have > > full OpenGL support (I think OpenGL2.1 is the minimum for latest > > viewers), some have only software OpenGL API (ridicolous performance). > > > > some detail more can be usefulkl to answer to your wuestion ;) > > ___ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting > privileges > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.14 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEAREKAAYFAkxHikAACgkQ8ZFfSrFHsmXY5QCeOx7nK9fi7kDXOx2GcSItiFAv > GVMAniN++5PN7mgnGDTLZxfbF6o+jrOg > =RN/k > -END PGP SIGNATURE- > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] User Stories: Water Prims
As a User, I would like the ability to apply a Linden supplied texture or Prim Type flag to turn a prim into Linden Water (such as a cube). This would allow residents to use Linden Water on multiple ground heights on land and in skyboxes. Currently one has to use prim/sculptie water that lacks various shader features, doesn't match up to, and/or looks worse then the Linden Water. As a resident I would like a standard for these kinds of applications. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 ___ Policies 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] WebP, a new image format for the Web
VP8 focuses too much on PSNR which for still photo usage comes out blurrier. Plus Google's ref-spec VP8 is not exactly known for being CPU friendly on encode or decode. Even then they're comparing to standard JPEG, not JPEG2000 which there has yet to be a comparison test of. Even then its an unproven format that so far only shows its better at compression then standard JPEG even when jpgcrunch is used. IMO, its not worth using until the issues are resolved and even then its still got a long way to go for adoption. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Fri, Oct 1, 2010 at 1:15 PM, SuezanneC Baskerville wrote: > Google is putting out a new open source image format, said to offer higher > compression rates than JPEG2000. > > I just thought someone with the appropriate technical knowledge ought to > take a look at in case it might be useful for use in Second Life. > > http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html > > *To improve on the compression that JPEG provides, we used an image >> compressor based on the VP8 codec that Google >> open-sourced<http://blog.webmproject.org/2010/05/introducing-webm-open-web-media-project.html>in >> May 2010. We applied the techniques from VP8 video intra frame coding to >> push the envelope in still image coding. We also adapted a very lightweight >> container based on >> RIFF<http://en.wikipedia.org/wiki/Resource_Interchange_File_Format>. >> While this container format contributes a minimal overhead of only 20 bytes >> per image, it is extensible to allow authors to save meta-data they would >> like to store. >> >> While the benefits of a VP8 based image format were clear in theory, we >> needed to test them in the real world. In order to gauge the effectiveness >> of our efforts, we randomly picked about 1,000,000 images from the web >> (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without >> perceptibly compromising visual quality. This resulted in an average 39% >> reduction in file size. We expect that developers will achieve in practice >> even better file size reduction with WebP when starting from an uncompressed >> image. >> * > > > http://code.google.com/speed/webp/ > -- > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > ___ > Policies 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] WebP, a new image format for the Web
Also forgot to add this link as its a good write up and comparison of x264 vs vp8 vs JPEG w/jpgcrunch for still images: http://x264dev.multimedia.cx/?p=541 Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Fri, Oct 1, 2010 at 1:33 PM, Ron Festa wrote: > VP8 focuses too much on PSNR which for still photo usage comes out > blurrier. Plus Google's ref-spec VP8 is not exactly known for being CPU > friendly on encode or decode. Even then they're comparing to standard JPEG, > not JPEG2000 which there has yet to be a comparison test of. Even then its > an unproven format that so far only shows its better at compression then > standard JPEG even when jpgcrunch is used. IMO, its not worth using until > the issues are resolved and even then its still got a long way to go for > adoption. > > Ron Festa > Virtual Worlds Admin > Division of Continuing Studies at Rutgers University > PGP key: http://bit.ly/b1ZyhY > Phone: 732-474-8583 > > > On Fri, Oct 1, 2010 at 1:15 PM, SuezanneC Baskerville > wrote: > >> Google is putting out a new open source image format, said to offer higher >> compression rates than JPEG2000. >> >> I just thought someone with the appropriate technical knowledge ought to >> take a look at in case it might be useful for use in Second Life. >> >> http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html >> >> *To improve on the compression that JPEG provides, we used an image >>> compressor based on the VP8 codec that Google >>> open-sourced<http://blog.webmproject.org/2010/05/introducing-webm-open-web-media-project.html>in >>> May 2010. We applied the techniques from VP8 video intra frame coding to >>> push the envelope in still image coding. We also adapted a very lightweight >>> container based on >>> RIFF<http://en.wikipedia.org/wiki/Resource_Interchange_File_Format>. >>> While this container format contributes a minimal overhead of only 20 bytes >>> per image, it is extensible to allow authors to save meta-data they would >>> like to store. >>> >>> While the benefits of a VP8 based image format were clear in theory, we >>> needed to test them in the real world. In order to gauge the effectiveness >>> of our efforts, we randomly picked about 1,000,000 images from the web >>> (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without >>> perceptibly compromising visual quality. This resulted in an average 39% >>> reduction in file size. We expect that developers will achieve in practice >>> even better file size reduction with WebP when starting from an uncompressed >>> image. >>> * >> >> >> http://code.google.com/speed/webp/ >> -- >> v i r t u a l w o r l d e n t h u s i a s t >> -- http://www.google.com/profiles/s u e z a n n e -- >> >> ___ >> Policies 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] Fermi Viewer
Visibuild is RealXtend and Naali, not vanilla SL or OpenSIM. Nothing contributed to that would benefit SL or vanilla OpenSIM especially since both SL & OS are getting mesh support. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Mon, Oct 18, 2010 at 10:51 AM, SuezanneC Baskerville wrote: > The "Visibuild" project, at http://visibuild3d.com/, might have some > bearing on this, possibly. > > One might think a viewer and grid that are suposed to be useful for real > world architecture would have some build tools other than the normal. > > It's C++, isn't it, not C? > > > On Mon, Oct 18, 2010 at 9:29 AM, Thomas Grimshaw wrote: > >> Imprudence is certainly not stable enough for a viewer targeted at >> builders. >> >> ~Tom >> >> On 18/10/2010 15:26, Jamey Fletcher wrote: >> > Marc Adored wrote: >> > >> >> Yes that could be awesome like The Fermi Builders Mod for Phoenix or >> > Imprudence? >> > ___ >> > Policies 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 >> > > > > -- > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > ___ > Policies 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
