Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

2012-06-26: improved oslic finder basics (chapter 6)

  • Loading branch information...
commit da3809f305e032af44443565bc13915d02eb4ef5 1 parent 6bec217
Karsten Reincke authored
View
7 oslic-en.tex
@@ -104,7 +104,8 @@
\usepackage{amssymb}
\usepackage{wasysym}
\usepackage{pstricks, pst-node, pst-tree}
-
+\usepackage{chngcntr}
+\counterwithout{footnote}{chapter}
\usepackage[intoc]{nomencl}
\let\abbr\nomenclature
@@ -216,13 +217,13 @@ \chapter{Open Source: Important Minor Points}
\input{snippets/en/05-osImportantMinorPoints/0505-oslicAndPatents}
%%%%%%%%%%%%%%%
-\chapter{Open Source: Use Cases As Principle of Classification}
+\chapter{Open Source Use Cases: Concept and Taxonomy}
\input{snippets/en/06-osUseCases/0600-chapterAbstractInc}
\input{snippets/en/06-osUseCases/0601-chapterStartInc}
\input{snippets/en/06-osUseCases/0602-chapterTheOslicUseCasesInc}
%%%%%%%%%%%%%%%
-\chapter{Open Source Licenses: Find Your Specific To-do Lists}
+\chapter{Open Source Use Cases: Find the License Fulfilling To-do Lists}
\input{snippets/en/07-osToDoListFinder/0700-chapterAbstractInc}
\input{snippets/en/07-osToDoListFinder/0701-chapterStartInc}
View
7 snippets/en/06-osUseCases/0600-chapterAbstractInc.tex
@@ -24,8 +24,11 @@
\footnotesize
\begin{quote}\itshape
-This chapter offers our taxonomie of use cases which lateron will structure each
-license specific chapter.
+This chapter establishes the concept of Open Source Use Cases
+as a sorting system for to-do lists, which fulfill specific licenses in the
+context of such an Open Source Use Case. Additionally it introduces a taxonomy
+for these Open Source Use Cases whose structure later on will organize the Open
+Sourse Use Case Finder.
\end{quote}
\normalsize{}
View
133 snippets/en/06-osUseCases/0602-chapterTheOslicUseCasesInc.tex
@@ -23,34 +23,35 @@
%% use all entries of the bibliography
%\nocite{*}
-After all these introducing remarks let us summarize our idea: We know that the
-right to use Open Source Software depends on doings required by the Open Source
-Licenses. In opposite to the commercial licenses, you can not buy the right to
-use a piece of Open Source software - never. It's part of the Open Source
-Definition that the right to use the software may not be sold. The OSD
-states firstly that an Open Source License may \glqq{}\ldots not
-restrict any party from selling or giving away the software as a component of (any)
-aggregate software distribution\grqq{}, and adds secondly that an Open Source
-License \glqq{}\ldots shall not require a royalty or other fee for such
-sale\grqq{}\footcite[cf.][\nopage wp. §1]{OSI2012a}.
+After all these introducing remarks let us summarize the center of our idea: We
+know that the right to use Open Source Software depends on the doings required
+by the corresponding Open Source Licenses. In opposite to the commercial
+licenses, you can not buy the right to use a piece of Open Source software.
+Never! It is embedded into the Open Source Definition that the right to use the
+software may not be sold. The OSD states firstly that an Open Source License may
+\glqq{}[\ldots] not restrict any party from selling or giving away the software
+as a component of (any) aggregate software distribution\grqq{}, and adds
+secondly in the same context that an Open Source License \glqq{}[\ldots] shall
+not require a royalty or other fee for such sale\grqq{}\footcite[cf.][\nopage
+wp. §1]{OSI2012a}.
-But it is not adequate to derive from this rule that you are automatically
-allowed to use Open Source Software without any service in return: generally you
-have to do something for getting the right to use the software. In other words:
-Open Source Software is specified by the idea of 'paying by doing'.
+But nevertheless, it is not adequate to derive from this statement that you are
+automatically allowed to use Open Source Software without any service in return:
+generally you have to do something for getting the right to use the software. In
+other words: Open Source Software is specified by the idea of 'paying by doing'.
Therefore these Open Source Licenses describe specific circumstances under
-which the user must execute some tasks. These sets of conditions may be viewed
-as triggers for a compliant behaviour. So, if we want to offer license fulfilling
-to-do lists, we have to consider these triggers.
+which the user must execute some tasks. Such circumstances are often sets of
+conditions and may be viewed as triggers for a compliant behaviour. So, if we
+want to offer license fulfilling to-do lists, we have to consider these triggers.
The real challenge is, that such circumstances are not linear and simple. They
contain combinations of (sometimes) context sensitive conditions. These
conditions refer to different class of tokens. Such a class of token might
-denote a feature of the software itself - like being an application or a library. Or
-it might denote the circumstances of using the software -
-like 'using the software only for yourself' or 'distributing the software also
-to third parties'.
+denote a feature of the software itself - like being an application or a
+library. Or it might denote the circumstances of using the software - like
+'using the software only for yourself' or 'distributing the software also to
+third parties'.
At the end, we want to determine a set of specific OSUCs - Open Source Use
Cases. And we want to deliver for each of these OSUCs and for each of the
@@ -65,17 +66,27 @@
answers.
In other words: this chapter defines the relevant tokens and derives the
-conceptual structures; the next chapter will use the results without depper
-explanations. So, let's now start with the classes of tokens by which the
-circumstances of using a piece of Open Source Software can be specified:
+conceptual structures. The following chapter will use the results of this
+chapter - but without deeper discussions.
+
+So, let's now start with the classes of tokens by which the circumstances of
+using a piece of Open Source Software can be specified:
\begin{itemize}
\item Firstly we will consider the \textbf{type of the Open Source Software}.
We will distinguish between code snippets, modules, libraries or plugins on
the one hand, and autonomous, processable applications, programs or servers on
the other hand. Let's name the first set the 'snimolis' and the second the
- 'proapses' for indicating, that we are not only talking about libraries and
- applications in the strict, sense. More detailedly spoken, we will ask you,
+ 'proapses' for indicating, that we are not only talking about libraries or
+ applications in the well known sense\footnote{Of course, our newly introduced
+ concepts 'snimoli' and 'proapse' are not absolutely one of the most elegant
+ words. So, initially we tried to talk about 'applications' and 'librabries',
+ although in our context these words should denote more than they traditionally
+ do. But we couldn't minimize the irritations of our interlocutors. Too often
+ we had to amend that we were not only talking about applications and
+ librabries in the strict sense of the words, but about clusters of similar
+ entities. Finally we decided to generate our own words. Naturally, each
+ improving proposal is welcome ;-) }. More detailedly spoken, we will ask you,
whether the Open Source Software, you want to use, is a software library in
the broadest sense (an includable code snippet, a linkable module or library,
or a loadable plugin), or whether it is an autonomous application or server
@@ -94,32 +105,48 @@
is using it as one of its' components. More detailedly spoken, we will ask
you, whether you are you using the evaluated Open Source Software as an
autonomous piece of software, or whether you are using it in combination
- with other components for setting up a larger, more complex piece software.
+ with other components for setting up a larger, more complex piece of software.
\item Fourthly we will consider the \textbf{recipient of the of the Open
- Source Software}: Sometimes you might intend to use the received Open
- Source Software only for yourself, in other cases you might to intend to
- hand over the software also to other people. More detailedly spoken, we will
- ask you whether you are going to use the evaluated Open Source Software only
- for yourself or do you plan to (re)distribute it (also) to third parties?
+ Source Software}: Sometimes you might wish to use the received Open
+ Source Software only for yourself. In other cases you might intend to
+ hand over the software (also) to other people. More detailedly spoken, we will
+ ask you, whether you are going to use the evaluated Open Source Software only
+ for yourself, or whether you plan to (re)distribute it (also) to third
+ parties,
\item Fifthly and finally we will consider the \textbf{combining mode of the
of the Open Source Software usage}: In this case, we will ask you, whether you
are going to combine the evaluated Open Source Software with other
software components by linking all together statically, by linking them
- dynamically, or by textually including the Open Source Software into your
- larger unit.
+ dynamically, or by textually including (parts of) the Open Source Software
+ into your larger unit.
+\end{itemize}
+
+In the beginning we defined an \emph{Open Source Use Case} as a set of
+classified tokens. No we have the following classified tokens:
+\begin{itemize}
+ \item \texttt{type::snimoli} or \texttt{type::proapse}
+ \item \texttt{state::unmodified} or \texttt{state::modified}
+ \item \texttt{context::alone} or \texttt{context::combined}
+ \item \texttt{recipient::4yourself} or \texttt{ecipient::4others}
+ \item \texttt{mode::statically-linked} or \texttt{mode::dynamically-linked} or
+ \\ \texttt{mode::textually-included}
\end{itemize}
-In the beginning we defined an Open Source Usecase as a set of classified
-tokens. If we now simply combine all tokens of all classes with all tokens of
-the other classes, we get 2*2*2*3*2 = 48 sets of tokens or 48 Open Source Use
-Cases. But some of these sets are invalid from an empirical view. And some of
-these sets are context sensitive:
+If we now simply combine all the tokens of all these classes with all the tokens
+of the other classes\footnote{in the sense of the cross product
+TYPE x STATE x CONTEXT x RECIPIENT x MODE}, we get 2*2*2*3*2 = 48 sets of tokens
+or 48 \textit{Open Source Use Cases}. But some of these sets are invalid from
+an empirical or logical view. And some of these sets are context sensitive:
-Firstly, it offers no additional knowledge to ask you, whether you are going to
-combine the received software with other software components by linking them
-statically or dynamically, or by including it textually into a larger unit, if
-you already have answered, that you want to use the received Open Source
-Software in combination with other elements.
+Firstly, it makes no sense to ask you whether you are going to combine the
+received software with other software components by linking them statically or
+dynamically, or by including it textually into a larger unit, if you already
+have answered, that the received Open Source Software is a \textit{proapse} or
+that it shall be used \textit{alone}: A readily prepared application or server
+can't be linked to another application or server, which also contains a
+\texttt{main}-function. And using a \textit{proapse} or \textit{snimoli}
+\textit{alone} includes that it is used \textit{not in combination} with other
+units, simply because they are tokens of the same class.
Secondly: If you already have specified that the used Open Source
Software is a \textit{proapse} - hence an autonomous program, an application,
@@ -133,18 +160,18 @@
And thirdly - just the other way round: If you already have specified that the
used Open Source Software is a \textit{snimoli} - hence a snippet of code, a
module, a plugin, or a library -, and that this \textit{snimoli} shall be used
-only by yourself (not distributed to other 3rd. parties, then your answer
+only by yourself (not distributed to other 3rd. parties), then your answer
includes pratically, that this \textit{snimoli} is used in combination. This
-is logical, because if you want to use it in the state \textit{alone}, then you
-would have a software library on your disc (your are 'using' it for yourself)
-without combining it to any other software: hence in this case this librabry
-would lie on your disc and nothing more: a senseless use case.
+conclusion is valid, because if you want to use it in the state \textit{alone},
+then you would have a software library on your disc (your are 'using' it for
+yourself) without combining it to any other software: hence in this case this
+librabry would lie on your disc and nothing more: a senseless use case.
-Do you think this is complicate? Yes, so we do. We spent a couple of time to
-explain ourselves these constraints. Only when we had transposed all
+Do you think, this is complicate? So we do. We spent a couple of time to
+explain ourselves these constraints. Only when we had transposed all the
combinations and rules into a tree, we got the real insight into situation.
-So let us summarize the these specifications by two little pictures before we
-will specify the real Open Source Use Case finder:
+So let us summarize these specifications by two little pictures before we
+will specify the real Open Source Use Case Finder:
\section{The OS Use Case Dimensions: Classes and Tokens}
View
8 snippets/en/07-osToDoListFinder/0700-chapterAbstractInc.tex
@@ -24,8 +24,12 @@
\footnotesize
\begin{quote}\itshape
-This chapter shall offer the finder in form of a process / deciding chart based
-on leading questions. The main part should be a simple picture!
+This chapter offers the Open Source Use Case Finder: Firstly it presents
+of form to gather the information. Secondly it offers a tree which easily
+can be transversed by the gathered information. Each leaf of the tree leads to
+one Open Source Use Case. These Open Source Use Cases are listed as third
+section of this chapter and are finally referring to the specific license
+fulfill to-do list.
\end{quote}
\normalsize{}
View
40 snippets/en/07-osToDoListFinder/0701-chapterStartInc.tex
@@ -23,6 +23,44 @@
%% use all entries of the bibliography
%\nocite{*}
-[TDB \ldots]
+\section{A standard form for gathering the relevant information}
+
+\begin{table}
+\scriptsize
+\caption{information needed for finding the relevant Open Source Use Case}
+\begin{center}
+\begin{tabular}[h]{|l|l|l|l|}
+\hline
+Class & Question & possible answers & your answer\\
+\hline
+ Type &
+ Is the Open Source Software, you want to use, a software library in
+ the broadest sense (an includable code snippet, a linkable module or library,
+ or a loadable plugin), or is it an autonomous application or server
+ which can be executed or processed? &
+ proapse or snimoli & ??\\
+\hline
+ State &
+ Do you want to leave the evaluated Open Source Software as you have got it, or
+ do you want to modify it before using and/or distributing it to 3rd parties? &
+ unmodified or modified & ??\\
+\hline
+ Context &
+ ZS &
+ alone or combined & ?? \\
+\hline
+Recipient & ZS & 4yourself or 4others & ?? \\
+\hline
+Mode & ZS & statically linked, dynamically linked, or textually included & ?? \\
+\hline
+\hline
+\end{tabular}
+\end{center}
+\end{table}
+
+
+\section{The taxonomic Open Source Use Case Finder}
+
+\section{The Open Source Use Cases and their links to the to-do lists}
%\bibliography{../../../bibfiles/oscResourcesEn}
Please sign in to comment.
Something went wrong with that request. Please try again.