In your current license document you state: » If you produce a product that includes or requires Saxon, please refer to it prominently as "The Saxon XSLT and XQuery Processor from Saxonica Limited", and include the URL of the home page, which is at http://www.saxonica.com/. As a courtesy, please take reasonable steps to ensure that your users know that they are running Saxon.«

Before digging deep in legalese, why not do a »Web 2.0« thing and create a platform where products that rely on Saxon can be listed with an indicator if the producers comply to the above request. This can at least create some awareness in the community.

Another thing is an easy way for companies to license Saxon. Offering Credit Card or PayPal payments is not easy enough. Also the licensing options could be a lot clearer; I would drop the 030/040/050 options altogether and wait for a simple Enterprise/Professional/Home scheme with steeps discounts for multiple licenses.

- Michael Müller-Hillebrand

Thanks for the suggestions. I've thought about a "naming and shaming" approach, but I think it's too much hassle to maintain and too likely to cause upset. Ease of purchase is certainly an issue for some companies, but mainly because of the complexity of their own internal processes: probably the best thing I could do here would be to point people to resellers in their local country (American corporations in particular seem to find it culturally difficult to purchase from a non-US supplier; and many companies find it easier to purchase via a third-party such as SHI to avoid setting up a new supplier on their database). I agree that the XSLT-only and XQuery-only variants are probably more trouble than they are worth (there are not many takers), but the XSD-only variant has a few customers who purchase in volume, so I should probably retain that as a "Validation Edition", perhaps with a separate software build.

Fun !

I was about to write something around that on my blog ...

Look at Creative Commons http://creativecommons.org/

Mohamed ZERGAOUI

The Creative Commons licenses are much better written than GPL (and most other software licenses) - unfortunate that they recommend not using them for software!

One big question is: "if a non-GPL software S dynamically links to a GPL library L, is S a derivative work is L"? There is no clear, legal answer to that question at this point [1]. There are just opinions. Your opinion is that, "no, S shouldn't be considered a derivative work of L". I agree, but since this argument hasn't been settled, a court could disagree with us.

a) Obviously, if a court were to disagree with us, it would just be illegal for a vendor to distribute S. And most lawyers will stop their thinking here: since the matter hasn't been settled, and there is a good chance for this to be illegal, they will just advice their client not to use any GPL code in their software.

b) But even if a court were to agree with us, the vendor of S would still have to ask its users to download and install L separately. Imagine that S uses a number of libraries (L1, L2, L3...). It will quickly becomes unpractical to ask users to download and install all those libraries before they can use S.

Choose your poison: illegal or highly unpractical. Most will say that the best option is to avoid the poison altogether, i.e.: don't use GPL software.

With this in mind, some companies figured that they could distribute their software as GPL and brand it as open source, knowing that most of the people interested in that software won't be able to use it under the GPL, and will have to acquire a commercial license. This is very much like the dealers who advertise a car that normally sells for $20,000 as a "$5,000 special for this coming weekend only", writing in the fine print that this offer is limited to 2 cars. In both cases the vendor isn't technically a liar, but just knows that most of his client just won't be able to get the car for $5,000 (they will have to pay $20,000) or won't be able to use the software under the GPL license (they will have to acquire a commercial license).

Yes, apparently that trick works for some dealers, and some software vendors. But it is not a trick I feel comfortable with. Especially since there are other ways to sell licenses; as the publisher of an "open source for all" software (licensed under the LGPL, Apache license, BSD...) you have at least two ways to drive licensing revenue:

* Selling versions that contain additional features for which the code isn't open source. Not need to elaborate on this one, since this is already something you are doing today.
* Selling "certified builds". Those are builds 100% based on the open source code but that are only provided to your clients who acquired a license. You would then provide updates (bug fixes) for those builds. This is what RedHat does with their RedHat Enterprise Linux, and I find this particularly interesting because it has been working quite well for them, and is something that provides real value to companies without precluding the use an "open source for all" license such as LGPL.

[1] http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works

Interesting discussion.

What this boils down to is that many of us producing open source software would prefer it if rich corporations (especially) that depend on it paid us (the developers) for the resources we have put into development. To get this to happen these users need to be incentivised/forced to pay -- being businesses it is practically their duty if, given an option to use something for free, they will take that option.

In my gut I agree with Alessandro that there seems something a bit distasteful about the GPL, But looked at from a business perspective is it really such a "trick"? The proposition seems quite straightforward to me: for organisations that wish to distribute functionality a fee is required to rid themselves of the toxic implications of the GPL. For "normal" users who just wish to use the software, this is not a problem, and for the freedom brigade who are happy to redistribute GPL'd derivates this is again, no problem. So in this way the GPL is a crude (but effective) means of enforcing a kind of differential pricing policy.

As a company, we're coming at this from an opposite direction - turning a product family using traditional fee-paying licence into a product family which is FOSS. We're going to use the AGPL as the FOSS licence for just this reason. In our judgement, corporations which wish to distribute functionality/products based on our software should (continue to) pay. At the same time we are hoping the legitimate free use of the software will drive adoption.

Still, there is no firm answer how best to monetize (ugh) FOSS. Part of me thinks FOSS itself was (/is) its own kind of bubble ...

- Alex.

Berkeley DB XML uses the Sleepycat License to do what you want to do:

http://www.opensource-definition.org/licenses/sleepycat.html

Thanks for the reference. I was actually searching for this yesterday, having come across it before, but I couldn't remember the name! It's nice that it doesn't have the polemic associated with GPL; though it still seems to suffer the problem that it's easily circumvented by asking the user to download the support library separately from the application. (But perhaps loopholes like that are not fatal commercially, as Alex points out?)

I'm sure an Oracle lawyer would find a way to argue against that. As the patent debate has taught us, it's not actual infringement but the threat of litigation that really stops a business from doing something.

If you're thinking about changing licensing, you should seriously consider the problem of companies who don't redistribute at all, but expose your functionality over a network. The AGPL has some definite advantages in that respect.

I'm sure Oracle lawyers are highly creative. But in the end, a license is only needed to permit you to do something that would otherwise be a breach of copyright, and it's hard to see how distributing an application that calls X, without distributing X itself, is an act that even requires a license, since there is no violation of X's copyright. That's especially true of course if X is called via public interfaces such as JAXP, XQJ, or JDBC.

When it comes to the question of risk, I guess users are probably more frightened of defending an unfounded allegation from Oracle than they are of defending an unfounded allegation from Saxonica!

Don't be so sure. Judges are fairly good at catching exceptions like "The user has to download it himself" and casting them to "You are an infringing distributor."

In particular, the DeCSS/2600 decision, though turning on circumvention rather than copyright, settled (in the U.S., at least) that linking is equivalent to distributing in certain circumstances, and since linking is just a convenient form of citation, saying "Go and download X to use this program" may be constructive distribution of X.

I am not a lawyer; this is not legal advice, but it is not the unauthorized practice of law, either.

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.

You make some very good points here, notably the fact that one actually wants to encourage some "free" use of the software to create the market and brand for the paid-for version, and a lot of the difficulties in finding the right packages and licenses are actually problems in defining exactly how one wants to deal with different parts of the market.

Maven incidentally already violates the Saxon license by distributing the executable code without the accompanying legal notices. Some people are scared to do things that the license does allow, others are not scared to do things that it doesn't! It's a funny world.