Bug 733038

Summary: RPM spec license not consistent with source code license
Product: Red Hat Enterprise Linux 6 Reporter: Daniel Berrangé <berrange>
Component: sanlockAssignee: David Teigland <teigland>
Status: CLOSED DUPLICATE QA Contact:
Severity: low Docs Contact:
Priority: high    
Version: 6.0CC: 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
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:

Comment 1 Daniel Berrangé 2011-08-24 14:56:48 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.

Comment 5 David Teigland 2011-08-24 15:52:52 UTC
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?

Comment 6 Daniel Berrangé 2011-08-24 16:00:39 UTC
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.

Comment 7 David Teigland 2011-08-24 22:26:04 UTC
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+.

Comment 8 David Teigland 2011-08-24 22:33:11 UTC
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.

Comment 9 Daniel Berrangé 2011-08-25 09:38:22 UTC
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) {

Comment 10 David Teigland 2011-08-25 22:39:24 UTC
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?)

Comment 11 David Teigland 2011-08-25 22:52:31 UTC
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.

Comment 12 David Teigland 2011-08-26 22:47:39 UTC
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.

Comment 13 Daniel Berrangé 2011-08-30 09:54:05 UTC
That sounds reasonable. I'll take a closer look & adjust libvirt to use the newer APIs

Comment 15 David Teigland 2011-09-19 15:27:27 UTC
see sanlock/README.license for which files/libs are which license

*** This bug has been marked as a duplicate of bug 658971 ***