From: dmg <dm...@uv...> - 2007-01-23 21:20:04
|
Summary of this message * GPL and panotools * Folding PT<binaries> into hugin I have been looking into the implications of the GPL, and it seems that (from the point of view of the FSF) if a program is run independently with no exchange of data structures, it does not break the spirit of the GPL (command line execution included). So command line execution by other tools seems to be a valid use. Now, in terms of windows users. I believe that PTgui and PTassembler are the largest user-base for panotools. They simply want executables to use (like PTstitcher). In my opinion PTgui and PTassembler should be the ones most worried about providing binaries for these platforms, not us. I will accept any redistribution by anybody as long as it is compliant with the GPL. That means that this, in my opinion, is a violation: http://www.tawbaware.com/maxlyons/pano12ml.htm Because it does not provide the source code along with the binaries. I will accept any redistribution of binaries of PTmender (and other tools) as long as the promise to provide source code is satisfied. Pointing to sourceforge does not satisfy it: http://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinary amnd http://www.gnu.org/licenses/gpl-faq.html#TOCSourceAndBinaryOnDifferentSites Pablo, would you consider folding the binaries of PTtools into Hugin? The reason for that is simple: * Panotools itself will not contain binaries * Binaries will come easily, but along with hugin, increasing the visibility of hugin to PTgui and PTassembler users. What do you think? dmg -- Daniel M. German "Don't try to be like Jackie. There is only one Jackie... Jackie Chan -> Study computers instead" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Bruno P. <br...@po...> - 2007-01-23 21:40:38
|
On Tue 23-Jan-2007 at 13:16 -0800, Daniel M. German wrote: > > Pablo, would you consider folding the binaries of PTtools into Hugin? I'm not Pablo, but this sounds ok to me. My only objection is technical: Currently my desktop is reduced to 512MB RAM, so to compile hugin I have to switch to runlevel 3 and it still takes several hours to build. Putting the command-line tools in with hugin raises the barrier of entry for future developers. -- Bruno |
From: Daniel M. G. <dm...@uv...> - 2007-01-26 02:17:03
|
Hi Bruno, >> Pablo, would you consider folding the binaries of PTtools into Hugin? Bruno> I'm not Pablo, but this sounds ok to me. Bruno> My only objection is technical: Currently my desktop is reduced to Bruno> 512MB RAM, so to compile hugin I have to switch to runlevel 3 and it Bruno> still takes several hours to build. Bruno> Putting the command-line tools in with hugin raises the barrier of Bruno> entry for future developers. Ok, bad idea :) let us leave them the way they are now :) Bruno> -- Bruno> Bruno Bruno> ------------------------------------------------------------------------- Bruno> Take Surveys. Earn Cash. Influence the Future of IT Bruno> Join SourceForge.net's Techsay panel and you'll get the chance to share your Bruno> opinions on IT & business topics through brief surveys - and earn cash Bruno> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV Bruno> _______________________________________________ Bruno> PanoTools-devel mailing list Bruno> Pan...@li... Bruno> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German "If debugging is the art of removing bugs, then programming must Anonymous -> be the art of inserting them." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Erik K. <eri...@gm...> - 2007-01-23 22:53:58
|
On Tuesday, January 23, 2007 at 13:16, Daniel M. German wrote: > I have been looking into the implications of the GPL, and it seems > that (from the point of view of the FSF) if a program is run > independently with no exchange of data structures, it does not break > the spirit of the GPL (command line execution included). > > > So command line execution by other tools seems to be a valid use. There was a lengthy discussion about that in 2004 on the main list: http://www.panotools.org/mailarchive/msg/24523 It came to no conclusion since the one person who put panotools under GPL didn't participate - Helmut Dersch. Apparently older versions where not GPLed and nobody knew when or why Helmut changed his mind. It was guessed that he originally intended something like the LGPL and it could be he released the tools under GPL in a hurry because he was threatened by ipix then. However, I think the LGPL should be considered as an alternative. If you think it would be appropriate to ask Helmut - I know his postal adress and telephone number (no, I never dared to contact him this way but I know the organizers of the Stuttgart panotools meeting did) best regards -- Erik Krause Resources, not only for panorama creation: http://www.erik-krause.de/ |
From: Daniel M. G. <dm...@uv...> - 2007-01-23 23:27:06
|
Erik> On Tuesday, January 23, 2007 at 13:16, Daniel M. German wrote: >> I have been looking into the implications of the GPL, and it seems >> that (from the point of view of the FSF) if a program is run >> independently with no exchange of data structures, it does not break >> the spirit of the GPL (command line execution included). >> >> >> So command line execution by other tools seems to be a valid use. Erik> There was a lengthy discussion about that in 2004 on the main list: Erik> http://www.panotools.org/mailarchive/msg/24523 Erik> It came to no conclusion since the one person who put panotools under Erik> GPL didn't participate - Helmut Dersch. Interesting discussion, I think the main difference now is that we do not have the baggage of the closed source PTstitcher. But I agree in general with the discussion there. If you distribute PTsticher.exe you are obligued to distribute its source code. If you don't you are violating the GPL. Helmut does not violate it because he does not distribute the software any more. So yes, PTassembler (and anybody who distributes PTstitcher) violates the GPL by redistributing PTstitcher. Erik> Apparently older versions where not GPLed and nobody knew when or why Erik> Helmut changed his mind. It was guessed that he originally intended Erik> something like the LGPL and it could be he released the tools under Erik> GPL in a hurry because he was threatened by ipix then. Erik> However, I think the LGPL should be considered as an alternative. If Erik> you think it would be appropriate to ask Helmut - I know his postal Erik> adress and telephone number (no, I never dared to contact him this Erik> way but I know the organizers of the Stuttgart panotools meeting did) Unless helmut and me explicitly place our under the LGPL we can't do it. And we will have to look for other "significant" contributions to see if they allow it too. I am not keen on the LGPL. -- Daniel M. German "My friends would think I was a nut, turning water into wine, Solsbury Hill, Peter Gabriel -> opening doors that seem to be shut." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Daniel M. G. <dm...@uv...> - 2007-01-24 05:59:51
|
Erik> There was a lengthy discussion about that in 2004 on the main list: Erik> http://www.panotools.org/mailarchive/msg/24523 Erik> It came to no conclusion since the one person who put panotools under Erik> GPL didn't participate - Helmut Dersch. Erik> Apparently older versions where not GPLed and nobody knew when or why Erik> Helmut changed his mind. It was guessed that he originally intended Erik> something like the LGPL and it could be he released the tools under Erik> GPL in a hurry because he was threatened by ipix then. Erik> However, I think the LGPL should be considered as an alternative. If Erik> you think it would be appropriate to ask Helmut - I know his postal Erik> adress and telephone number (no, I never dared to contact him this Erik> way but I know the organizers of the Stuttgart panotools meeting did) I might be in Germany this December. If that is the case I'll make a effort to visit him. -- Daniel M. German "War is not violence and killing, pure and simple; war is _controlled_ violence for a purpose. The purpose of war is to support your government's R. Heinlein -> decisions by force." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: JD S. <jd...@as...> - 2007-01-23 23:25:43
|
On Tue, 23 Jan 2007 13:16:05 -0800, dmg wrote: > > Summary of this message > > * GPL and panotools > * Folding PT<binaries> into hugin > > > I have been looking into the implications of the GPL, and it seems that > (from the point of view of the FSF) if a program is run independently with > no exchange of data structures, it does not break the spirit of the GPL > (command line execution included). > > > So command line execution by other tools seems to be a valid use. Are you certain none of the tools links directly to the libpano library, vs. just calling the stitcher front-ends? Why do they require pano12.dll then, simply for PTStitcher/Optimizer/etc. to load from? Here's the most relevant FSF FAQ I found: Can I release a non-free program that's designed to load a GPL-covered plug-in? It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program. If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins. If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case. That said, I feel PT isn't just a plug-in, but rather the core foundation. That may not change anything above, but it certainly impacts the spirit of things. JD |
From: Daniel M. G. <dm...@uv...> - 2007-01-24 01:06:35
|
JD Smith twisted the bytes to say: JD> On Tue, 23 Jan 2007 13:16:05 -0800, dmg wrote: >> >> Summary of this message >> >> * GPL and panotools >> * Folding PT<binaries> into hugin >> >> >> I have been looking into the implications of the GPL, and it seems that >> (from the point of view of the FSF) if a program is run independently with >> no exchange of data structures, it does not break the spirit of the GPL >> (command line execution included). >> >> >> So command line execution by other tools seems to be a valid use. JD> Are you certain none of the tools links directly to the libpano JD> library, vs. just calling the stitcher front-ends? Why do they JD> require pano12.dll then, simply for PTStitcher/Optimizer/etc. to load JD> from? Here's the most relevant FSF FAQ I found: totally Agreed. I am assumming they are not calling directly the .dll. if they do, it is a total violation. JD> That said, I feel PT isn't just a plug-in, but rather the core JD> foundation. That may not change anything above, but it certainly JD> impacts the spirit of things. Remember that we write software under the GPL without restriction on how it is going to be use it, even if we don't like the way it is used (as long as the license is used). I have been thinking exactly that: I don't like that PTassembler is just a shell for PTtools, but if the licenese allows that use, then I have to accept it. It part of the freedoms that I gain with the GPL. JD> JD JD> ------------------------------------------------------------------------- JD> Take Surveys. Earn Cash. Influence the Future of IT JD> Join SourceForge.net's Techsay panel and you'll get the chance to share your JD> opinions on IT & business topics through brief surveys - and earn cash JD> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV JD> _______________________________________________ JD> PanoTools-devel mailing list JD> Pan...@li... JD> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German "Speak not about what you have read, Azerbaijani Proverb -> but about what you have understood." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: yuval l. <yuv...@ya...> - 2007-01-23 23:26:30
|
I don't have much time, but I allow myself to chime in in this what I believe is very important. --- dmg <dm...@uv...>, "Daniel M. German" <dm...@uv...> wrote: > * Folding PT<binaries> into hugin please don't. I use it from the command line. I *love* using it from the command line. Since the bottleneck is disk I/O and not CPU I can control a bunch of old boxes (currently five of them, ranging from an AMD K6 450MHz to a Pentium III 500MHz) which have the one and only task to run PTStitcher (soon PTmender) and do projection transforms (I am amazed by all the projections you are adding. Keep going!) Regarding the GPL providing the source code along with the binaries is encouraged but not mandatory under the GPL <http://www.gnu.org/copyleft/gpl.html> Paragraph 3 ("You may copy and redistribute") says that one of three conditions must be met: a) what you ask for (provide the source code along) b) accompany the binary distribution with a written offer valid for at least three years to provide the code on request c) IMO not applicable to this situation (read it if you are interested). For most Windows users, the source code is a mysterious set of signs not much different from what is found on the walls of the Pyramids in Egypt that only a handful of erudites understand. It makes the download larger. The page linked above is a user friendly distribution and I don't see what negative effect it has on the software or on the project. > * Binaries will come easily, but along with hugin, > increasing the visibility of hugin to PTgui and > PTassembler users. What is the point of increasing the visibility of hugin to PTgui and PTassembler users? I am one of those users. I have tried hugin three times in the past three years. Every time I try it it has made very nice progress, but I still find myself more efficient working with PTgui or with the command line. Yuv (back into lurking mode) ____________________________________________________________________________________ Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html |
From: Daniel M. G. <dm...@uv...> - 2007-01-24 01:04:05
|
yuval levy twisted the bytes to say: yuval> I don't have much time, but I allow myself to chime in yuval> in this what I believe is very important. yuval> --- dmg <dm...@uv...>, "Daniel M. German" yuval> <dm...@uv...> wrote: >> * Folding PT<binaries> into hugin yuval> please don't. I use it from the command line. I *love* yuval> using it from the command line. Since the bottleneck No, I don't mean disappearing them. They will still exist, as they do now. yuval> Regarding the GPL providing the source code along with yuval> the binaries is encouraged but not mandatory under the yuval> GPL <http://www.gnu.org/copyleft/gpl.html> yuval> Paragraph 3 ("You may copy and redistribute") says yuval> that one of three conditions must be met: yuval> a) what you ask for (provide the source code along) yuval> b) accompany the binary distribution with a written yuval> offer valid for at least three years to provide the yuval> code on request yuval> c) IMO not applicable to this situation (read it if yuval> you are interested). Xactly: 1. where is the written offer? 2. they should provide the code. 3. If they make it available for download, the source code should be next to it. yuval> For most Windows users, the source code is a yuval> mysterious set of signs not much different from what yuval> is found on the walls of the Pyramids in Egypt that yuval> only a handful of erudites understand. It makes the yuval> download larger. The page linked above is a user yuval> friendly distribution and I don't see what negative yuval> effect it has on the software or on the project. they should provide the exact source code in which that binary is created. A tar.gz file with the source code, next to the binary is sufficient. >> * Binaries will come easily, but along with hugin, >> increasing the visibility of hugin to PTgui and >> PTassembler users. yuval> What is the point of increasing the visibility of yuval> hugin to PTgui and PTassembler users? I am one of yuval> those users. I have tried hugin three times in the yuval> past three years. Every time I try it it has made very yuval> nice progress, but I still find myself more efficient yuval> working with PTgui or with the command line. It is a marketting strategy. Will PTassembler be interested to say: here is hugin, you need it to run my tool? 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-01-23 23:42:37
|
On Tue, 23 Jan 2007 23:53:48 +0100, Erik Krause wrote: > On Tuesday, January 23, 2007 at 13:16, Daniel M. German wrote: > >> I have been looking into the implications of the GPL, and it seems that >> (from the point of view of the FSF) if a program is run independently >> with no exchange of data structures, it does not break the spirit of the >> GPL (command line execution included). >> >> >> So command line execution by other tools seems to be a valid use. > > There was a lengthy discussion about that in 2004 on the main list: > http://www.panotools.org/mailarchive/msg/24523 > > It came to no conclusion since the one person who put panotools under GPL > didn't participate - Helmut Dersch. That's true, but given the huge amount of work Daniel and the other developers have put into PanoTools in the last 2 years, I think the situation is now different. I believe they have an equal stake in its licensing. > Apparently older versions where not GPLed and nobody knew when or why > Helmut changed his mind. It was guessed that he originally intended > something like the LGPL and it could be he released the tools under GPL in > a hurry because he was threatened by ipix then. We don't know his intentions, but the license terms were made quite clear by the inclusion of the GPL with the source. I also don't see how LGPL would benefit anyone other than those who write the front-ends. Users will benefit from an open and freely available library which can be used 10 years down the road when commercial software authors have lost interest and moved onto other things. That's a stable base on which many things can be built (as they continue to). JD |
From: JD S. <jd...@as...> - 2007-01-24 01:34:39
|
> I have been thinking exactly that: I don't like that PTassembler is just a > shell for PTtools, but if the licenese allows that use, then I have to > accept it. It part of the freedoms that I gain with the GPL. I appreciate that attitude! My feeling is that they did a lot to attract users and developers to the community, and that they have been contributing over time back to the GPL codebase. This was a reasonable compromise scenario, even if they were in technical violation of the GPL (which isn't clear). Lately, some developers have re-implemented the functionality of PanoTools (and enblend, and autopano-sift) in closed form. This may be a temporary benefit to the userbase, since it streamlines the process, and makes some operations more efficient, but in the end it is a loss for the PanoTools community, since no improvements are "feeding back" from that effort any longer. Not much to do about that. Had PanoTools + Hugin been more closely associated from the beginning, I think things might have been different, in the sense that the command line tools, which were the enabling factor for the proliferation of the commercial closed-source offerings, may not have received as much emphasis as a library API. PTStitcher remaining closed was another contributing factor, which you have now overcome. Thanks always for your efforts. JD |
From: Max L. <max...@ve...> - 2007-01-24 06:05:57
|
This has been an interesting thread. Since my program (PTAssembler) and my site were mentioned in a few posts, I thought I'd post some responses to some of the comments that have been posted here. > That means that this, in my opinion, is a violation: > http://www.tawbaware.com/maxlyons/pano12ml.htm Because it does not > provide the source code along with the binaries. My current distributions of Pano Tools and PTAssembler both include Pano Tools source code. > If you distribute PTsticher.exe you are obligued to distribute its > source code. If you don't you are violating the GPL. I distribute PTStitcher as a convenience to Panorama Tools users. The source code for PTStitcher has never been made available. If this argument is correct, then it seems fair to say that anyone who distributes PTStitcher is violating the license, and even Dersch himself was in violation of the license when he distributed PTStitcher. Taking this line of argument to its logical conclusion seems to imply that neither PTStitcher nor any of the other Panorama Tools executables have ever been distributed legally. I wonder if there is any point in keeping pano12.dll around since it can only be used with these binaries? If folks feel that this is important, I'm happy to remove PTStitcher from my site, and contribute some of my time to a letter writing campaign to try and persuade anyone else who currently distributes PTStitcher to cease and desist. With some luck we should be able to eliminate PTStitcher and all of the other original Panorama Tools binaries from the Internet, ensuring that nobody can download this software ever again. I assume that others who agree with this will be happy to assist in the effort to remove this software from the Internet for good. > Are you certain none of the tools links directly to the libpano > library, vs. just calling the stitcher front-ends? PTAssembler does not link directly to the libpano library. I can't speak for the others. > If the program uses fork and exec to invoke plug-ins, then the > plug-ins are separate programs, so the license of the plug-in makes no > requirements about the main program In general terms, this is how PTAssembler works. In fact, the latest version introduces an additional separation from PTMender/PTStitcher: When creating a final image, PTAssembler doesn't call PTMender or PTStitcher directly. Rather, it creates a script file that contains commands necessary to invoke the stitcher. This script can be saved and executed outside of PTAssembler at any time. > For most Windows users, the source code is a mysterious set of signs > not much different from what is found on the walls of the Pyramids in > Egypt that only a handful of erudites understand. It makes the download > larger. That has been my view as well, but it seems that some folks feel that this violates the "letter of the law". I believe that my distribution now adheres to the letter (as well as the spirit) of the license. > they should provide the exact source code in which that binary is > created. A tar.gz file with the source code, next to the binary is > sufficient. I've included the source I use to create my binaries and the makefile I use in a zip file with my Panorama Tools distribution, and with PTAssembler. > I have been thinking exactly that: I don't like that PTassembler is > just a shell for PTtools, but if the licenese allows that use, then I > have to accept it. I'm glad we are agreed on the fact you'll have to accept it. However, as for PTAssembler being "just a shell", my perspective is a little different. I've spent five years working on PTAssembler. It contains tens of thousands of lines of code, all of which have been written from scratch. The logic is non-trivial, and I suspect that anyone else who has written "just a shell" would agree. It is in no way a "derivative" work of Pano Tools. Not in the technical sense, nor in the "common sense". In addition to five years of work on PTAssembler, I've donated a significant amount of "free" code to Panorama Tools. For example, I wrote all of the code for the "cropped tiff" feature in PTMender which makes it run considerably faster than PTStitcher, and made PTMender an interesting alternative to PTStitcher for most users. Speaking of contributions to the Pano Tools code, I'm now announcing the contribution of another program to Panorama Tools. I have rewritten PTInterpolate from scratch, and enhanced it with some additional features. (In order to avoid confusion with the original program, I've named my program PTAInterpolate.) Full source code (and a Windows binary) is included in my latest Panorama Tools download: http://www.tawbaware.com/maxlyons/pano12ml.htm For those who aren't familiar with PTInterpolate...it was one of the original programs that Helmut Dersch distributed with Panorama Tools. Its source code was never made available, so I have rewritten it from scratch and am contributing it to the Panorama Tools effort. > Lately, some developers have re-implemented the functionality of > PanoTools...in closed form....in the end it is a loss for the PanoTools > community, since no improvements are "feeding back" from that effort > any longer...Not much to do about that. I wonder if threads such as this one have been in any way responsible for this? Lastly...on the subject of "letter of the law", I noticed that the GPL includes this clause: "You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change". This seems to have been largely violated by most recent contributors to the project. For example, I see lots of modifications to adjust.c, but very few "prominent notices". How do folks feel about this...should this be vigorously enforced? Or, is it OK to ignore whatever clauses of the license seem inconvenient or uninteresting at any particular time? In any case, this was interesting, and I hope PTAinterpolate is a useful contribution to Pano Tools. Max |
From: Daniel M. G. <dm...@uv...> - 2007-01-24 06:13:51
|
To separate discussions and avoid combining them: Max> If this argument is Max> correct, then it seems fair to say that anyone who distributes PTStitcher is Max> violating the license, and even Dersch himself was in violation of the license Max> when he distributed PTStitcher. Taking this line of argument to its logical No, this is not correct. Helmut was able to "relicensed" himself the code under a different licence (he was at that point the sole author of the library). When Helmut compiled PTsitcher we could assert any license he wanted for the panotools library, since he owned it. Things would have been different if PTstitcher would have used another GPL library that we could not relicense. dmg -- Daniel M. German "I'm crazy, but I'm not stupid" Jackie Chan http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Daniel M. G. <dm...@uv...> - 2007-01-24 09:30:27
|
Hi Max, Again, I'll keep splitting the discussion to avoid losing issues. Max> Lastly...on the subject of "letter of the law", I noticed that Max> the GPL includes this clause: "You must cause the modified files Max> to carry prominent notices stating that you changed the files Max> and the date of any change". This seems to have been largely Max> violated by most recent contributors to the project. For Max> example, I see lots of modifications to adjust.c, but very few Max> "prominent notices". How do folks feel about this...should this I am not what you mean by this. There are only 3 people who have modified "adjust.c" in the last year: you, Pablo and me. We are all maintaining the ChangeLog. And the ChangeLog is part of the distribution. So we are prominently stating the changes we are making to the files. Do you mean we are not updating the header of the files any more? Max> be vigorously enforced? Or, is it OK to ignore whatever clauses Max> of the license seem inconvenient or uninteresting at any Max> particular time? Max> Max -- Daniel M. German "Compared to the real life, even the best on-line "virtual spaces" The Economist -> are cartoons" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Max L. <max...@ve...> - 2007-01-24 13:51:22
|
> Max> Lastly...on the subject of "letter of the law", I noticed that > Max> the GPL includes this clause: "You must cause the modified files > Max> to carry prominent notices stating that you changed the files > Max> and the date of any change". This seems to have been largely > Max> violated by most recent contributors to the project. For > Max> example, I see lots of modifications to adjust.c, but very few > Max> "prominent notices". How do folks feel about this...should this > > I am not what you mean by this. > > There are only 3 people who have modified "adjust.c" in the last year: > you, Pablo and me. We are all maintaining the ChangeLog. And the > ChangeLog is part of the distribution. So we are prominently stating > the changes we are making to the files. I think the ChangeLog is a wonderful idea. And I would argue that it adheres to the "spirit" of the license, but not the "letter" of the license. The license says the "the modified files" must "carry prominent notices" about "any change". The ChangeLog is not the same as "the modified files". My reading of the license is that if (for example) adjust.c is modified, then adjust.c should carry a "prominent notice" regardless of whether other file(s) (e.g. the ChangeLog) also have information about the change. In any case, I think this is a violation if the letter of the law, but not the spirit. Max |
From: Daniel M. G. <dm...@uv...> - 2007-01-24 18:12:53
|
Hi Max, I might have to ask our IP people and the FSF for clarification on this one. The section of the GPL in question: ---------------------------------------------------------------------- 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. ---------------------------------------------------------------------- There are two issues here: 1. We are not talking about a "work based on the program". We are talking about the original work (it still bears the same name, and purpose). 2. A notice in each file pointing to the ChangeLog will, in my opinion, satisfy _exactly_ the requirement. This is what I mean by project clarifications. In the worst case scenario we can just automatically use the svn log to generate those entries, but I don't think it is necessary. dmg Max> Lastly...on the subject of "letter of the law", I noticed that Max> the GPL includes this clause: "You must cause the modified files Max> to carry prominent notices stating that you changed the files Max> and the date of any change". This seems to have been largely Max> violated by most recent contributors to the project. For Max> example, I see lots of modifications to adjust.c, but very few Max> "prominent notices". How do folks feel about this...should this -- 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-01-24 18:31:00
|
On Wed, 24 Jan 2007 01:05:48 -0500, Max Lyons wrote: >> Lately, some developers have re-implemented the functionality of >> PanoTools...in closed form....in the end it is a loss for the PanoTools >> community, since no improvements are "feeding back" from that effort any >> longer...Not much to do about that. > > I wonder if threads such as this one have been in any way responsible for > this? I didn't name names, but you are definitely who I was thinking of when I described the "favorable compromise" scenario in which the front-end developers contributed back to the library. Users win with easier access to PanoTools via a GUI, *and* with continued improvements to the open library. Taking things closed seems to me to be an "easy out" to skirt the licensing issues, but is also ethically dubious given the shoulders on which all the GUIs have stood. Yes, writing a good GUI probably involves 5x more time and effort than the core remapping code, but the latter is also the most technical and tricky bit. One wonders whether any of the GUIs would exist as they are without that original kernel of (difficult to manage, but brilliant) code Dr. Dersch gifted to the world. If there had been no GUIs, a small community of us would still be using the tools the old-fashioned way... I even wrote a simple control point picker to automate the most tedious part of script generation (which I've not used in 2 years thanks to Hugin). Thanks for your efforts and contributions to PanoTools. JD |
From: Pablo d'A. <pab...@we...> - 2007-01-24 08:19:25
|
Hi Daniel & all, It seems that the discussion has become a bit lively. Daniel M. German schrieb: > Summary of this message > > * GPL and panotools > * Folding PT<binaries> into hugin > I have been looking into the implications of the GPL, and it seems > that (from the point of view of the FSF) if a program is run > independently with no exchange of data structures, it does not break > the spirit of the GPL (command line execution included). > So command line execution by other tools seems to be a valid use. Yes, this is true. And I think this is a situation that everybody can live with. I don't mind if these programs are used by others, as long as the use is compliant with the license. This is the case for PTAssembler, but not for PTGui, since it links the pano12.dll directly. PTGui is therefore violating the GPL. Since the pano12.dll code has been mostly written by Helmut himself, this is not my problem. However, PTGui is moving from panotools to its own implementation, so I guess it will never link to libpano13. As for PTAssembler, I know that it is a lot of work to develop a GUI, often more work than the code in the background. Therefore I can understand that people might want to get monetary compensation for that. While I disagree with Max, that PTassembler is not a panotools derivative in common terms (PTassembler would be useless without panotools), I think the fact that Max actively developed panotools (and still is) is kind of a win-win situation. > I will accept any redistribution by anybody as long as it is compliant > with the GPL. That means that this, in my opinion, is a violation: > > http://www.tawbaware.com/maxlyons/pano12ml.htm > > Because it does not provide the source code along with the binaries. As for the binaries distributed by Max, I believe it is no problem for him to put a .zip or .tar.gz file with the source code next to the windows binary he offers on the website. > Pablo, would you consider folding the binaries of PTtools into Hugin? > > The reason for that is simple: > > * Panotools itself will not contain binaries > > * Binaries will come easily, but along with hugin, increasing the > visibility of hugin to PTgui and PTassembler users. > > What do you think? Since hugin has a really big list of dependencies compared to panotools, I think technically, the best solution is to keep the panotools library separate for now. While it is an attractive idea (from my point of view ;-), nobody will stop others of only distributing a selected subset of binaries (and placing the source on the same webpage). I'm all for increasing the visibility of hugin, which for example can be done by listing hugin at the top of the panotools application page and not PTGui. (As a side note: PTLens is not using panotools anymore.) Also, the hugin windows binaries ship with the latest version of panotools, I think the most practical solutions would be to add a big and easily visible download link that points to the hugin windows download. ciao Pablo |
From: Daniel M. G. <dm...@uv...> - 2007-01-24 08:44:37
|
Hi Everybody, >> Summary of this message >> >> * GPL and panotools >> * Folding PT<binaries> into hugin >> I have been looking into the implications of the GPL, and it seems >> that (from the point of view of the FSF) if a program is run >> independently with no exchange of data structures, it does not break >> the spirit of the GPL (command line execution included). >> So command line execution by other tools seems to be a valid use. Pablo> Yes, this is true. And I think this is a situation that Pablo> everybody can live with. I don't mind if these programs are Pablo> used by others, as long as the use is compliant with the Good. Pablo> license. This is the case for PTAssembler, but not for PTGui, Pablo> since it links the pano12.dll directly. PTGui is therefore Pablo> violating the GPL. Since the pano12.dll code has been mostly Pablo> written by Helmut himself, this is not my problem. However, Indeed. Only the copyright holder can assert a copyright violation. As we place more and more code into the library we increase our copyright in it. We can't assert Helmut's copyright, but we can assert our copyright. Pablo> PTGui is moving from panotools to its own implementation, so I Pablo> guess it will never link to libpano13. Hopefully we will never have to see this situation. So summarizing, and let us see if we can agree to this as a clarification to the GPL (similar to what Linus Torvalds has done to clarify the relationship of proprietary programs to the GPL) The following IS A DRAFT ---------------------------------------------------------------------- Clarification in the manner in which closed-source software can use libpano13. This statements not replace nor change way in which Panotools is licensed (GPL), but clarify some points that might be contentious. * We accept that other programs will use panotools binaries via fork/exec and this type of use will not be violation of the GPL license under which the panotools are licensed. * We will not accept direct linking unless the program that links to the library is also GPL. * We welcome distribution of binaries as long as the GPL conditions are satisfied, including: - Binary only distributions include the LICENSE (GPL license) and an offer to the source code - If the binaries are provided via Web/FTP, the source code (including makesfiles to create them) are also provided in the same place (not necessarily in the same file, but next to it). ---------------------------------------------------------------------- Opinions? Max, this would mean that you are welcome to use panotools the way you have been doing it (via exec in your programs). The reason I'd like this clarification is that it makes it clear to everybody (OSS developers and commercial developers) what their rights and obligations are. And it erases the cloudiness under which the panotools have been used. Pablo> As for PTAssembler, I know that it is a lot of work to develop a GUI, often Pablo> more work than the code in the background. Therefore I can understand that I _totally_ agree with this statement. Max, I have never underestimated the work you have done with PTassembler. It is not easy work. Pablo> people might want to get monetary compensation for that. While I disagree Pablo> with Max, that PTassembler is not a panotools derivative in common terms Pablo> (PTassembler would be useless without panotools), I think the fact that Max Pablo> actively developed panotools (and still is) is kind of a win-win situation. I also agree with this. -- Daniel M. German "Nothing exists except atoms and empty Democritos -> space; everything else is opinion." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Daniel M. G. <dm...@uv...> - 2007-01-24 08:47:26
|
Pablo> Since hugin has a really big list of dependencies compared to panotools, I Pablo> think technically, the best solution is to keep the panotools library Pablo> separate for now. I agree. Pablo> While it is an attractive idea (from my point of view ;-), nobody will stop Pablo> others of only distributing a selected subset of binaries (and placing the Pablo> source on the same webpage). I'm all for increasing the visibility of hugin, Yeap. I know :) It just increases the bar :) Pablo> which for example can be done by listing hugin at the top of the panotools Pablo> application page and not PTGui. (As a side note: PTLens is not using Pablo> panotools anymore.) I totally agree with this. Would somebody volunteer to make those changes in the web pages? Pablo> Also, the hugin windows binaries ship with the latest version of panotools, Pablo> I think the most practical solutions would be to add a big and easily Pablo> visible download link that points to the hugin windows download. I think you have already noticed that I started doing this (in the panotoolsNG list). BTW, I want to thank you for creating the binaries, Pablo. -- Daniel M. German "Diminutive as a mote of dust, a mere peck of the pen, a crumb on the keyboard, the full stop --the period-- is the unsung legislator of our Alberto Manguel -> writing systems" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Bruno P. <br...@po...> - 2007-01-24 23:03:38
|
On Wed 24-Jan-2007 at 00:46 -0800, Daniel M. German wrote: > > Pablo> which for example can be done by listing hugin at the top of the panotools > Pablo> application page and not PTGui. (As a side note: PTLens is not using > Pablo> panotools anymore.) > > I totally agree with this. Would somebody volunteer to make those > changes in the web pages? Done. Since I wrote the list in the first place, I guess I'm responsible for changing it. Basically it was in chronological order to avoid any appearance of favouritism, but I guess ptgui has had the top spot for long enough. > Pablo> Also, the hugin windows binaries ship with the latest version of panotools, > Pablo> I think the most practical solutions would be to add a big and easily > Pablo> visible download link that points to the hugin windows download. Ok done, sort of, a bit lower down. This page was created as a temporary placeholder years ago, any suggestions (or contributions) for improvement or extending this site are welcome. -- Bruno |
From: Daniel M. G. <dm...@uv...> - 2007-01-26 02:13:29
|
Bruno Postle twisted the bytes to say: Bruno> On Wed 24-Jan-2007 at 00:46 -0800, Daniel M. German wrote: >> Pablo> which for example can be done by listing hugin at the top of the panotools Pablo> application page and not PTGui. (As a side note: PTLens is not using Pablo> panotools anymore.) >> >> I totally agree with this. Would somebody volunteer to make those >> changes in the web pages? Bruno> Done. Since I wrote the list in the first place, I guess I'm Bruno> responsible for changing it. Bruno> Basically it was in chronological order to avoid any appearance of Bruno> favouritism, but I guess ptgui has had the top spot for long enough. Thanks Bruno, I actually think that we should have a policy of helping/supporting other open source projects. Particularly (like in the case of hugin) is provides binaries for the library. -- Daniel M. German "Any sufficiently advanced technology is indistinguishable Arthur C. Clarke -> from magic." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Max L. <max...@ve...> - 2007-01-24 13:51:21
|
> I disagree with Max, that PTassembler is not a panotools derivative in > common terms (PTassembler would be useless without panotools) It isn't clear to me whether asking if product A (e.g. PTAssembler) is useless without product B (e.g. Pano Tools) is an appropriate way of determining if product A is a derivative of product B. If so, then I think one could argue that any Windows application (e.g. Microsoft Excel for Windows, or any other program that runs on Windows) is a derivative of Microsoft Windows. After all, what use is Microsoft Excel for Windows without the Windows OS? Even if one agrees that if one product is the "useless" without another is sufficient to establish it as a "derivative" work, I disagree that PTAssembler would be "useless" without Panotools, for two general reasons. First, PTAssembler can operate with any stitching engine that uses the correct syntax (none.exe, for example, and any other stitching programs that I or other developers may develop in the future), not just Pano Tools. Second, it performs a large number of useful functions completely unrelated to Pano Tools, a few of which are: 1. Determining the precise GPS coordinates of where an image was taken by cross referencing image EXIF data with GPS data files. 2. Computing the time of sunrise/sunset for the the time/location where the image was taken. 3. Converting between FOV and focal length with a focal length/FOV calculator. Hope this helps, Max |
From: Daniel M. G. <dm...@uv...> - 2007-01-24 20:29:21
|
Hi Max, and everybody else: Max> It isn't clear to me whether asking if product A Max> (e.g. PTAssembler) is useless without product B (e.g. Pano Max> Tools) is an appropriate way of determining if product A is a Max> derivative of product B. If so, then I think one could argue Max> that any Windows application (e.g. Microsoft Excel for Windows, Max> or any other program that runs on Windows) is a derivative of Max> Microsoft Windows. After all, what use is Microsoft Excel for Max> Windows without the Windows OS? In my position as the main maintainer of panorama tools (and copyright holder of a portion of panotools) I state this: 0. (This is still work in progress --see my previous message on the clarifications of derivative works-- but I think there is basis for consensus): For the purpose of interpreting the license under which panotools is being offered (GPL v2): a program that uses panorama tools via exec/fork is not considered a derivate work of panorama tools. It appears that PTassembler uses only fork/exec to interact with panarama tools. Assuming this, and under the previous definition, PTassembler is not a derivative work of Panorama Tools. DOES ANYBODY who has CONTRIBUTED to the COPYRIGHT of the current version of panotools disagrees with this statement? Then state so. Any othe person, please abstain (only copyright holders can enforce a license). 1. I recognize the importance that PTassembler has had in enlarging the community of Panorama users. PTassembler was, in fact, the first tool I ever used to create panoramas few years ago. 2. PTassembler provides functionality to panorama creators in addition to what panorama tools does (for example, it provides a nice GUI to find control points). PTassembler is no trivial piece of software. 3. Max has provided some significant enhacements to panorama tools. 4. I welcome Max Lyons to continue as a contributor to panotools (as I welcome anybody). 5. The goals of PTtools are independent of the goals of PTassembler. 6. My decisions (as the main maintainer of panotools) will be taken independently of the needs of PTassembler. dmg -- Daniel M. German "Don't try to be like Jackie. There is only one Jackie... Jackie Chan -> Study computers instead" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |