LICENSE: Add my copyright, as the author of ~30% of commits to the project. #4363

pfalcon · 2018-12-17T09:24:25Z

No description provided.

pfalcon · 2018-12-17T09:30:05Z

So, number of commits alone can't be fully adequate measure of "substantial contribution". Actually, no single metric could be. Of all single metrics, number of commits is probably giving the most insight.

I actually was keen to make other measurements, e.g. percentage of active lines authored by me, and number of changes lines (then apparently to py/ and extmod/, because number of changed lines in various HALs and BSPs can easily overshadow anything), but I don't see a tool which readily does that. As usual, there's a gazillion of tools which do "something", and it's not exactly clear what that something is. All in all, looking that, I figure I spend time which could better be spent on something else, and just submit this patch for starters.

pfalcon · 2018-12-17T09:38:21Z

Also, actually adjusting the figure from 40% to 30%. The 40% was based on one-year ago stats, plus also was based not on total no. of commits, but on the number of commits from 2 largest contributors.

My current stats show:

$ git log | grep "Author:" | grep "Sokolovsky" | wc
   2876   11504  161016
$ git log --oneline | wc
   9823   85499  663136

nickovs · 2019-01-18T14:29:05Z

It seems entirely reasonable for you to have credit for your work. That said, the license file ought to also be updated to reflect Damien's ongoing work, since the proposed new version of the file would likely be read as meaning that you had taken over the project entirely in 2014.

Strictly speaking, in the absence of explicit copyright assignment by every contributor, the copyright of any given bit of code lies with the author of the code not at the project level, the file level or even the line level but at the token level. This is why tools like cregit exist (see this presentation for details if you are not familiar with cregit). As a result the list of copyright owners should really include everyone who's ever had a PR accepted and who's code has not subsequently been removed or completely rewritten. A common way to deal with this is for there to be a Copyright file distinct from and referenced by the License file, with the copyright file listing all of the contributing authors, usually with the key maintainers and major contributors sorted to the top.

IMHO, I think that updating the Micropython copyright information to reflect that this is now a larger collaborative project rather than the work of one person would be a fine thing. Clearly the major contributions from @pfalcon should be recognised as part of that but I think that there is more to do than this one line change.

pfalcon · 2019-01-18T14:33:45Z

Well, I can reasonably care about just my stuff, that's why there's just one line change. There's a maintainer to care about all the other lines.

Otherwise, it's established practice to credit significant contributors explicitly. The exact contribution list and credits can be indeed found in "git log".

dpgeorge · 2019-01-24T08:25:18Z

Thanks for the discussion. The LICENSE file does need updating.

As a result the list of copyright owners should really include everyone who's ever had a PR accepted and who's code has not subsequently been removed or completely rewritten. A common way to deal with this is for there to be a Copyright file distinct from and referenced by the License file, with the copyright file listing all of the contributing authors, usually with the key maintainers and major contributors sorted to the top.

This is more like the direction I'd want to take here.

With a top-level LICENSE file it's not really clear what it applies to with a large project and lots of contributors, and also lots of submodules and libraries.

Instead, I'd rather individual copyright be listed at the file level, or a full list explicitly given, and the top-level LICENSE file be used to describe (and point to) all the kinds of licenses that appear in the whole project. The latter is definitely needed because at the moment it's hard to know exactly what licensing conditions there are when using a given port (eg if berkeley-db is used then UC Berkeley must be mentioned in advertising material).

My proposal would be:

Update the top-level LICENSE file to mention all licenses used in the repository (with MicroPython's MIT first).
For the copyright in the LICENSE file pertaining to MicroPython itself, either 1) write "Copyright 2013-2018 The MicroPython Developers" and leave it at that (individual names can be found elsewhere), or 2) write "Copyright 2013-2018 The MicroPython Developers, as listed in the accompanying AUTHORS file", and then maintain such an AUTHORS file.

stinos · 2019-01-24T08:29:45Z

+1 for this proposal. Also because having to read code diffs where copyrights get added/changed is uniteresting. Git blame does that already, and way better. Which also makes me wonder how necessary it is to keep the date in there, is that something legally required?

pfalcon · 2019-01-24T08:38:27Z

For the copyright in the LICENSE file pertaining to MicroPython itself, either 1) write "Copyright 2013-2018 The MicroPython Developers" and leave it at that (individual names can be found elsewhere)

I'd say this is OK, but then this single-line patch would indeed turn into pretty boring long patch to add/update my copyrights on many files that I missed (as I concentrated on other things when I had commit access). Actually, this PR was exactly an attempt to avoid preparing/maintaining such a boring patch.

pfalcon · 2019-01-24T08:49:57Z

and the top-level LICENSE file be used to describe (and point to) all the kinds of licenses that appear in the whole project. The latter is definitely needed because at the moment it's hard to know exactly what licensing conditions there are when using a given port (eg if berkeley-db is used then UC Berkeley must be mentioned in advertising material).

Good catch on libs like berkeley-db. And the reason why I called to avoid license zoo (for content written purposedly for MicroPython, i.e. any tool written should be just MIT licensed), and 100% avoid adding any GPL content, even if it's just a tool. And consequently, I'd say that top-level LICENSE should indeed list licensing for any code which may go inside a MicroPython binary, but not list any possible different licenses for tools/ and similar dirs (e.g. licenses for similar support scripts in imported/submodule'd projects).

dpgeorge · 2019-01-24T09:14:31Z

Which also makes me wonder how necessary it is to keep the date in there, is that something legally required?

Copyright expires after a certain number of years (eg 70, or 120) so it's important to list the year of creation of the works.

but then this single-line patch would indeed turn into pretty boring long patch to add/update my copyrights on many files that I missed

In such a case there would need to be a rule as to when it's fair to add a copyright line at the top of the file, eg when there are more than 25% of the lines authored by one individual.

And consequently, I'd say that top-level LICENSE should indeed list licensing for any code which may go inside a MicroPython binary, but not list any possible different licenses for tools/ and similar dirs (e.g. licenses for similar support scripts in imported/submodule'd projects).

Yes that makes sense. But then it would be good to add a one-liner to the LICENSE (at the end) along the lines of "Additional licenses may apply to support tools and scripts."

pfalcon · 2019-01-24T09:22:04Z

In such a case there would need to be a rule as to when it's fair to add a copyright line at the top of the file, eg when there are more than 25% of the lines authored by one individual.

Well, to remind, lack of formal rules (your no-desire to set them up) was the reason of the current project org situation. So yep, it's a bit strange to hear about formal rules now. I don't think "25% of the lines authored" would cut, the usual rule is "substantial contribution", which is either effectively writing it initially (also includes turning a many-lines placeholder into something really working), or adding something which takes a noticeable (also to others) algorithmic and/or debugging work - all surveyed and acked (or not acked) by project maintainer(s).

nickovs · 2019-01-24T14:00:23Z

I'm +1 on separating the license, copyright notice and authors at the top level and then including authors at a per-file level. I would caution against having a firm, written rule for what constitutes a substantial contribution for many of the reasons that @pfalcon just gave.

Regarding specifying licenses, it would make sense to at least mention the licenses for included components in the top level license file, as well as including the full license for the MicroPython code itself. Making mention of these at the top level makes it easier for users to find them and having the policy that you will do so helps ensure that people are aware when additional license requirements might creep in (which provides a little back-pressure against "license zoo"). I would also love to see SPDX license specifier tags in such files to make it easier for users to use tools to examine licenses in projects they use. Once this discussion is settled I am happy to submit a PR to add SPDX tags in the appropriate places.

dlech · 2019-01-24T17:18:56Z

My proposal would be:

1. Update the top-level LICENSE file to mention all licenses used in the repository (with MicroPython's MIT first).

I would like to suggest the debian/copyright file format for this (saves time vs. coming up with our own policy/specification and makes life easier for me debian package maintainers).

I am happy to submit a PR to add SPDX tags in the appropriate places.

👍 for SPDX, but I do know that in the Linux kernel, only the original author is allowed to make the patch that changes the license header (for legal reasons).

pfalcon · 2019-01-31T09:07:47Z

For the copyright in the LICENSE file pertaining to MicroPython itself, either 1) write "Copyright 2013-2018 The MicroPython Developers" and leave it at that (individual names can be found elsewhere)

@dpgeorge, So, do you intend to make this change?

pfalcon · 2019-03-29T07:40:21Z

Ok, so this PR is 3 months old by now. Nothing in the discussion was done soon after discussion, or before the 1.10 release, or at all so far. @dpgeorge, please merge this PR, then feel free to make rest of changes, if any, at your convenience. Thanks.

dpgeorge · 2019-05-17T08:17:36Z

Ok, since I didn't find time to make comprehensive changes to the LICENSE file (even though there were excellent efforts by @dlech in #4432), I'm happy to just merge the change here as a "temporary" solution as long as @pfalcon agrees that these copyright lines can be eventually removed and replaced with something like "Copyright 2013-2019 The MicroPython developers". Is that acceptable?

pfalcon · 2019-05-17T11:10:30Z

I'm happy to just merge the change here as a "temporary" solution as long as @pfalcon agrees that these copyright lines can be eventually removed and replaced with something like "Copyright 2013-2019 The MicroPython developers". Is that acceptable?

I'd appreciate merging this, yeah. Regarding 2nd part, I have to admit that I've come to a feeling, that no, I don't like and don't agree to that. The reason is that, using the rhetoric of author of some texts which got popular at recent times, it would be an act of dehumanizing the Open Source software development.

That said, I'd suggest to treat those as separate issues with separate reasoning (and discussion). The reasoning behind the change here was presented above - I'm the author of ~30% commits to the project, and designer of some subsystems and facilities in MicroPython which are now taken for granted as natural and integral parts of it, so I'd like to be clearly presented as such.

dpgeorge · 2019-05-17T13:29:23Z

I have to admit that I've come to a feeling, that no, I don't like and don't agree to that.

In that case we need to have a longer discussion about this. I don't want merging this PR to be a complete blocker to actions that might be taken later on (like I discuss above).

so I'd like to be clearly presented as such.

I was under the impression that #4787 was intended to take care of this, as you stated in #4363 (comment)

pfalcon · 2019-05-19T11:19:10Z

@dpgeorge

In that case we need to have a longer discussion about this. I don't want merging this PR to be a complete blocker to actions that might be taken later on (like I discuss above).

But what seems to be blocker is the lack of response and activity on this pretty important and yet simple matter. I said it's ok from my side on Jan 24, I pinged you on Jan 31, but there were no actions or even responses, which raises questions if there're reservations and double-think on your side.

so I'd like to be clearly presented as such.

I was under the impression that #4787 was intended to take care of this, as you stated in #4363 (comment)

Well, those patches were just routine updates of per-file copyrights which I didn't do when I had commit access because I concentrated on more technical things and kept book-keeping things like that in backlog.

Anyway, don't let me be the weakest link here.

Ok, since I didn't find time to make comprehensive changes to the LICENSE file (even though there were excellent efforts by dlech in #4432), I'm happy to just merge the change here as a "temporary" solution as long as @pfalcon agrees that these copyright lines can be eventually removed and replaced with something like "Copyright 2013-2019 The MicroPython developers". Is that acceptable?

Yes, please merge this patch, and I assume the reason for not having made the change of "Copyright 2013-2019 The MicroPython developers" in the LICENSE file since January is the desire to prepare it somehow "better" than just to make that change (e.g. to accompany it with additional stats). So, I assume such a future change will be for better, and agree to it. Thanks.

dpgeorge · 2019-05-21T07:34:35Z

So, I assume such a future change will be for better, and agree to it.

It's a bit hard to agree to "any future change for the better", since "better" is subjective. So probably the future direction should be spelled out now and agreed to now.

But apart from that, one issue with adding your copyright to the top-level LICENSE file is that it would (I assume) then apply to all files in the repo that don't have an explicit license. Eg ports/stm32/boards/pllvalues.py. That's obviously not a true reflection of the copyright of such files.

pfalcon · 2019-05-21T11:18:00Z

But apart from that, one issue with adding your copyright to the top-level LICENSE file is that it would (I assume) then apply to all files in the repo that don't have an explicit license.

Well, it's probably possible to find a file in the repo without copyright which wasn't created, and not/barely touched by you. So, it's a bit looking for breadcrumb issue. I look at the top-level LICENSE as a license/copyright overview file, listing major contributors (as copyright holders).

jimmo · 2019-05-21T11:48:47Z

Please see #4800 for a simple and concrete suggestion for the LICENSE file. The intent here is to clarify the overall project copyright and licensing, and making it clear that any author can claim copyright over their own individual work at a per-file level.

pfalcon · 2019-05-23T08:20:15Z

@dpgeorge: Ping.

dpgeorge · 2019-05-24T09:52:48Z

Well, it's probably possible to find a file in the repo without copyright which wasn't created, and not/barely touched by you.

But if it was added without a copyright/license then the top-level LICENSE file should implicitly apply to it (if said file was added after the top-level LICENSE was added). And changing LICENSE now is kind of like rewriting the copyright history of all those files.

I look at the top-level LICENSE as a license/copyright overview file, listing major contributors (as copyright holders).

There's a difference between an overview/summary of all the licenses/copyright holders in the repo (see eg #4800), and having a license that is generally applicable to the code in the repository. The latter is currently what LICENSE is.

All in all this is a pretty complex issue, and since is it's hard to undo some of these decisions once taken they should be well considered.

In the end there needs to be a way to fairly attribute contributions (eg done by #4787), make sure that everything in the repo has a well defined license/copyright (currently done by the LICENSE file as a default), and provide a way for users to understand and comply with the various licensing (eg #4432, #4800).

pfalcon · 2019-05-24T10:11:33Z

But if it was added without a copyright/license then the top-level LICENSE file should implicitly apply to it (if said file was added after the top-level LICENSE was added). And changing LICENSE now is kind of like rewriting the copyright history of all those files.

But it wasn't "good" in the first place. And that's the reason why "enterprisey" project are paramount about each and every file to have a copyright and licensing blurb. And it seems that at certain popularity (== accumulated controversy), any project needs to pay attention to that. So, the right way to resolve that appears to be: 1) be absolutely strict about licensing/copyright; 2) to track dow 6D40 n any unlicensed/uncopyrighted files and add relevant copyrights (with proper communication to assumed copyright holders.

All that's still orthogonal to the issue of this patch, and shouldn't influence/block it too much.

and having a license that is generally applicable to the code in the repository. The latter is currently what LICENSE is.

Again, my pragmatic treatment is that top-level LICENSE applies to the whole project. And I seek proper recognition of my efforts on the whole-project level, as unalienable part of the license. The fact that formally top-level LICENSE applies to each file not explicitly stated otherwise, is a low-level, formal, procedural issue, which of course should be resolved too, and proposal for that is outlined above.

In the end there needs to be a way to fairly attribute contributions (eg done by #4787), make sure that everything in the repo has a well defined license/copyright (currently done by the LICENSE file as a default), and provide a way for users to understand and comply with the various licensing (eg #4432, #4800).

Right. This patch is however orthogonal to those issues, and as I stated, it's not my intention to interfere with resolving or evolving these matters further, only to capture the status quo.

pfalcon · 2019-05-24T10:25:59Z

make sure that everything in the repo has a well defined license/copyright (currently done by the LICENSE file as a default), and provide a way for users to understand and comply with the various licensing

It's hard to refrain from a comment that one of the source of disagreement was exactly my efforts to "raise the bar" of contributions to the codebase, in particular, define principles and rules, and efforts to apply them more thoroughly (instead of "anything will do, we'll clean up after users" approach exercised during a few initial years of the project). There was ~ zero response and support of those efforts, leaving me one on one against the tide, with predictable consequences. In the end, turns out those issues are still ("now"?) relevant and need to be resolved. D'oh.

dpgeorge · 2019-05-25T02:43:45Z

the right way to resolve that appears to be: 1) be absolutely strict about licensing/copyright;

As part of that the purpose of the LICENSE file should be clarified, which is what I attempt in #4812

dpgeorge · 2019-05-26T13:38:18Z

Yes, please merge this patch, and I assume the reason for not having made the change of "Copyright 2013-2019 The MicroPython developers" in the LICENSE file since January is the desire to prepare it somehow "better" than just to make that change (e.g. to accompany it with additional stats). So, I assume such a future change will be for better, and agree to it. Thanks.

This is what I have tried to do in #4812, to "prepare it somehow better" and "accompany it with additional stats". IMO such a change is for the better, and so according to what you say here you would agree to it. But from your comments on #4812 it seems you do not agree to it.

to track down any unlicensed/uncopyrighted files and add relevant copyrights (with proper communication to assumed copyright holders.

So my next proposal would be along these lines. To go through the repository and make sure all files are licensed properly, remove/replace things that have no or unfavourable licenses, and clean it up. Then revisit this question of top-level licensing/copyright.

pfalcon · 2019-05-26T21:14:31Z

IMO such a change is for the better, and so according to what you say here you would agree to it. But from your comments on #4812 it seems you do not agree to it.

Nope, I just personally feel:

That LICENSE: further updates to make license and copyright more explicit #4812 is being done as a replacement of doing specific steps about this patch.
Now that I'm pulled into discussion of LICENSE: Reference third-party licenses #4800/LICENSE: further updates to make license and copyright more explicit #4812, I had to say that I indeed don't see it as improvement. Improvement attempt - perhaps, but IMHO, it confuses things more than improves them.

Both are rather subjective of course. And, I'm not "against it", just express my reservations.

So my next proposal would be along these lines. To go through the repository and make sure all files are licensed properly, remove/replace things that have no or unfavourable licenses, and clean it up. Then revisit this question of top-level licensing/copyright.

Sounds good.

pfalcon · 2019-05-30T07:02:46Z

Ok, since I didn't find time to make comprehensive changes to the LICENSE file (even though there were excellent efforts by @dlech in #4432), I'm happy to just merge the change here as a "temporary" solution as long as @pfalcon agrees that these copyright lines can be eventually removed and replaced with something like "Copyright 2013-2019 The MicroPython developers". Is that acceptable?

Ok, besides me agreeing to this, this still wasn't done in time for the 1.11, even though it was requested in its planning ticket, #4784 (comment) .

@dpgeorge, all your behavior here looks like ignoring the issue, then finding excuses for not making the requested change, to which even you yourself agreed.

…oject. Change-Id: Id40cab51cc51048771ae0799e2a12ccae1d22eb5

dpgeorge · 2021-06-22T05:55:35Z

Closed in favour of commit 2fa975c

This is in preparation for ESP32-S3 support and potentially others. Related to micropython#4363

pfalcon force-pushed the pfalcon-copyright branch from 2b7ab13 to d87521a Compare December 17, 2018 09:34

pfalcon changed the title ~~LICENSE: Add my copyright, as the author of ~40% of commits to the project.~~ LICENSE: Add my copyright, as the author of ~30% of commits to the project. Dec 17, 2018

dlech mentioned this pull request Jan 26, 2019

Introduce comprehensive COPYRIGHT file #4432

Closed

jimmo mentioned this pull request May 21, 2019

LICENSE: Reference third-party licenses #4800

Merged

dpgeorge mentioned this pull request May 25, 2019

LICENSE: further updates to make license and copyright more explicit #4812

Closed

LICENSE: Add my copyright, as the author of ~30% of commits to the pr…

a8c1665

…oject. Change-Id: Id40cab51cc51048771ae0799e2a12ccae1d22eb5

pfalcon force-pushed the pfalcon-copyright branch from d87521a to a8c1665 Compare May 30, 2019 07:16

dpgeorge closed this Jun 22, 2021

tannewt added a commit to tannewt/circuitpython that referenced this pull request Sep 13, 2021

Rename esp32s2 port to espressif

973a90f

This is in preparation for ESP32-S3 support and potentially others. Related to micropython#4363

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

LICENSE: Add my copyright, as the author of ~30% of commits to the project. #4363

LICENSE: Add my copyright, as the author of ~30% of commits to the project. #4363

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

LICENSE: Add my copyright, as the author of ~30% of commits to the project. #4363

LICENSE: Add my copyright, as the author of ~30% of commits to the project. #4363

Uh oh!

Conversation

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!