For simplicity, it is probably best to release the entire thing under GPL. 3-clause BSD license has no form of copy-left, so you are well within your rights to rebrand it, as long as you maintain its notice.
You will end up with two kinds of files:
- Originally BSD files: needs to have both headers, order isn't important to my knowledge, just that they are there
- Your files and originally GPL files: need to have the GPL header
And of course for any binary release you will need to include a link to source and both headers in some form of another. I would recommend the standard GPL, followed by "Portions of this program were originally released under the following license" or something like that, you can likely find examples of this happening in the wild if you look for it.
Note that I am not a lawyer, nor do I specialize in either open source licensing, or licensing in general. I am simply relaying what my interpretation of the given licensing combined would look like.
No, you probably don't need to put the BSD reference into the library, but you should.
When you re-release the BSD component within your GPLv3 package you are re-licensing the BSD component as well. At that point, the only license text that's required is the GPLv3 one.
The GPLv3 license contains the same or similar clauses as the BSD license. In particular, section 4 requires maintaining the copyright notices. Sections 15, 16, and 17 handle the disclaimer of warranty. And the section "How to apply these terms" goes into the details on propagating the conditions of the license.
However, as a courtesy to the original authors on the BSD licensed component, you should provide full attribution and a copy of the BSD license. Effectively you're saying "If you want to use this component from my distribution, then it's under GPLv3. However, you can access this component from its source under a BSD license."
Some supplementing points.
It means that the other license and the GNU GPL are compatible; you can combine code
released under the other license with code released under the GNU GPL in one larger
program.
All GNU GPL versions permit such combinations privately; they also permit distribution
of such combinations provided the combination is released under the same GNU GPL
version. The other license is compatible with the GPL if it permits this too.
The very last sentence (The other license is compatible...
) in that quoted section along with the preceding combination clause (they also permit distribution...
) is your permission (and requirement) to distribute the combination of your project + lxml as GPLv3.
The BSD license (without the advertising clause) is on FSF's list of compatible licenses. Specifically here. This is the same license the lxml team is using.
- Whether you provide a copy of lxml source is kind of a moot point.
Your program won't work without their program, so you can't really get around dragging their program into yours from a licensing point of view as far as the GPL is concerned. It's a "known" circumvention trick that isn't allowed. Fortunately, the licenses are compatible. Because you are choosing to release under the GPLv3 then you're re-licensing the lxml project as expressed / instantiated in your project. Essentially, you've forked the license on lxml but only for within your project.
The lxml team can continue to update and release their code under modified BSD, but the instantiation you use and any modifications you make to it within your project are considered as GPLv3. Note that you could still contribute directly to lxml and then they can release your contribution as BSD. But you can't do that through your GPL project.
Best Answer
Developing your library and daemon as one project, but releasing them under different licenses is probably fine, but I would advise against it. Unless you have a very clear project structure that separates the sources of both parts, you are likely to run into a situation where it becomes unclear which part a particular source file belongs to. And even if you do have a clear separation, the situation is less clear for common files. It is possible that it can be argued that those files are dual-licensed, which might make the GPL apply effectively also to your library. You should consult a lawyer to get that cleared up.
A better alternative is to split the library and daemon into two separate projects (both maintained by you), where the daemon project depends on the library.
It is certainly possible to use BSD-licensed libraries in a GPL-licensed product. Most BSD-style licenses are compatible with the GPL license, which means that you can legally distribute a product that uses both GPL and BSD-licensed parts. If parts are GPL, the entire product must comply with the restrictions set out in the GPL, but that does not affect (separately obtained) copies of the (BSD) library.