One thing I’m wondering is how this package’s license (GNU LGPL v3) will work with other packages which desire to depend on it. I’m not going to bash your choice of license; I’m a fan of the GPL/LGPL/AGPL license family in general. Is the license that you’ve chosen intended to signify intent for how this package should be used?
P.S. This package looks awesome, and regardless of the license or registry situation, I look forward to giving it a spin! 
I’m not very good at this whole licensing thing. I chose LGPL because it would let people include the code in a project without restriction (as opposed to GPL), but have to include any improvements they made. What usage intent have I signified?
After reading into the LGPL a bit more, I think my original assumptions about how it works are incorrect, so nevermind! 
For reference: I had somehow assumed that an LGPL-licensed library is only allowed to be used with other non-*GPL code when that code is dynamically linked to the LGPL library (which Julia does not do with package code; it’s more accurate to consider JIT’ing to be static linking). So I was worried that the only other packages that could be used with your package was other *GPL packages. But I don’t think that’s how the LGPL works from my more recent readings.
EDIT: My confusion was that I conflated the LGPL with the “linking exception” used by some GPL software.
Please consider a MIT license (or the equivalent ISC) like the rest of the ecosystem! That saves every Julian from thinking twice before depending on your nice work!
Definitely will do that for my personal work! This work was done via my employer, Emagin, so this was the most liberal license I could get.
I don’t think that LGPL is meaningfully different from GPL in Julia since we don’t dynamically link anything (although it may allow Julia to dynamically link GPL-incompatible dynamic libraries, e.g. MKL). So basically the effect of this is that any Julia program that uses this package will have to be effectively GPLv3 in the end but may depend on GPL-incompatible dynamic libraries. You may also want to consider the Apache 2.0 license.
Of course I’m not a lawyer, but may understanding of the LGPL is that it doesn’t require that a derived work must be released under the same terms as a whole. The requirements should be to specify the license of the LGPL library and provide any modification to its source code.
I read a few blogposts about licenses. It seems to me that MIT, Apache 2, and BSD are among the most permissive but Apache 2 appears to be clearest about patent rights: “the software can be used regardless of software patents which are in effect, without any further obligations.” and “software users can’t initiate litigation over patent infringement (and if so, they lose their license).” What is the MIT License? Top 10 questions answered | Snyk
see also:
2. The MIT, BSD, Apache, and Academic Free Licenses - Understanding Open Source and Free Software Licensing [Book]
Why Choose Apache-2.0 License?. A Carefully Weighed Decision | by Rob Muhlestein | Medium
I have the impression that if a developer prefers copyleft licenses but wants the software to be compatible with permissive licenses, then LGPL is closest to the permissive family. Would appreciate correction if I misunderstand the implications.