No subject


Fri Feb 5 05:04:03 PST 2010


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


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

The reason why the GPL has this very clear clause is to preserve the
unfettered operation of the development chain:  modify-distribute, next
person takes, modify-distribute, next person takes, modify-distribute, ....
etc.  Without this, everyone in the chain would be subject to the initial
creator's usage restrictions, whether or not they actually use the program.
Distro developers would not be able to fix security holes and then
distribute the fixed versions.  Nobody would be able to take the sources,
adapt them to other uses and distribute them, for the same reason.  The
whole GPL ecosystem would stop working through originator-imposed
restrictions on developers.

This is why clause 6 is so strongly worded.  You may not impose further
restrictions on the developers of a GPL-license program if you want to
continue using the GPL.



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

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


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

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

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



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

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


An export permission bit is not required before export of open-licensed
content can be done.  We don't have an export permission bit in RL, and yet
open licensing works just fine.  As Fleep pointed out
earlier<https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000405.html>,
SL creators are already open-licensing their products right now, since it is
so important for Education.

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

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

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

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


Morgaine.






=======================================

On Sun, Feb 28, 2010 at 1:31 AM, Soft Linden <soft at lindenlab.com> wrote:

> On Sat, Feb 27, 2010 at 12:47 AM, Morgaine
> <morgaine.dinova at googlemail.com> wrote:
> >
> > Q2: Does the policy limit use of the viewer source code that Linden Lab
> > makes available under the GPL?
> > A2: No, the policy is not intended to and does not place any restriction
> on
> > modification or use of our viewer source code that we make available
> under
> > the GPL.  Rather, the policy sets out requirements for connecting to our
> > Second Life service using a third-party viewer, regardless of the viewer
> > source code used.
> >
> > This looks great at first glance as it appears to make the separation
> > between developers and users that caused so much confusion in TPV v1.
> >
> > But notice that the answer says "does not place any restriction on
> > modification or use", and then goes on to say "Rather, the policy sets
> out
> > requirements for connecting".  Well connecting IS use, it couldn't be
> > anything else, so the answer contradicts itself in one and the same
> > paragraph. Such ambiguities need to be removed.
>
> It's important to understand that one can discontinue use of Second
> Life at any point. On doing so, there are no further obligations
> imposed by the TPV policy. The legal consults cleared this as a
> resolution to all free license issues.
>
> This agreement makes no restrictions on what anyone can do with the
> source. The GPL makes no restrictions on connecting to Second Life.
> These are two separate agreements, and don't need to be reconciled in
> such a way that each permits everything allowed by the other.
>
> That said, Linden Lab intends to keep the viewer platform under an
> open source license. If anyone ever received a request to alter the
> viewer in a way that would violate the GPL, point that out. Odds are
> the request isn't being communicated properly, or somebody didn't know
> of the implications. Again though - any request is just that. A change
> isn't required if the viewer author chooses to instead stop using it
> to connect to the service and withdraws it from the Viewer Directory.
>
>
> > Next, FAQ.12:
> >
> > Q12:  I develop for a Linux distribution where there is no opportunity to
> > present users with the disclosures required under section 1.c before the
> > user downloads and installs the software.  How can I comply with section
> 1.c
> > of the policy?
> > A12: For Linux distributions where there is no opportunity to provide the
> > section 1.c disclosures before installation of the software, you can
> comply
> > with the requirement by having your software client present the required
> > disclosures or a link to them in a dialogue box that the user must close
> > before logging into Second Life for the first time through your software.
> >
> > You can't require that of developers of GPL software.  It's a restriction
> on
> > a GPL developer's "freedom to modify and distribute", and is explicitly
> > prohibited in GPLv2 clause 6.  Please check the GPLv2 FAQ for the example
> of
> > the original BSD advertising clause, which was incompatible with the GPL.
> > That advertising clause had to be removed from GPL programs before they
> > could be licensed using GPL, because it was an additional restriction on
> the
> > freedom to modify and distribute.
>
> Anyone can make a derivative viewer that doesn't comply with the
> policy. That version of the viewer would not be eligible for inclusion
> in the Viewer Directory. The situation here is similar. Nothing is
> prohibited in terms of use of the GPL licensed code. The restriction
> is strictly placed on participation in the Viewer Directory.
>
>
> > And finally, FAQ.15 (in the context of licenses permitting free
> > distribution):
> >
> > Q15: Do the limitations of section 2.b on content export apply to content
> > that is full permissions?
> > A15: Yes, they do.  Residents retain intellectual property rights in the
> > content they create in Second Life and it is important for you to respect
> > those rights.  By setting content to "full permissions" using the Second
> > Life permissions system, a content creator merely indicates that the
> content
> > may be copied, modified, and transferred within Second Life.  Setting
> > content to "full permissions" does not provide any permission to use the
> > content outside of Second Life.
> >
> > This is fine (surprise, surprise :P), but incomplete.  It doesn't address
> > the quite common scenario of full-perm content created by Open Source or
> > Creative Commons developers using 100% personal textures, and accompanied
> by
> > a GPL, BSD, CC or other open source license which declares that the
> content
> > may be freely copied, modified, and transferred anywhere, not only within
> > Second Life.
> >
> > As is written in the answer A15, "Residents retain intellectual property
> > rights in the content they create in Second Life and it is important for
> you
> > to respect those rights."  Respecting their rights in this case requires
> you
> > to to allow that content to be exported as its creator desires.
> Therefore
> > you either need to extend A15 with this additional case, or add another
> FAQ
> > Q+A (preferably immediately after #15) to address it.
>
> That might be material for the FAQ. But because there is no export
> permission bit, it's not possible to add export capability for these
> cases without enabling violation of others' content. At this point, I
> couldn't see that affecting the TPV policy.
>

--0016e6d96d2846fc990480ab2a5a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Sun, Feb 28, 2010 at 1:31 AM, Soft Linden <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:soft at lindenlab.com" target=3D"_blank">=
soft at lindenlab.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt =
0.8ex; padding-left: 1ex;">

<div>
<br>
</div>It&#39;s important to understand that one can discontinue use of Seco=
nd<br>
Life at any point. On doing so, there are no further obligations<br>
imposed by the TPV policy. The legal consults cleared this as a<br>
resolution to all free license issues.<br></blockquote><div><br><br>It is n=
ot a resolution to all free license issues at all, not even close.=A0 They&=
#39;re just not reading the words of the license.<br><br>GPLv2 clause 6 all=
ows no &quot;further restrictions&quot; to be placed on the freedom of deve=
lopers to <i>&quot;modify and distribute</i>&quot; whatsoever, regardless o=
f whether the USAGE of that GPL software is constrained or not.=A0 The GPL =
has no interest is how software is used to connect to a service in the slig=
htest.=A0 You can constrain USAGE of code for service access as much as you=
 like, you can ban whomever or whatever you like, and it&#39;s completely i=
mmaterial to the GPL.=A0 The two things are entirely separate.=A0 The GPL i=
s not a usage license.<br>

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

<br>This is unambiguous in the GPL.=A0 Make them read it again.=A0 Make the=
m read the GPLv2 FAQ too.<br>=A0<br>Restrictions on connection are perfectl=
y acceptable!=A0 But that&#39;s not what you&#39;re doing, because your cla=
uses directly target developers, not merely permitted usage.=A0 &quot;A vie=
wer may not do XYZ when it connects to the SL service&quot; is totally fine=
 --- the GPL couldn&#39;t care less.=A0 &quot;A developer of this GPL code =
must do ABC if it is distributed&quot; is not fine --- it&#39;s in direct c=
onflict with the GPL&#39;s &quot;modify and distribute&quot; freedoms.<br>
<br><br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px s=
olid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
This agreement makes no restrictions on what anyone can do with the<br>
source. The GPL makes no restrictions on connecting to Second Life.<br>
These are two separate agreements, and don&#39;t need to be reconciled in<b=
r>
such a way that each permits everything allowed by the other.<br></blockquo=
te><div><br><br>That would be an excellent position to take, but you are no=
t taking it.=A0 You persist in laying requirements on DEVELOPERS, in direct=
 non-compliance with GPLv2 clause 6.=A0 And you keep mentioning &quot;devel=
opers&quot; when you mean &quot;users&quot;, in reference to connection to =
your service.=A0 Your warning that developers who distribute their modified=
 viewers will have to register with you is an utterly massive additional re=
striction on the freedom to modify and distribute that is at the heart of t=
he GPL (all versions), as are requirements for self-identification and prog=
ram modification at your request.=A0 The GPLv2 FAQ that I linked earlier gi=
ves an example of such an &quot;additional restriction&quot; being non-comp=
liant, despite being a tiny restriction compared to any of yours.<br>

<br>I think your lawyers must have little experience with the GPL, so I&#39=
;m glad to hear that you&#39;re obtaining additional expert advice external=
ly.=A0 I hope you&#39;re not going to Microsoft for that &quot;expert advic=
e on GPL&quot;. :P=A0 I recommend that you involve the FSF or the SFLC.<br>

=A0<br>This is something that you have to resolve, and it can&#39;t be reso=
lved if you maintain your current position imposing restrictions on GPL dev=
elopers.=A0 All that will happen is that your GPL non-compliance will escal=
ate, until eventually it hits the top and you are forced to either drop the=
 GPL or alter your restrictions to fall exclusively on users, not on GPL de=
velopers.<br>

<br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
That said, Linden Lab intends to keep the viewer platform under an<br>
open source license. If anyone ever received a request to alter the<br>
viewer in a way that would violate the GPL, point that out. Odds are<br>
the request isn&#39;t being communicated properly, or somebody didn&#39;t k=
now<br>
of the implications. Again though - any request is just that. A change<br>
isn&#39;t required if the viewer author chooses to instead stop using it<br=
>
to connect to the service and withdraws it from the Viewer Directory.<br></=
blockquote><div><br><br>You&#39;re still mixing up restrictions on usage wi=
th restrictions on developers.=A0 To not fall foul of this, you really need=
 to separate the issue into two categories:<br>
<ol><li>Restrictions on development and distribution:=A0 none, as per the G=
PLv2.</li><li>Restrictions on connection to SL and usage of SL:=A0 anything=
 you like.<br></li></ol><br>You cannot impose any <i>further restrictions</=
i> on GPL developers <b>at all</b>.=A0 From GPLv2:<br>

<br><ul><li><b>6.</b>
 Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions.  <b>You may not impose any further
restrictions on the recipients&#39; exercise of the rights granted herein.<=
/b>
You are not responsible for enforcing compliance by third parties to
this License.
</li></ul><br>Clause 6 is not at all hard to understand, so it rather looks=
 like your lawyers are trying desperately hard to ignore the words and inte=
ntions of the GPL license.=A0 Make them read the GPLv2 FAQ, it provides a c=
lear example of not being allowed to impose further restrictions on develop=
ers beyond those stated in the GPL.=A0 That clause is central to preserving=
 the developer&#39;s freedoms under the GPL.<br>

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

<br>This is why clause 6 is so strongly worded.=A0 You may not impose furth=
er restrictions on the developers of a GPL-license program if you want to c=
ontinue using the GPL.<br><br>
<br><br>
&gt; Next, FAQ.12:<br>
&gt;<br>
&gt; Q12:=A0 I develop for a Linux distribution where there is no opportuni=
ty to<br>
&gt; present users with the disclosures required under section 1.c before t=
he<br>
&gt; user downloads and installs the software. =A0How can I comply with sec=
tion 1.c<br>
&gt; of the policy?<br>
&gt; A12: For Linux distributions where there is no opportunity to provide =
the<br>
&gt; section 1.c disclosures before installation of the software, you can c=
omply<br>
&gt; with the requirement by having your software client present the requir=
ed<br>
&gt; disclosures or a link to them in a dialogue box that the user must clo=
se<br>
&gt; before logging into Second Life for the first time through your softwa=
re.<br>
&gt;<br>
&gt; You can&#39;t require that of developers of GPL software.=A0 It&#39;s =
a restriction on<br>
&gt; a GPL developer&#39;s &quot;freedom to modify and distribute&quot;, an=
d is explicitly<br>
&gt; prohibited in GPLv2 clause 6.=A0 Please check the GPLv2 FAQ for the ex=
ample of<br>
&gt; the original BSD advertising clause, which was incompatible with the G=
PL.<br>
&gt; That advertising clause had to be removed from GPL programs before the=
y<br>
&gt; could be licensed using GPL, because it was an additional restriction =
on the<br>
&gt; freedom to modify and distribute.<br>
<br>
</div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb=
(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Anyone can make a derivative viewer that doesn&#39;t comply with the<br>
policy. That version of the viewer would not be eligible for inclusion<br>
in the Viewer Directory. The situation here is similar. Nothing is<br>
prohibited in terms of use of the GPL licensed code. The restriction<br>
is strictly placed on participation in the Viewer Directory.<br></blockquot=
e><div><br><br>Your FAQ.4 gives clear warning that participation in the Vie=
wer Directory &quot;may&quot; become a requirement for being allowed to dis=
tribute modified sources --- you would not have said that if it wasn&#39;t =
desired by you and hence planned.=A0 That is the first &quot;further requir=
ement&quot; that conflicts with GPLv2 clause 6, and then your requirement t=
hat developers divulge personal details and modify their programs at your c=
ommand are two more.<br>

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

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

<br><br><br>
&gt; And finally, FAQ.15 (in the context of licenses permitting free<br>
&gt; distribution):<br>
&gt;<br>
&gt; Q15: Do the limitations of section 2.b on content export apply to cont=
ent<br>
&gt; that is full permissions?<br>
&gt; A15: Yes, they do.=A0 Residents retain intellectual property rights in=
 the<br>
&gt; content they create in Second Life and it is important for you to resp=
ect<br>
&gt; those rights.=A0 By setting content to &quot;full permissions&quot; us=
ing the Second<br>
&gt; Life permissions system, a content creator merely indicates that the c=
ontent<br>
&gt; may be copied, modified, and transferred within Second Life. =A0Settin=
g<br>
&gt; content to &quot;full permissions&quot; does not provide any permissio=
n to use the<br>
&gt; content outside of Second Life.<br>
&gt;<br>
&gt; This is fine (surprise, surprise :P), but incomplete.=A0 It doesn&#39;=
t address<br>
&gt; the quite common scenario of full-perm content created by Open Source =
or<br>
&gt; Creative Commons developers using 100% personal textures, and accompan=
ied by<br>
&gt; a GPL, BSD, CC or other open source license which declares that the co=
ntent<br>
&gt; may be freely=A0copied, modified, and transferred anywhere, not only w=
ithin<br>
&gt; Second Life.<br>
&gt;<br>
&gt; As is written in the answer A15, &quot;Residents retain intellectual p=
roperty<br>
&gt; rights in the content they create in Second Life and it is important f=
or you<br>
&gt; to respect those rights.&quot;=A0 Respecting their rights in this case=
 requires you<br>
&gt; to to allow that content to be exported as its creator desires.=A0 The=
refore<br>
&gt; you either need to extend A15 with this additional case, or add anothe=
r FAQ<br>
&gt; Q+A (preferably immediately after #15) to address it.<br>
<br>
</div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb=
(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
That might be material for the FAQ. But because there is no export<br>
permission bit, it&#39;s not possible to add export capability for these<br=
>
cases without enabling violation of others&#39; content. At this point, I<b=
r>
couldn&#39;t see that affecting the TPV policy.<br>
</blockquote></div><br><br>An export permission bit is not required before =
export of open-licensed content can be done.=A0 We don&#39;t have an export=
 permission bit in RL, and yet open licensing works just fine.=A0 As Fleep =
<a href=3D"https://lists.secondlife.com/pipermail/opensource-dev/2010-Febru=
ary/000405.html">pointed out earlier</a>, SL creators are already open-lice=
nsing their products right now, since it is so important for Education.<br>

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

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

<br>Or are you only going to respect the rights of those creators who shore=
 up the walls of your walled garden?=A0 I would prefer to believe that your=
 support is for all content creators&#39; rights and wishes.<br><br>How you=
 respond will reveal the truth of the matter.=A0 If you make it clear that =
building upon the openly and legally-licensed content of others is a ToS or=
 TPV violation, then you are not respecting the rights and wishes of open c=
reators.=A0 My suggested new FAQ.16 or similar would let you &quot;do the r=
ight thing&quot; and be a good citizen of the open license community.<br>

<br><br>Morgaine.<br><br><br><br><br><br><br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D<br><br><div class=3D"gmail_quote">On Sun, Feb 28, 2010 at 1:31=
 AM, Soft Linden <span dir=3D"ltr">&lt;<a href=3D"mailto:soft at lindenlab.com=
" target=3D"_blank">soft at lindenlab.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Sat, Feb 27, 2=
010 at 12:47 AM, Morgaine<br>
<div>&lt;<a href=3D"mailto:morgaine.dinova at googlemail.com" target=3D"_blank=
">morgaine.dinova at googlemail.com</a>&gt; wrote:<br>
&gt;<br>
</div><div>&gt; Q2: Does the policy limit use of the viewer source code tha=
t Linden Lab<br>
&gt; makes available under the GPL?<br>
&gt; A2: No, the policy is not intended to and does not place any restricti=
on on<br>
&gt; modification or use of our viewer source code that we make available u=
nder<br>
&gt; the GPL. =A0Rather, the policy sets out requirements for connecting to=
 our<br>
&gt; Second Life service using a third-party viewer, regardless of the view=
er<br>
&gt; source code used.<br>
&gt;<br>
&gt; This looks great at first glance as it appears to make the separation<=
br>
&gt; between developers and users that caused so much confusion in TPV v1.<=
br>
&gt;<br>
&gt; But notice that the answer says &quot;does not place any restriction o=
n<br>
&gt; modification or use&quot;, and then goes on to say &quot;Rather, the p=
olicy sets out<br>
&gt; requirements for connecting&quot;.=A0 Well connecting IS use, it could=
n&#39;t be<br>
&gt; anything else, so the answer contradicts itself in one and the same<br=
>
&gt; paragraph. Such ambiguities need to be removed.<br>
<br>
</div>It&#39;s important to understand that one can discontinue use of Seco=
nd<br>
Life at any point. On doing so, there are no further obligations<br>
imposed by the TPV policy. The legal consults cleared this as a<br>
resolution to all free license issues.<br>
<br>
This agreement makes no restrictions on what anyone can do with the<br>
source. The GPL makes no restrictions on connecting to Second Life.<br>
These are two separate agreements, and don&#39;t need to be reconciled in<b=
r>
such a way that each permits everything allowed by the other.<br>
<br>
That said, Linden Lab intends to keep the viewer platform under an<br>
open source license. If anyone ever received a request to alter the<br>
viewer in a way that would violate the GPL, point that out. Odds are<br>
the request isn&#39;t being communicated properly, or somebody didn&#39;t k=
now<br>
of the implications. Again though - any request is just that. A change<br>
isn&#39;t required if the viewer author chooses to instead stop using it<br=
>
to connect to the service and withdraws it from the Viewer Directory.<br>
<div><br>
<br>
&gt; Next, FAQ.12:<br>
&gt;<br>
&gt; Q12:=A0 I develop for a Linux distribution where there is no opportuni=
ty to<br>
&gt; present users with the disclosures required under section 1.c before t=
he<br>
&gt; user downloads and installs the software. =A0How can I comply with sec=
tion 1.c<br>
&gt; of the policy?<br>
&gt; A12: For Linux distributions where there is no opportunity to provide =
the<br>
&gt; section 1.c disclosures before installation of the software, you can c=
omply<br>
&gt; with the requirement by having your software client present the requir=
ed<br>
&gt; disclosures or a link to them in a dialogue box that the user must clo=
se<br>
&gt; before logging into Second Life for the first time through your softwa=
re.<br>
&gt;<br>
&gt; You can&#39;t require that of developers of GPL software.=A0 It&#39;s =
a restriction on<br>
&gt; a GPL developer&#39;s &quot;freedom to modify and distribute&quot;, an=
d is explicitly<br>
&gt; prohibited in GPLv2 clause 6.=A0 Please check the GPLv2 FAQ for the ex=
ample of<br>
&gt; the original BSD advertising clause, which was incompatible with the G=
PL.<br>
&gt; That advertising clause had to be removed from GPL programs before the=
y<br>
&gt; could be licensed using GPL, because it was an additional restriction =
on the<br>
&gt; freedom to modify and distribute.<br>
<br>
</div>Anyone can make a derivative viewer that doesn&#39;t comply with the<=
br>
policy. That version of the viewer would not be eligible for inclusion<br>
in the Viewer Directory. The situation here is similar. Nothing is<br>
prohibited in terms of use of the GPL licensed code. The restriction<br>
is strictly placed on participation in the Viewer Directory.<br>
<div><br>
<br>
&gt; And finally, FAQ.15 (in the context of licenses permitting free<br>
&gt; distribution):<br>
&gt;<br>
&gt; Q15: Do the limitations of section 2.b on content export apply to cont=
ent<br>
&gt; that is full permissions?<br>
&gt; A15: Yes, they do.=A0 Residents retain intellectual property rights in=
 the<br>
&gt; content they create in Second Life and it is important for you to resp=
ect<br>
&gt; those rights.=A0 By setting content to &quot;full permissions&quot; us=
ing the Second<br>
&gt; Life permissions system, a content creator merely indicates that the c=
ontent<br>
&gt; may be copied, modified, and transferred within Second Life. =A0Settin=
g<br>
&gt; content to &quot;full permissions&quot; does not provide any permissio=
n to use the<br>
&gt; content outside of Second Life.<br>
&gt;<br>
&gt; This is fine (surprise, surprise :P), but incomplete.=A0 It doesn&#39;=
t address<br>
&gt; the quite common scenario of full-perm content created by Open Source =
or<br>
&gt; Creative Commons developers using 100% personal textures, and accompan=
ied by<br>
&gt; a GPL, BSD, CC or other open source license which declares that the co=
ntent<br>
&gt; may be freely=A0copied, modified, and transferred anywhere, not only w=
ithin<br>
&gt; Second Life.<br>
&gt;<br>
&gt; As is written in the answer A15, &quot;Residents retain intellectual p=
roperty<br>
&gt; rights in the content they create in Second Life and it is important f=
or you<br>
&gt; to respect those rights.&quot;=A0 Respecting their rights in this case=
 requires you<br>
&gt; to to allow that content to be exported as its creator desires.=A0 The=
refore<br>
&gt; you either need to extend A15 with this additional case, or add anothe=
r FAQ<br>
&gt; Q+A (preferably immediately after #15) to address it.<br>
<br>
</div>That might be material for the FAQ. But because there is no export<br=
>
permission bit, it&#39;s not possible to add export capability for these<br=
>
cases without enabling violation of others&#39; content. At this point, I<b=
r>
couldn&#39;t see that affecting the TPV policy.<br>
</blockquote></div><br>

--0016e6d96d2846fc990480ab2a5a--


More information about the opensource-dev mailing list