Bug 733038
Summary: | RPM spec license not consistent with source code license | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Daniel Berrangé <berrange> | |
Component: | sanlock | Assignee: | David Teigland <teigland> | |
Status: | CLOSED DUPLICATE | QA Contact: | ||
Severity: | low | Docs Contact: | ||
Priority: | high | |||
Version: | 6.0 | CC: | ajia | |
Target Milestone: | rc | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | sanlock-1.8-1.el6 | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 739518 (view as bug list) | Environment: | ||
Last Closed: | 2011-09-19 15:27:27 UTC | Type: | --- | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 739518 |
Description
Daniel Berrangé
2011-08-24 14:55:25 UTC
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 *** |