Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

old BSD license #1

Open
onlyjob opened this issue Aug 10, 2015 · 6 comments
Open

old BSD license #1

onlyjob opened this issue Aug 10, 2015 · 6 comments

Comments

@onlyjob
Copy link

onlyjob commented Aug 10, 2015

Files src/crypt_client.c and ntirpc/rpcsvc/crypt.x are licensed under "BSD-4-clause" (old BSD) license. Unfortunately this GPL-incompatible license is universally deprecated.
It is not recognised as DFSG-compatible license hence this file can not be included to Debian etc.

See more

Please consider removing those files or re-license 'em under "new" BSD (aka BSD-3-clause) license if copyright holder agrees with that:

Bill Paul <wpaul@ctr.columbia.edu>
@onlyjob
Copy link
Author

onlyjob commented Aug 10, 2015

Same applies to ntirpc/misc/socket.h except that its copyright is ambiguous...

@onlyjob
Copy link
Author

onlyjob commented Aug 10, 2015

And to ntirpc/spinlock.h copyrighted 1998 John Birrell <jb@cimlogic.com.au>...

mattbenjamin pushed a commit that referenced this issue Sep 2, 2015
Coverity CID 130080 (#1 of 1): Missing unlock (LOCK)

Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>
mattbenjamin pushed a commit that referenced this issue Sep 2, 2015
Coverity CID 130080 (#1 of 1): Missing unlock (LOCK)

Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>
@mattbenjamin
Copy link
Contributor

the files referenced here have been removed or replaced in upstream ntirpc/duplex-12

@was4
Copy link
Contributor

was4 commented Oct 10, 2015

I've force pushed duplex-12 from upstream to here. Hopefully that will resolve the license issues.

@mattbenjamin
Copy link
Contributor

ok

Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

----- Original Message -----

From: "was4" notifications@github.com
To: "linuxbox2/ntirpc" ntirpc@noreply.github.com
Cc: "Matt Benjamin" mbenjamin@redhat.com
Sent: Friday, October 9, 2015 10:32:47 PM
Subject: Re: [ntirpc] old BSD license (#1)

I've force pushed duplex-12 from upstream to here. Hopefully that will
resolve the license issues.


Reply to this email directly or view it on GitHub:
#1 (comment)

@onlyjob
Copy link
Author

onlyjob commented Oct 13, 2015

Would it be possible to prepare a release for "duplex-12" please?
I'm not sure which branch is authoritative... I'll review licenses once new release of ntirpc becomes available...

Also it would be nice to document differences from "tirpc" somewhere...

By the way where is "upstream" for "duplex-12"? Where "duplex-12" was taken from?

madhuthorat added a commit to madhuthorat/ntirpc that referenced this issue Mar 11, 2019
Fixed the following valgrind report by initializing
'buffer' to 0 in 'svc_dg_reply':
==2615== Syscall param sendmsg(msg.msg_control) points to uninitialised byte(s)
==2615==    at 0x6651C6D: ??? (in /usr/lib64/libpthread-2.17.so)
==2615==    by 0x6A8A9E1: svc_dg_reply (svc_dg.c:465)
==2615==    by 0x6A88748: svc_sendreply (svc.c:549)
==2615==    by 0x44CDF2: nfs_rpc_execute (nfs_worker_thread.c:1344)
==2615==    by 0x44D447: worker_run (nfs_worker_thread.c:1562)
==2615==    by 0x50C4FF: fridgethr_start_routine (fridgethr.c:550)
==2615==    by 0x664AE24: start_thread (in /usr/lib64/libpthread-2.17.so)
==2615==    by 0x6FC434C: clone (in /usr/lib64/libc-2.17.so)
==2615==  Address 0x1360ce08 is on thread 17's stack
==2615==  in frame linuxbox2#1, created by svc_dg_reply (svc_dg.c:407)

Signed-off-by: Madhu Thorat <madhu.punjabi@in.ibm.com>
malahal pushed a commit to malahal/ntirpc that referenced this issue Mar 11, 2019
Fixed the following valgrind report by initializing
'buffer' to 0 in 'svc_dg_reply':
==2615== Syscall param sendmsg(msg.msg_control) points to uninitialised byte(s)
==2615==    at 0x6651C6D: ??? (in /usr/lib64/libpthread-2.17.so)
==2615==    by 0x6A8A9E1: svc_dg_reply (svc_dg.c:465)
==2615==    by 0x6A88748: svc_sendreply (svc.c:549)
==2615==    by 0x44CDF2: nfs_rpc_execute (nfs_worker_thread.c:1344)
==2615==    by 0x44D447: worker_run (nfs_worker_thread.c:1562)
==2615==    by 0x50C4FF: fridgethr_start_routine (fridgethr.c:550)
==2615==    by 0x664AE24: start_thread (in /usr/lib64/libpthread-2.17.so)
==2615==    by 0x6FC434C: clone (in /usr/lib64/libc-2.17.so)
==2615==  Address 0x1360ce08 is on thread 17's stack
==2615==  in frame linuxbox2#1, created by svc_dg_reply (svc_dg.c:407)

Signed-off-by: Madhu Thorat <madhu.punjabi@in.ibm.com>
(cherry picked from commit 52b1b5a)
madhuthorat added a commit to madhuthorat/ntirpc that referenced this issue Sep 16, 2019
Fixed the following valgrind report by initializing
'buffer' to 0 in 'svc_dg_reply':
==2615== Syscall param sendmsg(msg.msg_control) points to uninitialised byte(s)
==2615==    at 0x6651C6D: ??? (in /usr/lib64/libpthread-2.17.so)
==2615==    by 0x6A8A9E1: svc_dg_reply (svc_dg.c:465)
==2615==    by 0x6A88748: svc_sendreply (svc.c:549)
==2615==    by 0x44CDF2: nfs_rpc_execute (nfs_worker_thread.c:1344)
==2615==    by 0x44D447: worker_run (nfs_worker_thread.c:1562)
==2615==    by 0x50C4FF: fridgethr_start_routine (fridgethr.c:550)
==2615==    by 0x664AE24: start_thread (in /usr/lib64/libpthread-2.17.so)
==2615==    by 0x6FC434C: clone (in /usr/lib64/libc-2.17.so)
==2615==  Address 0x1360ce08 is on thread 17's stack
==2615==  in frame linuxbox2#1, created by svc_dg_reply (svc_dg.c:407)

Signed-off-by: Madhu Thorat <madhu.punjabi@in.ibm.com>
(cherry picked from commit 52b1b5a)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants