[GeoNetwork-devel] [GeoNetwork-commit] SF.net SVN: geonetwork:[5774] sandbox/BlueNetMEST

Clive_Boughton · February 14, 2010, 10:22pm

sppigot@anonymised.com wrote:

Revision: 5774
          http://geonetwork.svn.sourceforge.net/geonetwork/?rev=5774&view=rev
Author: sppigot
Date: 2010-02-14 10:16:10 +0000 (Sun, 14 Feb 2010)

Log Message:
-----------
Fixes for remote search (XML requests)

Modified Paths:
--------------
    sandbox/BlueNetMEST/src/org/fao/geonet/kernel/search/Z3950Searcher.java
    sandbox/BlueNetMEST/web/geonetwork/WEB-INF/classes/JZKitConfig.xml.tem
    sandbox/BlueNetMEST/web/geonetwork/WEB-INF/lib/jzkit_service-3.0.1-SNAPSHOT.jar
    sandbox/BlueNetMEST/web/geonetwork/WEB-INF/lib/jzkit_z3950_plugin-3.0.1-SNAPSHOT.jar

This is now getting rather serious, and the most
significant consequence of using these new snapshots
is the change to the licensing.

(It would help if the filenames were not
merely jzkit...SNAPSHOT... but had
the JZKit SVN revision number in them.)

On 2010-01-20 the LICENSE.txt file of JZKit 3 was changed.
It was GPL; it is now AGPL. To incorporate
an AGPL-licensed library into GN (BlueNet
in this case, but presumably the trunk sometime
down the track) is a major
change, and may be a burden on users,
especially if they make local modifications.
Please see clause 13 of the licence.

Perhaps this turns out to be no big deal,
but it is not _obvious_ that it's not
a big deal. For instance, AGPL is a modified GPL,
not a modified LGPL.
I think we should be _very sure_ of the
consequences for everyone before
proceeding.

--
Richard Walker
Software Improvements Pty Ltd
Phone: +61 2 6273 2055
Fax: +61 2 6273 2082

Timo_Proescholdt · February 15, 2010, 12:03am

Dear Richard,
dear all,

thanks for pointing out this issue. As far as the filenaming is
concerned, this is how the libraries compile with the supplied build
script. While I understand your concern, it is far from unusual to use
the vendor supplied file-naming. We can talk about finding another scheme.

But I think the AGPL issue is the more important thing here anyway.
AFAIK JZKit3 has been using this licenese since it was first released,
as can be seen at e.g.
http://developer.k-int.com/svn/jzkit/jzkit3/tags/jzkit_3.0.0/jzkit_service/LICENSE.txt
so this is not a sudden change.

I checked this before working with JZKit3 and I did not consider it an
issue, since it is all about code modification. If the AGPL code was
modified, this would be a different issue, but we only link to it.

My reading is that you can still build (and sell) your own applications
of GN without them falling under AGPL.

However, I'm having this checked by people more into law and copyright.

best regards
Timo

--
Timo Pröscholdt
Program Officer, WMO Information System (WIS)
Observing and Information Systems Department
World Meteorological Organization
Tel: +41 22 730 81 76
Cell: +41 77 40 63 554
e-mail: tproescholdt@anonymised.com

This is now getting rather serious, and the most
significant consequence of using these new snapshots
is the change to the licensing.

(It would help if the filenames were not
merely jzkit...SNAPSHOT... but had
the JZKit SVN revision number in them.)

On 2010-01-20 the LICENSE.txt file of JZKit 3 was changed.
It was GPL; it is now AGPL. To incorporate
an AGPL-licensed library into GN (BlueNet
in this case, but presumably the trunk sometime
down the track) is a major
change, and may be a burden on users,
especially if they make local modifications.
Please see clause 13 of the licence.

Perhaps this turns out to be no big deal,
but it is not _obvious_ that it's not
a big deal. For instance, AGPL is a modified GPL,
not a modified LGPL.
I think we should be _very sure_ of the
consequences for everyone before
proceeding.

sppigot · February 15, 2010, 12:50am

Hi Richard,

Changes to JZKit are to be submitted to JZKit developers once we're confident they are ok so that should (once it takes place) cope with the first part of clause 13 - in the interim I'm happy to supply patches to anyone interested in developing etc - I suspect Timo is too? Also happy to use whatever naming scheme we can agree on to fully identify the jzkit jars.

Cheers,
Simon
________________________________________

This is now getting rather serious, and the most
significant consequence of using these new snapshots
is the change to the licensing.

(It would help if the filenames were not
merely jzkit...SNAPSHOT... but had
the JZKit SVN revision number in them.)

On 2010-01-20 the LICENSE.txt file of JZKit 3 was changed.
It was GPL; it is now AGPL. To incorporate
an AGPL-licensed library into GN (BlueNet
in this case, but presumably the trunk sometime
down the track) is a major
change, and may be a burden on users,
especially if they make local modifications.
Please see clause 13 of the licence.

Perhaps this turns out to be no big deal,
but it is not _obvious_ that it's not
a big deal. For instance, AGPL is a modified GPL,
not a modified LGPL.
I think we should be _very sure_ of the
consequences for everyone before
proceeding.

--
Richard Walker
Software Improvements Pty Ltd
Phone: +61 2 6273 2055
Fax: +61 2 6273 2082

------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW

_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net

GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

Clive_Boughton · February 15, 2010, 1:45am

Timo Proescholdt wrote:

But I think the AGPL issue is the more important thing here anyway.
AFAIK JZKit3 has been using this licenese since it was first released,

OK, I didn't notice that before.

I checked this before working with JZKit3 and I did not consider it an
issue, since it is all about code modification. If the AGPL code was
modified, this would be a different issue, but we only link to it.

Maybe. As I said, AGPL is a modified GPL, not
a modified LGPL. It looks to me as though AGPL
spreads its influence into the rest of
an application the way GPL does.
See clause 5.

[Also see e.g.,
http://mohammed.morsi.org/blog/node/270
(also not a legal opinion).]

For example: someone installs GN and then
customizes the layout by modifying one of the
JavaScript or XSLT files. Do they then
have to publish this modification just because
of JZKit 3's use of AGPL?

I would feel more comfortable if the JZKit
licence were LGPL with the Affero clause added.
In that case, it would be easy to argue that you
can make changes to unrelated parts of the system
and not have to publish your changes.

My reading is that you can still build (and sell) your own applications
of GN without them falling under AGPL.

I hope so. In fact I'm not worried about
being able to "sell" (either applications or
development services), I'm worried about the
inconvenience to "buyers" (users, whether
or not they paid any money) who make customizations
(either by themselves or with some help), and
are then forced to make the source code of the
changes available.

--
Richard Walker
Software Improvements Pty Ltd
Phone: +61 2 6273 2055
Fax: +61 2 6273 2082

Clive_Boughton · February 15, 2010, 4:00am

Timo Proescholdt wrote:

AFAIK JZKit3 has been using this licenese since it was first released,
as can be seen at e.g.
http://developer.k-int.com/svn/jzkit/jzkit3/tags/jzkit_3.0.0/jzkit_service/LICENSE.txt
so this is not a sudden change.

I think you mean to claim it was not
a "recent" change.

I've just checked. It seems this change was _both_
sudden and recent.

The tagged file you indicate was changed to AGPL
as part of SVN revision 255
on 2010-01-20, just like trunk/LICENSE.txt.

svn log -v shows:

------------------------------------------------------------------------
r255 | ibbo | 2010-01-20 22:14:56 +1100 (Wed, 20 Jan 2010) | 2 lines
Changed paths:
    M /jzkit3/tags/jzkit_3.0.0/jzkit_core/LICENSE.txt
    M /jzkit3/tags/jzkit_3.0.0/jzkit_service/LICENSE.txt
    M /jzkit3/trunk/LICENSE.txt
    M /jzkit3/trunk/jzkit_core/LICENSE.txt
    M /jzkit3/trunk/jzkit_service/LICENSE.txt

updated license

--
Richard Walker
Software Improvements Pty Ltd
Phone: +61 2 6273 2055
Fax: +61 2 6273 2082

Timo_Proescholdt · February 15, 2010, 5:42pm

Hi Richard,
hi all,

thanks again for paying attention.

IMHO the issue is how we can use the jzkit libs in geonetwork when they
are released under the AGPL.

According to section 13 of the AGPL, AGPL libs can be linked to GPL v3
code, without the AGPL propagating into the GPL v3 code. The AGPL
code remains AGPL and the GPL v3 remains GPL. So that should be ok.

===
Notwithstanding any other provision of this License, you have permission
to link or combine any covered work with a work licensed under version 3
of the GNU General Public License into a single combined work, and to
convey the resulting work. The terms of this License will continue to
apply to the part which is the covered work, but the work with which it
is combined will remain governed by version 3 of the GNU General Public
License.

AFAIK Geonetwork is GPL v2. Is GPL v2 compatible with GPL v3? Not in
general, but since in GN it says "“version 2 or later,”, we should be safe.
http://www.fsf.org/licensing/licenses/gpl-faq.html#v2v3Compatibility

I think this is the sticky point. If this provision holds we are ok,
otherwise we might have to think about making GN GPL v3 or using a non
AGPL jzkit version (see below).

Should we make any changes to JZKit we would try to incorporate them
into the trunk, or just make them public by uploading them to the GN
repository.

Where it gets problematic is if we took sourcecode from AGPL copylefted
JZKit, modified it and included it into the geonetwork source.

Concerning the XSLT or javascript modifications. AFAIK XSLT sheets and
javascript are technically not part of the code, as they are not linked
to the resulting software. (not in a "binary" with jzkit).
So the XSLT, javascript and config files should not be affected by a
possible propagation of the AGPL into the code.
http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL
(geonetwork would be the interpreter here).

If the AGPL still poses a problem, I also have a JZkit3 version on my
computer that is GPL, my patch is compatible to it, so we could just use
this, although I would prefer not to branch out.

IMHO and OT:
the AGPL is a good thing and pretty much in line with the idea of
open source. What the AGPL was made for (or against) is big companies
that run their businesses on modified GPL programmes without sharing
their modifications with the community.

what do you think?

best regards
Timo

Software Improvements gn-devel a écrit :

Timo Proescholdt wrote:

AFAIK JZKit3 has been using this licenese since it was first released,
as can be seen at e.g.
http://developer.k-int.com/svn/jzkit/jzkit3/tags/jzkit_3.0.0/jzkit_service/LICENSE.txt
so this is not a sudden change.

I think you mean to claim it was not
a "recent" change.

I've just checked. It seems this change was _both_
sudden and recent.

The tagged file you indicate was changed to AGPL
as part of SVN revision 255
on 2010-01-20, just like trunk/LICENSE.txt.

svn log -v shows:

------------------------------------------------------------------------
r255 | ibbo | 2010-01-20 22:14:56 +1100 (Wed, 20 Jan 2010) | 2 lines
Changed paths:
    M /jzkit3/tags/jzkit_3.0.0/jzkit_core/LICENSE.txt
    M /jzkit3/tags/jzkit_3.0.0/jzkit_service/LICENSE.txt
    M /jzkit3/trunk/LICENSE.txt
    M /jzkit3/trunk/jzkit_core/LICENSE.txt
    M /jzkit3/trunk/jzkit_service/LICENSE.txt

updated license