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
Well, I don't know where your problem is, however next to keeping your code under BSD you could also dual-license it under GPL which will help you to keep headaches out on your end if licensing causes you some and you don't want to consult a lawyer on your behalf.
That done you can keep all your code under BSD (next to having it GPL) to also full-fill requirements to distribute GPL'ed parts with it. You can do that by making clear to users who contribute code that they contribute it under both licenses.
That done its clearly your users choice. All you need to do when accepting patches is to take care that the BSD of your library code is preserved.
This would be similarly the situation when the GPL component would not be part of your library and a user would integrate GPL components with it. Because of the BSD, nobody is hindered doing that.
Users who don't want to have a GPL'ed package can just remove any GPL'ed parts and only use the parts under BSD. Just make clear with your dual licensing model is not conjunctive (GPL and BSD) but disjunctive (GPL or BSD) for the files you keep under dual licensing.
This would also help you with the problem offering a software package on Github containing GPL'ed software not under the GPL - which is what I see you right now doing with the Github hosting platform (it has automatic packaging).