I see two perspectives to this:

Legal: Can you do it?
I see no reason you can’t. I know there are some laws/rules about bundling other people’s libraries, but that would probably only be for proprietary libraries or with licenses that have very specific rules against including them in other projects (This was the case for a company I worked at). I am not aware of any legal reasons why you can’t have your end-user go download it themselves; I believe Ubuntu has gotten around this issue just by having end-users download the drivers manually.

Design: Should you do it?
I once ran into an issue using a library and was getting a very weird error that made no sense to me. It turns out the error was stemming from the fact that the library I was using depended on another library that wasn’t referenced properly.

So if you use the KineticJS library just make sure that if they don’t include the library that you throw an error that tells them that the KineticJS library is missing.

Sure you can build your library on top of someone else’s. People do that all the time!

You shouldn’t need the permission of the author of the base library to do this (because you’re just referencing their code), but you might need their permission if you want redistribute their library with yours. This will affect how your users get the base library: if you are allowed to redistribute, then all is well. If not, you will have to direct them to the location where they can download the library they need.

To think of it from the other side:

Unless you are writing assembly on the bare metal, you are pretty much guaranteed to require other libraries, e.g. the C standard libraries, your operating system libraries, GUI toolkits, etc. Somewhere along the chain of execution, your code will involve several other libraries.

Building upon the work of others is a fundamental aspect of code re-use, and we wouldn’t make much progress if every single project had to start from scratch.

So, you should approach whether to use KineticJS the same way you would for whether to use a given language, operating system, etc.

Building a project upon a library is never free, including a library also means including that library’s bugs and download size.

Sometimes one may be able to consider the library an independent piece of code that need no maintaining and doesn’t really count towards the complexity of the project, but often that is not the case. As a professional developer the only way I can really justify using some small found-on-the-internet library is if I take care of that code as if it were my own. Maybe the original develop will fix a bug if I find one, maybe he won’t and I’d have to do it.

Ultimately an included library is part of the codebase, and as such count in every negative way like any other code. It may be good relatively bug-free code with a clean interface that thus doesn’t weigh much relative to its size, but the weight is never zero.

If library A depend on library B then including library A in my project implicitly adds the weight of both libraries.

You always want a library to be as lightweight as possible, including another library will almost always work against this goal. In some cases this will be a small extra weight added for a large benefit in saved work, in other cases it is a lot of weight for very little benefit.

Conclusion

Usually you should avoid library dependencies in libraries, but there are cases where the cost to gain ratio is low and it is acceptable. The following conditions in general make the use of a sub-library more acceptable:

• The library used is a widespread one that generally has few bugs and is well supported.
• All or most of the functionality of the library is being used, if the needed functionality were to be re-implemented the combined code-size would not be a lot smaller for it.
• The library deals with issues that would be hard to solve without it.