The GPL does not allow you to add a non-commercial restriction.[1] While you can create such a license it will not be the GPL and incompatible with the GPL and possibly other licenses. In particular, such restrictions go against the Open Source Definition and the Free Software Definition. As a consequence, your library will not be usable by the open source ecosystem.
Defining commerciality.
Aside from philosophical concerns about what free and open source software is supposed to be, a non-commerical restriction has the practical problem that it is really hard to define commercial use. Any definition will either be too vague or too specific, will leave loopholes or accidentally outlaw intended uses.
A classic example for the commercial – non-commercial distinction is use by a non-profit organization. Consider these examples:
- The software provides spreadsheet functionality, and is used internally by a charity for children with cancer to organize their fundraiser. Is this use commercial?
- The software implements an Amazon Dash style button, but for donations to the Red Cross. Is selling and using this button non-commercial?
There are existing non-FLOSS license attempts to define non-commercial use.
The Creative Commons BY-NC 4.0 license defines non-commericial as “not primarily intended for or directed towards commercial advantage or monetary compensation” which is fairly vague and possibly outlaws intended uses, such as users being allowed to profit from their own modifications.
The widely criticized Commons Clause (unrelated to Creative Commons) defines:
“Sell” means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software.
While this is less vague this is extremely broad. For example, getting paid to contribute to your software might be disallowed. On the other hand this still allows products that do not derive their value “entirely or substantially” from your software, and it allows internal use by a for-profit entity.
Because of these difficulties, it is important to think very carefully about your licensing goals. Possibly, open source licensing or a pseudo-open license is not a good fit for your requirements. You may be more interested in an explicitly non-free “shared source” model where other people can read the code, but development stays under your control. In contrast, the (A)GPL can be summarized as “any use is permitted, as long as the source code of any published version is available (possibly with modifications), and downstream users are not deprived of these rights.”
It turns out that the (A)GPL is very unattractive for many commercial use cases so that you can sell commercial licenses. Consider Qt and iText for projects with this strategy. Note that those are libraries. In contrast, commercial use of unmodified applications is not hindered by the (A)GPL.
GPL and derived works.
As for when the use of a GPL'ed library renders the software subject to the GPL, this is a widely debated topic. To get the perspective of the FSF (the GPL authors), read the GPL FAQ, starting with the discussion of plugins to GPL systems and whether the GPL license of an interpreter extends to the programs that it executes.
One reasonable opinion is that using a GPL library in a software project cannot extend the GPL license to the complete software, because the other source code in that software is not derived from the GPL'ed code. However, the resulting software is derived from both GPL and non-GPL code.
To distribute this software you must comply with the GPL license, which requires the Corresponding Source of the software to be available under the GPL. This indirectly requires any other components to be available under the GPL or a compatible license (such as MIT). This e.g. implies that a GPL'ed software cannot use proprietary libraries, unless the copyright holders of the GPL'ed software provide an exception for that library.
With this argument, it is irrelevant whether a GPL library is called by other software, or a GPL framework calls a differently-licensed plugin. However, no obligations if the GPL'ed code isn't distributed. For example, it is possible to build proprietary software with a GPL'ed build system such as autotools, as the built artifacts do not contain any GPL'ed code.
Some people disagree with this argument, but insist that a software that includes GPL'ed code is not derived from the GPL'ed code. Then, no obligations arise to publish any code except for the GPL'ed parts themselves. Under that interpretation the GPL and LGPL are equivalent, possibly even weaker. While this interpretation has merit it is not mainstream in the open source community. From a risk-management perspective, it would be unwise for a company to rely on this argument.
[1]: In section 7 of the GPLv3: “All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.”