I'd like to see the decision about whether a llGiveInventory() call is allowed to see follow the same pattern of the way the push restriction was designed to behave (not the way it currently behaves, see SVC-141). In fact, while we're at it, it might be cool if quite a few other functions could be limited in this manner by parcel owners.

I like this kind of limitation because it leaves options open. If I don't like this limitation, I can go to lands that don't have it set. If I find that a parcel owner has set this but still has scripts spams me with inventory offers when I show up on their parcel, my response is obvious: leave the parcel and find one that disallows scripted inventory offers. I like the idea of NOT making the scripted inventory spam protection into a client preference for the same reason that I didn't want Push Restriction to be a client option: there are plenty of legitimate uses of both llGiveInventory AND llPushObject, and people will be very likely not to take the time to educate themselves before turning on options that claim to be "anti-griefing". So a parcel setting like this is definitely the way to go.

I had not read SVC-422, which mainly focuses on money transactions with selling and buying limitations. The major differences is that my proposal now encloses the llGiveInventory() functions in addition, regardless of payments, and the approach is based on disabling LSL functions from being called rather than simulation behavior. (e.g. graying out the pay function avoids the need for rejected payment dialogs or having the simulator refunding the money)

UPDATE: Changed overall definitions and terms to reflect the broader scope of protections with a feature name that encompasses the no selling and no phishing elements along with llGiveInventory restrictions.

I also don't want to see llRequestPermissions() lumped together with llGiveInventory. I'd LIKE not to see even llGiveInventory lumped together with objects allowing payment, but that's necessary right now, I think. llRequestPermissions() should definitely be its own setting. Don't hamstring this feature by making it too much, which makes it an all-or-nothing proposal. If someone wants llRequestPermissions() to be allowed for whatever reason that we can't forsee, they shouldn't have to also allow llGiveInventory(), and vice versa.

I don't think you should be limiting setting objects for sale. There is no way whatsoever that setting an object for sale using SL's internal "for sale" checkbox could possibly result in an unsolicited inventory offer happening. Someone must buy the object before inventory will be sent. I think this should remain allowed. Only SCRIPTED vendors using the right-click pay system and llGIveInventory() should be limited. In other words, don't lump the buying system into this, lump right-click pay into it.

As for lumping the buying function together, I know it's not necessary but I think it's a value added protection with no particular hampering cost to the owner. In fact, I don't think many owners are tolerating or have use for any unauthorized third party setting objects for sale in their store or on their land unless their are renters or group members. For the few who have such legitimate use it would probably make sense for them to turn the entire feature off anyway. The problem of objects for sale spam is particularly frequent in popular landing/platform areas especially sandboxes where the no-selling rule is violated every day. I think it's an actual issue worth addressing at the same time.

I still don't agree that it's a good idea to lump for-sale objects into this proposal. It's like one of those bills in the US congress, where people keep lumping in semi-unrelated or unnecessary provisions, and eventually no one will vote for the bill because every person hates at least one part of it. We want to make sure people actually USE this functionality, so we should try to avoid having this one option turn off too many things so that fewer people will be forced not to use it. Furthermore, an object simply set for sale using the built-in system does not spam by its nature. If its very existence is considered spam, then turn off building on the plot. And if we're going to go back to trying to protect sandboxes... well, I'm sorry, but they ARE by their nature free-for-all areas.

(And BTW this isn't for the entire benefit of sandboxes without impairment, because it means no builders would be allowed to test money events or llGiveInventory functions with the restriction on... My goal would be to have this restriction in two sandboxes out of three, or slice a small parcel with no restrictions reserved for builders money/llGiveInventory related testing. It's could actually be an alternative to Linden sandboxes letting people script with limitations against selling and spamming. And, sandboxes are not free-for-all TO SELL as you know.)

So, to be clear, the default behavior will prevent anyone setting shop on your land, including freebie advertising methods, automated unsolicited distribution, or other such unethical business practice to be taking place. The premise making me assume that 99% of land owners actually want this is that: you don't go sell or promote things in other peoples stores or private property or in public areas no reserved for such activity. This kind of behavior is not freedom, it's violating other people's personal and property rights. I think WarKirby Magojiro and Gigs Taggart would agree based on their SVC-422 comments. I am honestly not quite sure why it bothers you that much, you can still opt-out, and this does not impair anyones ability to conduct permissible or legitimate activities.

I welcome and encourage more comments to see what others have to say.

I guess I haven't made myself clear yet. What I would want for option B would be BOTH checkboxes checked, so that this option limits NO ONE by default. I want this to be something that has to be explicitly set to cause any changes. Otherwise, we're going to slam a bunch of people with an unexpected change when this is released. I guarantee that some significant portion of the population would be disrupted and confused if you suddenly disallowed non-group people from giving/selling inventory all across the grid.

The reason it would bother me so much to enforce this by default is twofold: first, it's an unexpected change, and second, it's a case of you enforcing your preference on the grid.

As to the first, most people don't read the release notes on each new version, and they don't read the blog, so they'll be caught completely unaware if this change is rolled out and suddenly changes what can or cannot be done on their plot. I can think of plenty of cases where this will disrupt business, including rental vendor plots. I don't care how much of a benefit you forsee in enforcing this by default; if you change the way the grid operates and it breaks things, residents will be (rightfully) up in arms. I'm sure a vendor rental magnate won't enjoy spending hours trying to figure out what the heck is causing their customers' vendors to stop working while tens or hundreds of them are IMing the magnate demanding their money back.

As to the second, I'm all about giving people OPTIONS, but I'm not very happy with the idea of forcing those options on people without their concent or without informing them. There are bound to be cases that you and I can't think of in which this will severely inconvenience someone. That's happened to me plenty of times.

So, to make it clear: providing options is good. Changing the way SL behaves unilaterally isn't. If this option is useful enough, trust me, it'll see widespread adoption very quickly.