Hmm. However, with virtual objects the physical properties aren't fixed.
Unlike regular matter, the physical properties of an SL object can
change at any time. In fact - and I grant I only have anecdotal
information to support this - I think it is less likely for an object's
physical properties to
Joel Foner wrote:
> I wonder if anyone has an easy way to calculate the actual signal
> (os-dev posts) to noise (legal posts) ratio on this list over, let's
> say the last 30 days. It's getting hard to recall when the last actual
> os-dev discussion happened. Maybe I'm just missing it.
The lega
VR Hacks wrote:
> Then the TPV policy does not apply to them. Though, again, and imo, it would
> still be prudent for them to include a EULA with their binary distribution.
>
The EULA however in most of the world have no legal meaning, except it
can give the user rights against the developer.
I want to share a use-case/concept for physic simulation where the
client and sever wouldn't have to send object updates, or at least there
wouldn't be as many updates needed to send from the sim to the client.
Given we can use general relativity more as a mutual agreement rather
than assume it
Looking at this mailing list the meeting with Joe did not do anything but put
new oil in the fire. People start the same interpretation of intentions all
over again that were already discussed to death. Intentions were never
questioned. I don't really know what the point is of going through all
Don't go giving LL's lawyers ideas
Seriously, I would not be surprised to find the "IANALP" come out
next, complete with Joe talking about it inworld on voice only
"So, we're here to see how to move forward with people who want to
read any of our policies and dare interpret them - thi
Good idea! We could even have a directory of people qualified to talk about
it who give their RL info so that people show up front which commenters are
trustworthy. Any votes for writing this up as the Commenting on the Third
Party Viewer Policy Policy, or COTTPVPP?
/snark :)
Brent
On Thu, Apr
I also would be interested in seeing those freely offering their legal
advice on this list also describing their qualifications to do so and in
which jurisdictions they are licensed to practice law. If not, then please
add a "IANAL" or other suitable disclaimer, or mention to what level you
would b
Unless I'm mistaken this discussion has been going since almost this list's
entire lifetime...
On Thu, Apr 15, 2010 at 4:04 PM, Joel Foner wrote:
> I wonder if anyone has an easy way to calculate the actual signal (os-dev
> posts) to noise (legal posts) ratio on this list over, let's say the las
I wonder if anyone has an easy way to calculate the actual signal (os-dev
posts) to noise (legal posts) ratio on this list over, let's say the last 30
days. It's getting hard to recall when the last actual os-dev discussion
happened. Maybe I'm just missing it.
Back to my regularly scheduled progra
Fractured is correct regarding Onyx not breaking GPL. That's how LL was able
to legally keep Viewer 2 under wraps for so long.
On Apr 15, 2010 6:13 PM, "Michael Daniel" wrote:
VR Hacks wrote:
>> I mean you can't legally be held liable for users who refuse to follow a
>> cont...
I stand corrected
The TPV has no differentiation between source code and binary. The GPL
requires sourcecode distribution anyway. He's in the wrong and I
suspect he knows it.
Also, to be quite frank, contracts that are designed to be displayed
whenever the user logs into a service should be written so it is clear
VR Hacks wrote:
>> I mean you can't legally be held liable for users who refuse to follow a
>> contract they made with you, can you?
>>
>
> Sure you can. After all, if you write malicious code, you know you're doing
> it.
I stand corrected, then. I wasn't really talking about malicious cod
On Thu, Apr 15, 2010 at 9:38 PM, VR Hacks wrote:
[snip]
> B) Any developer who develops and/or distributes their viewer is
> "responsible" (please note the operative word, responsible) for whatever
> code they've implemented. In other words, it is up to them to a) debug their
> own code, b) write
These comments are beginning to seem rather like pure speculation. If you're
concerned about your project or your liabilities, I recommend consulting
with someone from LL or with your lawyer.
Anyhow, the discussion at hand could use some more focus on what further
modifications would be appreciate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What is considered malicious varies from grid to grid, someone could for
example setup a grid for the sole purpose of figuring out how strong you
can make a grid against attacks, and for the purpose of helping test it
and find new possibilities of atta
Michael wrote in part (full off-list comment is included below sig):
> That means that you can write and distribute anything you please, but if
> you connect to the grid with something like NeilLife and you get caught
> doing it then you will loose your account.
Yup, something to that effect.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(just bouncing back to the list)
- Original Message
Subject: Re: [opensource-dev] Requesting Linden Response: Please move
TPVPTopics to a different mailing list
Date: Thu, 15 Apr 2010 16:06:19 -0400
From: Michael Daniel
To: Tigro Sp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
About that "interesting scenario", the TPVp doesn't seem to care about
how many steps and hands separate the original code you did and what was
used to generate the binary Joe Developer uses to log in SL.
On 15/4/2010 17:19, VR Hacks wrote:
> Tigro Sp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I don't think developers are gonna be happy with LL threatening to kill
their accounts and bring them to court because of their non-SL related
activities.
IMO, LL should restrict their rules to only stuff done by connecting to
their machines; so only
Tigro Spottystripes
> Why developers for other grids would need to do any changes on their
> code? And why can't a SL resident develop clients for other grids while
> keeping their SL accounts safe without being forced to jump thru hoops?
For argument's sake, let's say I, as an SL user, choose to
Devs for other grids that don't need to agree to LL's policy probably
wouldn't have anything to worry about at all, especially if they included
EULAs with the right terms. As for residents, I wouldn't say their account
becomes 'unsafe.' However, my (emphasis on my) interpretation of the policy
is t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Why developers for other grids would need to do any changes on their
code? And why can't a SL resident develop clients for other grids while
keeping their SL accounts safe without being forced to jump thru hoops?
On 15/4/2010 17:00, Discrete Dreamscap
I would assume that, to be more detailed, your code would either not allow
connections to the LL grid, or you would have to decline the updated
ToS/TPVp, thus not agreeing to be bound to it but also preventing you from
using the LL grid yourself.
On Thu, Apr 15, 2010 at 3:58 PM, Tigro Spottystripe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
So any developer not willing to abide by the TPVp can simply say their
viewer is not meant for LL's grid and that is it?
On 15/4/2010 16:54, VR Hacks wrote:
> Tigro wrote:
>
>> What if the developer develops a viewer for other grids?
>
> Then the TP
Tigro wrote:
> What if the developer develops a viewer for other grids?
Then the TPV policy does not apply to them. Though, again, and imo, it would
still be prudent for them to include a EULA with their binary distribution.
And, of course, if their code is extending GPL code, they must retain
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What if the developer develops a viewer for other grids?
On 15/4/2010 16:38, VR Hacks wrote:
> Imo, some people fail to see the TPVp for what it is. To wit:
>
> A) Any and all developers who develop a client for connecting to the second
> life grid
Imo, some people fail to see the TPVp for what it is. To wit:
A) Any and all developers who develop a client for connecting to the second
life grid must adhere to a basic set of rules. To reiterate, the TPV policy
does not just apply to devs extending the lab's code base. To wit:
"This Policy g
"Many coders would likely accept liability when being paid well, or possibly
at all. But in the case of open source code created as a hobby, the GPL idea
of no warranty has so far been successful in the community because code can
be inspected by its users, and because the users can verify, alter, a
The problem with that is a contract requires assent on both sides
On Thu, Apr 15, 2010 at 4:47 PM, Discrete Dreamscape
wrote:
> It's possible to willingly agree to liability and wave whatever protections
> you wish that are normally under the GPL, which seems to be what the TPV
> asks you to do.
It's possible to willingly agree to liability and wave whatever protections
you wish that are normally under the GPL, which seems to be what the TPV
asks you to do. The issue most people seem to have is that it's not explicit
in this regard and it also doesn't make it clear that it is a contract
be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
from what i understand, according to GPL, developers and distributers of
GPL'd stuff are _*NOT*_ liable for any GPL code they create, modify or
distribute
On 15/4/2010 12:28, Robert Martin wrote:
> On Thu, Apr 15, 2010 at 11:01 AM, Gareth Nelson
> w
On Thu, Apr 15, 2010 at 11:01 AM, Gareth Nelson wrote:
> A quick note on that - this is not the whole meeting, some of the
> start was missing
>
suggestion for the next meeting MAKE IT TEXT CHAT ONLY.
how much of the meeting was lost to overhead related to voice links
getting garbled or relaying i
A quick note on that - this is not the whole meeting, some of the
start was missing
On Thu, Apr 15, 2010 at 2:08 AM, VR Hacks wrote:
> Michael wrote in part:
>
>> Is a transcript of this posted anywhere for those of us who could not
>> attend?
>
> I see someone has already posted a link to the fu
Am Mittwoch, 14. April 2010 20:49:59 schrieb Joe Linden:
> **we've had a lot of internal debate around cost/benefit of OS **... and
> we're fully committed to redoubling our commitment to make this a
> successful program*."
then... how about... opensourcing the SERVER (like someone pretty high
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
some TPVs might be released under licenses that do assign
responsibilities, legal liabilities etc to developers and/or
distributers, the TPVP shouldn't attempt to override any license applied
to any TPV
On 15/4/2010 09:13, Aleric Inglewood wrote:
> I
I thought it would make more sense (I still have hope) to say this now,
and not wait till 30 April.
Also I have decided that Linden Lab does not deserve the 40 hours
per week that I spend volunteering on the snowglobe sources.
Lately I have done less because my motivation was gone due to
the polic
37 matches
Mail list logo
