I meant to stay away from this discussion, after all I haven't contributed anything yet...
But from what I read, I think I'll stay away from this library. You guys know your subject really well and this library is most probably the main reference on the subject. So, it would seem like a logical package to look at for any application that wants to do anything remotely related to panoramas.

But then, if there is any chance that the software could make a penny, then the use of your library might simply jeopardize the whole business. This last comment about what constitutes a subterfuge and what doesn't is very scary, I bet that if you pay your lawyer enough, then any use of panotools (even through fork/exec) could be presented as a subterfuge and the "offending" software would have to fall into open source.

I'm worried that such a lawyer might even sue people doing similar features who would have learned the techniques from reading your code.

Some people can afford to donate their time, some people can't. I would have hoped that you guys would be able to find a less hardline position where, for example, those who make money out of linking panotools might contribute some $ to help run the initiative. After all, non-profit doesn't mean no-income.

That said, I do respect your decision, it is your code, you decide on your terms & conditions.
I'll come up with my own code.
Jerome Muffat-Meridol LRPS - http://www.webphotomag.com
- the online magazine about photographs, not cameras-

JD Smith a écrit :
On Tue, 30 Jan 2007 10:43:46 +0800, Joost Nieuwenhuijse wrote:

JD Smith wrote:
If you take a look at the text of the LGPL, it says:

"A program that contains no derivative of any portion of the Library, 
but is designed to work with the Library by being compiled or linked 
with it, is called a "work that uses the Library". Such a work, in 
isolation, is not a derivative work of the Library, and therefore falls 
outside the scope of this License."
What such a "work that uses the Library" does *not* fall out of scope
of, however, is the GPL license. 
The GPL explicitly limits its validity to derivative works (in the first 
clause of the license text). Further, the above explicitly states that a 
"work that uses the Library" is not considered a derivative work.

Only in the context of the LGPL.  In fact, the LGPL does not make the
distinction of "derivative works" vs. "non-derivative works", but only
of "works that use the Library" vs. "works that alter the Library".
The one doesn't transfer to the other.  The former is essentially
defining the boundary where the LGPL must be applied.  I'm surprised
you think that same boundary would apply to the GPL.  If it did, they
would in effect be the same license.

I agree that I'm mixing two licenses here, but I'm mixing the 
definitions, not the license conditions. Those definitions can be 
considered quite universal.

Not only is that reading not supported by the licenses themselves, it
runs against the majority interpretation of free software projects
everywhere.  Even Linux, with its reasonably lax reading of "derived"
to accomodate binary kernel modules for the likes of NVidia, draws the
line at programs which make use of internal data structures, and are
written specifically to an interface.

 If a library is released under the GPL (not the LGPL), does that mean
 that any program which uses it has to be under the GPL?

     Yes, because the program as it is actually run includes the library.

Note that it doesn't say "any program that distributes it", but rather
"any program that uses it".  It doesn't matter how your user came to
obtain the library.
But the program as distributed does not include the library. Copyright 
law protects distribution and publication. What the user does with the 
software is irrelevant, as long as he is not redistributing.

This is essentially "using technical means to circumvent the license",
and has been considered again and again throughout the history of the
GPL.  Yes, you can conceive of a variety of technical tricks to
seemingly avoid having the license apply to you.  Here is what RMS
wrote in part regarding these methods in 1993:

                 Can Technical Tricks Circumvent the GPL?

  People often speculate about technical procedures that might
  circumvent the GPL in some way.  For example, they may suggest a
  modified version could be cut artificially into two pieces, one free
  and one proprietary, that are called two independent programs.

  This kind of scheme is based on the premise that the legal system
  operates in the fashion of a stupid computer program, and that
  superficial manipulations of the way files are grouped and labeled
  would fool it.  While the legal system often does seem stupid and
  easily fooled in comparison with common sense, the FSF's lawyer told
  us that it would not be stupid about this.

  The lawyer said that such a scheme would fail because a judge would
  regard it as a subterfuge.  The judge would conclude that the two
  parts are really one program in disguise, and go on from there.

  Our lawyer also said that a judge would tend to be harsh toward anyone
  perceived to be trying a subterfuge.

By the way, PTGui would run with any library that has the same interface 
as pano12. If someone wrote such a library, would PTGui automatically 
violate its copyrights?

This is the same exact argument GSL (the scientific library considered
for use by PanoTools) went through:


If you actually did re-implement the panotools API, put it in the
public domain, or license similar from another party, and could show
that the two API's are compatible, then you might have a leg to stand
on.  But until such time, I believe any court would look very sourly
on such an argument.

Moreover, and more relevantly, the developers of GSL have made quite
firm their strong stance against this method of evading the terms of
their license.  This makes it uncomfortable to consider including GSL
in PanoTools (which it appears would be technically very compelling).
Consider that your actions, instead of aiding the free library which
gave you your start, could actually inhibit it.

I have one more important argument: even if the GPL would have contained 
a clause which explicitly forbids third party programs to interface to 
it by calling functions in the library, such a clause would have no 
value at all. The reason is that a software distribution license can 
never be more restrictive than copyright law itself. Copyright law 
doesn't prohibit me to interface to a third party library and therefore 
that library's distribution license is irrelevant.
You've got this argument backwards, unfortunately.  By default, US
copyright law (and, in my understanding, European as well) gives you
exactly *zero* rights regarding the distribution of a given piece of
copyrighted code or derived works based on it. 

We're saying the same thing basically: copyright law forbids certain 
things, and the license grants certain permissions. So the license is 
more permissive than copyright law.

But my point is: if copyright law does not forbid interfacing to a third 
party library, then a distribution license cannot prohibit that either 
because it would be more restrictive.

I agree.  But copyright law grants zero/zilch/none/no/nada rights
regarding your distribution rights of a piece of someone else's code
(or code derived from it)!  It forbids *all* uses, other than fair
use, to anyone aside from the copyright holder.  If you bought that
code on a CD, you have the right to read the code, and the physical
property rights to that CD.  You can sell it, burn it, use it as a
frisbee for your dog, anything, but regarding the code itself, you
have no natural rights.  If you found a piece of Microsoft's code
lying on the street, would you feel you had the right to use it?  Just
because the software's source is freely available, doesn't mean its
use is not restricted.

The GPL places *very few* restrictions on code, but it does require
that if you take, you have to give back.  Since GPL code in general
doesn't generate an income for the people who write it, this give and
take is their payback.  That's why they do it.
Let's back away from the legalities for a moment.  The entire point of
the GPL, and one of the main motivations of those who contribute code
to GPL projects, is to build a increasingly powerful collection of
free (as in freedom) and openly available software.   If closed code
can link directly to GPL code, a barrier which has been erected quite
purposefully has been knocked down.  That closed program can extend
and improve that library on its own side of the fence, all without
contributing these improvements back.  This isn't malicious, it's just
a natural consequence of dropping this protective barrier.  That is
the danger, and that is the reason why the GPL is so hard-nosed about
such use.

I respect the work you have put into PTGui, and I think the entire
PanoTools community owes you a debt of gratitude for where it is
today.  I also respect your desire to make a living doing what you
love to do.  Please just realize that there are many contributors,
possibly including the first, who is notably absent, who have donated
countless hours of their time and energy contributing to the GPL code,
specifically because they value the principles and goals it espouses.

In some ways, the PanoTools community is a symbiotic one: to attract
attention and interest, the core library relies heavily on the
front-ends GUIs (one of which is GPL).  This brings many types of
users into the community, including technically minded ones, many of
whom are inspired to donate their own time to improve the free library
(add projections, optimize reprojection, etc.).  The GUI's authors are
often similarly inspired.  These improvements then feed back directly
to the GUIs, enhancing their value.  The library improves, the GUIs
improve, and more users are attracted to the community.  It's not a
traditional arrangement, but it's a compromise that has worked well.
To keep it working well, the terms of the library's license must be
I agree. And in fact I am forced to respect it license. I am also 
willing to respect Daniel's wish to not dynlink to pano13 anymore, 
regardless whether this is enforced by the license or not. This will 
probably mean that PTGui's support for Panorama Tools will end at this 
point, since attempting to support it through the cmdline will be quite 

I hope that instead of throwing out the baby with the bathwater, you
might consider contributing back to PanoTools those things you need to
make PTGui operate and improve.  I realize you may feel a strong
motivation *not* to do this, since then the other GUIs get access to
that code as well, but I believe the strength of your product is in
its compelling and well-written interface.

Why not give back to the library which has given so much?  Your
contributions would have a life outside of PTGui, and even after you
move on to other things, your impact will be felt, just as Helmut's
impact has been felt now 5 years after he was forced to stop
contributing?  If you are in compliance with the library's license,
you can of course distribute it with PanoTools without any issues, and
your users would enjoy much easier access to its many capabilities
(which are growing day by day).

The PanoTools ecosystem is unique, in that it attracts technically
minded people who can roll up their sleeves and get dirty improving
things.  How many people have written a new projection for PanoWeaver
or some other fully commercial package?  Why not leverage this unique
benefit, and help this spirit continue?

But a have a legacy to support, I can't simply remove functionality from 
PTGui that has been there for 6 years (and not a single person has 
complained about it until now). Unless I would be breaking the law of 
course. I guess we will keep disagreeing on that point, but I really 
hope we can all accept the status quo and go on from here.

I think that's a reasonable solution, though since I don't hold
copyright, it would be up to the PanoTools copyright holders.  Pano12
was largely copyright Helmut, and he has essentially implicitly let
others use his work to position their products in the market.  Maybe
he didn't object, maybe he was just happy to have PanoTools used by
many people, whatever the means.  But looking to the future, it makes
sense for everyone involved in the PanoTools ecosystem to play by the
same rules.

[1] Here's another way to think of it: suppose you stumbled upon a
copy out on the internet of a binary accelerator library which sped up
large pano stitching by 100x.  The company which wrote the accelerator
normally licenses its use for $1000 per seat, and provides the API on
their website.  I very much doubt you'd feel you have the right to link to
this library, pointing customers to the website where you found it.
Not if the copy is illegal (e.g. posted on a warez site). But if the 
accelerator is distributed in a legal way (e.g. from the company's own 
website), I see no problem in having PTGui use the library if installed. 
Much like checking for the presence of DirectX and using it to speed up 

Your copy of PanoTools, if used without respecting the license, is
just as "illegal" as the "warez" version of a binary library you
found.  Just because you can point to sourceforge, and anyone can
easily find the code, doesn't mean your rights to use that code are
unrestricted.  That's the whole reason for the existence of a license!
I bet if you dig through your docs, you'll find some EULA license (or
four) governing the use of DirectX as well (and it won't be nearly as
generous as the GPL!).

Joost btw: I appreciate the discussion here, thanks!

I'm glad you're willing to discuss it too.



Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
PanoTools-devel mailing list