Bug 621416

This is not a complete review, but "MIT, partially public domain (see LICENSE)" is not a valid License tag. It should be "MIT and Public Domain", or even just "MIT" as that's what the license effectively is anyway (Public Domain stuff can be reused under any license). (Please also verify that the code claimed "Public Domain" is really placed in the public domain. I've seen people claiming "This is public domain software" and then listing a bunch of conditions on use or distribution, contradicting their claim. Truly Public Domain software cannot impose any such conditions.)

Here are some more comments:

- the license of the EPSG data files contains the following restriction:
  "The data may not be distributed for profit by any third party"
  I think this clause might be a problem. FE-Legal should have a look.

- drop BR: gzip and the call of gzip in %install as manpages are compressed automatically

- "%setup -q" should be sufficient in %prep

- I suggest to keep the timestamps of the csv files, e.g. by changing the for loop like this:
  for f in `find csv -type f | grep -q ISO-8859` ; do
    chmod 644 $f
    iconv -f ISO-8859-1 -t UTF-8 $f > ${f}.tmp
    touch -r $f $f.tmp
    mv -f $f.tmp $f
  done

- don't mix $RPM_BUILD_ROOT and %{buildroot}, use only one of them

- Delete the libtool archives (.la) and the static library (.a) in %install and remove both from %file (add "--disable-static" to %configure"). If the static lib is required by some reason, it should go to a -static package.

- I would remove, or at least prefix the generated manpages because some of the filenames, like index.1, are too generic and could conflict. Also, the man section should be 3 instead of 1. To me, it would be sufficient to provide the html docs.

> "The data may not be distributed for profit by any third party"

Yeah, this is not acceptable for Fedora. :-(

How this slipped through initial review, I don't know.

Unfortunately, this is going to be a serious problem because several other packages depend on this package.

LICENSE in the package appears to be out of date.

http://www.epsg-registry.org/help/xml/Terms_Of_Use.html

is the correct terms. I do believe that's why it was originally approved - upstream EPSG changed their terms. libgeotiff's README just needs updated.

This does, however, beg the question of why this issue isn't documented in the spec.  It certainly should have been, if only to avoid all of this confusion.

I've contacted upstream about the license and they'll change the file LICENSE.

I altered the loop a tad, since the chmod wouldn't catch it's target.

The manpages in an rpm-package don't have to be compressed? Are there different opinions on whether to keep the devel-manpages at all? Having this question pending, I haven't sorted out all issues associated with the manpages, Martin has pointed out.

Sadly there are some binaries that completely lack documentation. They are new for the release.

I guess, I can drop -r from the rm -rf, that only removes a single file, can I?

Spec URL: http://geofrogger.net/review/libgeotiff.spec
SRPM URL: http://geofrogger.net/review/libgeotiff-1.3.0-2.fc12.src.rpm

I don't know remember any more, however for the history of handling
license issue (especially EPSG license) can be found on:

https://bugzilla.redhat.com/show_bug.cgi?id=178162#c24
https://bugzilla.redhat.com/show_bug.cgi?id=222042#c6
https://bugzilla.redhat.com/show_bug.cgi?id=249296#c5

(In reply to comment #6)
> The manpages in an rpm-package don't have to be compressed?

Sorry if my previous comments were a bit unclear. 
You should not compress the manpages manually (e.g. by calling gzip in the spec file) because rpmbuild compresses them automatically when building the binary packages.

Since the doxygen generated manpages contain the API docs, they belong to section 3. Thus, the filename suffix should be 3 too. You can accomplish that by adding
sed -i '/^MAN_EXTENSION/d' docs/Doxyfile
before "make docs" for example. However, there's already a manpage index.3 documenting the string functions index and rindex, so you would get a clash here. I'm not sure how to deal with it. I would either prefix the filename or completely remove the manpages and go with the more comprehensive html docs.

> I guess, I can drop -r from the rm -rf, that only removes a single file, can I?

Yes, you can. :)

The package doesn't build at the moment because the .la file is still present but not packaged. Remove it with
rm -f %{buildroot}/%{_libdir}/*.la

Looks like this legal concern was resolved before I got to it. ;) Lifting FE-Legal.

Shall I wait for upstream's revised license file or much rather create a subpackage, since there are two different licenses? What is EPSG's license actually called?

There are a couple of "libtool: install: warning: `../libgeotiff.la' has not been installed in `/usr/lib64'". Should I worry about them?

Spec URL: http://geofrogger.net/review/libgeotiff.spec
SRPM URL: http://geofrogger.net/review/libgeotiff-1.3.0-3.fc12.src.rpm

(In reply to comment #10)
> Shall I wait for upstream's revised license file or much rather create a
> subpackage, since there are two different licenses? 

It's not necessary to wait for the updated license file. Just add a comment to the spec file that the license has been changed, and append the URL given by Bill in comment #4. You can drop it again once a new upstream release provides the current license text. There's also no need to split the data files into a subpackage.

> What is EPSG's license actually called?
I don't now. If something like "EPSG" was listed on [1], I would change the License tag to "MIT and EPSG". But since there's nothing like that, you can probably leave the tag as is. Maybe spot or some other legal expert can shed some light on this.

[1] http://fedoraproject.org/wiki/Licensing#Software_License_List


> There are a couple of "libtool: install: warning: `../libgeotiff.la' has not
> been installed in `/usr/lib64'". Should I worry about them?

No, you can ignore them.


> SRPM URL: http://geofrogger.net/review/libgeotiff-1.3.0-3.fc12.src.rpm

The URL doesn't work (404). :)


Finally, you should remove the compiler option -O3 added to CFLAGS. Fedora's %{optflags} already include -O2.
This can be done with "sed -i 's/ -O3 / /' configure" for example.

Spec URL: http://geofrogger.net/review/libgeotiff.spec
SRPM URL: http://geofrogger.net/review/libgeotiff-1.3.0-4.fc12.src.rpm (now really!)

Putting FE-Legal back on this. I don't think the EPSG license is okay, and I'm trying to figure out why I ever did think that.

Tom, can you explain why it is not?

Clause 2 in the license restricts for-profit distribution.

In my interpretation that refers to the standalone EPSG dataset. I think it's intended to keep you from selling something, they offer for free.

It later says:

"The data may be included in any commercial package provided that any commerciality is based on value added by the provider and not on a value ascribed to the EPSG Dataset which is made available at no charge."

Yeah, to me this sounds very much like the Artistic 2.0 and Bitstream Vera licenses which we both allow. But I'm not a lawyer… Tom, could we please get a definite expert opinion there, either from RH Legal or from the FSF?

Red Hat Legal confirms that the current EPSG license (as found on their website) is non-free.

Took me a while to figure out what caused the confusion here, so here's the explanation.

In 2007, Balint Cristian began a dialog with the maintainers of the EPSG dataset to change the licensing terms for that dataset to something that would be Free, and thus, acceptable to Fedora.

A draft license text was passed around, some clarifiying questions were asked, and at the end of it, we agreed that it was Free (barely).

Unfortunately, this text was never implemented, and the text on the website is substantially different from the draft text we reviewed.

What can we do about it?

Well, I would think the best bet would be to reach out to the EPSG folks and try to start a dialog about amending the license so that it is acceptable for Fedora (aka Free).

Specifically, the changes we would want are:

* Clarification or removal around the restrictions for including the EPSG dataset in a commercial offering. Would an image which contained only a trivial program (helloworld.c) and the EPSG dataset be permitted to be sold? If the answer is no, then it is a commercial use restriction.

(For what it is worth, I'm always baffled when people put commercial use restrictions on code or content that is available at no cost over the internet, especially when there is no hoops to jump through to acquire it. If someone is silly enough to pay for it, why would you wish to prevent that?)

* Clarification around modification. Specifically, wording that indicates that modification is always permitted, but that modifications outside of their defined scope will require that the dataset be renamed to something which does not use the EPSG trademarks.

There appears to be a place to leave a comment here:

http://www.epsg.org/Comms/Comment.asp

Re modification, do we really need to apply the rules for code as opposed to content here?

Strictly speaking no, but I would prefer if we had that right. Better to try for it.

I just sent an e-mail to Abby Findlay, who is the secretary of OGP, who take care of EPSG.

Any news here?

Not that I knew.

(In reply to comment #22)
> Strictly speaking no, but I would prefer if we had that right. Better to try
> for it.

Hello Folks,

 - Agree with booth, including lets try, but as last time with OGP and as for now there are some benevolent logic they might wont agree, for some good reason I can only explain that but only for "modify" paragraph.


 - that dataset is about some "ephemeres" and math like constants, its very wrong if people just modify those datas for potential forks, its like I would try some wierd math were PI is 3.15 instead if 3.14 and try even convince the world its just a brand new view on "geometries" and nothing is wrong.
 - OGP done that database and mark with their lets say "brand/name" and their credibility as surveyors (as Fedora guarantee certain things with their packages with their brand), things are done in years by precise geodetical surveys on-field and many calculus (many are done in colaboration with really paranoic and difficult governments), so any changes are made there for any reason as they also try state even in the very license is subject to alter "reality" for which EPSG cannot be responsable, and such changes are only for the damage of any community. They want by this way make sure any project is compatible with any other distinct project in resulting outputs in any future, like the example with PI constant. If at M.I.T. PI=3.14 at other universities should be too !


 Would this change a bit optics of RH legal on this ?


Regarding commercial (just guesses for very good reasons):

 - big and mogul companies like ESRI (the M$ equiv in GIS) would love to just bypass "the surveying stage of ephemers" for their products, but also would never give 1 cent to EPSG effort (I am confident in that). So EPSG decided that its free for "free" projects but not for ESRI or others who demonstrated ignorance at all during the time. They should go nicely on-field, pay their surveyors (even vaccinate them for dangerous places like those ones from Africa,Asia or Amazon) for lets say like 10 years and gather proper dataset on they own, then sell it just as they want. Unfortunately opensource GIS world is at a level with many things still to be done, but, by far cannot afford even to atempt to make a proper EPSG-like dataset without "borrowing" datas.And just from pure surveys (on field would be cleanest effort), also its not at the level to choke fingers with many governments to grant access to such datas, and even license it to a crowd of peoples as they would wish !

 In worst case, without EPSG we can forget "all" about Fedora and any of opensource GIS packages, to mention a list of: https://fedoraproject.org/wiki/GIS (and counting 10x more very interesting ones on the internet), so without EPSG _all_ those can be rendered outside of Fedora. Google highly popularised GIS around the world just by 'google-eath' there are the smart-phones, GPSs and cool navigation devices just spread in last 2-3 years, there are also the geotagged photos and so on, we would be lousy ones to skip these events out.


 I hope Volker to get a favorable answer back (I am doubting a bit), anyway I try catch up with Him see how could I help, some smooth and clean strategy is needed with OGP, but changing their optics will be hard.

While I do understand where they're coming from, this doesn't change that this license is not a Free license:
* about modification:
- All data can have errors. It is important that a project be able to fix any errors found in the data.
- The data may also change over time for physical reasons.
- Upstream themselves update their data every so often, which proves that it's NOT set in stone as you're trying to paint it.
* about the non-commercial restriction: This is just plain unacceptable for Fedora (as Fedora and derivative distributions must be redistributable for profit by third parties) and many other people and entities. No matter how good the intentions behind "free for Free projects only", this effectively renders the data non-Free. The freedom to use the data for any purpose, even commercial, is part of being Free. See also: http://freedomdefined.org/Licenses/NC

PS: If you want to change the value of M_PI in glibc to 3., you actually have the freedom to do that! It's part of being Free Software. And anyway, the data at hand here is not cast in stone the way pi is.

(In reply to comment #28)
> PS: If you want to change the value of M_PI in glibc to 3., you actually have
> the freedom to do that! It's part of being Free Software. And anyway, the data
> at hand here is not cast in stone the way pi is.


 OK, lets take theory: suppose I would.
 - I should try convince glibc comitee that my glibc fork is able to to such powerfull non-euclidian math, would even teleport through space-time bend created. I am sure some people even will belive that around the globe.

 There are the fonts too, is bitstream-vera still "vera" or only "bitstream" judging that i will modd 2-3 pixels around a decent fork ?
 
Guys,  Is there any way to derogate such exceptions at Fedora ?

No. There are no exceptions to the legal guidelines.

You MAY be able to convince FESCo that this data is content, not code, and as such can be distributed under the guidelines for content, which doesn't require the permission to modify. But even for content, banning commercial use is not acceptable.

Hold a moment,


The real license of EPSG data (one what we are in interest) is here:
http://www.epsg.org/CurrentDB.html

- I dont know why in front page is something "other" text ! (perhaps OGP != EPSG)
- Another way to check is: download it via http://www.epsg.org/databases/Arc/7_5/Discv7_5sql-mySql.html

  I can't see the "commercial restricion" amendament, in that form !

The new "Terms of Use" was Revised in 28 August 2007, that one is what Thomas and we got at that time. It even ship within the tarballs or the downlod-able files !

Please check up.


Can re-re-view this please ?

In the meanwhile we found more exactly (Web itself seems confusing):


 A) on web page offending paragraph #2 is:
      http://www.epsg.org/databases/Arc/7_5/Discv7_5sql-mySql.html
    "2. The EPSG Facilities are published by OGP at no charge.
Distribution for profit is forbidden. "

 B) inside tarball (e.g v7.5 mySQL) #2 says:
    "2. The data may be included in any commercial package provided
that any commerciality is based on value added  by the provider and
not on a value ascribed to the EPSG dataset which is made available at
no charge. The ownership of the EPSG dataset [OGP] must be
acknowledged."


We try ask EPSG why that discrepance, anyway can revew the one from tarball in the hope EPSG can fix/explain us web side ?

Created attachment 511657 [details]
Original EPSG tarball license document.

Original EPSG license document from their tarball distribution.

Any news ?

 Summing and proposal for a solution:

   - Discrepancy between web site and original license from their tarball.
   - We can include PDF doc into the rpm, reflecting the corect license.
   - We could include to all packages that are related to EPSG dataset.


* Attached the PDF out of their tarball to this ticket.
* See a summary Comment#32 for a light over the issue.

I have not seen additional comments on this package since Balint's comment on 7/7/2011, is what Balint purposed ok?  The code is clearly under the MIT license so it is just the data that is suspect.  I am wondering how we can break the log jam and get this very nice package updated.  Maybe we could remove the data altogether?   I ran the SPEC file and it builds nicely.

Yes, it's only about the data. I can't say anything about Balint's proposal though.

I'll try to start an appeal to Osgeo to find a sustainable solution to that problem. I contacted Debian's maintainer as a first step, as they suffer from the same problem.

Debian has an -epsg sub-package, so removing the data seems to be possible, but is not desireable, I fear.

Libtiff 4.0 was announced yesterday as well.

Ping? Any progress here? Or we can close this review?

Sadly, there's no progress at all.