Hide Forgot
Description of problem: The sanlock RPM says it is GPLv2+ licensed (ie, or later) # rpm -q --qf '%{LICENSE}\n' sanlock GPLv2+ The source code files disagree eg, src/main.c: /* * Copyright (C) 2010-2011 Red Hat, Inc. All rights reserved. * * This copyrighted material is made available to anyone wishing to use, * modify, copy, or redistribute it subject to the terms and conditions * of the GNU General Public License v.2. */ Note the absence of any 'or later' clause there. I expect this is a mistake in the per-source file license headers, but since per-source file license headers take precedence over RPM package license tag, sanlock is effectively GPLv2-only at this time. This is a significant problem, because sanlock gets used by libvirt, which can only use libraries compatible with "GPLv2 or later", since it must have GPLv3 compatibility. Version-Release number of selected component (if applicable): sanlock-1.7-4.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. Look at the source file license headers in the sanlock tar.gz archive 2. Look at the RPM specfile License 3. Actual results: RPM and source files disagree Expected results: RPM and source files agree on license Additional info:
NB, some source files even lack a license header entirely, ie monotime.c, sanlock_sock.c task.c. All source files should have an unambiguous license header present.
I hate the gplv3 nightmare, and would like to keep as far from it as possible. libvirt only uses libsanlock, right? So if I was going to leave the bulk of the source as gplv2-only, what source files would need to become lgplv2+ in order for libvirt to be ok?
Currently we link to /usr/lib64/libsanlock.so and use the following header files /usr/include/sanlock.h /usr/include/sanlock_admin.h /usr/include/sanlock_direct.h /usr/include/sanlock_resource.h /usr/include/sanlock_rv.h So any source file that is linked into libsanlock.so We might also like to use the libwdmd library in the future, but that's TBD.
Unfortunately libsanlock.so includes probably half of the source. I'll look into cutting it back. The client code for sending requests to the daemon should be fairly simple, but the code for sanlock_direct_init() looks like it will be more difficult. Does libvirt use sanlock_direct_init(), or could you use the cli "sanlock direct init ..."? It's likely that I'd end up splitting the client code out of libsanlock into libsanlock_client, with libsanlock being gpl and libsanlock_cilent lgpl+.
I see, you're probably just using sanlock_direct_align(), not sanlock_direct_init(). That would not be difficult to put in the lgplv2+ lib.
No, we use direct_init too $ grep sanlock_ src/locking/lock_driver_sanlock.c #include <sanlock_resource.h> #include <sanlock_direct.h> #include <sanlock_admin.h> if ((rv = sanlock_direct_align(&ls.host_id_disk)) < 0) { if ((rv = sanlock_direct_init(&ls, NULL, 0, 0, 0)) < 0) { if ((rv = sanlock_add_lockspace(&ls, 0)) < 0) { if ((rv = sanlock_direct_align(&res->disks[0])) < 0) { if ((rv = sanlock_direct_init(NULL, res, 0, 0, 0)) < 0) { if ((rv = sanlock_state_to_args((char *)state, (sock = sanlock_register()) < 0) { if ((rv = sanlock_acquire(sock, priv->vm_pid, 0, if ((rv = sanlock_restrict(sock, SANLK_RESTRICT_ALL)) < 0) { if ((rv = sanlock_inquire(-1, priv->vm_pid, 0, &res_count, state)) < 0) { if ((rv = sanlock_release(-1, priv->vm_pid, SANLK_REL_ALL, 0, NULL)) < 0) { if ((rv = sanlock_inquire(-1, priv->vm_pid, 0, &res_count, state)) < 0) {
It looks like sanlock_direct_init() will need to remain GPLv2. Not only would it be a big pain to refactor that code, but it includes GPLv2 code copied from the kernel. Other options include: 1. tell the user to run the cli command 2. fork the cli command 3. ask the sanlock daemon to do the init (would require the daemon to be running) I'd have to add a new sanlock_client_init(). (did I mention how much I hate gplv3?)
I guess the kernel crc32 code used by init does include the "or later", so it's probably possible from a license POV, but it's still looking like a big pain to refactor.
Dan, I've pushed a bunch of changes to sanlock.git, would these work for you? I've added libsanlock_client.so which includes the new sanlock_align() and sanlock_init() apis that you should be able to use in place of direct_align() and direct_init(). The new calls ask the sanlock daemon do the disk operations rather than doing the disk io directly. I've moved a bunch of code around and changed the license to LGPLv2+ on the .c and .h files used in libsanlock_client, and the headers you need to include.
That sounds reasonable. I'll take a closer look & adjust libvirt to use the newer APIs
see sanlock/README.license for which files/libs are which license *** This bug has been marked as a duplicate of bug 658971 ***