Comment by seabass-labrax | Hacker News Reader

Comment by seabass-labrax | Hacker News Reader

Parent Full thread

I am not familiar with this project, but I am an expert in free and open source licensing, and in this context there are some irregularities.

molticrystal points out the commit in which the licence is 'changed'. Some files which were previously labelled as being dedicated to the public domain ('Unlicense') are now indicated as being under the Creative Commons Attribution-NonCommercial-NoDerivatives International License, version 4. This an is untrue statement at the specific commit, because work in the public domain cannot be copyrighted (this is a simplification, but substantively true). However, it will become a true statement and thus legally significant as and when new, original code is added in future commits, as this would be copyrightable.

More importantly, there are other files which previously contained this declaration:

  // SPDX-License-Identifier: (GPL-3.0 OR CC-BY-NC-ND-4.0)

This, expressed in the ISO standard SPDX syntax, means that the copyright holder(s) allow copying under the terms of either the GNU General Public License version 3 or the aforementioned Creative Commons licence.

Contributors to the project generally continue to hold copyright to their commits under the 'inbound-outbound' doctrine, and this is reinforced by the GitHub terms of service. That means that the main author has to respect the licence terms too.

Here's the problem: by changing the licence of the whole program to only the Creative Commons BY-NC-ND, they have to have violated one of the two original options. If they use their rights from the GPL, they must retain the GPL option for others (copyleft principle); if they use their rights from the CC-BY-NC-ND-4.0 licence, they cannot make derivative works so won't be allowed to continue developing the project!

All in all, this is just yet another case of 're-licensing' a formerly free and open source project that has no grounds in law. More positively, it is also therefore another case of the inbound-outbound effect of collaborative development strengthening FOSS.

It doesn’t even properly address the original problem. Originally, this was stated to be in response to people “stealing” the source code, making low quality Android ports (without releasing source code), and users coming to the official channels to complain about problems unique to the Android versions. A license change does not in any way stop that, instead it only alienates those who wish to support development and yet now are seemingly disallowed from even contributing due to the weird licensing.

> If they use their rights from the GPL, they must retain the GPL option for others (copyleft principle); if they use their rights from the CC-BY-NC-ND-4.0 licence, they cannot make derivative works so won't be allowed to continue developing the project!

If they own the copyright to all of the code that was published, then they can use that right to relicense the code however they like without violating either of the licenses. That would, however, presume that they either did not accept contributions from anyone else prior to the change, had contributions assign them copyright, or removed code by those contributors.

And, of course, changing the license on new code doesn’t revoke the rights granted to people by the previous licenses if they had the code already.

What confused me was that the project is still using the Qt framework. Is that compatible with the new license?

Yes, Qt is LGPL except for a few plugins that are GPL.

The LGPL requires that you're able to debug, modify, and replace the library in question, in this case, Qt.

> You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications.

However, DuckStation supplies prebuilt bundles that don't allow for that, in the case of Windows.

Should open source contributors start including license terms with every commit? Or at least an SPDX identifier.

As long as the license pre-exists the change, then the changes will be included beneath that license. As law depends on intent, rather than anything strictly automatic. A "best effort" is fine.

The bigger problem is that re-licensing is... Hellfire. You require specific permission from all involved, every single person who agreed to previous terms. If a single person does not grant permission, you either cannot transition, or must strip out everything of their work - and anything their work may have further led to. They can't be the inspiration for anything.

You also cannot relicense something once you've placed it in the public domain (99.99999% of the time).

So... Begin your history with one license, you're fine.

Try and change it... Hire a lawyer first.

Right, but the license attached to a file doesn't make it clear whose diffs are whose. You don't think it would be a reasonable defensive measure to include a license so it's obvious who committed which changes on exactly which date? (Barring someone rewriting commit history, which they could do with licenses in code comments too.)

Reply on news.ycombinator.com