Minor language edits in paper.tex

These are mostly minor language edits. There is one significant fix: the
word `typically' in `a non-free software project typically' cannot be
distributed by the project. There is a whole range of licences between
strictly free software definition, strictly OSI open-source definition, and
fully closed source. For example, software with a no-commercial usage
licence (similar to CC-BY-NC) can be publicly redistributed on any server,
as long as there is no requirement of payment or no requirement of payment
that is "commercial" (according to lawyers' interpretation of when a
payment is commercial).

1 files changed, 6 insertions, 6 deletions

diff --git a/paper.tex b/paper.tex
index 7937d16..02d898b 100644
--- a/paper.tex
+++ b/paper.tex
@@ -275,11 +275,11 @@ However, because they are rarely complete (as discussed in principle \ref{princi
 IPOL, which uniquely stands out in other principles, fails here: only the final snapshot is published.
 
 \item \label{principle:freesoftware}\textbf{Free and open source software:}
-  Technically, reproducibility (defined in \ref{definition:reproduction}) is possible with a non-free or non-open-source software (a black box).
-  This principle is thus necessary to complement the definition of reproducibility and has many advantages which are critical to the sciences and the industry:
+  Technically, reproducibility (defined in \ref{definition:reproduction}) is possible with non-free or non-open-source software (a black box).
+  This principle is thus necessary to complement the definition of reproducibility and has many advantages which are critical to the sciences and to industry:
   1) The lineage, and its optimization, can be traced down to the internal algorithm in the software's source.
-  2) A free software that may not execute on a future hardware can be modified to work.
-  3) A non-free software cannot be distributed by the project, making the whole community reliant only on the proprietary owner's server (even if the proprietary software does not ask for payments).
+  2) A free software package that may not execute on a particular piece of future hardware can be modified to work on that hardware.
+  3) A non-free software project typically cannot be distributed by the project, making the whole community reliant only on the proprietary package owner's server (even if the proprietary software does not ask for payments).
 
   \emph{Comparison with existing:} The existing solutions listed above are all free software.
   While there are non-free lineage or workflow solutions, we do not consider them here precisely because of this principle.
@@ -715,7 +715,7 @@ Maintaining the various packages is time consuming for us (Maneage maintainers).
 However, because software installation is also in Make, some users are already adding their necessary software to the core Maneage branch, thus propagating the improvements to all projects using Maneage.
 Another caveat that has been raised is that publishing the project's reproducible data lineage immediately after publication may hamper their ability to continue with followup papers because others may do it before them.
 We propose these solutions:
-1) Through the Git history, the added work by another team, at any phase of the project, can be quantied, contributing to a new concept of authorship in scientific projects and help to quantify Newton's famous ``\emph{standing on the shoulders of giants}'' quote.
+1) Through the Git history, the added work by another team, at any phase of the project, can be quantified, contributing to a new concept of authorship in scientific projects and helping to quantify Newton's famous ``\emph{standing on the shoulders of giants}'' quote.
 This is however a long-term goal and requires major changes to academic value systems.
 2) Authors can be given a grace period where the journal, or some third authority, keeps the source and publishes it a certain interval after publication.
 
@@ -731,7 +731,7 @@ This is however a long-term goal and requires major changes to academic value sy
 \section{Conclusion \& Summary}
 \label{sec:conclusion}
 
-To effectively leaverage the power of big data, we need to have a complete view of its lineage.
+To effectively leverage the power of big data, we need to have a complete view of its lineage.
 Scientists are however rarely trained sufficiently in data management or software development, and the plethora of high-level tools that change every few years does not help.
 Such high-level tools are primarily targetted at software developers, who are paid to learn them and use them effectively for short-term projects.
 Scientists on the other hand need to focus on their own research fields, and need to think about longevity.