Changing the license of nwipe to GPLv3?

[Knogle]

Ahoy, I hope you're doing well! :)

Nwipe is currently licensed under GPLv2 (GPLv2-only), but this license comes with some significant limitations. Is there maybe already a discussion about moving to GPLv3?

One of the main issues with GPLv2 is its incompatibility with certain other licenses (like MIT). This can create problems when trying to collaborate with projects that use GPLv3 or other licenses that have more modern requirements, such as software patents (First i wanted to implement Philox as my first contribution, but it's licensed under MIT, therefore incompatible with GPLv2). These incompatibilities could limit the project’s growth and make it harder to work with other open-source projects.

Switching to GPLv3 would solve many of these issues. GPLv3 offers better protection for users. It also includes stronger protections against patent-related problems and is more compatible with a wider range of open-source licenses. By moving to GPLv3, Nwipe would be more open to collaboration and could work with a broader community of projects.

In the long run, the switch to GPLv3 (or at least to GPLv2-or-later) could offer more flexibility, better protection for users, and increased compatibility with other projects.

[PartialVolume]

To move to GPLv3, which I also think is necessary, we would need to get the ok of most of the contributors if possible. (see below).

I've drawn up a table that shows the libraries that we dynamically or statically link to and their compatibility with the GPL licences.

Software	License	Compatability with GPL-2.0	Compatability with GPL-2.0+	Compatability with GPL3
ncurses	Similiar to MIT-X11	YES	YES	YES
libconfig	LGPL-2.1	YES	YES	YES
libparted	GPL-3.0	NO	NO	YES
openssl	Apache 2	NO	NO	YES
hddtemp	GPL2 (or later)	YES	YES	YES

The table above basically shows that for nwipe to be fully compatible with all the dynamically or statically (if any) libraries it uses we need to move to GPLv3 as the GPLv2.0 license is incompatible with a number of libraries we use and would like to use in the future.

I have not included smartmontools or hdparm as we don't dynamically or statically link to their code but only use the output data that those programs generate and we do not incorporate any of their code into the nwipe binary so I don't believe they are relevant to this discussion.

It would be appreciated if the following contributors could give their OK to the move from GPLv2.0 to GPLv3.0 by commenting below. Thanks. Apologies if I have missed anybody, feel free to comment.

Contributors: Darik Horn @dajhorn (authored original dwipe code before it was forked to become nwipe) @abeverley @martijnvanbrummelen @PartialVolume @ggruber
@DimitriPapadopoulos @Firminator @infrastation @louib @andreasheil @Legogizmo @vuntz @xambroz @charles-dyfis-net @Knogle @dmshaw @aytey @sporqist @nbassler @kelderek @Polynomial-C @Awire9966 @fthobe @NoNameForMee @FreeMinded @ndowens

[fthobe]

Ok

[DimitriPapadopoulos]

OK from me

[Knogle]

Ok

[NoNameForMee]

ok

[sporqist]

Ok 👍

[abeverley]

Ok from me, but I think Darik sold the original code to Blancco, so they might have to give permission which they would be unlikely to do?

[abeverley]

Ok from me, but I think Darik sold the original code to Blancco, so they might have to give permission which they would be unlikely to do?

Although given the incredible amount of development since I forked it, I'm not sure how much of original code remains :) Many thanks to all those who took over the project.

[FreeMinded]

Ok My contribution is probably the smallest possible 🤣

[Knogle]

Ok from me, but I think Darik sold the original code to Blancco, so they might have to give permission which they would be unlikely to do?

If necessary, I would be willing to invest time and effort into replacing the existing code to address this issue.

[dajhorn]

@PartialVolume, I cannot grant this request because I do not have any current rights, interest, or ownership in any of the pertinent assets.

If necessary, I would be willing to invest time and effort into replacing the existing code to address this issue.

@Knogle, you should do this. 100% rip-and-replace anything that has ambiguous status or could be encumbered.

Past that, after more than two decades, I am delighted to know that this product family is still a going concern.

[vuntz]

No objection on my end!

[louib]

:+1: I'm ok with the license change

[PartialVolume]

@abeverley

Ok from me, but I think Darik sold the original code to Blancco, so they might have to give permission which they would be unlikely to do?

I don't think their permission is required as you can't apply a restriction to GPL'ed code and from what I can tell they made no changes to dwipe which then ended up in nwipe.

Blanco released DBAN 2.2.7 on 11/Sep/2012 (the day after their acquisition). The code was GPLv2 and remains so under the terms of the GPL. Even in DBAN 2.2.7 the .C headers retained the GPLv2 notice as below and the source was distributed under that license.

Your initial commit on github was Sep 6th 2013, Blanco didn't make another release until 22/Nov/2013. Even looking at the dwipe code from DBAN's final release in 4/Jun/2015 all the dwipe C files still retain the GPLv2 headers, so I don't think it's an issue to worry about.

/*  vi: tabstop=3
 *
 *  dwipe.c:  Darik's Wipe.
 *
 *  Copyright Darik Horn <dajhorn-dban@vanadac.com>.
 *  
 *  This program is free software; you can redistribute it and/or modify it under
 *  the terms of the GNU General Public License as published by the Free Software
 *  Foundation, version 2.
 *
 *  This program is distributed in the hope that it will be useful, but WITHOUT
 *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
 *  FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more
 *  details.
 *
 *  You should have received a copy of the GNU General Public License along with
 *  this program; if not, write to the Free Software Foundation, Inc., 675 Mass
 *  Ave, Cambridge, MA 02139, USA.
 *
 */

[PartialVolume]

@PartialVolume, I cannot grant this request because I do not have any current rights, interest, or ownership in any of the pertinent assets.

@dajhorn Understood. Your code was licensed under GPLv2 and Blanco still released under GPLv2 as the source still retains the GPLv2 headers even in their very last release in 2015. From what I can tell there is no code in nwipe that was contributed from Blanco so I don't think it's a problem.

Past that, after more than two decades, I am delighted to know that this product family is still a going concern.

Thanks for originally writing such a great program. It's been fun working on it and adding new features to it over the years :-)

[PartialVolume]

If necessary, I would be willing to invest time and effort into replacing the existing code to address this issue.

@Knogle I don't believe that will be necessary as once code is GPL'ed nobody can restrict it's distribution, modification etc which is the whole point of the license. To be honest even if Blanco changed any code it's still GPL code, hence why the source was always released with DBAN right upto to 2015. Nwipe predates that by several years. So I wouldn't be concerned.

[aytey]

Fine by me

[dmshaw]

Ok with me to either go GPL3 or to a "GPL2 or later."

[charles-dyfis-net]

If it were purely my own preference I'd go GPLv2-or-later, but since GPLv3 is required to use libparted, :+1: from me.

[andreasheil]

Ok! 👍

[infrastation]

No objections from me to make nwipe GPLv3-only if that's the proposed change.

[kelderek]

Ok

[Polynomial-C]

Ok

[Knogle]

Is there still a repo or a commit somewhere with the initial state of the dwipe fork? Just out of interest.

[PartialVolume]

Yes. Go to DBAN on source forge. Download the latest source. It's in there. If you can't find it, I'll send you more details later.

[PartialVolume]

https://sourceforge.net/projects/dban/files/dban/dban-2.3.0/dban-2.3.0_src.tar.bz2/download

[Knogle]

Thanks a lot! After reviewing the code, I believe it would be possible to replace and rewrite those sections within a few days, or at most a few weeks, if necessary. Integrating the additional features would require a bit more effort. According to some legal interpretations, the original function declarations or APIs could remain unchanged, which would minimize any significant impact on the rest of the code.

You're right that, in theory, Darik could retroactively release his last pre-Blancco version under GPLv3. However, I wouldn't be surprised if he chooses not to make such a commitment. No one wants to risk even a theoretical chance of becoming a target for a larger company after selling the software. Honestly, if I were in Darik's shoes, I'd likely take the same approach.

On a separate note, I’m currently running a different branch where some core parts of Nwipe have been rewritten in C++.

[PartialVolume]

Thanks a lot! I reviewed the code and believe it would be feasible to replace and rewrite those sections within a few days, or at most a few weeks if necessary. Adapting the additional features would require some more work. According to some legal interpretations, the original function declarations or APIs could be retained, meaning it may not have significant effects on the rest of the code.

Why remove any of the code? The code was licensed under GPLv2 meaning you can do what you want with it as long as you publish the changes but what you can't do is restrict others use of it. I feel it would be a waste of time and potentially break things and require extensive testing to make sure it was stable.

Same goes for C++. I see little point in rewriting a program even parts of it when it works fine in C.

You're right that, in theory, Darik could retroactively release his last pre-Blancco version under GPLv3. However, I wouldn't be surprised if he chooses not to make such a commitment. No one wants to risk even a theoretical chance of becoming a target for a larger company after selling the software. Honestly, if I were in Darik's shoes, I'd likely take the same approach.

Darik has already stated he has no interest in this which may well be because of a contractual obligation. However, because he hasn't objected to GPLv3 for nwipe then that's ok. As long as Martijn is ok with GPLv3 I don't see a issue with changing the licence to GPLv3. I'm only really waiting for Martijn to approve the change or not. If he says no, you may have to fork nwipe and go in your own direction with it as we wouldn't be able to use Openssl. We would then need to write are own AES code under GPLv2.

Also you probably need to look at the dwipe code just before DBAN was acquired. Basically there were hardly any changes in the code between that version and the last version.

[Knogle]

Ahhhh okay, thanks for your explanation! I thought it mainly depends on Darik.

Makes sense then. When we are not able to switch to GPLv2, there is also GnuTLS as an option to replace OpenSSL, as it offers almost the same feature set.

What about libparted and libconfig? How can we deal with that, if GPLv2+ or GPLv3 doesnt go through?

[PartialVolume]

Ahhhh okay, thanks for your explanation! I thought it mainly depends on Darik.

We would have had an issue had Darik categorically said no, however we don't need Darik to say yes, just that he has no interest in dwipe or code forked from it under GPLv2.

Like you say even if Martijn objects to GPLv3 we could then maybe use GnuTLS, however because libconfig and libparted also require we move to GPLv3 I don't think Martijn would object. It solves all our license issues moving to GPLv3.

We'll wait for @martijnvanbrummelen 's response before we make this change. He's a busy man so we need to be patient, I've emailed him.

[Knogle]

Thank you! Makes sense for me now.

[nbassler]

OK :)

[PartialVolume]

Just a quick update re GPLv3. Martijn will be checking a few things with Debian and if ok we should hopefully move to GPLv3 from a specific commit I will do that updates the C file headers and any license files.

[charles-dyfis-net]

One note -- make sure any commit for which you're relying on my authorization came from charles@dyfis.net and not chaduffy@cisco.com -- if it's the latter, my former employer owns the copyright and I don't have authority to approve relicensing. (Moreover, that particular former employer doesn't like GPLv3 very much -- the paperwork to get authorization to use GPLv3-licensed components there was a right pain -- and I wouldn't be surprised if they would refuse if asked).

[PartialVolume]

@charles-dyfis-net Will do.

[PartialVolume]

@charles-dyfis-net This is your commit history back to 2014, 2 commits, 20 additions, 16 deletions. You added some missing libraries for libparted for static linking and changes (but no additional code) to nwipe.c and pass.c changing loff_t to off64_t both dated October 17th, 2015.

Adding the libraries for static linking in configure.ac and Makefile.am using a cisco address. Adding a library, is that really copyright-able? I wouldn't have thought so.

I'm no expert in copyright but I thought it would need to be a reasonable amount of new code added to be able to fall under copyright ownership and there isn't any new lines of code, only edits to existing lines.

From cf36858211df5c33133f397b23de6f1e9e96157d Mon Sep 17 00:00:00 2001
From: Charles Duffy <chaduffy@cisco.com>
Date: Wed, 14 Oct 2015 16:24:01 -0500
Subject: [PATCH] Add libintl, libuuid dependencies to allow parted static link
 (#12)

---
 configure.ac    | 4 +++-
 src/Makefile.am | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 375c7758..78f66242 100644
--- a/configure.ac
+++ b/configure.ac
@@ -42,7 +42,9 @@ PKG_CHECK_MODULES(
    )]
 )

-AC_CHECK_LIB([parted], [ped_device_probe_all], ,[AC_MSG_ERROR([parted development library not found])])
+AC_CHECK_LIB([intl], [libintl_dgettext]) # needed to statically link libparted, but not given in its pkgconfig file
+AC_CHECK_LIB([uuid], [uuid_generate])    # needed to statically link libparted, but not given in its pkgconfig file
+PKG_CHECK_MODULES([PARTED], [libparted])
 AC_CHECK_LIB([pthread], [main], ,[AC_MSG_ERROR([pthread development library not found])])

 # Checks for header files.
diff --git a/src/Makefile.am b/src/Makefile.am
index c1233721..f3062fa7 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -7,3 +7,5 @@ AM_LDFLAGS =
 # the previous manual Makefile
 bin_PROGRAMS = nwipe
 nwipe_SOURCES = context.h isaac_rand.c logging.h options.h prng.h nwipe.c gui.c isaac_rand.h method.h pass.c device.c gui.h isaac_standard.h mt19937ar-cok.c nwipe.h mt19937ar-cok.h pass.h device.h logging.c method.c options.c prng.c version.c version.h
+nwipe_CFLAGS = ${PARTED_CFLAGS}
+nwipe_LDADD = ${PARTED_LIBS}

The second commit, being changes to existing lines, loff_t to off64_t, in the code rather than adding any new code, I'm not sure that's a copyright issue either.

From 2f44978db430101baeb643db160c9a5190ef7fa8 Mon Sep 17 00:00:00 2001
From: Charles Duffy <chaduffy@cisco.com>
Date: Wed, 14 Oct 2015 16:26:30 -0500
Subject: [PATCH] Move from loff_t to off64_t for musl libc support (#11)

Using musl libc, the loff_t type is unavailable. This is only exported by the
kernel when building with GNU_SOURCE, so there's an argument to be made that
it's desired behavior; see http://www.openwall.com/lists/musl/2013/01/23/6 for
discussion on this point.
---
 src/context.h |  2 +-
 src/nwipe.c   |  4 ++--
 src/pass.c    | 24 ++++++++++++------------
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/src/context.h b/src/context.h
index ca13d0cb..fbb5b410 100644
--- a/src/context.h
+++ b/src/context.h
@@ -82,7 +82,7 @@ typedef struct nwipe_context_t_
    int               device_minor;  /* The minor device number.                                       */
    int               device_part;   /* The device partition or slice number.                          */
    char*             device_name;   /* The device file name.                                          */
-   loff_t            device_size;   /* The device size in bytes.                                      */
+   off64_t           device_size;   /* The device size in bytes.                                      */
    struct stat       device_stat;   /* The device file state from fstat().                            */
    nwipe_device_t    device_type;   /* Indicates an IDE, SCSI, or Compaq SMART device.                */
    int               device_target; /* The device target.                                             */
diff --git a/src/nwipe.c b/src/nwipe.c
index 8a84eb12..7423124f 100644
--- a/src/nwipe.c
+++ b/src/nwipe.c
@@ -354,7 +354,7 @@ int main( int argc, char** argv )
                 }

-                if( c2[i]->device_size == (loff_t)-1 )
+                if( c2[i]->device_size == (off64_t)-1 )
                 {
                         /* We cannot determine the size of this device. */
                         nwipe_perror( errno, __FUNCTION__, "lseek" );
@@ -367,7 +367,7 @@ int main( int argc, char** argv )
                         /* Reset the file pointer. */
                         r = lseek( c2[i]->device_fd, 0, SEEK_SET );

-                        if( r == (loff_t)-1 )
+                        if( r == (off64_t)-1 )
                         {
                                 nwipe_perror( errno, __FUNCTION__, "lseek" );
                                 nwipe_log( NWIPE_LOG_ERROR, "Unable to reset the '%s' file offset.", c2[i]->device_name );
diff --git a/src/pass.c b/src/pass.c
index 1cf5c749..3c6dfab3 100644
--- a/src/pass.c
+++ b/src/pass.c
@@ -46,7 +46,7 @@ int nwipe_random_verify( nwipe_context_t* c )
    size_t blocksize;

    /* The result buffer for calls to lseek. */
-   loff_t offset;
+   off64_t offset;

    /* The input buffer. */
    char* b;
@@ -98,7 +98,7 @@ int nwipe_random_verify( nwipe_context_t* c )
    /* Reset the pass byte counter. */
    c->pass_done = 0;

-   if( offset == (loff_t)-1 )
+   if( offset == (off64_t)-1 )
    {
        nwipe_perror( errno, __FUNCTION__, "lseek" );
        nwipe_log( NWIPE_LOG_FATAL, "Unable to reset the '%s' file offset.", c->device_name );
@@ -177,7 +177,7 @@ int nwipe_random_verify( nwipe_context_t* c )
            /* Bump the file pointer to the next block. */
            offset = lseek( c->device_fd, s, SEEK_CUR );

-           if( offset == (loff_t)-1 )
+           if( offset == (off64_t)-1 )
            {
                nwipe_perror( errno, __FUNCTION__, "lseek" );
                nwipe_log( NWIPE_LOG_ERROR, "Unable to bump the '%s' file offset after a partial read.", c->device_name );
@@ -225,7 +225,7 @@ int nwipe_random_pass( NWIPE_METHOD_SIGNATURE )
    size_t blocksize;

    /* The result buffer for calls to lseek. */
-   loff_t offset;
+   off64_t offset;

    /* The output buffer. */
    char* b;
@@ -267,7 +267,7 @@ int nwipe_random_pass( NWIPE_METHOD_SIGNATURE )
    /* Reset the pass byte counter. */
    c->pass_done = 0;

-   if( offset == (loff_t)-1 )
+   if( offset == (off64_t)-1 )
    {
        nwipe_perror( errno, __FUNCTION__, "lseek" );
        nwipe_log( NWIPE_LOG_FATAL, "Unable to reset the '%s' file offset.", c->device_name );
@@ -328,7 +328,7 @@ int nwipe_random_pass( NWIPE_METHOD_SIGNATURE )
            /* Bump the file pointer to the next block. */
            offset = lseek( c->device_fd, s, SEEK_CUR );

-           if( offset == (loff_t)-1 )
+           if( offset == (off64_t)-1 )
            {
                nwipe_perror( errno, __FUNCTION__, "lseek" );
                nwipe_log( NWIPE_LOG_ERROR, "Unable to bump the '%s' file offset after a partial write.", c->device_name );
@@ -388,7 +388,7 @@ int nwipe_static_verify( NWIPE_METHOD_SIGNATURE, nwipe_pattern_t* pattern )
    size_t blocksize;

    /* The result buffer for calls to lseek. */
-   loff_t offset;
+   off64_t offset;

    /* The input buffer. */
    char* b;
@@ -470,7 +470,7 @@ int nwipe_static_verify( NWIPE_METHOD_SIGNATURE, nwipe_pattern_t* pattern )
    /* Reset the pass byte counter. */
    c->pass_done = 0;

-   if( offset == (loff_t)-1 )
+   if( offset == (off64_t)-1 )
    {
        nwipe_perror( errno, __FUNCTION__, "lseek" );
        nwipe_log( NWIPE_LOG_FATAL, "Unable to reset the '%s' file offset.", c->device_name );
@@ -534,7 +534,7 @@ int nwipe_static_verify( NWIPE_METHOD_SIGNATURE, nwipe_pattern_t* pattern )
            /* Bump the file pointer to the next block. */
            offset = lseek( c->device_fd, s, SEEK_CUR );

-           if( offset == (loff_t)-1 )
+           if( offset == (off64_t)-1 )
            {
                nwipe_perror( errno, __FUNCTION__, "lseek" );
                nwipe_log( NWIPE_LOG_ERROR, "Unable to bump the '%s' file offset after a partial read.", c->device_name );
@@ -587,7 +587,7 @@ int nwipe_static_pass( NWIPE_METHOD_SIGNATURE, nwipe_pattern_t* pattern )
    size_t blocksize;

    /* The result buffer for calls to lseek. */
-   loff_t offset;
+   off64_t offset;

    /* The output buffer. */
    char* b;
@@ -638,7 +638,7 @@ int nwipe_static_pass( NWIPE_METHOD_SIGNATURE, nwipe_pattern_t* pattern )
    /* Reset the pass byte counter. */
    c->pass_done = 0;

-   if( offset == (loff_t)-1 )
+   if( offset == (off64_t)-1 )
    {
        nwipe_perror( errno, __FUNCTION__, "lseek" );
        nwipe_log( NWIPE_LOG_FATAL, "Unable to reset the '%s' file offset.", c->device_name );
@@ -697,7 +697,7 @@ int nwipe_static_pass( NWIPE_METHOD_SIGNATURE, nwipe_pattern_t* pattern )
            /* Bump the file pointer to the next block. */
            offset = lseek( c->device_fd, s, SEEK_CUR );

-           if( offset == (loff_t)-1 )
+           if( offset == (off64_t)-1 )
            {
                nwipe_perror( errno, __FUNCTION__, "lseek" );
                nwipe_log( NWIPE_LOG_ERROR, "Unable to bump the '%s' file offset after a partial write.", c->device_name );

[PartialVolume]

@charles-dyfis-net Maybe I need to rewrite the changes in nwipe.c and pass.c to something like

off64_t error = -1
if( offset == error )
{
..
..

Or maybe create an alias for the data type, removing the references to off64_t that you added.

I'm not sure about how I deal with the following in configure.ac +AC_CHECK_LIB([intl], [libintl_dgettext]) # needed to statically link libparted, but not given in its pkgconfig file +AC_CHECK_LIB([uuid], [uuid_generate]) # needed to statically link libparted, but not given in its pkgconfig file +PKG_CHECK_MODULES([PARTED], [libparted])

and also the following in Makefile.am

+nwipe_CFLAGS = ${PARTED_CFLAGS} +nwipe_LDADD = ${PARTED_LIBS}

I'm starting the see why some people hate the headache caused by the incompatibility between v2 and v3

[Knogle]

I've done some research on this.

The changes you've described in configure.ac and Makefile.am are relatively minor, especially as they are mostly adjustments for linking libraries and including compiler flags. These sorts of changes, especially if they are functional and not original creative work, typically don't meet the threshold for copyright protection in most jurisdiction. I'm also quite sure, the same applies for simply renaming a variable.

[PartialVolume]

@knogle that's reassuring to know.

I reviewed libconfig's license and in fact it is LGPL which is compatible with GPLv2 and V3. So really it's just libparted and Openssl that are currently the incompatible libraries.

Hopefully Martijn won't have any issues with Debian and we'll be able to move to GPLv3.

I don't see any downsides to switching to GPLv3 other than we can't link to GPLv2 only libraries but can link to libraries licensed as GPLv2 which include the 'or later version of GPL clause'

[charles-dyfis-net]

I agree that that those changes look to be de minimis, functional as opposed to expressive, and thus not worthy of copyright protection at all. (That said, I'm not a lawyer, nor do I play one on TV)

[Knogle]

If necessary, it is also possible to request legal support free of charge through FSF, and SFLC especially for licensing stuff of OSS.

[Firminator]

If it were purely my own preference I'd go GPLv2-or-later, but since GPLv3 is required to use libparted, 👍 from me.

Charles, I'd be interested in your reasons to prefer GPLv2-or-later over GPLv3. Would you care to elaborate?

[charles-dyfis-net]

If it were purely my own preference I'd go GPLv2-or-later, but since GPLv3 is required to use libparted, 👍 from me.

Charles, I'd be interested in your reasons to prefer GPLv2-or-later over GPLv3. Would you care to elaborate?

I'm not willing to get into a back-and-forth here, so this will be my only reply on the topic in-thread -- if you want to discuss further, email me.

To summarize, though: Reduced friction incorporating in commercial projects. As previously mentioned -- in a past life I've had an employer who deeply objected to the patent clause. (Witness, similarly, Apple staying on bash 3.x rather than moving to 4.x on account of the GPLv3 relicense there -- that's a change that made life worse for everyone; end users, community members fielding support requests from those users, etc).

[Awire9966]

Question: if the change is made, when will it happen? Will it happen with next major release?

[Firminator]

To summarize, though: Reduced friction incorporating in commercial projects. As previously mentioned -- in a past life I've had an employer who deeply objected to the patent clause. (Witness, similarly, Apple staying on bash 3.x rather than moving to 4.x on account of the GPLv3 relicense there -- that's a change that made life worse for everyone; end users, community members fielding support requests from those users, etc).

Charles, Thanks for the insight. Looks like a FSF and/or EFF consultation regarding the real-world ramifications moving forward with nwipe is the way to go unless it's crystal-clear to Martijn and/or PartialVolume which GPL they want to use.

[ggruber]

regarding the code in hddtemp_scsi: The core functionality came from Emmanuel VARAGNAT hddtemp@guzu.net as you can see in nwipe/src/hddtemp_scsi/scsi.c and 4 other files in this directory. This is licensed "GPL2 (or later)", so that should be no problem.

My contribution is in get_scsi_temp.c, and it's ok for me to change the license to GPLv3.

[PartialVolume]

Just to give you an update on the licensing change. After discussing with Martijn, I'm going to release v0.38 from the current master ASAP as this resolves a i386 issue for both Debian, Fedora and other distros and allows a little more time to look at any issues regarding the licence change. This means any pull requests involving Openssl will be commited into v0.39. In the meantime With the release of nwipe 0.38, I can update ShredOS with the latest buildroot and nwipe. Hopefully 0.39 shouldn't follow too far behind 0.38.

[Firminator]

Wow. You the man. This is great news.

[Awire9966]

Im fine with converting to GPL-3, I just need to know when it will take place as I plan to update my script to be GPL 3