Hi all, BTW: - autopano-sift is part of redhat/fedora since Thu 28 Jul 2005. - autopano-sift-c is part of fedora 8/9 - panotools is not part of Redhat: no license issue there afaik.
I think it is more related to "undiscovered area" than to legal restrictions. Harry 2008/10/23 Harry van der Wolf <[EMAIL PROTECTED]> > > > 2008/10/23 Yuval Levy <[EMAIL PROTECTED]> > >> >> Dear Guido and Harry, >> >> Guido Kohlmeyer wrote: >> > Thus Yuv's aproach should be continued. >> >> my approach was to look at those who are more experienced and have more >> resources than me. Red Hat, Novell, Canonical are all large corporations >> producing popular Linux distributions. Canonical is based in U.K. and >> AFAIK has nothing that makes it subject to US jurisdiction. Red Hat is >> 100% US jurisdiction. Novell is an interesting case because it is a US >> company that bought Suse, an off-shore subsidiary in Germany. >> >> All of them have their own lawyers and it can be safely assumed that >> they are looking at all legal aspects pertinent to their distribution. >> >> Latest since the SCO lawsuits it has become clear how important it is to >> know where the code comes from and what IP rights are attached to it. >> >> In an ideal world, those companies have legal compliance processes in >> place that examine each piece of code before letting it into the >> distribution. The processes may not be perfect, but they are better than >> mine simply because they have the necessary resources. >> >> None of them includes SIFT code. >> >> >> > > The ones you mentioned may not include it in their distro's. Debian > however, one of the strictest, does include it, and (K)Ubuntu, by now the > biggest, also includes it. > Red Hat and Novell do have big commercial interests with "big bugs" license > contracts, maintenance contracts and support contracts with DELL, IBM, > HP/Compac and others, where these contracts are expanded to (second line) > commercial business partners of DELL, IBM, but also resellers and finally > end-users (customers). Their commercial "part" is the part that keeps them > alive these days and where they can't take risk. Their lawyers ONLY look at > their commercial interests and risks and not to the (non interesting and > risk less) GPL, open source "no bugs generating" part of it. > That's a huge difference with Hugin and therefore not comparable at all > (imo). > > > As soon as Hugin is at the same level as RedHat (or MySQL as another > example), it might be wise to spend more time to these kind of legal > aspects. > I have no fear whatsoever that "The university of British Columbia" will > ever start a trial at a (commercial) panoVR photographer from the USA, > using a Hugin "full package" from an Open Source packager. This will not be > worth the effort (unless this photographer wins the world press photo or > something like that and maybe even in that case I expect them (UBC) to use > it as a showcase rather than a case for trial). > Big businesses or organisations (organizations for USA residents, also > different here) starting to use a "full package" hugin to generate money for > their businesses/organisations might be a completely different case for UBC. > > > > @Guido: I suggested that "my" approach, a derivation of Yuv's > approach, could be used. In Open Source it's still the packager who more or > less decides what he/she wants to package (or risk). (And who is uncertain > what is happening to him/her while he/she is serving the community with only > the best intents as a volunteer spending many hours for others). > Also a big difference with RedHat, who deliver "products and services" for > "mainframe, server, desktop, small/medium/big companies" with the above > mentioned (big bugs) contracts (and yes also for the non-commercial > end-user). > Also Ippei and I interpret things differently when it comes to these > license cases. We've come to an agreement which we both feel serves us well > (delivering autopano-sift-c as plugin as a separate, installable package > within the Hugin package). However, we are both also not 100% happy with the > situation. > I am however a fan of Ippei's plugin solution as it gives the packager the > flexibility and possibility to deliver a hugin and their accompanying > plugins from one single webpage, but not as one package. This keeps it save > (next to making it more flexible for the packager to create hugin svn > packages and occasionally do a CP plugin upgrade). > > > Hoi, > Harry > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
