From: Erik K. <eri...@gm...> - 2007-01-26 00:35:13
|
On Thursday, January 25, 2007 at 23:24, Pablo d'Angelo wrote: [...] > On the other hand, > have you considered which new features and abilities have been added in the > last 1 or 2 years to panotools, because PTGui has used panotools? > > NONE Could well be. But where would panotools be without PTGui? Would there be any interest? When my interest in panoramas began I tried to use panotools - and failed miserably. No way to do anything with the copy and past barcode flags as control points. Guess how many others would have thrown this away (like me) because they thought it was unusable? PTGui made panotools to the most widely used stitching engine. > Instead Joost has choosen to reimplement improved functionality inside > PTGui. This was probably a little easier, but also gave him an advantage on > the market over PTassembler and hugin. I wasn't very fond of this step either. Infact I sent an angry email to Joost expressing my fear of the disruption of panotools development. Much the same what drives me to write this here. > PTGui just needs panotools because of > the fisheye patent, so there is not danger of getting sued. > > All the new functionality that has been added lately to panotools was > implemented by other developers not affiliated with PTGui. And users of > PTGui have not contributed new code either. Jim Watters, Rik Littlefield, Thomas Rauscher? Even Joost has contributed a patch... [...] > > On the other hand command line programs cause even more problems and I > > consider it a bit outdated to restrict a fantastic set of functionalities on > > the use via command line programs. > > Hugin and PTassembler are not command line programs. Panotools use is restricted to the command line for closed source programs. > > I think the question should not be "How can we enforce the GPL?" but "How > > can we find a licensing model that satisfies all?". There is (as already > > mentioned) the LGPL, but there are other licences, too: I'm no expert in > > this, but there are other products (like f.e. ImageMagick) that have similar > > problems. And dual licensing (as someone mentioned) is another option. > > Actually, I like the GPL, and deliberately choose it for hugin, and my > (until now smaller) contributions to panotools. The GPL is a nice thing and it seems to work very well for other programs. I don't have the impression it works well for hugin. In PTGui if I found a bug or would like a new feature I send an email to Joost and in the next version it will be corrected or implemented (if reasonable). Not so in hugin: I had a discussion with you about the control point editor some years (!) ago, and it hadn't changed much. It is virtually unusable for special problems (and manual control point placement is only necessary for special problems). Sorry if all this sounds a bit rude, but I don't see any point in restricting a right that was implicitely granted for 7 years now and helped to spread the worlds best panorama stitching engine... best regards -- Erik Krause Resources, not only for panorama creation: http://www.erik-krause.de/ |
From: JD S. <jd...@as...> - 2007-01-26 02:00:31
|
On Fri, 26 Jan 2007 01:35:05 +0100, Erik Krause wrote: > On Thursday, January 25, 2007 at 23:24, Pablo d'Angelo wrote: > > [...] >> On the other hand, >> have you considered which new features and abilities have been added in the >> last 1 or 2 years to panotools, because PTGui has used panotools? >> >> NONE > > Could well be. But where would panotools be without PTGui? Would > there be any interest? When my interest in panoramas began I tried to > use panotools - and failed miserably. No way to do anything with the > copy and past barcode flags as control points. Guess how many others > would have thrown this away (like me) because they thought it was > unusable? PTGui made panotools to the most widely used stitching > engine. That's such an unusual perspective... mine is *exactly* the opposite. Where would PTGui be without PanoTools? My answer: it would never have existed. Now it doesn't need PanoTools, but that's only because the easy out was chosen of re-implementing functionality it learned from the free library. I respect all the hard work which went into PTGui, the responsiveness of its developer, and the benefit to the community. >> Instead Joost has choosen to reimplement improved functionality inside >> PTGui. This was probably a little easier, but also gave him an advantage on >> the market over PTassembler and hugin. > > I wasn't very fond of this step either. Infact I sent an angry email > to Joost expressing my fear of the disruption of panotools > development. Much the same what drives me to write this here. But it's already done, so in a sense, PTGui is no longer relevant to PanoTools (other than its potential to replace it, but then again, there are other tools out there with the same aim). JD |
From: Joost N. <jo...@ne...> - 2007-01-26 05:45:06
|
dmgalpha wrote: > Joost, as one of main contributor of Panotools, I please ask you that > if you incorporate support for pano13 in PTgui you do it under the > terms of the GPL version 2 under which pano13 is being licensed. This > means PTgui is not allowed to link directly to the library, only > allowed to execute the Panotools executables via fork/exec. > > Unless, of course, you are willing to place PTgui under the GPL too. Hi Daniel and others, I'm taking this thread from panotoolsNG to panotools-devel if you don't mind. I have read the Licensing thread here but didn't want to interfere. But since you're asking me directly now, please allow me give you my view. [I'm not a laywer etc.., but:] I think PTGui does not violate the panotools copyright. It could only violate its copyright if it were a reproduction or a derivative work, but it is neither. The panotools source code is not used in PTGui, nor is it distributed as part of PTGui, therefore PTGui is not bound in any way by the panotools copyright license (GPL). Yes it knows how to call functions in pano12.dll but that has nothing to do with copyright, and it certainly doesn't make it a derivate work. Further, calling a .exe with command line parameters, or loading a dll, pushing parameters on the stack and calling a subroutine are completely equivalent if you ask me. Also, it would be trivial to write an .exe wrapper for a dll, so I don't see why you would want to make this distinction. Perhaps it would be a different case if PTGui required panorama tools and panorama tools was included in the PTGui distribution. I think this is the case that the FSF statement might refer to. But this does not and has never applied to PTGui. Further I've always been careful to give credit for Panorama Tools. Take the name: 'PTGui' means graphical user interface for Panorama Tools, I didn't call it SuperPano or something like that.. Before PTGui5, it was clearly noted on the homepage of the ptgui site that panorama tools is free and open source, together with a link to its homepage. This information is now on http://www.ptgui.com/panotools.html That said..: I do respect your work and the time you are spending voluntarily on improving panotools. The new projections are a great addition. I don't want to start a fight about this, and I'll think about your request. PTGui will not be GPL, but using exec/fork for pano13 may be an option. Joost |
From: Joost N. <jo...@ne...> - 2007-01-26 08:09:49
|
Daniel M. German wrote: > Joost> [I'm not a laywer etc.., but:] I think PTGui does not violate the > Joost> panotools copyright. It could only violate its copyright if it were a > Joost> reproduction or a derivative work, but it is neither. The panotools > Joost> source code is not used in PTGui, nor is it distributed as part of > Joost> PTGui, therefore PTGui is not bound in any way by the panotools > Joost> copyright license (GPL). Yes it knows how to call functions in > Joost> pano12.dll but that has nothing to do with copyright, and it certainly > Joost> doesn't make it a derivate work. > > Hi Joost, > > This is not my view. If you call the functions in the libpano13 I > consider your work a derivative work of the library. Daniel, I respect your view. But the GPL says something else: GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) PTGui does not contain any part of Panorama Tools. Not even a .h file. I haven't read any convincing argument in the entire licensing thread either. The only argument that I have heard is the FSF statement about dynamic linking, which has become a kind of dogma. > Joost> That said..: I do respect your work and the time you are spending > Joost> voluntarily on improving panotools. The new projections are a great > Joost> addition. I don't want to start a fight about this, and I'll think about > Joost> your request. PTGui will not be GPL, but using exec/fork for pano13 may > Joost> be an option. > > In the spirit of cooperation I ask you to consider my request: to not > load the library and call functions in it. If we collaborate everybody > will benefit: your users, you and ourselves. As I said, I will consider it. I don't see the benefits though. Joost |
From: Erik K. <eri...@gm...> - 2007-01-26 16:36:32
|
On Thursday, January 25, 2007 at 17:52, Daniel M. German wrote: > Erik> The GPL is a nice thing and it seems to work very well for other > Erik> programs. I don't have the impression it works well for hugin. In > Erik> PTGui if I found a bug or would like a new feature I send an email to > Erik> Joost and in the next version it will be corrected or implemented (if > Erik> reasonable). > > Erik, with all respect, I think you are confusing commercial > motivation with non-commercial motivation. If you paid money for Hugin > (and Pablo made a living from it) he will be very motivated to fix > those problems. > > Erik> Not so in hugin: I had a discussion with you about the control point > Erik> editor some years (!) ago, and it hadn't changed much. It is > Erik> virtually unusable for special problems (and manual control point > Erik> placement is only necessary for special problems). > > Again, it is commercial motivation, not the GPL. You name it - exactly what I meant. It is commercial motivation and it is the reason why I get what I want. My suspicion is that Pablo mostly implements what he is interested in - not primarily what is required by the users. This is his good right, since he has no commercial benefit. But this means, that anyone who needs a special feature or a simplified workflow has to wait until Pablo is in good mood to implement it. Helmut's motivation was different. I think he ever had commercial use in mind and hence he had nothing against direct linking of pano12. However, you are free to do with your code what you want. I personally don't need the new projections. In my opinion they are nice to have but not mandatory. Flexify f.e. has a good bunch, too. Projections don't contribute to the quality of a stitching engine. I don't even like the policy to split the functionality into several small programs. This all makes it more complicated for a user. It boils down to this situation: There is hugin which has evolved very good but has by far not the user-friendliness of PTGui. And there are several command line programs which are hard to use (who did ever code a PTStitcher script?) Then panotools will be reduced to the stitching engine of hugin and the other GUI developers will go their own way. And hugin - see above - apparently is a just-for-fun project... best regards -- Erik Krause Resources, not only for panorama creation: http://www.erik-krause.de/ |
From: Daniel M. G. <dm...@uv...> - 2007-01-26 17:17:33
|
hi Erik, Erik> You name it - exactly what I meant. It is commercial motivation and Erik> it is the reason why I get what I want. My suspicion is that Pablo Erik> mostly implements what he is interested in - not primarily what is Erik> required by the users. This is his good right, since he has no Erik> commercial benefit. But this means, that anyone who needs a special Erik> feature or a simplified workflow has to wait until Pablo is in good Erik> mood to implement it. Helmut's motivation was different. I think he I totally agree with you. One has to understand the gift culture of the free and open source world (and I think you do). I donate time and knowledge under a simple set of conditions (stated in the GPL). Many benefit. Perhaps I could benefit more people, but my resources and time are limited. You also participate in this gift culture with your contributions (tutorials, emails, discussion). And the same applies to you: you decide how and by how much to help others. Hugin is part of this gift culture and that is why it has an advantage over commercial products: it can call and interact directly with the code inside the library via function calls (as stated by the GPL). Commercial products that interact with panotools do not (in general) benefit me. They apparently benefit the users of Panotools (such as yourself, given that you appear to have a license to PTgui). Hugin benefits me because it increases the commons of knowledge of the free and open source world. This is why I am willing to help Hugin (by using my time and knowledge) to its benefit. Erik> However, you are free to do with your code what you want. I Erik> personally don't need the new projections. In my opinion they are Do you want somebody who finds and fixes the bugs in panotools? Somebody who is willing to do research and development in the libraries? Today it is projections, tomorrow it can be better blending algorithms, chromatic aberration, vignetting control. Erik> nice to have but not mandatory. Flexify f.e. has a good bunch, too. Erik> Projections don't contribute to the quality of a stitching engine. I Erik> don't even like the policy to split the functionality into several Erik> small programs. This all makes it more complicated for a user. Erik> It boils down to this situation: There is hugin which has evolved Erik> very good but has by far not the user-friendliness of PTGui. And Erik> there are several command line programs which are hard to use (who Erik> did ever code a PTStitcher script?) Then panotools will be reduced to Erik> the stitching engine of hugin and the other GUI developers will go Erik> their own way. And hugin - see above - apparently is a just-for-fun Erik> project... -- Daniel M. German "One reason that life is complex is that it has a real part and Andrew Koenig -> an imaginary part." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Erik K. <eri...@gm...> - 2007-01-26 21:44:14
|
On Friday, January 26, 2007 at 9:16, Daniel M. German wrote: > Do you want somebody who finds and fixes the bugs in panotools? > Somebody who is willing to do research and development in the > libraries? Today it is projections, tomorrow it can be better blending > algorithms, chromatic aberration, vignetting control. Yes, definitely. That's one of the reasons why I put forth the donation of the peleng for you ;-) I didn't mean to debase your hard work. To be honest I already had lost hope to get an up to date replacement for PTStitcher. I'm glad you do it and my rants where just because I fear that this work might be in vain. best regards -- Erik Krause Resources, not only for panorama creation: http://www.erik-krause.de/ |
From: JD S. <jd...@as...> - 2007-01-29 18:58:44
|
On Mon, 29 Jan 2007 13:58:19 +0800, Joost Nieuwenhuijse wrote: > JD Smith wrote: >>>> Hi Joost, >>>> >>>> This is not my view. If you call the functions in the libpano13 I >>>> consider your work a derivative work of the library. >>> Daniel, >>> >>> I respect your view. But the GPL says something else: >> >> Just to inject another practical view... the LGPL specifically exists >> to allow software distributed under any license to link with an open >> library. If the GPL really did allow this intrinsically, there would >> be no need for the LGPL (which the FSF has rechristened the "Lesser" >> GPL, formerly "Library" GPL). > > Hi JD, > > There is a need for the LGPL: the LGPL would allow me to distribute > PTGui with the Panotools library statically linked in (provided that I > include the Panotools source). Further it would allow me to distribute > PTGui together with PanoTools, dynamically linked, in a single package, > so that it would appear to be a single product to the end user. Cases > like these are a possible reason for the existence of the LGPL. Thanks for your thoughts, Joost. I'm glad you agree that creating a statically linked binary creates a derivative ("co-mingling of the code"). In fact, if you are in compliance with the GPL, it provides you the explicit right to distribute the library, as long as it is accompanied by an offer to provide the source code as well (or, e.g. a link to your copy of the code on your website). > 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. You've zeroed in here on the essence of the LGPL. This clause simply says, if you are just "using" a library which is LGPL, you have no requirement to make your own code LGPL. Only if you modify, enhance, or extend it are your modifications, enhancements, or extensions governed by the LGPL (and in any case, only if you distribute this derivative). However, the LGPL is not the GPL, and this is by design. There is even an explicit FAQ which covers this *exact* scenario: http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL 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. I'm not sure how much more explicit than this you could get. > PTGui is exactly this, a "work that uses the Library", and therefore not > a derivative work of PanoTools according to the definition of the LGPL. Indeed, and if PanoTools were distributed under the LGPL, then you would be in the clear. > 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. Aside from fair use (e.g. to write an article with excerpts criticizing pano spaghetti code, or some such), your "natural" rights to a piece of copyrighted code are exactly zilch. The best you can do is approach the author to ask for permission to use the code. He may comply, offer a paid license, or flat out deny you. If there are many authors, all would need to agree to the new license terms. There is no surprise here: it is just as you can't copy 100 pages from a book and re-publish it in your own work, not even just in the appendix [1]. The GPL is a more permissive license which derives its power from copyright law. It actually *subtracts* restrictions from copyright, and grants you *further* rights which you normally would not have had. Namely, the right to use the code, in exchange for your compliance with the terms of the license under which it is made available. Among these terms, the most prominent is that all derived works must retain the same license upon distribution. The authors of the GPL are quite clear about what constitutes a derived work with respect to libraries: any direct linking (static or dynamic). This is the true brilliance of the GPL: if you don't accept its terms, your rights default back to what they were before under copyright: i.e. zero. Eben Moglen describes this succinctly here: http://www.gnu.org/philosophy/enforcing-gpl.html This simple yet powerful notion is what has allowed the GPL to stand up in German court recently: http://www.linux.com/article.pl?sid=06/09/24/1252212 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 respected. JD [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. |
From: Daniel M. G. <dm...@uv...> - 2007-01-31 00:00:32
|
JD> [...] By default, US JD> copyright law (and, in my understanding, European as well) gives you JD> exactly *zero* rights regarding the distribution of a given piece of JD> copyrighted code or derived works based on it. Aside from fair use JD is totally right here. JD> The GPL is a more permissive license which derives its power from JD> copyright law. It actually *subtracts* restrictions from copyright, JD> and grants you *further* rights which you normally would not have had. JD> Namely, the right to use the code, in exchange for your compliance JD> with the terms of the license under which it is made available. Among JD> these terms, the most prominent is that all derived works must retain JD> the same license upon distribution. The authors of the GPL are quite JD> clear about what constitutes a derived work with respect to libraries: JD> any direct linking (static or dynamic). And again here. This is, my opinion, the beauty of the GPL. It uses copyright law to attact (succesfully in my opinion) copyright law. JD> This is the true brilliance of the GPL: if you don't accept its terms, JD> your rights default back to what they were before under copyright: JD> i.e. zero. Eben Moglen describes this succinctly here: JD> http://www.gnu.org/philosophy/enforcing-gpl.html I would suggest reading "Open source licensing" by Larry Rosen for an alternate view, and in-depth analysis of the GPL. JD> Let's back away from the legalities for a moment. The entire point of JD> the GPL, and one of the main motivations of those who contribute code JD> to GPL projects, is to build a increasingly powerful collection of JD> free (as in freedom) and openly available software. If closed code JD> can link directly to GPL code, a barrier which has been erected quite JD> purposefully has been knocked down. That closed program can extend JD> and improve that library on its own side of the fence, all without JD> contributing these improvements back. This isn't malicious, it's just JD> a natural consequence of dropping this protective barrier. That is JD> the danger, and that is the reason why the GPL is so hard-nosed about JD> such use. Xactly. It is about the ethical issues as much (or perhaps more) than the legal issues. The GPL was created to defend this ethical view, not the other way around. As I mentioned in a previous message, what we need is to create an environment that fosters collaboration. The current one does not. I would argue that PTgui (and its users) are more likely to lose than to gain if panotools developement reverts to what it was one year ago. In fact, for many years none of the companies that uses PTstitcher rewrote it. And you can't tell me it was in the best interest of their users (Jim and Max were the only ones trying). And we know that having the source code for the new "PTstitcher" has benefits (for example, it is available under OS X Intel, where the current PTstitcher will never be able to run). dmg -- Daniel M. German "To take photographs is to hold one's breath when all faculties converge in the face of fleeing reality. It is at that moment that mastering an image becomes a Henri Cartier-Bresson -> great physical and intellectual joy." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: <jm...@we...> - 2007-01-30 21:05:26
|
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 to panoramas. 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. --=20 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: > > =20 >> JD Smith wrote: >> =20 >>>> 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= ,=20 >>>> but is designed to work with the Library by being compiled or linked= =20 >>>> 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= lls=20 >>>> outside the scope of this License." >>>> =20 >>> What such a "work that uses the Library" does *not* fall out of scope >>> of, however, is the GPL license.=20 >>> =20 >> The GPL explicitly limits its validity to derivative works (in the fir= st=20 >> clause of the license text). Further, the above explicitly states that= a=20 >> "work that uses the Library" is not considered a derivative work. >> =20 > > 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. > > =20 >> 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. >> =20 > > 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. > > =20 >>> If a library is released under the GPL (not the LGPL), does that mea= n >>> that any program which uses it has to be under the GPL? >>> >>> Yes, because the program as it is actually run includes the libr= ary. >>> =20 > > 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. > =20 > =20 >> But the program as distributed does not include the library. Copyright= =20 >> law protects distribution and publication. What the user does with the= =20 >> software is irrelevant, as long as he is not redistributing. >> =20 > > 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= e > perceived to be trying a subterfuge. > > =20 >> By the way, PTGui would run with any library that has the same interfa= ce=20 >> as pano12. If someone wrote such a library, would PTGui automatically=20 >> violate its copyrights? >> =20 > > This is the same exact argument GSL (the scientific library considered > for use by PanoTools) went through: > > http://sourceware.org/ml/gsl-discuss/2001/msg00388.html > > 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. > > =20 >>>> I have one more important argument: even if the GPL would have conta= ined=20 >>>> a clause which explicitly forbids third party programs to interface = to=20 >>>> 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= =20 >>>> never be more restrictive than copyright law itself. Copyright law=20 >>>> doesn't prohibit me to interface to a third party library and theref= ore=20 >>>> that library's distribution license is irrelevant. >>>> =20 >>> 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 >>> =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= rd=20 >> party library, then a distribution license cannot prohibit that either= =20 >> because it would be more restrictive. >> =20 > > 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. > =20 > =20 >>> Let's back away from the legalities for a moment. The entire point o= f >>> 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= t >>> 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= y >>> (add projections, optimize reprojection, etc.). The GUI's authors ar= e >>> 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 >>> respected. >>> =20 >> 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= =20 >> point, since attempting to support it through the cmdline will be quit= e=20 >> complex. >> =20 > > 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? > > =20 >> But a have a legacy to support, I can't simply remove functionality fr= om=20 >> 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. >> =20 > > 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. > > =20 >>> [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 u= p >>> large pano stitching by 100x. The company which wrote the accelerato= r >>> 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= nk to >>> this library, pointing customers to the website where you found it. >>> =20 >> 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= =20 >> website), I see no problem in having PTGui use the library if installe= d.=20 >> Much like checking for the presence of DirectX and using it to speed u= p=20 >> display. >> =20 > > 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!). > > =20 >> Joost btw: I appreciate the discussion here, thanks! >> =20 > > I'm glad you're willing to discuss it too. > > Thanks, > > JD > > > > -----------------------------------------------------------------------= -- > 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 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > =20 |
From: Daniel M. G. <dm...@uv...> - 2007-01-30 21:46:58
|
J=E9r=F4me> I meant to stay away from this discussion, after all I J=E9r=F4me> haven't contributed anything yet... But from what I read, I J=E9r=F4me> think I'll stay away from this library. You guys know your J=E9r=F4me> subject really well and this library is most probably the J=E9r=F4me> main reference on the subject. So, it would seem like a J=E9r=F4me> logical package to look at for any application that wants to J=E9r=F4me> do anything remotely related to panoramas. J=E9r=F4me> I'm worried that such a lawyer might even sue people doing s= imilar=20 J=E9r=F4me> features who would have learned the techniques from reading = your code. Exactly, why risk a business on a interpretation that can be challenged in a court of law? Why risk the time and energy fighting it?=20 J=E9r=F4me> That said, I do respect your decision, it is your code, you J=E9r=F4me> decide on your terms & conditions. I'll come up with my own J=E9r=F4me> code. Perfectly acceptable decision.=20 -- Daniel M. German "As De Gaulle used to say: 'Aim well, shoot fast Henri Cartier Bresson -> and get the hell out.'" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . =20 |
From: Joost N. <im...@ne...> - 2007-01-31 02:44:41
|
JD Smith wrote: >>> 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. Yes, that's what the GNU says. But IMO copyright law says something else.. >> 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: Yes I'm using technical means, per definition. And you could say that I'm using it to circumvent your interpretation of the license. But as I read it, the license itself is clear and doesn't forbid interfacing to a GPL'd program, be it through the command line or by calling functions. It does not forbid this in the text of the license and I'm convinced that it not even intended to forbid this back in 1992. But it is apparently against the spirit of the GNU and certain developers. > 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. Come on, PTGui is not a modified version of Panotools. We have two clearly separated units, one is the user interface and one is the library, with a clearly defined interface. Also keep in mind that PTGui as it is today does not require Panotools. Panotools is an optional plugin, it's not a required part of PTGui, and therefore it can't be considered an artificial split. Finally, your reasoning makes no distinction at all between cmdline interfacing and function calling. So either both would be forbidden, or both would be allowed. >> 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: > > http://sourceware.org/ml/gsl-discuss/2001/msg00388.html > > 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. Well there is an alternative: almost all pano12 functionality is implemented natively in PTGui already. It's not released under GPL, but that should not matter. > 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. First of all, that would not be your problem; the GSL would have to take action against my company. Second: include it in pano13 and there's no problem at all. >> 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. Hey, the GPL poses no restriction at all with respect to usage! It's a distribution license. In other words: "5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works." So the GPL is not an EULA. It allows *all use*, with the exception of redistribution. > 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? It may not be much, but I have contributed a few things to panotools. And I would like to have contributed more. You're getting me wrong, I'm really not afraid that adding a new feature, projection, etc, would hurt my income because people would switch to one of the alternatives. The strength of PTGui is still mostly in the GUI itself. But in many cases it was easier to start from scratch, like in the case of the PTGui stitcher or the control point generator. And yes, it's no excuse, but lack of time is a problem for me too. >>> [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 >> display. > > 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!). As I said there is no restriction on the use of PanoTools (no EULA), except for redistribution. So if it is redistributed with respect for the GPL, it's completely legal to point to that location. And entirely different from a warez copy of some commercial product. Joost |
From: Daniel M. G. <dm...@uv...> - 2007-01-31 06:30:25
|
Joost Nieuwenhuijse twisted the bytes to say: >> >> 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. Joost> Well there is an alternative: almost all pano12 functionality is Joost> implemented natively in PTGui already. It's not released under GPL, but Joost> that should not matter. So then why do you need pano12? To protect yourself from a lawsuit because you don't want to directly support FOV > 160? dmg -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: JD S. <jd...@as...> - 2007-02-01 00:34:20
|
On Wed, 31 Jan 2007 03:43:46 +0100, Joost Nieuwenhuijse wrote: >> 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. > > Come on, PTGui is not a modified version of Panotools. We have two > clearly separated units, one is the user interface and one is the > library, with a clearly defined interface. It certainly isn't, but you've misinterpreted. What he means here by a "technical procedure" is taking a whole program (PTGui running with PanoTools) and dividing it into parts (PTGui sans PanoTools + PanoTools itself) as a means of getting around the terms of the license. Those are the "technical means" that the FSF's lawyer feels wouldn't stand up in court. Obviously, in your case they were always divided, but the issue is exactly the same. > Finally, your reasoning makes no distinction at all between cmdline > interfacing and function calling. So either both would be forbidden, or > both would be allowed. Nope, that doesn't enter here. You agree that if you linked statically to PanoTools, or linked dynamically and distributed it in a single unified bundle (as, unfortunately, other GUIs do), that you'd be in breach of the license. The reasoning of the FSF's lawyer is that simply dividing them up and distributing them separately (or distributing one and pointing to the other) doesn't get you out of the license's terms. Running them as a separate process via fork/exec, however, DOES satisfy the terms of the license (whether or not you distribute the library). Releasing your own code under the GPL would also satisfy those terms. >>> 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: >> >> http://sourceware.org/ml/gsl-discuss/2001/msg00388.html >> >> 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. > > Well there is an alternative: almost all pano12 functionality is > implemented natively in PTGui already. It's not released under GPL, but > that should not matter. If you actually wrote it into a library with precisely the same drop in interface, that would change things. It would also be a shame, in my opinion, given that that energy could have been put into PanoTools itself. >>> 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. > > Hey, the GPL poses no restriction at all with respect to usage! It's a > distribution license. In other words: > > "5. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Program or its derivative works." > > So the GPL is not an EULA. It allows *all use*, with the exception of > redistribution. Indeed it does. One of it's many positive features. It wouldn't, for instance, ever have anything to say about using code with >180 degree fisheye input. That's a very positive thing. It does require authors of derivative works to honor the terms of the license when distributing those works. The end user can do whatever crazy thing they want with it. Also, any user can take the GPL'd code, make their own local changes, and never show them to anyone. It's only when you start distributing the code _or products derived from it_ that the license applies. >>>> [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 display. >> >> 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!). > > As I said there is no restriction on the use of PanoTools (no EULA), > except for redistribution. Or, and this is *crucial*, redistribution of products _derived from PanoTools_. The fact that you link to PanoTools -- quite independent of whether you distribute it on your site -- in the eyes of the authors of the license, the current maintainers, and the vast majority of other free software authors on the planet, makes PTGui such a derivative. Don't mistake the common meaning of "derivative", i.e. a lesser re-purposing, for the one used in the license. One million lines of code can derive from 1000, if they are fundamental enough to be used. > So if it is redistributed with respect for > the GPL, it's completely legal to point to that location. And entirely > different from a warez copy of some commercial product. Correct. The problem occurs only if you distribute a product derived from PanoTools and fail to follow its license. Then, it's really no different than a warez copy of a commercial product (except it was easier to find!). In the latter case you may feel guilt for having deprived that company of income and circumvented their commercial license. What's missing is guilt over having deprived the authors of the GPL code the minor non-monetary payback they've requested via their free license -- to share back the code which derives from it. If PanoTools had been written as a commercial library, my strong suspicion is we wouldn't be having this conversation today, and this field would be much less active and feature poor. JD |