pyafm: Use 'open source' instead of 'FLOSS'

Less jargon, and more consistency (e.g. with my title ;).  The libre
distinction is small, and not particularly critical to this paper.  I
think it is essential that labs let you see their experiment control
software (eakly open source).  Whether or not their license allows for
sharing is less critical, although without significant funding
differences, I expect share-alike software to quickly surpass
no-derivatives software in terms of functionality.

diff --git a/src/pyafm/conclusions.tex b/src/pyafm/conclusions.tex
index eebf2945a42cb0f9460fc5b642951b80f303cd9c..8e044f2f864488cec87dfe73f6f480c658469eaa 100644 (file)
--- a/src/pyafm/conclusions.tex
+++ b/src/pyafm/conclusions.tex
@@ -19,7 +19,7 @@ stack\footnote{%
 }, and I've spent the remaining time tuning this stack (and the
 analysis software) while running experiments.
 
-A FLOSS stack allows collaborative development so that this
+An open source stack allows collaborative development so that this
 development cost can be shared between labs, as well as lowering the
 barrier to entry for new labs entering the field.  Besides benefiting
 SMFS groups, lower-level packages in the stack will be useful to a

diff --git a/src/pyafm/frameworks.tex b/src/pyafm/frameworks.tex
index 216ac12b691e7001f026b9e6cdc5f78a62ca837e..e913acc8f87c1211686d62cbf9e2499a34842a20 100644 (file)
--- a/src/pyafm/frameworks.tex
+++ b/src/pyafm/frameworks.tex
@@ -8,9 +8,9 @@ computers to control and monitor arbitrary physical processes is
 common in the scientific community and industry, but less so in the
 the general consumer market.  This means that interfaces between the
 digital and analog worlds haven't seen the focused development in the
-FLOSS community that more mainstream problem areas have received.  In
-this section I'll discuss a few possible options---both open and
-proprietary---in the context of my experiment control stack.
+open source community that more mainstream problem areas have
+received.  In this section I'll discuss a few possible options---both
+open and proprietary---in the context of my experiment control stack.
 
 \subsection{LabVIEW}
 \label{sec:labview}
@@ -83,20 +83,18 @@ recover earlier versions of the project.  For example, if you find a
 bug in your package, you can use your VCS to determine if that bug
 affected the data you gathered six months ago.
 
-There are a number of FLOSS version control systems in common use
-(Git, Mercurial, and Subversion, \dots), but in order to track and
+There are a number of open source version control systems in common
+use (Git, Mercurial, and Subversion, \dots), but in order to track and
 merge \emph{changes}, they need a way to calculate the difference
 between two versions of a given file.  For textual programming
 languages, the line-based textual differences used by VCSs work
 extremely well, but for binary file formats, performance decreases
 drastically.  There are third-party merge tools\citep{ni-merge} for
 LabVIEW, but the tools are not officially supported.
-
+%
 \nomenclature{VCS}{Version control system.  A system for tracking
   project development by recording versions of the project in a
   repository.}
-\nomenclature{FLOSS}{Free, Libre, and Open Source (software).  A
-  catch-all for copyleft licensing.}
 
 While National Instruments seems to put a reasonable amount of effort
 into maintaining backwards compatibility, long term archival of binary
@@ -134,7 +132,7 @@ The overhead of sending all the data through sockets to generic
 hardware interface modules was larger than I had na\"{\i}vely
 expected.  I also had trouble with multithreaded socket code on
 Cygwin, and decided to drop Microsoft Windows altogether in favor of
-a FLOSS operating system.
+an open source operating system.
 
 \begin{figure}
   \begin{center}
@@ -168,12 +166,13 @@ static int set_digital_output_data(DIGITAL_OUTPUT *d, unsigned int data)
 
 After transitioning to Linux-based systems, I could no longer use
 NI-DAQmx (which only supported Microsoft Windows).  Luckily, the
-\citetalias{comedi} project already provided FLOSS driver code for our
-DAQ card (an NI-PCI-6052E).  Comedi (from ``Control and Measurement
-Device Interface'') is a general purpose library for interacting with
-DAQ devices, and supports a wide range of hardware.  When I moved to
-Comedi, it was a stand-alone kernel module, but since November 2008 it
-has been included in the Linux source as a staging driver.
+\citetalias{comedi} project already provided open source driver code
+for our DAQ card (an NI-PCI-6052E).  Comedi (from ``Control and
+Measurement Device Interface'') is a general purpose library for
+interacting with DAQ devices, and supports a wide range of hardware.
+When I moved to Comedi, it was a stand-alone kernel module, but since
+November 2008 it has been included in the Linux source as a staging
+driver.
 
 Comedi development goes back to 2000, so by the time I arrived things
 were already pretty stable.  I submitted

diff --git a/src/pyafm/stack.tex b/src/pyafm/stack.tex
index c0be6aa1d536e23e85961ee3c6e0072775815c2c..130a274a08ae0fc1640ece320cd21ac013fb01eb 100644 (file)
--- a/src/pyafm/stack.tex
+++ b/src/pyafm/stack.tex
@@ -2,8 +2,8 @@
 \label{sec:pyafm:stack}
 
 In order to reduce future maintenance costs, I have based my stack as
-much as possible on existing FLOSS software, and split my stack into
-reusable components where such components might appeal to a wider
+much as possible on existing open source software, and split my stack
+into reusable components where such components might appeal to a wider
 audience.  From the bottom up, \pycomedi\ wraps the Comedi device
 driver for generic input/output, \pypiezo\ builds generic
 piezo-control logic on top of \pycomedi, \pyafm\ combines a