[PanoTools-devel] Alternatives

[Daniel M. G. <dm...@uv...>]

 yuval> not to play devil's advocate but Joost has the
 yuval> *functionalities* in PTgui already.

 yuval> Wouldn't it be easy for him to pack these
 yuval> functionalities behind the same interface in a
 yuval> separate DLL?

 yuval> Wouldn't this be the "independent library with the
 yuval> same interface?

 yuval> I would very much prefer a friendly, negotiated
 yuval> solution than a run on finding the next loophole.

The ones that are not alternatives:

* If we start using GPL libraries within libpano we can't guarantee
  that they don't sue somebody who uses libpano via dynamic
  linking. In fact, I would argue that if we state that we allowed
  dynamic linking explicitely then we risk to be found contributory
  infringers of the GPL of those other libraries (who do not accept
  dynamic linking).

Several alternatives:

1. PTgui releases a LGPL library of the code that has been created to
  reimplement libpano12. I commit to contribute to this LGPL library
  and to transfer the copyright of any of my contributions to PTgui
  (or whoever PTgui requests). PTgui would be the maintainer of this
  library.

2. Accept that libpano12 is only for Helmut to resolve (and its
   authors), even if we don't agree with the way it is currently being
   used. libpano13 will not accept dynamic linking.

3. Any tool that is currently using libpano12 (dynamic linking) will
   stop doing it. libpano13 will not accept dynamic linking.

4. We will not care who and how uses libpano12 and libpano13.

I personaly like option 3 the best, followed by option 1.


--
Daniel M. German                  "Heisenbug is a bug that disappears
                                   or alters its behavior when one
   Jargon Dictionary ->            attempts to probe or isolate it."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .