Permalink
Browse files

2012-06-22: first results of the new finder sturcture

as aligned on Thursday, 21. 06 in bonn
  • Loading branch information...
1 parent 0f67ede commit 758c658d4452738e573cb442d56d610d30a081a6 Karsten Reincke committed Jun 22, 2012
@@ -1,4 +1,4 @@
-% This file was created with JabRef 2.7b.
+% This file was created with JabRef 2.8.
% Encoding: UTF8
@INBOOK{ArlBriVol2004a,
@@ -674,7 +674,7 @@ @BOOK{VwdjDebVEee2003a
Antwort ist vielleicht etwas dünn: der grösste Teil der Lizenzen
sei von der BSD oder der GPL abgeleitet, um die grundlegenden Prinzipien
der Community zu schützen.},
- language = {emglish},
+ language = {english},
note = {Print},
owner = {reincke},
timestamp = {2012.02.20}
@@ -1159,6 +1159,28 @@ @BOOK{JaeMet2002a
timestamp = {2011.07.27}
}
+@BOOK{Kaes2008a,
+ author = {Simone Käs},
+ title = {Rethinking industry practice. The emergence of openness in the embedded
+ component industry},
+ address = {München},
+ year = {2008},
+ shorttitle = {Rethinking industry practice; The emergence of openness, 2008},
+ publisher = {Pro BUSINESS},
+ isbn = {978-3-86805-256-5},
+ annote = {Untersucht den Wandel hin zur Offenheit in der Softwareentwicklung
+ über Interviews innerhalb von 'Embedded-Linux'-Firmen. Das Ergebnis
+ ist, dass die Offenheit kundengetrieben sei und zugleich einen Lernprozess
+ innerhalb der Firmen bedinge. Das Buch enthält eine kurze, aber präzise
+ Darstellung dessen, was OSS auch aus Lizenzsicht ist; eine systematische
+ Darstellung der eingegangenen Verpflichtungen liefert es nicht.},
+ comment = {FaM Bibliothek Recht und Wirtschaft 05/QP 210 K11},
+ language = {english},
+ note = {Print},
+ owner = {reincke},
+ timestamp = {2011.08.01}
+}
+
@BOOK{Kersken2009a,
author = {Sasche Kersken},
title = {Apache 2.2. Das umfassende Handbuch},
@@ -1220,28 +1242,6 @@ @BOOK{Kugler2005a
timestamp = {2011.08.04}
}
-@BOOK{Kaes2008a,
- author = {Simone Käs},
- title = {Rethinking industry practice. The emergence of openness in the embedded
- component industry},
- address = {München},
- year = {2008},
- shorttitle = {Rethinking industry practice; The emergence of openness, 2008},
- publisher = {Pro BUSINESS},
- isbn = {978-3-86805-256-5},
- annote = {Untersucht den Wandel hin zur Offenheit in der Softwareentwicklung
- über Interviews innerhalb von 'Embedded-Linux'-Firmen. Das Ergebnis
- ist, dass die Offenheit kundengetrieben sei und zugleich einen Lernprozess
- innerhalb der Firmen bedinge. Das Buch enthält eine kurze, aber präzise
- Darstellung dessen, was OSS auch aus Lizenzsicht ist; eine systematische
- Darstellung der eingegangenen Verpflichtungen liefert es nicht.},
- comment = {FaM Bibliothek Recht und Wirtschaft 05/QP 210 K11},
- language = {english},
- note = {Print},
- owner = {reincke},
- timestamp = {2011.08.01}
-}
-
@ARTICLE{McAllister2003a,
author = {Neil McAllister},
title = {Licence to Profit [. Hybrid Open Source Licensing]},
@@ -1350,6 +1350,25 @@ @BOOK{Oberhem2008a
timestamp = {2011.08.01}
}
+@MISC{OSI2012a,
+ author = {{Open Source Initiative}},
+ title = {The Open Source Definition},
+ year = {2012 [Jahr o.A.]},
+ shorttitle = {The Open Source Definition, 2012},
+ annote = {Diese Seite listet die 10 Regeln auf, die zusammen bestimmen, wann
+ eine bestimmte Lizenz als Open Source Lizenz klassifiziert werden
+ kann. Sie präsentiert die Open Source Definition. Das bedeutet auch,
+ dass Software tatsächlich nur dann Open Source Software ist, wenn
+ ihre Lizenz als Open Source Lizenz durch die Open Source Initiative
+ bestätigt worden ist.},
+ language = {english},
+ note = {FreeWeb},
+ owner = {reincke},
+ timestamp = {2012.06.21},
+ url = {http://www.opensource.org/docs/osd},
+ urldate = {2012-06-21}
+}
+
@BOOK{Phillips2009a,
author = {Douglas E. Phillips},
title = {The Software License Unveiled. How Legislation by License Controls
@@ -1,4 +1,4 @@
-% This file was created with JabRef 2.7b.
+% This file was created with JabRef 2.8.
% Encoding: UTF8
@INBOOK{ArlBriVol2004a,
@@ -673,7 +673,7 @@ @BOOK{VwdjDebVEee2003a
Software licenses. The answer is perhaps a little thin: the most
part of the licenses are derived from BSD or GPL 'to protect the
fundamental principles of the communities'.},
- language = {emglish},
+ language = {english},
note = {Print},
owner = {reincke},
timestamp = {2012.02.20}
@@ -1154,6 +1154,28 @@ @BOOK{JaeMet2002a
timestamp = {2011.07.27}
}
+@BOOK{Kaes2008a,
+ author = {Simone Käs},
+ title = {Rethinking industry practice. The emergence of openness in the embedded
+ component industry},
+ address = {München},
+ year = {2008},
+ shorttitle = {Rethinking industry practice; The emergence of openness, 2008},
+ publisher = {Pro BUSINESS},
+ isbn = {978-3-86805-256-5},
+ annote = {This book analyzes the change to open software developement by interviewing
+ 'embedded-linux'-companies. The result is that openness is required
+ by the customers and that practicing openness evokes a process of
+ learning. The book offers a short but tellingly survey of OSS and
+ their licenses, although it doesn't offer a systematical review of
+ the obligations established by the different licenses.},
+ comment = {FaM Bibliothek Recht und Wirtschaft 05/QP 210 K11},
+ language = {english},
+ note = {Print},
+ owner = {reincke},
+ timestamp = {2011.08.01}
+}
+
@BOOK{Kersken2009a,
author = {Sasche Kersken},
title = {Apache 2.2. Das umfassende Handbuch},
@@ -1215,28 +1237,6 @@ @BOOK{Kugler2005a
timestamp = {2011.08.04}
}
-@BOOK{Kaes2008a,
- author = {Simone Käs},
- title = {Rethinking industry practice. The emergence of openness in the embedded
- component industry},
- address = {München},
- year = {2008},
- shorttitle = {Rethinking industry practice; The emergence of openness, 2008},
- publisher = {Pro BUSINESS},
- isbn = {978-3-86805-256-5},
- annote = {This book analyzes the change to open software developement by interviewing
- 'embedded-linux'-companies. The result is that openness is required
- by the customers and that practicing openness evokes a process of
- learning. The book offers a short but tellingly survey of OSS and
- their licenses, although it doesn't offer a systematical review of
- the obligations established by the different licenses.},
- comment = {FaM Bibliothek Recht und Wirtschaft 05/QP 210 K11},
- language = {english},
- note = {Print},
- owner = {reincke},
- timestamp = {2011.08.01}
-}
-
@ARTICLE{McAllister2003a,
author = {Neil McAllister},
title = {Licence to Profit [. Hybrid Open Source Licensing]},
@@ -1344,6 +1344,24 @@ @BOOK{Oberhem2008a
timestamp = {2011.08.01}
}
+@MISC{OSI2012a,
+ author = {{Open Source Initiative}},
+ title = {The Open Source Definition},
+ year = {2012 [Year n.st]},
+ shorttitle = {The Open Source Definition, 2012},
+ annote = {This page lists the ten rules which together specify under which
+ conditions a specific license can be classified as Open Source license.
+ It presents the Open Source Definition. So, a piece of software is
+ only then Open Source Software, if its license has been approved
+ as an Open Source License by the Open Source Initiative.},
+ language = {english},
+ note = {FreeWeb},
+ owner = {reincke},
+ timestamp = {2012.06.21},
+ url = {http://www.opensource.org/docs/osd},
+ urldate = {2012-06-21}
+}
+
@BOOK{Phillips2009a,
author = {Douglas E. Phillips},
title = {The Software License Unveiled. How Legislation by License Controls
@@ -28,4 +28,5 @@
Software}
\abbr[lc]{l.c.}{loco citato = latin for 'in the place cited'}
\abbr[np]{np.}{no page numbering}
-\abbr[wp]{wp.}{webpage / webdocument without any internal (page)numbering}
+\abbr[wp]{wp.}{webpage / webdocument without any internal (page)numbering}
+\abbr[nst]{n.st.}{not stated}
View
@@ -258,7 +258,7 @@ \chapter{Appendices}
\input{btexmat/oscNclJournalsInc}
\printnomenclature
-\bibliography{bibfiles/oscResourcesDe}
+\bibliography{bibfiles/oscResourcesEn}
\end{document}
@@ -23,6 +23,6 @@
%% use all entries of the bibliography
%\nocite{*}
-[todo: \ldots (insert all contexts concerning the idea of use cases)]
+%[todo: \ldots (insert all contexts concerning the idea of use cases)]
%\bibliography{../../../bibfiles/oscResourcesEn}
@@ -23,8 +23,74 @@
%% use all entries of the bibliography
%\nocite{*}
-Based on this information we can no derive and define the use cases by which the
-OSLiC classifies its license fulfilling to-do lists:
+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 Open Source
+Definition 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}.
+
+On the other hand it is wrong to simply conclude that you are 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 set 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.
+
+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 refer
+to a feature of the software itself - like being an application or a library. Or
+such class of tokens might refer to the circumstances of using the software -
+like 'using the software only for yourself' or 'distributing the software also
+to third parties'.
+
+In the end we want to determine a set of specific use cases and deliver for each
+of these use cases and for each of the considered Open Source Licenses one list
+of actions, which fulfill the license in the context of this use case. A use
+case is a set of tokens describing the circumstances of the usage. So, in the
+beginning we have to specify the relevant classes of tokens. Then we build the
+valid combinations of tokens, our use cases. And finally - based on these
+specifying tokens - we generate a taxonomy of our use cases for being able to
+offer an easily to use reference to the relevant use cases and the
+corresponding, the license fulfilling to-do list.
+
+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 type of the licensed software. We will
+ discriminate between code snippets, modules, libraries and plugins on the one
+ hand and autonomous, processable applications, programs, servers on the other
+ hand. Let's name the first set the 'snipmolibs' and the second the
+ 'progappsers' for indicating, that we are not only talking about libraries and
+ applications in the strict, sense. 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
+ which can be executed or processed. In the first case, the answer should be
+ 'it's a snipmolib', in the second 'it's a progappser'.
+ \item Secondly we will consider the state of the software: it might be used,
+ as one has got it, or one can modify it, before using it. More detailedly
+ spoken, we will ask you whether you want to leave the evaluated Open Source
+ Software as you have got it or whether you want to modify it before using
+ and/or distributing it to 3rd parties? In the firstcase, the answer should be
+ 'unmodified', in the second 'modified'.
+ \item Thirdly we will consider the
+\end{itemize}
+
+
+
+
+ Based on this information we can no derive and define the use cases by
+which the OSLiC classifies its license fulfilling to-do lists:
Firstly we have to discriminate the usage of Open Source software by the nature
of the software itself:
Binary file not shown.

0 comments on commit 758c658

Please sign in to comment.