I meant to stay away from this discussion, after all I haven't=20
contributed anything yet...
But from what I read, I think I'll stay away from this library. You guys=20
know your subject really well and this library is most probably the main=20
reference on the subject. So, it would seem like a logical package to=20
look at for any application that wants to do anything remotely related=20
But then, if there is any chance that the software could make a penny,=20
then the use of your library might simply jeopardize the whole business.=20
This last comment about what constitutes a subterfuge and what doesn't=20
is very scary, I bet that if you pay your lawyer enough, then any use of=20
panotools (even through fork/exec) could be presented as a subterfuge=20
and the "offending" software would have to fall into open source.
I'm worried that such a lawyer might even sue people doing similar=20
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=20
have hoped that you guys would be able to find a less hardline position=20
where, for example, those who make money out of linking panotools might=20
contribute some $ to help run the initiative. After all, non-profit=20
doesn't mean no-income.
That said, I do respect your decision, it is your code, you decide on=20
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 =E9crit :
> 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=20
>>>> isolation, is not a derivative work of the Library, and therefore fa=
>>>> 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.=20
>> The GPL explicitly limits its validity to derivative works (in the fir=
>> clause of the license text). Further, the above explicitly states that=
>> "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=20
>> definitions, not the license conditions. Those definitions can be=20
>> 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 mea=
>>> that any program which uses it has to be under the GPL?
>>> Yes, because the program as it is actually run includes the libr=
> 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 anyon=
> perceived to be trying a subterfuge.
>> By the way, PTGui would run with any library that has the same interfa=
>> as pano12. If someone wrote such a library, would PTGui automatically=20
>> 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 conta=
>>>> a clause which explicitly forbids third party programs to interface =
>>>> it by calling functions in the library, such a clause would have no=20
>>>> value at all. The reason is that a software distribution license can=
>>>> never be more restrictive than copyright law itself. Copyright law=20
>>>> doesn't prohibit me to interface to a third party library and theref=
>>>> 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.=20
>> We're saying the same thing basically: copyright law forbids certain=20
>> things, and the license grants certain permissions. So the license is=20
>> more permissive than copyright law.
>> But my point is: if copyright law does not forbid interfacing to a thi=
>> 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 o=
>>> 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 jus=
>>> 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 librar=
>>> (add projections, optimize reprojection, etc.). The GUI's authors ar=
>>> 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=20
>> willing to respect Daniel's wish to not dynlink to pano13 anymore,=20
>> regardless whether this is enforced by the license or not. This will=20
>> probably mean that PTGui's support for Panorama Tools will end at this=
>> point, since attempting to support it through the cmdline will be quit=
> 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 fr=
>> PTGui that has been there for 6 years (and not a single person has=20
>> complained about it until now). Unless I would be breaking the law of=20
>> course. I guess we will keep disagreeing on that point, but I really=20
>> 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.
>>>  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 u=
>>> large pano stitching by 100x. The company which wrote the accelerato=
>>> 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 li=
>>> 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=20
>> 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 installe=
>> Much like checking for the presence of DirectX and using it to speed u=
> 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=
> opinions on IT & business topics through brief surveys - and earn cash
> PanoTools-devel mailing list