On Sun, Feb 28, 2010 at 1:31 AM, Soft Linden <s...@lindenlab.com> wrote:
> > 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. > It is not a resolution to all free license issues at all, not even close. They're just not reading the words of the license. GPLv2 clause 6 allows no "further restrictions" to be placed on the freedom of developers to *"modify and distribute*" whatsoever, regardless of whether the USAGE of that GPL software is constrained or not. The GPL has no interest is how software is used to connect to a service in the slightest. You can constrain USAGE of code for service access as much as you like, you can ban whomever or whatever you like, and it's completely immaterial to the GPL. The two things are entirely separate. The GPL is not a usage license. Such *usage* concerns are concerns for the *user* alone --- when a developer connects to SL then she is no longer a developer at that point, but has the role of a user. If you place constraints, requirements or restrictions on the DEVELOPER, such as a requirement for registration, self-identification or code modification at your command, then you are adding "further restrictions" to the developer's freedom to "modify and distribute" and hence you are automatically GPL non-complaint. This is unambiguous in the GPL. Make them read it again. Make them read the GPLv2 FAQ too. Restrictions on connection are perfectly acceptable! But that's not what you're doing, because your clauses directly target developers, not merely permitted usage. "A viewer may not do XYZ when it connects to the SL service" is totally fine --- the GPL couldn't care less. "A developer of this GPL code must do ABC if it is distributed" is not fine --- it's in direct conflict with the GPL's "modify and distribute" freedoms. > 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 would be an excellent position to take, but you are not taking it. You persist in laying requirements on DEVELOPERS, in direct non-compliance with GPLv2 clause 6. And you keep mentioning "developers" when you mean "users", in reference to connection to your service. Your warning that developers who distribute their modified viewers will have to register with you is an utterly massive additional restriction on the freedom to modify and distribute that is at the heart of the GPL (all versions), as are requirements for self-identification and program modification at your request. The GPLv2 FAQ that I linked earlier gives an example of such an "additional restriction" being non-compliant, despite being a tiny restriction compared to any of yours. I think your lawyers must have little experience with the GPL, so I'm glad to hear that you're obtaining additional expert advice externally. I hope you're not going to Microsoft for that "expert advice on GPL". :P I recommend that you involve the FSF or the SFLC. This is something that you have to resolve, and it can't be resolved if you maintain your current position imposing restrictions on GPL developers. All that will happen is that your GPL non-compliance will escalate, 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 developers. > 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. > You're still mixing up restrictions on usage with restrictions on developers. To not fall foul of this, you really need to separate the issue into two categories: 1. Restrictions on development and distribution: none, as per the GPLv2. 2. Restrictions on connection to SL and usage of SL: anything you like. You cannot impose any *further restrictions* on GPL developers *at all*. >From GPLv2: - *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 <s...@lindenlab.com> wrote: > On Sat, Feb 27, 2010 at 12:47 AM, Morgaine > <morgaine.din...@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. >
_______________________________________________ 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
