Re: [opensource-dev] Open Development project: extendingavatar wearables

[Carlo Wood]

Hi Nyx and list,

I (finally) realized that there IS something that would
be a great improvement of wearables that won't be too hard
to implement :).

I don't have a solution (yet), but let me describe the
problem, and maybe the list can come up with the solution.

I store wearables in folders, and call those "outfits".
However, fact is that I have two different types of
"outfits": clothing, and things that make me myself,
things that belong to the avatar, to the naked avatar
so to speak:

* Hair, AO, earring, shape, eyes, necklace that
  I "never" take off, swimmer, braces, tatoos, skin,
  radar...

The number of things that belong to the "naked" avatar
are quite large in fact.

Outfits can also be pretty large, especially the number
of attachments. Allowing people to wear multiple layers
of pants, shirts and jackets will increase the number
of clothing items too.

Now lets say I have all the base things that belong
to the avatar in a folder "naked", and clothing outfits
in folders "swim outfit", "disco outfit", "samourai outfit"...

Then, when I want to switch from 'disco outfit' to
'swim outfit', there are currently two "paths" one
can take:

1) Click on 'naked' and do "replace outfit", then
   click on 'swim outfit' and do "add to outfit".

this makes me temporarily naked, and is therefore
often not desirable, so that leaves

2) Click on 'swim outfit' and do "add to outfit",
   then click on 'disco outfit' and do "Take off items",
   then click on 'naked' and do "add to outfit".

The last step is needed because some outfits DO
replace some of the 'naked' items.

This method as several disadvantages: it's a lot of
work, I have to find back the folder outfit that I'm
currently wearing, there is the danger that I accidently
click 'replace outfit' in the last step and it causes
often two or three rebakes instead of one.

What I'd like is an improvement here, a way to
switch outfits with a single click.

Does anyone have ideas?

-- 
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

[opensource-dev] Wearing multiple folders at once (was: Open Development project: extendingavatar wearables)

[Boroondas Gupte]

Just wanted to propose this as possible work flow for your task, only to
notice that it's already there:

   1. Select the (maybe already worn) 'naked' folder
   2. Hold down *Ctrl* and click the 'swim outfit' folder to add it to
  the selection
   3. Right click one of the selected folders and choose *Replace Outfit*

Doesn't work for attachments (*), but everything else seems fine. I'm
assuming the expected behaviour would be to have the same effect as
choosing "Replace Outfit" on a hypothetical folder that contained all
the selected folders but nothing else. Still 3 steps, but the final
operation seems as atomic as wearing a single folder.

cheers
Boroondas

(*) When both folders contain attachments, you'll get a message "Cannot
complete attachments. An attachment is pending for that spot", even if
they have different attachment points, and only attachments from one
folder are actually attached.

Interestingly, when selecting just multiple attachments (without the
containing folders) and choosing "wear" from the context menu, you get
the same message and only one will be attached, again even if they have
different attachment points. Right-clicking a folder with several
attachments and choosing "Add To Outfit" works fine, though. (Are there
JIRA entries about these issues, yet?)
___
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] Open Development project: extendingavatar wearables

[Kitty]

> This method as several disadvantages: it's a lot of work, I 
> have to find back the folder outfit that I'm currently 
> wearing, there is the danger that I accidently click 'replace 
> outfit' in the last step and it causes often two or three 
> rebakes instead of one.
> 
> What I'd like is an improvement here, a way to switch outfits 
> with a single click.
> 
> Does anyone have ideas?

Folder links would work fine for that...

Create a folder link to your "Naked" folder inside of both the "Swim outfit"
and "Disco Outfit": when you right-click and "Replace Outfit" from one of
the other LLAppearanceMgr::updateCOF() would follow the folder link inside
of the outfit folder and collect in the items from the "Naked" folder as
well.

Right now it doesn't actually follow folder links but since there is code in
place for it (take a peek at LLInventoryModel::collectDescendentsIf I
think), it's probably on the roadmap *somewhere* :). If not, it probably
shouldn't take that much coaxing to get it working :p.

[Personally I really dislike like the "Outfit concept" though and much
prefer "Add to Outfit" on the new folder followed by a "Remove from Outfit"
on the old folder if need be because it's infinitely more flexible than
being forced to always wear a certain "outfit" one specific way]

Kitty

___
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] Open Development project: extendingavatar wearables

['Carlo Wood']

I like this idea!

To translate it back to it's purest abstract form,
we would like to be able to construct outfits in
an object oriented way: be able to derive an outfit
from other outfits.

The "folder link" would be a pointer to the "base class"
so to speak.

However, we have to solve the following problems:

1) If I'd add a link from every outfit to 'naked',
then right-clicking an outfit folder and selecting
"Remove items" would become pointless (broken).

2) If the derived outfit has an attachment on the
same spot as one of the base outfits, then we need
to make sure that most-derived one prevails. I doubt
that is already functional.

3) Once it is allowed to wear more than one wearable
of the same type, it becomes totally unclear what
you want to do with "add to outfit". I doubt that
in most cases you want to actually only put on extra
shirts and not take off the previous ones.
Combining folders in this object oriented way should
allow to specify if, at the derive level, if a "add"
action should *remove* the items of the same type in
the base outfit(s) (like happens with attachements),
or that you want those to stay, and just add to it.

4) Finally, such way to derive from another outfit
would make it impossible to specify an ordering of
the combined wearables: what to do? Always put all
new shirts in the derived outfit on TOP of the ones
in the base class outfit? Also unclear.

On Mon, Mar 29, 2010 at 04:28:30PM +0200, Kitty wrote:
> > This method as several disadvantages: it's a lot of work, I 
> > have to find back the folder outfit that I'm currently 
> > wearing, there is the danger that I accidently click 'replace 
> > outfit' in the last step and it causes often two or three 
> > rebakes instead of one.
> > 
> > What I'd like is an improvement here, a way to switch outfits 
> > with a single click.
> > 
> > Does anyone have ideas?
> 
> Folder links would work fine for that...
> 
> Create a folder link to your "Naked" folder inside of both the "Swim outfit"
> and "Disco Outfit": when you right-click and "Replace Outfit" from one of
> the other LLAppearanceMgr::updateCOF() would follow the folder link inside
> of the outfit folder and collect in the items from the "Naked" folder as
> well.
> 
> Right now it doesn't actually follow folder links but since there is code in
> place for it (take a peek at LLInventoryModel::collectDescendentsIf I
> think), it's probably on the roadmap *somewhere* :). If not, it probably
> shouldn't take that much coaxing to get it working :p.
> 
> [Personally I really dislike like the "Outfit concept" though and much
> prefer "Add to Outfit" on the new folder followed by a "Remove from Outfit"
> on the old folder if need be because it's infinitely more flexible than
> being forced to always wear a certain "outfit" one specific way]
> 
> Kitty
> 

-- 
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

Re: [opensource-dev] [Linux] Frequent crashes with last Viewer 2 beta release

[Tofu Linden]

Anyone seeing this 100%, please email me your complete
~/.secondlife/logs/SecondLife.log for a crashed session.
Thanks!

Lance Corrimal wrote:
> I'm having a similar experience here.
> 
> Am Sonntag 28 März 2010 schrieb Jonathan Irvin:
>> Approx. how long into your session does it crash? 
> 
> a few seconds.
> 
>> What where you going that made it crash, etc.?
> 
> trying to log in.
> 
> ...happens every time.
> 
> my setup:
> opensuse 11.2, pulseaudio, kde 4.4.1
> the official client (1.23.5) works fine.
> 
> bye,
> LC
> 
> 
> ___
> 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] Wearing multiple folders at once (was: Open Development project: extendingavatar wearables)

[Kitty]

(*) When both folders contain attachments, you'll get a message "Cannot
complete attachments. An attachment is pending for that spot", even if they
have different attachment points, and only attachments from one folder are
actually attached.

Interestingly, when selecting just multiple attachments (without the
containing folders) and choosing "wear" from the context menu, you get the
same message and only one will be attached, again even if they have
different attachment points. Right-clicking a folder with several
attachments and choosing "Add To Outfit" works fine, though. (Are there JIRA
entries about these issues, yet?)

The first seems to be due to an apparant issue with
RezMultipleAttachmentsFromInv: rather than queue them up and process them
one at a time the second message *always* gets rejected with "Attachment
pending" etc if the first one hasn't finished attaching everything yet
(http://jira.secondlife.com/browse/SVC-5383 sort of partly relates).
 
RezSingleAttachmentFromInv (= "Wear") has the same issue (there it only
happens for conflicting attachment points oddly enough): "Cannot attach
multiple objects via wear" (http://jira.secondlife.com/browse/VWR-5063)
 
---
 
You can work around both in the viewer though: in LLFolderView::doToSelected
you "intercept" the actions "addtooutfit", "replaceoutfit" and "attach" and
then handle all selections at the same time instead of one after the other.
 
I can add "Add to/Replace Outfit" to the patch for 2.0 if you (or anyone)
want(s); I've just been waiting to see if LL won't fix it better because
putting LLXXXBridge specific logic into "doToSelected" probably isn't the
best possible way of fixing it viewerside :|.
 
Kitty
___
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] SL2 font problem on linux

[Tofu Linden]

On your system it's trying to load 103 system fonts for full unicode
coverage (on my system it's 43 fonts, which also seems huge so I
never dreamed of testing with 100+).
Not a huge problem in itself, but the current font system is hugely
wasteful of resources and Linux's font autoprobing can return
arbitrarily long lists of fonts.
In the longer term I'd like to make the font system more efficient (it's
currently loading each of these fonts... multiple times each, for
various sizes and styles :( ) but in the short term for Viewer2
I'll limit the fallback font list to something like the top 20 most
useful system fonts.
Thanks for the report!

Tayra Dagostino wrote:
> Every time i try to login SL2 crash due some font trouble, all font
> listed are present and readable by all users in the system...
> 
> somebody else seen this? (if yes i'll opena  JIRA, otherwise i look for
> a local trouble of my linuxbox...)
> 
> 
> 
> 
> ___
> 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] Open Development project: extendingavatar wearables

[Frans]

I might be wrong, but doesn't Viewer 2 already cover some the things you
want? Creating links to other outfits, and putting them all in the new
outfit folder(not sure what it is called, atm). It does put everything
together, so if you buy new hair you would have to redo them, I think.

On Mon, Mar 29, 2010 at 4:53 PM, Carlo Wood  wrote:

> I like this idea!
>
> To translate it back to it's purest abstract form,
> we would like to be able to construct outfits in
> an object oriented way: be able to derive an outfit
> from other outfits.
>
> The "folder link" would be a pointer to the "base class"
> so to speak.
>
> However, we have to solve the following problems:
>
> 1) If I'd add a link from every outfit to 'naked',
> then right-clicking an outfit folder and selecting
> "Remove items" would become pointless (broken).
>
> 2) If the derived outfit has an attachment on the
> same spot as one of the base outfits, then we need
> to make sure that most-derived one prevails. I doubt
> that is already functional.
>
> 3) Once it is allowed to wear more than one wearable
> of the same type, it becomes totally unclear what
> you want to do with "add to outfit". I doubt that
> in most cases you want to actually only put on extra
> shirts and not take off the previous ones.
> Combining folders in this object oriented way should
> allow to specify if, at the derive level, if a "add"
> action should *remove* the items of the same type in
> the base outfit(s) (like happens with attachements),
> or that you want those to stay, and just add to it.
>
> 4) Finally, such way to derive from another outfit
> would make it impossible to specify an ordering of
> the combined wearables: what to do? Always put all
> new shirts in the derived outfit on TOP of the ones
> in the base class outfit? Also unclear.
>
> On Mon, Mar 29, 2010 at 04:28:30PM +0200, Kitty wrote:
> > > This method as several disadvantages: it's a lot of work, I
> > > have to find back the folder outfit that I'm currently
> > > wearing, there is the danger that I accidently click 'replace
> > > outfit' in the last step and it causes often two or three
> > > rebakes instead of one.
> > >
> > > What I'd like is an improvement here, a way to switch outfits
> > > with a single click.
> > >
> > > Does anyone have ideas?
> >
> > Folder links would work fine for that...
> >
> > Create a folder link to your "Naked" folder inside of both the "Swim
> outfit"
> > and "Disco Outfit": when you right-click and "Replace Outfit" from one of
> > the other LLAppearanceMgr::updateCOF() would follow the folder link
> inside
> > of the outfit folder and collect in the items from the "Naked" folder as
> > well.
> >
> > Right now it doesn't actually follow folder links but since there is code
> in
> > place for it (take a peek at LLInventoryModel::collectDescendentsIf I
> > think), it's probably on the roadmap *somewhere* :). If not, it probably
> > shouldn't take that much coaxing to get it working :p.
> >
> > [Personally I really dislike like the "Outfit concept" though and much
> > prefer "Add to Outfit" on the new folder followed by a "Remove from
> Outfit"
> > on the old folder if need be because it's infinitely more flexible than
> > being forced to always wear a certain "outfit" one specific way]
> >
> > Kitty
> >
>
> --
> 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
>



-- 
Jeroen Frans
Virtual World Technology Specialist.
VesuviusGroup.com
SL: Frans Charming
___
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] [Linux] Frequent crashes with last Viewer 2 beta release

[Lance Corrimal]

Hi,

i guess on my system it's the "loads of fonts" problem described in 
another thread, I _do_ have an awful lot of fonts installed here.


bye,
LC

Am Montag 29 März 2010 schrieb Tofu Linden:
> Anyone seeing this 100%, please email me your complete
> ~/.secondlife/logs/SecondLife.log for a crashed session.
> Thanks!
> 
> Lance Corrimal wrote:
> > I'm having a similar experience here.
> > 
> > Am Sonntag 28 März 2010 schrieb Jonathan Irvin:
> >> Approx. how long into your session does it crash?
> > 
> > a few seconds.
> > 
> >> What where you going that made it crash, etc.?
> > 
> > trying to log in.
> > 
> > ...happens every time.
> > 
> > my setup:
> > opensuse 11.2, pulseaudio, kde 4.4.1
> > the official client (1.23.5) works fine.
> > 
> > bye,
> > LC
> > 
> > 
> > ___
> > 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] SL2 font problem on linux

[Tayra Dagostino]

On Mon, 29 Mar 2010 16:58:30 +0100
Tofu Linden  wrote:

> On your system it's trying to load 103 system fonts for full unicode
> coverage (on my system it's 43 fonts, which also seems huge so I
> never dreamed of testing with 100+).
> Not a huge problem in itself, but the current font system is hugely
> wasteful of resources and Linux's font autoprobing can return
> arbitrarily long lists of fonts.
> In the longer term I'd like to make the font system more efficient
> (it's currently loading each of these fonts... multiple times each,
> for various sizes and styles :( ) but in the short term for Viewer2
> I'll limit the fallback font list to something like the top 20 most
> useful system fonts.
> Thanks for the report!

removed quite all fonts, now i have less than 64 fonts... SL2 works
(58 font installed)
___
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] Open Development project: extending avatar wearables

[Nyx Linden]

Forums for discussing multi-wearables and related issues can be found 
here: 
https://blogs.secondlife.com/community/forums/open-source/open-development/multi-wearables

Please re-direct all multi-wearables related conversations there - I'd 
like to keep all discussion centralized so everyone knows where to look 
for the latest info!

 -Nyx

Nyx Linden wrote:
> Greetings Opensource-dev!
>
>This tiny robot is going to be working over the next few weeks to 
> begin working on the next iteration of avatar features, and needs your 
> help!
> We're hoping to continue our overhaul of how you manage your 
> appearance. Since we're shooting for moving towards quarterly 
> releases, there's a lot of work to be done!
>
> I'll be setting up a sub-form for collaboration and discussion of 
> designs, as well as working on cleaning up some initial design 
> concepts for how the user interface will be presented - I'll follow up 
> on this list with links to the documents when they're online.
>
> Some of the features we want to implement:
> 1) A new panel to edit what is stored in your saved outfit without 
> creating a new one.
>This will include both an inventory view and a view of your outfit 
> itself, so you can drag items from your inventory to your outfit 
> without having an extra floater open
> 2) Editing of wearable items (body parts and/or clothing objects) in 
> the sidebar, selectable from the outfit editor
> 3) Removal of the appearance floater
> 4) Order-specific outfits with the ability to re-order wearables as 
> desired
> 5) Ability to wear multiple wearables of the same type (multiple 
> shirts, multiple jackets and yes, multiple alpha masks!).
>
> I look forward to working with everyone and getting a lot of feedback 
> throughout the development process. I'll be releasing a lot more 
> detailed information as I can get it formatted and out the door. There 
> are just a handful of things to keep in mind.
>
> First, this is still a featureset developed by Linden Lab, which has a 
> few implications. If there is a dispute, we will hold final say on 
> what goes into the client we ship. There will not always be perfect 
> consensus on every decision made, but I will try to be more 
> transparent about what decisions we make and why, where appropriate. 
> Also, since the code for this feature will be in the main second-life 
> viewer, we do still require a signed CLA before we can integrate your 
> patches into our codebase.
>
> Second, I ask that we all do what we can to keep the discussion civil 
> and collaborative. The tiny robot cloning machine still isn't working 
> right yet, so there is only one of me and I'll make the time to 
> collaborate with everyone who wants to help with creating a more 
> robust featureset that will ship in the time we have to develop it. 
> Posts for ideas that we don't have the time or resource to implement, 
> rants, or non-constructive feedback will receive significantly less 
> attention.
>
> Once the forums are up, I'll post there with details of what 
> infrastructure is currently in place, what our initial designs are, 
> and how best to give feedback. Once we get our new branch structure in 
> place, I'll be doing all of my checkins in the open and will be 
> pulling in community contributions on a regular basis. I look forward 
> to working with the community on this project and providing a positive 
> examples to encourage other internal projects to work more directly 
> with the community!
>
> -Nyx

___
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] Wearing multiple folders at once (was: OpenDevelopment project: extendingavatar wearables)

[Kitty]

Added a preliminary patch for 2.0 to
http://jira.secondlife.com/browse/VWR-5063 ("Cannot attach multiple objects
via wear") if anyone wants to look it over :).

I tried to avoid actually handling bridge-specific actions in LLFolderView
this time:
  - LLFolderView::doToSelected() groups all selected items by derived class
type
  - for each type "performActionBatch()" is called if more than one item of
that type was selected
(the default implementation just calls "processAction" for each item
like it does now)
  - LLObjectBridge overrides "performActionBatch" and attaches all selected
items at once rather than one at a time (or copies them to inventory first
if they're in the library)

No patch for the "Add to/Remove from Outfit" since it requires quite a bit
of changes to code that is likely to change before the beta cycle is over so
it's not very worthwhile to bother until after release :(.

Kitty

___
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] SL2 font problem on linux

[Glen Canaday]

Oh, wow. I guess I'll be remembering this one. I had no idea on it.

--GC

On 03/29/2010 02:44 PM, Tayra Dagostino wrote:
> On Mon, 29 Mar 2010 16:58:30 +0100
> Tofu Linden  wrote:
>
>
>> On your system it's trying to load 103 system fonts for full unicode
>> coverage (on my system it's 43 fonts, which also seems huge so I
>> never dreamed of testing with 100+).
>> Not a huge problem in itself, but the current font system is hugely
>> wasteful of resources and Linux's font autoprobing can return
>> arbitrarily long lists of fonts.
>> In the longer term I'd like to make the font system more efficient
>> (it's currently loading each of these fonts... multiple times each,
>> for various sizes and styles :( ) but in the short term for Viewer2
>> I'll limit the fallback font list to something like the top 20 most
>> useful system fonts.
>> Thanks for the report!
>>  
> removed quite all fonts, now i have less than 64 fonts... SL2 works
> (58 font installed)
> ___
> 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] A note on preserving "NO WARRANTY" for SL TPV developers

[Morgaine]

In this note I'll identify 3 simple scenarios in which TPV developers can
retain some confidence that the "NO WARRANTY" clauses of their open licenses
remain intact.  This is a technical reading of GPLv2 and similar licenses
which developers can verify for themselves, rather than a legal reading of
the TPV which Q Linden explained was beyond our ability to
understand
.

The 1st of April is approaching rapidly, and April Fool aside, this is also
the date on which the Linden TPV policy comes into effect.

That policy apparently overrides the "NO WARRANTY" clauses 11 and 12 of
GPLv2 *as they apply to TPV developers*, by imposing numerous conditions and
liabilities upon them.  It is important that developers of TPVs realize the
possible personal dangers to themselves that may result from loss of "NO
WARRANTY" protection, so that they can make a personal decision about TPV
development on 1st April and thereafter.  Boy Lane gave a well reasoned summary
of the situation
here
.

To address a small part of the uncertainty created by TPV, I'll make some
simple technical observations on how to preserve the "NO WARRANTY"
protections of your open sources licenses if you are a TPV developer whose
viewers are used in SL by others.  No part of this note is legal advice
(obviously), but under the assumption that law occasionally tries to be
logical, it may help developers separate what is relatively certain from
what is highly uncertain.

*The most important point to appreciate is that LL has no power to void the
"NO WARRANTY" clause on any open source license not issued by them, or
issued by them prior to 1st April 2010.*

This means that the following 3 developer scenarios seem quite safe from the
standpoint of their "NO WARRANTY" clauses surviving any attack:


   - When a viewer project is licensed under BSD, Apache, MIT, GPLv3, LGPL,
   or any other license other than GPLv2, this is clearly not the license
   granted by LL and therefore its "NO WARRANTY" protections cannot be
   overridden by LL.  LL is not the licensor in this case.


   - When a viewer project is an independent project licensed by the
   project's developers under GPLv2 but does not use any Linden source code at
   all, then the license (together with its "NO WARRANTY" freedom) is being
   offered and granted by those developers, and it is clearly not being offered
   and granted by LL.  Consequently LL has no say over the "NO WARRANTY"
   protections provided in a GPLv2 license that is granted by someone else in
   such an independent project.  LL is not the licensor in this case.


   - When a project creates a TPV based on Linden sources released by LL
   under GPLv2 prior to 1st April 2010, those sources are not encumbered by
   LL's TPV document, but instead are licensed under the normal terms of a
   valid GPLv2 *at the time that they were released*.  This is because *GPL
   licenses are non-revocable*, and therefore the entire GPLv2 license
   (including its "NO WARRANTY" clauses) which was valid upon release remains
   valid for all eternity.  As a result, TPV developers are protected by their
   GPLv2 "NO WARRANTY" clauses, as long as they do not use any LL sources
   released on or after 1st April 2010.  LL is the licensor in this case, but
   the GPLv2 "NO WARRANTY" protection was granted to you by Linden Lab
   themselves prior to the TPV possibly affecting it, and that granted license
   cannot be revoked, ever.


In the above 3 cases, LL has no means of overriding the "NO WARRANTY"
protections in the respective licenses.  (Read GPLv2 clauses 11-12 carefully
though, because they protect you only from *certain types* of liability, not
everything.)

In contrast, any other TPV scenarios are highly dependent on interpretation
of the ambiguous TPV document, and hence developer protection under those
conditions is very uncertain.  It would have to be decided in court, and I
would not wish to second guess the outcome.   Much caution is advised, and
even these purely technical observations should be examined carefully, and
followed at your own risk only if you think they are accurate.

I reiterate that the above is not legal advice, but only a technical
analysis given the very well known terms of the major open source licenses.
The GPL is particularly strong, and it has finally received testing in court
in recent years, so relying on its strength to provide "NO WARRANTY"
protection for open source developers is probably a reasonable idea.  On 1st
April, the situation may change though.


Morgaine.






On Thu, Mar 25, 2010 at 6:36 AM, Ryan McDougall  wrote:

> I think it's pretty clear LL will broach no more discussion on this
> matter, as the only people complaining are "non contributors" -- as
> clear a statement yet that realXtend and OpenSim are not consi

Re: [opensource-dev] Open Development project: extending avatar wearables

[Philippe (Merov) Bossut]

Hi,

On Fri, Mar 26, 2010 at 3:31 PM, Joel Foner  wrote:

> This is a pretty generic question, but I hope it will be helpful.
>
> Under what conditions might it be possible to do a fairly quick to
> release version and then iterate the feature behavior towards
> something more sophisticated, without breaking things?
>

Nyx stated he wanted to develop this feature "in the open" which means that
he'll be developing in viewer-internal which is exported on each successful
build (so we avoid those breakage) to viewer-external (see
http://wiki.secondlife.com/wiki/Linden_Lab_Repository_Strategy for naming
conventions).

Now, will the feature be always 100% bug free during the course of
development? I bet it won't but that's the nature of developing a
significant feature in the open. I'm also quite sure that Nyx will do all he
can to make that prediction turn wrong :)

Cheers,
- Merov
___
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

[Maya Remblai]

I thought the TPV policy went into effect on April 30?

Maya

Morgaine wrote:
> In this note I'll identify 3 simple scenarios in which TPV developers 
> can retain some confidence that the "NO WARRANTY" clauses of their 
> open licenses remain intact.  This is a technical reading of GPLv2 and 
> similar licenses which developers can verify for themselves, rather 
> than a legal reading of the TPV which Q Linden explained was beyond 
> our ability to understand 
> .
>
> The 1st of April is approaching rapidly, and April Fool aside, this is 
> also the date on which the Linden TPV policy comes into effect.
>
> That policy apparently overrides the "NO WARRANTY" clauses 11 and 12 
> of GPLv2 *as they apply to TPV developers*, by imposing numerous 
> conditions and liabilities upon them.  It is important that developers 
> of TPVs realize the possible personal dangers to themselves that may 
> result from loss of "NO WARRANTY" protection, so that they can make a 
> personal decision about TPV development on 1st April and thereafter.  
> Boy Lane gave a well reasoned summary of the situation here 
> .
>
> To address a small part of the uncertainty created by TPV, I'll make 
> some simple technical observations on how to preserve the "NO 
> WARRANTY" protections of your open sources licenses if you are a TPV 
> developer whose viewers are used in SL by others.  No part of this 
> note is legal advice (obviously), but under the assumption that law 
> occasionally tries to be logical, it may help developers separate what 
> is relatively certain from what is highly uncertain.
>
> *The most important point to appreciate is that LL has no power to 
> void the "NO WARRANTY" clause on any open source license not issued by 
> them, or issued by them prior to 1st April 2010.*
>
> This means that the following 3 developer scenarios seem quite safe 
> from the standpoint of their "NO WARRANTY" clauses surviving any attack:
>
> * When a viewer project is licensed under BSD, Apache, MIT, GPLv3,
>   LGPL, or any other license other than GPLv2, this is clearly not
>   the license granted by LL and therefore its "NO WARRANTY"
>   protections cannot be overridden by LL.  LL is not the licensor
>   in this case.
>
> * When a viewer project is an independent project licensed by the
>   project's developers under GPLv2 but does not use any Linden
>   source code at all, then the license (together with its "NO
>   WARRANTY" freedom) is being offered and granted by those
>   developers, and it is clearly not being offered and granted by
>   LL.  Consequently LL has no say over the "NO WARRANTY"
>   protections provided in a GPLv2 license that is granted by
>   someone else in such an independent project.  LL is not the
>   licensor in this case.
>
> * When a project creates a TPV based on Linden sources released by
>   LL under GPLv2 prior to 1st April 2010, those sources are not
>   encumbered by LL's TPV document, but instead are licensed under
>   the normal terms of a valid GPLv2 *at the time that they were
>   released*.  This is because *GPL licenses are non-revocable*,
>   and therefore the entire GPLv2 license (including its "NO
>   WARRANTY" clauses) which was valid upon release remains valid
>   for all eternity.  As a result, TPV developers are protected by
>   their GPLv2 "NO WARRANTY" clauses, as long as they do not use
>   any LL sources released on or after 1st April 2010.  LL is the
>   licensor in this case, but the GPLv2 "NO WARRANTY" protection
>   was granted to you by Linden Lab themselves prior to the TPV
>   possibly affecting it, and that granted license cannot be
>   revoked, ever.
>
>
> In the above 3 cases, LL has no means of overriding the "NO WARRANTY" 
> protections in the respective licenses.  (Read GPLv2 clauses 11-12 
> carefully though, because they protect you only from *certain types* 
> of liability, not everything.)
>
> In contrast, any other TPV scenarios are highly dependent on 
> interpretation of the ambiguous TPV document, and hence developer 
> protection under those conditions is very uncertain.  It would have to 
> be decided in court, and I would not wish to second guess the outcome. 
>   Much caution is advised, and even these purely technical 
> observations should be examined carefully, and followed at your own 
> risk only if you think they are accurate.
>
> I reiterate that the above is not legal advice, but only a technical 
> analysis given the very well known terms of the major open source 
> licenses.  The GPL is particularly strong, and it has finally received 
> testing in court in recent years, so relying on its strength to 
> provide "NO WARRANTY" protection for open source developers is 
> probably a reasonable

Re: [opensource-dev] A note on preserving "NO WARRANTY" for SL TPV developers

[Boy Lane]

Small correction here, according to the FAQ the commencement date of TPV is 30 
April, so one more month from now on.
  - Original Message - 
  From: Morgaine 
  To: opensource-dev@lists.secondlife.com 
  Cc: Boy Lane ; Ryan McDougall 
  Sent: Tuesday, March 30, 2010 10:36 AM
  Subject: A note on preserving "NO WARRANTY" for SL TPV developers


  In this note I'll identify 3 simple scenarios in which TPV developers can 
retain some confidence that the "NO WARRANTY" clauses of their open licenses 
remain intact.  This is a technical reading of GPLv2 and similar licenses which 
developers can verify for themselves, rather than a legal reading of the TPV 
which Q Linden explained was beyond our ability to understand.

  The 1st of April is approaching rapidly, and April Fool aside, this is also 
the date on which the Linden TPV policy comes into effect.

  That policy apparently overrides the "NO WARRANTY" clauses 11 and 12 of GPLv2 
as they apply to TPV developers, by imposing numerous conditions and 
liabilities upon them.  It is important that developers of TPVs realize the 
possible personal dangers to themselves that may result from loss of "NO 
WARRANTY" protection, so that they can make a personal decision about TPV 
development on 1st April and thereafter.  Boy Lane gave a well reasoned summary 
of the situation here.

  To address a small part of the uncertainty created by TPV, I'll make some 
simple technical observations on how to preserve the "NO WARRANTY" protections 
of your open sources licenses if you are a TPV developer whose viewers are used 
in SL by others.  No part of this note is legal advice (obviously), but under 
the assumption that law occasionally tries to be logical, it may help 
developers separate what is relatively certain from what is highly uncertain.

  The most important point to appreciate is that LL has no power to void the 
"NO WARRANTY" clause on any open source license not issued by them, or issued 
by them prior to 1st April 2010.

  This means that the following 3 developer scenarios seem quite safe from the 
standpoint of their "NO WARRANTY" clauses surviving any attack:


a.. When a viewer project is licensed under BSD, Apache, MIT, GPLv3, LGPL, 
or any other license other than GPLv2, this is clearly not the license granted 
by LL and therefore its "NO WARRANTY" protections cannot be overridden by LL.  
LL is not the licensor in this case.

a.. When a viewer project is an independent project licensed by the 
project's developers under GPLv2 but does not use any Linden source code at 
all, then the license (together with its "NO WARRANTY" freedom) is being 
offered and granted by those developers, and it is clearly not being offered 
and granted by LL.  Consequently LL has no say over the "NO WARRANTY" 
protections provided in a GPLv2 license that is granted by someone else in such 
an independent project.  LL is not the licensor in this case.

a.. When a project creates a TPV based on Linden sources released by LL 
under GPLv2 prior to 1st April 2010, those sources are not encumbered by LL's 
TPV document, but instead are licensed under the normal terms of a valid GPLv2 
at the time that they were released.  This is because GPL licenses are 
non-revocable, and therefore the entire GPLv2 license (including its "NO 
WARRANTY" clauses) which was valid upon release remains valid for all eternity. 
 As a result, TPV developers are protected by their GPLv2 "NO WARRANTY" 
clauses, as long as they do not use any LL sources released on or after 1st 
April 2010.  LL is the licensor in this case, but the GPLv2 "NO WARRANTY" 
protection was granted to you by Linden Lab themselves prior to the TPV 
possibly affecting it, and that granted license cannot be revoked, ever. 

  In the above 3 cases, LL has no means of overriding the "NO WARRANTY" 
protections in the respective licenses.  (Read GPLv2 clauses 11-12 carefully 
though, because they protect you only from certain types of liability, not 
everything.)

  In contrast, any other TPV scenarios are highly dependent on interpretation 
of the ambiguous TPV document, and hence developer protection under those 
conditions is very uncertain.  It would have to be decided in court, and I 
would not wish to second guess the outcome.   Much caution is advised, and even 
these purely technical observations should be examined carefully, and followed 
at your own risk only if you think they are accurate.

  I reiterate that the above is not legal advice, but only a technical analysis 
given the very well known terms of the major open source licenses.  The GPL is 
particularly strong, and it has finally received testing in court in recent 
years, so relying on its strength to provide "NO WARRANTY" protection for open 
source developers is probably a reasonable idea.  On 1st April, the situation 
may change though.


  Morgaine.




  


  On Thu, Mar 25, 2010 at 6:36 AM, Ryan McDougall  w

Re: [opensource-dev] A note on preserving "NO WARRANTY" for SL TPV developers

[Morgaine]

Thanks Maya, and Boy!

I'm very glad to hear that there is still a month to go.

In that case one can still live in hope that LL might reconsider and rewrite
the policy into something reasonable and unambiguously GPL-compliant for SL
TPV developers.   There's still time.


Morgaine.






On Tue, Mar 30, 2010 at 5:53 AM, Boy Lane  wrote:

>  Small correction here, according to the FAQ the commencement date of TPV
> is 30 April, so one more month from now on.
>
> - Original Message -
> *From:* Morgaine 
> *To:* opensource-dev@lists.secondlife.com
> *Cc:* Boy Lane  ; Ryan McDougall 
> *Sent:* Tuesday, March 30, 2010 10:36 AM
> *Subject:* A note on preserving "NO WARRANTY" for SL TPV developers
>
> In this note I'll identify 3 simple scenarios in which TPV developers can
> retain some confidence that the "NO WARRANTY" clauses of their open licenses
> remain intact.  This is a technical reading of GPLv2 and similar licenses
> which developers can verify for themselves, rather than a legal reading of
> the TPV which Q Linden explained was beyond our ability to 
> understand
> .
>
> The 1st of April is approaching rapidly, and April Fool aside, this is also
> the date on which the Linden TPV policy comes into effect.
>
> That policy apparently overrides the "NO WARRANTY" clauses 11 and 12 of
> GPLv2 *as they apply to TPV developers*, by imposing numerous conditions
> and liabilities upon them.  It is important that developers of TPVs realize
> the possible personal dangers to themselves that may result from loss of "NO
> WARRANTY" protection, so that they can make a personal decision about TPV
> development on 1st April and thereafter.  Boy Lane gave a well reasoned 
> summary
> of the situation 
> here
> .
>
> To address a small part of the uncertainty created by TPV, I'll make some
> simple technical observations on how to preserve the "NO WARRANTY"
> protections of your open sources licenses if you are a TPV developer whose
> viewers are used in SL by others.  No part of this note is legal advice
> (obviously), but under the assumption that law occasionally tries to be
> logical, it may help developers separate what is relatively certain from
> what is highly uncertain.
>
> *The most important point to appreciate is that LL has no power to void
> the "NO WARRANTY" clause on any open source license not issued by them, or
> issued by them prior to 1st April 2010.*
>
> This means that the following 3 developer scenarios seem quite safe from
> the standpoint of their "NO WARRANTY" clauses surviving any attack:
>
>
>- When a viewer project is licensed under BSD, Apache, MIT, GPLv3,
>LGPL, or any other license other than GPLv2, this is clearly not the 
> license
>granted by LL and therefore its "NO WARRANTY" protections cannot be
>overridden by LL.  LL is not the licensor in this case.
>
>
>- When a viewer project is an independent project licensed by the
>project's developers under GPLv2 but does not use any Linden source code at
>all, then the license (together with its "NO WARRANTY" freedom) is being
>offered and granted by those developers, and it is clearly not being 
> offered
>and granted by LL.  Consequently LL has no say over the "NO WARRANTY"
>protections provided in a GPLv2 license that is granted by someone else in
>such an independent project.  LL is not the licensor in this case.
>
>
>- When a project creates a TPV based on Linden sources released by LL
>under GPLv2 prior to 1st April 2010, those sources are not encumbered by
>LL's TPV document, but instead are licensed under the normal terms of a
>valid GPLv2 *at the time that they were released*.  This is because *GPL
>licenses are non-revocable*, and therefore the entire GPLv2 license
>(including its "NO WARRANTY" clauses) which was valid upon release remains
>valid for all eternity.  As a result, TPV developers are protected by their
>GPLv2 "NO WARRANTY" clauses, as long as they do not use any LL sources
>released on or after 1st April 2010.  LL is the licensor in this case, but
>the GPLv2 "NO WARRANTY" protection was granted to you by Linden Lab
>themselves prior to the TPV possibly affecting it, and that granted license
>cannot be revoked, ever.
>
>
> In the above 3 cases, LL has no means of overriding the "NO WARRANTY"
> protections in the respective licenses.  (Read GPLv2 clauses 11-12 carefully
> though, because they protect you only from *certain types* of liability,
> not everything.)
>
> In contrast, any other TPV scenarios are highly dependent on interpretation
> of the ambiguous TPV document, and hence developer protection under those
> conditions is very uncertain.  It would have to be decided in court, and I
> would not wish to second guess the outcome.

[opensource-dev] svn viewer-external

[Philippe (Merov) Bossut]

Hi,

We've been moving along turning the export script on. After a couple of
issues of various nature (Linux build, upload to S3, creation of asset URLs
usable externally), we now have a working auto export and commit script for
the vendor branch! Yeah!

Since we also wanted something consistent (and non confusing) with regard
to  the branching doc (see
http://wiki.secondlife.com/wiki/Linden_Lab_Repository_Strategy), we renamed
the branch to:
https://svn.secondlife.com/svn/linden/branches/2010/viewer-external

Similarly, the asset are uploaded to an S3 location starting at:
http://secondlife.com/developers/opensource/downloads/viewer-external/

See doc/asset_urls.txt for the complete asset locations as before.

For the moment, we sync with an internal hg repo that is synced with
viewer-2-0 as we do not have yet a viewer-public repo created. Exporting
from this though will be just a matter of flipping a switch in the build
parameters of that branch.

That viewer-external has been updated to beta4 so I also created a tag for
it:

https://svn.secondlife.com/svn/linden/branches/2010/viewer_2-0_beta4

Next steps:
- I'll complete the beta5 sync and turn the export switch on definitely
sometime this week.
- Merge of viewer-external to Snowglobe 2.0 trunk
- Back to C++ (at last): go through the backlog of Snowglobe 1.x non merged
patches to produce a true Snowglobe 2.0

Cheers,
- Merov
___
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

[Marine Kelley]

Thank you for the heads up Morgaine. Correct me if I'm wrong, but if  
the "no warranty" clause vanishes from the source code, then does that  
mean that LL guarantees that the code of the original viewer is bug- 
free ? We can't guarantee it as open source programmers if the  
original devs don't in the first place, and they can't expect us to  
remove it ourselves afterwards, so who is liable for the original  
defects if a law suit was started because of an exploit ?
___
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