It's possible to restrict LogTree.Internal to be visible only within the package (see cabal's other-modules field), but please don't do so. You will inevitably fail at providing every necessary function or accommodating all reasonable uses of your library. Then some user will either write their own, use something else or, if you're lucky, fork your library and send you a merge request. It will happen (unless you have no other users).
As a recent example, I was using a library that had an internal data structure, 'A' (completely unexposed) as part of an exposed data structure 'B'. Both had 'deriving Generic' clauses. However, the Generic instance of 'B' was mostly useless because if you wanted to use the Generic instance to declare e.g. 'instance Binary B', it's also necessary to create a Binary instance for 'A'. Which was impossible for users, because 'A' was completely unexposed. When I pointed this out, the library's author graciously accepted a patch to expose the type constructor 'A' (I'm not entirely happy with this solution either, but for now we can't think of anything better).
You could take this as an implementation flaw of Generic as it's currently implemented (which it possibly is), however I would hope you also take it as a demonstration of how data abstraction can interact with many different language features in often-subtle ways. I think erring on the side of allowing users maximum freedom is the best choice for now (preferably stashed in modules/functions with names like 'internal' or 'unsafe').