[opensuse-packaging] Split licenses.rpm (based on 'Building packages with linking a license from licenses.rpm')
Moin, After our discussion with JSrain we decided to write to packages with just another issue about licenses.rpm. The current RPM content size (unpacked) is quite big du -sh /usr/share/doc/licenses/ -> 3.9 MB This package-size is a bit disputable when talking about saving-space ;) Actually it is because the package contains some very-rare licenses or some obscure licenses used just for one package in our distribution. The proposal is simple: - Find out, which packages in a minimal installation use which licenses and create licenses-base.rpm (for example) that would contain only those important/used licenses. - The rest could stay in licenses.rpm. We'd save space for the minimal-installation and we'd still have all licenses for 'the other cases'. BTW: I have to admit, that splitting-it up was a jsrain's idea :) ;) What do you think of that? Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic
On 2007-07-25 14:07:07 +0200, Lukas Ocilka wrote:
After our discussion with JSrain we decided to write to packages with just another issue about licenses.rpm.
The current RPM content size (unpacked) is quite big du -sh /usr/share/doc/licenses/ -> 3.9 MB
how much space do we save with no longer duplicating files?
This package-size is a bit disputable when talking about saving-space ;)
it would still save us space on the media. and text files can be compressed very well.
Actually it is because the package contains some very-rare licenses or some obscure licenses used just for one package in our distribution.
The proposal is simple: - Find out, which packages in a minimal installation use which licenses and create licenses-base.rpm (for example) that would contain only those important/used licenses. - The rest could stay in licenses.rpm.
We'd save space for the minimal-installation and we'd still have all licenses for 'the other cases'. BTW: I have to admit, that splitting-it up was a jsrain's idea :) ;)
What do you think of that?
do you have any numbers for the license-base.rpm? how many licenses would be needed? whats the installed size? darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Marcus Rueckert wrote:
On 2007-07-25 14:07:07 +0200, Lukas Ocilka wrote:
After our discussion with JSrain we decided to write to packages with just another issue about licenses.rpm.
The current RPM content size (unpacked) is quite big du -sh /usr/share/doc/licenses/ -> 3.9 MB
how much space do we save with no longer duplicating files?
This package-size is a bit disputable when talking about saving-space ;)
it would still save us space on the media. and text files can be compressed very well.
Yes, the current solution fits the task 'make installation media smaller' well but there is another major task: 'make the minimal installation small as possible'.
Actually it is because the package contains some very-rare licenses or some obscure licenses used just for one package in our distribution.
The proposal is simple: - Find out, which packages in a minimal installation use which licenses and create licenses-base.rpm (for example) that would contain only those important/used licenses. - The rest could stay in licenses.rpm.
We'd save space for the minimal-installation and we'd still have all licenses for 'the other cases'. BTW: I have to admit, that splitting-it up was a jsrain's idea :) ;)
What do you think of that?
do you have any numbers for the license-base.rpm? how many licenses would be needed? whats the installed size?
Honestly, we didn't do any research in that way. That would need to check every single package in the minimal installation whether it contains some file with license and which license it is. We are asking for your opinion whether it even makes sense to invest (waste) some time in this area ;) Lukas
On Wed, Jul 25, 2007 at 02:27:13PM +0200, Lukas Ocilka wrote:
We are asking for your opinion whether it even makes sense to invest (waste) some time in this area ;)
You should consider one big warning here: If you have only one license package you can just add licenses there and basically never delete one. This ensures that with a license package that is at least as recent as your other most recent package you can always fulfill any dependencies. If you do licenses-base you might want to remove licenses there as well and move them into the other licenses package but as soon as you start removing licenses from there you might break older packages installed on a system. Sure you can find solutions for all these problems but in my opinion it will just produce a bug mess and source of inconsistencies. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Robert Schiele wrote:
On Wed, Jul 25, 2007 at 02:27:13PM +0200, Lukas Ocilka wrote:
We are asking for your opinion whether it even makes sense to invest (waste) some time in this area ;)
You should consider one big warning here: If you have only one license package you can just add licenses there and basically never delete one. This ensures that with a license package that is at least as recent as your other most recent package you can always fulfill any dependencies. If you do licenses-base you might want to remove licenses there as well and move them into the other licenses package but as soon as you start removing licenses from there you might break older packages installed on a system.
Sure you can find solutions for all these problems but in my opinion it will just produce a bug mess and source of inconsistencies.
That's a good point, thanks. On the other hand it always depends on the current solution: Possibly buggy solution ----------------------- * licenses-base.rpm provides 'licenses-base' * my package requires 'licenses-base' Possibly working solution :) ------------------------- (already mentioned on this mailing-list) * licenses-base.rpm provides 'licenses/md5/005e9765ce1a51f0aab9b2e14a785474' ... 'licenses/md5/0636e73ff0215e8d672dc4c32c317bb3' 'licenses/md5/18ba770020b624031bc7c8a7b055d776' ... 'licenses/md5/fd6c32a44ff3cf3efd167ddb697b9eb1' * my package requires 'licenses/md5/0636e73ff0215e8d672dc4c32c317bb3' Even if the license is moved anywhere else, the dependency is solved automagically ;) (if "Provides" is changed as well). Lukas
Hello, on Mittwoch, 25. Juli 2007, Lukas Ocilka wrote:
After our discussion with JSrain we decided to write to packages with just another issue about licenses.rpm.
The current RPM content size (unpacked) is quite big du -sh /usr/share/doc/licenses/ -> 3.9 MB
This package-size is a bit disputable when talking about saving-space ;) Actually it is because the package contains some very-rare licenses or some obscure licenses used just for one package in our distribution.
You mentioned an interesting point: Licenses used just for one package. IMHO it's pointless to move them to the licenses package because you can't save any space - you only can waste it if the package with that license isn't installed. I'd propose to put only licenses that are used at least by 10 packages in the licenses package. This solves several problems: - the non-existing space saving effect I mentioned above - the risk of having to keep old licenses (as mentioned by Robert) just to stay backward-compatible is reduced (because at least some of the packages will still be using it ;-) - the licenses package would be smaller - no need to split it Just to give you some numbers, I did some statistics on 10.2's ARCHIVES.gz (from retail DVD): # zgrep License: ARCHIVES.gz | sed 's/.*License: //' | sort | uniq -c |sort -nr 3402 GNU General Public License (GPL) 817 GNU Library General Public License v. 2.0 and 2.1 (LGPL) 470 GNU General Public License (GPL), GNU Library General Public License v. 2.0 and 2.1 (LGPL) 399 BSD License and BSD-like 377 GNU General Public License (GPL), Other License(s), see package 334 X11/MIT 302 Artistic License 301 BSD License and BSD-like, Other License(s), see package 229 Other License(s), see package 165 Other uncritical OpenSource License, Other License(s), see package 112 The Apache Software License 106 BSD License and BSD-like, GNU General Public License (GPL) 92 Public Domain, Freeware, Other License(s), see package 71 Freely Redistributable Software (FSR), Other License(s), see package 61 The Apache Software License, Other License(s), see package 59 Artistic License, Other License(s), see package 57 Public Domain, Freeware 56 GNU Library General Public License v. 2.0 and 2.1 (LGPL), Other License(s), see package 55 X11/MIT, Other License(s), see package 54 Artistic License, GNU General Public License (GPL) 52 Commercial (all types), Other License(s), see package 45 MOZILLA PUBLIC LICENSE (MPL/NPL) 30 IBM Public License 29 Other uncritical OpenSource License 26 TeX-License, Other License(s), see package 26 GNU General Public License (GPL), THE Q PUBLIC LICENSE (QPL) 21 IBM Public License, Other License(s), see package 16 No license agreement found in package, Other License(s), see package 16 Freely Redistributable Software (FSR) 15 GNU General Public License (GPL), X11/MIT 15 Contact author, Other License(s), see package 13 GNU Free Documentation License, Version 1.1 (GFDL), GNU General Public License (GPL) 12 GNU General Public License (GPL), Public Domain, Freeware 12 BSD License and BSD-like, GNU Library General Public License v. 2.0 and 2.1 (LGPL) 11 No license agreement found in package 11 MOZILLA PUBLIC LICENSE (MPL/NPL), Other License(s), see package 11 GNU Library General Public License v. 2.0 and 2.1 (LGPL), MOZILLA PUBLIC LICENSE (MPL/NPL) 10 Beerware, Cardware, Shareware (not restricted), Other License(s), see package 8 zlib/libpng License 8 The Apache Software License, X11/MIT 7 Python Copyright, Other License(s), see package 7 Commercial (all types) 6 Public Domain, Freeware, X11/MIT 6 LaTeX Public License (LPPL) 5 GNU Library General Public License v. 2.0 and 2.1 (LGPL), Public Domain, Freeware 4 Python Copyright 4 GNU General Public License (GPL), Other uncritical OpenSource License 4 GNU General Public License (GPL), MOZILLA PUBLIC LICENSE (MPL/NPL) 4 GNU Free Documentation License, Version 1.1 (GFDL) 4 Beerware, Cardware, Shareware (not restricted) 3 GNU General Public License (GPL), No license agreement found in package 3 GNU Free Documentation License, Version 1.1 (GFDL), GNU Library General Public License v. 2.0 and 2.1 (LGPL) 2 THE Q PUBLIC LICENSE (QPL) 2 GNU Library General Public License v. 2.0 and 2.1 (LGPL), No license agreement found in package 2 GNU General Public License (GPL), The Apache Software License 2 GNU Free Documentation License, Version 1.1 (GFDL), Other License(s), see package 2 Contact author 2 Commercial (all types), GNU General Public License (GPL) 2 BSD License and BSD-like, X11/MIT 2 BSD License and BSD-like, Python Copyright 2 BSD License and BSD-like, GNU Free Documentation License, Version 1.1 (GFDL) 2 Artistic License, Public Domain, Freeware 1 YaST License 1 Restricted Shareware 1 GNU General Public License (GPL), Linux Documentation Project License (LDPL) Of course these numbers aren't set in stone because already an additional space makes "another" GPL version, but you should get the point - it's pointless to move the "YaST License" to the licenses package. BTW: I'm curious about the legal status of packages with License: No license agreement found in package ... ;-) Regards, Christian Boltz --
Bitkollisionen finden v.a. in Kneipen und Festzelten statt, würde ich mal annehmen. [H. Bengen] Und zu viele davon führen zu einem stomach overflow? [L. Barth]
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Boltz wrote:
Hello, ... You mentioned an interesting point: Licenses used just for one package. IMHO it's pointless to move them to the licenses package because you can't save any space - you only can waste it if the package with that license isn't installed.
I'd propose to put only licenses that are used at least by 10 packages in the licenses package. This solves several problems: - the non-existing space saving effect I mentioned above - the risk of having to keep old licenses (as mentioned by Robert) just to stay backward-compatible is reduced (because at least some of the packages will still be using it ;-) - the licenses package would be smaller - no need to split it
Actually *all* licenses are in one package, so moving a license file from one to another isn't *space wasting* :) rpm -ql licenses | grep /usr/share/doc/licenses/md5/ | wc -l 263 Your proposal including a license in licenses.rpm seems to be interesting, however it doesn't solve *space wasting* because there is no such issue. We should, of course, include only licenses, that are in use. Backward compatibility should be considered only for already released RPMs for one product. (I think this might be a bit tricky if not handled correctly). Have a nice... whatever :) Lukas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGrPmcVSqMdRCqTiwRAmCEAJ0cuzTS3uqiknL+9Y5+AiLVCWEAoACbBEH4 xSjdK0qREwQ/qXjbogV9mPo= =nyNm -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, on Sonntag, 29. Juli 2007, Lukas Ocilka wrote:
Christian Boltz wrote:
Hello, ... You mentioned an interesting point: Licenses used just for one package. IMHO it's pointless to move them to the licenses package because you can't save any space - you only can waste it if the package with that license isn't installed.
I'd propose to put only licenses that are used at least by 10 packages in the licenses package. This solves several problems: - the non-existing space saving effect I mentioned above - the risk of having to keep old licenses (as mentioned by Robert) just to stay backward-compatible is reduced (because at least some of the packages will still be using it ;-) - the licenses package would be smaller - no need to split it
Actually *all* licenses are in one package, so moving a license file from one to another isn't *space wasting* :)
Only if each of the licenses is needed by at least one _installed_ package.
rpm -ql licenses | grep /usr/share/doc/licenses/md5/ | wc -l 263
Do you have some statistics *how many times* each of them is used? This would be the most interesting information here.
Your proposal including a license in licenses.rpm seems to be interesting, however it doesn't solve *space wasting* because there is no such issue.
Depends of the point of view. There *is* such an issue on the well-discussed "minimal system" with only few packages installed. In this case, you don't need any of the more "exotic" licenses. You only need GPL, LGPL and the BSD license. (Yes, I know this is over-simplified, but you should get the point.) OTOH, I think that nearly no space will be wasted by "unused" licenses on my full-blown home installation (workstation + web development + much more). Looking at it from the other way round: By moving all licenses to the licenses package, - you _can_ save space at often used licenses (GPL and LGPL are the best examples, they are used hundres of times each) - you _cannot_ save space if a license is only needed by one package. This may even need additional space if the package with this license isn't installed.
We should, of course, include only licenses, that are in use.
Obvious - we don't need the Windows EULA ;-)
Backward compatibility should be considered only for already released RPMs for one product. (I think this might be a bit tricky if not handled correctly).
Sooner or later, you'll end up with a licenses-compat package. And, whatever you do, the size will always increase because of new licenses, but never decrease because you aren't allowed to remove "outdated" licenses. And you'll probably have to ship all licenses* packages, including -compat, in every media set, even on the one-CD for legal reasons [1] - you know how small a CD can be? ;-) Regards, Christian Boltz [1] I doubt that a pointer "please download all licenses at download.opensuse.org/somepath" is valid... -- Since 1997 we are VERP-DoSing mail servers all over the world [Henne Vogelsang in opensuse about lists.suse.com] --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Jul 29, 07 00:28:32 +0200, Christian Boltz wrote:
I'd propose to put only licenses that are used at least by 10 packages in the licenses package. This solves several problems: - the non-existing space saving effect I mentioned above - the risk of having to keep old licenses (as mentioned by Robert) just to stay backward-compatible is reduced (because at least some of the packages will still be using it ;-) - the licenses package would be smaller - no need to split it
No. The point in having /usr/share/doc/licenses is that this establishes one single location where all licenses used in a product are visible. So the content of the licenses.rpm should not only be comprehensive, but also exact. We can easily ignore any space saving effects.
# zgrep License: ARCHIVES.gz | sed 's/.*License: //' | sort | uniq -c |sort -nr [...]
Of course these numbers aren't set in stone because already an additional space makes "another" GPL version, but you should get the point
we have 20 or 30 textual variations of the same GPL, if I recall correctly.
- it's pointless to move the "YaST License" to the licenses package.
-au contraire.
BTW: I'm curious about the legal status of packages with License: No license agreement found in package ... ;-)
This is an error. If you spot any of these after Alpha6, please file a bug. cheers, Jw. -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de wide open suse_/ _---|____________\/ \ | 0911 74053-508 (tm)__/ (____/ /\ (/) | __________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Oral agreements are worth about as much as the paper they are written on." --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On Jul 30 17:26 Juergen Weigert wrote (shortened):
The point in having /usr/share/doc/licenses is that this establishes one single location where all licenses used in a product are visible.
Might this cause confusion for some users when they find out that they have many special licenses installed but not the software which belongs to those special licenses? I.e. what about "my installed licenses" versus "all licenses which are somewhere used by whatever software in the product"? (Yes, I know, the obvious technical solution is to check to which installed license a symlink points ;-) Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Johannes Meixner wrote:
Hello,
On Jul 30 17:26 Juergen Weigert wrote (shortened):
The point in having /usr/share/doc/licenses is that this establishes one single location where all licenses used in a product are visible.
Might this cause confusion for some users when they find out that they have many special licenses installed but not the software which belongs to those special licenses?
I agree. Moreover I have to say, I'm confused: who should profit from the licenses.rpm packgage? If this is intended for users it's IMHO superfluous: to find what license has some package, users will either use 'rpm -qi' (or equivalent) or go to /usr/share/doc/packages/<pkg>. If this is because of us as distributors, I really don't see any significant advantages (if size question is insignificant). In any case, licenses for not installed products are confusing and I regard the obligation to install such package a bloat.
I.e. what about "my installed licenses" versus "all licenses which are somewhere used by whatever software in the product"?
(Yes, I know, the obvious technical solution is to check to which installed license a symlink points ;-)
Isn't it the same effort as scanning /usr/share/doc/packages for license files (rather than for symlinks pointing to /usr/share/doc/licenses)? Best regards Petr Cerny --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 2007-07-31 13:35:59 +0200, Petr Cerny wrote:
Johannes Meixner wrote:
Hello,
On Jul 30 17:26 Juergen Weigert wrote (shortened):
The point in having /usr/share/doc/licenses is that this establishes one single location where all licenses used in a product are visible.
Might this cause confusion for some users when they find out that they have many special licenses installed but not the software which belongs to those special licenses?
I agree. Moreover I have to say, I'm confused: who should profit from the licenses.rpm packgage? If this is intended for users it's IMHO superfluous: to find what license has some package, users will either use 'rpm -qi' (or equivalent) or go to /usr/share/doc/packages/<pkg>. If this is because of us as distributors, I really don't see any significant advantages (if size question is insignificant).
In any case, licenses for not installed products are confusing and I regard the obligation to install such package a bloat.
it is less bloat than having the same file multiple times on the system. this package is not about "having all licenses" installed. it is about having a way to save space _and_ still have the license file available for symlinking. i dont see an issue of having a documentation packaging around that carries all used licenses. as a comparison: should an RFC package only install the files, which contain infos about my installed services? i dont think so.
I.e. what about "my installed licenses" versus "all licenses which are somewhere used by whatever software in the product"?
(Yes, I know, the obvious technical solution is to check to which installed license a symlink points ;-)
Isn't it the same effort as scanning /usr/share/doc/packages for license files (rather than for symlinks pointing to /usr/share/doc/licenses)?
this is all about saving space. so a symlink will definitely help us. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, On Jul 31 13:45 Marcus Rueckert wrote (shortened):
i dont see an issue of having a documentation packaging around that carries all used licenses. as a comparison: should an RFC package only install the files, which contain infos about my installed services?
Don't mix up usual documentation with legal stuff. A package license file is not just "documentation". Often a license file is a contract between the user and the manufacturer of the software. I don't know (IANAL) what it means from the legal point of view if such a contract is installed but the associated software is not, e.g. when the contract or license talks only about "the software". Again and again: This is not a technical issue. It is a legal issue. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Marcus Rueckert wrote:
On 2007-07-31 13:35:59 +0200, Petr Cerny wrote:
Johannes Meixner wrote:
Hello,
The point in having /usr/share/doc/licenses is that this establishes one single location where all licenses used in a product are visible. Might this cause confusion for some users when they find out that
On Jul 30 17:26 Juergen Weigert wrote (shortened): they have many special licenses installed but not the software which belongs to those special licenses? I agree. Moreover I have to say, I'm confused: who should profit from the licenses.rpm packgage? If this is intended for users it's IMHO superfluous: to find what license has some package, users will either use 'rpm -qi' (or equivalent) or go to /usr/share/doc/packages/<pkg>. If this is because of us as distributors, I really don't see any significant advantages (if size question is insignificant).
In any case, licenses for not installed products are confusing and I regard the obligation to install such package a bloat.
it is less bloat than having the same file multiple times on the system. this package is not about "having all licenses" installed. it is about having a way to save space _and_ still have the license file available for symlinking.
Juergen Weigert wrote:
No. The point in having /usr/share/doc/licenses is that this establishes one single location where all licenses used in a product are visible. So the content of the licenses.rpm should not only be comprehensive, but also exact.
We can easily ignore any space saving effects.
Please consult previous posts: this "space saving" makes sense for small distribution (USB, PDA). Then however you would probably bzip2 each license file to really gain as much space as possible. On a fully-blown desktop distro the space saving would be visible, yet less needed. Moreover on a desktop with some 2000 packages you would save more space by uninstalling the packages you really don't need yet the got there because installer thought you might use them.
i dont see an issue of having a documentation packaging around that carries all used licenses. as a comparison: should an RFC package only install the files, which contain infos about my installed services?
i dont think so.
Wrong types in comparision. Installing rfc package is much more like installing *-devel or *-debuginfo packages than licenses.
I.e. what about "my installed licenses" versus "all licenses which are somewhere used by whatever software in the product"?
(Yes, I know, the obvious technical solution is to check to which installed license a symlink points ;-) Isn't it the same effort as scanning /usr/share/doc/packages for license files (rather than for symlinks pointing to /usr/share/doc/licenses)?
this is all about saving space. so a symlink will definitely help us.
I would say it differently: *If* this is all about saving space a symlink will *usually* help us. AFAIK on some (if not most) filesystems symlink takes one block (1KB at least) if the referenced filename takes more than 60B (e.g. strlen("/usr/share/doc/license/license-<md5sum>")=64 *in 1byte encoding*). MIT license is small (600B) so it occupies the same space as the symlink - one block. With GPL symlink helps. Best regards Petr --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, on Montag, 30. Juli 2007, Juergen Weigert wrote:
On Jul 29, 07 00:28:32 +0200, Christian Boltz wrote:
BTW: I'm curious about the legal status of packages with License: No license agreement found in package ... ;-)
This is an error. If you spot any of these after Alpha6, please file a bug.
I'm afraid it's not only one bug I have to file... From Factory ARCHIVES.gz (zgrep "No license" | sort | uniq -c) as of today: 3 Artistic License, No license agreement found in package, accepted by IBM (said to be GPL) 4 GPL v2 or later, No license agreement found in package 3 LGPL v2 or later, No license agreement found in package 33 No license agreement found in package 3 No license agreement found in package, Public Domain, Freeware 2 No license agreement found in package, Public Domain, Freeware, (C) International Organization for Standardization 1986 17 No license agreement found in package, this package contains only pictures, sounds and icons, but no code. I can not define any license. This package will be part of the official KDE 2.2 release. The detailed list, including package names, is attached. What do you prefer: One report for all, or one per package (which would mean *lots of* reports)? Also interesting: There are several license tags in german: 52 BSD 3-Clause, Mit dem Zusatz (aus COPYING): 1 GPL v2 or later, NACHFOLGEND SIND DIE VERTRAGSBEDINGUNGEN F R DIE BENUTZUNG UND DEN ERWERB VON Another problem: Several packages seem to contain multi-line licenses, but ARCHIVES.gz only contains the first line of it (grep for "License: .*:$"). Is this also worth bugreports? (If yes: against the packages, against rpm or against the script generating ARCHIVES.gz?) The "best" i found is: 3 GNU Free Documentation License, Version 1.1 (GFDL), see https://bugzilla.novell.com/show_bug.cgi?id=277387 Needless to say that bug 277387 resolves to "access denied" :-( There are some other minor problems, sometimes it seems like internal notes were put to the license tag. If you find some free time, read zgrep License: ARCHIVES.gz |sed 's/.*License: //' |sort | uniq -c (about 330 lines) So: How many bugreports shall I file? ;-) Regards, Christian Boltz -- Lies halt mal dclp.*, da faellt dir nix mehr ein. Wenn man ein Guerteltier ueber die Tastatur abrollt, kommt besserer PHP Code raus als da gepostet wird. [R. Huebenthal in darw]
participants (7)
-
Christian Boltz -
Johannes Meixner -
Juergen Weigert -
Lukas Ocilka -
Marcus Rueckert -
Petr Cerny -
Robert Schiele