-
Notifications
You must be signed in to change notification settings - Fork 87
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
Changing the license of nwipe to GPLv3? #613
Comments
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.
The table above basically shows that for nwipe to be fully compatible with all the dynamically or statically (if any) I have not included smartmontools or hdparm as we don't dynamically or statically link to their code but only use the 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: |
Ok |
OK from me |
Ok |
ok |
Ok 👍 |
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. |
Ok |
If necessary, I would be willing to invest time and effort into replacing the existing code to address this issue. |
@PartialVolume, I cannot grant this request because I do not have any current rights, interest, or ownership in any of the pertinent assets.
@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. |
No objection on my end! |
👍 I'm ok with the license change |
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.
|
@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.
Thanks for originally writing such a great program. It's been fun working on it and adding new features to it over the years :-) |
@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. |
Fine by me |
Ok with me to either go GPL3 or to a "GPL2 or later." |
If it were purely my own preference I'd go GPLv2-or-later, but since GPLv3 is required to use libparted, 👍 from me. |
Ok! 👍 |
No objections from me to make nwipe GPLv3-only if that's the proposed change. |
Ok |
1 similar comment
Ok |
Is there still a repo or a commit somewhere with the initial state of the dwipe fork? |
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. |
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++. |
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.
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. |
Ahhhh okay, thanks for your explanation! Makes sense then. What about libparted and libconfig? How can we deal with that, if GPLv2+ or GPLv3 doesnt go through? |
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. |
Thank you! Makes sense for me now. |
OK :) |
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. |
One note -- make sure any commit for which you're relying on my authorization came from |
@charles-dyfis-net Will do. |
@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.
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.
|
@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 and also the following in Makefile.am +nwipe_CFLAGS = ${PARTED_CFLAGS} I'm starting the see why some people hate the headache caused by the incompatibility between v2 and v3 |
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. |
@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' |
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) |
If necessary, it is also possible to request legal support free of charge through FSF, and SFLC especially for licensing stuff of OSS. |
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). |
Question: if the change is made, when will it happen? Will it happen with next major release? |
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. |
regarding the code in hddtemp_scsi: My contribution is in get_scsi_temp.c, and it's ok for me to change the license to GPLv3. |
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. |
Wow. You the man. This is great news. |
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 |
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.
The text was updated successfully, but these errors were encountered: