Clarify that this wasi-filesystem API is not derived from CloudABI. (#73

)

CloudABI was an important influence and wasi-filesystem retains some
of the core ideas, and the witx API was derived from it. However, the
wit API here has been entirely rewritten around the needs and features
of Wit, and POSIX and Windows compatibility.

README.md

@@ -57,6 +57,10 @@ WASI filesystem is not intended to be used as a virtual API for accessing
 arbitary resources. Unix's "everything is a file" philosophy is in conflict
 with the goals of supporting modularity and the principle of least authority.
 
+Many of the ideas related to doing capability-based filesystem sandboxing with
+`openat` come from [CloudABI](https://github.com/NuxiNL/cloudabi) and
+[Capsicum](https://wiki.freebsd.org/Capsicum).
+
 ### Goals
 
 The primary goal of WASI filesystem is to allow users to use WASI programs to

wasi-filesystem.wit.md

@@ -11,9 +11,6 @@ Paths are passed as interface-type `string`s, meaning they must consist of
 a sequence of Unicode Scalar Values (USVs). Some filesystems may contain paths
 which are not accessible by this API.
 
-Some of the content and ideas here are derived from
-[CloudABI](https://github.com/NuxiNL/cloudabi).
-
 ## `size`
 ```wit
 /// Size of a range of bytes in memory.