Re: [Fedora-packaging] License issue for all GIS related packages. [call for help]
by Tom Callaway
On Tue, 2007-06-26 at 00:35 +0200, Balint Cristian wrote:
> Pardon me if i mistake here, a _non_ lawyer point of view:
>
> Here arised in my mind that epsg tables ar not similar as PCI ID
> plain only database, a new entry in that database need certain
> certification and probaly very precise technical mesurments before it
> can
> be validated and ratified. I dont think anyone can easy do this step,
> like just PCI-ID ones. EPSG asummed this task to collect cand
> ertificate those
> constants and projections in the past. The process is not an easy one
> as far
> I understanded, but this is only the technical side. That could be
> olso the strong
> reason to not let those constants to be altered in some way.
>
> Please correct me if i mistakenly miss understood that EPSG
> activity from
> tech point of view. Just wanted make some comment over certain value
> of
> database.
I think that there are several good parallels here, the most obvious
seems to be that of the GNU Free Documentation License (GFDL),
specifically section 4, which permits modification, but also describes
what you must do as the end result of modification.
Another good example is the Bitstream Font License. Bitstream wanted to
make their Fonts available for the Free Software community, and to
permit people to make derived fonts from Bitstream fonts, but they
didn't want people selling the fonts standalone, or referring to any
derived fonts as "Bitstream".
Here is their license, in its entirety:
======================
Copyright (c) 2003 by Bitstream, Inc. All Rights Reserved. Bitstream
Vera is a trademark of Bitstream, Inc.
Permission is hereby granted, free of charge, to any person obtaining a
copy of the fonts accompanying this license (“Fonts”) and associated
documentation files (the “Font Software”), to reproduce and distribute
the Font Software, including without limitation the rights to use, copy,
merge, publish, distribute, and/or sell copies of the Font Software, and
to permit persons to whom the Font Software is furnished to do so,
subject to the following conditions:
The above copyright and trademark notices and this permission notice
shall be included in all copies of one or more of the Font Software
typefaces.
The Font Software may be modified, altered, or added to, and in
particular the designs of glyphs or characters in the Fonts may be
modified and additional glyphs or characters may be added to the Fonts,
only if the fonts are renamed to names not containing either the words
“Bitstream” or the word “Vera”.
This License becomes null and void to the extent applicable to Fonts or
Font Software that has been modified and is distributed under the
“Bitstream Vera” names.
The Font Software may be sold as part of a larger software package but
no copy of one or more of the Font Software typefaces may be sold by
itself.
THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF
COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL
BITSTREAM OR THE GNOME FOUNDATION BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL,
OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT
SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE.
Except as contained in this notice, the names of Gnome, the Gnome
Foundation, and Bitstream Inc., shall not be used in advertising or
otherwise to promote the sale, use or other dealings in this Font
Software without prior written authorization from the Gnome Foundation
or Bitstream Inc., respectively. For further information, contact: fonts
at gnome dot org.
======================
So, to sum it up, here's what we would like to see:
The license needs to permit people to create derived works of the EPSG
dataset. Simply because we cannot fathom any possible derived works does
not mean that the right should be withheld. This is at the very heart of
open source and free software. However, it is perfectly acceptable to
say that those derived works may not call themselves the EPSG dataset.
If we can get that, we can include the EPSG dataset in Fedora. :)
~spot
16 years, 9 months
License issue for all GIS related packages. [call for help]
by Balint Cristian
Hello folks,
All GIS packages (from fedora-extras now fedora) suffer a missing of geodetic constants
sets from www.epsg.org (very important for GIS otherwise) becouse of license issues. I
personaly tried to add some packages to fedora and maintain those, but basicly some of tham
are pure repack of tarballs and removal of some doubted piece of code. I am a GIS fan, i tryed my
very best to shape and polish up all GIS related packages and its related libs: ogdi, gdal, grass,
mapserver, but without geodetic constants is like in math trigonometry without PI constant ...
Its very frustrating that tons of GIS code depends on a simple collection of 'constants' like PI
one from math, in a simple excel like file ...
The problem, more exactly, is with this dataset aviable at: http://www.epsg.org, (the organisation
who collected datasets and made them aviable), under EPSG Version 6.12 Online Documentation
there is an 'Use of data' section with the license, you can follow it to read.
The hurting license text is:
3. The data may not be distributed for profit by any third party;
After some mail excenge between OSSgeo (http://www.ossgeo.org) chairman who is olso very
interested as open source party of GIS, me and other folks, EPSG proposed a draft and called OSgeo
to review it. Fortunatley OSgeo has no lawyer they kindly pass this away with the reason that they
are not lawyers too :) and the whole thing remain stalled.
I would like if someone look into attached proposal from OSgeo, and if its OK i would like to invite him
to help me out in a possible discuss with Roger Lott (chairman of EPSG) as per a good law technical one.
I attach the new version of license draft proposed by EPSG itself, a preliminary verdict that validate
its usability for open source scope would be fine , before start to talk with EPSG ...
BTW,
There is extremly nice and powerfull GIS software, like http://grass.itc.it/ wich can easy compete
GIS software giant: http://www.esri.com.
This would be great if happen :)
/christian
16 years, 9 months
Update to php-eaccelerator and how to make it "just work"
by Matthias Saou
Hi,
I'm currently cleaning up the php-eaccelerator package. It has been in
Fedora since the very beginning and I'm pretty sure it never went
through any review (straight from freshrpms).
The major change I have to do is "fix" the version :
"5.2.3_0.9.5.1" has to become plain "0.9.5.1"
...so I'll have to introduce and epoch :-(
The problem is historical, as the module had to track the main php
package's version quite closely, back when the zend_abi version wasn't
provided by the php package, and this ugly trick was an easy way for end
users to know if the package was the correct one.
Anyway, I'll be doing that unless someone objects ;-)
The next issue is that the cache files created by the module are stored
in /var/cache/php-eaccelerator/ and the ownership of that directory is
hardcoded to apache:apache in the package. This is a problem when using
php with another web server, lighttpd for instance (which I do a lot).
It's even worse when using multiple web servers on the same machine...
I'd like the find a clean solution for this. The only one I can think
of is to have php-eaccelerator create its own group in which it'll
put apache, lighttpd and eventually others, and have the cache
directory owned by "root:eacceler" (it's better with only 8 chars,
right?) and set g+S. This way, all web servers should be able to write
and read cache files. I was also thinking of adding the web server
users to the group by using triggers in the php-eaccelerator package.
Does this seem sane to do?
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7
Load : 0.72 0.81 0.81
16 years, 9 months
Hardlinking *.pyc and *.pyo
by Ville Skyttä
Hello,
Related to recent space saving discussions, I came across PLD's
rpm-build-macros package recently, and found that they hardlink
identical *.pyc and *.pyo. In a lot of cases, they're the same,
and there's some potential for saving some MB "for free",
on my FC6 x86_64 box:
$ /usr/sbin/hardlink -ncv /usr/lib*/python2.4 2>&1 | tail -n 1
Would save 11116544
The PLD implementation looks like this:
# Hardlink binary identical .pyc and .pyo files
# (idea by glen <at> pld-linux <dot> org)
%__spec_install_post_py_hardlink {\
%{!?no_install_post_py_hardlink: __spec_install_post_py_hardlink() { \
[ ! -d "$RPM_BUILD_ROOT" ] || find "$RPM_BUILD_ROOT" -name '*.pyc' | while read a; do \
b="$(echo $a|sed -e 's/.pyc$/.pyo/')"; \
if cmp -s "$a" "$b"; then \
ln -f "$a" "$b"; \
fi; \
done \
}; __spec_install_post_py_hardlink } }
The use of "cmp" would require diffutils installed. Or the above
could be converted to use hardlink instead (which would have to be made
sure to be around) or maybe sha1sum (in coreutils, pretty much always
around in buildroots).
I suppose something like the above could be easily added to
redhat-rpm-config or rpm, eg. embedded in brp-python-bytecompile
or run after it in %__os_install_post.
Worth it? Other comments?
16 years, 9 months
Proposal: Allow upstream VCS commit ID in alphatag
by Jason L Tibbitts III
I have drafted http://fedoraproject.org/wiki/PackagingDrafts/CommitIDs
and added it to the schedule. The proposal is simply to add the
following text to the naming guidelines to the "Snapshot packages"
section:
If the upstream revision control system provides some sort of unique
commit identifier, it may be appended to the `%{alphatag}`:
{{{
YYYYMMDDsvn12345
YYYYMMDDgit5aef11739b
}}}
This has been in use for a while in a few instances, so it would be
good to consider it officially.
- J<
16 years, 9 months
ocaml signature hashing: really neccessary?
by Axel Thimm
I wonder whether this is maybe overdesigned. AFAIU this signature
hashing was made because ocaml is not considered stable enough to
carry over signatures from release to release.
Same could be told about hundreds of C libraries, wouldn't the
neccessity in ocaml then imply a neccessity to hash C-library APIs as
well? Maybe it's something we will consider to do someday, but the
order would be to cater for C/C++/Fortran/etc libraries first and then
for niche languages like ocaml.
I think it's a bit too much, or did I miss something important (I'm
not a real ocaml user, there is just this one application that even
justifies ocaml's existance ;)
--
Axel.Thimm at ATrpms.net
16 years, 9 months
Re: native code incompatibilities vs byte code incompatibilities
by Richard Jones
On Fri, Jun 15, 2007 at 11:19:30AM +0100, Stefano Zacchiroli wrote:
> On Fri, Jun 15, 2007 at 11:02:31AM +0100, Richard Jones wrote:
> > OK, I see the point now. I had assumed -- wrongly -- that the hash of
> > a.cmo would change in this case, but it does not. So we need a
> > version of ocamlobjinfo which can handle *.cmx files as well.
>
> Right, that's our issue to. Maybe now we are two different large
> distribution we have more power to go and ask INRIA for this?
>
> Julien: can you refresh our memory about the tool (IIRC) you spotted in
> the OCaml sources able to extract info from *.cmx files?
>
> > There is another problem with ocamlobjinfo too. See:
> > http://groups.google.co.uk/group/fa.caml/msg/f2c3e9e8cfa628b3?hl=en&
> >
> > In Fedora we have avoided this by having a list of modules in the
> > standard library which we just ignore (Asttypes, Outcometree and
> > Cmo_format so far).
>
> Ok, maybe we can keep it on a shared wiki page to ease of maintenance?
Yup, I don't mind.
Rich.
--
Richard Jones
Red Hat
16 years, 9 months
Re: native code incompatibilities vs byte code incompatibilities
by Richard Jones
On Fri, Jun 15, 2007 at 10:04:44AM +0100, Stefano Zacchiroli wrote:
> On Fri, Jun 15, 2007 at 09:44:32AM +0100, Stefano Zacchiroli wrote:
> > > > Still, native code objects can break link time compatibility with
> > > > compatible .cmis.
> > > I don't understand - why is this?
> > I'll try to reproduce the problem in a sandbox...
>
> Ok, here is an example and an explanation:
>
> $ cat a.ml b.ml main.ml
> (* a.ml *)
> let foo () = 1
> (* b.ml *)
> let bar () = A.foo () + 1
> (* main.ml *)
> print_int (B.bar ())
> $ # let's build in bytecode and nativecode (with inlining)
> $ ocamlc -c a.ml
> $ ocamlc -c b.ml
> $ ocamlc -o a.byte a.cmo b.cmo main.ml
> $ ocamlopt -inline 100 -c a.ml
> $ ocamlopt -inline 100 -c b.ml
> $ ocamlopt -o a.native a.cmx b.cmx main.ml
> $ # now let's change the *implementation* of module A and recompile that module only
> $ sed -i s/1/2/ a.ml
> $ ocamlc -c a.ml
> $ # relinking in bytecode work, i.e. assumptions over interfaces are respected
> $ ocamlc -o a.byte a.cmo b.cmo main.ml
> $ # relinking in nativecode fails, i.e. assumptions over implementations are not respected
> $ ocamlopt -inline 100 -c a.ml
> $ ocamlopt -o a.native a.cmx b.cmx main.ml
> Files b.cmx and a.cmx make inconsistent assumptions over implementation A
>
> The rationale is that with inlining enabled, ocamlopt when building
> module B has embedded in it implementations coming from module A. If
> that is changed module B needs to be rebuilt as well.
>
> Now: do you have a way to inspect native code objects for extracting
> assumptions related to module implementations? Cause we have been so far
> able only to extract assumption about interfaces...
OK, I see the point now. I had assumed -- wrongly -- that the hash of
a.cmo would change in this case, but it does not. So we need a
version of ocamlobjinfo which can handle *.cmx files as well.
There is another problem with ocamlobjinfo too. See:
http://groups.google.co.uk/group/fa.caml/msg/f2c3e9e8cfa628b3?hl=en&
In Fedora we have avoided this by having a list of modules in the
standard library which we just ignore (Asttypes, Outcometree and
Cmo_format so far).
Rich.
--
Richard Jones
Red Hat
16 years, 9 months
Re: "slicing" ocaml 3.10.0: comparison with debian friends?
by Richard Jones
On Fri, Jun 15, 2007 at 09:44:32AM +0100, Stefano Zacchiroli wrote:
> On Fri, Jun 15, 2007 at 08:34:54AM +0100, Richard Jones wrote:
> > > Still, native code objects can break link time compatibility with
> > > compatible .cmis.
> > I don't understand - why is this?
>
> Out of the box I don't know how to reproduce it, but we have been beaten
> by this in the past. IIRC md5sum information stored in native code
> objects are not only about interfaces but also about the actual module
> implementations. Given that they are not inspectable (ocamlobjinfo only
> work on bytecode objects) you have no way to check them.
I think we've dealt with this one by depending on the
name-version-release of ocaml itself.
This makes it an all-or-nothing thing: as on Debian we need to upgrade
every OCaml package at the same time. This is causing a problem at
the moment because I can't get PXP & CDuce compiled. CDuce upstream
have released a full version for OCaml 3.10, but PXP (on which CDuce
depends) haven't done so yet.
Rich.
--
Richard Jones
Red Hat
16 years, 9 months