![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
terminal adds upon package install sound like a great idea to me! we should allow them, unlike npm:
https://www.zdnet.com/article/npm-bans-terminal-ads/
---
[1] lists 4 kinds of docs:
tutorial explanatory how-to/recipe reference
[2] adds
README
i would also add
things like Python's tutorial, or the Ruby book,
which are mixtures of tutorial and explanatory, while also being comprehensive (to a point)
--- license
" I have talked to GCC developers about integrating a Rust frontend and they said, the main blocker is the fact that the language specification isn't stable and a fast moving target. ... I think the instability the GCC devs are concerned about is the release schedule. Rust has 9 releases per year while GCC has 4-5 releases. Unless you update your compiler quickly, you won't be able to use much of the crates.io ecosystem as crates are quick at requiring a new compiler version. Often the implementation of a new language feature is still getting last-minute fixes up to 6 weeks before the release, and sometimes even after that beta period. ... GCC can't miss out releases. The rustc 1.36.0 frontend needs at least a 1.35.0 frontend to compile itself. And most Rust programs in the ecosystem work with rustcs compiled with older LLVM releases, but most Rust programs that have dependencies do need newer rustc releases.
... As for stability of MIR: currently I think MIR is serialized to disk in a glorified mmap way. Basically following the Rust memory representation. It's great if both the creator of the MIR as well as the part that reads the MIR are written in Rust. Furthermore, there are libraries about how memory layout should look like that are provided to codegen backends. Those libraries are written in Rust and not really usable outside of Rust. So currently unless someone serializes MIR using e.g. bincode and provides C bindings for those layout libraries, there are good reasons to write the codegen backend in Rust itself, at least the part that translates MIR to the next stage. "
---
There's an organization called Blue Oak Council in which 3 FOSS lawyers work on licensing-ish stuff:
https://heathermeeker.com/2019/03/07/blue-oak-council-and-the-permissive-license-list/
Kyle Mitchell (executive director), Heather Meeker, Luis Villa. Kyle authors a zillion new licenses, so i'd like to see that this stuff was actually supported by the others, and it seems it was. According to that post by Heather all actively participated in the license list project and in the creation of the Blue Oak license.
Luis also publicly supports this work: " Luis Villa argues that the list of OSI-approved licenses isn't a comprehensive list of usable open source licenses. It should therefore be avoided in contracts or license clauses. But if not that, what is the purpose of the list? Would it make sense to create a smaller list of useful licenses? Villa points to his Blue Oak project as a list of useful permissive licenses. " -- [3]
"I'd happily submit the Blue Oak Model permissive license as an initial guinea pig for such a process...I have no current plans to submit the license primarily because I am too busy to have a massively inefficient discussion on license-review" -- http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020279.html
"Agree there definitely doesn’t need to be a flood of new licenses, of course, but the correct number is > 0 (or we should nuke everything other than Apache. Or Blue Oak Winking face)" -- https://twitter.com/luis_in_brief/status/1215503399648514048
"(I should disclose here that Kyle and I work together quite a bit, and I co-authored a license with him in 2019—the Blue Oak Model License—that I volunteered to submit to the OSI as a guinea pig to test any improved processes.)" -- https://blog.tidelift.com/open-source-licenses-2019-year-in-review
Luis Villa is the Apache 2.0 guy, i think.
Richard Fontana seems to like the Blue Oak License too: "Blue Oak is, as to its content, both extremely simple and extremely non-controversial" -- Richard Fontana (Mar 19 2019)
however earlier here he says:
"new putative FOSS licenses should be drafted in public and collaboratively, not in private as I gather Blue Oak was" (https://twitter.com/richardfontana/status/1104811186665721856) and mentions that here: https://lists.fedorahosted.org/archives/list/copyleft-next@lists.fedorahosted.org/thread/2YJ4COON2V33J7SF7B2DXE3EYUHVZXWA/ (Mar 16 2019)
The group of Meeker, Villa, Mitchell also works on the Polyform Project, a set of non-FOSS licenses: https://polyformproject.org/licenses/
" A group of attorneys also published a set of standard, but again very explicitly commercial/not-open, licenses as the Polyform Project.
While the lawyers involved in these (including Kyle, Heather Meeker, and me) would be the first to tell you that these licenses aren’t open source, I include them here because they bear two key similarities to open source licenses. " -- https://blog.tidelift.com/open-source-licenses-2019-year-in-review
and Villa claims that Mitchell's non-FOSS "License Zero" has some adoption [4]
https://licensezero.com/ (seems like the actual license is Parity) related forum: https://forum.artlessdevices.com/top
Villa is a little chillier towards other licenses there:
" Commercial “open source”
In late 2018, Mongo submitted the Server Side Public License to the OSI, intended to replace the AGPL with a license that was more aggressive and protected their business from cloud vendors. In 2019, this trend accelerated and turned into a movement of a sort, with Redis using a new source available license. These discussions eventually snowballed into something calling itself Commercial Open Source Software, centered around an Open Core Summit.
The entire thing was a little odd, given that open source has (from literally the time the phrase was coined!) been pro-commerce, and that also since the nominally pro-commerce COSS folks appeared to be arguing primarily for licenses that...oppose commercial use.
While I think some of the readings of this have been uncharitable, suffice to say that this messaging has been at best very confusing and at worst perceived as an active attack on the definition of open source by venture capitalists who want Red Hat-like returns without putting in the effort.
Regardless of the confused messaging, I expect we’ll see more of this in 2020—in both good and bad faith. "
The rest of the post speaks somewhat admiringly about CAL (a broader-than-GPL license that extends freedom to data as well as code) and Parity (another extremely broad license, but one with simplified wording; from Mitchell). These are noted on Blue Oak's copyleft guide: https://blueoakcouncil.org/copyleft
interestingly Blue Oak Council also has a model FOSS usage policy for use by businesses. Cool! https://blueoakcouncil.org/starter-policy for small companies and https://blueoakcouncil.org/company-policy for larger ones. And here's a policy for contractors: https://blueoakcouncil.org/development-use
here's a blog post about how blue oak council came to be: https://writing.kemitchell.com/2019/03/07/Blue-Oak-Council.html
interestingly Bruce Perens has split from OSI:
and he now advocates for everyone to use one of AGPL 3, LGPL3, or Apache 2, to reduce confusion.
github suggests GPLv3 and MIT: https://choosealicense.com/ but also is cool with AGPLv3, Apache 2.0, MIT: https://choosealicense.com/licenses/
GNU suggests Apache 2.0 for permissive: https://www.gnu.org/licenses/license-recommendations.html
here's mitchell's take on a minimal set of licenses: https://writing.kemitchell.com/2019/03/17/License-Utopia.html
" Stephen Paul Weber occasionally sees such “any OSI-approved license” terms in contests or in aggregators. Sometimes, any OSI- or FSF-approved license is allowed, to avoid choosing “sides”. Fontana thinks that approach is clever: both OSI and FSF are respected neutral authorities, unlike e.g. Blue Oak or Fedora. As a historical point, Fontana remembers that Fedora did not rely on the OSI license list because OSI was then seen as too commercially influenced. Nowadays, OSI criticism seems to be the opposite. Henrik Ingo thinks the OSI is now much more important than back then, because Linux distros no longer have the role of kingmakers: whether the software is packaged for Debian or Fedora is no longer crucial for an open source project. "
here's the FSF list:
https://www.gnu.org/licenses/license-list.en.html
here's the OSI list:
https://opensource.org/licenses
https://www.kiuwan.com/blog/comparison-popular-open-source-licenses/ says that whitesource says that the most popular permissive licenses are MIT and Apache 2.0
here's a License Picker on Meeker's website:
https://heathermeeker.com/license-picker-2-0/
here's wikipedia's comparison page:
https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licences
here's blue oak's permissive license:
https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licences
here's blue oak's permissive license list:
https://blueoakcouncil.org/list
the only 'Gold' rated license is BSD-2-Clause Plus Patent License (BSD-2-Clause-Patent) (and it looks like they consider their own license Gold or better than Gold). Apache 2.0, MIT are both rated 'silver'.
afaict BSD-2-Clause-Patent isn't well known and isn't even on FSF's list at https://www.gnu.org/licenses/license-list.en.html.
https://spdx.org/licenses/BSD-2-Clause-Patent.html https://opensource.org/licenses/BSDplusPatent https://opensource.org/licenses/BSDplusPatent links to :
GNU License List Wikipedia License List OSSWatch License Diff Choose a license (by Github)
here's some discussion on Blue Oak (Mitchell thinks it's better than MIT and BSD): https://writing.kemitchell.com/2019/03/09/Deprecation-Notice.html https://blueoakcouncil.org/2019/03/06/model.html https://news.ycombinator.com/item?id=19347898
Mitchell seems to think that Blue Oak is the plain language version of Apache, at least in some respects: "Licenses like Apache 2.0 show how lawyers do this in legal terms for private deals every day. Blue Oak shows the same job done in everyday English, without long lists, run-on sentences, or complex scope rules." That blog post is generally complimentary of Apache 2.0, except that he thinks the rules around contributors are too complex.
here's something else he says about apache 2.0:
kemitchell on Mar 10, 2019 [–]
Both Blue Oak and Apache are relatively modern permissive licenses, but they differ intentionally in design. In the short to medium term, I foresee that many projects will continue to choose Apache where contributions from large software patent holders are essential, because of Apache's complex rules on patent scope. At the same time, I think large software patent holders will prefer to receive code under the uncomplicated Blue Oak patent grant, even as they insist on Apache's mazelike compromise for outbound contributions. -- https://news.ycombinator.com/item?id=19347898
so my summary:
---
user 'skade' on lobsters volunteers to be contacted by and give advice to programming language community organizers, is particulary happy to give advice on conference organization and on surveys:
https://lobste.rs/s/xgquet/2020_state_haskell_survey#c_hp7nfs
---
regarding PL community surveys, user 'skade' on lobsters suggests starting by copying the battle-tested survey from Rust.
An example of some tricky stuff he gives is that rather than asking about trans-ness, for various reasons it may be better to just ask:
“Do you consider yourself a member of an underrepresented demographic in technology?”
I won’t list them all here, but it lists 14 characteristics that we are aware of, such as gender identity, race, but also language skill + a free form field
“Do you feel your situation makes it difficult for you to participate in the Rust community?”
Yes
No
Maybe---
some more ideas for release methodology:
some excerpts from my old 'release staging' workflow:
"
Note that, until the previous version has made its way through preview and beta and is deployed to production, another alpha release won't be made.
We will be using the git-flow workflow. Most of this page needs to be updated to be consistent with that terminology.
Following the git-flow branching model, we have three active git branches at any one time for each project:
The develop branch keeps on growing. When a ffreeze release is made, the dev repo is branched into a release branch. When the version in the release branch is deemed stable enough for production, the release branch is merged into "master".
In addition, developers are encouraged to maintain OtherRepos? for personal development and/or for developing features which do not yet qualify for acceptance into dev. Please see the page OtherRepos?