On Tue, 2007-10-09 at 16:22 -0700, Toshio Kuratomi wrote: > Andrew Bartlett wrote: > > On Tue, 2007-10-09 at 10:07 -0800, Jeff Spaleta wrote: > > > >> Samba as a project has every right to re-license its codebase as it > >> sees fit. But at the same time, don't we as a distributor have some > >> responsibility to make sure we introduce that change in such a way to > >> minimize potential licensing violations? I think we do. > > > > Isn't this an argument for the Licence tags on RPMs, and for someone to > > run a depsolver over the packages, ensuring the packages do not rely on > > services with incompatible licences? > > > > Bumping the soname just makes people recompile code, with no further > > indication as to what is incompatible. Unlike and ABI change, the > > problem doesn't go away with a rebuild. > > > > I think the problem people are trying to address is how to allow the > packages which can only link to libsmbclient-GPLv2+ to do so while > providing samba-GPLv3+ for everything else. If we have an SONAME bump, > then we can have a package for the programs which need GPLv2 and a > package for the packages which are free to move on. The problem is, there is no long-term will to maintain such a -compat package. How long would such a package last - forever if other packages don't move? Who would maintain it? The bit that bothers me is that not only was Samba for the longest time mentioned in most GPLv3 news articles, we asked if anybody had a reason not to change our licence, and nobody gave a compelling reason. We have time yet before Samba 3.2.0 for other packages to either allow a compatible licence, or decide that they no longer need the services Samba's library provides. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
