Fix Copyrights

[Shamar]

After the recent reintroduction of the missing 9front's copyright statements to the libsec's code at 81d25a4063b3ae76e993fbab3a06661a2ca68e00, it has been jokingly pointed to me that "I'm not worthy", since none of my 6 months of commits have left a sign in Harvey. :-)

After a grep confirming the fact, I've noticed that my port of zlib has been removed and the console has been put back in kernel (removing the user-space filesystem that I wrote in 2015). Also I know that my contributions to the continuous integration and the Coverity integration cannot be evident into the sources.

However looking around I've noticed that at 066eb48ac5025570bf5a63a8ef24da4b35f4cbc2 my name and copyright has been removed from two new files that, despite simple in itself, were part of two non trivial contributions at cf801d01f503fc340efd6d0ca97a4921b24b447c and 5616a46061a3a6ea84375e0c34dc8c9dfe9ee87c that moved read(2) and write(2) to user-space while cleaning up the kernel. I realize now that I should have probably amended the copyright of all the files touched by the change, to avoid filling this issue now.

Since I can't find the AUTHORS file referenced by @rminnich in the commit message at 066eb48ac5025570bf5a63a8ef24da4b35f4cbc2 it's clear that, actually, an AUTHORS file cannot replace proper copyright statements in the code (as wisely predicted by Ron himself in the mailing list).

I do not remember if I have contributed other non trivial changes to Harvey (that have not been reverted or removed). For example I do not know if the changes at 401284bef0d6ae6d240e1d27dece8a5165011316 or at 4392ad33cbf6ab719c02c535158b01014d17ec69 were trivial or I had to add my copyright to the files modified. I was pretty naive back then, but I guess that if the change is not trivial, the copyright holds even if not noticed in the license's header, so it would probably be better to make it explicit.

Nevertheless, since my name has gone in libc, it's possible that it happened to other contributors too and while I'm not a lawyer, I guess this should be fixed. Unfortunately I have no time to check them all.

As for me I prefer the copyright to be put in the files I contributed to, as suggested by the Ron back in 2015.
Please do not use an AUTHORS file for me, since it has proven to break. I'd like my humble contributions to be noticed in source code just like the others.

Expected behavior

Contributors' names and copyrights are preserved in the code base.

Actual behavior

My name and copyright have been removed from the code, without removing the code or reverting the changes. This might have happened to others.

Steps to reproduce

• clone the repository
• cd to the repository
• grep giacomo@tesio.it -wnr sys/src/libc/
• find | grep AUTHORS

[elbing]

Thanks for the info, an explanation is in PR #699 . We're sorry you could feel bad about this, the reasons weren't from bad feelings, just for preserving the work of all of us, even you, for the future in an homogeneus form and avoiding conflicts, that's all. We copyrighted again write.c and read.c.

Also, your work is in history log of the repo, for all of those who want to learn from it.

Thanks!

[Shamar]

Thanks Álvaro for your prompt response.

I'm a bit surprised by the new policy from Software Freedom Conservancy as it seems in direct contrast with both common practice and with the GPL howto by the Free Software Foundation.
It has the sad effect to disincentive any cleanup on free software, as it's often really time consuming to remove code on a complex application. But at the end of the day, this might explain a lot about the exploding complexity in the free software.

But, don't worry, I know it was just an unfortunate mistake! ;-)

BTW, since it's the only place where authorship is preserved in Harvey I analyzed the git log with the command

git log --author=giacomo@tesio.it --pretty=format:"%h"|xargs git show|less

and found that other copyrights of mine were removed.

My copyright has gone in sys/include/libc.h (copyright amended at 45d24cf0c5fee8a42b7d3cff6811b6fac446b910 and removed at 4c391803a791cfcae8395bd04f4cb21d87df4b0d), in sys/src/9/port/portclock.c and sys/src/9/port/sysproc.c (copyright amended at 45d24cf0c5fee8a42b7d3cff6811b6fac446b910 and removed at f71bee0356db4a2cbe45a589f9d7daced7ddff25) and in sys/src/libc/port/lock.c (copyright amended after lockt(2) introduction at 8896d97d3dec4c5cbfd865249a0ebf6b3ba020c2 and removed at 066eb48ac5025570bf5a63a8ef24da4b35f4cbc2).

Please put back these too.

Also, before closing the issue, you might use the command I provided to check if other contributors' names have gone.

Thanks!

[elbing]

Is there any reamaning code from you in libc.h, portclock.c and sysproc.c? The copyrighted code was removed with the copyright itself. No offense. If any of it is still there we'll be glad to remove it for avoiding issues. Also the policy is not from sfc, was agreed for the project. For avoiding things like this, precisely.

[elbing]

Other authors can claim individually their issues if they could happen when they want. Every case will be reviewed separately.

[Shamar]

No offense, Álvaro, really. I just open this issue to help fixing a little mistake! ;-)

As far as I can remember I agreed to contribute that way (I even explicitly asked what to do), and my contributions were accepted that way by the project. As far as I know, what was later agreed for the project cannot be applied retroactively.

As for libc,h, all cleanups I did are still there (see for example const qualifiers or the abort macro?). As for libc/port/lock.c the lockt function is still there. As for kernel's code I can suppose you still have 64 bit ticks that I introduced.

I'm not against removing my contributions (you can remember that I'm always for simplifying things!), but if you decide to go toward this path I have to ask you to git revert each and every of my commits referencing this issue in the commit message, so that it will be clear from the git log of why that changes has been reverted and why they cannot be added back.

This way my copyrights will be effectively gone, and we will be sure that, 6 month from now, my changes wont be applied again with an "Harvey OS" copyright notice.

[elbing]

Well, seems the only way in what harvey could stop worrying you. So we'll do so. Thanks for the info!

[elbing]

Well, after a reviewing, you claim for copyright in libc.h, sysproc.c, portclock.c and removing lockt/or keeping adding copyright. For being clear and don't back over this in future. Any other claim?

[Shamar]

Álvaro, I'm sad, really sad. You don't need to worry about me more than any other contributor.

But given your attitude here I see only two possible solution:

1. Add back the copyright notices where they were removed (libc.h, sysproc.c, portclock.c and lockt).
2. git revert each of the 175 commits I contributed to Harvey referencing this issue and documenting somewhere that those changes cannot being reintroduced.

Initially I thought it was a simple mistake easy to fix with the first approach. But given what I've read here, I strongly prefer the second option: with the first I will keep holding the copyright on my contributions to Harvey, and I really do not want to.
Not because I regret the work we did together. It has been a great time. And even this unexpected outcome teach me a new lesson.

But I cannot trust you anymore.
You might accidentally remove the copyrights again and I would never notice it. I do not monitor Harvey's sources. This issue has been pointed to me by a friend I suggested to try Harvey as it's more stable than my own Plan 9 fork. Months after the facts.

And since, just like you, I don't want to back over this in future, I think reverting my commits is the only safe solution. That way, I will have no copyrights to claim on the Harvey's code and the git log will inform new contributors about this sad mess.

So please, just do as you said.

[0intro]

I think a reasonable solution to this issue for all of us would be to write a CONTRIBUTORS file listing all the people (with associated e-mail addresses) who contributed to Harvey. This is what most open sources projects do (see Go or Linux for example). What do you think @Shamar?

[Shamar]

David, the CREDITS file in Linux works because of Linus. It's a matter of trust. Here a CONTRIBUTORS file has been removed at some point. So it's not reliable, here.

The few copyright notices that I added in 2015, were not reliable either: they have been removed once, they might be removed again.

You can see that we need a more reliable solution to this issue.

The best way is to simply git revert each of my commit in reverse order and document somewhere that those changes cannot be applied again, not just because of this issue, but because Harvey does not need them. As far as I can see, something similar happened before, at 279effbf562faf51e1a77035da1ad6146b3870ab, at 23ecd7506879007d15c5cf42b76e6fb0ee7adadc and even with the removal of some system call, like sysr1. So really, where is the problem? How hard can it be? If the contributions we are talking about are so trivial that they do not deserve a copyright notice, it should be very easy to git revert them! :-)

A more complex but reliable solution could be to add back the copyright notice that I added in 2015 and to make my copyrights explicit in each file that my non trivial commits modified. Few lines similar to the ones that were added to libsec to fix the 9front's copyright would do. The redundancy should ensure that my copyrights wont completely disappear again in the future.

Still I prefer the git revert solution. It's simple and clear cut. And until someone do not try to add the same changes under a different copyright, we will all be fine.

[dancrossnyc]

Ok.

Giacomo's commits have been removed from Harvey.

Closing this issue.

[Shamar]

@dancrossnyc unfortunately while none of my commit is present in Harvey after your git rebase, some code I contributed is still there.

For example the changes I contributed at 401284bef0d6ae6d240e1d27dece8a5165011316 and 4392ad33cbf6ab719c02c535158b01014d17ec69 are still there in both libc.h and in the various other files modified (eg in libc's runestrlen.c, strncat and so on... in kernel's portdat.h, alarm.c and so on...).

This is strange, actually, because those commits are still present on some files in master but not in others.

For example I'm listed among the authors of runestrlen but not in strncat despite the fact they were both modified by the same commit. Same thing for the changes at 4392ad33cbf6ab719c02c535158b01014d17ec69: no commit but the code is still there.

I suppose that you accidentally squashed some of my changes into others during the git rebase.

[dancrossnyc]

Yes, in some cases types were widened or code was added or changed for const-correctness. Those are changes that can only be written one way; there is nothing original or significant in their authorship and they cannot reasonably be credited to a single author. Would you seriously suggest that we cannot add a 'const' qualifier to a pointer argument of a function because you did it at some point? That would be rather absurd, don't you think?

Your commits were removed, as you requested. If the effect of those commits were replicated elsewhere, then given that that is the only way to replicate them, there's nothing anyone can do about that.

You are no longer listed as a contributor to Harvey on the main page; whether the effect of trivial changes persists is independent of whether you ever authored similar code.

As for the two files you reference, it is unclear to me why you are listed as a contributor on the one; perhaps this is a github UI issue. If you look at both the blame listing and file history, you are not mentioned anywhere. As I mentioned, the other changes you refer to are trivial changes that can not reasonably be written any other way and you cannot command others to use narrower types or not add const correctness.

[Shamar]

Are you saying this wasn't accidental?
If so, can you please list all contributions of mine that you squashed in your commits?

Guys, I think you should really ask a lawyer what "trivial change" means.
Maybe people @conservancy can help you here.

My bet is that changing the signature of over 120 functions (in over 135 files) and increasing (and fixing) processor's clock and scheduling precision in the kernel do not constitute "trivial changes" without "significant authorship".
The Harvey's mailing list proves that those changes were entirely my own ideas (see here and here).
Also they do not match any standard (as Harvey's libc is non-standard) and no previous Plan 9 fork introduced them.

If you feel you can't remove those changes because they are important for Harvey, you can still add my copyright statement to each of modified files.

But, if you really don't want my contributions... you don't want my contributions.
That is, you have to find alternative solutions to the problems that they addressed.

Tertium non datur.

Indeed, if you just produce changes that can be obtained by trivial edits of my patches, you are just hiding my copyright. Again.

Please, try to understand why it is important to be serious about contributors' copyrights.

It's not just a matter of Free Software's ethics: when you use somebody else code without proper copyright statements, you pose a threat to their own right to use their code elsewhere.

I'm sure you are all good people, and you will never pretend that you wrote my patches.

But, as this thread proves, things changes. It's important that no future maintainer of Harvey can try to sue me because I applied those changes elsewhere with a different license.

So please, reopen this issue and fix it for real.

[dancrossnyc]

Are you suggesting that we cannot add const qualifiers to pointer arguments because you may, at some point in the past, have done something similar? Can you think of another way to effect that change without adding a const qualifier?

The "alternative solution" we pursued was to go through libc.h and add const qualifiers to functions that can take them. You cannot claim ownership of that because it was not done by you, even if at some point in the past you had done something similar. You may assert otherwise, but there it is.

Your interpretation was wrong: we did not keep anything you did, intentionally or otherwise.

I will not reopen the issue. If you feel you have a case, by all means contact a lawyer.

[dancrossnyc]

And let me be very clear about the process we followed:

We removed all of your commits. We then went through and audited libc etc adding e.g. const qualifiers, without consultation of your work, which had been removed by that point.

[Shamar]

Dan, do you really need hints from me?
And why did you squashed all this "original" work with other commits, if you did it from scratch? And... why I'm still listed among authors in some libc files if you changed the signatures from scratch?

Also you said nothing about the scheduler's fix.
Are you saying you did it from scratch and obtained the exact same patch, there too?
What a happy coincidence!

Can you please list all of my contributions that have been accidentally replicated verbatim after removing my copyrights? I didn't check each commit carefully because I thought you were in good faith.

You know I can't sue the Software Freedom @Conservancy. I feel betrayed by their silence here, given what Karen wrote me one year ago. You got that mail too.
But I can't afford to play their own game.

I just hoped in your honesty.

[dancrossnyc]

We removed your commits at your request.

Nothing was squashed. We didn't carry any of your code forward. You asked, "can you please list all of my contributions that have been accidentally replicated verbatim after removing my copyrights?" Sure: that's easy. None. Your contributions were minimal.

We didn't have to do any of this, but we did -- at your request -- to be nice. It took a team of volunteers five weeks of work. I didn't even do any of it, but I felt that we should give you the courtesy of letting you know that it had happened.

We then added const in some places (but not everywhere that had been in your patch, if you care to compare what's in Harvey now to what you keep pointing to: e.g., the argument to _assert(), which you made const, but we did not) and widened some types (but didn't keep any of your other clock changes; your tk2ms() macro was after all just a copy of the TK2MS macro on the very next line of the same file, and those functions you authored in portclock.c were not carried forward, and functions that you removed, such as 'ms2tk' were reintroduced). You certainly cannot assert copyright over the idea of qualifying a pointer argument 'const' (importantly, ideas cannot be copyright), particularly if the ISO C standard already does that for many functions, and you don't get a monopoly on representing time as a 64-bit quantity (especially since the year 2038 problem has been known since Unix adopted a 32-bit time_t).

And as I recall, I was the one who found the problem in the scheduler on that conference call two years ago.

The supreme irony of course is that the commits you keep pointing to didn't include copyright statements. I personally find it odd that you feel you can assert copyright over e.g. libc.h, which has probably been modified by on the order of 100 or so contributors over the years (and those contributors made far more substantial changes than you ever did to Harvey's version -- indeed, none of your contributions remain in the Harvey version. As I've said repeatedly, they were written out). Given that most of those changes merely bring Harvey in line with the ISO C standard, your assertions are just downright bizarre.

We hoped for your honesty too, Giacomo. It now appears that you are trying to bully a project into giving you credit for work you did not do.

https://www.softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html http://digital-law-online.info/lpdi1.0/treatise9.html

[Shamar]

It now appears that you are trying to bully a project into giving you credit for work you did not do.

No. I'm just trying to protect my own current and future use of those changes.

Indeed I asked you to remove them.

Fine. Lesson learned.