Royalty amount property

In the Properties dialog for all item types:
[x] Royalty on buy L$ [__100]

Where the Creator sets the royalty amount and no matter who gets the
item the amount is paid to the Creator for that item.

If the royalty is set then the item can no longer be copied by others
using Take Copy and the minimum Buy price must be at least the total
of all the royalties within the item being bought. eg. Prim royalty plus texture royalty plus script royalty plus notecard royalty (in a multi-author environment each creator plays a big part in a successful product).

If a user gives the item to someone else, the receiver is prompted to
pay the sum of the royalties within the item and may also choose to
decline. So your dialog that normally says Accept or Decline will
change to Pay (and shows the amount and all the items being paid for
as per the normal Buy dialog) or Decline.

llGiveInventory LSL function would need to make use of the new logic
too. Perhaps also a new LSL function:
integer llGetTotalRoyaltyAmount(string inventoryNameOrKey)

In some instances such as a customer wanting a refund it will be
useful to know how much L$ went to each person. So account history
should reflect this. But that gets hairy! But don't worry, the scripters will come up with solutions - one day.

Perhaps even better:
key llRequestRoyaltyData()
that could return:

Creator key|item name|inventory type|royalty amount

eg. returns via the data event:

<blah, key here>|Handbag of Doom|INVENTORY_OBJECT|10
<blah, key here>|Red Leather|INVENTORY_TEXTURE|5
<blah, key here>|doom.lsl|INVENTORY_SCRIPT|100

To vote for this feature go here and search for the word Royalty:
http://secondlife.com/vote/

What happens if this passes? You suddenly change SL so that you can all get jobs! Multiple authors, no problem. Sales person wanting to add a bit of commission on top, no problem.

We go from Business to Client model to Business to Business model.

Clever, although it goes against THE PLAN.

Whose plan? What plan?

As far as I can tell so far from private correspondence from Philip this is a good idea.

Yes, copyrights/royalites have been discussed in the forums before. I am all for this; people that make items and are used by others deserve compensation, however; there should be a choice for the time/object for the creator to select Receive Royalites? Yes or No. Excellent! I approve of this Proposal.

Best Regards
Blake Rockwell.
Arts and Entertainment Representative.

Don't forget to vote (search for Royalty), otherwise the endorsement won't count. Thanks.

I really like this idea and I've voted for it. Surprised so few have so far.

If this existed I'd sell my products for a lot less.

Same! My cost of development would easily be recovered by quantity, so I could definitely reduce the price.

People could give or sell a copy to their friends and the creators still get their royalties.

A good product will travel far.

Nah it's my fault for posting it late, so other ideas got votes instead because this wasn't up yet.

Are you able to reassign your votes? If so, please do so.

I endorse this product and/or service.

- Ace

I am firmly against this product and/or service.

This would be a database nightmare.

Your opinion is welcome, but the reasons are more important. Please tell us why.

Thanks.

Actually, it's one more integer stored in the database per item.

The rest is the huge ripple effect of UI and transfer logic changes.

Default behaviour of L$0 Royalty will match current behaviour so that it doesn't break existing solutions.

Everyone is quite happy to vote for new Havok implementation and yet somehow it's ok to be blind to the impact of those changes. It's huge.

This is big too, but I'd say it's well overdue.

I predict those who are complacent with their abilities to create content of all types will resist this feature. Whereas people who can only achieve one or two types of content or have the desire to help sell on will welcome it with open arms.

Rather do the fundamental changes while the virtual world is relatively small, because adding this later becomes an even bigger nightmare. Imagine a million users.

However, it really is up to Linden Labs to assess the impact in detail before stamping it with a 'Can't Do' or 'Accepted'.

Stepping back a bit, let's look at the fundamental problem...

Currently everything is Business to Client (B2C). The manufacturer sells direct to the end user.

We are unable to employ middle men/women to create a Business to Business (B2B) environment (group projects/multi-author projects).

This is merely something I have thought up to break us out of the B2C spiral that will forever keep the rich rich and the poor poor.

If you have a better solution, please by all means speak out and say something!

I don't care if this idea gets scrapped in favour of another one that fixes the underlying problem outlined in this post.

ok the way I read this:
A) I go to a store and buy an item. I use this item in another item that I wish to sell. Creator of item gets cash everytime I sell this item?
----Good idea possibly if not set to high. Could see abuse. Origonal person turnign around and making my item for cheaper, etc.

B) I go to store and buy an item for my friend or significant other. I then hand it to them and have to pay a royalty.
----BAD MONKEY BAD!

C) How would the price be reflected. I could see someone saying the price was 300L and it is but then after roalties the customer could end up paying 1000L

I'm all four some way for people to work on something and get royalties in it after the items have been made if being resold. Problem is making sure it is done in a way that is clear and cannot be abused.

Thank you. This is exactly the kind of feedback we need - use cases that may not have been not considered.

In case B, say the item was no copy, then the Royalty need only be paid once. Happy with that.

Case A is not an issue, you basically set your royalty as your expectation. The total royalty amount for the item sold is the minimum price it can be. If you sell it at more than royalty then that's a bonus to the seller. This way, you encourage others to sell your products.

Yes, this use case is open to abuse.

Ideas anyone?

Perhaps Royalty-enabled items can't be given via llGiveInventory();?

Ideas and insight I have. Answers I have not. Not even close to understanding how to do things in the game just how they will end up.

Maybe make it so that if you use "Buy" it royalties. if you simply "Give" it does not.

I don't like this. It both gives a new incentive for people to steal existing products as it leaves certain types of content creators above others (for example, this would be a lot harder for scripters and creators that sell Modifiable objects).

It's a decent idea on paper... but I just dislike how I feel this would work out in practice.

I think this idea would help solve the problem of what non-creators can actually do in the game, by adding the potential for middle-men in the game. Creators would benefit from increased product distribution.

I see it having to be restricted to paying a royalty every copy. And the royalty on an item would have to be clearly visible. It could be abused in vendors, but then i could make a vendor which takes peoples money and gives them a 0.5 x 0.5 default textured sphere instead of the promised very expensive item.

I see what you mean about modifiable scripts, they present a problem. I suppose they can still be sold at an appropriately raised one-off price though.

I'm sure that LL can think of a way to implement this safely, or that if they couldn't, they wouldn't implement it. Still, I believe they can and will, because it solves said problem, so it gets my vote.

couldnt you have a vendor that gives royalties (aka x% of the sale) to anyone... couldnt you just use that for most cases?

It would work for multi user products, but wouldn't effect the resale, gift, modify, or transferability of the item. it would also not create another potential abuse hazzard.

the first flaw that comes to mind for the grand scheme of the post concept, is your B2B sales.
But If you just talk with a buisness and make a buisness offer (exp I sell my product here you get royalties) you could still have your B2B and your B2C sales.


problems? pros? cons?

another con i thought of would be trust,.. you would have to trust that the product was being sold in the vendor, and or that the product was being sold and the agreed apon price. but perhaps the vendor item could be properly scripted to eliminate these issues?

Yes. Many people do this already.

Most of the posts on this feature (royalties for objects) are very old and I think the issue should be revisited. I'm new here. But I can see that the entire economy has changed from when this feature was initially proposed.

Currently, to provide objects for sale, you need to either a) create the whole darn thing, or b) assemble it from freely available components. This limits commercial activity, and favors a handful of people who control the entire distribution of certain product classes. There is a lot more money to be made, and everybody can be involved. The economy can grow at a staggering rate if this feature is provided. You don't need to be an expert of everything that goes into your object if there is a way to import the hard work of others and compensate them for their expertise.

It isn't technically difficult. If the object creator sets a price on an object, yet makes it copyable and transferable, he/she/it gets that price when the object is copied, or used in yet another object. Let's take a front door as an example. If you build a house with Bob's front door, and he wants L$10 for the door, it is given to him whenever a house is built using his front door. Yes, the system needs to guarantee he gets his payment. The sum total of all royalties used in a complex object sets the minimum price of the object as a whole. The person re-selling this object may or may not add a profit onto this. What you get for this is an ability for component experts to provide components for value-add, it also opens a wholesale market allowing new visitors to open up store fronts stocked with goods provided by others - and without relying on goodwill to ensure payment to the creator. The entire marketplace grows as a result. The only technical issue is how to ensure that the current holder of the object can't give it away or sell it for less than the composite royalties. It isn't rocket science.

Otherwise, the house builder has to also be an expert at doors, or find one for free. If Bob's is the best front door, why force Bob to also be a house architect, a sales person, a land owner, etc? Maybe he's only good at doors and doesn't want to give away his work. Let him do what he does best and compensate him for it. Likewise, script architects can provide good scripts to others for payment without forcing them also to be experts at 3-d modeling and thinking up all the custom creations which could be based on their scripts.

Without this feature, eventually the economy will stagnate because only a small fraction of members will be able to do it all for any complex product. They will take all the money. 99% of the community will only be consumers. A large part of the success of SL is the ability for anybody to make money off of virtual merchandise. But if this ability is not there, or the learning curve too steep for them to participate, many of these consumers will eventually leave. Letting them create new product classes or new distribution channels while compensating those who can help build the products creates new markets. If everybody is making money, they will often spend it as well, without requiring infusions of $US to buy the goods and services they desire.