From: Pablo d. <Pab...@we...> - 2007-01-26 09:09:59
|
Hi all, My (simplified) thought about the background of the link vs. exec debate i= s: the exec approach requires new functionality to be available completely in a standalone exectuable. In the other case, functionality can be mixed between proprietary and open source parts. Then the benefits maybe do not reach the open source part. This may sound a bit extreme, but then the GPL is about free software. I will continue to contribute to panotools under the GPL license. However, if I get an acceptable, commercial offer, I' quite willing to pro= vide my code under a dual license. This is how the commercial market works. However I don't believe that this scheme can be applied well to the curren= t situation. To conclude the debate on the link vs execute from my side, I explicitly s= tate that all code I, Pablo d'Angelo, provide to panotools from now on may not = be linked to closed source programs. This is only a clarification, since from= my point of view, the GPL does not allow linking of GPL'ed code to closed sou= rce programs. Obviously I can only speak for myself. > > Jim> If a program would call queryFeatures to determine what is avail= able=20 > > Jim> within panotools. For example querying projections and their pa= rameters=3F > >=20 > > That program will have to be GPL. >=20 > By the way: the queryFeatures code was originally written by me.. You are free to use your code in any way you wish, as long as it respects the copyright of the code written by others. ciao Pablo =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Viren-Scan f=FCr Ihren PC! Jetzt f=FCr jeden. Sofort, online und kostenlos. Gleich testen! http://www.pc-sicherheit.web.de/freescan/=3Fmc=3D022222 |
From: Pablo d. <Pab...@we...> - 2007-01-26 23:59:55
|
Hi Erik, > > Erik> Not so in hugin: I had a discussion with you about the control = point=20 > > Erik> editor some years (!) ago, and it hadn't changed much. It is=20 > > Erik> virtually unusable for special problems (and manual control poi= nt=20 > > Erik> placement is only necessary for special problems).=20 > >=20 > > Again, it is commercial motivation, not the GPL. Erik, I remember meeting you at the stuttgart meeting 2004. Back then hugin was quite an infant. However, I don't see for which problems hugin is virtually unuseable. Please help me remember. > You name it - exactly what I meant. It is commercial motivation and=20 > it is the reason why I get what I want. My suspicion is that Pablo=20 > mostly implements what he is interested in - not primarily what is=20 > required by the users. This is his good right, since he has no=20 > commercial benefit. True. I've started hugin because i wanted a tool on linux and I am interested in the technical side more than with providing ultra smooth GUIs. Currently I have reached a point where the hugin base is stable enought for some new innovations on the technical side, which I hope you might find interesting. > But this means, that anyone who needs a special=20 > feature or a simplified workflow has to wait until Pablo is in good=20 > mood to implement it. I feel that the "is in good mood" comment is a bit unfair, because the main problem is not my unstable mood but the time I have to work on hugin. Or find someone else to implement it. Hugin is opensource, after all. > Helmut's motivation was different. I think he=20 > ever had commercial use in mind and hence he had nothing against=20 > direct linking of pano12. I haven't witnessed the birth of panotools, but the proj-imim mailinglist suggests that it all started as a project at the University of applied sci= ences Furtwangen and not as a hobby of Helmut. Which is quite different from hugin. > It boils down to this situation: There is hugin which has evolved=20 > very good but has by far not the user-friendliness of PTGui. And=20 > there are several command line programs which are hard to use (who=20 > did ever code a PTStitcher script=3F) Then panotools will be reduced to=20 > the stitching engine of hugin and the other GUI developers will go=20 > their own way. And hugin - see above - apparently is a just-for-fun=20 > project... I'm sorry that hugin doesn't fit your needs. You are free to ignore it, or work constructively by providing real suggestions instead of just discarting it as a just for fun project. I didn't mean to offend anyone, in case it sounds a bit harsh. ciao Pablo =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= Erweitern Sie FreeMail zu einem noch leistungsst=E4rkeren E-Mail-Postfach! =09 Mehr Infos unter http://freemail.web.de/home/landingpad/=3Fmc=3D021131 |
From: Erik K. <eri...@gm...> - 2007-01-28 17:31:35
|
First of all I hope it is on topic here. If not I'll take it off list immediately... On Saturday, January 27, 2007 at 0:54, Pablo dAngelo wrote: > Erik, I remember meeting you at the stuttgart meeting 2004. > Back then hugin was quite an infant. However, I don't see for > which problems hugin is virtually unuseable. Please help me remember. I remember that I mentioned the CP editor there. But I remember too, that you asked me for more feedback, which I didn't give then - at least not much (sorry about that). > True. I've started hugin because i wanted a tool on linux and I am > interested in the technical side more than with providing ultra > smooth GUIs. Currently I have reached a point where the hugin > base is stable enought for some new innovations on the technical > side, which I hope you might find interesting. I'm always looking forward and I always tried to keep an eye on hugin. > > 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. > > I feel that the "is in good mood" comment is a bit unfair, because > the main problem is not my unstable mood but the time I have to > work on hugin. Sorry, I possibly choose the wrong words. I know your time is limited, I only wanted to express that apparently you implement what *you* think is appropriate. > Or find someone else to implement it. Hugin is opensource, after all. I regret very much that I never learned C - my programming knowledge is limited to Borland Pascal, PL/SQL, SQL, Javascript and PHP - and not much up-to-date practice in the first two... > > Helmut's motivation was different. I think he > > ever had commercial use in mind and hence he had nothing against > > direct linking of pano12. > > I haven't witnessed the birth of panotools, but the proj-imim mailinglist > suggests that it all started as a project at the University of applied > sciences Furtwangen and not as a hobby of Helmut. Which is quite different > from hugin. That's what I meant. It was a perfect example of "applied science"... > > 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... > > I'm sorry that hugin doesn't fit your needs. You are free to ignore it, > or work constructively by providing real suggestions instead of just > discarting it as a just for fun project. There is nothing wrong with doing something just for fun - it's far better to have fun than doing something only unwillingly. But you are right: Such statements are not constructive - I hope you forgive me. My major problem with the hugin at the moment is the CP editor: hugin with autopano are very good in finding CPs automatically - far better btw. than PTGui's internal CP finder. Hence for most panotrama work the CP editor isn't an issue. What I would need it for is stitching of the handheld nadir shot. Imagine a tiled floor without much structure with furniture standing around visible along the edges of the image. Autopano finds lots of CPs on the furniture and none on the floor itself. Unfortunately the furniture is subject to parallax errors while the floor is not - and I want to stitch the floor only of course. In hugin 0.7 b3 the CP editor zooms after I set a CP which makes it very hard to locate the corresponding region in the other image. Even if some points are correctly defined hugin doesn't place the mouse on the corresponding place in the other image (which it could do after partial optimization). The colored circle makes it hard to spot the exact location since it hides the details. In magnified view at 200% it is too large to estimate the center precisely. A crosshair would be far better. Another possibility I need the CP editor for is not implemented in hugin at all: lens calibration with straight line CPs (t3 and above). Next point is the lack of templates. It shouldn't be too hard to read a project file but only apply lens and position settings to the currently loaded images. An "advanced template" would put hugin beyond PTGui: the possibility to choose what settings should be applied. And of course a batch mode would be fine. I know I can set up anything in a shell/batch script, but it is far more convenient to set CPs, optimize and choose settings in the GUI, save projects and let them be calculated over night... > I didn't mean to offend anyone, in case it sounds a bit harsh. No problem, my posting probably sounded harsher than yours ;-) best regards -- Erik Krause Resources, not only for panorama creation: http://www.erik-krause.de/ |
From: Pablo d. <Pab...@we...> - 2007-01-31 08:04:18
|
Hi all, JD wrote: > On Tue, 30 Jan 2007 06:04:28 -0800, yuval levy wrote: >=20 > > How about reconsidering dual licensing, as proposed by > > Erik a few exchanges ago=3F it does not have to be the > > LGPL. > > > I think the starting point for negotiating is the stated copyright > > condition that I read from Daniel and from Pablo that "no dynamic > > linking to their contributed code is allowed". We must respect whateve= r > > condition they set. > >=20 > > Since this condition is a deal-breaker, I kindly ask them and everybod= y > > else to consider an alternative. I am fully aware that it is 100% unde= r > > the control of the individual copyright holder and bow to their > > decision. > >=20 > > How about replacing "no dynamic linking allowed" with something along > > "if a software package that uses the library is distributed under any > > other license than the GPL, the distributor is required to pay X% of t= he > > collected revenue to Y". I think this is an attractive idea, and I would agree to such dual licensi= ng schemes. They can work well (Trolltech is an example). I doubt that such a "general" extension of the license would work in pract= ice. I guess individual contracts need to be made, which is complicated by the = many developers involved in panotools. ciao Pablo =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Viren-Scan f=FCr Ihren PC! Jetzt f=FCr jeden. Sofort, online und kostenlos. Gleich testen! http://www.pc-sicherheit.web.de/freescan/=3Fmc=3D022222 |
From: alexandre j. <ale...@ko...> - 2007-02-02 08:15:11
|
> I think if some more checking is done that there are other commercial > software packages that are in the very least using the queryfeature to > determine what is available to PTStitcher. They will need to respect > the "no linking" too. I followed carefully this thread and the future of panotools. It's a really great library and I really care about it's future. But the topic of licensing need to be fixed first. The option we choose for Autopano Pro and Panotools relation was to have an import and export for project file. It's seems that between closed source and GPL, this is good option to choose. In fact, it's exactly what Max was doing, he just called the exe, stuff that we didn't do, but the principle is the same. That's why I pretty agree with bruno's plan : - Design a (text / xml / whatever) common script to make panotool do stuff : (we could keep the panotool script language, it just have to be clearly documentated and updated). - Closed source will only use this script file to interface to pano13 and will not link in any way to it. - Everyone concentrate on pano13. I would be happy to help to manage such a goal. Alexandre Jenny autopano |
From: Daniel M. G. <dm...@uv...> - 2007-01-26 09:18:43
|
Pablo> To conclude the debate on the link vs execute from my side, I explicitly state Pablo> that all code I, Pablo d'Angelo, provide to panotools from now on may not be Pablo> linked to closed source programs. This is only a clarification, since from my Pablo> point of view, the GPL does not allow linking of GPL'ed code to closed source Pablo> programs. I, Daniel German, state that the code that I have provided, and will provide to the panotools cannot be linked, statically or dynamically to closed source software. This is only a clarification, since from my point of view the GPL does not allow linking (dynamic or static) of GPL code to closed source programs. I, Daniel German, from this moment (and until further notice) stop being a maintainer and contributor to panotools. Dr. Daniel M. German Dept of Computer Science University of Victoria Victoria BC Canada |
From: Michael G. (adv) <ad...@md...> - 2007-01-26 11:01:50
|
Hi I dont have much to say about licensing but since this all started with "my" Peirce Quincuncial Projection (Peirce Quincuncial Projection -> GSL -> Licsensing Questions -> DMG is no longer maintainer of panotools) I feel a little bad now. I want to offer my help to solve this licensing problems. Maybe we could implement sth which makes it Ptgui (and other software) easier to call the executable file? Maybe a XML interface. Maybe the XML files could also be transfered by pipes or TCP/IP to the panotools executable to overcome the overhead of restarting the executable (I dont know if this also violates the GPL). Michael Daniel M. German wrote: > Pablo> To conclude the debate on the link vs execute from my side, I explicitly state > Pablo> that all code I, Pablo d'Angelo, provide to panotools from now on may not be > Pablo> linked to closed source programs. This is only a clarification, since from my > Pablo> point of view, the GPL does not allow linking of GPL'ed code to closed source > Pablo> programs. > > > I, Daniel German, state that the code that I have provided, and will > provide to the panotools cannot be linked, statically or dynamically > to closed source software. This is only a clarification, since from my > point of view the GPL does not allow linking (dynamic or static) of > GPL code to closed source programs. > > I, Daniel German, from this moment (and until further notice) stop > being a maintainer and contributor to panotools. > > > Dr. Daniel M. German > Dept of Computer Science > University of Victoria > Victoria BC Canada > > ------------------------------------------------------------------------- > 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=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > |
From: Joost N. <jo...@ne...> - 2007-01-26 11:24:20
|
Alright: PTGui will not dynamically or statically link to the pano13 library. It's not a big issue for me, while apparently it is for you. As I said I have been following the Licensing thread and wanted to express my point of view, definately not to offend you or anyone. But apparently that's what happened. Sorry for that. I'm out of here. Joost Daniel M. German wrote: > I, Daniel German, from this moment (and until further notice) stop > being a maintainer and contributor to panotools. |
From: Jim W. <jwa...@ph...> - 2007-01-26 17:55:22
|
I think dynamically linking to pano12.dll is acceptable but that is just me. In the future, what difference will it make to disallow dynamic linking, when the pano13 set of tools will all be stand along executables, that are themselves are statically linked to the core code? There will not be a pano13.dll. Building a pano13.dll that has a queryFeatures function to get the available features will not tell you what features where built into the stand along executable. PTOptimizer, PTStitcher and the other helper tools will all have to have their own method of returning what they support. Even if a pano13.dll was built it wont tell what was built into the standalone executables, when they were built. It has already been stated that calling these executables is acceptable to GPL. Obviously projects that are directly derived from panotools should be stopped. By derived I mean use the panotools source code. Building the standalone executables will eliminate DLL Hell. This will be a good thing. pano12.dll and the old helper tools will still be around for a while till all the replacements are done. Unfortunately, this also means that it is possible that all the tools will get out of sync from each other. This also mean a lot of duplicate code will get compiled into each helper tool but that is not as issue with the current size of hard disks and small size of these executables. When I started the replacement for PTStitcher it was simply to fix the bug, that memory was allocated using one system in the dll and deallocated using another system in PTStitcher. That is part of DLL Hell. Building the helper tools as standalone will avoid problems like this again. I thank Daniel for taking over the development of this and all of his contributions to panotools. I do hope to contribute much more time to development of panotools in the near future. My current goal is to create a complete Windows installer package with all the most current tools that will work as replacements to the old tools. Hopefully I will be able to dedicate some hours this weekend to this. First action will be to create a todo: list. I still like effect of fisheye images that are way beyond 360 deg. And I want to work with these images. I will continue to distribute convent binaries on my site. But soon as an installer package. The installer will go on SourceForge too but it will have to be the crippled version. Thanks to Tom Niemann for starting this effort. -- Jim Watters jwatters @ photocreations . ca http://photocreations.ca |
From: Michael G. <mic...@fl...> - 2007-01-26 10:53:02
|
Hi I dont have much to say about licensing but since this all started with "my" Peirce Quincuncial Projection (Peirce Quincuncial Projection -> GSL -> Licsensing Questions -> DMG is no longer maintainer of panotools) I feel a little bad now. I want to offer my help to solve this licensing problems. Maybe we could implement sth which makes it Ptgui (and other software) easier to call the executable file? Maybe a XML interface. Maybe the XML files could also be transfered by pipes or TCP/IP to the panotools executable to overcome the overhead of restarting the executable (I dont know if this also violates the GPL). Michael Daniel M. German wrote: > Pablo> To conclude the debate on the link vs execute from my side, I explicitly state > Pablo> that all code I, Pablo d'Angelo, provide to panotools from now on may not be > Pablo> linked to closed source programs. This is only a clarification, since from my > Pablo> point of view, the GPL does not allow linking of GPL'ed code to closed source > Pablo> programs. > > > I, Daniel German, state that the code that I have provided, and will > provide to the panotools cannot be linked, statically or dynamically > to closed source software. This is only a clarification, since from my > point of view the GPL does not allow linking (dynamic or static) of > GPL code to closed source programs. > > I, Daniel German, from this moment (and until further notice) stop > being a maintainer and contributor to panotools. > > > Dr. Daniel M. German > Dept of Computer Science > University of Victoria > Victoria BC Canada > > ------------------------------------------------------------------------- > 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=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > |
From: Daniel M. G. <dm...@uv...> - 2007-01-26 16:16:33
|
Michael> Hi Michael> I dont have much to say about licensing but since this all started with Michael> "my" Peirce Quincuncial Projection (Peirce Quincuncial Projection -> GSL -> Licsensing Questions -> DMG is no longer maintainer of panotools) I Michael> feel a little bad now. Michael, please don't feel this way. This has _nothing_ to do with you or your contributions. This has to do with my contributions and the way I feel they should be treated. I am not willing to maintain nor contribute to a project in which a commerical project is so openly willing to violate the spirit (and perhaps the letter--which can only be resolved by a court of law) of the General Public License. --daniel -- Daniel M. German "We don't believe in kings, presidents and voting; We believe The Internet Credo -> in rough consensus and working code." 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-26 16:51:59
|
Hi Joost, You have not offend me. I don't consider the expression of your point of view and the view of PTgui to be offensive. I think the issue here is that when two parties disagree in the interpretation of a license or a contract, there is only one way to resolve that difference, and that is the courts: let a judge decide for us which interpretation is correct. Currently I am not interested in asking a judge decide if you are using lawfully (or not) the license. I am happy and willing to work with you, Max, and Alexandre in maintaining a common interface to our programs. I will make this a priority and policy of Panotools: to work with commercial products towards an interface that makes it easy to interact with the functionality of panotools via fork/exec. I'll wait until you act on your offer and you re-release your products without dynamic linking to any of the versions of panotools (including pano12). Thanks Joost, -- daniel Joost> Alright: PTGui will not dynamically or statically link to the pano13 Joost> library. It's not a big issue for me, while apparently it is for you. Joost> As I said I have been following the Licensing thread and wanted to Joost> express my point of view, definately not to offend you or anyone. But Joost> apparently that's what happened. Sorry for that. Joost> I'm out of here. Joost> Joost Joost> Daniel M. German wrote: >> I, Daniel German, from this moment (and until further notice) stop >> being a maintainer and contributor to panotools. Joost> ------------------------------------------------------------------------- Joost> Take Surveys. Earn Cash. Influence the Future of IT Joost> Join SourceForge.net's Techsay panel and you'll get the chance to share your Joost> opinions on IT & business topics through brief surveys - and earn cash Joost> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV Joost> _______________________________________________ Joost> PanoTools-devel mailing list Joost> Pan...@li... Joost> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German "Technology now more often arouses apocalyptic ecstasies or visions of the kingdom of God Jacques Ellul -> than rational reflection" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Joost N. <jo...@ne...> - 2007-01-29 05:34:19
|
Daniel M. German wrote: > I'll wait until you act on your offer and you re-release your products > without dynamic linking to any of the versions of panotools (including > pano12). > > Thanks Joost, Hi Daniel, I've been offline for the weekend, hence the delayed reply. PTGui has dynlinked to pano12 for more than 6 years. I'm convinced it's perfectly compliant to the GPL (i'll bother you with more arguments in a separate posting). As a courtesy to you I've offered not to dynlink to pano13, but you seem to have really halted development and not willing to make any compromise. I'm afraid I can't convince you to change your mind, but hopefully someone else can. In any case, I will not remove functionality from PTGui, simply because our users (yes, yours too) will not benefit from that. Thanks, Joost |
From: Daniel M. G. <dm...@uv...> - 2007-01-26 20:18:41
|
Hi Jim, Jim> I think dynamically linking to pano12.dll is acceptable but that is just Jim> me. Jim> In the future, what difference will it make to disallow dynamic Jim> linking, when the pano13 set of tools will all be stand along Jim> executables, that are themselves are statically linked to the Jim> core code? There will not be a pano13.dll. Building a "what difference does it make" from the point of view of the user needs to be answer in a more complex way. I suggest you read the following document, by RMS: http://www.gnu.org/philosophy/pragmatic.html >From a phylosophical point of view I am closer to the position of Linus Torvalds than RMS. Read this interview: http://www.tlug.jp/docs/linus.html I quote Linus from this interview: "Before the commercial ventures, Linux tended to be rather hard to set up, because most of the developers were motivated mainly by their own interests, which very seldom include issues like ease-of-use. And with Linux, commercialism doesn't exclude the availability of sources, so you get the best of both worlds." I do like the idea of free software as an ultimate goal, but currently I write and create software under the GPL because that increases the spirit of cooperation between all parties involved. I think commercial products can bring and will bring benefits to free software (see for instance, the improvements that Max Lyons has made the library). Jim> When I started the replacement for PTStitcher it was simply to fix the Jim> bug, that memory was allocated using one system in the dll and Jim> deallocated using another system in PTStitcher. That is part of DLL Jim> Hell. Building the helper tools as standalone will avoid problems like Jim> this again. I thank Daniel for taking over the development of this and Jim> all of his contributions to panotools. Imagine if I wrote PTmender and kept the source code closed, and dynamically linked to the binary. You will still have the same problem as before. In the long term you have benefited by the fact that I had to provide back these improvements to the library. Jim> I still like effect of fisheye images that are way beyond 360 deg. And I do to. And I have been thinking about how to allow the user to nicely specify if ot not it should be included. -- Daniel M. German "To take photographs means to recognize --simultaneously and within a fraction of a second --both the fact itself and the rigorous organization of visually perceived forms that give it meaning. It is putting one's head, one's eye and one's heart on the same Henri Cartier Bresson -> axis" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Jim W. <jwa...@ph...> - 2007-01-26 22:33:19
|
Daniel M. German wrote: > Hi Jim, > > Jim> I think dynamically linking to pano12.dll is acceptable but that is just > Jim> me. > > Jim> In the future, what difference will it make to disallow dynamic > Jim> linking, when the pano13 set of tools will all be stand along > Jim> executables, that are themselves are statically linked to the > Jim> core code? There will not be a pano13.dll. Building a > > "what difference does it make" from the point of view of the user > needs to be answer in a more complex way. > The fact that panotools was licensed as GPL, and not LGPL, means that dynamic linking should not be allowed by closed source programs. I agree with JD Smith, to allow dynamic linking is why the LGPL exist. But the license for panotools has been treated as if it is LGPL. If a judge was to decide I am sure that GPL would be the only outcome. > I do like the idea of free software as an ultimate goal, but currently > I write and create software under the GPL because that increases the > spirit of cooperation between all parties involved. > > I think commercial products can bring and will bring benefits to free > software (see for instance, the improvements that Max Lyons has made > the library). > I agree. There has been many improvements made by Joost Nieuwenhuijse, Kevin Kratzke, and Thomas Rauscher as well. They all have commercial products. If the current GUIs were not as good as they are, then I probably look for at the open source versions to make them do what I need. It is the graphic interaction that makes all the difference. > Imagine if I wrote PTmender and kept the source code closed, and > dynamically linked to the binary. You will still have the same problem > as before. In the long term you have benefited by the fact that I had > to provide back these improvements to the library. > Thank you again. I do appreciate the whole concept of open source development. I dislike overpriced software and pattens for common or intuitive ideas. But I also dream about creating my own original stuff, and making a living at it. Don't make much money by giving everything away for free. I have to balance the greater good of improving and giving back to the community with my own happiness. -- Jim Watters jwatters @ photocreations . ca http://photocreations.ca |