LICENSE.md doesn't include MIT license?

Question

LICENSE.md doesn't include MIT license?

Closed this issue 4 years ago · 11 comments

some automated tooling for checking licenses noticed (in https://android-review.googlesource.com/c/platform/external/bc/+/1557812) that there's MIT license text in these files:

include/rand.h
safe-install.sh
src/rand.c

i notice that there's no mention of this in LICENSE.md, despite the fact that rand.c is part of the regular build. that seems like a bug, so i thought i'd report it.

Answer 1 · 2021-01-22T20:43:54.000Z

You are correct, that is a bug.

Technically, I don't have to add anything for safe-install.sh because it is also under CC0, but I will anyway.

I will add the licenses in my local tree and release 3.2.5 within a week (I hope) which will include the license fixes as well as fixes for a crash in dc.

Until I do fix the licenses (I am currently trying to rebuild my computer and can't do it right away), I will keep this issue open.

Thank you!

Answer 2 · 2021-01-26T17:32:27.000Z

I have committed the fix and will be releasing in a few days. I will keep this issue open until then.

However, I am curious: why does Android use my bc directly? toybox has bc (an older version of this one).

Answer 3 · 2021-01-26T18:32:36.000Z

I have committed the fix and will be releasing in a few days. I will keep this issue open until then.

thanks!

However, I am curious: why does Android use my bc directly? toybox has bc (an older version of this one).

more of a "why not?" really... why filter through another layer? the upstream tests are likely always to be a superset of the toybox ones, you seem to take releases pretty seriously, and any changes made in toybox to make the toybox bc match the local coding style have the possibility of introducing errors (and make it more difficult for you to backport important fixes) without adding any real value to the user. it would be more convenient to get everything directly from toybox, yes, but otherwise the pros and cons seem to lean in favor of getting it direct from the source.

similarly, even if/when toybox gets an awk, i'm assuming we'll keep one-true-awk. (at least until/unless the absence of gawk extensions or whatever make that unhelpful to users. mksh is in weird territory where it's a fine POSIX sh -- and explicitly doesn't want to be anything more -- but users actually want a bash instead. bc though is a lot less user-facing. at least i don't know anyone with opinions on bc!)

it's pretty awesome that you're trying to get to a one-true-bc situation for everyone btw, especially because it meant writing a new one that everyone can use rather than just digging up and dusting off the original one. thanks for that!

Answer 4 · 2021-01-26T20:49:25.000Z

I admit that your comment blindsided me, in a good way. I did not expect that answer. I thought it might be something like "performance" (the toybox version is old enough that it has poorer performance than GNU).

That said, the way I would have worded my aim was "get as many users as possible," so I guess I can understand that sentiment.

However, if I may ask (and you don't have to answer because I know you're busy), what did I do right to make a one-true-bc? When I started this project, I knew nothing about making people happy, so I guess I am asking what I accidentally did right. Also, what could I do better?

PS: Feel free to bring bug reports, especially Android-specific reports, directly to me. Now that I know you are a user, I will make special effort to support you to the extent that you don't need patches or anything else. (Is that what makes this a one-true-bc?)

Answer 5 · 2021-01-31T00:39:49.000Z

Version 3.2.5 has been released. Thank you!

Answer 6 · 2021-01-31T18:15:43.000Z

There were problems in 3.2.5 found by FreeBSD. I don't know if it will affect Android, but I will release 3.2.6 in a few hours if you want to wait.

Answer 7 · 2021-01-31T20:51:02.000Z

3.2.6 is out.

Answer 8 · 2021-02-06T00:07:27.000Z

I admit that your comment blindsided me, in a good way. I did not expect that answer. I thought it might be something like "performance" (the toybox version is old enough that it has poorer performance than GNU).

that's probably not super likely on-device, but one thing you may not know is that we've been trying to use the same tools for the build on the host as we use on the device. it gives us a bit of extra confidence that the tools we're using on device work right, and it gives us consistency between the host and target environments. (this is both the OS build itself and also the kernel builds, which are done separately and dropped in as prebuilts.)

which means that, although it's pretty unlikely that anyone's doing anything serious with bc on the device -- and tbh the only use i know of is basically just adding a list of [small] numbers -- it may well get more exercise during the build. we've certainly seen SoC vendors stressing tools like sed in unexpected ways, for example.

That said, the way I would have worded my aim was "get as many users as possible," so I guess I can understand that sentiment.

However, if I may ask (and you don't have to answer because I know you're busy), what did I do right to make a one-true-bc? When I started this project, I knew nothing about making people happy, so I guess I am asking what I accidentally did right. Also, what could I do better?

speaking for myself, but thinking of what i look for when i'm giving my "yae" or "nay" on additions to external/ in AOSP, it's things like...

has tests
...ideally unit tests
...and a culture of adding a new test to go with every bug fix
fuzzes
runs the above in CI
has proper releases (with versions/tags, so we're not just chasing random SHAs)
has clear goals
...that aren't experimental --- being stodgy is a plus for infrastructure :-)

i also have to care about the things the lawyers care about:

licenses
licenses
licenses

in an ideal world i'd like:

written in a safer language than C

but even in 2021 i'm not sure what that language is. seems like it might be rust? (but in 1995 if you'd asked me to predict 2021 i'd have said that everything important would have been rewritten in ahead-of-time compiled Java by now...)

i think the main thing that's missing is probably "healthy community" (i.e. "not just one maintainer", "bunch of regular contributors/reviewers"). but i honestly don't think that's particularly realistic for bc/dc in 2021. (or even in 1981, tbh!)

PS: Feel free to bring bug reports, especially Android-specific reports, directly to me. Now that I know you are a user, I will make special effort to support you to the extent that you don't need patches or anything else.

literally the only thing we've tripped over has been changes to your build/test scripts. since AOSP builds third-party projects with its own build system, there's some amount of duplication we need to do there. but -- unlike, say, strace -- you're on the easy end of the spectrum there. (the real pain -- for cross-compilation in general -- is a build system that builds a binary that needs to run on the target to generate something that's used later in the build. dealing with those situations is terrible. but unlikely for something like bc, luckily.)

(Is that what makes this a one-true-bc?)

actually, no, in that regard i really just meant "super friendly licensing so that anyone can use this code, regardless of their local { never_gpl, only_gpl } stance" :-)

Answer 9 · 2021-02-06T00:09:10.000Z

3.2.6 is out.

thanks! merged to AOSP: https://android-review.googlesource.com/c/platform/external/bc/+/1571055

(ignore the fact that it says "Test: make" --- we do actually run your tests in presubmit, but the script that adds the "Test:" line doesn't know that.)

Answer 10 · 2021-02-06T00:12:01.000Z

3.2.6 is out.

thanks! merged to AOSP: https://android-review.googlesource.com/c/platform/external/bc/+/1571055

(ignore the fact that it says "Test: make" --- we do actually run your tests in presubmit, but the script that adds the "Test:" line doesn't know that.)

which actually reminds me of another:

is available on github

because even if you're not a fan (as i know you're not), github is ubiquitous. so the chances are that if anyone has any kind of infrastructure for automatically tracking third-party project updates, it supports github. this is why the computers were able to have that update all done and ready for my approval so quickly, which is a real time saver when you have hundreds of third-party projects!

Answer 11 · 2021-02-06T15:59:25.000Z

Thank you for your comments, especially about licenses. After the recent Elasticsearch debacle, I was wondering if copyleft licenses would be better for future projects, but your comment has made it clear that that may not be the case.

And the rest of your comments were enlightening, especially the GitHub one. Thank you.