[opensuse-packaging] in a lib package, where does the copyright info go?
As I look at already installed lib* packages I find different answers to this question. some have 3 packages 1) libFOO 2) libFOOX where X comes from the SONAME and contains the .so.x.x.x 3) libFOO-devel And I have seen case like this where the the copyright and other docs is in 1)libFOO I have also seen cases that look like this 1)libFOOX where X comes from the SONAME and contains the .so.x.x.x 2)libFOO-devel and the copyright was in libFOO-devel I have even seen cases where there was a copyright file in the libFOOX package! In the case of a library, which packages get the copyright file and which don't? When is there supposed to be the libFOO package (without the SONAME number)? I can not find where policy on this is documented for open suse. -- Paul Elliott 1(512)837-1096 pelliott@BlackPatchPanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
1) libFOO 2) libFOOX where X comes from the SONAME and contains the .so.x.x.x 3) libFOO-devel
I am not a lawyer, so only common sense tels me that if any piece of libFOO (libFOO, libFOOX, libFOO-devel or other) is installed, then appropriate license must be present (by this subpackage or its requirement). This is in contradiction with our Shared library packaging policy though. Petr
On Tue, Sep 06, 2011 at 08:55:57AM +0200, Petr Gajdos wrote:
1) libFOO 2) libFOOX where X comes from the SONAME and contains the .so.x.x.x 3) libFOO-devel
I am not a lawyer, so only common sense tels me that if any piece of libFOO (libFOO, libFOOX, libFOO-devel or other) is installed, then appropriate license must be present (by this subpackage or its requirement). This is in contradiction with our Shared library packaging policy though.
/usr/share/doc/packages/<pkgname>/ seems like a fine place for it and would not collide. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 6 Sep 2011, Marcus Meissner wrote:
On Tue, Sep 06, 2011 at 08:55:57AM +0200, Petr Gajdos wrote:
1) libFOO 2) libFOOX where X comes from the SONAME and contains the .so.x.x.x 3) libFOO-devel
I am not a lawyer, so only common sense tels me that if any piece of libFOO (libFOO, libFOOX, libFOO-devel or other) is installed, then appropriate license must be present (by this subpackage or its requirement). This is in contradiction with our Shared library packaging policy though.
/usr/share/doc/packages/<pkgname>/ seems like a fine place for it and would not collide.
Yes, /usr/share/doc/packages/<sub-pkgname>/ would be ok even for libFOOX (but not /usr/share/doc/packages/libFOO/ for libFOOX for example). If I put on an IANAL hat then every subpackage has to contain the license information. But _at least_ it should be present if any of the packages are installed. Thus, as usually libFOO-devel requires libFOOX the license should be present in libFOOX. It should always be present in libFOOX as that can be installed separately without any other subpackages. Thus, the shared library policy should be amended that it's ok to put _license_ information (but not readme, news, etc.) for the shared-library package libFOOX into /usr/share/doc/packages/libFOOX/. I'm going to amend it this way. Richard. -- Richard Guenther <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
On Tuesday, September 06, 2011 02:37:36 AM you wrote:
On Tue, 6 Sep 2011, Marcus Meissner wrote:
On Tue, Sep 06, 2011 at 08:55:57AM +0200, Petr Gajdos wrote:
1) libFOO 2) libFOOX where X comes from the SONAME and contains the .so.x.x.x 3) libFOO-devel
I am not a lawyer, so only common sense tels me that if any piece of libFOO (libFOO, libFOOX, libFOO-devel or other) is installed, then appropriate license must be present (by this subpackage or its requirement). This is in contradiction with our Shared library packaging policy though.
/usr/share/doc/packages/<pkgname>/ seems like a fine place for it and would not collide.
Yes, /usr/share/doc/packages/<sub-pkgname>/ would be ok even for libFOOX (but not /usr/share/doc/packages/libFOO/ for libFOOX for example).
If I put on an IANAL hat then every subpackage has to contain the license information. But _at least_ it should be present if any of the packages are installed. Thus, as usually libFOO-devel requires libFOOX the license should be present in libFOOX. It should always be present in libFOOX as that can be installed separately without any other subpackages.
Thus, the shared library policy should be amended that it's ok to put _license_ information (but not readme, news, etc.) for the shared-library package libFOOX into /usr/share/doc/packages/libFOOX/.
I'm going to amend it this way.
Richard.
This would appear to conflict with debian practice, see Debian Policy Manual section 8.2 http://www.debian.org/doc/debian-policy/ch-sharedlibs.html Since the upstream source for a large number of projects was originally written for debian, and then tweeked by a .spec file author to also work for suse and the other rpm based distros, this will result in spec file tweeking, with associated labor and maintainence costs. One can control the PACKAGE a file is in simply by moving a line from one package to the other. But if the name or directory a file is in changes from debian to rpm that invokes hand tweeking, (In the absence of changes by the upstream author). -- Paul Elliott 1(512)837-1096 pelliott@BlackPatchPanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
On Tue, 6 Sep 2011, Paul Elliott wrote:
On Tuesday, September 06, 2011 02:37:36 AM you wrote:
On Tue, 6 Sep 2011, Marcus Meissner wrote:
On Tue, Sep 06, 2011 at 08:55:57AM +0200, Petr Gajdos wrote:
1) libFOO 2) libFOOX where X comes from the SONAME and contains the .so.x.x.x 3) libFOO-devel
I am not a lawyer, so only common sense tels me that if any piece of libFOO (libFOO, libFOOX, libFOO-devel or other) is installed, then appropriate license must be present (by this subpackage or its requirement). This is in contradiction with our Shared library packaging policy though.
/usr/share/doc/packages/<pkgname>/ seems like a fine place for it and would not collide.
Yes, /usr/share/doc/packages/<sub-pkgname>/ would be ok even for libFOOX (but not /usr/share/doc/packages/libFOO/ for libFOOX for example).
If I put on an IANAL hat then every subpackage has to contain the license information. But _at least_ it should be present if any of the packages are installed. Thus, as usually libFOO-devel requires libFOOX the license should be present in libFOOX. It should always be present in libFOOX as that can be installed separately without any other subpackages.
Thus, the shared library policy should be amended that it's ok to put _license_ information (but not readme, news, etc.) for the shared-library package libFOOX into /usr/share/doc/packages/libFOOX/.
I'm going to amend it this way.
Richard.
This would appear to conflict with debian practice, see Debian Policy Manual section 8.2 http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
Since the upstream source for a large number of projects was originally written for debian, and then tweeked by a .spec file author to also work for suse and the other rpm based distros, this will result in spec file tweeking, with associated labor and maintainence costs.
One can control the PACKAGE a file is in simply by moving a line from one package to the other.
But if the name or directory a file is in changes from debian to rpm that invokes hand tweeking, (In the absence of changes by the upstream author).
But that's simply a long-standing difference where debian puts package specific documentation (/usr/share/package-name/ vs. /usr/share/packages/package-name/) Richard. -- Richard Guenther <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
On Tue, 6 Sep 2011 13:55, Paul Elliott <pelliott@...> wrote:
On Tuesday, September 06, 2011 02:37:36 AM you wrote:
On Tue, 6 Sep 2011, Marcus Meissner wrote:
On Tue, Sep 06, 2011 at 08:55:57AM +0200, Petr Gajdos wrote:
1) libFOO 2) libFOOX where X comes from the SONAME and contains the .so.x.x.x 3) libFOO-devel
I am not a lawyer, so only common sense tels me that if any piece of libFOO (libFOO, libFOOX, libFOO-devel or other) is installed, then appropriate license must be present (by this subpackage or its requirement). This is in contradiction with our Shared library packaging policy though.
/usr/share/doc/packages/<pkgname>/ seems like a fine place for it and would not collide.
Yes, /usr/share/doc/packages/<sub-pkgname>/ would be ok even for libFOOX (but not /usr/share/doc/packages/libFOO/ for libFOOX for example).
If I put on an IANAL hat then every subpackage has to contain the license information. But _at least_ it should be present if any of the packages are installed. Thus, as usually libFOO-devel requires libFOOX the license should be present in libFOOX. It should always be present in libFOOX as that can be installed separately without any other subpackages.
Thus, the shared library policy should be amended that it's ok to put _license_ information (but not readme, news, etc.) for the shared-library package libFOOX into /usr/share/doc/packages/libFOOX/.
I'm going to amend it this way.
Richard.
This would appear to conflict with debian practice, see Debian Policy Manual section 8.2 http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
Since the upstream source for a large number of projects was originally written for debian, and then tweeked by a .spec file author to also work for suse and the other rpm based distros, this will result in spec file tweeking, with associated labor and maintainence costs.
One can control the PACKAGE a file is in simply by moving a line from one package to the other.
But if the name or directory a file is in changes from debian to rpm that invokes hand tweeking, (In the absence of changes by the upstream author).
Just a moment, people, please. Aren't the sub-packages under exactly the same license as the master-package? Isn't it so that without the master package the sub-packages can't be installed regulary? (without --nodeps etc) Then only /usr/share/doc/packages/<master-package>/ should exist. No sense in cluttering a system with useless, senseless sh*t. any documentation of a package, includnig it's dependend sub-packages shloud be there, and not in any additional dir under /usr/share/doc/packages/ . It's waste of space enough as it is, no sense to add to that. What about /usr/share/doc/licences/<licence-name> and just a file named LICENSE_IS_<licence-name> with a content of a line "see /usr/share/doc/licences/<licence-name>" to end that waste of space on the same file over and over. At least for the most used licenses (GPL, BSD, Mozilla, Apache) and their acknowlged derivates this would be sufficent to the license and the law. Just let a file-deduplation run on the /usr/share/doc/packages/ directory of a normally installed system and look at the output. For a SSD installation this is not acceptable, even less for more space restriced systems. Why not just include a license in everything, even the compiled code to be more absurd. ATM we are getting there. Stop it. Now. Take a step back, regain sanity, wisdom, and forward thinking. Find a workable, qualified, space conserving solution. Yamaban. PS: Sorry for the rant, but themata "Licence included in everthing" becomes absurd. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tuesday, September 06, 2011 07:32:35 AM Yamaban wrote:
On Tue, 6 Sep 2011 13:55, Paul Elliott <pelliott@...> wrote:
On Tuesday, September 06, 2011 02:37:36 AM you wrote:
On Tue, 6 Sep 2011, Marcus Meissner wrote:
On Tue, Sep 06, 2011 at 08:55:57AM +0200, Petr Gajdos wrote:
1) libFOO 2) libFOOX where X comes from the SONAME and contains the .so.x.x.x 3) libFOO-devel
I am not a lawyer, so only common sense tels me that if any piece of libFOO (libFOO, libFOOX, libFOO-devel or other) is installed, then appropriate license must be present (by this subpackage or its requirement). This is in contradiction with our Shared library packaging policy though.
/usr/share/doc/packages/<pkgname>/ seems like a fine place for it and would not collide.
Yes, /usr/share/doc/packages/<sub-pkgname>/ would be ok even for libFOOX (but not /usr/share/doc/packages/libFOO/ for libFOOX for example).
If I put on an IANAL hat then every subpackage has to contain the license information. But _at least_ it should be present if any of the packages are installed. Thus, as usually libFOO-devel requires libFOOX the license should be present in libFOOX. It should always be present in libFOOX as that can be installed separately without any other subpackages.
Thus, the shared library policy should be amended that it's ok to put _license_ information (but not readme, news, etc.) for the shared-library package libFOOX into /usr/share/doc/packages/libFOOX/.
I'm going to amend it this way.
Richard.
This would appear to conflict with debian practice, see Debian Policy Manual section 8.2 http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
Since the upstream source for a large number of projects was originally written for debian, and then tweeked by a .spec file author to also work for suse and the other rpm based distros, this will result in spec file tweeking, with associated labor and maintainence costs.
One can control the PACKAGE a file is in simply by moving a line from one package to the other.
But if the name or directory a file is in changes from debian to rpm that invokes hand tweeking, (In the absence of changes by the upstream author).
Just a moment, people, please. Aren't the sub-packages under exactly the same license as the master-package? Isn't it so that without the master package the sub-packages can't be installed regulary? (without --nodeps etc)
The Problem is the package that must be installed (i.e. master package) the libFOOX package, is also the package that varies most rapidly. The libFOOX package changes with every new SONAME. The libFOO-devel package depends on _A_ libFOOX package, but it can outlive any one of them. You might want to have a pointer in libFOO-devel to the copyright file but you can't because libFOOX might be newer and have a different X hence different directory names. That is, if the copyright file is /usr/share/packages/libFOOX/copyright in the package libFOOX, then how can the package libFOO-devel have a pointer to this file, when the -devel package does not know what X is? If on the otherhand, the copyright file is /usr/share/packages/libFOO-devel/copyright but the copyright file is owned by the libFOOX package, which package will be the owner of the directory /usr/share/packages/libFOO-devel? Remember the libFOOX package can be installed when the libFOO-devel is not. If you force libFOO-devel to be replaced everytime a libFOOX chages, that is everytime a SONAME changes, you undermine the value of the libtool versioning system and force a lot of user programs, (which are not necessarily packaged), to be recompiled. You also force a lot of new versions of packaged programs. Also, at least under debian there can be more than one libFOOX package installed! This allows program compiled with different versions of libFOO-devel to be installed at the same time. The libtool versioning system is setup to allow for this. Is this not the case with opensuse as well? In this case, a copyright file owned by libFOOX can not be installed in a common place like /usr/share/packages/libFOO because you would get 2 packages owning the same file. But if the copyright file is in /usr/share/packages/libFOOX/copyright then you could have 2 copies of the copyright file. (For 2 different Xs i.e. libFOO5 and libFOO6 could be installed at same time so: /usr/share/packages/libFOO5/copyright /usr/share/packages/libFOO6/copyright The libFOOX package is used to run programs under the gpl and most OS/FS licenses, programs can be run without a license. To distribute a program you must develop it first. But to develop it you will need the -devel package. It that package contains the license you will have your opertunity to read the license. Distributing is the activity that usually triggers the need for a license. Thus it is OK for the license info to be in the -devel package. The above is an example of the truism that there is generally method in the debian madness. If you try to vary from the debian way without carefull thought you generally run into problems. Even opensuse has tumbleweed now.
Then only /usr/share/doc/packages/<master-package>/ should exist. No sense in cluttering a system with useless, senseless sh*t. any documentation of a package, includnig it's dependend sub-packages shloud be there, and not in any additional dir under /usr/share/doc/packages/ . It's waste of space enough as it is, no sense to add to that.
What about /usr/share/doc/licences/<licence-name> and just a file named LICENSE_IS_<licence-name> with a content of a line "see /usr/share/doc/licences/<licence-name>" to end that waste of space on the same file over and over. At least for the most used licenses (GPL, BSD, Mozilla, Apache) and their acknowlged derivates this would be sufficent to the license and the law.
Just let a file-deduplation run on the /usr/share/doc/packages/ directory of a normally installed system and look at the output.
For a SSD installation this is not acceptable, even less for more space restriced systems.
Why not just include a license in everything, even the compiled code to be more absurd. ATM we are getting there.
Stop it. Now. Take a step back, regain sanity, wisdom, and forward thinking. Find a workable, qualified, space conserving solution.
Examining the details is the key to this.
Yamaban.
PS: Sorry for the rant, but themata "Licence included in everthing" becomes absurd.
-- Paul Elliott 1(512)837-1096 pelliott@BlackPatchPanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
Hi, On Tue, 6 Sep 2011, Paul Elliott wrote:
The Problem is the package that must be installed (i.e. master package) the libFOOX package, is also the package that varies most rapidly. The libFOOX package changes with every new SONAME. The libFOO-devel package depends on _A_ libFOOX package, but it can outlive any one of them.
That's not correct. A libfoo-devel package of a certain version depends on exactly one specific libfooX package, as the .so softlink needs to point to a certain .so.X file, and that X is exactly the X in the package name.
You might want to have a pointer in libFOO-devel to the copyright file
And even if the above weren't true you would solve all problems by not wanting such a pointer. But as the above is true all your worries vanish.
Also, at least under debian there can be more than one libFOOX package installed!
That's the whole point of encoding the major version in the package name, indeed.
In this case, a copyright file owned by libFOOX can not be installed in a common place like /usr/share/packages/libFOO because you would get 2 packages owning the same file.
Ehh? That's why we have this discussion, the proposal is to put the license into /usr/share/packages/libfoox.
To distribute a program you must develop it first. But to develop it you will need the -devel package. It that package contains the license you will have your opertunity to read the license. Distributing is the activity that usually triggers the need for a license. Thus it is OK for the license info to be in the -devel package.
No it's not. Think about libfoo5 and libfoo6 that have different licenses. As there's only one -devel package you wouldn't be able to see both licenses. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (6)
-
Marcus Meissner -
Michael Matz -
Paul Elliott -
Petr Gajdos -
Richard Guenther -
Yamaban