publishing a project that uses 3rd party assets

I have project that uses several assets which are paid for, I'd also like to make my project publicly available in some way, ie github for example. I obviously can't include the libraries or code from the paid assets within my project that renders them available to other people. How can I make my code still use the functionality of the paid assets/libraries without explicity making the code or libraries from these assets publicly available?

Another example is if I wanted to publish my project on the asset store, either for free or paid, while allowing use of the 3rd party asset for use only within the project, but not allowing it to be used publicly from my project.

Ideally, I'd like to create my only DLL which has the 3rd party dll's internally compiled, and only available internally to my DLL.

Further to this, I've seen addons for assets, such as Playmaker, where the addon requires this to work. Is this the best and most practical approach?

 

Put your external assets into git ignore and do not upload them to the repository.
Add instructions to the project explaining which assets are necessary, and where they should be placed.

Uhh... what?
You'd need to obtain permission of the 3rd party author of the asset and specify terms of use for that 3rd party asset. Personally, I wouldn't bother with complicated license like that.

Well, you can't do that. By trying to embed a 3rd party dll into your project, you're creating a derived work and redistributing that 3rd party dll, no matter how you do that.
Unless the dll is under permissive license (BSD, MIT, ZLib), or you have permission of the original developer (preferably in written form), you cannot embed it in any way.

With zlib/mit/bsd project anything goes, really, as the licenses are easy to adhere to.

For the asset store stuff, you're explicitly forbidden to do that.
https://unity3d.com/legal/as_terms
See 3.8.

Basically, the asset store doesn't seem to be well suited for complicated dependencies, unless we're talking about media addons for scriptable project.

 

Thanks for the information, that is very helpful.

Lets say I have an AI character controller, a plug and play asset, however the inner workings of the AI controller code makes use of various 3rd party assets,
how would I able to publish my AI Agent without asking that that all the tertiary assets be bought also?

 

You would publish it while asking that all the tertiary assets are also bought. You also put this requirement in bold text and clearly state that those assets are REQUIRED for the project to function.

Alternatively you seek out all the owners of the 3rd party assets, form a partnership together, create combined work, and then deal with splitting profits. Which is unlikely to happen.

The easiest and most desirable course of action is not to have heavy 3rd party dependencies so your asset would not require anything else.

 

This is craziness and anti-productive. You are telling me that standing on the shoulders of giants is strictly prohibited.

There must be more to this, as this isn't how software is built. Something to do with Creative rights and sufficiently changing something to be unrecognizable from the original.

Taking the above example and extending it to the extreme, I make a complete game, I can sell this, yet I don't have to ask everyone who buys it to also buy the assets used to make it.

I'm guessing that there is a distinction between software and assets in the terms of use.

 

Theres a big difference between selling a game using assets, and selling assets using assets. All which are outlined in asset store and unity TOS.

Sorry but this is the hurdle all asset store developers have to jump through. Ultimately if you built an asset you want to sell that is dependent on all sorts of code that you do not own, I would go as far as to say you probably could have planned out that asset a lot better before developing it. In general, hindering your asset by making it dependent on buying other assets makes it not particularly marketable and you will struggle to sell it. All of which are factors you should take into account before actually making the thing.

If you absolutely have to (as in your idea does not function with out XYZ 3rd party assets) You are better off making assets that are formal extensions or add ons to the assets in question, which various people already do on the asset store. So if this was reliant on say "vegetation studio", you would call it a "vegetation studio add on" (contact the original developer first still).

Either way all of this exists so you cant just reap the benefits of others work while doing minimal work yourself to create something worth buying. Otherwise people would just add minimal amount of BS features to an asset and be able to resell it.

All of these TOS clauses are good things to have in the TOS if you are an asset store developer making assets and dont want everything to be stolen at the drop of a hat.

 

No he's not; he's saying that standing on the shoulders of giants requires that you ask permission and/or compensate the giants for the height advantage they give you.

oh yes it is.

What, you think its about what's convenient for you when you want to reuse someone's work, not what protects the person who created the work you want to reuse?
Nope.

That's not taking it to the extreme, that's how asset licensing works

If you buy an asset from the Asset Store, you're specifically licensed to use it in making a final product.
If you buy an asset from the Asset Store you're specifically not licensed to redistribute work derived from that asset to some other user for use as an asset. If you want to do that, you need to make an appropriate arrangement separate from the kind of licensing the the Asset Store provides.

 

Welcome to the amazing world of copyright law.

To build on shoulders of giants, you must obtain giant's written permission, preferably verified by lawyer. Or honor their license agreement. And pay royalties when applicable. Because giants own the right to their work.

It is exactly how software is built. When you have commercial asset, you are not allowed to redistribute it. Or make a derived work. Or even decompile it. Sometimes you don't have an asset, because developer made critical component of it into SAAS so they lock you into using their service.

Yes, because by doing so you honor terms of asset store agreement and are permitted to do so.
https://unity3d.com/legal/as_terms
However, you cannot resell assets. See:
https://forum.unity.com/threads/ass...old-on-steam-as-dlc-for-maker-program.817455/

--------

Long story short, you've stumbled into problem that is partly related to reasons which initially gave rise to Free Software movement.

Currently, if you want to incorporate a 3rd party library without legal hassle, you have to ensure that the library is under sufficiently open license. Namely BSD, MIT, ZLib, and others.

You can't use GPL, by the way, because you'd be unable to fullfill its requirements in a unity project.

So, basically, pay attention to agreements and licenses, honor them, and stick to projects with no 3rd party dependencies, data assets with no dependencies, or opensource libraries when possible.

Speaking of unity store itself, I'm not aware of functionality to pull dependent packages (and purchase them). In case of pure git, git submodule can reduce hassle of multiple dependencies, but it won't help you in the slightest with legal trouble.

 

And just so its clear 'Something to do with Creative rights and sufficiently changing something to be unrecognizable from the original' has no basis in intellectual property and copyright law.

Copyright law exists to protect the rights of the creator of work, to allow them control over who may redistribute their work. The 'creative rights' to that work are owned by them as its creator.

The notion that deriving from someone's work gives you more rights than the creator is entirely false. The notion that deriving from someone else's work gives you rights to redistribute that derivative is entirely false.
The argument that you can transform a derivative sufficiently to cease to resemble the original has no relevance; its actually a dishonest and specious argument that this somehow negates the original author's ownership of their work.

Its worth remembering that the entire premise of open source software is inherently dependent on the author of a work having the right to control the redistribution of any derivative.

 

As far as I'm aware, it does have a basis, but it does not apply to computer programming. At all.
https://en.wikipedia.org/wiki/Rogers_v._Koons
https://en.wikipedia.org/wiki/Substantial_similarity
http://www.law.harvard.edu/faculty/martin/art_law/image_rights.htm
It is related to the field of art.

Also related:
https://en.wikipedia.org/wiki/Derivative_work

In case of gamedev/software development, however...
https://en.wikipedia.org/wiki/Silicon_Knights#Silicon_Knights_vs._Epic_Games

 

Im saying it (changing code to be unrecognisable) doesnt have a basis as an exemption clause for copyright law.

And yes, it does apply to computer programming. It doesnt apply to abstractions, eg algorithms, but it does apply to code. Running someone else's code through an obfuscator doesnt strip the writer of their copyright.

As regards derivative work, only any substantially new and original portion would be elegible for copyright protection for the deriving author (they dont somehow get copyright over the work they derived from), and only if they actually had appriopriate permission to make a derivative work in the first place.

 

I'm saying that in practice there's an advice when using references. The advice is to use so many sources that result can't be recognized as any single one of them.

In this scenario you'd be able to get away with it. However, this does not work with computer programming due to obvious reasons.

Regarding protection of derivative work, substantiality can be very interesting. For example, this is a separate work from the original.
https://en.wikipedia.org/wiki/L.H.O.O.Q.

US copyright laws also has "transformative" clause.
https://www.justia.com/intellectual-property/copyright/fair-use/transformative-use/
https://en.wikipedia.org/wiki/Campbell_v._Acuff-Rose_Music,_Inc.

But that also does not apply to programming, and US copyright law isn't used everywhere.

 

One problem you will have making an asset which requires other assets is you are then depending on the other assets both not significantly changing nor becoming deprecated. That's a lot of risk. I'd recommend contacting the developers of those assets and seeing if you can work out a deal for incorporating the parts of their assets you need into yours. Modify those assets so they are in a new namespace, so won't conflict with the full version of those assets if they are in the same project. This would let you lock in a specific version of these other assets and limit outside dependencies.

I'm sure doing the above is possible using the universal language of negotiation (aka you offer money up front).