Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
On forking and change of license #3
opened on 25 Apr by raimue
On forking and change of license
Saved for the sake of completeness: asciidoc3/asciidoc3-deprecated was deleted by now. (asciidoc3 did this)
raimue commented on 25 Apr
it is great to see someone willing to work on porting AsciiDoc to Python 3!
It looks like you modified the original source code of asciidoc, but also dropped all history from the repository by importing a snapshot of the source code. In my opinion, this is a bad start for a fork, as this takes away the chance to explore the history of the project. Could your changes be applied on top of the current state of AsciiDoc (for Python 2.x) to preserve the history?
You also changed the license to Affero GPLv3. As far as I see, the licensing statement for AsciiDoc does not even contain the "or any later version" phrasing, so it is strictly licensed as GPLv2 only. IANAL, but I highly doubt that Affero GPLv3 would even qualify as a later version of GPLv2. Do you have permission from all previous contributors to change the license?
Copying documentation from the old AsciiDoc website into your user guide, without any mention of the source or names of the original authors is also quite rude and questionable.
Overall I wonder why this project is not a continuation of the existing work at https://github.com/asciidoc/asciidoc3? See also asciidoc/asciidoc#83. Is compatibility with Python 3 alone worth a fork and a split of the community?
First, changing (?) license
Second, ‚copying documentation ... without any mention‘ (?)
Third, asciidoc(2) forking (?)
You can't relicense code you didn't write: https://softwareengineering.stackexchange.com/questions/66254/can-a-user-relicense-lgpl-as-gpl-or-gpl-as-agpl
You can upgrade AsciiDoc's original code to GPLv3 (based on the evidence you provided) but you can't relicense it to AGPL.
Beyond what you can and can't do. I think the AGPL is too drastic and it would hinder the adoption of the AsciiDoc language. Imagine a popular proprietary web service written in Python that would like to use your code (extract it out to use it as a lib), the AGPL would poison their code base and they would need to make the whole service open source. You lose the opportunity of users that way.
I see, the statement in COPYRIGHT is in fact different from what is stated in README. I originally only looked at the README, but I agree that COPYRIGHT should take precedence. So upgrading the license to GPLv3 is allowed.
However, I am still not sure about switching from GPLv3 to AGPLv3. From https://www.gnu.org/licenses/license-list.html#AGPLv3.0:
I think we agree that upgrading AsciiDoc3 to GPLv3 is not the point – that‘s ok. My intention was (and is) to make the software „as free as possible“ (to say in my own words).
Back to licensing and closing:
You can't relicense code you didn't write because you don't own the copyright, you have the right to use and modify the code under its license. It's two different things.
I can't contribute to this both on moral grounds (the AGPL is too copyleft to be used for infrastructure-level code) and on legal grounds (you are performing copyright infringement). I'll show myself out.
I encounter some kind of ‚shitstorm‘ since my statement about choosing the AGPLv3. All right, I do not insist on AGPL, the forthcoming release of AsciiDoc3 will be ‚GPLv3 or later‘ ...
This fork is in violation of the license of AsciiDoc Python. In particular, you have
If you do not bring the fork into compliance with the terms of the license of AsciiDoc Python (GPL2), the authors of AsciiDoc Python will work with the Software Freedom Law Center (or equivalent entity) to have this fork taken down. Consider this to be the official request in writing.
@asciidoc3 to explain further, Asciidoc Python is a copyright work whose copyright is owned by many people, all of whom have agreed to release it under the GPLv2+ license. That license allows you to distribute it in accordance with the terms of a later version of that license, but it does not allow you to change the license. Only the copyright owners can do that, (actually they can't change it, but they can release it under a different license) and all of them must agree for that to happen.
It doesn't matter how much or how little of Asciidoc Python code you use, any Asciidoc Python code remains copyrighted by others, and therefore licensed in accordance with the GPLv2+ unless the copyright holders agree to change it.
You can of course use any compatible license such as GPLv3 for the parts you create, and the whole may be distributed under that license since its is one that GPLv2+ allows. But you must acknowledge and inform users and contributors that parts remain licensed under GPLv2+, not simply change the license of the whole software to GPLv3.
If your git history allows your changes to be distinguished from original code I would have thought (but this is not legal advice) that you could just state that original code is GPLv2+ and new code is GPLv3, but otherwise I have no suggestion how to distinguish.
Just normal open source public development processes, there are comments on issues with the project.
Licenses are a sensitive topic in the open source community, they are all that ensures projects remain open source. Hence when people see a mistake they try to make the originator aware of that, and because they care about the projects remaining open source, that point may be made somewhat forcefully.
Stuart owns copyright of most, but all the contributors continue to own copyright of their contribution as recorded in the Git history, the Asciidoc project has no copyright assignment to Stuart. Thats part of why @mojavelinux was so cross about your erasing history, you have erased the record of copyright ownership and effectively assigned it to someone else.
If you really want to keep this as a separate project then you must fix the license problem and restore history. The simplest way to fix the license would be to just make the whole project GPLv2+, or, as I said above you might want to make new work GPLv3 whilst old content still remains under the GPLv2+, but then you have to state that in the headers and supply copies of both licenses.
But probably the best solution is to contribute to asciidoc/asciidoc3 (which will soon be renamed to asciidoc/asciidoc-py3, please don't use that name yourself, it will cause confusion). The more people communicate and co-operate to improve one version of software, the better off everyone is.
The problem with the asciidoc3 name (which applies to asciidoc/asciidoc3 as well, thats why it will be renamed) is that it may be confused with being a later version of Asciidoc not the original version of Asciidoc using a later version of Python.
There are plans to define the Asciidoc language independent of any specific implementation (like commonmark for markdown) and so its important not to confuse users between implementations, and versions of the language specification.
Well said, @elextr. The only point I have to add at this time is that preserving copyright notices isn't specific to open source licenses. This point is stated quiet clearly on the OSI site.
You can want copyright discussion to go away, but unless you come into compliance with the law, it doesn't work that way.
You cannot remove copyright and license notices that existed in the tarball. You have done that in the following files (not an exhaustive list)
You've also changed the license in many files. In fact, in at least one place you incorrectly cite the license of the original work as MIT (see https://github.com/asciidoc3/asciidoc3/blob/f5831ba11925e515ed9561f3e3fddabf79f81504/a2x3.py). My understanding is that you could use GPLv3 (as the GPLv2 license states), but you absolutely cannot change the license to AGPLv3.
There's also a trademark issue at hand here. You are using the original name of the software (adding a 3 does not make it different), yet running it as a separate project. You'll have to rename the project if you don't want to contribute your changes back upstream.
I think you really need to ask yourself if you are trying to help or harm AsciiDoc Python. Your current path is damaging the project substantially because you have created both controversy and confusion. If you have no interest in being part of the community, then you must come into compliance with the law and rename the project. If you'd like to contribute your changes upstream and rejoin the project, I invite you to do so (and I'm sure Lex does as well). If you decided on the latter, it would turn this situation around and generally benefit the AsciiDoc Python community.
@asciidoc3 its unfortunate that you started with a tarball. Tarballs are just a distribution mechanism for a snapshot of the project, they do not contain the history of the changes that have been made to get to the point and who made them, and are not intended to do so. A tarball is simply the result of those changes.
The answer on the stackexchange you quote provides answers to most of your points:
The technical mechanism to become compliant is to simply fork (in the github sense of the word) the Asciidoc repository, that will then have all the records of who owns which contributions. Then just apply your changes (except the ones breaking the license of course) to that clone instead of a tarball and publish it under a suitable name. That is a simple exercise of git.
But I would like to ask a non-technical question? What is your intention for this project, is it:
In both cases 2 and 3 it is necessary to communicate with the Asciidoc community, preferably before you published a fait accompli, so they could have advised you and you could have avoided the mistakes and this whole conversation. And then those making the version on the Asciidoc website and yourself could have cooperated on a single version making everybodys workload smaller. Instead there is now two ports of Asciidoc Python to Python 3, causing confusion for users.
And in all cases let me encourage you to communicate communicate communicate, we all have days where we forget that, and do something thats "obvious" to us, only to have others have a different opinion. Asking first saves us all heartache, that should be the big takeaway from this experience, both for this and all other projects you want to be involved in.
This will be my procedure:
Just out of curiosity: I always thought having my GPL sources available in git (or any SCM) was optional. Even having a downloadable tarball is no must. The key is to offer the sources, even if it's just on request and by direct submission (via E-Mail, USB-stick, ...) Of course this stays true for forks.
@ff200 well, its not the subject of this issue, which is about this specific project, the source is obviously available, its here on github, so you might be better asking on places dedicated to how to comply with the GPL, GNU themselves have several such resources.
Switching from GPLv2 or later to AGPL is perfectly legal. This does not relicense the original code, it just sets the license of new code and of the project as a whole.
The old code still stays GPLv2+, but when it is combined with the new code under AGPLv3 (or later?), the combined project will be under AGPLv3 (or later?).
However switching from GPL to AGPL without consensus of all other contributors is considered rude, because it could preclude some of the original authors from using the project. Their professional use of the project might depend on the loopholes in the copyleft of the GPL.
That aside (for all who happen to find this just as I did): The README in the new repository on gitlab states that the fork is GPLv2 or later.
@ArneBab, @asciidoc3 has usefully documented here a complaint that related to a previous fork, the license was changed on the original code, it was not left at GPLV2+. As you note that has been corrected on this fork.
Certainly new code can be any compatible license although the practicalities of tracing intermixed parts of code under different licenses is questionable. You can do it in Git, but a source tarball would lose that information.
Typically you’ll try to keep the license of the files for simplicity, however the license header typically says
Therefore you can use any later version and also redistribute under the later version (which means that you can change the license in the files: the code you distribute then has a different license, even though it’s identical to code under another license (so people could just use the old code instead)).
You can then always diff the old code und the new code to see which parts are also available under GPLv2. Though I would recommend to keep the license of individual files as it is and only apply the new project license to new files. That’s the difference between "you’re allowed to" and "it is typically a good idea".
No, the code thats distributed does not have a new license. Distribution requires defined actions under the GPLs. Those do not include changing the license of distributed software. Indeed it could not require that, as unless the distributor is the sole copyright holder of that code, they would be unable to change the license as they do not hold copyright. Although you may elect to comply with the terms of the GPLv3 in distributing GPLv2+ software, the receiver can still benefit from the terms of the GPLv2+, the license did not change to GPLv3 in the distribution action.
As an aside, similarly you can distribute software with compatible licenses (ones that allow distribution under the GPL terms) such as Apache 2 combined with GPLed software provided you do the distribution under the terms of the GPL. This does not however change the license of that software, and someone receiving it can still benefit from the extra freedom available for Apache 2 licensed code and the extra restrictions of the GPLed code.
If you are talking about the license header of the source files, you must keep the existing header, since code in the file is still licensed under that, and you must add information indicating that changes are made to the file (and date) in accordance with the GPLv2. The GPLv2 only allows modifications that are "identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves" to be under different licenses. That may apply to new files if their functionality is sufficiently independent.
New files containing new code may therefore be under any compatible license (but no that does not mean copying code from an old file to a new file allows you to change its license unless you own its copyright).
I’m not fully sure about whether you can change the license header in the files from GPL2+ to GPL3+.Tthe header itself says that I could distribute under GPL3 (or later). Therefore I’m not sure whether you need to keep the note that the file was originally under GPL2.
(means that your argument does not convince me, since it contradicts how I understand the file header)
This actually seems different with the Apache License which says
You cannot change the header in a way that changes the license of the file, you are NOT allowed to do that unless you have the copyright holders permission.
The GPL header wording from the section on how to apply the license says "you can redistribute it and/or modify it under the terms" which does not allow you to change the license. It just allows you to do modification or distribution under different terms, eg GPLv3 is (IIUC) more friendly to simply referring to online sources of GPL libraries you compile into a distributed binary, instead of having your own source copy (an acknowledgement of the ubiquity of Git, Github et al I guess).
Although the Apache 2.0 license is explicit about it, copyright law gives you no rights to do anything substantive with a work unless explicitly allowed by a license from the copyright holder, so the same applies to GPL or any other license.
The main part to clear up is whether the sentence in the header allows changing the header.
It was not my intention to change your decision, just to clear up misconceptions surrounding the decisions which have a way of taking on a life of their own.
For the definition of new code you need to look up the treshold of originality. It’s a copyright term, and as usual that means that it is murky water.