💬 Discussion | Copyleft police! come out with your licenses up in the air! :-) #884

Closed
opened 2019-04-25 06:28:56 +00:00 by five-c-d · 18 comments
five-c-d commented 2019-04-25 06:28:56 +00:00 (Migrated from github.com)

There was a discussion about an old pull-request that failed to get merged: the code in question was written in Dec'17 when the privacyToolsIO website was saying the website-contents were CC-BY-SA-4.0, and the github repo against which the pull-request was made was saying the repo-contents were GPLv3.

The pull-request from @angela-d was about to be merged in Nov'18, but a problem was discovered by an anonymous person: the license for the pull-request was GPLv3 (as it should have been), but in between the authoring of the pull-request and the attempt to merge the pull-request, the entire website-license and repo-license had both been changed to WTFPL.

My understanding is that the 2018-04-05 commit was incorrect, because unless I'm missing something, there is no clickwrap on the pull-requests to a contributor-licensing-agreement or something of that nature. Each contributor to the website, between 2015-08-10 all the way through 2018-04-04, was contributing code (HTML+CSS markup specifically... not programmatic code... but copyright law does not make a distinction) under the GPLv3 terms. However, each contributor retained copyright-ownership of the material they submitted, unless I'm mistaken.

Thus, even though @BurungHantu1605 is the founder and project-leader, because they were not the sole contributor of material, and because there was no copyright-assignment nor clickwrap implying a contributor-licensing-agreement, then I don't think the strong copyleft nature of GPLv3 (and for that matter the strong copyleft nature of CC-BY-SA-4.0 as well) actually permit changing the license to WTFPL. This is not because the change is a bad idea, and not because the change cannot be properly accomplished -- it is because, specifically, the exact terms of the GPLv3 license-text say explicitly that any derivative work must remain under the same license, unless the copyright-holder(s) agree jointly to re-license the combined work.

In the case of the HTML+CSS of privacyToolsIO repo as of 2015-08-10 the copyright-owner was one single person, the human known on github as Burung Hantu. There were a lot of other contributors later though: each of them received the existing code under the GPLv3, made some changes to form a derivative work also under GPLv3, and then pull-requested the changes back into the main repo, where the new combined work (original + changed stuff) was GPLv3 also... but with multiple copyright-holders now because multiple people contributed.

Basically, as soon as ANYBODY used a github pull-request to suggest a change, and the change was merged, that made a relicense impossible without first getting signoff (in the legally-binding sense of "signing away copyright control or at least signing off on the re-license as something EACH copyright-holder agreed unto"). See the gory details here https://www.gnu.org/licenses/license-compatibility.html#combining and further up that same page. https://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyleft explains the idea of 'virality' reasonably well: once code is strong-copyleft, nobody can re-license it as permissive, unless they have signoff from all contributors to the combined work.

There is some wiggle-room here, depending on who you talk to. RMS would almost certainly think there is no wiggle-room, see link above: once GPLv3 always GPLv3, unless you get explicit signoff from every contributor to the combined work that provided GPLv3-licensed code to the effort. ESR however might not be so adamant... because, at least in 2002, he was pretty strongly of the opinion that the legal difference between a collective work and a joint authorship, plus some unpublished court-cases, give the project-owner that has done most of the writing an implied power to alter the overall project license, of some kind. Even ESR is pretty clear about going from permissive-to-strong-copyleft or going from strong-copyleft-to-permissive being a risky move, however. http://www.catb.org/~esr/Licensing-HOWTO.html#changing

p.s. I have some recommendations about how to move forwards (could involve reverting the license-change or could involve seeking sign-off or could involve deciding to risk the stance of 'collective work' and then documenting exactly those things with a pull-request template that includes clickwrap agreeing to the collective-work rubric). But I figured I better check whether anybody cares about this stuff first :-) It is a complex subject. @Shifterovich you were also commenting over in issue 418, so I ping you as well

<!-- Remember to stay civil! --> There was <a href="https://github.com/privacytoolsIO/privacytools.io/issues/856#issuecomment-485334311">a discussion</a> about an old pull-request that failed to get merged: the code in question was written in Dec'17 when the privacyToolsIO website was saying the website-contents were CC-BY-SA-4.0, and the github repo against which the pull-request was made was saying the repo-contents were GPLv3. The pull-request from @angela-d was about to be merged in Nov'18, but a problem was discovered by an anonymous person: the license for the pull-request was GPLv3 (as it should have been), but in between the authoring of the pull-request and the attempt to merge the pull-request, the entire website-license and repo-license had both been changed to WTFPL. * https://github.com/privacytoolsIO/privacytools.io/commits/master/LICENSE.txt * GNU GPL v3.0 . BurungHantu1605 committed on Aug 10, 2015 * #418 [wtfpl]. Burung Hantu committed on Apr 5, 2018 My understanding is that the 2018-04-05 commit was incorrect, because unless I'm missing something, there is no clickwrap on the pull-requests to a contributor-licensing-agreement or something of that nature. Each contributor to the website, between 2015-08-10 all the way through 2018-04-04, was contributing code (HTML+CSS markup specifically... not programmatic code... but copyright law does not make a distinction) under the GPLv3 terms. However, each contributor retained copyright-ownership of the material they submitted, unless I'm mistaken. Thus, even though @BurungHantu1605 is the founder and project-leader, because they were not the **sole** contributor of material, and because there was no copyright-assignment nor clickwrap implying a contributor-licensing-agreement, then I don't think the strong copyleft nature of GPLv3 (and for that matter the strong copyleft nature of CC-BY-SA-4.0 as well) actually *permit* changing the license to WTFPL. This is not because the change is a bad idea, and not because the change cannot be properly accomplished -- it is because, specifically, the exact terms of the GPLv3 license-text say explicitly that any derivative work must remain under the same license, unless the copyright-holder(**s**) agree jointly to re-license the combined work. In the case of the HTML+CSS of privacyToolsIO repo as of 2015-08-10 the copyright-owner was one single person, the human known on github as Burung Hantu. There were a lot of other contributors later though: each of them received the existing code under the GPLv3, made some changes to form a derivative work also under GPLv3, and then pull-requested the changes back into the main repo, where the new combined work (original + changed stuff) was GPLv3 also... *but with multiple copyright-holders* now because multiple people contributed. Basically, as soon as ANYBODY used a github pull-request to suggest a change, and the change was merged, that made a relicense impossible without first getting signoff (in the legally-binding sense of "signing away copyright control or at least signing off on the re-license as something EACH copyright-holder agreed unto"). See the gory details here https://www.gnu.org/licenses/license-compatibility.html#combining and further up that same page. https://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyleft explains the idea of 'virality' reasonably well: once code is strong-copyleft, nobody can re-license it as permissive, unless they have signoff from *all contributors* to the combined work. There is some wiggle-room here, depending on who you talk to. RMS would almost certainly think there is no wiggle-room, see link above: once GPLv3 always GPLv3, unless you get explicit signoff from every contributor to the combined work that provided GPLv3-licensed code to the effort. ESR however might not be so adamant... because, at least in 2002, he was pretty strongly of the opinion that the legal difference between a collective work and a joint authorship, plus some unpublished court-cases, give the project-owner that has done most of the writing an implied power to alter the overall project license, of some kind. Even ESR is pretty clear about going from permissive-to-strong-copyleft or going from strong-copyleft-to-permissive being a risky move, however. http://www.catb.org/~esr/Licensing-HOWTO.html#changing p.s. I have some recommendations about how to move forwards (could involve reverting the license-change or could involve seeking sign-off or could involve deciding to risk the stance of 'collective work' and then documenting exactly those things with a pull-request template that includes clickwrap agreeing to the collective-work rubric). But I figured I better check whether anybody cares about this stuff first :-) It is a complex subject. @Shifterovich you were also commenting over in issue 418, so I ping you as well
abbluiz commented 2019-04-25 07:22:00 +00:00 (Migrated from github.com)

It seems like a complicated matter. If it is resolved, maybe consider changing it to CC0? It's basically public domain and (way) more specific/informative than WTFPL, compatible with GPLv3

https://www.gnu.org/licenses/license-list.html
https://directory.fsf.org/wiki/License:CC0

It seems like a complicated matter. If it is resolved, maybe consider changing it to CC0? It's basically public domain and (way) more specific/informative than WTFPL, compatible with GPLv3 https://www.gnu.org/licenses/license-list.html https://directory.fsf.org/wiki/License:CC0
five-c-d commented 2019-04-25 07:48:52 +00:00 (Migrated from github.com)

Yes, that is going to be my suggestion, if the intent is to have maximum ability to survive all the weird copyright jurisdictions around the world. (Or dual-licensed WTFPLv2 + CC0 maybe... both of them are GPL-compatible and CC-BY-SA-compatible in the upmerge-direction.)

But first I'd like to get the can-the-project-lead-re-license-from-copyleft-to-uber-permissive unilaterally thing worked out... I think we need signoffs, or maybe there was clickwrap I don't know about in the pull-request templates prior to 2018?

Yes, that is going to be my suggestion, if the intent is to have maximum ability to survive all the weird copyright jurisdictions around the world. (Or dual-licensed WTFPLv2 + CC0 maybe... both of them are GPL-compatible and CC-BY-SA-compatible in the upmerge-direction.) But first I'd like to get the can-the-project-lead-re-license-from-copyleft-to-uber-permissive unilaterally thing worked out... I think we need signoffs, or maybe there was clickwrap I don't know about in the pull-request templates prior to 2018?
abbluiz commented 2019-04-25 07:57:46 +00:00 (Migrated from github.com)

Section 6 of this website made it somewhat clear for me

https://opensource.guide/legal/

Section 6 of this website made it somewhat clear for me https://opensource.guide/legal/
angela-d commented 2019-04-25 22:17:56 +00:00 (Migrated from github.com)

This is a goofy complaint.

As the one whose commit caused this nonsense, I have stated on record that I would not care if somebody re-submitted my "work."

Stallman is an awesome guy and I agree with most of his views, but there is a grey area (imo) for situations like this.

  • The goal of this project (on the surface, at least) is to inform users
  • Nobody (that we know of) profits from any "work" done on PTIO - can you revoke the exchange of ideas?

It was a chart of information and some tiny bits of HTML that my commit had. There was no original work to copyright.

This is a goofy complaint. As the one whose commit caused this nonsense, I have stated on record that I would not care if somebody re-submitted my "work." Stallman is an awesome guy and I agree with most of his views, but there *is* a grey area (imo) for situations like this. - The goal of this project (on the surface, at least) is to inform users - Nobody (that we *know of*) profits from any "work" done on PTIO - can you revoke the exchange of ideas? It was a chart of **information** and some tiny bits of HTML that my commit had. There was no *original* work to copyright.
privacytoolsIO commented 2019-04-25 23:50:36 +00:00 (Migrated from github.com)

Who cares, @five-c-d? Do what the fuck you want. I can't believe you've spent so much time for this nonsense.

Who cares, @five-c-d? Do what the fuck you want. I can't believe you've spent so much time for this nonsense.
five-c-d commented 2019-04-25 23:57:07 +00:00 (Migrated from github.com)

It is a risk to the website itself, in the longer term. Anybody that contributed from August 2015 through March 2018, was contributing under GPLv3, which is a copyleft license. Github terms of use are that the contributor (not the project leader) owns the copyright. DMCA takedown of a derivative work is not outside the range of possibility.

That's why. It is nonsense, like most lawyer-stuff. But it is risky to ignore it when the end result could be dire for the project as a whole. It's your project, if you think the risk is zero, go ahead and close. Wikipedia had to relicense, Mozilla Foundation had to relicense, these have to be done with care, or bad things can happen. I'm not trying to complain pointlessly; since I never contributed in the past (I only learned of the site after it was nominally WTFPL already), I'm not a potential DMCA threat. But I see it as a non-zero worry

It is a risk to the website itself, in the longer term. Anybody that contributed from August 2015 through March 2018, was contributing under GPLv3, which is a copyleft license. Github terms of use are that the contributor (not the project leader) owns the copyright. DMCA takedown of a derivative work is not outside the range of possibility. That's why. It **is** nonsense, like most lawyer-stuff. But it is risky to ignore it when the end result could be dire for the project as a whole. It's your project, if you think the risk is zero, go ahead and close. Wikipedia had to relicense, Mozilla Foundation had to relicense, these have to be done with care, or bad things can happen. I'm not trying to complain pointlessly; since I never contributed in the past (I only learned of the site after it was nominally WTFPL already), I'm not a potential DMCA threat. But I see it as a non-zero worry
angela-d commented 2019-04-26 00:06:58 +00:00 (Migrated from github.com)

It is not. Did you contribute under another name? If not, why does it matter?

What's your angle? Are you trying to drum up scene points and get on the team so you can sneak in malware suggestions or something?
These anonymous users that pop out of nowhere with this "esteemed" info and trying to change major things about PTIO are really weird.

Wikipedia had to relicense, Mozilla Foundation had to relicense

Do you see a scale of difference? PTIO is suggestions of tools. No original work. An argument could be made for Wikipedia as the same, but its not; it sells itself as an encyclopedia. I don't think PTIO are in the same league at all and that's not a hit on PTIO.

I'm not a potential DMCA threat.

You and another anonymous user are the only people I've seen bring this up since I've been lurking PTIO, I first came across this site in 2017. That's a lot of posts that have gone by without a single mention, until you two came about.

What are you guys up to?

It is not. Did you contribute under another name? If not, why does it matter? What's your angle? Are you trying to drum up scene points and get on the team so you can sneak in malware suggestions or something? These anonymous users that pop out of nowhere with this "esteemed" info and trying to change major things about PTIO are really weird. > Wikipedia had to relicense, Mozilla Foundation had to relicense Do you see a scale of difference? PTIO is suggestions of tools. No original work. An argument could be made for Wikipedia as the same, but its not; it sells itself as an encyclopedia. I don't think PTIO are in the same league at all and that's not a hit on PTIO. > I'm not a potential DMCA threat. You and another anonymous user are the *only* people I've seen bring this up since I've been lurking PTIO, I first came across this site in 2017. That's a lot of posts that have gone by without a single mention, until you two came about. What are you guys up to?
five-c-d commented 2019-04-26 00:23:09 +00:00 (Migrated from github.com)

This is not about you Angela, your commit was rejected because of a license-incompatibility (I'm still presuming that is the case). GPL'd material cannot be merged into a permissively-licensed project. Any programmer knows this, who understands copyleft. This is about everybody who had a commit that was merged, and thus, is a copyright-holder of a portion of the current version of the website which is a derivative work (in part) of their GPL'd contribution, made sometime prior to the relicensing of the combined work: https://github.com/privacytoolsIO/privacytools.io/commits?after=00339a051a40b001668a30f2dcbfdbd7b94665a8+483 all the way back to August 2015 when the GPL license was selected.

Any of them can "in theory" file a copyright complaint with github -- but more importantly, with the webhost where www.privacytools.io material is served -- and with any webhosts that have copies of it, from any time after a commit that was merged under GPL, and is the motivation of a copyright dispute. Copyright can be assigned to another person, or to a corporation, at any time: somebody could go through that commit-list contacting all the contributors from August 2015 thru March 2018 and offering to buy their copyright, and then use that legal thing to file DMCA takedown. There is a grey area in the law, you are correct, and the 2002 draft from ESR makes clear that he believed there was some wiggle room. But it is a pointless risk to take on, there is still time to correct the problem.

Are you trying to drum up scene points and get on the team so you can sneak in malware suggestions or something? These anonymous users that pop out of nowhere

My suggestions are to keep listing firefox and to keep listing signalapp... pretty sure those are not malware. Pretty sure that BurungHantu thinks I'm nuts, so little chance of that :-) But I'm 100% correct here on whether the project-lead can relicense GPL'd code to WTFPLv2 without signoff, and whether that is an ongoing risk to the project. That you are shocked people like myself who contribute to a website about privacy and the tools to achieve it, are anonymous, is mildly amusing to me. I guess I shouldn't be shocked that you are paranoid about people screwing with privacyToolsIO, since after all, I'm paranoid about people screwing with privacyToolsIO myself... that's the whole reason I post here at all.

I'm just a person that knows what copyleft means, and I'm pointing it out because I know what DMCA takedowns work like: the webhost has to do the takedown, or they shoulder a huge liability onto themselves. @JonahAragon probably can correct me if that's wrong, but nothing has changed in DMCA-world that I'm aware

This is not about you Angela, your commit was rejected because of a license-incompatibility (I'm still presuming that is the case). GPL'd material cannot be merged into a permissively-licensed project. Any programmer knows this, who understands copyleft. This is about everybody who had a commit that **was** merged, and thus, is a copyright-holder of a portion of the **current** version of the website which is a derivative work (in part) of their GPL'd contribution, made sometime prior to the relicensing of the combined work: https://github.com/privacytoolsIO/privacytools.io/commits?after=00339a051a40b001668a30f2dcbfdbd7b94665a8+483 all the way back to August 2015 when the GPL license was selected. Any of them can "in theory" file a copyright complaint with github -- but more importantly, with the webhost where www.privacytools.io material is served -- and with any webhosts that have copies of it, from *any* time after a commit that was merged under GPL, and is the motivation of a copyright dispute. Copyright can be assigned to another person, or to a corporation, at any time: somebody could go through that commit-list contacting all the contributors from August 2015 thru March 2018 and offering to buy their copyright, and then use that legal thing to file DMCA takedown. There is a grey area in the law, you are correct, and the 2002 draft from ESR makes clear that he believed there was some wiggle room. But it is a pointless risk to take on, there is still time to correct the problem. > Are you trying to drum up scene points and get on the team so you can sneak in malware suggestions or something? These anonymous users that pop out of nowhere My suggestions are to keep listing firefox and to keep listing signalapp... pretty sure those are not malware. Pretty sure that BurungHantu thinks I'm nuts, so little chance of that :-) But I'm 100% correct here on whether the project-lead can relicense GPL'd code to WTFPLv2 without signoff, and whether that is an ongoing risk to the project. That you are shocked people like myself who contribute to a website about privacy and the tools to achieve it, are anonymous, is mildly amusing to me. I guess I shouldn't be shocked that you are paranoid about people screwing with privacyToolsIO, since after all, I'm paranoid about people screwing with privacyToolsIO myself... that's the whole reason I post here at all. I'm just a person that knows what copyleft means, and I'm pointing it out because I know what DMCA takedowns work like: the webhost **has** to do the takedown, or they shoulder a huge liability onto themselves. @JonahAragon probably can correct me if that's wrong, but nothing has changed in DMCA-world that I'm aware

We could comply with any DMCA takedown requests easily. If we received a valid copyright takedown from a former contributor, I don't see it being a huge deal. Service providers typically take down entire sites/profiles because they don't have the time (nor probably ability) to edit their customer's websites to remove only the offending content. If someone complained about content on our site, we would most likely simply immediately remove just that contributor's contributions, which would be fairly simple since we of course also control the site content and Git makes it easy. Then, because our contributions are public and transparent, a team member or other contributor could independently recreate the content/recommendation/whatever we removed in line with our current license, and that would be merged in.

If we're being honest, @BurungHantu1605 is probably responsible for 90% of the content from before the license switch anyways. The risk is minimal and easy to resolve in the moment, as far as I'm aware.

We could comply with any DMCA takedown requests easily. If we received a *valid* copyright takedown from a former contributor, I don't see it being a huge deal. Service providers typically take down entire sites/profiles because they don't have the time (nor probably ability) to edit their customer's websites to remove only the offending content. If someone complained about content on *our* site, we would most likely simply immediately remove just that contributor's contributions, which would be fairly simple since we of course also control the site content and Git makes it easy. Then, because our contributions are public and transparent, a team member or other contributor could independently recreate the content/recommendation/whatever we removed in line with our current license, and that would be merged in. If we're being honest, @BurungHantu1605 is probably responsible for 90% of the content from before the license switch anyways. The risk is minimal and easy to resolve in the moment, as far as I'm aware.
angela-d commented 2019-04-26 00:42:25 +00:00 (Migrated from github.com)

Did I say it was about me? I explicitly mentioned that same commit you're referring to.

your commit was rejected because of a license-incompatibility (I'm still presuming that is the case

You weren't even around when that occurred, why are you so sure that's the case? Shifterovich said nothing when he closed the commit. Wouldn't he have just said "License incompatibility - cannot merge" if that were the issue? No one else's commits have been rejected on those grounds. Or was there something special about mine? Enlighten us.

But I'm 100% correct here on whether the project-lead can relicense GPL'd code to WTFPLv2 without signoff

Have you ever forked a project and made it your own?

Unless the original licensor has a clause forbidding such, any new changes (made under your new license) are under the license of your choosing, you can't retroactively change old contributions, which I don't think BurungHantu did, else you wouldn't be able to even see there's an old license when going through the history. So you are wrong.

Prior to April 5, 2018:

  • All prior commits are GPL v3 (old commits are covered by this license)

After April 5, 2018:

  • All new commits are essentially public domain (new commits are covered by this license)

Commits that were in limbo, such as mine, would be expected to be whatever the license is at the time of merge, by my understanding.

If you took issue with this project and decided to fork off, you could add your own license and disregard the public domain license, but your new license is only covered on your commits after the license record date.

If BurungHantu wanted to retroactively change the license prior to April 5, yes, I will agree he would need permission from prior contributors to make changes to those commits.

There's nothing stating "everything for the life of PTIO is covered in this license."

I would suspect he gave it the license he did to specifically avoid nonsense like this. Licenses have their place, to protect original works. This site is supposed to be a useful tool and folks with too much time on their hands take the fun out of it.

Did I say it was about me? I explicitly mentioned that same commit you're referring to. > your commit was rejected because of a license-incompatibility (I'm still presuming that is the case You weren't even around when that occurred, why are you so sure that's the case? Shifterovich said nothing when he closed the commit. Wouldn't he have just said "License incompatibility - cannot merge" if that were the issue? No one else's commits have been rejected on those grounds. Or was there something special about mine? Enlighten us. > But I'm 100% correct here on whether the project-lead can relicense GPL'd code to WTFPLv2 without signoff Have you ever forked a project and made it your own? Unless the original licensor has a clause forbidding such, any *new* changes (made under your new license) are under the license of your choosing, you can't retroactively change old contributions, which I don't think BurungHantu did, [else you wouldn't be able to even see there's an old license](https://github.com/privacytoolsIO/privacytools.io/commits/master/LICENSE.txt) when going through the history. So you are wrong. Prior to April 5, 2018: - All prior commits are GPL v3 (old commits are covered by this license) After April 5, 2018: - All new commits are essentially public domain (new commits are covered by this license) Commits that were in limbo, such as mine, would be expected to be whatever the license is at the time of merge, by my understanding. If you took issue with this project and decided to fork off, you could add your own license and disregard the public domain license, but your new license is only covered on *your* commits after the license record date. If BurungHantu wanted to retroactively change the license *prior* to April 5, yes, I will agree he would need permission from prior contributors to make changes to *those* commits. There's nothing stating "everything for the life of PTIO is covered in this license." I would suspect he gave it the license he did to specifically avoid nonsense like this. Licenses have their place, to protect original works. This site is supposed to be a useful tool and folks with too much time on their hands take the fun out of it.
five-c-d commented 2019-04-26 00:47:43 +00:00 (Migrated from github.com)

we would most likely simply immediately remove just that contributor's contributions, which would be fairly simple

The problem is that, if Alice made a pull-request 100 lines of changes in January 2016 -- long enough to be considered copyrightable though courts differ on exactly HOW long is necessary -- every version of the site after April 2016 when that was merged, is a derivative work.

The bigger problem is that, if somebody wants to screw with privacyToolsIO, they can purchase copyright-assignment from a few dozen contributors spread all across the timeframe when the site was GPL-licensed, and then simultaneously present DMCA takedowns for seven different subsections of the website.

probably responsible for 90% of the content

Correct, and in these situations, ESR argues that there is an "implicit contractual agreement that contributors are not copyright-holders but that the overall copyright-holder is the editor of the collective work". But this is a legal theory, in the grey area. If somebody that wants to DMCA takedown privacyToolsIO has a lawyer that argues the entire content of the 2020 website is a derivative work of their half-dozen 2016-2017 contributions that they purchased earlier that month, and that the copyright-law which is applicable is the joint-work legislative statutes rather than the collective-work ones, the webhost will have to either obey the DMCA takedown request, or shoulder liability.

I'm not a lawyer, but that's the horror-scenario. The correct way to eliminate the risk, is to get sign-off from anybody who contributed more than NNN lines of pull-requests that were merged with GPL, that they agree to re-license (or better yet that they will assign copyright of their contributions to the human known as Burung Hantu). It is a pain in the buttocks, but should not be hard to get 90% of the way there with a few github-pings to people that authored contributions in the timespan in question. Depending on how that effort plays out, the next step would either be to stomach the remaining risk-factor (small unless a major contributor refused to relicense or could not be contacted because they left github), or to revert the license-change, or to rollback to a version that is fully clean, and then start from there "clean room style"

There's nothing stating "everything for the life of PTIO is covered in this license."

'you must pass on... the same freedoms... under **this** License'

The terms of the GPL state almost exactly that:

  • "...if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received... 5. Conveying Modified [HTML] Source... You may convey a [modified] work based on the [one you received]... provided that... [modified] work must carry prominent notices stating that it is released under this License [aka the modified work must always be released under the GPL -- never under any other license whether it be proprietary licensing or permissive licensing or incompatible-copyleft-licensing]."

The way the GPL works, is that all derivative works must be under the same license-terms, and all copies of the work must be under the same license-terms. There was a bunch of HTML+CSS in July 2017 that was "the covered work" and under GPL. You made some changes to a derivative of that work in December 2017. Your changes were under GPL, because that is how GPL works. Had your changes been committed at any time up until April 2018 the merge would have been Angela's GPL stuff combined with existing GPL stuff from the main repo... resulting in a combined work, all of it under GPL, and with you as a potential copyright-holder in the overall work, thanks to your merged contribution.

("Potential" because the change merged has to be 'copyrightable' ...if you just fixed a single typo it is not copyrightable but if your change was large and non-tedious/repetitive then it was probably copyrightable.) But that's not what happened: your work was not merged, even though Shifterovich wanted it in there. I've already asked them about whether they closed your contrib because of the license conflict, but they've been too busy to answer yet. They have seen this thread however, so if we're patient maybe we'll find out. But it was a long time ago, so maybe Shifterovich cannot remember :-) We live in suspense until then.

But like I tried to explain, this github-issue is not about that pull-request, which was "in limbo" as you aptly put it. The problem is the people who are NOT in limbo, that were merged in from late 2015 thru early 2018, and "in theory" could cause DMCA trouble.

Have you ever forked a project and made it your own?

Not on github, but yes.

Unless the original licensor has a clause forbidding such, any new changes (made under your new license) are under the license of your choosing

Unless the original licensor picked a strong copyleft -- in which case, the new license cannot proprietarize the old one.

> we would most likely simply immediately remove just that contributor's contributions, which would be fairly simple The problem is that, if Alice made a pull-request 100 lines of changes in January 2016 -- long enough to be considered copyrightable though courts differ on exactly HOW long is necessary -- every version of the site after April 2016 when that was merged, is a derivative work. The bigger problem is that, if somebody wants to screw with privacyToolsIO, they can purchase copyright-assignment from a few dozen contributors spread all across the timeframe when the site was GPL-licensed, and then simultaneously present DMCA takedowns for seven different subsections of the website. > probably responsible for 90% of the content Correct, and in these situations, ESR argues that there is an "implicit contractual agreement that contributors are *not* copyright-holders but that the overall copyright-holder is the editor of the collective work". But this is a legal theory, in the grey area. If somebody that wants to DMCA takedown privacyToolsIO has a lawyer that argues the entire content of the 2020 website is a derivative work of their half-dozen 2016-2017 contributions that they purchased earlier that month, and that the copyright-law which is applicable is the joint-work legislative statutes rather than the collective-work ones, the webhost will have to either obey the DMCA takedown request, or shoulder liability. I'm not a lawyer, but that's the horror-scenario. The correct way to eliminate the risk, is to get sign-off from anybody who contributed more than NNN lines of pull-requests that were merged with GPL, that they agree to re-license (or better yet that they will assign copyright of their contributions to the human known as Burung Hantu). It is a pain in the buttocks, but should not be hard to get 90% of the way there with a few github-pings to people that authored contributions in the timespan in question. Depending on how that effort plays out, the next step would either be to stomach the remaining risk-factor (small unless a major contributor refused to relicense or could not be contacted because they left github), or to revert the license-change, or to rollback to a version that **is** fully clean, and then start from there "clean room style" > There's nothing stating "everything for the life of PTIO is covered in this license." <details><summary>'you must pass on... the same freedoms... under **this** License'</summary><p> The terms of the GPL state almost exactly that: * "...<a href="https://www.gnu.org/licenses/gpl-3.0.en.html">if you distribute</a> copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received... 5. Conveying Modified [HTML] Source... You may convey a [modified] work based on the [one you received]... provided that... [modified] work must carry prominent notices stating that it is released under this License [aka the *modified* work must *always* be released under the GPL -- never under any other license whether it be proprietary licensing or permissive licensing or incompatible-copyleft-licensing]." The way the GPL works, is that all derivative works must be under the same license-terms, and all copies of the work must be under the same license-terms. There was a bunch of HTML+CSS in July 2017 that was "the covered work" and under GPL. You made some changes to a derivative of that work in December 2017. Your changes were under GPL, because that is how GPL works. Had your changes been committed at any time up until April 2018 the merge would have been Angela's GPL stuff combined with existing GPL stuff from the main repo... resulting in a combined work, all of it under GPL, and with you as a *potential* copyright-holder in the overall work, thanks to your merged contribution. ("Potential" because the change merged has to be 'copyrightable' ...if you just fixed a single typo it is not copyrightable but if your change was large and non-tedious/repetitive then it was probably copyrightable.) But that's not what happened: your work was not merged, even though Shifterovich wanted it in there. I've already asked them about whether they closed your contrib because of the license conflict, but they've been too busy to answer yet. They have seen this thread however, so if we're patient maybe we'll find out. But it was a long time ago, so maybe Shifterovich cannot remember :-) We live in suspense until then. But like I tried to explain, *this* github-issue is *not* about that pull-request, which was "in limbo" as you aptly put it. The problem is the people who are NOT in limbo, that were merged in from late 2015 thru early 2018, and "in theory" could cause DMCA trouble. > Have you ever forked a project and made it your own? Not on github, but yes. > Unless the original licensor has a clause forbidding such, any new changes (made under your new license) are under the license of your choosing Unless the original licensor picked a strong copyleft -- in which case, the new license cannot proprietarize the old one. </p></details>
angela-d commented 2019-04-26 00:54:48 +00:00 (Migrated from github.com)

@five-c-d Play devil's advocate for a second. You're Google and want to shut PTIO down.

What, exactly, is copyrighted? An html table that says Tor is the most privacy-consious browser? How can you claim copyright to such a thing?

The html table that made it? Is html really "original works" in today's web?

The copyright argument goes both ways. They'd need to show proof they own said copyright.

@five-c-d Play devil's advocate for a second. You're Google and want to shut PTIO down. What, exactly, is copyrighted? An html table that says Tor is the most privacy-consious browser? How can you claim copyright to such a thing? The html table that made it? Is html really "original works" in today's web? The copyright argument goes both ways. They'd need to show proof they own said copyright.

every version of the site after April 2016 when that was merged, is a derivative work.

I disagree with this idea. Git keeps very close track of the exact changes a contributor makes. I would argue that only the specific text they contributed would fall under their copyright, and only contributions from before the license change, because GitHub's terms of service make it clear that contributions automatically fall under the new license, which is currently effectively public domain (although not quite, and we should probably switch to CC0, but that's a separate issue).

> every version of the site after April 2016 when that was merged, is a derivative work. I disagree with this idea. Git keeps very close track of the exact changes a contributor makes. I would argue that only the specific text they contributed would fall under their copyright, and only contributions from before the license change, because GitHub's terms of service make it clear that contributions automatically fall under the new license, which is currently effectively public domain (although not quite, and we should probably switch to CC0, but that's a separate issue).
five-c-d commented 2019-04-26 02:02:37 +00:00 (Migrated from github.com)

proof they own said copyright

WIPO law grants automatic copyright as soon as something original is put into 'writing' or fixed form. This paragraph -- that I'm writing just now -- is idiosyncratic enough to be copyrightable. If you modify it, it is under the github TOS, which is how you received a copy of this paragraph. If I contribute code via pull-request, github TOS say that I-the-contributor retain copyright-ownership, unless there is a separate contributor-agreement (signalapp uses one but I've also seen them in lots of other libre-licensed projects) which then governs and takes precedence over the github TOS boilerplate.

Hence my question: was there a pull-request template, during the Aug'2015-thru-Apr'2018 timeframe, that asked for copyright assignment or asserted collective-work-status-under-editorship-of-the-project-lead or otherwise made an implied ability to relicense later legally binding? If not, we are still in the grey area. 90% of the site was by the project-owner when the relicense occurred. Is that enough to prove it is a collective work? Well... that is the problem, it is a grey area because it is hard to "prove" such a thing without going to court.

But DMCA gives all the power to the accuser: webhosts obey DMCA takedown notices as soon as they get them, let the site-owner fight in court. Which is usually pointless, even if you win it takes years, unless you can get an injunction or some kind of magic. But redistribution in violation of copyright is one of those "presumed guilty until proven innocent" types of things, unfortunately.

only the specific text they contributed would fall under their copyright[-ownership]

Yes, this is correct, at the time their contribution is merged. Say that Alice merges 100 lines of code in January 2016 in the VPN section. It is GPL. A year later in January 2017 Bob makes some changes to the VPN section -- which modify some of what Alice contributed. Bob's work is a derivative work of the original 2015 site and also of Alice's combined-work version that was merged the year earlier. Still GPL, but now with more copyright-holders

When Chuck makes more changes to the VPN section in January 2018, whether his work is a combined work of the Bob-stuff and the Alice-stuff and the original stuff, depends mostly on "lawyers peering at hanging chads". Which is not where we want privacyToolsIO to get stuck. Because while the lawyers are arguing about the chads, and whether 99 words is copyrightable or if 111 words is needed, the DMCA takedown has already booted privacyToolsIO content offline, including all mirrors.

only contributions from before the license change

Yes, this is 100% correct. The problem is that the license-change was probably not "legal" unless the work as of April 2018 was considered to be a collective work, with editorship and copyright-control-overall residing in the person of Burung Hantu. Iff that license-change was proper, then not only are all post-april-2018 changes under WTFPLv2, so are all the prior changes! Because everything was properly relicensed by the person with copyright-control-overall.

You're Google and want to shut PTIO down

So if my not-a-lawyer-but-pretty-damn-sure take on events is correct, then the license-change was in violation of the terms of the GPL. This is no problem, unless somebody who is

  1. copyright-owner and copyright-holder of a copyrightable contribution or ten
  2. that was merged between Aug'15 and Apr'18 into the codebase
  3. decides to make legal trouble. Or, decides to sell their copyright to Zuckerberg's shell-company LLC which is offering thousands of dollars for old commits, no strings attached...

The problem is not that the contributors might contain a badguy, the problem is that they might sell their copyright-ownership to a badguy, whilst mistakenly believing "hah hah they are paying me big bucks for HTML that is under the WTFPLv2 wheee". That's the threat here: because I think all those contributions are still GPL'd, that the license-change didn't impact previous contributions, and copyleft does not permit relicense-unless-you-control-the-copyright-overall.

probably switch to CC0, but that's a separate issue

Well, it won't hurt. (If that is the desire: to make the contents of the site anyone-can-edit including anyone-can-commercialize or anyone-can-re-GPL or whatever.) And very definitely it is possible to switch from WTFPLv2 over to CC0, for new contributions at least, but first we have to make sure whether I'm a lunatic for worrying about the switchover a year ago from GPL to WTFPL ... getting that one hammered out, that is my main worry.

I would suspect he gave it the license he did to specifically avoid nonsense like this

Yes, that was almost certainly his intent. But I don't think he had copyright-control-overall, not in a bulletproof way, because there is a legal grey area when you change from any strong copyleft to hyper-permissive. Morally, I have no qualms (parenthetical edit: though folks who are GPL purists and believe themselves the next incarnation of RMS will definitely have qualms -- I consider the 'community-risk' to be small compared to the lawyer-worry though because even most copyleft-purists don't see HTML as programming which mutes their purism). But legally is another matter, and in the legal world what matters is whether any of the contributors which were merged during that time, decide to complain... or sell their copyright to somebody else, who decides to complain... and perhaps bought up a lot of 'useless copyrights' with that in mind.

So unfortunately, the attempt to never see another github-issue like 418 again, directly led to github issue 884. Life's rich pageant and all that.

This site is supposed to be a useful tool and folks with too much time on their hands take the fun out of it.

Then go read the site with the listings of useful tools -- www.privacytools.io -- and spend your time enjoying yourself.

looks like we are on github right now, which is different

This site is supposed to be github, where people who care about libre-licensed software work on improving libre-licensed projects. Sometimes it is fun, but it is a certain sort of fun: the kind that takes hard work. I didn't open this issue for you, I opened it for the project-maintainers. I don't care about your unmerged commit, though at one time I did :-) If you think lawyer stuff like this is no fun, you are correct. Go work on another issue, that you do find fun. If you don't find working on issues fun anymore, there are plenty of other forums where you can discuss browsers and so on. But no, the mission here is to educate the masses in an effort to fight mass surveillance, and I don't really think of it as being a barrel of monkeys kind of fun. It is sometimes rewarding work, although not this particular time, obviously.

You think this issue should be closed, and my participation here ended, you have already made that perfectly clear. Fortunately or unfortunately, I'm not here to make things fun for you Angela. I'm here to work on improving the privacyToolsIO content, and for the most part, I've been trying to keep it from going downhill because of process-problems related to how the contributor-community is managed. There is not much time for "fun" contributing that adds new stuff, because the way the github is run at present is without moderation. Which is another discussion for another time, so I'll cut my rant short ;-)

> proof they own said copyright WIPO law grants automatic copyright as soon as something original is put into 'writing' or fixed form. This paragraph -- that I'm writing just now -- is idiosyncratic enough to be copyrightable. If you modify it, it is under the github TOS, which is how you received a copy of this paragraph. If I contribute code via pull-request, github TOS say that I-the-contributor retain copyright-ownership, unless there is a separate contributor-agreement (signalapp uses one but I've also seen them in lots of other libre-licensed projects) which then governs and takes precedence over the github TOS boilerplate. Hence my question: was there a pull-request template, during the Aug'2015-thru-Apr'2018 timeframe, that asked for copyright assignment or asserted collective-work-status-under-editorship-of-the-project-lead or otherwise made an implied ability to relicense later legally binding? If not, we are still in the grey area. 90% of the site was *by* the project-owner when the relicense occurred. Is that enough to prove it is a collective work? Well... that is the problem, it is a grey area because it is hard to "prove" such a thing without going to court. But DMCA gives all the power to the accuser: webhosts obey DMCA takedown notices as soon as they get them, let the site-owner fight in court. Which is usually pointless, even if you win it takes years, unless you can get an injunction or some kind of magic. But redistribution in violation of copyright is one of those "presumed guilty until proven innocent" types of things, unfortunately. > only the specific text they contributed would fall under their copyright[-ownership] Yes, this is correct, ***at*** the time their contribution is merged. Say that Alice merges 100 lines of code in January 2016 in the VPN section. It is GPL. A year later in January 2017 Bob makes some changes to the VPN section -- which modify some of what Alice contributed. Bob's work is a derivative work of the original 2015 site *and* also of Alice's combined-work version that was merged the year earlier. Still GPL, but now with more copyright-holders When Chuck makes more changes to the VPN section in January 2018, whether his work is a combined work of the Bob-stuff and the Alice-stuff and the original stuff, depends mostly on "lawyers peering at hanging chads". Which is *not* where we want privacyToolsIO to get stuck. Because while the lawyers are arguing about the chads, and whether 99 words is copyrightable or if 111 words is needed, the DMCA takedown has already booted privacyToolsIO content offline, including all mirrors. > only contributions from before the license change Yes, this is 100% correct. The problem is that the license-change was probably not "legal" unless the work as of April 2018 was considered to be a collective work, with editorship and copyright-control-overall residing in the person of Burung Hantu. ***Iff*** that license-change was proper, then not only are all post-april-2018 changes under WTFPLv2, so are all the prior changes! Because everything was properly relicensed by the person with copyright-control-overall. > You're Google and want to shut PTIO down So if my not-a-lawyer-but-pretty-damn-sure take on events is correct, then the license-change was in violation of the terms of the GPL. This is no problem, unless somebody who is 1. copyright-owner and copyright-holder of a copyrightable contribution or ten 2. that was merged between Aug'15 and Apr'18 into the codebase 3. decides to make legal trouble. Or, decides to sell their copyright to Zuckerberg's shell-company LLC which is offering thousands of dollars for old commits, no strings attached... The problem is not that the *contributors* might contain a badguy, the problem is that they might *sell* their copyright-ownership to a badguy, whilst mistakenly believing "hah hah they are paying me big bucks for HTML that is under the WTFPLv2 wheee". That's the threat here: because I think all those contributions are still GPL'd, that the license-change didn't impact previous contributions, and copyleft does not permit relicense-unless-you-control-the-copyright-overall. > probably switch to CC0, but that's a separate issue Well, it won't hurt. (If that is the desire: to make the contents of the site anyone-can-edit including anyone-can-commercialize or anyone-can-re-GPL or whatever.) And very definitely it is possible to switch from WTFPLv2 over to CC0, for new contributions at least, but first we have to make sure whether I'm a lunatic for worrying about the switchover a year ago from GPL to WTFPL ... getting that one hammered out, that is my main worry. > I would suspect he gave it the license he did to specifically avoid nonsense like this Yes, that was almost certainly his intent. But I don't think he had copyright-control-overall, not in a bulletproof way, because there is a legal grey area when you change from any strong copyleft to hyper-permissive. Morally, I have no qualms (parenthetical edit: though folks who are GPL purists and believe themselves the next incarnation of RMS will definitely have qualms -- I consider the 'community-risk' to be small compared to the lawyer-worry though because even most copyleft-purists don't see HTML as *programming* which mutes their purism). But legally is another matter, and in the legal world what matters is whether any of the contributors which were merged during that time, decide to complain... or sell their copyright to somebody else, who decides to complain... and perhaps bought up a lot of 'useless copyrights' with that in mind. So unfortunately, the attempt to never see another github-issue like 418 again, directly led to github issue 884. Life's rich pageant and all that. > This site is supposed to be a useful tool and folks with too much time on their hands take the fun out of it. Then go read the site with the listings of useful tools -- www.privacytools.io -- and spend your time enjoying yourself. <details><summary>looks like we are on github right now, which is different</summary><p> ***This*** site is supposed to be github, where people who care about libre-licensed software work on improving libre-licensed projects. Sometimes it is fun, but it is a certain sort of fun: the kind that takes hard work. I didn't open this issue for you, I opened it for the project-maintainers. I don't care about your unmerged commit, though at one time I did :-) If you think lawyer stuff like this is no fun, you are correct. Go work on another issue, that you do find fun. If you don't find working on issues fun anymore, there are plenty of other forums where you can discuss browsers and so on. But no, the mission here is to educate the masses in an effort to fight mass surveillance, and I don't really think of it as being a barrel of monkeys kind of fun. It is sometimes rewarding work, although not *this* particular time, obviously. You think this issue should be closed, and my participation here ended, you have already made that perfectly clear. Fortunately or unfortunately, I'm not here to make things fun for you Angela. I'm here to work on improving the privacyToolsIO content, and for the most part, I've been trying to keep it from going downhill because of process-problems related to how the contributor-community is managed. There is not much time for "fun" contributing that adds new stuff, because the way the github is run at present is without moderation. Which is another discussion for another time, so I'll cut my rant short ;-) </p></details>
angela-d commented 2019-04-26 02:19:19 +00:00 (Migrated from github.com)

You might get your point across better with more concise replies.

A permissive license was utilized in place of a more restrictive one. There was no mention of "everything" at any point. Past commits are GPLv3, new ones are public domain.

Since the site was largely redone after the license switch, you are once again in a grey area as 99% of the codebase likely changed. What about commits that reworded or rephrased prior commits? This site has had large verbiage, grammatical and structural changes since I first seen it.

You are making a big deal out of nothing.

The time you spend typing these enormous replies, you could have filled up your Github profile with your own original works and put your licensing experience to real use!

You might get your point across better with more concise replies. A permissive license was utilized in place of a more restrictive one. There was no mention of "everything" at any point. Past commits are GPLv3, new ones are public domain. Since the site was largely redone after the license switch, you are once again in a grey area as 99% of the codebase likely changed. What about commits that reworded or rephrased prior commits? This site has had large verbiage, grammatical and structural changes since I first seen it. You are making a big deal out of nothing. The time you spend typing these enormous replies, you could have filled up your Github profile with your own original works and put your licensing experience to real use!
five-c-d commented 2019-04-26 03:44:21 +00:00 (Migrated from github.com)
Angela

permissive license was utilized in place of [GPL]

which, I submit, violated the terms of the GPL... but this is the greyzone

There was no mention of "everything" at any point

No, the GPL requires that modified works must be GPL. That is what strong copyleft means. It is not optional, except in the very rare circumstance that the work in question is entirely under control of a single copyright-holder, or a group of copyright-holders which agree to act jointly and relicense. (That's the point of CLA and of work-for-hire in employee/employer contracts: to put things under a single point of control.)

Past commits are GPLv3, new ones are [wtfpl]

Not if the license-switch was invalid. The "new" commits are derivative works of the stuff they are modifying... and the stuff they are modifying, is GPL stuff, and the GPL requires that the modified work stay GPL

the site was largely redone after the license switch

Derivative work of the previous version(s) of the site. See above. Once GPL, always GPL, that is what copyleft means. There are some ways to wriggle out of it, such as asserting "collective work" or such as getting signoff from all contributors or whatnot.

What about commits that reworded or rephrased prior commits?

Depends on the complexity of the change. Typo fix: not copyrightable, thus, not "a contributor" in the DMCA-attack-vector scenario. Significant rewrite with lots of original creative effort: derivative work, must remain GPL due to copyleft, but adds +1 more copyright-holder to the joint-authorship. Or, if you believe the collective work thing that ESR lays out, derivative work, must remain GPL due to copyleft, but adds +0 more copyright holders... and the editor/controller who holds overall copyright, CAN relicense. Trouble is I'm not sure ESR is right on the merits, and I'm very not sure the risk is worth shouldering. Better to do it proper, get the signoffs, or revert the relicense, or anything but pretend there is no problem here move along nothing to see.

You are making a big deal out of nothing

I understand you think so. If I thought so as well, I would never have bothered to ask you whether you would please relicense your old GPLv3 commit from 2017 that you obviously don't care about anymore, I would just have taken it and relicensed it to WTFPLv2 and gone merrily on my way. Lots more fun that way.

But risky to the project upstream, if they merge my efforts, because license-incompatibility is a copyright law incompatiblity which can get the project into hot water. And if I took your GPL stuff and pretended it was WTFPL then very clearly I would be violating copyright-law, because unlike Burung Hantu my efforts are not nine-tenths of the existing combined-work so I cannot hope to claim 'collective work' rubric. (I wouldn't try to relicense anyways because it is polite to ask :-)

Years later sometimes, DMCA can come back to haunt you, or license-incompability can hurt the legal entity which did not manage to cross all the T's and dot all the i's. Copyright lasts a very long time, thanks to Mickey Mouse being an extremely valuable commodity and Disney being simultaneously a powerful corporation in California politics, plus not wanting anybody else to be able to make derivative works of their 1928 goldmine.

p.s. What you are describing, the ability to change from GPL to permissive, and from permissive to proprietary, is exactly why the Linux kernel, as a joint-authorship not a collective-work, has not been "relicensed to CC0" by google engineers who forked it to build android. Because they cannot do so, thanks to the copyleft nature of the codebase. Unless they 'cheat' e.g. https://news.ycombinator.com/item?id=2338142 from 2011.

Notice the constant reference to copyrightable, and that the definition of that word is a greyzone. There is some question whether "listings of [things]" is a copyrightable area, the most famous being Feist. Tools-listings are not alphabetical (with the exception of the VPN-table), tools are only selectively included, categories are creative/non-obvious, and so on.

backstory

p.p.s. Yes, I have been putting my knowledge of esoteric licensing to good use for many decades now. Just not on github. I only joined github because I wanted to file some bugs in signalapp. I'm under the impression github is not a very friendly place though :-) My pet issue over there is still not fixed ;-) Any codebase that I contribute to is more likely to be elsewhere. No offense to our hosts here in privacyToolsIO, they are awesome, and no offense to you Angela either. You are definitely getting on my nerves with your constant assertions that I must be some kind of badguy, otherwise what am I doing here, et cetera. But I do not fault you for wanting to save privacyToolsIO from nonsense and un-fun-ness and so on.

But it is simple: I'm here because I've spent many years interested in privacy, and before that, many many years interested in crypto and infosec and whatnot. And because this particular project has some really good info, I think it might actually have a chance to help beat mass surveillance (ditto for signalapp and my participation there). But it is very easy to go off the rails, on the way to such a thing. Plenty of lawyers and programmers understand copyleft, and if they were told "go find a way to get privacyToolsIO" then they would think of this, if they happened to notice the website was relicensed in a way that was from a subsuming license to a subsumed license. Sneaking in bad ideas is not a likely threat-vector. DMCA-takedown is a potential threat-vector, though I would not call it 'likely' exactly, because the potential damage is super-high, even a small risk is quite worrisome.

And unfortunately, when you and I had our conversation over in 856 about the relicense thing, I made a poor assumption: that there was a clickwrap or a CLA or something, or that signoff was garnered. So I already spilled the beans, over in 856, if any of Zuck's minions were trying to come up with an attack-vector, it was already made public. Hence when I looked into the commit-history, and found my poor assumption was poor, I kicked myself, but then went ahead and opened this thread, explaining why I was documenting a potential attack-vector in public: because, unfortunately, the attack-vector was already in public. Otherwise I would have quietly emailed Jonah (or more likely Shifterovich since they have an end2end encrypted email address in their github profile).

<details><summary>Angela</summary><p> > permissive license was utilized in place of [GPL] which, I submit, violated the terms of the GPL... but this is the greyzone > There was no mention of "everything" at any point No, the GPL **requires** that modified works must be GPL. That is what strong copyleft means. It is not optional, except in the very rare circumstance that the work in question is ***entirely*** under control of a single copyright-holder, or a group of copyright-holders which agree to act jointly and relicense. (That's the point of CLA and of work-for-hire in employee/employer contracts: to put things under a single point of control.) > Past commits are GPLv3, new ones are [wtfpl] Not if the license-switch was invalid. The "new" commits are derivative works of the stuff they are modifying... and the stuff they are modifying, is GPL stuff, and the GPL requires that the modified work *stay GPL* > the site was largely redone after the license switch Derivative work of the previous version(s) of the site. See above. Once GPL, always GPL, that is what copyleft means. There are some ways to wriggle out of it, such as asserting "collective work" or such as getting signoff from all contributors or whatnot. > What about commits that reworded or rephrased prior commits? Depends on the complexity of the change. Typo fix: not copyrightable, thus, not "a contributor" in the DMCA-attack-vector scenario. Significant rewrite with lots of original creative effort: derivative work, must remain GPL due to copyleft, but adds +1 more copyright-holder to the joint-authorship. Or, if you believe the collective work thing that ESR lays out, derivative work, must remain GPL due to copyleft, but adds +0 more copyright holders... and the editor/controller who holds **overall** copyright, CAN relicense. Trouble is I'm not sure ESR is right on the merits, and I'm *very* not sure the risk is worth shouldering. Better to do it proper, get the signoffs, or revert the relicense, or anything but pretend there is no problem here move along nothing to see. > You are making a big deal out of nothing I understand you think so. If I thought so as well, I would never have bothered to ask you whether you would please relicense your old GPLv3 commit from 2017 that you obviously don't care about anymore, I would just have taken it and relicensed it to WTFPLv2 and gone merrily on my way. Lots more fun that way. But risky to the project upstream, if they merge my efforts, because license-incompatibility is a *copyright law incompatiblity* which can get the project into hot water. And if I took your GPL stuff and pretended it was WTFPL then very clearly I would be violating copyright-law, because unlike Burung Hantu my efforts are **not** nine-tenths of the existing combined-work so I cannot hope to claim 'collective work' rubric. (I wouldn't try to relicense anyways because it is polite to ask :-) Years later sometimes, DMCA can come back to haunt you, or license-incompability can hurt the legal entity which did not manage to cross all the T's and dot all the i's. Copyright lasts a very long time, thanks to Mickey Mouse being <a href="en.wikipedia.org/wiki/Mickey_Mouse_Protection_Act">an extremely valuable commodity</a> and Disney being simultaneously a powerful corporation in California politics, plus not wanting anybody else to be able to make derivative works of their 1928 goldmine. </p></details> p.s. What you are describing, the ability to *change from GPL to permissive*, and from permissive to proprietary, is <a href="https://en.wikipedia.org/wiki/Copyright_law_of_the_United_States#Authorship,_Ownership,_and_Work_for_Hire">exactly why</a> the Linux kernel, as a joint-authorship not a collective-work, has not been "relicensed to CC0" by google engineers who forked it to build android. Because they *cannot* do so, thanks to the copyleft nature of the codebase. Unless they 'cheat' e.g. https://news.ycombinator.com/item?id=2338142 from 2011. Notice the constant reference to copyrightable, and that the definition of that word is a greyzone. There is some question whether "listings of [things]" is a copyrightable area, the most famous being <a href="https://en.wikipedia.org/wiki/Feist_Publications,_Inc.,_v._Rural_Telephone_Service_Co.">*Feist*</a>. Tools-listings are not alphabetical (with the exception of the VPN-table), tools are only selectively included, categories are creative/non-obvious, and <a href="https://en.wikipedia.org/wiki/Wikipedia:Copyright_in_lists#Selection">so on</a>. <details><summary>backstory</summary><p> p.p.s. Yes, I have been putting my knowledge of esoteric licensing to good use for many decades now. Just not on github. I only joined github because I wanted to file some bugs in signalapp. I'm under the impression github is not a very friendly place though :-) My pet issue over there is *still* not fixed ;-) Any codebase that I contribute to is more likely to be elsewhere. No offense to our hosts here in privacyToolsIO, they are awesome, and no offense to you Angela either. You are definitely getting on my nerves with your constant assertions that I must be some kind of badguy, otherwise what am I doing here, et cetera. But I do not fault you for wanting to save privacyToolsIO from nonsense and un-fun-ness and so on. But it is simple: I'm here because I've spent many years interested in privacy, and before that, many many years interested in crypto and infosec and whatnot. And because this particular project has some really good info, I think it might actually have a chance to help *beat* mass surveillance (ditto for signalapp and my participation there). But it is very easy to go off the rails, on the way to such a thing. Plenty of lawyers and programmers understand copyleft, and if they were told "go find a way to get privacyToolsIO" then they would think of this, if they happened to notice the website was relicensed in a way that was from a subsuming license to a subsumed license. Sneaking in bad ideas is not a likely threat-vector. DMCA-takedown *is* a potential threat-vector, though I would not call it 'likely' exactly, because the potential damage is super-high, even a small risk is quite worrisome. And unfortunately, when you and I had our conversation over in 856 about the relicense thing, I made a poor assumption: that there was a clickwrap or a CLA or something, or that signoff was garnered. So I already spilled the beans, over in 856, if any of Zuck's minions were trying to come up with an attack-vector, it was already made public. Hence when I looked into the commit-history, and found my poor assumption *was* poor, I kicked myself, but then went ahead and opened this thread, explaining *why* I was documenting a potential attack-vector in public: because, unfortunately, the attack-vector was already **in** public. Otherwise I would have quietly emailed Jonah (or more likely Shifterovich since they have an end2end encrypted email address in their github profile). </p></details>

It is a pain in the buttocks, but should not be hard to get 90% of the way there with a few github-pings to people that authored contributions in the timespan in question. Depending on how that effort plays out, the next step would either be to stomach the remaining risk-factor (small unless a major contributor refused to relicense or could not be contacted because they left github)

I'm not sure if you've actually looked at the list of contributors for that time period, but there are virtually no major contributors outside the team. The "risk" is as small as it gets already. Someone could probably buy the copyrights from the bottom 60 (out of 70) contributors on that list and it wouldn't affect the site long-term, because we could easily remove all those contributions and rewrite them based on past discussions ourselves.

> It is a pain in the buttocks, but should not be hard to get 90% of the way there with a few github-pings to people that authored contributions in the timespan in question. Depending on how that effort plays out, the next step would either be to stomach the remaining risk-factor (small unless a major contributor refused to relicense or could not be contacted because they left github) I'm not sure if you've actually looked at the [list of contributors for that time period](https://github.com/privacytoolsIO/privacytools.io/graphs/contributors?from=2015-07-05&to=2018-04-05&type=a), but there are virtually no major contributors outside the team. The "risk" is as small as it gets already. Someone could probably buy the copyrights from the bottom 60 (out of 70) contributors on that list and it wouldn't affect the site long-term, because we could easily remove all those contributions [and rewrite them based on past discussions ourselves](https://github.com/privacytoolsIO/privacytools.io/issues/884#issuecomment-486884795).
five-c-d commented 2019-04-26 04:15:32 +00:00 (Migrated from github.com)

Yes, I looked. And I agree with your assessment, were the legal system a sane thing.

pretty sure it ain't sane

But imagine that you are a webhost. Some lawyer is explaining that the code of their client was [insert jargon here] and an immediate DMCA takedown is needed. The webhost either has to comply or shoulder some liability by giving up the safe harbor provision thing.

It doesn't matter that privacyToolsIO will win in court, probably-with-any-luck. And until the court case is over, it will be hard to get any rewrite done, because the rewrite will also be accused (by the lawyer who is only there to try and sabotage privacyToolsIO in the first place) as being a derivative work of the prior versions, to which they have purchased a bona fide partial copyright.

we could easily remove all those contributions and rewrite them

Maybe... if you don't think that the March 2019 HTML is a derivative work of the February 2019 HTML, which is a derivative work of the January 2019 HTML, and so on. That was where you disagreed above, and apparently still disagree.

Even with derivative works, though, there is wiggle-room. It is always possible to do a clean-room rewrite, and if that does not pass muster in court, a cleaner clean-room rewrite. The problem is, trying to avoid getting taken to court at all. Trying to avoid being at risk of potentially getting taken to court, in other words, since DMCA takedown would be the goal of the badguys, not "winning in court"

Rather than take my word for it, talk to somebody you are friendly with that is familiar with complicated commercial software agreements, where the company is trying to build a proprietary product on top of a partially-libre-licensed bunch of libraries, including various portions that are GPL. You can see a lot of handset vendors in the last few years, and a lot of wifi-router vendors, that have been bitten by copyright and licensing compliance issues. Because they tried to release some kind of proprietary codebase with GPL'd busybox in it, or whatever.

Derivative work remains a derivative work, no matter how many years go by without lawsuits or the precursors.

there are virtually no major contributors outside the team

Right, which is good, speeds up risk-reduction. My advice is to speak with them (electronically is fine as long as it is via their github usernames) and get explicit signoff: "yes I agree to tri-license all my past contributions to the privacyToolsIO repo under GPLv3 and also under WTFPLv2 and also under CC0" with hyperlinks to the exact license-texts. Easier is if you ask the question, in a github-issue, and they comment "I hereby agree" in the issue.

Or even better: "yes I agree to transfer copyright-ownership of all my past contributions to Jonah Aragon" which gives more wiggle-room. (You can in turn transfer to Burung Hantu as needed or instantly but it might help to have a recipient with a name versus a github-handle... if you go this route rather than the tri-license signoff better check with somebody actually a lawyer.)

Since there are not that many, and since August 2015 is not that long ago, it won't take long to get the people most likely to have made judged-by-a-court-as-copyrightable contributions to signoff.

Yes, I looked. And I agree with your assessment, were the legal system a sane thing. <details><summary>pretty sure it ain't sane</summary><p> But imagine that you are a webhost. Some lawyer is explaining that the code of their client was [insert jargon here] and an immediate DMCA takedown is needed. The webhost either has to comply or shoulder some liability by giving up the safe harbor provision thing. It doesn't matter that privacyToolsIO will win in court, probably-with-any-luck. And until the court case is over, it will be hard to get any rewrite done, because the rewrite will also be accused (by the lawyer who is only there to try and sabotage privacyToolsIO in the first place) as being a derivative work of the prior versions, to which they have purchased a bona fide partial copyright. > we could easily remove all those contributions and rewrite them Maybe... if you don't think that the March 2019 HTML is a derivative work of the February 2019 HTML, which is a derivative work of the January 2019 HTML, and so on. That was where you disagreed above, and apparently still disagree. Even with derivative works, though, there is wiggle-room. It is always possible to do a clean-room rewrite, and if that does not pass muster in court, a cleaner clean-room rewrite. The problem is, trying to avoid getting taken to court *at all*. Trying to avoid being at risk of potentially getting taken to court, in other words, since DMCA takedown would be the goal of the badguys, not "winning in court" Rather than take my word for it, talk to somebody you are friendly with that is familiar with complicated commercial software agreements, where the company is trying to build a proprietary product on top of a partially-libre-licensed bunch of libraries, including various portions that are GPL. You can see a lot of handset vendors in the last few years, and a lot of wifi-router vendors, that have been bitten by copyright and licensing compliance issues. Because they tried to release some kind of <a href="https://en.wikipedia.org/wiki/BusyBox#GPL_lawsuits">proprietary codebase with GPL'd busybox</a> in it, or whatever. </p></details> Derivative work remains a derivative work, no matter how many years go by without lawsuits or the precursors. > there are virtually no major contributors outside the team Right, which is good, speeds up risk-reduction. My advice is to speak with them (electronically is fine as long as it is via their github usernames) and get explicit signoff: "yes I agree to tri-license all my past contributions to the privacyToolsIO repo under GPLv3 and also under WTFPLv2 and also under CC0" with hyperlinks to the exact license-texts. Easier is if you ask the question, in a github-issue, and they comment "I hereby agree" in the issue. Or even better: "yes I agree to transfer copyright-ownership of all my past contributions to Jonah Aragon" which gives more wiggle-room. (You can in turn transfer to Burung Hantu as needed or instantly but it might help to have a recipient with a name versus a github-handle... if you go this route rather than the tri-license signoff better check with somebody actually a lawyer.) Since there are not that many, and since August 2015 is not **that** long ago, it won't take long to get the people most likely to have made judged-by-a-court-as-copyrightable contributions to signoff.
This repo is archived. You cannot comment on issues.
No Milestone
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#884
No description provided.