There are 2 other issues I'd curious how you'd address. I too have had a hard time understanding licenses and their real meanings. For my personal project my goals are different in that I want anyone to use it without obligation to me of any kind. For that I chose the "BSD" license because its something I believe I can understand. The GPL licenses (2 and 3) are so complicated that I cannot understand them, and I'm not sure even lawyers would come to the same conclusions. Furthermore, to my reading the GPL seems to have somewhat of a "Political Agenda" of trying to force all software to become "free" so anything that touches a GPL licensed product becomes infected with it ... So I stay away from it myself. But here's questions. 1) What is your goals for licensing Saxon (B) for use in purely open source products ? Say product B uses Saxon. Presumably your intent is that users B would have to have the same licensing rules *for the use of the saxon component" as if they used used Saxon. But do you do that by forcing Product B to use the exact same license as Saxon ? I think that would be a detriment. Say the intent of Product B was less restrictive then Saxon, it wouldnt be right to force the license for B to change. Even if product B wouldn't be usable without saxon, perhaps the authors would like people to be able to edit the source code of B and repackage/resell it ... then I suppose they would have to come to grips with Saxon's license (but hopefully not with Product B's as well). I guess this all comes down to your first issue about how to define "derivative work" and if people can bypass licensing issues by having the end user download the Dependant libraries. At some point someone will come up with something like maven which can just go out to the net (say sourceforge) and download dependant products automatically removing the frustrating aspect of this. 2) Internal corporate use. What are your intents with Saxon B for use for internal use only in companies ? For example, in programs that a company uses but does not sell. Where is the dividing line ? Would saxon jar itself have to be physically used within the sellable part of a product ? or is it sufficient that saxon was used to create content ? For example. Suppose Company X sold an ebook reader. If saxon was used *inside* the ebook reader then I would think that a saxon comercial license would be required for every copy of the ebook (?). However suppose saxon was used in the production of the content - in the "Back Office" maybe on one persons desktop. Would a comercial license be required ? In that use they wouldn't be using saxon in a product they sold (the ebook reader). It can get even slippier. Suppose they sold the "content" that was produced (the "ebook data file") now the content doensnt 'contain saxon' but what if it was created with something that used saxon ? would a license be required for that ? Similarly say for the runtime (like java) ... where would its licensing be required ? And if the content creation process ran on Linux ... Surely an ebook using all those technologies in some ones interpretation would be a "derivative work". My personal opinion being biased because I am NOT a legal expert is that this is a very very complicated world. For the most part, if you "give away" software its prety much impossible in practice to define all the variants of these kinds of use, let alone legislate and enforce it. I believe your current licensing scheme is about as close as practical, you separate the functionality into A and B and hope that there is enough extra value in B for people to pay for it. If you didnt "give away" A in some kind of simple to understand way so that people (especially corporate legal departments) were not terrified of using it without triggering a lawsuit, you would likely have a hard time selling B without a huge marketing arm. So in a real sense, "A" is your marketing department. You ask how Mysql does it ? Not sure about the licensing part, but from the business model, Mysql does it in a very similar way. They have a "free" component with minimal restrictions, and a "paid" version with different value-added components bundled with a services plan. I'm not really sure how many 'open source' products can emulate this model and make money. Its been tried over and over with some successes and vast failures. I am guessing that one of the keys in the success stories are products which are difficult to customize/optimize/maintain ... and with a high value in doing so. Also cases where the "free" version is sufficiently usable that enough people use it and get addicted, then want "a little more". Databases fall into that, same with "servers" like linux and JBoss.