Hi guys,
I am wondering if I am allowed to use third-party DLLs as part of my asset I am planning to sell.
The DLL is a JSON parser which can be found here: https://lbv.github.io/litjson/
The point is that its license states that I can copy, modify, distribute it for both commercial and non-commercial purposes.
The license can be found here: Deed - CC0 1.0 Universal - Creative Commons
Since it’s fine by the maker of this DLL, I am wondering if Asset Store is okay with it.
Thanks in advance 
Yes, that one even doesn’t need you to credit the author, being public domain.
As @orb said, it’s public domain so your good.
I would suggest though, that you include the source with asset and links to the repo. You are adding another layer of dependency for the end user, make sure they have all the resources they need. Additionally, several users have expressed that they won’t purchase assets that don’t include source if a dll is used (myself included). Including the source will probably prevent losing a few sales.
Do you think this is necessary for freely available 3rd party stuff that’s already open source? I’d be happy with a link to the project and a version number, myself.
How obscure is the asset and how likely will the source remain online? If the source were only available in one location and that location were at risk of going off-line (like Google Code will be come Jan 25th 2016) I might be inclined to bundle the source. Granted I could just mirror it myself somewhere and link that.
Unless Mac Os X version of unity can load dlls (which is doubtful), I’d avoid including any platform-specific files in your project. In general, including any platform specific binaries is not a good idea. Include source code instead and let compiler handle target platform.
There’s SimpleJSON on the wiki: http://wiki.unity3d.com/index.php/SimpleJSON . It is somewhat slow, but it is usable.
Providing the built DLLs are Mono compliant, Unity should have no issue using them on OS X or Linux for that matter.
Yes, the library in question is managed code (CLR assembly), so it shouldn’t be a problem:
The “Mono/.Net assembly” part is the important bit. It should drop right into Unity on any platform.
Thanks for replies guys,
@zombiegorilla I was trying to include source into my project, but there were compilation issues. So I had to include a link to the repo only.
The problem is that including the whole source of a DLL could be a nuisance for least skilled programmers who don’t need source code. Besides, that adds up additional memory for the asset, which becomes a problem for low-speed internet users.
Like @lorenalexm said, DLL should work on all Unity Editor platforms. I am using LitJson to export and import data of my custom inspector, so it’s not supposed to be in the game build.
Yet I am unsure if I should include DLL source of LitJson, either zipped or a folder of it.
To be on the safe side, you could compile the assembly yourself and provide that DLL. I recommend including an archive with the source you used to create it, so that anyone can compile it again. Bonus if you use MonoDevelop to create the assembly, so you know that anyone on any platform can rebuild it.
Any idea how to do that? 
Right, I forgot that Unity defaults for .NET 2.0 support, which removes, for example, default parameters from functions.
Including dll also may be a nuisanse for least skilled programmers, if the dll fails to function for whatever reason. Source code is preferable, as long as source is platform-independent.
Never knew that there are a lot of Unity devs that are still using dial-up connection.
We aren’t in the nineties or eighties. Connection is worth worrying about if your asset goes over 100 megabytes.
You should test your asset on Mac Os, preferably on several different configurations.
That’s because “it should work” is not good enough.
This.
Just include the source as an archive. Just linking to the repo, especially one you don’t control, could be problematic. It could simply go away, or if the author significantly changes it, the user will have to through old revisions to ensure it works properly with your tool.
I think there is a definitive post on the subject somewhere on these forums. I think you can figure it out from just looking inside MonoDevelop though. New project->Library->add Unity’s Mono assemblies as reference. As you’ve noticed, there might be some massaging needed to make it compile against Unity’s implementation of C#.
Then again, Unity also has JSON support built in now: http://docs.unity3d.com/Manual/JSONSerialization.html
The archive should preferably be a Unity package, such that the files are automatically extracted into the correct folders. E.g. in you case into an Editor folder.
If the source is meant to be built into a DLL outside Unity it might be better to just use plain ZIP. Or both
Obviously the Mac handles dlls. Both using and creating them. Dlls for plugins are fine, as long as source is available. The problem is when it isn’t and a developer needs to modify a plugin or the asset gets orphaned by the creator.
I am glad they have finally added support for JSON serialization. But I want to have a wide support for my plugin (starting Unity 4.6), which is why relying on the built-in solution is not an option for me.
From a customer perspective, it is preferable that if a dll is not working, I can simply extract the source files and work with those to resolve the issue. If they are not placed in the correct directories, I can easily waste a lot of time. With a Unity package, it will end up in the correct place automatically. As customer, I don’t care whether it was created outside of Unity. The source code is my fallback in the case that there is an issue and that fallback has to be as simple to use as possible.
Besides that, it can heavily simplify the workflow of a publisher when an issue occurs. You don’t have to compile it outside of Unity, import it and check whether it works. You can directly modify it in the Unity project and test whether it works. Then you certainly need to create the dll and test it again.
Agreed. However, including an unity package and a zipped mono develop project that can be use to just build the dll is the kind of thing that elevates a asset developer to rockstar status. 