Collaboration vs Asset store.

Does asset store have some sort of "team" framework in place?
I.e. a person can become part of a team, or leave a team.
They can buy assets on behalf of the team, which become available to other members (as long as they aren't one license per seat).

Basically, asset store stance is unclear on reuse of assets in teams.
Faq ( https://unity3d.com/asset-store/help )

Has two interesting paragraphs:

And

Asset store eula:

Basically, as far as I can tell, asset store can really decide if all assets should be licensed as "one per seat" or if they should be shareable between team members, and, as far as I can tell, that makes using asset store content in collaboration/team environment a headache. Let's say you have 10 people and need a $10 asset. Do you need to buy 10 copies of it? Common says that an asset that is not marked as "one license per seat" needs to be purchased only once in this scenario and would belong to the studio/team.

It would be great if there were a framework to streamline this nonsense away and to simplify working in teams. Now, the question is... IS there this kind of framework on store, or not? It is possible that I overlooked it.

 

+1


Also I'd love to have the ability for asset creators to collaborate on assets. I think the idea of a coder and an artist teaming up to make a game kit seems reasonable, yet there is (to my knowledge) nothing in place that could handle splitting payment between the teammembers in a safe, easy and drama-free way.

 

Me reading EULAs.

They've put a lot of effort into the terms and default licensing, going through many iterations. But still I'm always unsure what the heck to do in some cases. More team systems are needed, and they already have it in place for Unity itself (assigning seats), so it might happen for the store.

 

I'm more interested in shared ownership of assets in collaborative projects.

As far as I can tell, ideally there should be some sort of multi-tier structure, for example...

Company -> Team -> Project -> Person

Where anyone from any level below gets access to stuff from level above AND can purchase stuff for the level above that.

Also, after reading eula, I'm not sure how the heck assets should be shared in a multi-person project. Common sense says there shouldn't be a need to buy a copy for every employee on project that do not use 1 license per seat.

 

That's my thinking too - the existence of the 1 per seat option for sellers SHOULD mean that the rest are collaboration-friendly. But I use logic, not a law degree.

 

Perhaps a community manager like @Buhlaine or @aliceingameland can chime in? I think there was one more "dog person" from unity, not sure if they were a community manager, though... :-\

 

Just about any animal employed by them will do, because they can poke at the right animal to get them to this thread

 

As a publisher, I get asked this a lot. The clarification I got from Unity (and pass along to customers who ask) is that the publisher specifies whether the asset is licensed per-seat or per-studio by selecting the asset category. Currently, assets in the Editor Extensions category are licensed per-seat. If an asset is not explicitly marked as per-seat, it's per-studio.

For per-studio licenses, the studio only needs to purchase one license for all employees who are based out of the same physical location (edit: amended per this clarification). They can then use the asset in all projects owned by the studio. However, if an employee of the studio freelances on other non-studio projects, the employee must buy a separate license for that purpose.

For per-seat licenses, every person who works on the Unity project should have a seat license. For example, if you have a 10-person team on a project that uses PlayMaker, you have to buy 10 licenses, even if only one person actually uses the PlayMaker editor to build FSMs. For any of the team members to be able to run the project, PlayMaker still has to run those FSMs, so technically everyone is using PlayMaker, even if they're not directly in the PlayMaker editor.

The current seat license management setup isn't ideal. I believe the Asset Store folks are looking into improving the way these licenses are bought and managed to provide better license compliance validation and make it easier for teams to manage licenses.

 

So, in this case for "per studio" projects the best idea would be to create separate account for the studio, and handle purchases through it, correct?

That means a contractor or employee will have to poke account administrator every time they need a purchase.

Well, I guess it works, even though it is not ideal.

 

@neginfinity : As far as I can tell, only one person can use an account. So the owner of the account still can't transfer stuff even if it's a company account to the individuals.

I could be wrong on that though, haven't read the EULA is quite some time.
But i just know the Asset Store is pretty picky. I included a license in one of my assets that was only stating you can modify said product and resell it and they declined it just until I removed that license.

I'd honestly get in touch directly with Unity on this issue and not go off guessing from us haha.
If anything if it isn't allowed, they should do another purchase option like lets say it's 10 dollars. To make it where you can purchase 10 copies for like 70 bucks to give to a team of 10 that way you still get a deal while also giving the creator more money more easily through the good deal - if this makes any sense?


EDIT: @TonyLi : It's never asked me about selecting per seat, etc.

 

That's probably a good way to handle it.

Just wanted to add that contractors and employees are only licensed to use the asset on studio-owned projects. If they want to use the asset on a personal project or side job, or a contract for another studio (in the case of contractors), they need to buy a separate license for that.

It's automatic. If you publish your asset in the Editor Extensions category, it's per-seat. Otherwise it's per-studio.

 

Really? I never noticed that before. Wonder why EE are separate.

 

Hey All,

We are researching and designing new license types and license management for the Asset Store. It is a fine balancing act between defending the publishers' IP and the customers' experience. No one wants a customer purchasing an asset and then dealing with messy UI for 10 minutes just to use the thing.

But in general the things we are trying to achieve are:

For the customer

• Communicate clearly that some assets use a seat (think user) level license.
  
• Establish an easy to use UI that allows members (most likely Admins only) within an Organization to purchase, assign, transfer and remove Assets for users within the Origination.
• Reduce friction for new members of a team to purchase / acquire the license to an asset that the team is using. At the moment we're thinking of a few options:
  • Allow the admin to establish a payment method (credit card or some account balance)
  • Allow the team member to make a request-for-purchase to the Admin
  • Org level licensing (see below)

For the publisher

• Allow the publisher the option to distribute their asset under different terms. Think supporting educational customers with discounts or enterprise customers with enhanced support.
• Allow the publish the option to distribute under an optional ORG level license - allowing larger customers to avoid messy license management.

@neginfinity - it is very unlikely we achieve some sort of revenue share model within the concept of a publisher. It is definitely a cool idea, but it's quite niche and technically feasibly under the current model.

 

Uh, did I even talk about revenue sharing?

The reason why I started this thread is because I wanted to know how to handle a situation when a company buys an asset to use, and company employees/contractors should have access to the asset.

As far as I can tell (based on responses), if it is not "one license per seat", company is allowed to give access to the asset to its employees, although the employees are not allowed to use the asset for private project. So what I said it would be great if there were an easy to way to manage access/permissions for assets through asset store interface.

The reason for the confusion is asset store eula 3.5:

Coupled with asset store help page:

 

Since the seat license is different (per) for editor tools, so I was always under the assumption the others were essentially usable by the purchaser in their project(s), and that everyone else didn't need a licence, since it was part of that project. Though, if they weren't the purchaser, they couldn't use it elsewhere. But really, I have no clue. I have misunderstood their legal stuff before.

I think the challenge arises because of the all the ad-hoc constantly changing "collaboration" projects. You get a company trying to provide reasonable product solutions (for publishers and developers), and mixing it with 13yr CEOs building their first MMORGPGs with all their new online friends, but have blown through all their allowance already. Having a perfect business model that supports both.

Now let's make it a little more ugly...
- no DRM (good thing)
- a lot of great (and sometimes expensive) assets/tools specifically to help new users (good thing)
- experienced developers constantly beating new users over the head about always using VCS. (good thing)
- many of the free VCS solutions are public, or not private by default. (uh... oh).

I have no useful or worthwhile opinions on the subject, and don't envy Unity having to deal with this kind of stuff. We aren't allowed to use AS stuff, for pretty much this reasons, the licensing is... challenging. Personally, I only use/buy editor extensions, or for prototyping/playing or even just to see how they did something.

 

Sorry! That was referencing Matin_H - I hadn't had a coffee yet

Under 2.3 of the EULA, we permit sharing of non editor extension assets under two circumstances:

1. The End User using the asset is on-site from where the asset was purchased.​

• • This allows a team in the same physical location to work on the project.
  • If there are contractors or people off-site, they each need to purchase the asset's license one time each for the project.

2. The End User using the asset is on a laptop originating from the office the asset was purchased.

• This allows someone, from the physical location mentioned above, to work remotely on the project as long as its on a company computer.

​

If you have any further questions, please send them to me.

 

But this begs the question, how is this even enforced in the first place? Unless there's some Spying system involved lol.

 

I never share assets I buy. There is not enough money in them for the makers if you do that. LOL, and it saves you from two weeks partnerships when your internet teammate(s) vacuum up all the assets you bought and move on.

 

I'm the same way.
You'd think Unity could at least add a simple thing that checks your account if you own the product when importing it. Deny it if they don't own it kind of thing.

The Eula seems almost pointless in terms of distribution if they can't in fact enforce the rules.

 

It's not usually multiple people importing it, it's "One person imports it, pushes to source control, now everyone has it once they pull." And having any kind of DRM would reduce the usability considerably; an asset you can't see/edit the source code of is often a liability.

 

@Errorsatz : I hear you... I was just saying, have they ever actually enforced it before? Because I've never heard of it happening. Word gets around here fairly quickly if anything happens lol.

 

its not enforced, and the problem is further compounded bought assets go straight into the project, and get pushed onto a teams version control. Really just have to rely on good faith. When it comes to tools, we always try and make sure we got 1 license of it for every unity license we have since if a tool is good i want to support it. When it comes to people from real studios working on projects with real budgets i find you can rely on good faith just fine.

 

How would these checks work when a lot of assets are distributed as source code? I guess authors could compile to dll first and some check could be added to the dll. But that would reduce the value of the product for most, since i will often add my own features to bought products. Like the version of cinema director i use at work is heavily modified with a lot of our own features added.

I am already pretty resigned to the fact that if people want to steal my stuff they will and there is little I can do about it, and little point stressing over it.

 

What about teams working together as a single organisation without a physical premises? That's pretty common with indie teams.

 

EULA Section 2.3's "physically located at a single physical location" is pretty clear to me. It's a shame, though, since as you said so many teams are geographically distributed.

The intent of the next clause in 2.3 ("laptops belonging to END-USER which have been made available by END-USER to its employees that are employed at the same Site") is to allow employees at that physical location to also work on a laptop if they want to bring their work home with them or get in some work while commuting. I suppose one could try to argue that geographically-distributed team members are all employed at the same Site, even if they're never actually physically present at that site, but even with this tenuous argument it would have to (1) be a laptop, and (2) be provided ("made available to... employees") by the employer, not a personal laptop. So I think the only practical thing is for each remote team member to buy their own license.

 

Hmm. Alright. So this info coupled with what zombiegorrilla said earlier, means that for remote/distributed teams the best idea is to avoid asset store due to legal reasons.. and that for asset developers that made be interested more in making their assets useful for people and less than getting maximum profit it might make sense to seek alternatives to unity store as asset distribution platform.

It is nice to know this, I guess.

 

I have to respectfully disagree. Let's say you have a distributed team of 5, and you want to use a $50 asset in your project. This would cost a maximum of $250 (less if some team members are physically located together). If it would cost your team more than $250 to design, implement, debug, maintain, and support a custom solution, then it's more financially responsible to buy the asset from the Asset Store.

Working at just $25/hour, you'd have 10 work hours, which in practice might be divided into something like design=2 hours, implement=2 hours, debug=1 hour, maintain/support over its lifetime=5 hours. That's not a lot of time. It's almost always more efficient to take advantage of the Asset Store.

And for per-seat assets (editor extensions), it makes no difference. You always need to buy a license for each person, regardless of whether they're located together or not.

 

Or if you hire a freelancer to work on some deeper part of the project you'll have to either buy him/her a copy of every single asset you already have or waste time carefully splitting project into completely modular parts. If the freelancer has to be replaced, you'll have to do that again for the new one.

If the project has a lot of assets, the costs per new employee will keep increasing.

As far as I can tell, the system isn't good. Might be acceptable in some cases (depending on rates, budgets and the like), but in general the best idea seems to be keeping asset store use to a bare minimum.

 

No doubt it is always better if you can just do everything yourself. If that is not an option the next best thing would be to have a local team of people to work with. Failing that there is little option to just "wing it" with asset store and outsourcing.

It would be good if they just did away with these "per seat" licenses period and made it so if you buy an asset and hire someone else well they are just going to get it as a matter of working on your project. I can understand why neither Unity or the asset creators would like that. But I think they have to consider how many lost sales would it really be? Not many I think.

I suppose another way of doing it would be to request all contractors to provide proof of purchase they already have the necessary assets. But yeah in general it all seems like a bit of pain in the ass. It's interesting how often doing things (in all of life) "the legit way" is also "the biggest pain in the ass most inconvenient and expensive way". I suppose this is why so many people cut corners and do not put so much focus on "doing the right thing".

If only there were other folks in this small town who were into this stuff. That'd be pretty cool... if they knew what they were doing.

 

The reality is that the small hobby/collaboration/indie teams are going to break the rules. If you have done more than a little contract work you will have surely been sent projects with many included assets.

As a contractor my approach is:

1. Ask the employer to purchase me a copy of each asset (for larger projects)
2. Buy the assets myself (if they are any good)
3. Contact the publisher and ask for an exemption from them (nearly everyone I have asked has said yes to this)

As a publisher I'd rather the EULA err on the side of caution.

 

I've only hired out work involving one asset and in that case I started out with here's $50 grab so-and-so asset. I don't think it is a big problem for me personally. But for a project involving many assetz and perhaps many people it could be a pretty huge amount.

Ultimately, I've bought many things on the asset store and out of those I find two actually useful and worthwhile. So I'd rather just hire out work I think. Instead of buying an asset hire someone to build a specialzed version with only functionality I need and additional highly useful functionality.

Or better yet just get a team and have a tools builder.

 

It's clear. I'm pointing out that it's a pain.

You're overlooking the fact that buying a solution for many things still involves design, implementation, debugging, maintenance and ongoing support.

 

Lets be honest here. None of Unity's licenses work very well for the casual contract freelancer.

Unfortunately it it what it is. And the casual contract freelancer is not a big enough market to push Unity to change their model just for us.

 

Heck, I understand all of that. I still feel annoyed about it, though.

 

It'd be handy if things could be licensed per project rather than based on physical location.

 

Some of them are, yes. And that "some" is likely to include more if things are made hard for them.

As @neginfinity points out, right now it's actually pretty darn difficult to play by the rules in some cases regardless of intention.

It can't be physically enforced either way, so why not make something that's at least reasonable for those who want to do the right thing?

 

Interesting points of view.
Looking at it slightly different - from the view of a person attempting to hire a freelancer - I'd write in the job advertisement tools required to perform the task(s). So in the advert - Unity, Playmaker, Substance designer, Maya etc.
Freelancers interested in the project will either already have these tools - or they will roll the price to purchase these tools into the quote, for the tools they do not currently own.

It's similar (though cheaper in most cases) when a job posting requires a specific software for development, ie Max, Maya, Blender - because usually the client already has a pipeline in place and don't what to fuss about with issues that don't fit the current pipeline.

 

I think this is an interesting idea.. If we could just say, like, I get 40%, person B gets 30 %, and person C gets 30%.... And then for Unity to simply handles the payments to each person. Everything is pretty much in place already - making payments, keeping track of sales, reporting etc.. We just need the payout to be divided up between people. This would allow a lot of team collaborations and make things a lot easier, otherwise e.g. If I try to do this as a single publisher, then I now have to try to deal with my own legal contracts, making payments, invoicing and all this other stuff. Unity would remove all the pain easily.

 

That works well for tools that are relatively standard. You can cover the cost of Playmaker or NGUI over a bunch of contracts because they're so common. On the other hand, it's really awkward for non-standard stuff, especially if there's a lot of it and/or it's expensive (lets say I have 10 different art packs in my game, I can't expect arbitrary contractors to have them). Getting a day of help from someone could require spending thousands on assets before I'm even allowed to share the project with them, which ultimately means it's just not an option.

And for stuff that's no longer available you're just fat outta luck, because even if you want to then you can't buy licenses to abide by the rules. "Yeah, just fly over to my country and pop by my place with your laptop so we can do this legitimately." Uhhh... no? So even if you want to permanently expand your team you can't do that legitimately, either.

Now that I think of it, same deal with tech support. You can't share your project with a vendor to get their help if you also use stuff from any other vendor.


A business like Unity tying things to physical locations just seems... awkward? It's an archaic and outdated way to do things in the internet age with distributed work teams being common.

Plus, keep in mind that all of this offers practically zero physical protection to the assets, because it's only going to stop people who both read and want to abide by the rules, who are the very same people it makes life harder for.

 

I believe the discussion is about asset consumers, not asset publishers.

 

And to clarify, this isn't "per vendor". It's "per person per vendor", so it also makes life harder for them.

 

You might reasonably expect a freelancer to have access to Unity, Playmaker, Substance Designer and the like. Especially if the job involves using one of those tools. But what about generic environment art pack 1703?

Pricing the asset purchase into the job is often not practical either. Makes sense for a big job, if I'm going to spend months working on a project I don't mind getting the assets. But just as often I will spend only three or four hours on a project. Often my spec is limited to 'get in, identify a specific bug, implement a fix, get out'. The price of licensing a second set of assets could easily be several times the cost of my labour.

Stripping out generic assets is sometimes an option. But in the late development stages of a project that can take an inordinate amount of time and effort. And my job is to reduce the effort required by the client, not make them jump through hoops.

Fortunately Unity doesn't enforce any of this licensing stuff. So its possible to operate in the grey area of 'don't ask, don't tell'. But its not nice to operate in grey areas. The pro, plus, personal 'integrating content' rule also falls into the same sorts of traps.

Ultimately this. Today in game development the remote team is very much a thing. Eventually the licensing model will catch up.

 

Awkward is a fair summation. I mean, I get the idea behind it, if you in are in a physical studio, purchasing one asset for project makes sense, the asset may be reused by the studio,etc. It makes sense in a fashion. To me it feels awkward because, I feel there is an inverse correlation between size/scale of a team and the amount of (non-editor) assets they will buy. If a studio has a physical location, they are probably not going to use a lot of content type assets.

 

To me it's because assets are purchased for projects rather than teams.

When I buy music from my preferred vendor, in the purchase form it asks what project it is for. The license terms are for the project. If I sell the project or hand it over to a client then the license goes with it. If more people come onto the project they're covered. Location doesn't matter so it works for distributed/officeless teams. If I want to use it on another project I need to buy another license. It's nice and neat and easy to understand.

On the down side, I guess, it doesn't fit into a sales cycle because it's very much based on an "as needed" system as opposed to a "dangle carrots in front of consumers" system.

 

Yeah - I see you points.
Too bad there wasn't an x-ref type setup, where specific geometry or other content could be represented by an empty game object or nulls which have all the characteristics of the original object - code, colliders, animation data etc - but the actual geometry/bones/textures etc are not actually available in the scene. I'm sure that would lead to other issues also.

And also I've purchased several tools from the asset store that I think are really useful and will eventually be used for a project in the future, but not the project I'm currently working on.

 

"Must have $2 chair model, $3 spoon model, and 148 assets listed below in order to apply"
I don't know, that quite different from "must be familiar with Maya/Blender" and sounds very silly.

"As long as you're paying for the plane tickets, hotel and will wait couple of weeks till I get a visa..."

 

I have a few questions related to assetstore usage:

Imagine a traditional gamedev studio with an office. They could use art assets from the store on-site with a single license purchase as far as I understand. Correct? As far as I know the assetstore EULA permits use with non-Unity engines or even non-game related usages. Correct? Now imagine you have a studio that finds an audio asset pack or some textures that would be useful to them, they don't qualify for any free version of Unity and they would like to purchase and download assets from the store to use on their project (e.g. a game in a custom made engine, archviz work or a movie). Would they seriously need to buy Unity Pro because they don't qualify to use Unity Personal Edition, and there is no way to download assets without using the Unity editor? That would be quite an expensive barrier to assetstore sales and wouldn't make any sense to me. Yet I'm not aware of any clause anywhere allowing this without buying pro.

 

That just wouldn't happen. It's a silly hypothetical.

 

I'm not sure if it is even possible to make audio/texture asset incompatible with free version of unity. (what would be the point?)

 

He's meant the team being unable to use Unity Free to retrieve the asset due to being over the income threshold.