Date: Thu, 20 May 2021 15:05:21 -0500 From: "David C. Rankin" drankinatty@gmail.com To: aur-general@lists.archlinux.org Subject: Re: [aur-general] Notification of GPL violation Message-ID: c2e5a266-a494-7057-e4af-cbe57964c677@gmail.com Content-Type: text/plain; charset="utf-8"
On 5/18/21 2:06 AM, Brett Cornwall via aur-general wrote:
On 2021-05-17 21:16, Carsten Haitzler via aur-general wrote:
On Mon, 17 May 2021 13:32:26 +0000 lawl via aur-general aur-general@lists.archlinux.org said:
Hello
I'm the developer of NoiseTorch ( https://github.com/lawl/NoiseTorch/). I faithfully believe that the package "noisetorch" in the ArchLinux User Repository ("AUR") ( https://aur.archlinux.org/packages/noisetorch/) violates my license (GPLv3).
I have the asked previous maintainer of this package to not apply patches or make it clear that this is a fork that's being conveyed. Several Arch Linux trusted users were also informed of this: https://github.com/lawl/NoiseTorch/issues/2#issuecomment-785262068
I am just looking at the AUR repository for this right now. It has no patches. It does not modify anything from the original. It builds the original with standard go tooling and options available in that toolchain (not modifications to your software) and then packages up the resulting build. The only addition is ADDING a .desktop file to that package archive to make it easier to run the application. This does not modify the software. So by your quotes below it meets the license requirements. I don't know what was in the AUR pkg repo before but it certainly seems to be fine now.
For anyone else wondering what the fuss is all about, this is a long- running bout of drama stirred up by the developer of Noisetorch [1]. They are hostile and will not be reasoned with, unfortunately.
We are under no obligation to listen to these demands as we do not distribute the software and only supply a build script for which a user may build their own package. Kowtowing to this petulance will hardly solve the problem long-term as it is clear that *any* packages not made by the developer are treated with hostility.
But I guess hashworks has already extended the olive branch; We'll have to see whether that's enough...
[1] https://github.com/lawl/NoiseTorch/issues/2#issuecomment-785262068
I have reviewed all commits from 811aec6641ff509bd44cd80aa872f71df502e36a forward and there was no GPLv3 violation to begin with. The patch of the version is irrelevant to the operation or use of the software.
(notwithstanding that Arch doesn't distribute anything to begin with)
Probably kinda hard for a Go programmer to understand...
I know I will be the minority in this list. However, this statement doesn't sound right to me if the patch file is applied to the original source code.
Unlike the file PKGBUILD, a patch file constitutes a modified source code because it does include some original code. No matter whether the modification is for use, or operation, or just even a typo fix, GPLV3 section 5 "Conveying Modified Source Versions" [1] doesn't distinguish them.
I had a similar experience in terms of the AUR package SGE. I put my source code modification into a single patch file and put it to AUR git. Without my modification, SGE won't work with latest Linux anymore. However, due to an AUR website bug confirmed by a TU, the package was taken over without any emails sent to me.
After a lot of back and force with the second maintainer, I finally gave up re-owning the package or making the software better within AUR. Instead I asked the second maintainer to add my name to the single patch file so I get the credit I deserve. However, the second maintainer denied that. He split the patch into many small patch files without my name in any of them, and insists that it is enough to have my name as the first AUR package maintainer. Then I asked him to remove my code modification, also was denied.
Then I tried to ask TU to remove the package many times, all TUs denied my request, except the last TU deleted all those small patch files after he understood this is a serious copyright violation issue.
Here is my understanding about those copyright conflicts. If you modified any source code, then GPL license will be applied, you have to copy the original copyright without any modification and then add yours, just as section 4 in GPL v3 says "You may convey verbatim copies of the Program's source code as you receive it"
It is understandable that many AUR maintainers, or programmers like myself, don't know the details and often violates some copyright law more or less. We are lucky that most upstream programmers don't mind it. But, should such issue arise, I would do my best to make the upstream programmer happy or just find another alternative software.
I know I am the minority in this list because the AUR SGE got two up- votes ironically after it didn't work anymore, and the second maintainer is even promoting the binary version based on my modification on some other repos. But, life is too short, I can live with it. I am writing this email because I just hope my painful experience can help this list know copyright better.
[1] https://www.gnu.org/licenses/gpl-3.0.en.html
Best, Manhong
Hi Manhong,
it's squishy to form an opinion related to violation of a license and toleration of sensible modifications and sometimes even to distinguish between theft and fortuitousness.
If you wrote a song named "love song" composed of holding the note c for 1000 beats and after that holding the note c# for another 1000 beats at 120 beats per minute and a year later I write two songs and name both "love song", too, one composed of holding the note c for 1000 beats at 120 beats per minute and the other one holding the note c# for 1000 beats at 120 beats per minute. Would it make sense to argue related author's rights?
Sometimes disputes make no sense. Several factors must be taken into account and often common sense can be used to rate, if it's worth to argue.
Regards, Ralf
On Fri, 2021-05-21 at 18:27 +0200, Ralf Mardorf via aur-general wrote:
Hi Manhong,
it's squishy to form an opinion related to violation of a license and toleration of sensible modifications and sometimes even to distinguish between theft and fortuitousness.
If you wrote a song named "love song" composed of holding the note c for 1000 beats and after that holding the note c# for another 1000 beats at 120 beats per minute and a year later I write two songs and name both "love song", too, one composed of holding the note c for 1000 beats at 120 beats per minute and the other one holding the note c# for 1000 beats at 120 beats per minute. Would it make sense to argue related author's rights?
Sometimes disputes make no sense. Several factors must be taken into account and often common sense can be used to rate, if it's worth to argue.
Regards, Ralf
Full agreed with the common sense part, as copyright law is often complicated, even for attorneys. but I still think even 'sensible modifications' is still a modification, especially if the original author has an issue with it.
In terms of your wonderful metaphor 'love song', sorry I cannot comment , as there is no cell remotely related to any music in my brain or toe. :)
Best, Manhong
On Fri, 21 May 2021 12:37:05 -0400, Manhong Dai wrote:
I still think even 'sensible modifications' is still a modification, especially if the original author has an issue with it.
Yesno ;)! There are GPL vs BSD license disputes for no good reasons. How Pooterish can we go? As long as the world revolves around us, we are altruistic, but as soon as it isn't like that, nobody should expect that we continue acting altruistic? IOW should become 'free' and/or 'altruistic' just (an) empty word(s)? A 'sensible modification' is a 'sensible modification', it shouldn't be overrated.
On Fri, 2021-05-21 at 19:34 +0200, Ralf Mardorf via aur-general wrote:
On Fri, 21 May 2021 12:37:05 -0400, Manhong Dai wrote:
I still think even 'sensible modifications' is still a modification, especially if the original author has an issue with it.
Yesno ;)! There are GPL vs BSD license disputes for no good reasons. How Pooterish can we go? As long as the world revolves around us, we are altruistic, but as soon as it isn't like that, nobody should expect that we continue acting altruistic? IOW should become 'free' and/or 'altruistic' just (an) empty word(s)? A 'sensible modification' is a 'sensible modification', it shouldn't be overrated.
Good point! We do already have plenty of 'open source/free' licenses to pick from.
I also think we can agree that the original programmer/owner must have picked a particular license for a reason. Obviously, the original programmer/owner has a different understanding about 'sensible modification' here.
That being said, I always hope AUR can have as little conflicts like this as possible, so I can continuously benefit from Arch Linux.
Best, Manhong
On Fri, 21 May 2021 13:48:49 -0400, Manhong Dai wrote:
That being said, I always hope AUR can have as little conflicts like this as possible, so I can continuously benefit from Arch Linux.
In my experiences most of the AUR is without problems, a benefit for all of us.
We are all humans and the same reasoning can sound quite different.
One would say, all cultures are creative in different and/or equal ways, we can gain that much from each other. While I agree, I have to add that all cultures are blinkered in different and equal ways and we can be gigantic self-defeating, if we just try hard enough.
On 5/21/21 7:48 PM, Manhong Dai via aur-general wrote:
On Fri, 2021-05-21 at 19:34 +0200, Ralf Mardorf via aur-general wrote:
On Fri, 21 May 2021 12:37:05 -0400, Manhong Dai wrote:
I still think even 'sensible modifications' is still a modification, especially if the original author has an issue with it.
Yesno ;)! There are GPL vs BSD license disputes for no good reasons. How Pooterish can we go? As long as the world revolves around us, we are altruistic, but as soon as it isn't like that, nobody should expect that we continue acting altruistic? IOW should become 'free' and/or 'altruistic' just (an) empty word(s)? A 'sensible modification' is a 'sensible modification', it shouldn't be overrated.
Good point! We do already have plenty of 'open source/free' licenses to pick from.
I also think we can agree that the original programmer/owner must have picked a particular license for a reason. Obviously, the original programmer/owner has a different understanding about 'sensible modification' here.
Not a lawyer here, but here is my opinion on the matter.
I do not remember the GPL license stating anything about "sensible modifications", and while I do partly understand how some people are not happy about the certain clauses in some of these licenses, it is important to remember that these licenses have legal effects, while individual opinions on what modifications are "sensible" and what are not do not have any legal effect in most cases. Personal opinions for or against the chosen license do not excuse anyone from disobeying the license as long as the license applies (of which the details may vary depending on the country), in the same way "I hate person X" is in not an (legally) accepted reason for killing the particular person in most cases, although this comparison might be a bit extreme.
Basically, if you have anything against the license of a software, write to the author about it or do not use the software. Period.
That being said, I always hope AUR can have as little conflicts like this as possible, so I can continuously benefit from Arch Linux.
Best, Manhong
El sáb, 22 may 2021 a las 20:51, Yangjun Wang via aur-general (< aur-general@lists.archlinux.org>) escribió:
Not a lawyer here, but here is my opinion on the matter.
I do not remember the GPL license stating anything about "sensible modifications", and while I do partly understand how some people are not happy about the certain clauses in some of these licenses, it is important to remember that these licenses have legal effects, while individual opinions on what modifications are "sensible" and what are not do not have any legal effect in most cases. Personal opinions for or against the chosen license do not excuse anyone from disobeying the license as long as the license applies (of which the details may vary depending on the country), in the same way "I hate person X" is in not an (legally) accepted reason for killing the particular person in most cases, although this comparison might be a bit extreme.
Basically, if you have anything against the license of a software, write to the author about it or do not use the software. Period.
Not a lawyer either, but I think that the discussion, while really interesting, is missing a couple of core points regarding the license:
a) Arch is not distributing the source code of the software in any form, modified or not. b) Arch is not distributing a compiled version of the software either.
And, as it happens that the GPL (as well as most OS licenses out there) is about distribution and not about (custom/personal) use, I really can't see how on Earth it is being violated.
The point is that Arch (AUR) is just distributing:
$ wget foo.bar/foobar.tgz $ tar xvf foobar.tgz $ [sed s/foo/bar/|patch < foobar.patch|whatever] $ make
If the result of that never leaves the computer in which it was executed, where is the distribution element?
I can take ANY GPL software out there, make as many modifications as I like (I can even change the copyright notice and put a string saying that it belongs to my dog) and, as long as it never leaves my computer, I am still fully compliant with the license. If upstream doesn't like me to mess with their code, then maybe they shouldn't publish the code in the first place, but there's not a single reason to try to forbid some others (AUR) to publish A SCRIPT that helps people build custom binary versions not intended to be distributed in any way. What would happen then with the PKGBUILDs that are downloading, modifying (yep, modifying to the point of removing/changing binary libraries, using patchelf, etc.) and repackaging proprietary software?
In short, regarding upstream's request... nothing to see here, please disperse.
Best,
Miguel
On Sat, May 22, 2021, 3:52 PM Miguel Revilla Rodríguez via aur-general < aur-general@lists.archlinux.org> wrote:
El sáb, 22 may 2021 a las 20:51, Yangjun Wang via aur-general (< aur-general@lists.archlinux.org>) escribió:
Not a lawyer here, but here is my opinion on the matter.
I do not remember the GPL license stating anything about "sensible modifications", and while I do partly understand how some people are not happy about the certain clauses in some of these licenses, it is important to remember that these licenses have legal effects, while individual opinions on what modifications are "sensible" and what are not do not have any legal effect in most cases. Personal opinions for or against the chosen license do not excuse anyone from disobeying the license as long as the license applies (of which the details may vary depending on the country), in the same way "I hate person X" is in not an (legally) accepted reason for killing the particular person in most cases, although this comparison might be a bit extreme.
Basically, if you have anything against the license of a software, write to the author about it or do not use the software. Period.
Not a lawyer either, but I think that the discussion, while really interesting, is missing a couple of core points regarding the license:
a) Arch is not distributing the source code of the software in any form, modified or not
b) Arch is not distributing a compiled version of the software either.
I repectfully disagree. In this case the package maintainer had a patch file which includes some source code.
Thus, Arch AUR is distributing modified source code.
And, as it happens that the GPL (as well as most OS licenses out there) is about distribution and not about (custom/personal) use, I really can't see how on Earth it is being violated.
The point is that Arch (AUR) is just distributing:
$ wget foo.bar/foobar.tgz $ tar xvf foobar.tgz $ [sed s/foo/bar/|patch < foobar.patch|whatever] $ make
If the result of that never leaves the computer in which it was executed, where is the distribution element?
I can take ANY GPL software out there, make as many modifications as I like (I can even change the copyright notice and put a string saying that it belongs to my dog) and, as long as it never leaves my computer, I am still fully compliant with the license. If upstream doesn't like me to mess with their code, then maybe they shouldn't publish the code in the first place, but there's not a single reason to try to forbid some others (AUR) to publish A SCRIPT that helps people build custom binary versions not intended to be distributed in any way. What would happen then with the PKGBUILDs that are downloading, modifying (yep, modifying to the point of removing/changing binary libraries, using patchelf, etc.) and repackaging proprietary software?
In short, regarding upstream's request... nothing to see here, please disperse.
Best,
Miguel
El sáb, 22 may 2021 a las 21:57, Manhong Dai (daimh@umich.edu) escribió:
I repectfully disagree. In this case the package maintainer had a patch file which includes some source code.
Thus, Arch AUR is distributing modified source code.
Yep, it is distributing source code published under the GPL-3 license in a way that it cannot be confused at all with the original code, not in form, not in name, and certainly not in usability (that patch, by itself, is pretty much useless if it is not applied to something) so, respectfully too (cannot be in a different way), the patch file fully complies with the GPL-3, as the patching only happens in a "not public" environment, which is very different of, for example, distributing the patched sources without notice that it is not what upstream is originally publishing. Anyway, the original complaint was about "modifying" (i.e., patching) the software while keeping the original name, and not about distributing a few lines of the original code in the form of a patch. The former is simply not happening (at least not in the AUR/Arch "domains"), the latter wasn't even mentioned by the OP/upstream and wouldn't be a violation of the license either.
Best
On Sat, May 22, 2021, 4:15 PM Miguel Revilla Rodríguez via aur-general < aur-general@lists.archlinux.org> wrote:
El sáb, 22 may 2021 a las 21:57, Manhong Dai (daimh@umich.edu) escribió:
I repectfully disagree. In this case the package maintainer had a patch file which includes some source code.
Thus, Arch AUR is distributing modified source code.
Yep, it is distributing source code published under the GPL-3 license in a way that it cannot be confused at all with the original code, not in form, not in name, and certainly not in usability (that patch, by itself, is pretty much useless if it is not applied to something) so, respectfully too (cannot be in a different way), the patch file fully complies with the GPL-3, as the patching only happens in a "not public" environment, which is very different of, for example, distributing the patched sources without notice that it is not what upstream is originally publishing. Anyway, the original complaint was about "modifying" (i.e., patching) the software while keeping the original name, and not about distributing a few lines of the original code in the form of a patch. The former is simply not happening (at least not in the AUR/Arch "domains"), the latter wasn't even mentioned by the OP/upstream and wouldn't be a violation of the license either.
I fully agree with that the copyright holder doesn't have any ground if he is complaining about that the package maintainer shouldn't modify it.
But if he is complaining about how the patch file should be distributed, I think he does have a ground to sue, as a patch file constitutes a modified source code and then subjects to many limitation of GPL. For example, does the package maintainer carry an 'appropriate copyright notice' as in
https://www.gnu.org/licenses/gpl-faq.en.html#IWantCredit
Unfortunately, I don't know if there is any cases about the patch files. This will be interesting!
Best, Manhong
Best
22 мая 2021 г., 23:35 +0300, Manhong Dai via aur-general aur-general@lists.archlinux.org, написал (-а):
On Sat, May 22, 2021, 4:15 PM Miguel Revilla Rodríguez via aur-general < aur-general@lists.archlinux.org> wrote:
El sáb, 22 may 2021 a las 21:57, Manhong Dai (daimh@umich.edu) escribió:
I repectfully disagree. In this case the package maintainer had a patch file which includes some source code.
Thus, Arch AUR is distributing modified source code.
Yep, it is distributing source code published under the GPL-3 license in a way that it cannot be confused at all with the original code, not in form, not in name, and certainly not in usability (that patch, by itself, is pretty much useless if it is not applied to something) so, respectfully too (cannot be in a different way), the patch file fully complies with the GPL-3, as the patching only happens in a "not public" environment, which is very different of, for example, distributing the patched sources without notice that it is not what upstream is originally publishing. Anyway, the original complaint was about "modifying" (i.e., patching) the software while keeping the original name, and not about distributing a few lines of the original code in the form of a patch. The former is simply not happening (at least not in the AUR/Arch "domains"), the latter wasn't even mentioned by the OP/upstream and wouldn't be a violation of the license either.
I fully agree with that the copyright holder doesn't have any ground if he is complaining about that the package maintainer shouldn't modify it.
But if he is complaining about how the patch file should be distributed, I think he does have a ground to sue, as a patch file constitutes a modified source code and then subjects to many limitation of GPL. For example, does the package maintainer carry an 'appropriate copyright notice' as in
https://www.gnu.org/licenses/gpl-faq.en.html#IWantCredit
Unfortunately, I don't know if there is any cases about the patch files. This will be interesting!
Best, Manhong
Best
Strictly speaking patch file does not contain modified source code. It contains unmodified (and not copyrighted, surprisingly) part of original source code AND instruction how this code should be changed on users' machines.
Pasha
"(and not copyrighted, surprisingly) part of original source code"
I am truly surprised by the quoted above . How can you think the original source code is not copyrighted? As far as I know, US copyright law doesn't have distinction between different parts of software code.
Unless the upstream put the work in public domain explicitly as in the GPL FAQ link below, I don't think you understanding about copyright is any close to right.
https://www.gnu.org/licenses/gpl-faq.en.html#RequiredToClaimCopyright
Best, Manhong Sent from phone
вс, 23 мая 2021 г. в 02:15, Manhong Dai daimh@umich.edu:
"(and not copyrighted, surprisingly) part of original source code"
I am truly surprised by the quoted above . How can you think the original source code is not copyrighted? As far as I know, US copyright law doesn't have distinction between different parts of software code.
Unless the upstream put the work in public domain explicitly as in the GPL FAQ link below, I don't think you understanding about copyright is any close to right.
https://www.gnu.org/licenses/gpl-faq.en.html#RequiredToClaimCopyright
Best, Manhong Sent from phone
Of course, I meant that there is no copyright notice inside the patch file. Does it mean that the distribution of any patch file, patching GPL code is illegal? Because it by itself clearly breaks
publish on each copy an appropriate copyright notice
Pasha
On Sat, May 22, 2021, 7:20 PM Паша pavel.finkelshtein@gmail.com wrote:
вс, 23 мая 2021 г. в 02:15, Manhong Dai daimh@umich.edu:
"(and not copyrighted, surprisingly) part of original source code"
I am truly surprised by the quoted above . How can you think the original source code is not copyrighted? As far as I know, US copyright law doesn't have distinction between different parts of software code.
Unless the upstream put the work in public domain explicitly as in the GPL FAQ link below, I don't think you understanding about copyright is any close to right.
https://www.gnu.org/licenses/gpl-faq.en.html#RequiredToClaimCopyright
Best, Manhong Sent from phone
Of course, I meant that there is no copyright notice inside the patch file. Does it mean that the distribution of any patch file, patching GPL code is illegal? Because it by itself clearly breaks
Just like any other lawsuit, it is not confirmed to be illegal until a court says so.
If I am the package maintainer and the upstream complained, I would copy all the legal document including copyright, license, etc. from the upstream. If they are small enough, I can even put them inside the patch file so it is just one single patch file, which is much easier for anybody who wants to modify my work further.
If the upstream is still grumpy, I will give up and find an alternative.
Just my two cents, as I mentioned many times, I know nothing about law.
Best, Manhong
publish on each copy an appropriate copyright notice
Pasha
On 5/22/21 4:35 PM, Manhong Dai via aur-general wrote:
I fully agree with that the copyright holder doesn't have any ground if
he
is complaining about that the package maintainer shouldn't modify it.
But if he is complaining about how the patch file should be distributed, I think he does have a ground to sue, as a patch file constitutes a modified source code and then subjects to many limitation of GPL. For example, does the package maintainer carry an 'appropriate copyright notice' as in
https://www.gnu.org/licenses/gpl-faq.en.html#IWantCredit
Unfortunately, I don't know if there is any cases about the patch files. This will be interesting!
Who is this about? The noisetorch software, or the sge software? And what even is this???
Not to mention that the copyright holder already complained in this particular case, and the package maintainer did use a patch file, which always includes the original source code. Upside is it seems the package maintainer already fixed it.
In the former case the noisetorch copyright owner didn't state "I want credit" for the patch hunk containing copyrighted lines. So there is no point in arguing about whether or not distributing a patch file is fair use of the copyrighted code, or counts as obviously crediting the owner "because anyone capable of reading a patch also realizes that the copyright can be referenced by looking at the source code it is downloaded alongside".
Because... the author didn't demand credit.
If this is about sge, then first off I don't understand why you're replying to the noisetorch thread.
Second, my understanding is you, the purported copyright holder, do not in fact own the *original source code* for sge copyright, it is dave.love's modifications to Sun's original IP.
The question of whether you can claim copyright violation over a copy of 3 lines of the *original* source code in the diff hunk not having a copyright header, is irrelevant again, because dave.love didn't complain about the sge copyright.
So... we're back to the question I mentioned in my first response, "do the changes, not the *original* source code, constitute a creative work eligible for copyright"?
I humbly submit to the court of public opinion that, though I did not actually look at your patches to find out, I'm of the opinion that they must not be a creative work eligible for copyright.
Because. If you *thought* it was a creative work eligible for copyright?
You would not be WASTING EVERYONE'S TIME discussing inanities like whether or not someone's copyright is being violated if as a side effect of the "patch" technology some fragments of source code you don't own are being distributed!
I completely, utterly, 100% do not care in any way shape or form what you think about the general idea of patch files not containing copyright headers for the original source code which they are modifying (larger than the rest of the file, even). It's probably covered by fair use. To be certain, I don't think I've ever once seen anyone put copyright headers on patch files in order to advertise the license of half-baked fragments of context diffs worth of the original project's pre-modification source code. You do NOT have the right to declare for other people whether other people believe their copyright is being violated.
If, for software which you own the copyright to, you demand people include your copyright text any time they reuse your code by including it in the surrounding context of a patch file, then it's not worth my time to litigate with you, whether it is fair use or whatnot. I'll include an insultingly rude preamble e.g.
"The author of the original source code which this patch modifies, is a butthead that insisted I include full copyright notices for 3 lines of diff context used under fair use to tell the patch program how to apply my changes. This is patently nonsense and the author is clearly just trying to stir up trouble. The software is of course licensed under the license in the linked archive of, you know, actual code -- to which this patch of mine must be applied in order to be used. Since I cannot be bothered to argue this drivel, here are 674 lines worth of your free copy of the GPL, after which you can find 6 lines of above-licensed code, surrounding one line which is copyrighted by me and licensed under the terms of the shut-the-heck-up-this-is-copyright-the-upstream-project-license-already. I hope you enjoy reading through all that GPL before finding this tiny patch. Don't worry! You can read it again once you download the original project code too.
P.S. This is why we can't have nice things."
Because the GPL only tells me how I may use the code, it doesn't forbid me from calling you a butthead on the side.
All this is, of course, if we are actually talking about a project you produce (not a patch to someone else's project), and assumes I care enough about your project to actually persist in trying to use it rather than simply abandoning your project by the wayside and finding some other project to suit my needs -- one written by someone who is satisfied with producing code and demanding I distribute notice of the overall license, but doesn't care how I "license" bits and scraps of his code distributed in the accompanying patch file.
On 24/05/2021 13:43, Eli Schwartz via aur-general wrote:
Who is this about? The noisetorch software, or the sge software? And what even is this???
...
The orginal discussion was already concluded with [1]. The ongoing discussion of sge, initiated by Manhong, is completely unrelated and nothing but spam.
So indeed, everyone's time is wasted.
Alad
[1] https://lists.archlinux.org/pipermail/aur-general/2021-May/036236.html
On Mon, 2021-05-24 at 14:11 +0200, alad via aur-general wrote:
On 24/05/2021 13:43, Eli Schwartz via aur-general wrote:
Who is this about? The noisetorch software, or the sge software? And what even is this???
...
The orginal discussion was already concluded with [1]. The ongoing discussion of sge, initiated by Manhong, is completely unrelated and nothing but spam.
So indeed, everyone's time is wasted.
If it is 'spam', why did quite some people reply? and why did a few even support my understanding about copyright? Do you think all of those replied are not able tell 'spam' from discussion?
Alad
[1] https://lists.archlinux.org/pipermail/aur-general/2021-May/036236.html
On 24/05/2021 15:05, Manhong Dai wrote:
On Mon, 2021-05-24 at 14:11 +0200, alad via aur-general wrote:
On 24/05/2021 13:43, Eli Schwartz via aur-general wrote:
Who is this about? The noisetorch software, or the sge software? And what even is this???
...
The orginal discussion was already concluded with [1]. The ongoing discussion of sge, initiated by Manhong, is completely unrelated and nothing but spam.
So indeed, everyone's time is wasted.
If it is 'spam', why did quite some people reply? and why did a few even support my understanding about copyright? Do you think all of those replied are not able tell 'spam' from discussion?
This discussion was about noisetorch. You turned it into a discussion of copyright in general, based on your slights with the sge package. Replies or not, aur-general is *not* the place for that. There are plenty of mailing lists where legal topics can be discussed instead, such as license-discuss. [1]
So, please, take it to one of those.
Alad
[1] https://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensour...
Alad
[1] https://lists.archlinux.org/pipermail/aur-general/2021-May/036236.html
On Mon, 2021-05-24 at 07:43 -0400, Eli Schwartz via aur-general wrote:
On 5/22/21 4:35 PM, Manhong Dai via aur-general wrote:
I fully agree with that the copyright holder doesn't have any ground if
he
is complaining about that the package maintainer shouldn't modify it.
But if he is complaining about how the patch file should be distributed, I think he does have a ground to sue, as a patch file constitutes a modified source code and then subjects to many limitation of GPL. For example, does the package maintainer carry an 'appropriate copyright notice' as in
https://www.gnu.org/licenses/gpl-faq.en.html#IWantCredit
Unfortunately, I don't know if there is any cases about the patch files. This will be interesting!
Who is this about? The noisetorch software, or the sge software? And what even is this???
I only mentioned sge in my first email because I had similar experience with AUR. I even said 'life is too short' in the same email because I already moved on. You are the one bringing up sge again. Thus you might want to ask yourself your own question "why you're replying to the noisetorch thread". Not to mention your claim about SGE are all false. I will quote below.
Not to mention that the copyright holder already complained in this particular case, and the package maintainer did use a patch file, which always includes the original source code. Upside is it seems the package maintainer already fixed it.
In the former case the noisetorch copyright owner didn't state "I want credit" for the patch hunk containing copyrighted lines. So there is no point in arguing about whether or not distributing a patch file is fair use of the copyrighted code, or counts as obviously crediting the owner "because anyone capable of reading a patch also realizes that the copyright can be referenced by looking at the source code it is downloaded alongside".
Because... the author didn't demand credit.
If this is about sge, then first off I don't understand why you're replying to the noisetorch thread.
Second, my understanding is you, the purported copyright holder, do not in fact own the *original source code* for sge copyright, it is dave.love's modifications to Sun's original IP.
This is a lie! I never claimed to have copyright of SGE. I claimed U of Michigan has the copyright of my patch file, without which, SGE doesn't work with Arch Linux or any modern Linux at all. As the current AUR SGE depends openssl-1.0 according to https://aur.archlinux.org/packages/sge/ , you will understand this package became a joke, as openssl 1.1 is released in 2016.
The question of whether you can claim copyright violation over a copy of 3 lines of the *original* source code in the diff hunk not having a copyright header, is irrelevant again, because dave.love didn't complain about the sge copyright.
So... we're back to the question I mentioned in my first response, "do the changes, not the *original* source code, constitute a creative work eligible for copyright"?
I humbly submit to the court of public opinion that, though I did not actually look at your patches to find out, I'm of the opinion that they must not be a creative work eligible for copyright.
Because. If you *thought* it was a creative work eligible for copyright?
You would not be WASTING EVERYONE'S TIME discussing inanities like whether or not someone's copyright is being violated if as a side effect of the "patch" technology some fragments of source code you don't own are being distributed!
I completely, utterly, 100% do not care in any way shape or form what you think about the general idea of patch files not containing copyright headers for the original source code which they are modifying (larger than the rest of the file, even). It's probably covered by fair use. To be certain, I don't think I've ever once seen anyone put copyright headers on patch files in order to advertise the license of half-baked fragments of context diffs worth of the original project's pre-modification source code. You do NOT have the right to declare for other people whether other people believe their copyright is being violated.
If, for software which you own the copyright to, you demand people include your copyright text any time they reuse your code by including it in the surrounding context of a patch file, then it's not worth my time to litigate with you, whether it is fair use or whatnot. I'll include an insultingly rude preamble e.g.
"The author of the original source code which this patch modifies, is a butthead that insisted I include full copyright notices for 3 lines of diff context used under fair use to tell the patch program how to apply my changes. This is patently nonsense and the author is clearly just trying to stir up trouble. The software is of course licensed under the license in the linked archive of, you know, actual code -- to which this patch of mine must be applied in order to be used. Since I cannot be bothered to argue this drivel, here are 674 lines worth of your free copy of the GPL, after which you can find 6 lines of above-licensed code, surrounding one line which is copyrighted by me and licensed under the terms of the shut-the-heck-up-this-is-copyright-the-upstream-project-license- already. I hope you enjoy reading through all that GPL before finding this tiny patch. Don't worry! You can read it again once you download the original project code too.
P.S. This is why we can't have nice things."
Because the GPL only tells me how I may use the code, it doesn't forbid me from calling you a butthead on the side.
All this is, of course, if we are actually talking about a project you produce (not a patch to someone else's project),
Oh God. this sentence is the most horrendous copyright understanding I ever saw. If you are a TU, I would honestly suggest you to spend some time to read GPL. Let us keep it simple.
The upstream copyright holder owns the full copyright of the upstream software. Your understanding about this part is right.
If an AUR package maintainer applies a source code patch file, he owns the copyright of the patch file, unless he explicitly put the patch file in public domain. [1]
Here is the GPL FAQs that might interest you， https://www.gnu.org/licenses/gpl-faq.en.html#RequiredToClaimCopyright
Best, Manhong
and assumes I care enough about your project to actually persist in trying to use it rather than simply abandoning your project by the wayside and finding some other project to suit my needs -- one written by someone who is satisfied with producing code and demanding I distribute notice of the overall license, but doesn't care how I "license" bits and scraps of his code distributed in the accompanying patch file.
On Sat, May 22, 2021, 2:52 PM Yangjun Wang via aur-general < aur-general@lists.archlinux.org> wrote:
On 5/21/21 7:48 PM, Manhong Dai via aur-general wrote:
On Fri, 2021-05-21 at 19:34 +0200, Ralf Mardorf via aur-general wrote:
On Fri, 21 May 2021 12:37:05 -0400, Manhong Dai wrote:
I still think even 'sensible modifications' is still a modification, especially if the original author has an issue with it.
Yesno ;)! There are GPL vs BSD license disputes for no good reasons. How Pooterish can we go? As long as the world revolves around us, we are altruistic, but as soon as it isn't like that, nobody should expect that we continue acting altruistic? IOW should become 'free' and/or 'altruistic' just (an) empty word(s)? A 'sensible modification' is a 'sensible modification', it shouldn't be overrated.
Good point! We do already have plenty of 'open source/free' licenses to pick from.
I also think we can agree that the original programmer/owner must have picked a particular license for a reason. Obviously, the original programmer/owner has a different understanding about 'sensible modification' here.
Not a lawyer here, but here is my opinion on the matter.
I do not remember the GPL license stating anything about "sensible modifications", and while I do partly understand how some people are not happy about the certain clauses in some of these licenses, it is important to remember that these licenses have legal effects, while individual opinions on what modifications are "sensible" and what are not do not have any legal effect in most cases. Personal opinions for or against the chosen license do not excuse anyone from disobeying the license as long as the license applies (of which the details may vary depending on the country), in the same way "I hate person X" is in not an (legally) accepted reason for killing the particular person in most cases, although this comparison might be a bit extreme.
Basically, if you have anything against the license of a software, write to the author about it or do not use the software. Period.
Thanks a lot for confirming my opinion!
I have been 'spamming' this list since yesterday as I feel some package maintainers and even TUs have a interesting understanding about copyright. I learned that their reasons are 'law is also spirit', 'gpl means freedom', or even 'different culture', etc.....
I understand freedom as the freedom of choice so we can pick one from many similar open source software, instead of the freedom of using whatever software I like.
Not to mention that the copyright holder already complained in this particular case, and the package maintainer did use a patch file, which always includes the original source code. Upside is it seems the package maintainer already fixed it.
Are the few lines of original code in a patch file copyrightable? Even in the recent Oracle v. Google case, which is very narrow decision and only about '0.4 percent of the entire API', six justices said "We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copyrighted." Page 15 the court opinion. And the two dissenting justices further said "Is declaring code protected by copyright? I would hold that it is." Page 4 of the dissenting opinion.
Best, Manhong
That being said, I always hope AUR can have as little conflicts like this as possible, so I can continuously benefit from Arch Linux.
Best, Manhong
On Fri, 2021-05-21 at 18:27 +0200, Ralf Mardorf via aur-general wrote:
Hi Manhong,
it's squishy to form an opinion related to violation of a license and toleration of sensible modifications and sometimes even to distinguish between theft and fortuitousness.
If you wrote a song named "love song" composed of holding the note c for 1000 beats and after that holding the note c# for another 1000 beats at 120 beats per minute and a year later I write two songs and name both "love song", too, one composed of holding the note c for 1000 beats at 120 beats per minute and the other one holding the note c# for 1000 beats at 120 beats per minute. Would it make sense to argue related author's rights?
Sometimes disputes make no sense. Several factors must be taken into account and often common sense can be used to rate, if it's worth to argue.
Regards, Ralf
Hi Ralf,
You example is clearly missing the point. Let's unwrap.
Scenario 1: You did not know of the other song. You coincidently create the same song as someone else, no copyright will be applied. You simply did not copy anything. This example is not related to GPL at all.
Scenario 2: You did know about the song. You heard it in the radio. You liked the song, but you never actually did focus on the song trying to count how often each tone occured, you did not exactly measure the beats per minute, you did not search the internet for the exact details of the song. You rather got inspired by the song. You set down, you got creative and wrote down a brand new song which coincidently is the same song as published a year ago. You simply did not copy anything, GPL is not related at all.
In - broadly speaking - any other situation, you are copying. Copying is protected by the copyright. GPL grants you rights under certain conditions. If you don't fully comply with the restriction, you loose the rights.
There may be a fair use policy applying in certain situations. I am not aware, GPL grants any. As such: a patch file only containing 3 lines of the original is already copying. Writing those 3 lines "coincidently" is bullshit. Your purpose was never to be creative, your purpose was to write exactly those three lines. If I could "coincidently" write the same 3 lines in a patch file, then I could also "coincidently" type all the bits and bytes of the latest Star Wars movie in mp4 format by coincident and all copyright laws are dead the same second. So no, you did not write coincidently the same lines. You did copy.
Me personally I don't like the fact that big companies (unfortunately mine included) are earning a big pile of money using software they download for free from the internet without ever giving anything back to the community.
Now in this thread I got the feeling, many feel like "We are open source. We should not be monitored too close.". Arguments came up like "We do not distribute the software. We only distribute an installation script.". The latter one sounds very much like PirateBay, doesn't it?
Well, if we don't obey the GPL very strictly, why should those big companies do? Should we as members of the open source community not be the first to actually obey the GPL?
I am not blaming Arch Linux or any TU for wrong doing. I am not blaming anyone for anything because I am not a GPL / copyright expert. And I know it has been fixed already.
I just feel like supporting the opinion of Manhong and clearly opposing the mail of Ralf.
Oh, sorry to say Ralf: in any scenario you should never again consider to write a song! That song is horrible!
ente
On Fri, 2021-05-21 at 19:10 +0200, ente via aur-general wrote:
On Fri, 2021-05-21 at 18:27 +0200, Ralf Mardorf via aur-general wrote:
Hi Manhong,
it's squishy to form an opinion related to violation of a license and toleration of sensible modifications and sometimes even to distinguish between theft and fortuitousness.
If you wrote a song named "love song" composed of holding the note c for 1000 beats and after that holding the note c# for another 1000 beats at 120 beats per minute and a year later I write two songs and name both "love song", too, one composed of holding the note c for 1000 beats at 120 beats per minute and the other one holding the note c# for 1000 beats at 120 beats per minute. Would it make sense to argue related author's rights?
Sometimes disputes make no sense. Several factors must be taken into account and often common sense can be used to rate, if it's worth to argue.
Regards, Ralf
Hi Ralf,
You example is clearly missing the point. Let's unwrap.
Scenario 1: You did not know of the other song. You coincidently create the same song as someone else, no copyright will be applied. You simply did not copy anything. This example is not related to GPL at all.
Scenario 2: You did know about the song. You heard it in the radio. You liked the song, but you never actually did focus on the song trying to count how often each tone occured, you did not exactly measure the beats per minute, you did not search the internet for the exact details of the song. You rather got inspired by the song. You set down, you got creative and wrote down a brand new song which coincidently is the same song as published a year ago. You simply did not copy anything, GPL is not related at all.
In - broadly speaking - any other situation, you are copying. Copying is protected by the copyright. GPL grants you rights under certain conditions. If you don't fully comply with the restriction, you loose the rights.
There may be a fair use policy applying in certain situations. I am not aware, GPL grants any. As such: a patch file only containing 3 lines of the original is already copying. Writing those 3 lines "coincidently" is bullshit. Your purpose was never to be creative, your purpose was to write exactly those three lines. If I could "coincidently" write the same 3 lines in a patch file, then I could also "coincidently" type all the bits and bytes of the latest Star Wars movie in mp4 format by coincident and all copyright laws are dead the same second. So no, you did not write coincidently the same lines. You did copy.
Me personally I don't like the fact that big companies (unfortunately mine included) are earning a big pile of money using software they download for free from the internet without ever giving anything back to the community.
Now in this thread I got the feeling, many feel like "We are open source. We should not be monitored too close.". Arguments came up like "We do not distribute the software. We only distribute an installation script.". The latter one sounds very much like PirateBay, doesn't it?
Well, if we don't obey the GPL very strictly, why should those big companies do? Should we as members of the open source community not be the first to actually obey the GPL?
I am not blaming Arch Linux or any TU for wrong doing. I am not blaming anyone for anything because I am not a GPL / copyright expert. And I know it has been fixed already.
I just feel like supporting the opinion of Manhong and clearly opposing the mail of Ralf.
Oh, sorry to say Ralf: in any scenario you should never again consider to write a song! That song is horrible!
Finally someone with plenty of musicial cells stood up. Thx! :)
ente
On Fri, 21 May 2021 19:10:57 +0200, ente wrote:
Oh, sorry to say Ralf: in any scenario you should never again consider to write a song! That song is horrible!
:D
While I have to agree that my analogy doesn't work perfectly, this part of the analogy does a good job.
You and I probably agree, that due to the poor quality of the "love song" compositions, any dispute related to authorship is moot.
Common Vogon poetry is way more creative work, than this "love song" composition.
Hi ente,
On Fri, 21 May 2021 at 19:11, ente via aur-general < aur-general@lists.archlinux.org> wrote:
In - broadly speaking - any other situation, you are copying. Copying is protected by the copyright. GPL grants you rights under certain conditions. If you don't fully comply with the restriction, you loose the rights.
As far as I know, GPL governs how you can modify and distribute the modifications, it does not place any restrictions on what you may want to do to the software for your own use. The AUR does not distribute any modified version of the software, it merely provides a recipe for users to freely use or not.
There may be a fair use policy applying in certain situations. I am not aware, GPL grants any. As such: a patch file only containing 3 lines of the original is already copying. Writing those 3 lines "coincidently" is bullshit. Your purpose was never to be creative, your purpose was to write exactly those three lines.
Yes, but the volume of what you copy compared to the whole of the original creation does matter in copyright law. Even in Oracle v. Google ( https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.#Decision ) that consideration was one of the factors that led SCOTUS to rule that copying the whole Java API was fair use, even if Google did it with a prospect of profit. Those three lines by themselves serve absolutely no meaningful purpose and can hardly be considered a copyright violation.
Daniel
On Fri, May 21, 2021, 2:30 PM Daniel Berjón Díez via aur-general < aur-general@lists.archlinux.org> wrote:
Hi ente,
On Fri, 21 May 2021 at 19:11, ente via aur-general < aur-general@lists.archlinux.org> wrote:
In - broadly speaking - any other situation, you are copying. Copying is protected by the copyright. GPL grants you rights under certain conditions. If you don't fully comply with the restriction, you loose the rights.
As far as I know, GPL governs how you can modify and distribute the modifications, it does not place any restrictions on what you may want to do to the software for your own use. The AUR does not distribute any modified version of the software, it merely provides a recipe for users to freely use or not.
There may be a fair use policy applying in certain situations. I am not aware, GPL grants any. As such: a patch file only containing 3 lines of the original is already copying. Writing those 3 lines "coincidently" is bullshit. Your purpose was never to be creative, your purpose was to write exactly those three lines.
Yes, but the volume of what you copy compared to the whole of the original creation does matter in copyright law. Even in Oracle v. Google ( https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.#Decision ) that consideration was one of the factors that led SCOTUS to rule that copying the whole Java API was fair use, even if Google did it with a prospect of profit. Those three lines by themselves serve absolutely no meaningful purpose and can hardly be considered a copyright violation.
Google vs Oracle is not a broad decision as its opinion says "In reaching this result, the Court does not overturn or modify its earlier cases involving fair use. "
Further, as Daniel already pointed out, this case is just about API. The opinion says "The copied lines of code are part of a “user interface” that provides a way for programmers to access prewritten computer code through the use of simple commands. As a result, this code is different from many other types of code, ..."
IMHO, as it is very tricky to distribute a patch file without copyright, a better solution for AUR maintainers is to creat patch files including the upstream copyright and then host the files somewhere else. AUR will not be liable to such legal headache anymore, and the patch file owner enjoys the deserved credit all by himself while taking the full liability too. After all, AUR seems to be a public community for now and TU works for free for now too.
Best, Manhong
Daniel
-‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, May 21, 2021 10:25 PM, Manhong Dai via aur-general aur-general@lists.archlinux.org wrote:
IMHO, as it is very tricky to distribute a patch file without copyright, a better solution for AUR maintainers is to creat patch files including the upstream copyright and then host the files somewhere else. AUR will not be liable to such legal headache anymore, and the patch file owner enjoys the deserved credit all by himself while taking the full liability too. After all, AUR seems to be a public community for now and TU works for free for now too.
You know how fugly that is? If my domain where I store my source code gets nuked because I get hit by a bus, nobody else may know what the patch's content was. Sure, I could be less "anti-social" and just use github like too many other people, but I don't like being forced to do so. There was a similar discussion on the topic in the pypi community recently, where the problem of too many things hosted elsewhere is raised in the same way.
https://discuss.python.org/t/what-to-do-about-gpus-and-the-built-distributio...
cheers! mar77i
Sent with ProtonMail Secure Email.
On Fri, May 21, 2021, 4:36 PM mar77i via aur-general < aur-general@lists.archlinux.org> wrote:
-‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, May 21, 2021 10:25 PM, Manhong Dai via aur-general < aur-general@lists.archlinux.org> wrote:
IMHO, as it is very tricky to distribute a patch file without copyright,
a
better solution for AUR maintainers is to creat patch files including the upstream copyright and then host the files somewhere else. AUR will not
be
liable to such legal headache anymore, and the patch file owner enjoys
the
deserved credit all by himself while taking the full liability too. After all, AUR seems to be a public community for now and TU works for free for now too.
You know how fugly that is? If my domain where I store my source code gets nuked because I get hit by a bus, nobody else may know what the patch's content was. Sure, I could be less "anti-social" and just use github like too many other people, but I don't like being forced to do so. There was a similar discussion on the topic in the pypi community recently, where the problem of too many things hosted elsewhere is raised in the same way.
https://discuss.python.org/t/what-to-do-about-gpus-and-the-built-distributio...
As long as other people ever downloaded your patch files, everything is fine no matter your website is nuked or you get hit by a bus.
Actually your logic applies to AUR too, are you worried about AUR is nuked?
Best, Manhong
cheers! mar77i
Sent with ProtonMail Secure Email.
пт, 21 мая 2021 г., 23:40 Manhong Dai via aur-general < aur-general@lists.archlinux.org>:
On Fri, May 21, 2021, 4:36 PM mar77i via aur-general < aur-general@lists.archlinux.org> wrote:
-‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, May 21, 2021 10:25 PM, Manhong Dai via aur-general < aur-general@lists.archlinux.org> wrote:
IMHO, as it is very tricky to distribute a patch file without
copyright,
a
better solution for AUR maintainers is to creat patch files including
the
upstream copyright and then host the files somewhere else. AUR will not
be
liable to such legal headache anymore, and the patch file owner enjoys
the
deserved credit all by himself while taking the full liability too.
After
all, AUR seems to be a public community for now and TU works for free
for
now too.
You know how fugly that is? If my domain where I store my source code
gets
nuked because I get hit by a bus, nobody else may know what the patch's content was. Sure, I could be less "anti-social" and just use github like too many other people, but I don't like being forced to do so. There was
a
similar discussion on the topic in the pypi community recently, where the problem of too many things hosted elsewhere is raised in the same way.
https://discuss.python.org/t/what-to-do-about-gpus-and-the-built-distributio...
As long as other people ever downloaded your patch files, everything is fine no matter your website is nuked or you get hit by a bus.
Actually your logic applies to AUR too, are you worried about AUR is nuked?
Best, Manhong
cheers! mar77i
Sent with ProtonMail Secure Email.
With all due respect I want to remind you that law has not only the letter, but also a spirit. And when RMS was advocating for GPL he always kept in mind how the story had begun: he wasn't able to fix error in the printer firmware cause it was proprietary. And the whole idea of GPL was ability for user to change the software.
And also it was always about freedom and availability of course AND knowledge. Saying that we should not teach other users how they can modify source code they have is bad for the freedom and breaks both of these principles.
On Fri, May 21, 2021, 4:47 PM Паша pavel.finkelshtein@gmail.com wrote:
пт, 21 мая 2021 г., 23:40 Manhong Dai via aur-general < aur-general@lists.archlinux.org>:
On Fri, May 21, 2021, 4:36 PM mar77i via aur-general < aur-general@lists.archlinux.org> wrote:
-‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, May 21, 2021 10:25 PM, Manhong Dai via aur-general < aur-general@lists.archlinux.org> wrote:
IMHO, as it is very tricky to distribute a patch file without
copyright,
a
better solution for AUR maintainers is to creat patch files including
the
upstream copyright and then host the files somewhere else. AUR will
not
be
liable to such legal headache anymore, and the patch file owner enjoys
the
deserved credit all by himself while taking the full liability too.
After
all, AUR seems to be a public community for now and TU works for free
for
now too.
You know how fugly that is? If my domain where I store my source code
gets
nuked because I get hit by a bus, nobody else may know what the patch's content was. Sure, I could be less "anti-social" and just use github
like
too many other people, but I don't like being forced to do so. There
was a
similar discussion on the topic in the pypi community recently, where
the
problem of too many things hosted elsewhere is raised in the same way.
https://discuss.python.org/t/what-to-do-about-gpus-and-the-built-distributio...
As long as other people ever downloaded your patch files, everything is fine no matter your website is nuked or you get hit by a bus.
Actually your logic applies to AUR too, are you worried about AUR is nuked?
Best, Manhong
cheers! mar77i
Sent with ProtonMail Secure Email.
With all due respect I want to remind you that law has not only the letter, but also a spirit. And when RMS was advocating for GPL he always kept in mind how the story had begun: he wasn't able to fix error in the printer firmware cause it was proprietary. And the whole idea of GPL was ability for user to change the software.
And also it was always about freedom and availability of course AND knowledge. Saying that we should not teach other users how they can modify source code they have is bad for the freedom and breaks both of these principles.
Thanks a lot for teaching me not to teach others!
Actually I am not teaching anyone as I said I know nothing about law and it is just my humble opinion.
Best, Manhong
On Fri, 21 May 2021 at 22:26, Manhong Dai daimh@umich.edu wrote:
Further, as Daniel already pointed out, this case is just about API.
I did no such thing, I merely pointed out that one of their arguments is that the copy was not substantial in volume, and it was a lot more than three lines for a patch; actually, they specifically did not rule on the API copyrightability issue.
On Fri, May 21, 2021, 6:34 PM Daniel Berjón Díez asuranceturix@gmail.com wrote:
On Fri, 21 May 2021 at 22:26, Manhong Dai daimh@umich.edu wrote:
Further, as Daniel already pointed out, this case is just about API.
I did no such thing, I merely pointed out that one of their arguments is that the copy was not substantial in volume, and it was a lot more than three lines for a patch; actually, they specifically did not rule on the API copyrightability issue.
Very fun discussion! Thanks for the inspiration!
In the Syllabus, page 2 and 3 of the opinion, it is all about API or "user interface".
https://www.supremecourt.gov/opinions/20pdf/18-956_new_0e04.pdf
Everybody can argue about that a diff patch file is 'fair use' or not. But I think we can agree that 'fair use' is always case by case as it depends on how large/important the the patch is. I also think we can agree that most of the patch files are neither API nor "user interface" as in the opinion above.
If the patch file is more than API, I am certain that the two dissenting justices will think it is also a copyright violation, and I am not certain how many of the other 6 justices will vote.
Just my naive understanding about the Scotus opinion, it is worth $0.019 due to the current inflation, and it is worth zero in Europe.
Best, Manhong
On 5/21/21 1:10 PM, ente via aur-general wrote:
On Fri, 2021-05-21 at 18:27 +0200, Ralf Mardorf via aur-general wrote:
Hi Manhong,
it's squishy to form an opinion related to violation of a license and toleration of sensible modifications and sometimes even to distinguish between theft and fortuitousness.
If you wrote a song named "love song" composed of holding the note c for 1000 beats and after that holding the note c# for another 1000 beats at 120 beats per minute and a year later I write two songs and name both "love song", too, one composed of holding the note c for 1000 beats at 120 beats per minute and the other one holding the note c# for 1000 beats at 120 beats per minute. Would it make sense to argue related author's rights?
Sometimes disputes make no sense. Several factors must be taken into account and often common sense can be used to rate, if it's worth to argue.
Regards, Ralf
Hi Ralf,
You example is clearly missing the point. Let's unwrap.
Scenario 1: You did not know of the other song. You coincidently create the same song as someone else, no copyright will be applied. You simply did not copy anything. This example is not related to GPL at all.
Scenario 2: You did know about the song. You heard it in the radio. You liked the song, but you never actually did focus on the song trying to count how often each tone occured, you did not exactly measure the beats per minute, you did not search the internet for the exact details of the song. You rather got inspired by the song. You set down, you got creative and wrote down a brand new song which coincidently is the same song as published a year ago. You simply did not copy anything, GPL is not related at all.
In - broadly speaking - any other situation, you are copying. Copying is protected by the copyright. GPL grants you rights under certain conditions. If you don't fully comply with the restriction, you loose the rights.
There may be a fair use policy applying in certain situations. I am not aware, GPL grants any. As such: a patch file only containing 3 lines of the original is already copying. Writing those 3 lines "coincidently" is bullshit. Your purpose was never to be creative, your purpose was to write exactly those three lines. If I could "coincidently" write the same 3 lines in a patch file, then I could also "coincidently" type all the bits and bytes of the latest Star Wars movie in mp4 format by coincident and all copyright laws are dead the same second. So no, you did not write coincidently the same lines. You did copy.
This is all moot -- the letter "c" repeated endlessly is not a creative work and is ineligible for copyright protection.
If this is intended to be a good comparison to an AUR "violation of copyright" (I have not looked at Manhong's claim) then there's no issue, the disputed patches were never under any copyright to violate.
Determining whether there is a copyright to violate might require more time than one is interested in spending to analyze whether some change is the kind of change e.g. best described as "only one obvious way to accomplish it".
e.g. this C function is not copyrightable:
int add(int a, int b) { return a + b; }
Neither is this function:
int add(a, b) { return a + b; }
... even though it's both silly and bad. More importantly, a patch to add the int types and make it compile without warnings, is not a copyrightable patch either.
Me personally I don't like the fact that big companies (unfortunately mine included) are earning a big pile of money using software they download for free from the internet without ever giving anything back to the community.
Now in this thread I got the feeling, many feel like "We are open source. We should not be monitored too close.". Arguments came up like "We do not distribute the software. We only distribute an installation script.". The latter one sounds very much like PirateBay, doesn't it?
In fact, the distinction is very important. IANAL, but my understanding is:
Licenses for works which you legally receive, and then modify in ways that violate the license, are generally binding only when you distribute the results. Such terms would therefore prohibit packaging noisetorch for the [community] repository, but be permitted in the AUR.
... furthermore with your Pirate Bay <-> AUR comparison, the common point is "not distributing anything, only linking to it". But in the case of the AUR, the links are linking to legal content, while in the case of the Pirate Bay, the links are linking to illegal content.
If the AUR does not:
- distribute illegal content - link to illegal content - teach you how to do something illegal
then what, precisely, is it doing that is getting y'all so hot and bothered?
It is *legal* to: - download the completely legal noisetorch source code - locally patch it in any way you like - run it on your personal laptop in violation of the terms demanding it be renamed - publish a guide to teach other people how to do the same thing
Even if it weren't legal, the noisetorch program was not being modified in any practical sense. The only patch applied was a patch to the build system, so that a script used to dynamically generate a source file using git was replaced by a saved copy of the generated source file processed directly.
By the very loosest meaning of the word "modify", it was being modified. But running the go compiler also modifies it (turns it from text into machine code). Adding a backported patch from upstream git master modifies it. Running gofmt modifies it.
The program logic didn't get modified in any way, not even in a "different algorithm, same result" way. In all probability, the resulting compiled binary was byte-identical to the version without the patch.
Comparing the AUR to the Pirate Bay is simply arguing in extremely bad faith, for multiple reasons.
"locally patch it in any way you like"
I basically agree with everything you said, but the statement quoted above is tricky.
As I said before, it really depends on how you patch it. If it is a diff patch file, which always uses the original code, then the upstream programmer does have a ground to sue.
Best, Manhong Sent from phone
On Fri, May 21, 2021 at 15:06:09 -0400, Manhong Dai via aur-general wrote:
"locally patch it in any way you like"
I basically agree with everything you said, but the statement quoted above is tricky.
As I said before, it really depends on how you patch it. If it is a diff patch file, which always uses the original code, then the upstream programmer does have a ground to sue.
Isn't a patch file simply nothing more than a formalised way of explaining "here is how you (yourself, on your machine) have to change the source to make it work".
Why is it different from a guide in plain $human_language that explains the same set of changes?
Best, Tinu
On Sun, May 23, 2021, 6:02 AM Tinu Weber takeya@bluewin.ch wrote:
On Fri, May 21, 2021 at 15:06:09 -0400, Manhong Dai via aur-general wrote:
"locally patch it in any way you like"
I basically agree with everything you said, but the statement quoted above is tricky.
As I said before, it really depends on how you patch it. If it is a diff patch file, which always uses the original code, then the upstream programmer does have a ground to sue.
Isn't a patch file simply nothing more than a formalised way of explaining "here is how you (yourself, on your machine) have to change the source to make it work".
Why is it different from a guide in plain $human_language that explains the same set of changes?
I would fully agree with you if the patch file doesn't include any original source code.
Actually, to boil it down, it all depends on how the upstream feels.
In most of the cases, I believe the upstream doesn't care or is even happy about it. But small companies or individuals do need the credit/income to survive and grow.
btw, I am sure we can see more conflicts like this if AUR becomes more popular and has some income, which I think is well deserved. but this is another topic about 'fair use' clause in US copyright law, which should concern AUR owner, IMHO.
Best, Manhong
Best, Tinu
El dom, 23 may 2021 a las 17:12, Manhong Dai via aur-general (< aur-general@lists.archlinux.org>) escribió:
I would fully agree with you if the patch file doesn't include any original source code.
Then we only have to start using xdelta instead of diff to create the patches and we will be fine, as the deltas don't contain any of the original code, but only instructions on how to convert it to the new one. It is not human readable, git won't like it as much as it likes plain text files, and won't work with line offsets, but it will fully comply with the license.
Best
Miguel
On Mon, 2021-05-24 at 09:11 +0200, Miguel Revilla Rodríguez via aur- general wrote:
El dom, 23 may 2021 a las 17:12, Manhong Dai via aur-general (< aur-general@lists.archlinux.org>) escribió:
I would fully agree with you if the patch file doesn't include any original source code.
Then we only have to start using xdelta instead of diff to create the patches and we will be fine, as the deltas don't contain any of the original code, but only instructions on how to convert it to the new one. It is not human readable, git won't like it as much as it likes plain text files, and won't work with line offsets, but it will fully comply with the license. Best
Miguel
I am sure this xdelta idea can be useful in some 'right to repair' cases, as it doesn't use any source code, and thus doesn't have the copyright issue. The thing is xdelta file will break if the upstream file changes.
That being said, I think diff/patch file is just fine as most upstream won't complain. Not to mention it is easier for a package maintainer to put his own copyright claim inside the diff file.
Best, Manhong
24 mai 2021 09:11 "Miguel Revilla Rodríguez via aur-general" aur-general@lists.archlinux.org a écrit:
Then we only have to start using xdelta instead of diff to create the patches and we will be fine, as the deltas don't contain any of the original code, but only instructions on how to convert it to the new one.
Correct me if I'm wrong, but I think we could also use `diff -U0`, as it does not include any context at all. Only and strictly only the lines added and removed are mentionned. This means that, if you do not remove any lines at all, you should be fine.
Antoine Viallon (aviallon)
On Tue, 2021-05-25 at 12:56 +0000, Antoine Viallon via aur-general wrote:
24 mai 2021 09:11 "Miguel Revilla Rodríguez via aur-general" < aur-general@lists.archlinux.org> a écrit:
Then we only have to start using xdelta instead of diff to create the patches and we will be fine, as the deltas don't contain any of the original code, but only instructions on how to convert it to the new one.
Correct me if I'm wrong, but I think we could also use `diff -U0`, as it does not include any context at all. Only and strictly only the lines added and removed are mentionned. This means that, if you do not remove any lines at all, you should be fine.
Antoine Viallon (aviallon)
Unfortunately it still uses the original code. Here is my test.
$ diff -U0 <(seq 900 1000) <(seq 900 1000 | sed -e "s/999/99999999/" ) --- /dev/fd/63 2021-05-25 09:57:37.954088656 -0400 +++ /dev/fd/62 2021-05-25 09:57:37.954088656 -0400 @@ -100 +100 @@ -999 +99999999
Note the '-999' part.
Best, Manhong
Unfortunately it still uses the original code. Here is my test.
$ diff -U0 <(seq 900 1000) <(seq 900 1000 | sed -e "s/999/99999999/" ) --- /dev/fd/63 2021-05-25 09:57:37.954088656 -0400 +++ /dev/fd/62 2021-05-25 09:57:37.954088656 -0400 @@ -100 +100 @@ -999 +99999999
Note the '-999' part.
so your claim is that that single line added for context is copyright-able? I'm not sure judges would agree on that.
On Tue, 2021-05-25 at 16:11 +0200, Damjan Georgievski wrote:
Unfortunately it still uses the original code. Here is my test.
$ diff -U0 <(seq 900 1000) <(seq 900 1000 | sed -e "s/999/99999999/" ) --- /dev/fd/63 2021-05-25 09:57:37.954088656 -0400 +++ /dev/fd/62 2021-05-25 09:57:37.954088656 -0400 @@ -100 +100 @@ -999 +99999999
Note the '-999' part.
so your claim is that that single line added for context is copyright- able? I'm not sure judges would agree on that.
1, patch files include some original source code
2, a patch file could include any lines of source code between one and a billion. (well, I admit that a billion is a stretch)
3, There is no hard limit of how many lines of code can be considered as copyright-able in law, AFAIK. GPL's benchmark is 300 lines, but it also says 'Unless, that is, the code is specially important'. [1]
4, If you agree that any lines of source code could be copyright-able, then it boils down to if the patch file is a fair use. Everybody can have his own opinion, while it actually depends on the upstream's feeling, and the US copyright law has four factors to consider. Footnote 4, page 51 of [2].
5, If we think the code in a patch file is categorically no copyright- able, what if somebody used a patch file you spent a lot of time on and significantly improved a software, but he didn't credit you?
When we are protecting other's copyright, we are also protecting our own.....
[1] https://www.gnu.org/licenses/gpl-faq.en.html#NoticeInSourceFile
[2] https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf
Best, Manhong
As an outside observer of this thread, it seems like the time for discussion is over. This talk appears to center largely about opinions on civil litigation.
So, my suggestion to whoever thinks they have legal recourse, stop talking and start acting; hire an attorney and seek resolution.
Your legal team can provide the appropriate advise and merits, costs and likelihood of different outcomes.
Thanks
gene
25 mai 2021 16:42 "Genes Lists via aur-general" aur-general@lists.archlinux.org a écrit:
As an outside observer of this thread, it seems like the time for discussion is over. This talk appears to center largely about opinions on civil litigation.
Actually, this discussion could be important if the responsability of Arch could potentially be involved. Nobody wants the Arch project to be sued or to be liable in some way or another.
aviallon
On 25/05/2021 18:58, Antoine Viallon via aur-general wrote:
25 mai 2021 16:42 "Genes Lists via aur-general" aur-general@lists.archlinux.org a écrit:
As an outside observer of this thread, it seems like the time for discussion is over. This talk appears to center largely about opinions on civil litigation.
Actually, this discussion could be important if the responsability of Arch could potentially be involved. Nobody wants the Arch project to be sued or to be liable in some way or another.
...and, as I said already, it was long established that Arch is not liable or involved in any way.
https://lists.archlinux.org/pipermail/aur-general/2021-May/036236.html
But sure, let's keep talking about ways to obscure trivial patches to mitigate phantom copyright claims. I mean, really?
Alad
aviallon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
25 mai 2021 19:04 "alad via aur-general" aur-general@lists.archlinux.org a écrit:
...and, as I said already, it was long established that Arch is not liable or involved in any way.
https://lists.archlinux.org/pipermail/aur-general/2021-May/036236.html
I guess you are right ¯_(ツ)_/¯
aviallon
On Tue, 2021-05-25 at 19:04 +0200, alad via aur-general wrote:
On 25/05/2021 18:58, Antoine Viallon via aur-general wrote:
25 mai 2021 16:42 "Genes Lists via aur-general" < aur-general@lists.archlinux.org> a écrit:
As an outside observer of this thread, it seems like the time for discussion is over. This talk appears to center largely about opinions on civil litigation.
Actually, this discussion could be important if the responsability of Arch could potentially be involved. Nobody wants the Arch project to be sued or to be liable in some way or another.
...and, as I said already, it was long established that Arch is not liable or involved in any way.
https://lists.archlinux.org/pipermail/aur-general/2021-May/036236.html
But sure, let's keep talking about ways to obscure trivial patches to mitigate phantom copyright claims. I mean, really?
Alad
I beg to differ, as 'trivial' is subjective.
As long as a patch file includes a significant portion or essential part of the upstream code, it constitutes software redistribution, and subjects to Section 4 and 5 of GPLV3. The package maintainer/submitter is responsible.
Then, if AUR or even a TU is involved in anything related to the patch file, such as modifying the patch file, AUR will become liable too.
Filipe Laíns's opinion in your link is actually conforming to the GPL requirement, because he suggested to provide a notice, which should include copyright and warranty at a minimum.
On another note, I often notice that people in this list say a PKGBUILD file doesn't have copyright. IMHO, this opinion is wrong unless AUR'd Term of Services says that the user agrees to assign the PKGBUILD file copyright to AUR while using the service.
Just my two cents. Again, I am not lawyer and never made a cent with law. Instead, law made me lose quite some money.....
Best, Manhong
aviallon
On Tue, 25 May 2021 at 19:27, Manhong Dai via aur-general < aur-general@lists.archlinux.org> wrote:
On Tue, 2021-05-25 at 19:04 +0200, alad via aur-general wrote:
On 25/05/2021 18:58, Antoine Viallon via aur-general wrote:
25 mai 2021 16:42 "Genes Lists via aur-general" < aur-general@lists.archlinux.org> a écrit:
As an outside observer of this thread, it seems like the time for discussion is over. This talk appears to center largely about opinions on civil litigation.
Actually, this discussion could be important if the responsability of Arch could potentially be involved. Nobody wants the Arch project to be sued or to be liable in some way or another.
...and, as I said already, it was long established that Arch is not liable or involved in any way.
https://lists.archlinux.org/pipermail/aur-general/2021-May/036236.html
But sure, let's keep talking about ways to obscure trivial patches to mitigate phantom copyright claims. I mean, really?
Alad
I beg to differ, as 'trivial' is subjective.
As long as a patch file includes a significant portion or essential part of the upstream code, it constitutes software redistribution, and subjects to Section 4 and 5 of GPLV3. The package maintainer/submitter is responsible.
Then, if AUR or even a TU is involved in anything related to the patch file, such as modifying the patch file, AUR will become liable too.
Filipe Laíns's opinion in your link is actually conforming to the GPL requirement, because he suggested to provide a notice, which should include copyright and warranty at a minimum.
On another note, I often notice that people in this list say a PKGBUILD file doesn't have copyright. IMHO, this opinion is wrong unless AUR'd Term of Services says that the user agrees to assign the PKGBUILD file copyright to AUR while using the service.
Just my two cents. Again, I am not lawyer and never made a cent with law. Instead, law made me lose quite some money.....
Just adding in my 2 cents. The lines of code in the patch file is not actual code, but markers.
To explain this to lawyer types that like splitting hairs but don't necessarily understand programming:
The patch program assumes you have the source that needs to be patched handy. This means that you must have obtained the source code to be patched before it can work, and is bound by the license of that software.
The lines in the patch file, while it LOOKS like source code, is actually never executed, and only serves as a marker as to where the changes are to be made. It is completely useless otherwise. The patch program would very happily edit plain text documents that are not code at all, and it does not even understand any programming language in itself.
In short, if you do not have the source code already, the patch won't make it for you. If you do have it, it obviously was distributed to you, and the lines in the patch only refers to a section of code you already have. So, the lines in the patch file are explicitly covered by the copyright of the source that is getting patched.
No one is pulling a fast one, and no source is being distributed without it's original licences.
I may not be a lawyer, but many highly paid lawyers have looked at patch files in great detail for decades, and could not find any reason to sue anyone that has made patch files, ever.
So, my unqualified position is that we are OK to distribute patches to make software work.
Kind regards, -Evert Vorster-
On Tue, 2021-05-25 at 19:57 +0200, Evert Vorster wrote:
On Tue, 25 May 2021 at 19:27, Manhong Dai via aur-general < aur-general@lists.archlinux.org> wrote:
On Tue, 2021-05-25 at 19:04 +0200, alad via aur-general wrote:
On 25/05/2021 18:58, Antoine Viallon via aur-general wrote:
25 mai 2021 16:42 "Genes Lists via aur-general" < aur-general@lists.archlinux.org> a écrit:
As an outside observer of this thread, it seems like the time
for
discussion is over. This talk appears to center largely about opinions on civil litigation.
Actually, this discussion could be important if the
responsability
of Arch could potentially be involved. Nobody wants the Arch project to be sued or to be liable in some way or another.
...and, as I said already, it was long established that Arch is not liable or involved in any way.
https://lists.archlinux.org/pipermail/aur-general/2021-May/036236.html
But sure, let's keep talking about ways to obscure trivial patches
to
mitigate phantom copyright claims. I mean, really?
Alad
I beg to differ, as 'trivial' is subjective.
As long as a patch file includes a significant portion or essential part of the upstream code, it constitutes software redistribution, and subjects to Section 4 and 5 of GPLV3. The package maintainer/submitter is responsible.
Then, if AUR or even a TU is involved in anything related to the patch file, such as modifying the patch file, AUR will become liable too.
Filipe Laíns's opinion in your link is actually conforming to the GPL requirement, because he suggested to provide a notice, which should include copyright and warranty at a minimum.
On another note, I often notice that people in this list say a PKGBUILD file doesn't have copyright. IMHO, this opinion is wrong unless AUR'd Term of Services says that the user agrees to assign the PKGBUILD file copyright to AUR while using the service.
Just my two cents. Again, I am not lawyer and never made a cent with law. Instead, law made me lose quite some money.....
Just adding in my 2 cents. The lines of code in the patch file is not actual code, but markers.
To explain this to lawyer types that like splitting hairs but don't necessarily understand programming:
The patch program assumes you have the source that needs to be patched handy. This means that you must have obtained the source code to be patched before it can work, and is bound by the license of that software.
The lines in the patch file, while it LOOKS like source code, is actually never executed, and only serves as a marker as to where the changes are to be made. It is completely useless otherwise. The patch program would very happily edit plain text documents that are not code at all, and it does not even understand any programming language in itself.
In short, if you do not have the source code already, the patch won't make it for you. If you do have it, it obviously was distributed to you, and the lines in the patch only refers to a section of code you already have. So, the lines in the patch file are explicitly covered by the copyright of the source that is getting patched.
No one is pulling a fast one, and no source is being distributed without it's original licences.
I may not be a lawyer, but many highly paid lawyers have looked at patch files in great detail for decades, and could not find any reason to sue anyone that has made patch files, ever.
So, my unqualified position is that we are OK to distribute patches to make software work.
Kind regards, -Evert Vorster-
With all due respect, while the case quoted below says otherwise, it is very possible that your opinion is confirmed in other nations/courts/cases.
'A patch is nearly an exact copy of the main file of the computer program that contains the part of the code that interacts with the security device.'
https://law.justia.com/cases/federal/district-courts/FSupp2/128/1027/2298546...
Best, Manhong
Em maio 25, 2021 15:18 Manhong Dai via aur-general escreveu:
With all due respect, while the case quoted below says otherwise, it is very possible that your opinion is confirmed in other nations/courts/cases.
'A patch is nearly an exact copy of the main file of the computer program that contains the part of the code that interacts with the security device.'
https://law.justia.com/cases/federal/district-courts/FSupp2/128/1027/2298546...
This thread has run it's course perhaps some 50 emails ago. Let's end this. I don't want to have to emergency moderate the list. Thanks for the comprehension.
Regards, Giancarlo Razzolini
On Tue, 25 May 2021 13:27:07 -0400, Manhong Dai via aur-general wrote:
I beg to differ, as 'trivial' is subjective.
In an ideal world nobody would care about vanity, glory and/or money and all would be happy, if intellectual property would be completely unimportant. Often the wording of a law can't fulfil the spirit of a law. However, to distinguish between different approaches I do understand, that an upstream developer is in favour of a renamed fork, but OTOH seemingly "Scots have more words for snow than Inuit". Giving each slightly modified distributed software another name, might not necessarily help to distinguish between really important different approaches.
On Tue, 25 May 2021 19:04:33 +0200, alad via aur-general wrote:
https://lists.archlinux.org/pipermail/aur-general/2021-May/036236.html
"The Arch Linux project does not distribute your software."
Probably hairsplitting, but in some kind of way it does.
Anyway, IMHO this isn't the point.
Word for word CumEx was legal, just by the spirit of the laws it wasn't.
IMOH the downloadable snapshot complies the spirit of the GPL and IMHO this is the important point.
On 25/05/2021 21:01, Ralf Mardorf via aur-general wrote:
On Tue, 25 May 2021 19:04:33 +0200, alad via aur-general wrote:
https://lists.archlinux.org/pipermail/aur-general/2021-May/036236.html
"The Arch Linux project does not distribute your software."
Probably hairsplitting, but in some kind of way it does.
No, it doesn't. Now please comply to Giancarlo's request. Thanks.
Alad
Anyway, IMHO this isn't the point.
Word for word CumEx was legal, just by the spirit of the laws it wasn't.
IMOH the downloadable snapshot complies the spirit of the GPL and IMHO this is the important point.
On 2021-05-21 11:54, Manhong Dai via aur-general wrote:
I know I will be the minority in this list. However, this statement doesn't sound right to me if the patch file is applied to the original source code.
Unlike the file PKGBUILD, a patch file constitutes a modified source code because it does include some original code. No matter whether the modification is for use, or operation, or just even a typo fix, GPLV3 section 5 "Conveying Modified Source Versions" [1] doesn't distinguish them.
I had a similar experience in terms of the AUR package SGE. I put my source code modification into a single patch file and put it to AUR git. Without my modification, SGE won't work with latest Linux anymore. However, due to an AUR website bug confirmed by a TU, the package was taken over without any emails sent to me.
After a lot of back and force with the second maintainer, I finally gave up re-owning the package or making the software better within AUR. Instead I asked the second maintainer to add my name to the single patch file so I get the credit I deserve. However, the second maintainer denied that. He split the patch into many small patch files without my name in any of them, and insists that it is enough to have my name as the first AUR package maintainer. Then I asked him to remove my code modification, also was denied.
Then I tried to ask TU to remove the package many times, all TUs denied my request, except the last TU deleted all those small patch files after he understood this is a serious copyright violation issue.
Here is my understanding about those copyright conflicts. If you modified any source code, then GPL license will be applied, you have to copy the original copyright without any modification and then add yours, just as section 4 in GPL v3 says "You may convey verbatim copies of the Program's source code as you receive it"
It is understandable that many AUR maintainers, or programmers like myself, don't know the details and often violates some copyright law more or less. We are lucky that most upstream programmers don't mind it. But, should such issue arise, I would do my best to make the upstream programmer happy or just find another alternative software.
I know I am the minority in this list because the AUR SGE got two up- votes ironically after it didn't work anymore, and the second maintainer is even promoting the binary version based on my modification on some other repos. But, life is too short, I can live with it. I am writing this email because I just hope my painful experience can help this list know copyright better.
I think that's a valid angle to bring up!
FWIW, https://en.wikipedia.org/wiki/ROM_hacking#Distribution and https://en.wikipedia.org/wiki/Unofficial_patch#Law may be of interest. If a litigious company like Nintendo hasn't gotten courts to stamp out romhack patches I'm not sure this little software project poses any threat...
The upstream developer merely has an axe to grind against those that don't take openly-available code and use it in ways they intend. To that end, beating their chest with vague legal threats is an attempt at dominance rather than any pursuance of legal justice.
On Fri, 2021-05-21 at 09:50 -0700, Brett Cornwall via aur-general wrote:
On 2021-05-21 11:54, Manhong Dai via aur-general wrote:
I know I will be the minority in this list. However, this statement doesn't sound right to me if the patch file is applied to the original source code.
Unlike the file PKGBUILD, a patch file constitutes a modified source code because it does include some original code. No matter whether the modification is for use, or operation, or just even a typo fix, GPLV3 section 5 "Conveying Modified Source Versions" [1] doesn't distinguish them.
I had a similar experience in terms of the AUR package SGE. I put my source code modification into a single patch file and put it to AUR git. Without my modification, SGE won't work with latest Linux anymore. However, due to an AUR website bug confirmed by a TU, the package was taken over without any emails sent to me.
After a lot of back and force with the second maintainer, I finally gave up re-owning the package or making the software better within AUR. Instead I asked the second maintainer to add my name to the single patch file so I get the credit I deserve. However, the second maintainer denied that. He split the patch into many small patch files without my name in any of them, and insists that it is enough to have my name as the first AUR package maintainer. Then I asked him to remove my code modification, also was denied.
Then I tried to ask TU to remove the package many times, all TUs denied my request, except the last TU deleted all those small patch files after he understood this is a serious copyright violation issue.
Here is my understanding about those copyright conflicts. If you modified any source code, then GPL license will be applied, you have to copy the original copyright without any modification and then add yours, just as section 4 in GPL v3 says "You may convey verbatim copies of the Program's source code as you receive it"
It is understandable that many AUR maintainers, or programmers like myself, don't know the details and often violates some copyright law more or less. We are lucky that most upstream programmers don't mind it. But, should such issue arise, I would do my best to make the upstream programmer happy or just find another alternative software.
I know I am the minority in this list because the AUR SGE got two up- votes ironically after it didn't work anymore, and the second maintainer is even promoting the binary version based on my modification on some other repos. But, life is too short, I can live with it. I am writing this email because I just hope my painful experience can help this list know copyright better.
I think that's a valid angle to bring up!
FWIW, https://en.wikipedia.org/wiki/ROM_hacking#Distribution%C2%A0and https://en.wikipedia.org/wiki/Unofficial_patch#Law%C2%A0may be of interest. If a litigious company like Nintendo hasn't gotten courts to stamp out romhack patches I'm not sure this little software project poses any threat...
The upstream developer merely has an axe to grind against those that don't take openly-available code and use it in ways they intend. To that end, beating their chest with vague legal threats is an attempt at dominance rather than any pursuance of legal justice.
Very interesting links! I learned a lot. Here is my understanding after reading the two links.
In terms of the first link about 'Rom Hacking', I would guess, if the Rom patch tool uses something like dd, especially if it is something like 'dd seek=', then the Rom patch doesn't use anything from the original Rom. However, a patch file generated by diffing source code files is very different as it does use the original source code.
In terms of the second link 'Unofficial_patch', the three cases are all about if the user can modify a system he owns, more like a 'right to fix' case, instead of how a user can distribute a modified source code. In the Nintendo case, Game Genie sells a tool to modify Nintendo, but I would guess the tool doesn't include any code from Nintendo.
Going back to the initial issue about this email chain, I would guess the AUR maintainer can use 'dd' instead of 'diff'. But this will become ridiculous and I personally won't do that at all, no matter I am the package maintainer or the original programmer.
Just my two cents. I know nothing about law. If someone end up in jail and point a finger to me, all I do is to visit him once to make fun of him. :)
Best, Manhong
aur-general@lists.archlinux.org