Licensing guidelines suggestions
by Ville Skyttä
Hello,
Here's a few notes/questions that IMO need to be addressed in the new
licensing guidelines in Wiki. IANAL, etc, but anyway, something for near
future FPC meetings (which I still probably won't be able to attend to for a
couple of weeks):
1) The licensing pages strongly imply that OSI-approved licenses are ok.
However for example the original Artistic license is OSI-approved but listed
in Wiki page as "bad". Something needs real fixing - "ask upstream to move
to a "good" Artistic license" is IMO just a band aid.
http://fedoraproject.org/wiki/Licensing
http://www.opensource.org/licenses/artistic-license.php
2) The Wiki pages refer to "files" and "content" without specifying whether
those refer to files/content in the source rpm, the resulting binary rpms, or
both.
Example case: an upstream source tarball contains source files under let's say
BSD, LGPLv2.1+ and GPLv2+ licenses. That would mean that let's say a binary
built from all those would fall under GPLv2+. Specifying GPLv2+ as the
License tag would be misrepresenting the copyrights of the files in the
source rpm that carry BSD and LGPLv2.1+ notices. Specifying "BSD and
LGPLv2.1+ and GPLv2+" would be misrepresenting the copyright of the combined
work in the resulting binary.
3) Source licenses are not the only thing that affect the distributables'
copyrights. For example when something is built from let's say LGPLv2+
sources but linked with a GPLv2+ library, the resulting binary will be
GPLv2+, while the sources are still LGPLv2+ (unless their embedded copyright
notices are changed to GPLv2+, but that can't be done for many *GPL
licenses).
Suggested combined fix for 2) and 3) above: change the licensing guidelines to
prominently note something like that the value of the License tag represents
the copyright/license info of binary packages only, and only when built in
the configuration specified by the Fedora build system, build
dependencies/conflicts in the specfile, and no non-Fedora software installed
that will affect the build in any way. Source rpms' copyrights are
determined by the sources and other content included in them.
16 years, 8 months
New db4 update and package changes
by Jindrich Novy
Hi folks,
you may have noticed Oracle released db-4.6.18 recently. The update is
now prepared in CVS, old db-4.5.20 is now moved to compat-db so the new
db4 is ready to hit rawhide soon.
I want to announce a change I made in the new db4, that may affect
you from the packaging POV if your package is dependent on db4. It is
that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages
to reduce dependency bloat (#220484).
If you have any proposals/objections related to the update, please speak up.
Thanks,
Jindrich
--
Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/
16 years, 8 months
Texlive packaging and "Errata packages"
by Jonathan Underwood
Hi,
Jindrich Novy has been preparing texlive packages for F8 for a while
now, and there are essentially 3 RPMs:
telive (the binaries)
texlive-texmf (the texmf tree)
and texlive-texmf-errata
The one I am concerned about is telive-texmf-errata. As Jindrich says
"This is the errata package for the TeXLive 2007 formatting system.
The purpose of this package is to support updates to huge texmf tree
without a need to download all the texmf tree again, but to ship only
the fixed parts. texlive-errata puts updated files into a seperate
texmf tree which is searched prior to the main tree so there are no
conflicts between texlive-errata and texlive-texmf packages."
I think this is a totally different packaging paradigm - as far as I'm
aware there's no precedent in Fedora for issuing errata packages
rather than updated packages. A far better alternative IMO is to have
finer grained subpackaging of the texlive texmf tree, such that
updates don't replace the whole thing. That of course has other major
advantages, such as allowing smaller tex installs.
Also, to have *two* system managed texmf trees searched is a big
change, and something else that system admins have to think about when
they add their own local texmf trees.
Put more bluntly, while I understand the convenience from a packagers
point of view, this seems like a really ugly way to package. It feels
a bit like the ever increasing number of hotfixes you get installed on
an M$ system (although there would never be more than a single
texmf-errata package installed at a time of course).
I know Rex Dieter likes the errata package idea. I wonder what others think?
Cheers,
Jonathan
16 years, 8 months
multiple changlog entries for one e-v-r
by Till Maas
Aloas,
is it ok to use multiple changelog entries for one e-v-r?
E.g.:
%changelog
* Thu Jun 15 2003 Joe Packager <joe at gmail.com> - 1.0-2
- Added LICENSE file (#43).
* Wed Jun 14 2003 Joe Packager <joe at gmail.com> - 1.0-2
- Added README file (#42).
Regards,
Till
16 years, 8 months
Package EOL procedure when merging two packages
by Todd Zullinger
Hola,
I want to get a sanity check on something so I don't cause any dep
problems. I'm planning to merge the python-gpod package into the main
libgpod package (it was originally built separately due to
requirements on Extras packages).
This is planned for devel first, and then eventually F7. As I
understand it, I should:
a) add a dead.package file in the devel branch for python-gpod
explaining that it's been merged with libgpod, and delete the other
files from the branch.
b) ask rel-eng to block the package from devel.
I'm unsure about b. Can anyone help clarify this and let me know if
I'm missing other steps? (The package isn't in comps and will remain
in FC6 for sure, and F7 for a little while at least -- so steps 3 and
4 on PackageMaintainers/PackageEndOfLife aren't relevant.)
Thanks,
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If quitters never win, and winners never quit, then who is the fool
who said "Quit while you're ahead?"
16 years, 8 months
