From: Pablo d. <Pab...@we...> - 2007-01-29 09:52:43
|
Hi Joost, We have to be careful not to mix apples with oranges... > 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.=20 > >> Daniel, > >> > >> I respect your view. But the GPL says something else: > >=20 > > 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). >=20 > Hi JD, >=20 > There is a need for the LGPL: the LGPL would allow me to distribute=20 > PTGui with the Panotools library statically linked in (provided that I=20 > include the Panotools source). Further it would allow me to distribute=20 > PTGui together with PanoTools, dynamically linked, in a single package,=20 > so that it would appear to be a single product to the end user. Cases=20 > like these are a possible reason for the existence of the LGPL. >=20 > If you take a look at the text of the LGPL, it says: >=20 > "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 falls=20 > outside the scope of this License." >=20 > PTGui is exactly this, a "work that uses the Library", and therefore not= =20 > a derivative work of PanoTools according to the definition of the LGPL. It is important to remember that the above comments *DO NOT APPLY* to PTGui's use of PanoTools, since PanoTools is licensed under the GPL, not t= he LGPL license! To cite from the offical FSF GPL FAQ: http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins ----------------------------------------------- Can I release a non-free program that's designed to load a GPL-covered plu= g-in=3F It depends on how the program invokes its plug-ins. If the program uses fo= rk and exec to invoke plug-ins, then the plug-ins are separate programs, s= o 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 progr= am, 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 distri= buted for use with these plug-ins. If the program dynamically links plug-ins, but the communication between t= hem is limited to invoking the `main' function of the plug-in with some op= tions and waiting for it to return, that is a borderline case. ------------------------------------------------- Additionally, from http://www.gnu.org/licenses/gpl.html ------------------------------------------------ How to Apply These Terms to Your New Programs [...] This General Public License does not permit incorporating your program int= o proprietary programs. If your program is a subroutine library, you may c= onsider it more useful to permit linking proprietary applications with the= library. If this is what you want to do, use the GNU Lesser General Publi= c License instead of this License. ------------------------------------------------ Since I am not a lawyer, I can't comment on the relations between the GPL = and the local copyright laws. However, the above is what most developers have in mind when they choose t= he plain GPL license, as opposed to the LGPL license. To remember: The LGPL license is not to be confused with the GPL license. > I have one more important argument: even if the GPL would have contained= =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 therefore=20 > that library's distribution license is irrelevant. Do you have any hard facts about this claim=3F If if that applies, then the users who would download PTGui and add panoto= ols to it will violate the license, so you would have just moved the violation from = you to the users, which I'm sure is what the users want to do. Additionally, before PTGui can interface with PanoTools, it needs the head= er files of panotools, which are also licensed under the GPL, and thus cannot be used = during the creation/compilation of PTGui. 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 Mit der Gruppen-SMS von WEB.DE FreeMail k=F6nnen Sie eine SMS an alle=20 Freunde gleichzeitig schicken: http://freemail.web.de/features/=3Fmc=3D021179 |
From: Pablo d. <Pab...@we...> - 2007-01-29 13:51:50
|
Joost Nieuwenhuijse wrote: > Pablo dAngelo wrote: > > To cite from the offical FSF GPL FAQ:=20 > > http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins=20 > > ----------------------------------------------- Can I release a > > non-free program that's designed to load a GPL-covered plug-in=3F > >=20 > > 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. > >=20 > > 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. > >=20 >=20 > Yes, I've seen this quoted several times. But I have never seen any > explanation of these claims, and I really don't understand what=20 > reasoning is behind them. In the end it's the text of the license that=20 > counts. And the interpretation of that text by a judge (but not the FSF)= . True, in the end its the interpretation of a judge that counts. Considerin= g that the whole field is very complex, and strange things will inevitably h= appen, I have chosen the interpretation of the license creators (FSF) for hugin a= nd my contributions to PanoTools. In the end, until there is a final judgement (which I don't expect to see anytime soon), this issue will be subject to debate (and probably the debate will continue even then...). I sincerely hope that we all can respect each others individual views on the licensing issues in our actions. 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: yuval l. <yuv...@ya...> - 2007-01-29 15:20:28
|
--- Pablo dAngelo <Pab...@we...> wrote: > I sincerely hope that we all can respect each others > individual views on the licensing issues in our > actions. I think this is the most important sentence in the whole debate. If you, Pablo or any other developer, don't want dynamic links to your part of the code, I, the user, should respect that, and so should other developers. Full stop. The past has been quite messy. Let's leave it behind us as it is. I would like to suggest a compromise: * No dynamic linking in the future. No dynamic linking to the new features of pano13. Full stop. * Acceptance of the established practices of the past six years, dynamic linking to the old pano12. What do you think? My interest, as a user, is to see Daniel continuing as maintainer of the panotools. I organized the drive to donate him the fisheye lens and I will organize whatever I can reasonably do to retain his talent. I value the functionality he added to 3.x and respect his wish not to have them linked. It's actually not a wish - I consider it a licensing condition and I urge everybody not to violate it as well. At the same time I also value the functionality that Joost provides me with PTgui and I would not want to see *existing* functionality being sacrificed to GPL dogmatism. I don't care if the new projections are unavailable from within PTgui. Yuv ____________________________________________________________________________________ Need a quick answer? Get one in minutes from people who know. Ask your question on www.Answers.yahoo.com |
From: Joost N. <jo...@ne...> - 2007-01-29 11:11:21
|
Pablo dAngelo wrote: > Hi Joost, > > We have to be careful not to mix apples with oranges... [...] >> 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. > > It is important to remember that the above comments *DO NOT APPLY* to > PTGui's use of PanoTools, since PanoTools is licensed under the GPL, > not the LGPL license! You are right, that sentence was taken from the LGPL which does not apply to panotools. But I cited it because it gives another definition of what is a derivative work, and what is not. The difference between the LGPL and GPL is in what they allow with respect to derivative works: the GPL does not allow closed source derivative works, but the LGPL does under certain conditions. But the definition of what is a derivative work would probably be quite universal. > To cite from the offical FSF GPL FAQ: > http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins > ----------------------------------------------- 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. ------------------------------------------------- Yes, I've seen this quoted several times. But I have never seen any explanation of these claims, and I really don't understand what reasoning is behind them. In the end it's the text of the license that counts. And the interpretation of that text by a judge (but not the FSF). > Additionally, from http://www.gnu.org/licenses/gpl.html > > ------------------------------------------------ How to Apply These > Terms to Your New Programs > > [...] > > This General Public License does not permit incorporating your > program into proprietary programs. If your program is a subroutine > library, you may consider it more useful to permit linking > proprietary applications with the library. If this is what you want > to do, use the GNU Lesser General Public License instead of this > License. ------------------------------------------------ I think they mean static linking here. Otherwise it would contradict the first clause (number 0) of the license itself. >> 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. > > Do you have any hard facts about this claim? See it another way: the law is above everything. If some country decides that software may be copied freely, then the GPL is not applicable there. Similarly: if copyright law does not prohibit interfacing with another product, then the GPL cannot prohibit that either. > If if that applies, then the users who would download PTGui and add > panotools to it will violate the license, so you would have just > moved the violation from you to the users, which I'm sure is what the > users want to do. Only if they would distribute the linked product :-) But that would be technically difficult and it is prohibited by the PTGui license anyway.. > Additionally, before PTGui can interface with PanoTools, it needs the > header files of panotools, which are also licensed under the GPL, and > thus cannot be used during the creation/compilation of PTGui. I don't use the .h files directly. But of course I've had to write data structures that are binary compatible with the structures used in PTools. Joost |
From: Erik K. <eri...@gm...> - 2007-01-29 20:35:08
|
On Monday, January 29, 2007 at 10:52, Pablo dAngelo wrote: > 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. Only for curiosity and because no one answered the question last time I asked it: According to http://en.wikipedia.org/wiki/Linux_kernel Linux is licensed under GPL. As far as I know there are Linux closed source programs. Are they allowed to link to Linux kernel routines or are they not? Yes, the above page mentions "loadable kernel drivers" but I suspect that "normal" programs can call kernel functions, too... Another issue: The panotools photoshop plugins are special DLLs. Will the development of the plugins stop and Thomas's version considered illegal, since it is made to be linked from a closed source program? best regards -- Erik Krause Resources, not only for panorama creation: http://www.erik-krause.de/ |
From: JD S. <jd...@as...> - 2007-01-29 21:08:55
|
On Mon, 29 Jan 2007 21:34:51 +0100, Erik Krause wrote: > On Monday, January 29, 2007 at 10:52, Pablo dAngelo wrote: > >> 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. > > Only for curiosity and because no one answered the question last time I > asked it: According to http://en.wikipedia.org/wiki/Linux_kernel Linux is > licensed under GPL. As far as I know there are Linux closed source > programs. Are they allowed to link to Linux kernel routines or are they > not? They are, by a special allowance (not a modification to the license). E.g. linux/COPYING says: This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also see Linus' note: http://kerneltrap.org/node/1735 in which he explores the gray zone of closed kernel modules. Here's his bottom line: Basically: - anything that was written with Linux in mind (whether it then _also_ works on other operating systems or not) is clearly partially a derived work. - anything that has knowledge of and plays with fundamental internal Linux behaviour is clearly a derived work. If you need to muck around with core code, you're derived, no question about it. He makes a special exception by pointing out his stance that "the copyright holder recognizes that there are limits to a derived work, and spells out one such limit that he would never contest in court." > Yes, the above page mentions "loadable kernel drivers" but I suspect that > "normal" programs can call kernel functions, too... Indeed they can, but Linus doesn't consider that constitutes a derived work. I don't truly see the analogy between a user-level program making system calls and GUI's making libpano calls; in the latter case, the tools would fail to satisfy both of Linus' guidelines above. JD |
From: Erik K. <eri...@gm...> - 2007-01-29 22:58:32
|
On Monday, January 29, 2007 at 14:08, JD Smith wrote: > > Only for curiosity and because no one answered the question last time I > > asked it: According to http://en.wikipedia.org/wiki/Linux_kernel Linux is > > licensed under GPL. As far as I know there are Linux closed source programs. > > Are they allowed to link to Linux kernel routines or are they not? > > They are, by a special allowance (not a modification to the license). > > E.g. linux/COPYING says: This copyright does *not* cover user programs > that use kernel services by normal system calls - this is merely > considered normal use of the kernel, and does *not* fall under > the heading of "derived work". But this shows that the GPL alone is not clear in this point. If an allowance is possible without infringing the license, then the license is not strict and can be used this or that way. This at least would make allowances possible for the plugins. And perhaps it would make well defined allowances possible for other closed source programs, too. Especially since the past policy (which was encouraged by Helmut!) established something like a customary right. best regards -- Erik Krause Resources, not only for panorama creation: http://www.erik-krause.de/ |
From: Bruno P. <br...@po...> - 2007-01-29 23:37:48
|
On Mon 29-Jan-2007 at 23:58 +0100, Erik Krause wrote: > This at least would make allowances possible for the plugins. And > perhaps it would make well defined allowances possible for other > closed source programs, too. Especially since the past policy (which > was encouraged by Helmut!) established something like a customary > right. Helmut may be happy to allow the library to become part of a closed tool, but Daniel has a right to do whatever he likes with his own code. PTmender and the various other new tools have already been moved out of pano12 and into pano13, so Yuval's plan is a solution, and probably workable. Though there are other contributors to pano12 and any one of them can decide to enforce the license at any time. -- Bruno |
From: JD S. <jd...@as...> - 2007-01-29 23:45:57
|
On Mon, 29 Jan 2007 23:58:21 +0100, Erik Krause wrote: > On Monday, January 29, 2007 at 14:08, JD Smith wrote: > >> > Only for curiosity and because no one answered the question last time >> > I asked it: According to http://en.wikipedia.org/wiki/Linux_kernel >> > Linux is licensed under GPL. As far as I know there are Linux closed >> > source programs. Are they allowed to link to Linux kernel routines or >> > are they not? >> >> They are, by a special allowance (not a modification to the license). >> >> E.g. linux/COPYING says: This copyright does *not* cover user programs >> that use kernel services by normal system calls - this is merely >> considered normal use of the kernel, and does *not* fall under the >> heading of "derived work". > > But this shows that the GPL alone is not clear in this point. If an > allowance is possible without infringing the license, then the license is > not strict and can be used this or that way. The only issue is what constitutes a "derived work", and it's an issue not specific to the GPL, but for copyright law, generically. Different people have different opinions (for instance, the FSF treads very lightly around this notion of proprietary plug-ins). In the end, courts decide case by case. They often look at whether something made substantial use of the original program. To me, writing a userland application that happens to call a Linux kernel function via the normal API seems worlds apart from writing a front-end to a library which contains most of the algorithms required for your program to function. The original context of this discussion was the GSL, a GNU library for scientific calculations. The GSL maintainers are quite explicit about the permitted uses of their library, and the current PanoTools situation would not work for them, I'd guess. Here's an example: http://sourceware.org/ml/gsl-discuss/2001/msg00390.html The FSF likewise is quite explicit about what constitutes derivative works: anything that runs library code in the same process space (and eventually more; in GPL3, you can't hide behind offering an application as a web service). See: http://www.gnu.org/licenses/why-not-lgpl.html > This at least would make allowances possible for the plugins. And perhaps > it would make well defined allowances possible for other closed source > programs, too. Especially since the past policy (which was encouraged by > Helmut!) established something like a customary right. Can you shed more light on what encouragement Helmut gave to the front-end tools, if any? It would be useful to know his stance in detail. JD |
From: Daniel M. G. <dm...@uv...> - 2007-01-31 02:25:17
|
Erik Krause twisted the bytes to say: Erik> Starting with version 5 PTGui no longer needs Erik> panotools. Supporting it is an option (ok, it is mandatory if > Erik> 160=B0 fisheyes where used), an option that offers many things Erik> that where not possible with other programs. (f.e. not even Erik> hugin supports the straight line control points that Helmut Erik> introduced as one of his last contributions in 2002). You have hit the nail on the head. He supports panotools (in my opinion mainly) because it gives him an excuse to try to shift blame if the IPX patent owner comes knocking on his door. And yet supports FOV > 160. Erik> Speaking of plugins: How do you intend to license them in the Erik> future? If the source code to the plug-ins is also GPL I don't have a problem with it, even if they are sold commercially. Erik> They are integral part of panotools, but they where created for=20 Erik> dynamic linking by photoshop and compatible programs. And of cours= e=20 Erik> they link to pano12. Have you thought about that? And how difficul= t=20 Erik> it would be to allow dynamic linking from photoshop, paintshop pro= or=20 Erik> irfanview but not from PTGui? My main concerns would be if the plugin is able to run under the Gimp, and the source code is available. Erik> Correct me if I'm wrong: The main author ans all contributors befo= re=20 Erik> Daniel knew how pano12 was used. All of them contributed anyway or= =20 Erik> even especially because some GUI's uses it. None of them ever thou= ght=20 Erik> of enforcing the GPL against Kevin, Joost, Max, Thomas, Magnus=20 Erik> Egelberg (panowizard) or who ever used it, even though this issue = was=20 Erik> discussed some years ago. It ever was perfectly ok to dynlink pano= 12.=20 Erik> This is called a customary right and even a judge would honor this= . That is why I don't like it. Erik> It is perfectly ok if Daniel wants his code under GPL but I think = he=20 Erik> has no right at all to withdraw panotools from the community.=20 I can't. My contributions are GPL. they are owned by the community already. The issue here is not the past, is the future. Erik> As a constructive proposal: Create a separate program for the=20 Erik> projections and put it under GPL. Put PTMender, PTBlender and all = the=20 Erik> new programs under GPL. Put the core library ander LGPL - I'm pret= ty=20 Erik> sure all former contributors will agree: Max, Joost, Kevin and Tho= mas=20 Erik> R. will because they have personal interest. Jim did already. This= =20 Erik> leaves Rik Littlefield, Fulvio Senore, Douglas Wilkins, Rob Platt = and=20 Erik> of course Helmut Dersch to ask (taken from the panoinfo patch list= ). I tend to agree with this proposal.=20 Essentially: pano13 forks into another project, without the legal legacy of panotools, the branch is essentially removed from panotools (to avoid copyright licensing issues such as the ones we are discussing). pano12 stays as panotools, PTmender (and other binaries I created are rewritten or removed to avoid use of my copyright in new versions of the library that are meant to continue to be linked--in the spirit that I have contributed to the project). I would algo suggest you make it an explicit policy any binaries can link to it (a clarification similar to the linux one). We then all go our own marry way.=20 I can live with this. dmg (A variant of the above proposal is to ditch pano12 and leave to the companies and plug-ins to maintain it, and make it clear that pano12 is not an official panotools project). -- Daniel M. German "There is no such thing as absolute certainty, but there is assurance sufficient for the purposes John Stuart Mill -> of human life." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . =20 |
From: JD S. <jd...@as...> - 2007-02-01 00:54:47
|
> I'm not sure what the situation is with including them in an > installer (eg with PTassembler) - Is this 'mere aggregation' if the > source is included too? Yes, you can distribute commercial and GPL programs alongside each other without any issue. http://www.gnu.org/licenses/gpl-faq.html#MereAggregation JD |
From: JD S. <jd...@as...> - 2007-02-01 00:55:13
|
On Tue, 30 Jan 2007 18:24:18 -0800, Daniel M. German wrote: > (A variant of the above proposal is to ditch pano12 and leave to the > companies and plug-ins to maintain it, and make it clear that pano12 > is not an official panotools project). I think that's better. Most new developers who come along to join a GPL project will assume their code is not being used directly by commercial closed-source projects. To spare them the pain, pano13 should be *the* PanoTools, and pano12 can stick around for legacy support of the apps which have been linking it all along. Those apps could come along to pano13, as long as they did not link directly. |
From: <rog...@ro...> - 2007-02-02 17:42:52
|
To avoid writing an essay, let me just make a "few" statements. Heh. 1 - It's important that the license for PanoTools be respected and =20 actively enforced, or it means little, and is bound to lead to =20 conflicts; 2 - It's equally important that the license for PanoTools be a best =20 fit for the mix of stakeholders 3 - The PanoTools stakeholders include, in no order of importance, =20 core PanoTools developers, third-party PanoTools product developers, =20 and direct and indirect users of PanoTools 4 - GPL is simply a means to an end; it is not the point of the project 5 - GPL and perhaps other free/open source licenses, serve both an =20 active role as a license, but perhaps an equally important role for =20 attracting and maintaining developer interest 6 - Core developers and third-party product developers may have =20 conflicting interests, especially with regards to point 2 above 7 - The GPL is significantly useful as a means of promoting and =20 protecting an ecosystem of free (as in speech) products in a =20 particular niche 8 - Attracting qualified, interested developers will always be a =20 challenge for what is a pretty small market to begin with 9 - The panoramic ecosystem is not large enough to expect secondary, =20 non-traditional funding for development - this is a key difference =20 from people working on Linux, Apache, MySQL and other products that =20 have attracted enterprise support and funding 10 - Ultimately, end-users are (by and large) unconcerned about the =20 license specifics; they are looking for productivity tools, and =20 (mostly) not looking to advance any larger agenda 11 - End users are willing to pay a reasonable price for panoramic =20 imaging tools; free (as in beer) is not a *major* benefit for most =20 users; I'll happily pay $100 for a PT-based product 12 - Using a license to enforce arbitrary and ultimately counter-=20 productive requirements such as specifying *how* a product may =20 integrate with a tool (rather than whether it can or cannot) seems =20 largely petty and nitpicky; either a product is derivative or not; =20 whether it integrates via one method or another seems utterly =20 irrelevant to most users, and forcing a third-party product to use a =20 less efficient interface is not a compromise, it's a curse 13 - I see very little discussion about the impact on users; even in =20 open source there are users, and they are ultimately the audience. =20 PanoTools is not developed in a vacuum 14 - If the developers can't find a compromise that allows the open =20 and closed-source products to thrive then we've taken a huge step =20 backwards. Forget Linux, forget Apache, we are nothing like those products or =20 markets. While we are also nothing like MySQL, I think they offer a =20 fairly interesting model, as it's a product both standalone and often =20= embedded in both closed and open source products. MySQL offers a dual-=20= license approach. You can get it in completely free, GPL-like =20 licensing models, with all its restrictions - this helps promote open =20= source by attracting legions of developers and third-party =20 integration within the terms of that license. However, for markets =20 and products where that licensing model doesn't work, they offer a =20 closed-source compatible licensing option. Consider the following approach: 1. Form an organization - let's call it the PanoTools Foundation 2. Make the foundation the holder of PanoTools source code copyright, =20= and the relevant trademarks (though none exist today, it may be too =20 late for PanoTools=99, but perhaps it's time to move past that name =20 anyhow, or at least deprecate it) 3. Provide PanoTools free (beer/speech) under a GPL-like license, and =20= use the foundation to actively enforce that license 4. Provide an alternative license to commercial entities, allowing =20 complete liberty to use PanoTools in commercial products - for a fee =20 (to be determined - a blanket license fee, a per unit sales fee, an =20 annual fee, etc) 5. Provide incentives for third-party commercial licensees to =20 actively contribute to PanoTools developments, through fee waivers =20 (for instance) or rebates 6. Use the collected funds to support core PanoTools development - =20 for instance, purchasing gear such as lenses (as we did earlier this =20 year as a group) This would seem, with refinement, of course - I'm writing this on a =20 smelly, packed, noisy old Airbus 320 so I'm not suggesting this is a =20 complete model - to address the core needs. 1. Continue to support development of PanoTools as an open source effort 2. Provide commercial developers a reasonable option to share the =20 benefits of PanoTools while contributing something back to the core =20 effort, either through funding or code sharing 3. Prevent forking PanoTools 4. Create the incentive to formalize an organization designed to =20 protect and promote PanoTools IP Finally, one further thought. What is PanoTools really? It's both a =20 specific chunk of code, but it's also broader than that. Perhaps it's =20= time to retire the name, or better define it. Is Hugin part of =20 PanoTools? Is nona? What, really, is PanoTools? Best, Roger |
From: Erik K. <eri...@gm...> - 2007-02-03 12:45:07
|
On Saturday, February 03, 2007 at 0:17, Bruno Postle wrote: > In order to grow and develop, the library will inevitably change its > binary interface, it would be unusual and restrictive for an open > source library to maintain the same binary interface indefinitely. This is pretty ok. > ..but if you want to keep using PTStitcher and be able to drop the > library into any version of ptgui, then the binary interface has to > stay the same, not even the name of the library can change. It's not so much about PTStitcher but other of the "old" applications, too: PTEditor, PTInterpolate f.e. or the plugins. Of course I would like to see the plugins support the new library... And I would like to see the plugins to be more user friendly: especially the ability to record parameters to actions would be a very nice feature (and be it only the name of a parameter file). best regards -- Erik Krause Resources, not only for panorama creation: http://www.erik-krause.de/ |
From: yuval l. <yuv...@ya...> - 2007-02-03 13:18:21
|
--- Erik Krause <eri...@gm...> wrote: > On Saturday, February 03, 2007 at 0:17, Bruno Postle > wrote: > > > In order to grow and develop, the library will > > inevitably change its binary interface > > This is pretty ok. Then why the fuzz against "forking"? True, forking in human terms - parting, mostly on bad terms, to pursue similar goals - is bad, but here the "fork" would do more good than bad: 1. it would free pano13 of legacy - license and old API alike 2. it would allow pano12 to keep living for as long as it is needed 3. it would free developer to contribute under their preferred license 4. it would empower users to benefit from both developments > Of course I would like to see the plugins support the > new library... me too. Think the power of the mappings available from within Photoshop (or the Gimp). I wish those who have a say on this discussion could bring it to an end, so that the valuable time that they donate to these projects can be used for coding such features again. For my part, I intend once the dust is settled to write a list of specs, talk with the devs about them and set up a bounty system. I doubt the bounty system can match market value. We lack the critical mass. But I hope it will bring users and developers together. Yuv ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html |
From: Daniel M. G. <dm...@uv...> - 2007-02-03 20:27:21
|
yuval> I wish those who have a say on this discussion could yuval> bring it to an end, so that the valuable time that yuval> they donate to these projects can be used for coding yuval> such features again. Here is my own resolution: * I started contributing to the panotools in the belief they were GPL * Given the current environment (the way the panotools are used, and the way a large proportion of end-users, and some contributors to panotools feel) I will no longer contribute to panotools. * I will proceed to remove my code and tools from the repository and move it somewhere else, continue to rewrite Helmut's code, and innovate. The goal would be to have a library that has clean copyright provenance. The name of this new project is tlalli. * I will continue working towards panoramic software, but only in projects that align with my views and expectations (such as Hugin). * At the convenience of panotools mailing list maintainers I'll refund the cost of the Peleng or send it to a designated address. My code will continue to be GPL, and can and will be reused under the conditions set by the GPL. daniel -- Daniel M. German "If I were stuck on a desert island with only one compiler Brian Kernighan -> I'd want a C compiler" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: yuval l. <yuv...@ya...> - 2007-02-04 22:27:02
|
Daniel, --- "Daniel M. German" <dm...@uv...> wrote: > * Given the current environment (the way the > panotools are used, and the way a large proportion of > end-users, and some contributors to panotools feel) > I will no longer contribute to panotools. The panotools project is losing a talented, skilled, focused and dedicated key contributor. I am sad. > * I will proceed to remove my code and tools from > the repository and move it somewhere else, continue > to rewrite Helmut's code, and innovate. The goal > would be to have a library that has clean > copyright provenance. The name of this new project > is tlalli. Your rewrites are value added. Your innovations are fascinating. Clean copyright provenance is in the interest of everybody, I think. A question however still haunts me: how would tlalli be different from panotools in respect to how other stakeholders feel, which seems to be what is driving you away from panotools in the first place? > * At the convenience of panotools mailing list > maintainers I'll refund the cost of the Peleng or > send it to a designated address. There is no condition attached to the lens. It is yours and you can do what you want with it. *everything* (unlike licensed software that comes with strings of all sorts). However be aware that there is no obligation on the side of the mailing list maintainers to accept your lens or your money. As the initiator of the donation I am very unhappy about your decision to get rid of it but there is not much I can do other than reiterate that it was given to you *unconditionally* and not linked to any expectation about your contribution (or not) to the panotools project. The lens is yours, do what you want with it. The code is yours, do what you want with it. Yuv ____________________________________________________________________________________ Need a quick answer? Get one in minutes from people who know. Ask your question on www.Answers.yahoo.com |
From: Max L. <max...@ve...> - 2007-02-04 22:51:52
|
> --- "Daniel M. German" <dm...@uv...> wrote: > > * I will proceed to remove my code and tools from > > the repository and move it somewhere else, > yuval levy <yuv...@ya...> wrote: > The code is yours, do what you want with it. Please leave my code in the repository. I contributed quite a lot of code to PTMender, including the cropped TIFF feature, and the region-of-interest processing logic which is what makes PTMender much faster than PTStitcher. It would be a shame if this was to disappear when Daniel removes "his" code. Also...how does one go about deciding what is "his" code and what is "someone else's" code in an environment when multiple people have contributed to the project, sometimes creating new features, and sometimes enhancing or adding to features added by others? It isn't clear to me how one makes this distinction. But, perhaps there is a standard way of doing this? Thanks, Max |
From: yuval l. <yuv...@ya...> - 2007-02-04 23:08:21
|
Hi Max, I hope my remarks did not offend you. Of course I recognize your ownership to your part of the code. As a user, my situation is simple. It is all *your* (i.e. the team's) code and I am thankful to each and every one of you for every line of it and every second you spent on giving me such wonderful tools to use. thanks Yuv --- Max Lyons <max...@ve...> wrote: > > --- "Daniel M. German" <dm...@uv...> wrote: > > > * I will proceed to remove my code and tools > from > > > the repository and move it somewhere else, > > > > yuval levy <yuv...@ya...> wrote: > > The code is yours, do what you want with it. > > > Please leave my code in the repository. I > contributed quite a lot of code to > PTMender, including the cropped TIFF feature, and > the region-of-interest > processing logic which is what makes PTMender much > faster than PTStitcher. It > would be a shame if this was to disappear when > Daniel removes "his" code. > > Also...how does one go about deciding what is "his" > code and what is "someone > else's" code in an environment when multiple people > have contributed to the > project, sometimes creating new features, and > sometimes enhancing or adding to > features added by others? It isn't clear to me how > one makes this distinction. > But, perhaps there is a standard way of doing this? > > Thanks, > > Max > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support > web services, security? > Get stuff done quickly with pre-integrated > technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 > based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com |
From: Daniel M. G. <dm...@uv...> - 2007-02-04 23:33:51
|
Max> Please leave my code in the repository. I contributed quite a Max> lot of code to PTMender, including the cropped TIFF feature, and Max> the region-of-interest processing logic which is what makes Max> PTMender much faster than PTStitcher. It would be a shame if Max> this was to disappear when Daniel removes "his" code. Hi Max, Now that we can just concentrate in pano12 this is what I suggest: >From pano12 I remove PTcommon.c and PTcommon.h, but move these functions somewhere else. These were your main contributions found in PTcommon.c: int uncropTiff(char *inputFile, char *outputFile, char *messageBuffer) void getROI( TrformStr *TrPtr, aPrefs *aP, PTRect *ROIRect ) void getCropInformationFromTiff(TIFF *tif, CropInfo *c) void getCropInformation(char *filename, CropInfo *c) void setCropInformationInTiff(TIFF *tiffFile, CropInfo *crop_info) { The rest of my contributions I donate them to the project. Does that sound like a satisfactory compromise for pano12? dmg Max> Also...how does one go about deciding what is "his" code and what is "someone Max> else's" code in an environment when multiple people have contributed to the Max> project, sometimes creating new features, and sometimes enhancing or adding to Max> features added by others? It isn't clear to me how one makes this distinction. Max> But, perhaps there is a standard way of doing this? Max> Thanks, Max> Max Max> ------------------------------------------------------------------------- Max> Using Tomcat but need to do more? Need to support web services, security? Max> Get stuff done quickly with pre-integrated technology to make your job easier. Max> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo Max> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 Max> _______________________________________________ Max> PanoTools-devel mailing list Max> Pan...@li... Max> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Daniel M. G. <dm...@uv...> - 2007-02-04 23:45:37
|
The US copyright act has a sentence of this issue 103(b): (b) The copyright in a compilation or derivative work extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work, and does not imply any exclusive right in the preexisting material. The copyright in such work is independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material. That is why I think it is easier to distinguish copyright by identifying the main creator/contributor of a section. That is why I think it just easier for pano12 to consider PTcommon.c and PTcommon.h as my contributions (once getROI and other functions are moved somewhere else) Just remember, the reason to do this is so everybody can be happy with the "link as you please" policy that the panotools is trying to promote. My code, given that is already licensed as GPL can be used and reused in whatever project you want as GPL. I only object to it being used under this linking policy. I hope we can find a good arrangement. dmg -- Daniel M. German "Mathematicians often marvel at how they dream up concepts such as "zero" or "sum", and then seem to have no say about how these things behave. But they can decide how they look, and that is not a science. The Economist -> So it must be art." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Daniel M. G. <dm...@uv...> - 2007-02-04 23:25:46
|
>> --- "Daniel M. German" <dm...@uv...> wrote: >> > * I will proceed to remove my code and tools from >> > the repository and move it somewhere else, Max> Please leave my code in the repository. I contributed quite a lot of code to Max> PTMender, including the cropped TIFF feature, and the region-of-interest Max> processing logic which is what makes PTMender much faster than PTStitcher. It Max> would be a shame if this was to disappear when Daniel removes "his" code. Let us sort things one by one. First Pano13 are all the commits to Pano13. You can see that there are only 4 lines from you. Also, remember you can always "recommit" my contributions. r661 | dangelo | 2007-01-25 14:54:55 -0800 (Thu, 25 Jan 2007) | 2 lines r660 | dangelo | 2007-01-25 13:43:00 -0800 (Thu, 25 Jan 2007) | 3 lines r659 | dangelo | 2007-01-24 13:47:33 -0800 (Wed, 24 Jan 2007) | 2 lines r658 | dangelo | 2007-01-23 14:22:49 -0800 (Tue, 23 Jan 2007) | 2 lines r657 | dangelo | 2007-01-23 14:20:49 -0800 (Tue, 23 Jan 2007) | 1 line r656 | dangelo | 2007-01-23 14:20:16 -0800 (Tue, 23 Jan 2007) | 3 lines r655 | dmg | 2007-01-23 00:06:45 -0800 (Tue, 23 Jan 2007) | 12 lines r653 | dmg | 2007-01-11 11:36:01 -0800 (Thu, 11 Jan 2007) | 4 lines r652 | dmg | 2007-01-11 01:01:35 -0800 (Thu, 11 Jan 2007) | 8 lines r651 | dmg | 2007-01-10 23:55:10 -0800 (Wed, 10 Jan 2007) | 1 line r650 | dmg | 2007-01-10 23:50:28 -0800 (Wed, 10 Jan 2007) | 6 lines r649 | dmg | 2007-01-10 23:32:26 -0800 (Wed, 10 Jan 2007) | 1 line r648 | dmg | 2007-01-10 23:04:45 -0800 (Wed, 10 Jan 2007) | 6 lines r647 | dmg | 2007-01-10 22:04:23 -0800 (Wed, 10 Jan 2007) | 15 lines r646 | dmg | 2007-01-10 16:37:14 -0800 (Wed, 10 Jan 2007) | 19 lines r645 | dmg | 2007-01-01 14:07:21 -0800 (Mon, 01 Jan 2007) | 23 lines r644 | dangelo | 2007-01-01 11:42:38 -0800 (Mon, 01 Jan 2007) | 1 line r643 | dangelo | 2006-12-31 00:38:08 -0800 (Sun, 31 Dec 2006) | 1 line r642 | dangelo | 2006-12-31 00:20:51 -0800 (Sun, 31 Dec 2006) | 1 line r641 | dangelo | 2006-12-30 23:43:39 -0800 (Sat, 30 Dec 2006) | 1 line r640 | dangelo | 2006-12-30 12:57:35 -0800 (Sat, 30 Dec 2006) | 2 lines r639 | dmg | 2006-12-26 23:29:10 -0800 (Tue, 26 Dec 2006) | 36 lines r636 | brunopostle | 2006-12-21 02:17:29 -0800 (Thu, 21 Dec 2006) | 2 lines r635 | dangelo | 2006-12-18 13:35:49 -0800 (Mon, 18 Dec 2006) | 2 lines r634 | dangelo | 2006-12-17 05:28:28 -0800 (Sun, 17 Dec 2006) | 1 line r633 | dangelo | 2006-12-17 03:05:20 -0800 (Sun, 17 Dec 2006) | 1 line r631 | dmg | 2006-12-15 23:33:54 -0800 (Fri, 15 Dec 2006) | 6 lines r630 | dmg | 2006-12-15 17:37:56 -0800 (Fri, 15 Dec 2006) | 24 lines r629 | dangelo | 2006-12-15 14:59:32 -0800 (Fri, 15 Dec 2006) | 2 lines r628 | dmg | 2006-12-13 20:35:40 -0800 (Wed, 13 Dec 2006) | 5 lines r627 | dangelo | 2006-12-13 13:57:11 -0800 (Wed, 13 Dec 2006) | 2 lines r626 | dmg | 2006-12-12 18:09:55 -0800 (Tue, 12 Dec 2006) | 10 lines r625 | dmg | 2006-12-12 13:44:29 -0800 (Tue, 12 Dec 2006) | 17 lines r624 | dangelo | 2006-12-12 07:08:51 -0800 (Tue, 12 Dec 2006) | 2 lines r623 | dangelo | 2006-12-12 07:08:05 -0800 (Tue, 12 Dec 2006) | 2 lines r622 | dmg | 2006-12-11 23:07:12 -0800 (Mon, 11 Dec 2006) | 20 lines r621 | dmg | 2006-12-04 10:01:29 -0800 (Mon, 04 Dec 2006) | 1 line r620 | dmg | 2006-12-04 09:52:32 -0800 (Mon, 04 Dec 2006) | 1 line r619 | dmg | 2006-12-03 23:03:04 -0800 (Sun, 03 Dec 2006) | 35 lines r618 | dmg | 2006-11-28 21:22:51 -0800 (Tue, 28 Nov 2006) | 1 line r617 | dmg | 2006-11-28 21:18:15 -0800 (Tue, 28 Nov 2006) | 12 lines r616 | dmg | 2006-11-28 20:02:17 -0800 (Tue, 28 Nov 2006) | 1 line r615 | dmg | 2006-11-28 20:00:41 -0800 (Tue, 28 Nov 2006) | 1 line r614 | dmg | 2006-11-28 19:48:07 -0800 (Tue, 28 Nov 2006) | 47 lines r613 | dmg | 2006-11-25 18:10:31 -0800 (Sat, 25 Nov 2006) | 21 lines r612 | dmg | 2006-11-25 02:27:57 -0800 (Sat, 25 Nov 2006) | 3 lines r611 | dmg | 2006-11-25 02:15:53 -0800 (Sat, 25 Nov 2006) | 22 lines r603 | dmg | 2006-11-18 01:26:14 -0800 (Sat, 18 Nov 2006) | 1 line r602 | dmg | 2006-11-18 01:24:59 -0800 (Sat, 18 Nov 2006) | 1 line r601 | dmg | 2006-11-18 01:00:57 -0800 (Sat, 18 Nov 2006) | 15 lines r600 | dmg | 2006-11-17 19:50:15 -0800 (Fri, 17 Nov 2006) | 6 lines r599 | jim0watters | 2006-11-14 22:28:49 -0800 (Tue, 14 Nov 2006) | 1 line r598 | jim0watters | 2006-11-12 22:33:23 -0800 (Sun, 12 Nov 2006) | 1 line r597 | dmg | 2006-11-02 12:49:56 -0800 (Thu, 02 Nov 2006) | 1 line r596 | dmg | 2006-10-28 14:30:35 -0700 (Sat, 28 Oct 2006) | 1 line r595 | dmg | 2006-10-28 14:25:19 -0700 (Sat, 28 Oct 2006) | 1 line r594 | dmg | 2006-10-28 13:48:25 -0700 (Sat, 28 Oct 2006) | 28 lines r593 | dmg | 2006-10-28 11:15:22 -0700 (Sat, 28 Oct 2006) | 4 lines r592 | dmg | 2006-10-28 11:03:33 -0700 (Sat, 28 Oct 2006) | 15 lines r591 | dmg | 2006-10-27 02:33:04 -0700 (Fri, 27 Oct 2006) | 25 lines r590 | dmg | 2006-10-27 00:56:17 -0700 (Fri, 27 Oct 2006) | 1 line r589 | dmg | 2006-10-27 00:50:32 -0700 (Fri, 27 Oct 2006) | 1 line r588 | dmg | 2006-10-26 23:34:41 -0700 (Thu, 26 Oct 2006) | 14 lines r587 | dmg | 2006-10-26 22:44:16 -0700 (Thu, 26 Oct 2006) | 28 lines r586 | dmg | 2006-10-26 18:02:17 -0700 (Thu, 26 Oct 2006) | 6 lines r585 | dmg | 2006-10-26 16:44:27 -0700 (Thu, 26 Oct 2006) | 6 lines r584 | dmg | 2006-10-26 16:43:55 -0700 (Thu, 26 Oct 2006) | 6 lines r583 | dmg | 2006-10-25 11:20:19 -0700 (Wed, 25 Oct 2006) | 7 lines r582 | dmg | 2006-10-25 10:26:17 -0700 (Wed, 25 Oct 2006) | 7 lines r581 | dmg | 2006-10-25 10:15:40 -0700 (Wed, 25 Oct 2006) | 10 lines r579 | dmg | 2006-10-24 09:50:49 -0700 (Tue, 24 Oct 2006) | 15 lines r578 | dmg | 2006-10-22 20:18:58 -0700 (Sun, 22 Oct 2006) | 9 lines r577 | dmg | 2006-09-24 19:27:35 -0700 (Sun, 24 Sep 2006) | 1 line r574 | dmg | 2006-09-21 19:55:27 -0700 (Thu, 21 Sep 2006) | 1 line r573 | dmg | 2006-09-20 21:40:50 -0700 (Wed, 20 Sep 2006) | 7 lines r572 | dmg | 2006-09-20 21:34:16 -0700 (Wed, 20 Sep 2006) | 6 lines r571 | dmg | 2006-09-20 17:12:36 -0700 (Wed, 20 Sep 2006) | 8 lines r570 | maxlyons | 2006-09-16 12:24:41 -0700 (Sat, 16 Sep 2006) | 1 line r566 | maxlyons | 2006-09-05 18:47:41 -0700 (Tue, 05 Sep 2006) | 1 line r565 | maxlyons | 2006-09-05 18:40:14 -0700 (Tue, 05 Sep 2006) | 1 line r564 | maxlyons | 2006-09-05 18:35:21 -0700 (Tue, 05 Sep 2006) | 1 line r562 | dmg | 2006-09-01 23:20:07 -0700 (Fri, 01 Sep 2006) | 1 line r561 | dmg | 2006-08-30 14:42:06 -0700 (Wed, 30 Aug 2006) | 1 line r560 | dmg | 2006-08-12 23:35:56 -0700 (Sat, 12 Aug 2006) | 1 line r559 | dmg | 2006-08-12 21:57:02 -0700 (Sat, 12 Aug 2006) | 1 line r558 | dmg | 2006-08-12 21:50:19 -0700 (Sat, 12 Aug 2006) | 1 line r557 | dangelo | 2006-08-12 11:26:27 -0700 (Sat, 12 Aug 2006) | 3 lines r556 | dmg | 2006-08-05 11:08:04 -0700 (Sat, 05 Aug 2006) | 1 line r555 | dmg | 2006-08-05 11:03:46 -0700 (Sat, 05 Aug 2006) | 1 line r554 | dmg | 2006-07-30 15:06:47 -0700 (Sun, 30 Jul 2006) | 1 line r553 | dmg | 2006-07-30 15:00:28 -0700 (Sun, 30 Jul 2006) | 1 line r552 | dmg | 2006-07-30 12:52:39 -0700 (Sun, 30 Jul 2006) | 1 line r551 | dmg | 2006-07-30 11:37:26 -0700 (Sun, 30 Jul 2006) | 1 line r550 | dmg | 2006-07-28 23:48:12 -0700 (Fri, 28 Jul 2006) | 1 line r549 | dmg | 2006-07-28 23:45:39 -0700 (Fri, 28 Jul 2006) | 1 line r548 | dmg | 2006-07-28 23:19:43 -0700 (Fri, 28 Jul 2006) | 1 line r547 | dmg | 2006-07-28 20:11:42 -0700 (Fri, 28 Jul 2006) | 1 line r546 | dmg | 2006-07-28 20:04:01 -0700 (Fri, 28 Jul 2006) | 1 line r545 | dmg | 2006-07-28 19:53:16 -0700 (Fri, 28 Jul 2006) | 1 line r533 | brunopostle | 2006-07-11 13:54:04 -0700 (Tue, 11 Jul 2006) | 2 lines r532 | dmg | 2006-07-10 23:18:08 -0700 (Mon, 10 Jul 2006) | 1 line r531 | dmg | 2006-07-10 23:12:53 -0700 (Mon, 10 Jul 2006) | 1 line r530 | dmg | 2006-07-10 23:11:30 -0700 (Mon, 10 Jul 2006) | 1 line r529 | dmg | 2006-07-09 17:34:13 -0700 (Sun, 09 Jul 2006) | 1 line r528 | dmg | 2006-07-08 13:41:51 -0700 (Sat, 08 Jul 2006) | 14 lines r526 | dmg | 2006-06-30 07:17:37 -0700 (Fri, 30 Jun 2006) | 1 line Max> Also...how does one go about deciding what is "his" code and what is "someone Max> else's" code in an environment when multiple people have contributed to the Max> project, sometimes creating new features, and sometimes enhancing or adding to Max> features added by others? It isn't clear to me how one makes this distinction. Max> But, perhaps there is a standard way of doing this? These are your contributions. r570 | maxlyons | 2006-09-16 12:24:41 -0700 (Sat, 16 Sep 2006) | 1 line Adding import of file.h to fix this: "ptmender.c:310: warning: implicit declaration of function `panoFileMakeTemp'" ------------------------------------------------------------------------ r566 | maxlyons | 2006-09-05 18:47:41 -0700 (Tue, 05 Sep 2006) | 1 line Fixing panoReplaceExt which was broken for filenames like c:\dir\another.dir\file, because of the period as part of the directory name ------------------------------------------------------------------------ r565 | maxlyons | 2006-09-05 18:40:14 -0700 (Tue, 05 Sep 2006) | 1 line Adding check for isNan in getROI. Sometimes the remapping function returns NaN. This is probably a bug in the remapping function, but in the meantime adding a check for isNan in getROI. ------------------------------------------------------------------------ r564 | maxlyons | 2006-09-05 18:35:21 -0700 (Tue, 05 Sep 2006) | 1 line Max> Thanks, Max> Max Max> ------------------------------------------------------------------------- Max> Using Tomcat but need to do more? Need to support web services, security? Max> Get stuff done quickly with pre-integrated technology to make your job easier. Max> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo Max> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 Max> _______________________________________________ Max> PanoTools-devel mailing list Max> Pan...@li... Max> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- 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 . |
From: Daniel M. G. <dm...@uv...> - 2007-02-04 23:41:40
|
Daniel M German twisted the bytes to say: >> --- "Daniel M. German" <dm...@uv...> wrote: >> > * I will proceed to remove my code and tools from >> > the repository and move it somewhere else, Max> Please leave my code in the repository. I contributed quite a lot of code to Max> PTMender, including the cropped TIFF feature, and the region-of-interest Max> processing logic which is what makes PTMender much faster than PTStitcher. It Max> would be a shame if this was to disappear when Daniel removes "his" code. Daniel> Let us sort things one by one. First Pano13 are all the commits to Daniel> Pano13. You can see that there are only 4 lines from you. Also, Daniel> remember you can always "recommit" my contributions. Just to clarify, the "lines" field in these is lines in the description of the change. When I meant 4 lines I meant to say 4 commits. Daniel> r661 | dangelo | 2007-01-25 14:54:55 -0800 (Thu, 25 Jan 2007) | 2 lines Daniel> r660 | dangelo | 2007-01-25 13:43:00 -0800 (Thu, 25 Jan 2007) | 3 lines Daniel> r659 | dangelo | 2007-01-24 13:47:33 -0800 (Wed, 24 Jan 2007) | 2 lines Daniel> r658 | dangelo | 2007-01-23 14:22:49 -0800 (Tue, 23 Jan 2007) | 2 lines Daniel> r657 | dangelo | 2007-01-23 14:20:49 -0800 (Tue, 23 Jan 2007) | 1 line Daniel> r656 | dangelo | 2007-01-23 14:20:16 -0800 (Tue, 23 Jan 2007) | 3 lines Daniel> r655 | dmg | 2007-01-23 00:06:45 -0800 (Tue, 23 Jan 2007) | 12 lines Daniel> r653 | dmg | 2007-01-11 11:36:01 -0800 (Thu, 11 Jan 2007) | 4 lines Daniel> r652 | dmg | 2007-01-11 01:01:35 -0800 (Thu, 11 Jan 2007) | 8 lines Daniel> r651 | dmg | 2007-01-10 23:55:10 -0800 (Wed, 10 Jan 2007) | 1 line Daniel> r650 | dmg | 2007-01-10 23:50:28 -0800 (Wed, 10 Jan 2007) | 6 lines Daniel> r649 | dmg | 2007-01-10 23:32:26 -0800 (Wed, 10 Jan 2007) | 1 line Daniel> r648 | dmg | 2007-01-10 23:04:45 -0800 (Wed, 10 Jan 2007) | 6 lines Daniel> r647 | dmg | 2007-01-10 22:04:23 -0800 (Wed, 10 Jan 2007) | 15 lines Daniel> r646 | dmg | 2007-01-10 16:37:14 -0800 (Wed, 10 Jan 2007) | 19 lines Daniel> r645 | dmg | 2007-01-01 14:07:21 -0800 (Mon, 01 Jan 2007) | 23 lines Daniel> r644 | dangelo | 2007-01-01 11:42:38 -0800 (Mon, 01 Jan 2007) | 1 line Daniel> r643 | dangelo | 2006-12-31 00:38:08 -0800 (Sun, 31 Dec 2006) | 1 line Daniel> r642 | dangelo | 2006-12-31 00:20:51 -0800 (Sun, 31 Dec 2006) | 1 line Daniel> r641 | dangelo | 2006-12-30 23:43:39 -0800 (Sat, 30 Dec 2006) | 1 line Daniel> r640 | dangelo | 2006-12-30 12:57:35 -0800 (Sat, 30 Dec 2006) | 2 lines Daniel> r639 | dmg | 2006-12-26 23:29:10 -0800 (Tue, 26 Dec 2006) | 36 lines Daniel> r636 | brunopostle | 2006-12-21 02:17:29 -0800 (Thu, 21 Dec 2006) | 2 lines Daniel> r635 | dangelo | 2006-12-18 13:35:49 -0800 (Mon, 18 Dec 2006) | 2 lines Daniel> r634 | dangelo | 2006-12-17 05:28:28 -0800 (Sun, 17 Dec 2006) | 1 line Daniel> r633 | dangelo | 2006-12-17 03:05:20 -0800 (Sun, 17 Dec 2006) | 1 line Daniel> r631 | dmg | 2006-12-15 23:33:54 -0800 (Fri, 15 Dec 2006) | 6 lines Daniel> r630 | dmg | 2006-12-15 17:37:56 -0800 (Fri, 15 Dec 2006) | 24 lines Daniel> r629 | dangelo | 2006-12-15 14:59:32 -0800 (Fri, 15 Dec 2006) | 2 lines Daniel> r628 | dmg | 2006-12-13 20:35:40 -0800 (Wed, 13 Dec 2006) | 5 lines Daniel> r627 | dangelo | 2006-12-13 13:57:11 -0800 (Wed, 13 Dec 2006) | 2 lines Daniel> r626 | dmg | 2006-12-12 18:09:55 -0800 (Tue, 12 Dec 2006) | 10 lines Daniel> r625 | dmg | 2006-12-12 13:44:29 -0800 (Tue, 12 Dec 2006) | 17 lines Daniel> r624 | dangelo | 2006-12-12 07:08:51 -0800 (Tue, 12 Dec 2006) | 2 lines Daniel> r623 | dangelo | 2006-12-12 07:08:05 -0800 (Tue, 12 Dec 2006) | 2 lines Daniel> r622 | dmg | 2006-12-11 23:07:12 -0800 (Mon, 11 Dec 2006) | 20 lines Daniel> r621 | dmg | 2006-12-04 10:01:29 -0800 (Mon, 04 Dec 2006) | 1 line Daniel> r620 | dmg | 2006-12-04 09:52:32 -0800 (Mon, 04 Dec 2006) | 1 line Daniel> r619 | dmg | 2006-12-03 23:03:04 -0800 (Sun, 03 Dec 2006) | 35 lines Daniel> r618 | dmg | 2006-11-28 21:22:51 -0800 (Tue, 28 Nov 2006) | 1 line Daniel> r617 | dmg | 2006-11-28 21:18:15 -0800 (Tue, 28 Nov 2006) | 12 lines Daniel> r616 | dmg | 2006-11-28 20:02:17 -0800 (Tue, 28 Nov 2006) | 1 line Daniel> r615 | dmg | 2006-11-28 20:00:41 -0800 (Tue, 28 Nov 2006) | 1 line Daniel> r614 | dmg | 2006-11-28 19:48:07 -0800 (Tue, 28 Nov 2006) | 47 lines Daniel> r613 | dmg | 2006-11-25 18:10:31 -0800 (Sat, 25 Nov 2006) | 21 lines Daniel> r612 | dmg | 2006-11-25 02:27:57 -0800 (Sat, 25 Nov 2006) | 3 lines Daniel> r611 | dmg | 2006-11-25 02:15:53 -0800 (Sat, 25 Nov 2006) | 22 lines Daniel> r603 | dmg | 2006-11-18 01:26:14 -0800 (Sat, 18 Nov 2006) | 1 line Daniel> r602 | dmg | 2006-11-18 01:24:59 -0800 (Sat, 18 Nov 2006) | 1 line Daniel> r601 | dmg | 2006-11-18 01:00:57 -0800 (Sat, 18 Nov 2006) | 15 lines Daniel> r600 | dmg | 2006-11-17 19:50:15 -0800 (Fri, 17 Nov 2006) | 6 lines Daniel> r599 | jim0watters | 2006-11-14 22:28:49 -0800 (Tue, 14 Nov 2006) | 1 line Daniel> r598 | jim0watters | 2006-11-12 22:33:23 -0800 (Sun, 12 Nov 2006) | 1 line Daniel> r597 | dmg | 2006-11-02 12:49:56 -0800 (Thu, 02 Nov 2006) | 1 line Daniel> r596 | dmg | 2006-10-28 14:30:35 -0700 (Sat, 28 Oct 2006) | 1 line Daniel> r595 | dmg | 2006-10-28 14:25:19 -0700 (Sat, 28 Oct 2006) | 1 line Daniel> r594 | dmg | 2006-10-28 13:48:25 -0700 (Sat, 28 Oct 2006) | 28 lines Daniel> r593 | dmg | 2006-10-28 11:15:22 -0700 (Sat, 28 Oct 2006) | 4 lines Daniel> r592 | dmg | 2006-10-28 11:03:33 -0700 (Sat, 28 Oct 2006) | 15 lines Daniel> r591 | dmg | 2006-10-27 02:33:04 -0700 (Fri, 27 Oct 2006) | 25 lines Daniel> r590 | dmg | 2006-10-27 00:56:17 -0700 (Fri, 27 Oct 2006) | 1 line Daniel> r589 | dmg | 2006-10-27 00:50:32 -0700 (Fri, 27 Oct 2006) | 1 line Daniel> r588 | dmg | 2006-10-26 23:34:41 -0700 (Thu, 26 Oct 2006) | 14 lines Daniel> r587 | dmg | 2006-10-26 22:44:16 -0700 (Thu, 26 Oct 2006) | 28 lines Daniel> r586 | dmg | 2006-10-26 18:02:17 -0700 (Thu, 26 Oct 2006) | 6 lines Daniel> r585 | dmg | 2006-10-26 16:44:27 -0700 (Thu, 26 Oct 2006) | 6 lines Daniel> r584 | dmg | 2006-10-26 16:43:55 -0700 (Thu, 26 Oct 2006) | 6 lines Daniel> r583 | dmg | 2006-10-25 11:20:19 -0700 (Wed, 25 Oct 2006) | 7 lines Daniel> r582 | dmg | 2006-10-25 10:26:17 -0700 (Wed, 25 Oct 2006) | 7 lines Daniel> r581 | dmg | 2006-10-25 10:15:40 -0700 (Wed, 25 Oct 2006) | 10 lines Daniel> r579 | dmg | 2006-10-24 09:50:49 -0700 (Tue, 24 Oct 2006) | 15 lines Daniel> r578 | dmg | 2006-10-22 20:18:58 -0700 (Sun, 22 Oct 2006) | 9 lines Daniel> r577 | dmg | 2006-09-24 19:27:35 -0700 (Sun, 24 Sep 2006) | 1 line Daniel> r574 | dmg | 2006-09-21 19:55:27 -0700 (Thu, 21 Sep 2006) | 1 line Daniel> r573 | dmg | 2006-09-20 21:40:50 -0700 (Wed, 20 Sep 2006) | 7 lines Daniel> r572 | dmg | 2006-09-20 21:34:16 -0700 (Wed, 20 Sep 2006) | 6 lines Daniel> r571 | dmg | 2006-09-20 17:12:36 -0700 (Wed, 20 Sep 2006) | 8 lines Daniel> r570 | maxlyons | 2006-09-16 12:24:41 -0700 (Sat, 16 Sep 2006) | 1 line Daniel> r566 | maxlyons | 2006-09-05 18:47:41 -0700 (Tue, 05 Sep 2006) | 1 line Daniel> r565 | maxlyons | 2006-09-05 18:40:14 -0700 (Tue, 05 Sep 2006) | 1 line Daniel> r564 | maxlyons | 2006-09-05 18:35:21 -0700 (Tue, 05 Sep 2006) | 1 line Daniel> r562 | dmg | 2006-09-01 23:20:07 -0700 (Fri, 01 Sep 2006) | 1 line Daniel> r561 | dmg | 2006-08-30 14:42:06 -0700 (Wed, 30 Aug 2006) | 1 line Daniel> r560 | dmg | 2006-08-12 23:35:56 -0700 (Sat, 12 Aug 2006) | 1 line Daniel> r559 | dmg | 2006-08-12 21:57:02 -0700 (Sat, 12 Aug 2006) | 1 line Daniel> r558 | dmg | 2006-08-12 21:50:19 -0700 (Sat, 12 Aug 2006) | 1 line Daniel> r557 | dangelo | 2006-08-12 11:26:27 -0700 (Sat, 12 Aug 2006) | 3 lines Daniel> r556 | dmg | 2006-08-05 11:08:04 -0700 (Sat, 05 Aug 2006) | 1 line Daniel> r555 | dmg | 2006-08-05 11:03:46 -0700 (Sat, 05 Aug 2006) | 1 line Daniel> r554 | dmg | 2006-07-30 15:06:47 -0700 (Sun, 30 Jul 2006) | 1 line Daniel> r553 | dmg | 2006-07-30 15:00:28 -0700 (Sun, 30 Jul 2006) | 1 line Daniel> r552 | dmg | 2006-07-30 12:52:39 -0700 (Sun, 30 Jul 2006) | 1 line Daniel> r551 | dmg | 2006-07-30 11:37:26 -0700 (Sun, 30 Jul 2006) | 1 line Daniel> r550 | dmg | 2006-07-28 23:48:12 -0700 (Fri, 28 Jul 2006) | 1 line Daniel> r549 | dmg | 2006-07-28 23:45:39 -0700 (Fri, 28 Jul 2006) | 1 line Daniel> r548 | dmg | 2006-07-28 23:19:43 -0700 (Fri, 28 Jul 2006) | 1 line Daniel> r547 | dmg | 2006-07-28 20:11:42 -0700 (Fri, 28 Jul 2006) | 1 line Daniel> r546 | dmg | 2006-07-28 20:04:01 -0700 (Fri, 28 Jul 2006) | 1 line Daniel> r545 | dmg | 2006-07-28 19:53:16 -0700 (Fri, 28 Jul 2006) | 1 line Daniel> r533 | brunopostle | 2006-07-11 13:54:04 -0700 (Tue, 11 Jul 2006) | 2 lines Daniel> r532 | dmg | 2006-07-10 23:18:08 -0700 (Mon, 10 Jul 2006) | 1 line Daniel> r531 | dmg | 2006-07-10 23:12:53 -0700 (Mon, 10 Jul 2006) | 1 line Daniel> r530 | dmg | 2006-07-10 23:11:30 -0700 (Mon, 10 Jul 2006) | 1 line Daniel> r529 | dmg | 2006-07-09 17:34:13 -0700 (Sun, 09 Jul 2006) | 1 line Daniel> r528 | dmg | 2006-07-08 13:41:51 -0700 (Sat, 08 Jul 2006) | 14 lines Daniel> r526 | dmg | 2006-06-30 07:17:37 -0700 (Fri, 30 Jun 2006) | 1 line -- 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-05 17:37:20
|
> Just remember, the reason to do this is so everybody can be happy with > the "link as you please" policy that the panotools is trying to > promote. Is anyone actively promoting the use of the new features of libpano13 via linking (maybe they are and I missed it)? Can't the linking issue be relegated to libpano12, which can slowly be replaced and deprecated in favor of non-linking, license-respecting use of libpano13, perhaps mediated through an updated project file format (e.g. XML-based)? > My code, given that is already licensed as GPL can be used and > reused in whatever project you want as GPL. I only object to it > being used under this linking policy. But, unless I'm mistaken, it isn't being used (yet), so the issue is, can all commercial users agree *not* to use it in that way, making pano13 the fresh start for the project? What am I missing? |
From: Daniel M. G. <dm...@uv...> - 2007-02-05 18:02:32
|
JD Smith twisted the bytes to say: >> Just remember, the reason to do this is so everybody can be happy with >> the "link as you please" policy that the panotools is trying to >> promote. JD> Is anyone actively promoting the use of the new features of libpano13 JD> via linking (maybe they are and I missed it)? Can't the linking issue JD> be relegated to libpano12, which can slowly be replaced and deprecated JD> in favor of non-linking, license-respecting use of libpano13, perhaps JD> mediated through an updated project file format (e.g. XML-based)? I feel uncomfortable within a project that actively supports linking (even for one version). From what we know linking hasn't happened with pano13. -- 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 . |