Browse Source

updating events, fla, follow-up-pdf, freesoftware basics

svn path=/trunk/; revision=23959
guest-sstavra 6 years ago
parent
commit
ee82b28d55
100 changed files with 10248 additions and 24 deletions
  1. 2
    2
      about/basics/freesoftware.el.xhtml
  2. 20
    0
      activities/ftf/fla.el.xhtml
  3. 31
    0
      campaigns/pdfreaders/follow-up.el.xhtml
  4. 21
    0
      events/2012/event-20120818-01.el.xml
  5. 25
    0
      events/2012/event-20120925-01.el.xml
  6. 19
    22
      freesoftware/basics/summary.el.xhtml
  7. 58
    0
      news/legal-news.el.xhtml
  8. BIN
      projects/os/201003-odt-questions.odt
  9. 164
    0
      projects/os/2012-06-uk-consultation-os.en.xhtml
  10. BIN
      projects/os/FSFE-response.questionnaire.pdf
  11. BIN
      projects/os/bsa-eif-letter-fsfe-response.pdf
  12. 400
    0
      projects/os/bsa-letter-analysis.de.xhtml
  13. 394
    0
      projects/os/bsa-letter-analysis.el.xhtml
  14. 162
    0
      projects/os/bsa-letter-analysis.en.xhtml
  15. 155
    0
      projects/os/bsa-letter-analysis.es.xhtml
  16. 154
    0
      projects/os/bsa-letter-analysis.pt.xhtml
  17. BIN
      projects/os/bsa-letter-ec.pdf
  18. 105
    0
      projects/os/bt-open-letter.en.xhtml
  19. 112
    0
      projects/os/def.de.xhtml
  20. 111
    0
      projects/os/def.el.xhtml
  21. 106
    0
      projects/os/def.en.xhtml
  22. 115
    0
      projects/os/def.es.xhtml
  23. 108
    0
      projects/os/def.et.xhtml
  24. 114
    0
      projects/os/def.fr.xhtml
  25. 104
    0
      projects/os/def.hr.xhtml
  26. 103
    0
      projects/os/def.it.xhtml
  27. 153
    0
      projects/os/def.nl.xhtml
  28. 67
    0
      projects/os/def.ro.xhtml
  29. 99
    0
      projects/os/def.ru.xhtml
  30. 77
    0
      projects/os/dfd.el.xhtml
  31. 46
    0
      projects/os/dfd.en.xhtml
  32. 85
    0
      projects/os/dfd.nl.xhtml
  33. 18
    0
      projects/os/document-msooxml-converter-hoax.de.xml
  34. 18
    0
      projects/os/document-msooxml-converter-hoax.el.xml
  35. 17
    0
      projects/os/document-msooxml-converter-hoax.en.xml
  36. 11
    0
      projects/os/document-msooxml-converter-hoax.fr.xml
  37. 17
    0
      projects/os/document-msooxml-converter-hoax.it.xml
  38. 16
    0
      projects/os/document-msooxml-converter-hoax.nl.xml
  39. 17
    0
      projects/os/document-msooxml-idiosyncrasies.el.xml
  40. 18
    0
      projects/os/document-msooxml-idiosyncrasies.en.xml
  41. 11
    0
      projects/os/document-msooxml-idiosyncrasies.fr.xml
  42. 18
    0
      projects/os/document-msooxml-idiosyncrasies.it.xml
  43. 20
    0
      projects/os/document-msooxml-idiosyncrasies.nl.xml
  44. 15
    0
      projects/os/document-msooxml-interoperability.de.xml
  45. 16
    0
      projects/os/document-msooxml-interoperability.el.xml
  46. 15
    0
      projects/os/document-msooxml-interoperability.en.xml
  47. 11
    0
      projects/os/document-msooxml-interoperability.fr.xml
  48. 21
    0
      projects/os/document-msooxml-interoperability.nl.xml
  49. 20
    0
      projects/os/document-msooxml-questions-for-ms.de.xml
  50. 20
    0
      projects/os/document-msooxml-questions-for-ms.el.xml
  51. 18
    0
      projects/os/document-msooxml-questions-for-ms.en.xml
  52. 12
    0
      projects/os/document-msooxml-questions-for-ms.fr.xml
  53. 18
    0
      projects/os/document-msooxml-questions-for-ms.it.xml
  54. 18
    0
      projects/os/document-msooxml-questions-for-ms.nl.xml
  55. 16
    0
      projects/os/document-msooxml-questions.de.xml
  56. 16
    0
      projects/os/document-msooxml-questions.el.xml
  57. 16
    0
      projects/os/document-msooxml-questions.en.xml
  58. 17
    0
      projects/os/document-msooxml-questions.es.xml
  59. 11
    0
      projects/os/document-msooxml-questions.fr.xml
  60. 16
    0
      projects/os/document-msooxml-questions.it.xml
  61. 16
    0
      projects/os/document-msooxml-questions.nl.xml
  62. 18
    0
      projects/os/document.de.xml
  63. 17
    0
      projects/os/document.el.xml
  64. 11
    0
      projects/os/document.en.xml
  65. 11
    0
      projects/os/document.fr.xml
  66. 11
    0
      projects/os/document.nl.xml
  67. 505
    0
      projects/os/eifv2-01.el.xhtml
  68. BIN
      projects/os/eifv2-01.en.pdf
  69. 437
    0
      projects/os/eifv2-01.en.xhtml
  70. 400
    0
      projects/os/eifv2-01.fr.xhtml
  71. BIN
      projects/os/eifv2-02.odt
  72. BIN
      projects/os/eifv2-02.pdf
  73. 662
    0
      projects/os/eifv2.el.xhtml
  74. BIN
      projects/os/eifv2.en.pdf
  75. 645
    0
      projects/os/eifv2.en.xhtml
  76. 540
    0
      projects/os/eifv2.fr.xhtml
  77. 46
    0
      projects/os/guardian-open-letter.en.xhtml
  78. 103
    0
      projects/os/leaflet-OS-about.de.xhtml
  79. 97
    0
      projects/os/leaflet-OS-about.el.xhtml
  80. 87
    0
      projects/os/leaflet-OS-about.en.xhtml
  81. 92
    0
      projects/os/leaflet-OS-about.es.xhtml
  82. 73
    0
      projects/os/leaflet-OS-about.fr.xhtml
  83. 80
    0
      projects/os/leaflet-OS-about.it.xhtml
  84. 118
    0
      projects/os/leaflet-OS-about.nl.xhtml
  85. 235
    0
      projects/os/minimalisticstandards.de.xhtml
  86. 205
    0
      projects/os/minimalisticstandards.en.xhtml
  87. 150
    0
      projects/os/msooxml-converter-hoax.de.xhtml
  88. 156
    0
      projects/os/msooxml-converter-hoax.el.xhtml
  89. 142
    0
      projects/os/msooxml-converter-hoax.en.xhtml
  90. 152
    0
      projects/os/msooxml-converter-hoax.es.xhtml
  91. 100
    0
      projects/os/msooxml-converter-hoax.fr.xhtml
  92. 137
    0
      projects/os/msooxml-converter-hoax.it.xhtml
  93. 163
    0
      projects/os/msooxml-converter-hoax.nl.xhtml
  94. 90
    0
      projects/os/msooxml-converter-hoax.sr.xhtml
  95. 261
    0
      projects/os/msooxml-idiosyncrasies.el.xhtml
  96. 243
    0
      projects/os/msooxml-idiosyncrasies.en.xhtml
  97. 147
    0
      projects/os/msooxml-idiosyncrasies.fr.xhtml
  98. 244
    0
      projects/os/msooxml-idiosyncrasies.it.xhtml
  99. 287
    0
      projects/os/msooxml-idiosyncrasies.nl.xhtml
  100. 0
    0
      projects/os/msooxml-idiosyncrasies.pdf

+ 2
- 2
about/basics/freesoftware.el.xhtml View File

@@ -151,8 +151,8 @@ FAQ</a>:
151 151
      <li><a href="/freesoftware/basics/sourcecode.html">Τι είναι 
152 152
      ο 'πηγαίος κώδικας';</a></li>
153 153
 
154
-    <li> <a href="/freesoftware/basics/openstandard.html">Τι είναι 
155
-    τα 'Ανοιχτά Πρότυπα';</a></li>
154
+    <li> <a href="/activities/os/os.html">Τι είναι τα 'Ανοιχτά Πρότυπα';</a>
155
+    </li>
156 156
 
157 157
     <li><a href="/freesoftware/basics/4freedoms.html">Πώς να εξηγήσετε
158 158
     τις τέσσερις ελευθερίες στα παιδιά</a></li>

+ 20
- 0
activities/ftf/fla.el.xhtml View File

@@ -13,6 +13,26 @@
13 13
 <p id="category"><a href="/activities/ftf/ftf.html">Νομικό Τμήμα</a></p> 
14 14
 <h1>Συμφωνητικό Εμπιστευτικότητας Άδειας Χρήσης (FLA)</h1>
15 15
 
16
+<!-- <h3>Περίληψη</h3>
17
+
18
+<p>Το Συμφωνητικό Εμπιστευτικότητας Άδειας Χρήσης (Fiduciary License 
19
+Agreement - FLA) είναι μία συμφωνία ανάμεσα στον κάτοχο του copyright 
20
+και στον θεματοφύλακα. Το FLA μεταφέρει κάποια από τα δικαιώματα χρήσης
21
+από τον κάτοχο των πνευματικών δικαιωμάτων στο θεματοφύλακα. Εκτός από
22
+μηχανισμός συλλογής το FLA αφορά την <i>ομαδοποίηση</i> των συμφερόντων
23
+των κατόχων copyright στον θεματοφύλακα (και όχι τη διανομή του προϊόντος).</p>
24
+
25
+<p>Η χρήση του λογισμικού διέπεται από τη συμφωνία άδειας χρήσης. Τα 
26
+προγράμματα ελεύθερου λογισμικού έχουν συνήθως περισσότερους από έναν κατόχους 
27
+πνευματικών δικαιωμάτων οι οποίοι εργάζονται συλλογικά σε κάθε πρόγραμμα. 
28
+Σε ενδεχόμενη παραβίαση της συμφωνίας άδειας χρήσης αυτά τα κατανεμημένα
29
+πνευματικά δικαιώματα ίσως να προκαλέσουν προβλήματα επειδή σε περίπτωση
30
+αγωγής ίσως απαιτηθεί η παρουσία όλων των κατόχων copyright.</p>
31
+
32
+<p>Το FLA συγκεντρώνει όλα τα δικαιώματα των κατόχων copyright 
33
+στο θεματοφύλακα. Τότε αυτός θα είναι σε θέση να προβάλλει τα συμφέροντα
34
+των κατόχων copyright στο δικαστήριο.</p> -->
35
+
16 36
 <h3>Τι είναι το FLA;</h3>
17 37
 
18 38
 <p>Το Συμφωνητικό Εμπιστευτικότητας Άδειας Χρήσης (Fiduciary Licence 

+ 31
- 0
campaigns/pdfreaders/follow-up.el.xhtml View File

@@ -26,6 +26,37 @@
26 26
 στις υπηρεσίες της χώρας σας ζητώντας τους να αφαιρέσουν τις διαφημιστικές
27 27
 καταχωρήσεις μη-ελεύθερου λογισμικού από τους ιστοχώρους τους.</p>
28 28
 
29
+<h2>Ελέγξτε πριν</h2>
30
+
31
+<p>Πριν ξεκινήσετε να στέλνετε μηνύματα αλληλογραφίας ρίξτε μια ματιά στον
32
+ιστότοπο της αναφερόμενης υπηρεσίας στη
33
+ <a href="/campaigns/pdfreaders/buglist.html">λίστα σφαλμάτων</a> και
34
+ελέγξτε αν έχουν αφαιρέσει τη διαφήμιση. Αν δεν δείτε διαφήμιση κάνετε
35
+τα ακόλουθα:</p>
36
+
37
+<ul>
38
+
39
+    <li>Εξετάστε με μια μηχανή αναζήτησης αν κάποια άλλη λέξη "adobe" ή
40
+    "acrobat" υπάρχει στον τομέα, (π.χ. με site:www.exmaple.com). Αν βρεθεί
41
+    κάποιο, ενημερώστε τη λίστα σφαλμάτων με το νέο URL στο "bugs-XY.xml" 
42
+    (μπορείτε να στείλετε και μήνυμα στην
43
+    <a href="mailto:web@fsfeurope.org">ομάδα ιστού</a> αν δεν έχετε πρόσβαση
44
+    για τροποποίηση του ιστοτόπου).</li>
45
+
46
+    <li>Αν δεν υπάρχει καμία, γράψτε στο <a
47
+      href="mailto:pdfreaders@lists.fsfe.org">pdfreaders@lists.fsfe.org</a>,
48
+    αναφέρετε την επιτυχία σας και ζητήστε να σημειωθεί το σφάλμα 
49
+    ως διορθωμένο.</li>
50
+
51
+    <li>Έπειτα γράψτε ένα μικρό ευχαριστήριο μήνυμα στη δημόσια υπηρεσία.</li>
52
+
53
+</ul>
54
+
55
+<p>Αν η διαφήμιση είναι ακόμη ορατή στον ιστότοπο της δημόσιας υπηρεσίας
56
+μπορείτε να δραστηριοποιηθείτε στέλνοντάς τους μήνυμα <a
57
+  href="/campaigns/pdfreaders/letter.html">με βάση το υπόδειγμα επιστολής 
58
+μας</a>.</p>
59
+
29 60
 <h2>Να είστε πάντα ευγενικοί</h2>
30 61
 
31 62
 <p>Ο θυμός δεν θα βοηθήσει καθόλου. Στείλαμε μια επιστολή που περιείχε μια

+ 21
- 0
events/2012/event-20120818-01.el.xml View File

@@ -0,0 +1,21 @@
1
+<?xml version="1.0" encoding="utf-8" ?>
2
+<eventset>
3
+   <event start="2012-08-18" end="2012-08-19">
4
+        <title>OggCamp 2012 Λίβερπουλ</title>
5
+        <body>
6
+		Το FSFE για ακόμη μία φορά θα έχει παρουσία στο Ogg Camp 
7
+        με πληροφορίες, εμπορεύματα, φυλλάδια και την ευκαιρία εγγραφής.
8
+        Ελάτε και μιλήστε με τα Μέλη και τον συντονιστή του FSFE για το 
9
+        Ηνωμένο Βασίλειο.
10
+        </body>
11
+	<link>http://oggcamp.org/</link>
12
+        <tags>
13
+             <tag>front-page</tag>
14
+             <tag>gb</tag>
15
+             <tag>fellowship</tag>
16
+             <tag>liverpool</tag>
17
+	     <tag>booth</tag>
18
+	     <tag>oggcamp</tag>
19
+        </tags>
20
+   </event>
21
+</eventset>

+ 25
- 0
events/2012/event-20120925-01.el.xml View File

@@ -0,0 +1,25 @@
1
+<?xml version="1.0" encoding="UTF-8"?>
2
+
3
+<eventset>
4
+  <event start="2012-09-25" end="2012-09-25">
5
+    <title>World Computer Congress: Πώς οι πατέντες λογισμικού 
6
+    καθυστερούν το μέλλον</title>
7
+    <body>
8
+      <p>
9
+Στις 25 Σεπτεμβρίου στο 22ο IFIP World Computer Congress στο Άμστερνταμ,
10
+στην Ολλανδία, ο Karsten Gerloff θα συμμετάχει σε μια συζήτηση ειδικών 
11
+για τις πατέντες στο λογισμικό. Η συζήτηση σχετικά με το αν «οι πατέντες
12
+προάγουν την καινοτομία στο πεδίο του λογισμικού υπολογιστών» διοργανώνεται
13
+από το European Patent Organisation.
14
+      </p>
15
+    </body>
16
+    <page>http://www.wcc-2012.org/</page>
17
+    <tags>
18
+      <tag>swpat</tag>
19
+      <tag>patents</tag>
20
+      <tag>policy</tag>
21
+      <tag>nl</tag>
22
+      <tag>front-page</tag>
23
+    </tags>
24
+  </event>
25
+</eventset>

+ 19
- 22
freesoftware/basics/summary.el.xhtml View File

@@ -10,21 +10,27 @@
10 10
     <h1>Ελεύθερο Λογισμικό</h1>
11 11
   </div>
12 12
 
13
-<p><a href="http://www.fsfe.org/about/basics/freesoftware.html">Ελεύθερο Λογισμικό</a> είναι το λογισμικό που
14
-εγγυάται ένα σύνολο ελευθεριών για τον κάτοχό του. Είναι «ελεύθερο» όπως στην ελευθερία και όχι δωρεάν με την
15
-απόδοση της έκφρασης free beer. Για την αποφυγή της σύγχυσης, άλλα ονόματα εμφανίστηκαν, όπως Ανοικτός Κώδικας,
16
-Libre Software, FOSS, FLOSS... Στο FSFE, <a href="http://www.fsfe.org/documents/whyfs.html">προτιμάμε να μιλάμε
17
-για «Ελεύθερο Λογισμικό»</a> επειδή αυτός ο όρος αντανακλά καλύτερα τη βασική φιλοσοφία με τις 
18
-<a href="http://www.fsfe.org/freesoftware/basics/4freedoms.html">τέσσερις ελευθερίες του Ελεύθερου Λογισμικού</a>.
13
+<p><a href="http://www.fsfe.org/about/basics/freesoftware.html">Ελεύθερο 
14
+Λογισμικό</a> είναι το λογισμικό που εγγυάται ένα σύνολο ελευθεριών για τον 
15
+κάτοχό του. Είναι «ελεύθερο» όπως στην ελευθερία, όχι με την έννοια του δωρεάν.
16
+Αν και <a href="/about/basics/freesoftware.html#terminology">μια ποικιλία 
17
+όρων</a> χρησιμοποιούνται για να αποδοθεί η σημασία αυτή, στο FSFE 
18
+<a href="/documents/whyfs.en.html">προτιμάμε να μιλάμε για ελεύθερο λογισμικό
19
+</a> επειδή έτσι αντανακλάται καλύτερα η φιλοσοφία σχετικά με τις 
20
+<a href="/freesoftware/basics/4freedoms.en.html">τέσσερις ελευθερίες</a> 
21
+οι οποίες είναι εγγενείς σε αυτό.
19 22
 </p>
20 23
 
21
-<p>Το κίνημα του Ελεύθερου Λογισμικού προέρχεται από τον Richard Stallman το 1983 όταν εγκαινίασε το 
22
-<a href="http://www.fsfe.org/freesoftware/basics/gnuproject.html">GNU project</a>. Στηρίχθηκε στην ιδέα
23
-ότι ο χρήστης αποκτά ισχύ αν έχει πλήρη έλεγχο στο λογισμικό που αγοράζει, και για αυτό χρειάζεται, ανάμεσα
24
-στα άλλα, να έχει πρόσβαση στον <a href="http://www.fsfe.org/freesoftware/basics/sourcecode.html">πηγαίο κώδικα</a>.
25
-Πέρα από την εργασία στο λογισμικό, ο αγώνας για την υιοθέτηση του ελεύθερου λογισμικού έχει επεκταθεί 
26
-και στον αγώνα για την υιοθέτηση νόμων για τα 
27
-<a href="http://www.fsfe.org/freesoftware/basics/openstandard.html">ανοικτά πρότυπα</a>.</p>
24
+<p>Το κίνημα του Ελεύθερου Λογισμικού ξεκίνησε με τον Richard Stallman το 1983 
25
+όταν εγκαινίασε το 
26
+<a href="/freesoftware/basics/gnuproject.html">GNU project</a>. Στηρίχθηκε 
27
+στην ιδέα ότι οι άνθρωποι πρέπει να έχουν πλήρη έλεγχο στο λογισμικό που 
28
+κατέχουν. Ο Stallman αντιλήφθηκε ότι για να είναι αυτό εφικτό, η πρόσβαση στον 
29
+<a href="/freesoftware/basics/sourcecode.html">πηγαίο κώδικα</a> του 
30
+προγράμματος ενός υπολογιστή είναι μια θεμαλιώδης απαίτηση. Πέρα από το πεδίο 
31
+της βιομηχανίας υπολογιστών, ο αγώνας για την υιοθέτηση του ελεύθερου 
32
+λογισμικού έχει επεκταθεί και στον αγώνα για την υιοθέτηση νόμων για τα 
33
+<a href="/freesoftware/basics/openstandard.html">ανοιχτά πρότυπα</a>.</p>
28 34
 
29 35
    <div class="related">
30 36
 
@@ -59,15 +65,6 @@ Libre Software, FOSS, FLOSS... Στο FSFE, <a href="http://www.fsfe.org/documen
59 65
 
60 66
   </ul>
61 67
 
62
-<!--h2>Κείμενα ομιλιών</h2>
63
-
64
-<ul>
65
-<li><a href="/freesoftware/transcripts/rms-2009-05-22-eliberatica.html">Διάλεξη του Richard Stallman
66
-       στο Βουκουρέστι στις 22 Μαΐου 2009</a></li>
67
-<li><a href="/freesoftware/transcripts/rms-fs-2006-03-09.html">Διάλεξη του Richard Stallman στο Ζάγκρεμπ
68
-       στις 9 Μαρτίου 2006</a></li>
69
-</ul-->
70
-
71 68
  </div>
72 69
 
73 70
  </body>

+ 58
- 0
news/legal-news.el.xhtml View File

@@ -0,0 +1,58 @@
1
+<?xml version="1.0" encoding="utf-8" ?>
2
+
3
+<html>
4
+  <head>
5
+    <title>Αρχειοθήκη Νομικών Ειδήσεων – FSFE</title>
6
+  </head>
7
+  <body>
8
+    <h1>Αρχειοθήκη Νομικών Ειδήσεων</h1>
9
+
10
+    <p id="introduction">
11
+Η σελίδα αυτή συλλέγει όλες τις ειδήσεις νομικού ενδιαφέροντος που 
12
+δημοσιεύονται στον ιστοχώρο του FSFE. Στις Νομικές Ειδήσεις συλλέγουμε
13
+ενδιαφέροντες συνδέσμους για την αδειοδότηση Ελεύθερου Λογισμικού,
14
+για ζητήματα σχετικά με επιχειρήσεις Ελεύθερου Λογισμικού, για πατέντες
15
+λογισμικού, για την Κυβέρνηση και για πολιτικές για το Ελεύθερο Λογισμικό,
16
+για τα Ανοιχτά Πρότυπα και τη Δικτυακή Ουδετερότητα.
17
+    </p>
18
+  
19
+    <legal-news/>
20
+  
21
+<h2>Σχετικά με τις Ειδήσεις Νομικού Ενδιαφέροντος για το Ελεύθερο Λογισμικό</h2>
22
+ 
23
+  	<h2 id="subpages">Πλοήγηση</h2>
24
+  
25
+    <ul>
26
+
27
+    
28
+      <li>
29
+        <h3><a href="/news/legal-news.html">Στείλτε Νομικές Ειδήσεις</a></h3>
30
+        <p>Σύνδεσμοι σχετικα με την ειδησεογραφία για το Ελεύθερο Λογισμικό
31
+        συλλέγονται και μετά από επεξεργασία δημοσιεύονται σε εβδομαδιαία βάση
32
+        για την παρακολούθηση σημαντικών νομικών ζητημάτων. Καλωσορίζουμε
33
+        την υποβολή ειδήσεων με συνδέσμους σε μηνύματα αλληλογραφίας στο
34
+        legal-news at fsfeurope dot org</p>
35
+      </li>
36
+    
37
+	  	<li>
38
+        <h3><a href="/activities/ftf/ftf.html">FSFE Νομικό Τμήμα - 
39
+        Η Ομάδα Εργασίας Ελευθερίας</a></h3>
40
+        <p>
41
+Το FSFE έχει δεσμευτεί να βοηθά άτομα, έργα, επιχειρήσεις και δημόσιες 
42
+υπηρεσίες στην εξεύρεση για το Ελεύθερο Λογισμικό νομικής πληροφόρησης, 
43
+ειδικών και υποστήριξης. Αποστολή μας είναι η διάδοση της γνώσης,
44
+η επίλυση προβλημάτων και η ενθάρρυνση της μακροπρόθεσμης ανάπτυξης του
45
+Ελεύθερου Λογισμικού.
46
+        </p>
47
+      </li>
48
+</ul>
49
+
50
+  </body>
51
+  
52
+  <timestamp>$Date: 2011-04-22 17:37:47 +0200 (ven. 22 avril 2011) $ $Author: ato $</timestamp>
53
+</html>
54
+<!--
55
+Local Variables: ***
56
+mode: xml ***
57
+End: ***
58
+-->

BIN
projects/os/201003-odt-questions.odt View File


+ 164
- 0
projects/os/2012-06-uk-consultation-os.en.xhtml View File

@@ -0,0 +1,164 @@
1
+<?xml version="1.0" encoding="UTF-8" ?>
2
+
3
+<html>
4
+  <head>
5
+    <title>FSFE's submission to the UK Open Standards Consultation 2012</title>
6
+<meta content="FSFE's submission to the UK Open Standards Consultation 2012" name="description" />
7
+<meta content="Open standards UK submission ICT Futures team Cabinet Office European interoperability framework Declaration on Standards Future of the Internet Document Freedom Day Definition Emerging Standards FSFE" name="keywords" />
8
+  </head>
9
+
10
+  <body>
11
+ <p id="category"><a href="http://www.fsfe.org/projects/work.html">Our Work</a> / <a href="/projects/os/os.html">Overview of Open Standards</a></p>
12
+    <h1>Submission to UK Open Standards Consultation 2012</h1>
13
+
14
+<div id="introduction">
15
+
16
+    <p>This is FSFE's submission to the <a href="http://consultation.cabinetoffice.gov.uk/openstandards/">UK Open Standards Consultation</a>, held by the ICT Futures team in Cabinet Office, submitted on 1st June 2012.</p>
17
+</div>
18
+
19
+    <h2>Chapter 1: Criteria for Open Standards</h2>
20
+
21
+	<h3>1. How does this definition of open standard compare to your view of what makes a standard 'open'?</h3>
22
+
23
+<h4>What exactly is a "government body"?</h4>
24
+
25
+<p>FSFE supports the content of the proposed definition, but some details in wording still have to be clarified, in order to ensure that the policy can be implemented effectively: </p>
26
+
27
+<blockquote> 1. Government bodies must consider open standards for software interoperability, data and document formats and in procurement specifications should require solutions that comply with open standards, unless there are clear, documented business reasons why this is inappropriate.</blockquote>
28
+
29
+<p>First, it is not clear what is meant by a “government body”. We fear that in the end just a small subset of public bodies will be covered by this term, and consequently by the policy.</p>
30
+<p>Software and in particular document formats are subject to strong network effects, and one government body using proprietary formats might cause problems for many others using formats based on Open Standards.If an Open Standards policy is to be effective, it needs to address the largest possible set of organisations. We therefore propose to use “Public bodies or private bodies exercising public functions” instead of “government bodies”.</p>
31
+<p>Furthermore, it is not clear from the available policy documents which public bodies will be within the scope of the policy. According to information provided by Cabinet Office representative Linda Humphries in a meeting on Open Standards and Leveling the Playing Field on May 29, 2012, the policy would only apply to central government bodies, not local governments or other government bodies. She also remarked that the G-Cloud Strategy would not be covered by the policy.</p>
32
+<p>This limited reach would severely constrain the effectiveness of the policy, and heavily curtail the benefits it will provide. Local authorities, the education and health sectors, and a plethora of other public bodies will continue to be locked into overpriced, proprietary solutions, and lack guidance and support from central government to build vendor-independent IT systems. Small and medium IT companies will continue to be excluded from most of the public-sector market, as public-sector IT spending will remain heavily concentrated on a small number of large systems integrators.</p>
33
+<p>These problems will be even more severe where the G-Cloud is concerned. If this central service is built on anything else than Open Standards, this will compound the current set of problems (concentrated procurement, vendor lock-in, amplified by network effects, leading to a lack of competition) for the entire UK public sector, and make it even more difficult for public bodies to pursue IT strategies which are orientated towards long-term sustainability and value for money. Given the network effects described above, the policy will only be effective if a broad set of government bodies are compelled to move to Open Standards.</p>
34
+<p>Procurement teams will also require training in dealing with legacy software solutions, and breaking free from vendor lock-in. Without a proactive effort by the government, widespread vendor lock-in will all but guarantee the policy's failure.</p>
35
+<p>The proposed "comply or explain" approach is largely suitable. However, we strongly recommend that compliance should be determined, and explanations provided, *before* the procurement actually proceeds. Once tenders are published and contracts are signed, corrections and alternative approaches are infinitely harder to implement.</p>
36
+<p>Therefore, we propose the following wording:</p>
37
+
38
+<blockquote> 1. [Public bodies or private bodies exercising public functions] must [use] open standards for software interoperability, data and document formats and in procurement specifications should require solutions that comply with open standards, unless there are clear, documented business reasons why this is inappropriate. </blockquote>
39
+
40
+<p>It should however be made very clear that the fact that an organisation is currently subject to vendor lock-in on account of its use of proprietary formats is not a "clear, documented business reason" to refuse adopting Open Standards. UKG should provide education and assistance for overcoming the obstacles of current vendor lock-in to public bodies and private bodies exercising public functions.</p>
41
+<p>This provides a strong impulse for change in line with the intent of the policy, while still preserving an option for those public bodies which are for some reason unable (rather than merely unwilling) to move to Open Standards.</p>
42
+
43
+<h4>Licensing of patents in standards</h4>
44
+<p>In </p>
45
+
46
+<blockquote> 2. For the purpose of UK Government software interoperability, data and document formats, the definition of open standards is those standards which fulfill the following criteria: [...]</blockquote>
47
+
48
+<p>FSFE sees problems in the following part of the definition:</p>
49
+
50
+<blockquote>owners of patents essential to implementation have agreed to license these on a royalty free and non-discriminatory basis for implementing the standard and using or interfacing with other implementations which have adopted that same standard. Alternatively, patents may be covered by a non-discriminatory promise of non-assertion.</blockquote>
51
+
52
+<p>Royalty-free (and restriction-free) licensing of patents contained in standards is the norm in IT, and more so in software standardisation. In software, so-called "FRAND" ("Fair, Reasonable And Non-Discriminatory) licensing of patents necessary to implementing a standard puts the patent holder in control of an entire product category, and is therefore inimical to competition and innovation in the market.</p>
53
+<p>In particular, FRAND licensing is incompatible with the most widely used Free Software licenses, such as the GNU General Public License. Even in a hypothetical approach where patent royalty rates would be set to zero, the patent holder (usually a large corporation) would still be able to refuse a patent license to a Free Software project, or impose conditions which effectively prevent the project from implementing the standard. Even though recourse through the legal system might be available in theory, in practice the Free Software developers (often small companies) will rarely have the required resources to confront a multinational corporation in court.</p>
54
+<p>It is therefore essential that UKG insists that patents included in standards for software are made available to any interested party without licensing fees or restrictions.</p>
55
+
56
+<h3>2. What will the Government be inhibited from doing if this definition of open standards is adopted for software interoperability, data and document formats across central government?</h3>
57
+
58
+<p>If the Government adopts a definition of Open Standards along the lines of what we propose in response to question 1, this would greatly increase the freedom of action which public bodies and private bodies exercising public functions - enjoy.</p>
59
+<p>The only restriction they would suffer is that they would no longer be at liberty to lock themselves into proprietary formats owned by a single vendor; this can only be considered a good thing. In cases where there is currently no Open Standard available, or where it is not feasible to use, the policy provides sufficient alternative options ("comply or explain", which should be a step taken before a public body releases a call for tender.)</p>
60
+<p>If, however, application of the policy is restricted to central government alone, this will lead to severe interoperability problems with the rest of the UK's public sector, which remains mired in vendor lock-in. We recommend that UKG should take a bolder stance, apply the policy as widely as possible, and take steps to enable all public sector organisations to implement it.</p>
61
+
62
+<h3>3. For businesses attempting to break into the government IT market, would this policy make things easier or more difficult - does it help to level the playing field?</h3>
63
+
64
+<p>Adopting the proposed policy including FSFE's amendments (see Question 1) would be a significant step towards leveling the playing field. Today, 60% of revenue from central government contracts goes to only 10 or so systems integrators. It is not acceptable for the government to pick winners in this fashion. </p>
65
+<p>The policy, if implemented in full, will be an important step towards opening the UK's public sector IT market to competition. A comprehensive Open Standards policy would greatly lower the bar for UK businesses, in particular smaller ones, to compete for government contracts. In addition, Open Standards naturally circumvent vendor lock-in and therefore guarantee the freedom of choice for future government procurement and a vivid competition inside the government IT market.</p>
66
+
67
+<h3>5. What effect would this policy have on improving value for money in the provision of government services?</h3>
68
+
69
+<p>The policy would substantially open up competition for government business as Open Standards can be implemented by the widest possible range of software suppliers. For the buyers, this means lower prices, and better quality. The absence of a vendor lock-in would allow government bodies to switch suppliers comparatively easily.</p>
70
+<p>By making it easy to move from one supplier to another, Open Standards guarantee maximum choice for customers This, in turn, leads to improved performance as vendors compete to keep government customers loyal. </p>
71
+<p>In addition, using Open Standards will boost innovation, as new products can be based on existing ones. Innovation in software development is, and has always been, largely incremental, building on improvements made by others. Open Standards make these incremental innovations a lot easier, accelerating the rate of innovation, which will in turn lead to better products on the market.</p>
72
+<p>The technologies that make up the Internet are best examples of an infrastructure which is built upon non-restrictive and royalty-free standards, thus enabling Free Software as well as proprietary programs to compete in the most vibrant and innovative environment.</p>
73
+
74
+<h3>6. Would this policy support innovation, competition and choice in delivery of government services? </h3>
75
+<p>The openness of standards for software, document formats and data is critical in this respect. Since Open Standards can be implemented without restrictions, the proposed policy would greatly contribute to supporting innovation, competition and choice in the delivery of government services. Standards provide a platform on top of which businesses can compete, and Open Standards mean that there is no limit to the number and approaches which businesses can take to satisfy government needs.</p>
76
+<p>If public data, for example, is published or delivered in formats based on Open Standards, this makes it possible for anyone to build innovative software to interact with this data. This will enable citizens to take the initiative and develop applications to suit their needs and those of their communities.</p>
77
+<p>As explained above, the policy would be key to introducing real competition into the market for public sector IT service contracts in the UK. Currently, most of the UK's public bodies are tied to a small number of large vendors, many of which are headquartered outside the UK. </p>
78
+<p>If the policy is implemented in full, across all public bodies and private bodies exercising public functions, together with suitable training and education for procurement staff, it will become possible for a large number of UK businesses (both existing and new) to compete for public sector IT contracts, as barriers to market entry will decrease significantly. </p>
79
+
80
+<h3>7. In what way do software copyright licences and standards patent licences interact to support or prevent interoperability? </h3>
81
+<p>As explained above, FRAND licensing of patents in standards for software, data and document formats is incompatible with the most widely used Free Software licenses. At the same time, many of the main competitors to dominant programs in the market are Free Software. Deciding which patent licensing policies to accept in standards therefore turns into a choice between a free market and one dominated by an oligopoly. </p>
82
+<p>To ensure software interoperability, copyright and patent licenses may only be included in an Open Standard under a non-restriction and non-assertion license. Otherwise this standard will exclude Free Software from using it and is not in any sense interoperable. (F)RAND licensing thereby prevents interoperability. Royalty-free licenses on the other hand are free to use, also for Free Software and therefore strongly support interoperability. Please see Question 8 for a more detailed analysis.</p>
83
+
84
+
85
+<h3>8. How could adopting (Fair) Reasonable and Non Discriminatory ((F)RAND) standards deliver a level playing field for open source and proprietary software solution providers? </h3>
86
+
87
+<p>(F)RAND standards cannot deliver a level playing field for participants in the software market because most (F)RAND standards require a royalty fee to be paid for each copy of a program that is distributed. Paying royalties of even a single penny per copy or less to implement a standard might appear "fair" to someone not familiar with the problem. </p>
88
+<p>In addition, and maybe even more important, per-copy royalties are fundamentally incompatible with the GNU GPL, which is the most widely used Free Software license [See <a href="http://osrc.blackducksoftware.com/data/licenses/">statistic of “Top 20 Most Commonly Used Licenses in Open Source Projects”</a>] and covers key programs such as the Linux kernel and much of the GNU operating system. Moreover, such royalties are fundamentally incompatible with most of the Free Software licenses out there. According to the quantity of usage of different licenses, more than 80% of Free Software projects are distributed under licenses that are incompatible with patent royalty-bearing regimes. In reality, (F)RAND is unfair, unreasonable, and highly discriminatory against all Free Software.</p>
89
+<p>The only solution that enables full competition is "zero-royalty" or "royalty-free" licensing for patents included in standards for software, data, and document formats. Because "zero-royalty" does not exclude Free Software from using the standard nor does it exclude proprietary (or even heavily patented) implementations. Indeed, "Zero-royalty" means that if certain technologies are mandated by a standard, they must be available to everybody without requiring running royalties. Meanwhile the implementations can be distributed under any given license and include any technology, provided that the standard is respected.</p>
90
+<p>The exponential growth of the Internet and the World Wide Web, which are built entirely on the basis of restriction-free standards, clearly demonstrate the potential that the policy can unleash if UKG sticks to <a href="http://fsfe.org/projects/os/def.en.html">a definition of Open Standards that makes them available for implementation to all interested parties without restrictions</a>.</p>
91
+
92
+<h3>9. Does selecting open standards which are compatible with a free or open source software licence exclude certain suppliers or products? </h3>
93
+<p>Open Standards do not exclude anyone. On the contrary, since they can be implemented by anyone, they open up the market to all players.</p>
94
+<p>Since by definition, there are no restrictions on implementing an Open Standard, developers of proprietary software have the option of including support for the relevant interfaces or file formats in their programs, at no cost beyond that of the implementation itself. Claims that requiring Open Standards would exclude one group of suppliers are generally without merit.</p>
95
+
96
+<h3>10. Does a promise of non-assertion of a patent when used in open source software alleviate concerns relating to patents and royalty charging? </h3>
97
+<p>Businesses serving government need a firm legal basis to build upon. While a promise not to assert a patent is generally a friendly gesture by the patent holder, it is no replacement for a clear policy requirement for Open Standards, which can be implemented without royalty payments or restrictions. Promises of non-assertion may eventually be rescinded (e.g. when the patents it covers are sold to another company). </p>
98
+
99
+<h3>12. In terms of standards for software interoperability, data and document formats, is there a need for the Government to engage with or provide funding for specific committees/bodies? </h3>
100
+<p>Regarding UKG's approach of setting up an Open Standards Board to steer the implementation of the policy, we consider it essential that discussions of the board are conducted in a transparent fashion. In order to ensure participation is not limited to representatives of the current large suppliers, there needs to be the opportunity for representatives of smaller companies to participate in the board and exercise equal influence. Board discussions need to be structured in a way that minimises the time burden especially on representatives of small companies. UKG should consider setting up a mechanism to encourage and support the participation of smaller companies in the board.</p>
101
+
102
+<h2>Chapter 2: Open standards mandation</h2>
103
+
104
+<h3>1. What criteria should the Government consider when deciding whether it is appropriate to mandate particular standards?</h3>
105
+<p>Where it mandates a particular standard for software, data, or document formats, government must make sure that the standard is an Open Standard -- it must carry no restrictions on implementation, and must not require the implementer to pay patent royalties.</p>
106
+
107
+<h3>4. Could mandation of competing open standards for the same function deliver interoperable software and information at reduced cost? </h3>
108
+<p>Competition takes place on top of standards, not between standards. Competition on top of a standard removes barriers, increases interoperability and customer choice. Competition between standards reduces interoperability, fragments the market, and leads to vendor lock-in.</p>
109
+<p>For example, the frequency used in alternating-current (AC) electricity networks -- 50 Hz -- is largely arbitrary. It might be equally possible to use a frequency of 40 Hz, or 70 Hz, instead. What is important is that everyone connecting to the network -- electricity generators as well as users -- use the same frequency. </p>
110
+<p>If government decides to mandate standards, it would be best by recommending an initial set of Open Standards. These standards must strictly conform to the definition and should come with a large number of implementations, in order to provide a basis on which the policy can be successfully implemented. Other Open Standards can be added to this list at a later date.</p>
111
+
112
+<h3>5. Could mandation of open standards promote anti-competitive behaviour in public procurement? </h3>
113
+<p>Mandating Open Standards could not conceivably lead to anticompetitive behaviour in the software market. Quite to the contrary, they are the best way to open up competition in the software market. Since Open Standards carry no restrictions on implementation, smaller implementers (all else being equal) are in a better position to challenge incumbents. Conversely, standards with restrictions on their implementation have long been shown to foster anticompetitive behaviour (e.g. Microsoft's proprietary .doc format).</p>
114
+
115
+<h3>7. How should the Government best deal with the issue of change relating to legacy systems or incompatible updates to existing open standards? </h3>
116
+<p>Legacy systems and file formats are a cost factor in any case. Even with proprietary software and formats, new versions of a program frequently are unable to properly process older versions of what is notionally the same file format. Extracting data and converting files into new formats is a significant task in any IT migration. An organisation that adopts Open Standards will only have to do this once in order to move its files to a format that is fully and publicly documented. Thereafter, it is easy to use (and if necessary build) tools to convert files from one open format to another as needed.</p>
117
+<p>However, UKG should be clear about the fact that breaking free from vendor lock-in will require an initial effort. Experience from numerous other countries in Europe and around the world shows that policies such as the one proposed can only be implemented if the people who are supposed to implement them -- procurement and IT teams in public bodies and private organisations exercising public functions -- receive training and assistance. </p>
118
+<p>The costs of these efforts (which are really costs that the user organisation incurred at the time it chose a proprietary IT solution or document format) will be quickly offset by savings realised by buyers in a more competitive IT service market.</p>
119
+
120
+<h3>9. How should the Government strike a balance between nurturing innovation and conforming to standards? </h3>
121
+<p>This is the wrong question to ask. There is no balance to be struck. Standards, and Open Standards in particular, provide a basis for innovation because innovation happens on top of standards, not within standards. The great innovation space that is the Internet is based on a set of Open Standards that have either remained unchanged for decades, or have been updated slowly and carefully. It is exactly this "conservative" approach to standards that has turned the Internet into the basis of a huge number of innovations.</p>
122
+<p>UK government would therefore best encourage innovation by relying on well-established Open Standards, and pushing for them to be used across the entire UK public sector. This will remove the barriers to innovation presented by proprietary formats and interfaces, and allow market participants to innovate and build tomorrow's solutions. </p>
123
+
124
+<h3>11. Are there any are other policy options which would meet the objective more effectively? </h3>
125
+<p>A strong mandate for Open Standards, together with an overhaul of procurement practices, is the single best policy option on the table to increase the government's value for money, and promote innovation in the software sector.</p>
126
+<p>To guarantee these benefits, there should be a mechanism to give recognition to those public bodies which follow the policy. At the same time, public bodies which fail to follow the policy need to be identified, and actively encouraged to adhere to the policy in future. For example, there could be a peer-review procedure for some of the body's tenders. At the same time, UKG needs to ensure that bidders who were excluded due to a body's failure to adhere to the policy have an easy, low-cost route to challenging the tenders concerned.</p>
127
+<p>Regarding UKG's approach of setting up an Open Standards Board to steer the implementation of the policy, we consider it essential that discussions of the board are conducted in a transparent fashion. In order to ensure participation is not limited to representatives of the current large suppliers, there needs to be the opportunity for representatives of smaller companies to participate in the board and exercise equal influence. Board discussions need to be structured in a way that minimises the time burden especially on representatives of small companies. UKG should consider setting up a mechanism to encourage and support the participation of smaller companies in the board.</p>
128
+
129
+
130
+<h2>Chapter 3: International alignment</h2>
131
+
132
+<h3>Is the proposed UK policy compatible with European policies, directives and regulations (existing or planned) such as the European Interoperability Framework version 2.0 and the reform proposal for European Standardisation?</h3>
133
+<p>The proposed policy is not only fully compatible with European policies, regulations and directives. It faithfully transposes what the European Interoperability Framework has to say with regard to Open Standards into actionable national policy. The relevant parts of the EIF in turn build on the Ministerial Declarations made in Malmo and Granada, highlighting the need for all EU member states to produce compatible national interoperability frameworks by 2013.</p>
134
+<p>The policy is also in line with the Digital Agenda for Europe, in particular the actions concerning the European Interoperability Framework (24, 25, 26, 27), the ICT procurement guidelines (Action 23), the Horizontal guidelines (22) and the European Standardisation Reform (21).</p>
135
+
136
+<h3>Will the open standards policy be beneficial or detrimental for innovation and competition in the UK and Europe?</h3>
137
+<p>The Open Standards policy, if implemented effectively across the UK's public sector and including private organisations exercising public functions, would be highly beneficial for innovation and competition in the IT markets of the UK and Europe. </p>
138
+<p>Applied in this fashion, the policy would open up the UK market to full competition, lowering prices and increasing performance across the board.</p>
139
+<p>Without a broad application of the policy, however, we fear that the policy will have little impact in practice. The UK's public bodies would then continue to suffer from vendor lock-in, and spending funds provided by UK taxpayers on overpriced proprietary IT solutions rather than more essential public services. The IT service market in the UK would remain highly concentrated, with more than 60% of public-sector contracts going to only 10 or so large suppliers and systems integrators. Finally, the Cabinet Office itself, having put such commendable efforts behind developing this policy, would lose quite a bit of credibility in the eyes of the IT industry, which may harm its negotiating position in future.</p>
140
+
141
+<h3>Are there any are other policy options which would meet the objectives described in this consultation paper more effectively?</h3>
142
+<p>The proposed policy seems largely suitable, if the modifications proposed in our response are implemented. Based on experience gained in other countries (e.g. Sweden, Italy, Spain, Germany, the Netherlands, and others), it will be essential for the policy's success that the government invests in training those who will have to implement the policy around the UK public sector, and in making it possible for them to receive advice on an ongoing basis.</p>
143
+<p>There should be a mechanism to give recognition to those public    bodies which follow the policy. At the same time, public bodies which fail to follow the policy need to be identified, and actively encouraged to adhere to the policy in future. For example, there    could be a peer-review procedure for some of the body's tenders. At the same time, UKG needs to ensure that bidders who were excluded    due to a body's failure to adhere to the policy have an easy, low-cost route to challenging the tenders concerned.</p>
144
+<p>Sweden's approach of public-sector framework contracts for the procurement of Free Software has proved successful, and should be adopted in the UK. This approach has greatly helped to broaden IT choice for Sweden's public-sector buyers, and has provided them with an easy way to exercise that choice in practice.</p>
145
+<p>Free Software use in the UK lags far behind the rest of Europe. The UK now is in the happy position to avail itself of the benefits of Free Software, while being able to learn from the experience of others. For the benefit of its citizens and businesses, the UK government should seize this opportunity.</p>
146
+
147
+<h2>For further information about FSFE's work on Open Standards:</h2>
148
+<ul>
149
+	<li><a href="http://fsfe.org/projects/os/def.en.html">FSFE`s definition of Open Standards</a></li>
150
+	<li><a href="http://fsfe.org/projects/os/os.en.html">Overview of FSFE`s work on Open Standards</a></li>
151
+	<li><a href="http://fsfe.org/projects/os/ps.en.html">Analysis on balance: Standardisation and Patents</a></li>
152
+	<li><a href="http://fsfe.org/projects/os/bsa-letter-analysis.en.html">Defending Open Standards: FSFE refutes BSA's false claims to European Commission</a></li>
153
+	<li><a href="http://fsfe.org/projects/igf/sovsoft.en.html">Open Standards, Free Software, and the Internet</a></li>
154
+</ul>
155
+
156
+  </body>
157
+
158
+  <timestamp>$Date: 2012-04-21 17:12:14 +0200 (Sat, 21 Apr 2012) $ $Author: samtuke $</timestamp>
159
+</html>
160
+<!--
161
+Local Variables: ***
162
+mode: xml ***
163
+End: ***
164
+-->

BIN
projects/os/FSFE-response.questionnaire.pdf View File


BIN
projects/os/bsa-eif-letter-fsfe-response.pdf View File


+ 400
- 0
projects/os/bsa-letter-analysis.de.xhtml View File

@@ -0,0 +1,400 @@
1
+<?xml version="1.0" encoding="UTF-8" ?>
2
+
3
+<html>
4
+  <head>
5
+    <meta name="author-name-1" content="Karsten Gerloff" />
6
+    <meta name="author-link-1" content="/about/gerloff/gerloff.html" />
7
+    <meta name="author-name-2" content="Carlo Piana" />
8
+    <meta name="author-name-3" content="Sam Tuke" />
9
+    <meta name="author-link-3" content="/about/tuke/tuke.html" />
10
+    <meta name="publication-date" content="2010-10-15" />
11
+    <meta name="pdf-link" content="/projects/os/bsa-eif-letter-fsfe-response.pdf" />
12
+    <title>EIF-BSA-Brief</title>
13
+  </head>
14
+  <body>
15
+    
16
+    <h1>Offene Standards verteidigen: Die FSFE widerlegt die falschen
17
+      Behauptungen der BSA gegenüber der Europäische Kommission</h1>
18
+
19
+    <p id="introduction">Die Business Software Alliance (BSA) übt Druck auf
20
+    die Europäische Kommission aus, um aus der aktuellen Version der
21
+    Interoperabilitätsempfehlungen der EU, dem European Interoperability
22
+    Framework (EIF), auch die letzten Überbleibsel einer Unterstützung für
23
+    Offene Standards zu entfernen.
24
+    <br /><br />
25
+    Die FSFE ist in den Besitz der Kopie
26
+    <a href="/projects/os/bsa-letter-ec.pdf">eines Briefs</a> gekommen, den
27
+    die BSA letzte Woche an die Kommission geschickt hat. Im Folgenden
28
+    analysieren wir die Argumente der BSA und erklären, warum ihre
29
+    Behauptungen falsch sind, und warum Offene Standards ein wesentliches
30
+    Element für Interoperabilität und Wettbewerb im europäischen
31
+    Software-Markt sind. Wir haben die Europäische Kommission über diese
32
+    Analyse <a href="/projects/os/bsa-eif-letter-fsfe-response.pdf">in
33
+    Kenntnis gesetzt</a>.</p>
34
+    
35
+    <ol>
36
+    
37
+      <li><a href="#1">Gebührenfreie Patentlizenzierung eröffnet
38
+      Möglichkeiten zur Marktteilnahme und fördert Innovation</a></li>
39
+      
40
+      <li><a href="#2">Die von der BSA als Beispiele angeführten Standards
41
+      sind im Software-Bereich irrelevant</a></li>
42
+      
43
+      <li><a href="#3">(F)RAND-Lizenzierung in Software-Standards ist
44
+      unfair und diskriminierend</a></li>
45
+      
46
+      <li><a href="#4">Die BSA repräsentiert nicht einmal ihre eigenen
47
+      Mitglieder, geschweige denn die Software-Industrie als Ganzes</a></li>
48
+      
49
+      <li><a href="#5">(F)RAND ist inkompatibel mit den meisten
50
+      Freie-Software-Lizenzen</a></li>
51
+      
52
+      <li><a href="#6">Eine Bevorzugung Offener Standards steht in
53
+      keinerlei Zusammenhang mit der Verhandlungsposition der EU gegenüber
54
+      China</a></li>
55
+      
56
+      <li><a href="#7">Spezifikationen ohne Beschränkungen werden
57
+      Standardisierung, Wettbewerb und Interoperabilität fördern</a></li>
58
+      
59
+      <li><a href="#8">Empfehlungen</a></li>
60
+    
61
+    </ol>
62
+
63
+    <h2 id="1">Gebührenfreie Patentlizenzierung eröffnet Möglichkeiten zur
64
+    Marktteilnahme und fördert Innovation</h2>
65
+
66
+    <p>In ihrem Brief argumentiert die BSA, dass „wenn die EU eine
67
+    Bevorzugung gebühren-/patentfreier Spezifikationen beschließt, die
68
+    Anreize für Firmen untergraben werden, Spitzen-Innovationen in die
69
+    Standardisierung einzubringen, was in weniger innovativen europäischen
70
+    Spezifikationen und weniger wettbewerbsfähigen europäischen Produkten
71
+    resultiert.“</p>
72
+
73
+    <p>In Wirklichkeit stellt dies ein grobes Missverständnis von Standards,
74
+    ihrer Rolle und ihrer Funktionsweise dar.</p>
75
+
76
+    <ol>
77
+
78
+      <li>Gebührenfreie Lizenzbedingungen verhindern nicht, dass patentierte
79
+      Technologien in Standards aufgenommen werden. Der Beitragende ist
80
+      nur angehalten, keine Lizenzgebühren für Implementierungen zu
81
+      erheben.</li>
82
+
83
+      <li>Die auf einzigartige Weise erfolgreichste
84
+      Technologie-Plattform der Welt, das
85
+      Internet, baut auf Standards auf, die vollständig unter gebührenfreien
86
+      Lizenzbedingungen verfügbar gemacht wurden. In der Tat hat das W3C,
87
+      die für Web-Standards zuständige Standardisierungsorganisation (SSO),
88
+      im Konsens eine gebührenfreie „Geistiges-Eigentum-Richtlinie“
89
+      beschlossen, nach der gebührenpflichtige Technologien nur in seltenen
90
+      Ausnahmefällen verwendet werden dürfen. Anstatt Innovationen zu
91
+      behindern, wie von der BSA behauptet, hat dies das Internet zu einer
92
+      Hochburg der Innovation gemacht. Tatsächlich ist es gerade das
93
+      Wesen von Standards, dass sie eine Plattform stabilisieren, auf deren
94
+      Grundlage Marktteilnehmer innovative oder interoperable Lösungen
95
+      entwickeln können<a class="fn" href="#refs">1</a>.</li>
96
+
97
+      <li>Im Widerspruch zur Behauptung der BSA eröffnen gebührenfreie
98
+      Patentlizenzierungsrichtlinien der größtmöglichen Anzahl von
99
+      Marktteilnehmern und Implementierern die Möglichkeit, am
100
+      Standardisierungsprozess für Software teilzunehmen. Im Ergebnis sind
101
+      Software-Standards, die von Standardisierungsorganisationen mit
102
+      gebührenfreien Patentlizenzierungsrichtlinien, wie dem W3C,
103
+      beschlossen werden, weit verbreitet, dabei ist der HTML-Standard nur
104
+      das bekannteste Beispiel.</li>
105
+
106
+    </ol>
107
+
108
+    <p>Aus einer umfassenderen Sicht hinsichtlich Richtlinien ist es auch
109
+    fragwürdig, dass Innovatoren, die bereits einen Anreiz durch ein
110
+    Patent haben, einen weiteren Anreiz bräuchten, indem das Patent in
111
+    einen Standard aufgenommen wird. Ein Patent bedeutet nicht das Recht
112
+    auf eine garantierte Einkommensquelle.</p>
113
+
114
+    <h2 id="2">Die von der BSA als Beispiele angeführten Standards sind im
115
+    Software-Bereich irrelevant</h2>
116
+
117
+    <p>Die BSA argumentiert, dass „viele der heute am weitesten
118
+    verbreiteten offenen Spezifikationen patentierte Innovationen
119
+    beinhalten, die von kommerziellen Firmen entwickelt wurden … darunter
120
+    WiFi, GSM und MPEG.“</p>
121
+
122
+    <p>Damit wird unterstellt, es gebe einen zwingenden Zusammenhang zwischen
123
+    „kommerziell“ und „patentiert“. Kommerzielle Unternehmen würden die von
124
+    ihnen entwickelten Technologien grundsätzlich patentieren, während
125
+    nicht-patentierte Erfindungen nur im nicht-kommerziellen Bereich zu
126
+    finden seien.
127
+    In Wirklichkeit stellt ein Großteil
128
+    der nicht patentierten modernen Technologie, die ihren Ursprung in
129
+    kommerziellen Unternehmen hat, weltweit eingesetzte Standards dar (wie
130
+    z.&#160;B. HTML5), die auch weiterhin ihre Entwickler mit Einkommen
131
+    versorgen. Es gibt keine derartige Trennlinie, weder ökonomisch noch
132
+    ideologisch, zwischen Hardware- und Software-Technologien, die patentiert
133
+    sind, und denen, die es nicht sind. Trotzdem legt die BSA 
134
+    nahe, dass es einen Unterschied zwischen konventionellen
135
+    und akzeptierten Geschäftsmethoden, die sie mit Patenten in Verbindung
136
+    bringen, und nicht-geschäftsmäßigen, nicht-kommerziellen Organisationen,
137
+    die sie mit patentfreier Technologie in Verbindung bringen, gebe. Im
138
+    Hinblick auf die zunehmende Verbreitung von Freier Software im
139
+    europäischen IT-Dienstleistungsmarkt ist solch eine Behauptung schlicht
140
+    und einfach falsch.</p>
141
+
142
+    <p>Die von der BSA als Beispiele aufgeführten Standards beziehen sich (mit
143
+    Ausnahme von MPEG<a class="fn" href="#refs">2</a>) auf hardwarebasierte
144
+    Technologien. Die Ökonomie des Hardware-Markts unterscheidet sich
145
+    wesentlich von der des Software-Markts. Während der Eintritt in den
146
+    Hardware-Markt beträchtliche Investitionen voraussetzt, kann ein
147
+    Software-Unternehmen mit einem sehr kleinen Startkapital gegründet
148
+    werden. Von solch einem Software-Startup-Unternehmen zu verlangen,
149
+    Gebühren für die Implementierung von Software-Standards zu bezahlen,
150
+    würde die Markteintrittsbarriere signifikant erhöhen, Innovationen
151
+    verringern und den Wettbewerb behindern, und daneben auch die Preise für
152
+    Konsumenten (einschließlich Organisationen des öffentlichen Sektors)
153
+    erhöhen.</p>
154
+
155
+    <p>Für Software ist es eindeutig, dass die Akzeptanz der Aufnahme
156
+    von Patenten in Standards unter (F)RAND-Bedingungen die
157
+    Eintrittsbarriere in den europäischen Software-Markt auf unangemessene
158
+    und unnötige Art erhöht, und dadurch die europäische IKT-Wirtschaft
159
+    weniger wettbewerbsfähig macht.</p>
160
+
161
+    <h2 id="3">(F)RAND-Lizenzierung in Software-Standards ist unfair und
162
+    diskriminierend</h2>
163
+
164
+    <p>Die BSA argumentiert, dass „die Bedingungen, dass eine offene
165
+    Spezifikation ‚frei implementierbar‘ sein muss, sowie frei
166
+    verbreitet und wiederverwenden werden kann, mehrdeutig sind,
167
+    und darauf hindeuten, dass der Standard frei von geistigen
168
+    Eigentumsrechten sein muss.“</p>
169
+
170
+    <p>Weiter argumentiert die BSA, dass FRAND sicherstellt, dass diese
171
+    Innovationen unter fairen Bedingungen benutzt werden können, um den
172
+    Standard zu implementieren.
173
+    Dadurch wird es Erfindern erlaubt, eine
174
+    angemessene Gebühr zu erheben, wenn ihre Technologien in Spezifikationen
175
+    verwendet werden.“ In Software-Standards sind (F)RAND-Bedingungen aber
176
+    diskriminierend gegenüber Freier Software und allen darauf basierenden
177
+    Geschäftsmodellen. Die am häufigsten verwendeten Freie-Software-Lizenzen
178
+    erlauben nicht, dass den Benutzern der Software zusätzliche Bedingungen
179
+    auferlegt werden. Doch (F)RAND würde verlangen, dass solche Bedingungen
180
+    gestellt würden, normalerweise in Form von Lizenzgebühren, die von der
181
+    Zahl der Benutzer abhängen, was (F)RAND-Lizenzierungsrichtlinien
182
+    inkompatibel mit Freier Software macht. Was Software-Standards betrifft,
183
+    ist die (F)RAND-Herangehensweise weder vernünftig, noch
184
+    nicht-diskriminierend.</p>
185
+
186
+    <p>Im umgekehrten Fall schließt eine Gebührenfreiheit proprietäre
187
+    Implementierungen nicht aus (nicht einmal solche, die in hohem Ausmaß
188
+    patentiert sind). Tatsächlich bedeutet Gebührenfreiheit, dass, insofern
189
+    bestimmte Technologien in einem Standard vorgeschrieben sind, diese jedem
190
+    ohne die Zahlung einer Lizenzgebühr zur Verfügung stehen müssen. Indessen
191
+    können die Implementierungen unter beliebigen Lizenzen vertrieben werden
192
+    und beliebige Technologien beinhalten, solange sie sich an den Standard
193
+    halten.</p>
194
+
195
+    <p>Der gebührenfreie HTML-Standard ist beispielsweise in einer Vielzahl
196
+    von Browsern implementiert, sowohl solchen, die auf Freier Software
197
+    beruhen, als auch proprietären. Dies zeigt deutlich, dass ein
198
+    gebührenfreier Software-Standard eine weite Verbreitung haben
199
+    und Innovation durch Wettbewerb fördern kann.</p>
200
+
201
+    <h2 id="4">Die BSA repräsentiert nicht einmal ihre eigenen Mitglieder,
202
+    geschweige denn die Software-Industrie als Ganzes</h2>
203
+
204
+    <p>Die BSA argumentiert, „der EIF könnte dahingehend interpretiert
205
+    werden, dass die Teilnahme der innovativsten europäischen und
206
+    nicht-europäischen Unternehmen am Standardisierungsprozess
207
+    nicht erwünscht ist, falls sie Patente in den relevanten
208
+    Technologien besitzen und sie im Fall, dass diese
209
+    Patente Teil eines Standards werden, eine Vergütung für ihre Erfindungen
210
+    verlangen.“</p>
211
+
212
+    <p>Weiter behauptet die BSA: „Die Beteiligten verstehen die wichtige
213
+    Verbindung zwischen geistigem Eigentum und Standardisierung – und
214
+    verstehen auch, dass FRAND-basierte Standards äußerst flexibel sind
215
+    und in einem großen Bereich von Lösungen implementiert werden können,
216
+    sowohl in Open-Source, als auch in proprietären.“</p>
217
+
218
+    <p>Im Widerspruch zur Behauptung der BSA, eine einheitliche Position
219
+    der Software-Industrie zu vertreten, möchten wir bemerken, dass die
220
+    ECIS, die von wichtigen Beteiligten der Industrie gebildet wurde (von
221
+    denen manche  auch Mitglied der BSA sind), das Gegenteil
222
+    behauptet<a class="fn" href="#refs">3</a>. Obwohl die Mitglieder der ECIS
223
+    über große Patentportfolios verfügen, wollen sie, dass Standards zur
224
+    Software-Interoperabilität frei von Lizenzgebühren sind. Um nur ein
225
+    Beispiel zu nennen: Google hat in großem Maße zu gebührenfreien
226
+    Standards beigetragen, indem es eine durch die Industrie unterstützte
227
+    Alternative zu MPEG anbietet.</p>
228
+
229
+    <h2 id="5">(F)RAND ist inkompatibel mit den meisten
230
+    Freie-Software-Lizenzen</h2>
231
+
232
+    <p>Die BSA behauptet, dass „die meisten Open-Source-Lizenzen vollständig
233
+    kompatibel mit FRAND-basierter Lizenzierung sind.“</p>
234
+
235
+    <p>Nach jeder vernünftigen Zählung (ob nach Menge des verfügbaren
236
+    Source-Codes, dessen Wichtigkeit oder beidem) sind die relevantesten
237
+    Freien (Open-Source) Software-Lizenzen:</p>
238
+
239
+    <ol>
240
+
241
+      <li>GNU GPL und LGPL</li>
242
+      <li>Mozilla Public License</li>
243
+      <li>Apache Public License</li>
244
+      <li>BSD/MIT und andere ultra-freizügige Lizenzen</li>
245
+      <li>EUPL</li>
246
+
247
+    </ol>
248
+
249
+    <p>Alle diese, eventuell mit Ausnahme der ultra-freizügigen Lizenzen,
250
+    was aber nicht sicher ist, sind eindeutig inkompatibel mit
251
+    gebührenpflichtigen Patentlizenzen. Gemäß Statistiken, die von
252
+    <a href="http://www.blackducksoftware.com/oss/licenses#top20">Black Duck
253
+    Software</a> veröffentlicht wurden, werden mehr als 85% der
254
+    Freie-Software-Projekte unter Lizenzen vertrieben, die mit
255
+    gebührenpflichtigen Patentlizenzen inkompatibel sind. Die GNU General
256
+    Public License (GPL) ist als die weitaus am Häufigsten verwendete
257
+    Freie-Software-Lizenz aufgelistet, sie wird von nahezu der Hälfte aller
258
+    Projekte verwendet. Die Aufnahme von patentierten Technologien in
259
+    auf Freier Software basierende Produkte verlangt von den
260
+    Implementierern, falls überhaupt möglich, eine schwierige Vermischung
261
+    von proprietären Teilen mit Freier Software. In solchen Fällen ist
262
+    der resultierende Code zwangsläufig proprietäre
263
+    Software<a class="fn" href="#refs">5</a>.</p>
264
+
265
+    <h2 id="6">Eine Bevorzugung Offener Standards steht in keinerlei
266
+    Zusammenhang mit der Verhandlungsposition der EU gegenüber China</h2>
267
+
268
+    <p>Die BSA behauptet: „Die Mehrdeutigkeit der vorgeschlagenen
269
+    Bevorzugung im EIF wird zweifelsohne
270
+    die Fähigkeit der Kommission schwächen, die geistigen Eigentumsrechte
271
+    der Europäer gegen eine Bedrohung aus China zu verteidigen.“</p>
272
+
273
+    <p>Die Behauptung, dass die Empfehlung, offene
274
+    Spezifikationen zu bevorzugen, die Verhandlungsposition der EU gegenüber China schwächen
275
+    wird, ist schlicht und einfach falsch. Empfehlungen bezüglich der
276
+    Nutzung offener Software-Spezifikationen im öffentlichen Sektor haben
277
+    keinerlei Auswirkungen auf die Position der Kommission. Außerdem sollte
278
+    noch einmal gesagt werden, dass gebührenfreie Standards nicht im
279
+    Widerspruch zu einer „soliden Verteidigung“ von Patenten, Urheberrechten
280
+    und Markenzeichen stehen.</p>
281
+
282
+    <p>Wir möchten bemerken, dass in den Vereinigten Staaten im Zuge der
283
+    Erstellung des „Special 301“ Berichts zu Handelshemmnissen von 2010
284
+    dem US-Handelsbeauftragten ähnliche Bedenken übermittelt wurden. Der
285
+    Handelsbeauftragte beschloss, diese Bedenken nicht mit in den Bericht
286
+    aufzunehmen, was deutlich zeigt, dass dies für die Regierung der
287
+    Vereinigten Staaten kein Thema ist. Während solche Bedenken oft
288
+    bei Beeinflussungsversuchen öffentlicher Politik geäußert werden, gibt
289
+    es eine augenfällige Abwesenheit von Versuchen, solche Bevorzugungen
290
+    auf rechtlichem Weg zu entfernen – vermutlich weil die, die die
291
+    Behauptungen aufstellen, sehr gut wissen, dass die Behauptungen nicht
292
+    auf Fakten beruhen.</p>
293
+
294
+    <h2 id="7">Spezifikationen ohne Beschränkungen werden Standardisierung,
295
+    Wettbewerb und Interoperabilität fördern</h2>
296
+
297
+    <p>Die BSA behauptet, dass „die vorgeschlagene Bevorzugung des EIF für
298
+    Spezifikationen, die frei von geistigem Eigentum sind, langfristig
299
+    Standardisierung, Wettbewerbsfähigkeit und Interoperabilität untergraben
300
+    wird.“</p>
301
+
302
+    <p>Wir sind nicht in der Lage, zu deuten, was die BSA mit
303
+    „von geistigem Eigentum freien Spezifikationen“ meint, aber wir glauben,
304
+    dass eine solche Wortwahl von einem ungenügenden Verständnis des
305
+    Standardisierungsprozesses von Seiten der BSA zeugt.</p>
306
+
307
+    <p>Die Behauptung, dass die aktuelle Version des EIF Interoperabilität
308
+    untergraben könnte, ist einfach untragbar. Sie folgt aus unbewiesenen
309
+    Annahmen, von denen wir in der obigen Diskussion gezeigt haben, dass
310
+    sie falsch sind. Zum gegenwärtigen Zeitpunkt halten Lock-in-Effekte, die
311
+    aus der Benutzung proprietärer Software und Dateiformate entstehen,
312
+    die öffentliche Verwaltung häufig von einer freien Wahl ihrer
313
+    IT-Lösungen ab. Stattdessen bleiben sie an einen bestimmten Anbieter
314
+    gebunden.
315
+    Der Stadtrat von Brighton und der Schweizer Kanton Solothurn sind zwei
316
+    Beispiele der letzten Monate für die zahlreichen öffentlichen
317
+    Einrichtungen, die von einer IT-Lösung zu einer anderen migrieren
318
+    wollen und dabei durch patentgeschützte Software-Standards in einer
319
+    suboptimalen Lösung festgehalten werden. Dieser Lock-in-Effekt führt zu
320
+    Schwierigkeiten bei der Migration und zu hohen Kosten für die
321
+    Steuerzahler.</p>
322
+
323
+    <p>Im umgekehrten Fall erlauben Software-Standards, die ohne
324
+    Beschränkungen implementiert werden könne, vielen konkurrierenden
325
+    Implementierungen, miteinander zusammenzuarbeiten. In so einem Umfeld
326
+    werden die Monopoleinnahmen einer kleinen Zahl von Großunternehmen
327
+    durch einen lebhaften, innovativen Markt abgelöst, der sich durch
328
+    einen harten Wettbewerb auszeichnet. Das Ergebnis sind bessere Lösungen
329
+    und Dienstleistungen zu niedrigeren Preisen.</p>
330
+
331
+    <h2 id="8">Empfehlungen</h2>
332
+
333
+    <p>Im Licht der obigen Überlegungen fordern wir die Kommission
334
+    eindringlich auf, Interoperabilität und Wettbewerb auf dem europäischen
335
+    Software-Markt zu fördern, und nicht den etablierten, dominanten
336
+    Unternehmen einen weiteren Hebel an die Hand zu geben, um ihre
337
+    Kontrolle des Markts aufrechtzuerhalten. Daher fordern wir die
338
+    Kommission auf, keine Billigung von (F)RAND-Lizenzierungen für
339
+    Software-Standards in den EIF aufzunehmen. Stattdessen fordern wir
340
+    die Kommission eindringlich auf, die Empfehlung beizubehalten, dass
341
+    Spezifikationen nur als offen angesehen werden können, wenn sie unter
342
+    unterschiedlichen Software-Linzenzierungsmodellen implementiert und
343
+    verbreitet werden können, inklusive Freier
344
+    Software<a class="fn" href="#refs">6</a> , die unter der GNU GPL
345
+    lizenziert wird.</p>
346
+
347
+    <p>Wir fordern die Kommission auch eindringlich auf, in die
348
+    Revision des European Interoperability Framework eine starke
349
+    Empfehlung an öffentliche Einrichtungen aufzunehmen, die Vorteile
350
+    von Software, die auf Offenen Standards<a class="fn" href="#refs">7</a>
351
+    basiert, im Hinblick auf freie Wahl, Wettbewerb, Vermeidung von
352
+    Lock-in-Effekten und langfristiger Lesbarkeit von Daten zu nutzen.</p>
353
+
354
+    <h2 id="fn">Fußnoten</h2> 
355
+
356
+    <ol id="refs"> 
357
+
358
+      <li>Siehe z.B. Rishab Aiyer Ghosh, Philipp Schmidt (2006): United
359
+      Nations University Policy Brief, Nr. 1, 2006: „Wohldefinierte
360
+      Offene Standards können den einzigartigen ökonomischen Effekt haben,
361
+      dass ‚natürliche‘ Monopole für eine bestimmte Technologie gebildet
362
+      werden können, während sie einen vollen Wettbewerb zwischen
363
+      Anbietern dieser Technologie gewährleisten.“ [Hervorhebung
364
+      hinzugefügt]</li>
365
+      
366
+      <li>MPEG ist eigens dahingehend entwickelt, dass ausdrücklich der
367
+      Einsatz patentierter Technologien vorgeschrieben wird, sogar wo diese
368
+      größtenteils durch (nach Meinung von Experten) nicht patentgeschützte
369
+      Alternativen ersetzt werden können. Es ist vorstellbar, dass der
370
+      Grund dafür ist, dass so viel Profit wie möglich aus der Verwendung
371
+      einer bestimmten Implementierung gewisser mathematischer Prinzipien
372
+      erzielt werden soll, anstatt eine gemeinsame und standardisierte
373
+      Plattform zum Zweck der Interoperabilität zu schaffen.
374
+      <br />
375
+      Darüber hinaus wurden die meisten MPEG-Standards zu einer Zeit
376
+      etabliert, als Codecs noch in Hardware implementiert wurden, weil
377
+      die verfügbare Bandbreite begrenzt und generische Hardware nicht
378
+      ausreichend leistungsfähig war.</li>
379
+      
380
+      <li>Siehe
381
+      <a href="http://www.ecis.eu/documents/ECISStatementreEIF13.10.10.pdf">die
382
+      Reaktion der ECIS</a> vom 13. Oktober 2010 auf den Brief der BSA</li>
383
+	  
384
+      <li>Für eine Diskussion hybrider Lösungen und Netzwerkprotokollen
385
+      siehe die <a href="/projects/ms-vs-eu/fsfe_art18_reply_published_sourcecode.pdf">Antwort
386
+      der FSFE und des Samba-Teams auf den Artikel 18</a>.</li>
387
+      
388
+      <li>Siehe die <a href="http://fsfe.org/about/basics/freesoftware.en.html">Definition Freier Software der FSFE</a></li>
389
+      
390
+      <li>Wie definiert in der <a href="/projects/os/def.html">Definition
391
+      eines Offenen Standards der FSFE</a></li>
392
+    
393
+    </ol>
394
+	
395
+  </body>
396
+
397
+  <timestamp>$Date: 2010-10-21 16:02:28 +0200 (Thu, 21 Oct 2010) $ $Author: guest-enz $</timestamp>
398
+
399
+<translator>Markus Enzenberger</translator>
400
+</html>

+ 394
- 0
projects/os/bsa-letter-analysis.el.xhtml View File

@@ -0,0 +1,394 @@
1
+<?xml version="1.0" encoding="UTF-8" ?>
2
+
3
+<html>
4
+  <head>
5
+    <meta name="keywords" content="eif,ευρωπαϊκό πλαίσιο διαλειτουργικότητας,ανοιχτά πρότυπα,fsfe,ανοιχτός κώδικας,επιτροπή,ευρώπη,πρότυπα" />
6
+    <meta name="description" content="Η Business Software Alliance (BSA) ασκεί πιέσεις προς την Ευρωπαϊκή Επιτροπή να αφαιρέσει τα τελευταία ίχνη υποστήριξης για τα Ανοιχτά Πρότυπα από την τελευταία έκδοση των συστάσεων διαλειτουργικότητας της ΕΕ, του Ευρωπαϊκού Πλαισίου Διαλειτουργικότητας (EIF)" />
7
+    <title>EIF BSA Επιστολή</title>
8
+  </head>
9
+
10
+  <body>
11
+    <p id="category"><a href="/projects/os/os.html">Ανοιχτά Πρότυπα</a></p>
12
+    <h1>Υπερασπίζοντας τα Ανοιχτά Πρότυπα: το FSFE ανασκευάζει τους 
13
+    λαθεμένους ισχυρισμούς της BSA προς την Ευρωπαϊκή Επιτροπή</h1>
14
+
15
+    <p id="introduction">Η Business Software Alliance (BSA) ασκεί πιέσεις προς 
16
+    την Ευρωπαϊκή Επιτροπή να αφαιρέσει τα τελευταία ίχνη υποστήριξης για τα
17
+    Ανοιχτά Πρότυπα από την τελευταία έκδοση των συστάσεων διαλειτουργικότητας
18
+    της ΕΕ, του Ευρωπαϊκού Πλαισίου Διαλειτουργικότητας.
19
+    <br /><br />
20
+    Το FSFE έχει εξασφαλίσει ένα αντίγραφο της 
21
+    <a href="/projects/os/bsa-letter-ec.pdf">επιστολής που εστάλη στην Επιτροπή</a>
22
+    από την BSA  την περασμένη εβδομάδα. Στις επόμενες παραγράφους αναλύουμε 
23
+    τα επιχειρήματα της BSA και εξηγούμε γιατί οι ισχυρισμοί τους είναι λαθεμένοι 
24
+    και γιατί τα Ανοιχτά Πρότυπα είναι κλειδί για τη διαλειτουργικότητα και τον 
25
+    ανταγωνισμό στην Ευρωπαϊκή αγορά λογισμικού. Έχουμε 
26
+    <a href="/projects/os/bsa-eif-letter-fsfe-response.pdf">μοιραστεί αυτήν την ανάλυση</a> 
27
+    με την Ευρωπαϊκή Επιτροπή.</p>
28
+    
29
+    <ol>
30
+    
31
+      <li><a href="#1">Η ελεύθερη δικαιωμάτων από πατέντες αδειοδότηση
32
+      ανοίγει τη συμμετοχή και προωθεί την καινοτομία</a></li>
33
+      
34
+      <li><a href="#2">Τα παραδείγματα προτύπων της BSA είναι άσχετα 
35
+      με το πεδίο του λογισμικού</a></li>
36
+      
37
+      <li><a href="#3">Η (F)RAND αδειοδότηση στα πρότυπα λογισμικού 
38
+      είναι άδικη και μεροληπτική</a></li>
39
+      
40
+      <li><a href="#4">Η BSA δεν αντιπροσωπεύει ούτε τα ίδια τα μέλη της, 
41
+      πολύ λιγότερο το σύνολο της βιομηχανίας λογισμικού</a></li>
42
+      
43
+      <li><a href="#5">Η (F)RAND είναι ασύμβατη με τις περισσότερες 
44
+      από τις άδειες χρήσης Ελεύθερου Λογισμικού</a></li>
45
+      
46
+      <li><a href="#6">Η σύσταση προτίμησης για Ανοιχτά Πρότυπα είναι εντελώς 
47
+      άσχετη με τη διαπραγματευτική θέση της ΕΕ απέναντι στην Κίνα</a></li>
48
+      
49
+      <li><a href="#7">Οι ελεύθερες περιορισμών προδιαγραφές θα προωθήσουν 
50
+      την προτυποποίηση, τον ανταγωνισμό και τη διαλειτουργικότητα</a></li>
51
+      
52
+      <li><a href="#8">Συστάσεις</a></li>
53
+    
54
+    </ol>
55
+
56
+    <h2 id="1">Η ελεύθερη δικαιωμάτων από πατέντες αδειοδότηση
57
+      ανοίγει τη συμμετοχή και προωθεί την καινοτομία</h2>
58
+
59
+    <p>Στην επιστολή της, η BSA υποστηρίζει ότι «[Α]ν η ΕΕ υιοθετήσει μια 
60
+    προτίμηση για ελεύθερες χρεώσεων/πατεντών προδιαγραφές, θα υπονομεύσει 
61
+    τα κίνητρα που έχουν οι εταιρείες για να συνεισφέρουν καινοτομίες αιχμής 
62
+    στην προτυποποίηση - το οποίο θα έχει ως αποτέλεσμα λιγότερο καινοτόμες 
63
+    Ευρωπαϊκές προδιαγραφές και λιγότερο ανταγωνιστικά Ευρωπαϊκά προϊόντα».</p>
64
+
65
+    <p>Στην πραγματικότητα αυτό αντανακλά μια τεράστια παρανόηση για
66
+     τα πρότυπα, τον ρόλο και τη λειτουργία τους.</p>
67
+
68
+    <ol>
69
+
70
+      <li>Μηδενικής εκμετάλλευσης συνθήκες αδειοδότησης δεν παρεμποδίζουν 
71
+      πατενταρισμένες τεχνολογίες να περιλαμβάνονται στα πρότυπα. 
72
+      Μάλλον απαιτείται από τον συμβαλλόμενο να αποφύγει να επιβάλλει
73
+      δικαιώματα εκμετάλλευσης σε υλοποιήσεις.</li>
74
+
75
+      <li>Η μοναδική και πιο επιτυχημένη πλατφόρμα τεχνολογίας στη Γη,
76
+      το Διαδίκτυο, έχει δομηθεί σε πρότυπα τα οποία είναι πλήρως διαθέσιμα
77
+      με συνθήκες μηδενικής εκμετάλλευσης δικαιωμάτων αδειοδότησης. 
78
+      Πράγματι ο W3C, ο οργανισμός θέσπισης προτύπων (standard setting 
79
+      organization, SSO) που διαχειρίζεται τα πρότυπα του ιστού έχει μέσα
80
+      από συναίνεση υιοθετήσει μια μηδενικής εκμετάλλευσης δικαιωμάτων
81
+      πολιτική ("IPR policy"), όπου σε τεχνολογίες επιφορτισμένες με δικαιώματα
82
+      επιτρέπεται να συνεισφέρουν μόνο σε μια αυστηρή κατ' εξαίρεση βάση.
83
+      Αντί να καταπνίγεται η εφευρετική δραστηριότητα, όπως ισχυρίζεται
84
+      η BSA, αυτή η πολιτική έχει μετατρέψει το Διαδίκτυο σε ένα θερμοκήπιο
85
+      καινοτομίας. Πράγματι, πρόκειται για την ίδια τη φύση των προτύπων
86
+      που σταθεροποιούν μια πλατφόρμα πάνω στην οποία ανταγωνιστές
87
+      μπορούν να δημιουργούν καινοτόμες και διαλειτουργικές 
88
+      λύσεις<a class="fn" href="#refs">1</a>.</li>
89
+
90
+      <li>Σε αντίθεση με τον ισχυρισμό της BSA, οι πολιτικές μηδενικής 
91
+      εκμετάλλευσης δικαιωμάτων αδειοδότησης πατεντών ανοίγουν τη
92
+      συμμετοχή στη θέσπιση προτύπων λογισμικού στην ευρύτερη δυνατή
93
+      ομάδα επιχειρηματιών και τεχνικών της αγοράς. Ως αποτέλεσμα,
94
+      πρότυπα λογισμικού που προέρχονται από οργανισμούς θέσπισης
95
+      προτύπων με πολιτικές μηδενικής εκμετάλλευσης δικαιωμάτων 
96
+      αδειοδότησης πατεντών, όπως ο W3C έχουν υιοθετηθεί σε ευρεία
97
+      βάση, με το πρότυπο HTML να είναι μόνο το πλέον ορατό παράδειγμα.</li>
98
+
99
+    </ol>
100
+
101
+    <p>Από έναν ευρύτερο πολιτικό ορίζοντα, είναι επίσης αμφισβητήσιμο 
102
+    ότι οι εφευρέτες, οι οποίοι ήδη λαμβάνουν κίνητρο από μια πατέντα,
103
+    θα χρειαστεί να προβούν σε επέκταση του κινήτρου συμπεριλαμβάνοντας
104
+    την πατέντα στο πρότυπο. Ένα δίπλωμα ευρεσιτεχνίας δεν ισοδυναμεί 
105
+    με δικαίωμα σε εγγυημένη ροή εσόδων.</p>
106
+
107
+    <h2 id="2">Τα παραδείγματα προτύπων της BSA είναι άσχετα με το πεδίο του λογισμικού</h2>
108
+
109
+    <p>Η BSA υποστηρίζει ότι «[π]ολλές από τις σημερινές ευρέως 
110
+    διαδεδομένες προδιαγραφές εμπεριέχουν πατενταρισμένες καινοτομίες
111
+    οι οποίες εφευρέθηκαν από εμπορικές εταιρίες...
112
+    όπως οι WiFi, GSM και MPEG». </p>
113
+
114
+    <p>Πρόκειται για μιαν απόπειρα εσφαλμένης διχοτόμησης ανάμεσα 
115
+    σε «εμπορικές» εταιρείες που εφευρίσκουν πατενταρισμένη τεχνολογία,
116
+    και σε «μη-εμπορικές» εφευρέσεις οι οποίες δεν έιναι πατενταρισμένες.
117
+    Στην πραγματικότητα ένας μεγάλος πλούτος απατεντάριστης σύγχρονης
118
+    τεχνολογίας προέρχεται από εμπορικές εταιρίες που συμβάλλουν σε
119
+    διεθνείς υλοποιήσεις προτύπων (όπως το HTML5), ενώ συνεχίζουν
120
+    να παρέχουν εισόδημα στους δημιουργούς τους.
121
+    Δεν υπάρχει τέτοια διαίρεση, οικονομική ή ιδεολογική, ανάμεσα στις
122
+    τεχνολογίες υλικού και λογισμικού που είναι πατενταρισμένες και σε εκείνες
123
+    που δεν είναι. Αλλά η BSA διχαστικά υπονοεί ότι υπάρχει διαφορά
124
+    ανάμεσα σε συμβατικές και αποδεκτές επιχειρηματικές μεθόδους, τις
125
+    οποίες συναρτούν με διπλώματα ευρεσιτεχνίας και σε ξένους προς την
126
+    επιχειρηματικότητα μη-εμπορικούς οργανισμούς, τους οποίους συνδέουν
127
+    με ελεύθερη πατεντών τεχνολογία. Με δεδομένη την αυξανόμενη 
128
+    επικράτηση του Ελεύθερου Λογισμικού στην αγορά υπηρεσιών 
129
+    Πληροφορικής στην Ευρώπη, ένας τέτοιος ισχυρισμός είναι 
130
+    απλώς λαθεμένος.</p>
131
+
132
+    <p>Τα πρότυπα τα οποία η BSA αναφέρει ως παραδείγματα 
133
+    (με την εξαίρεση του MPEG<a class="fn" href="#refs">2</a>) 
134
+    σχετίζονται με τεχνολογίες με βάση το υλικό (hardware). 
135
+    Τα οικονομικά της αγοράς υλικού είναι πολύ διαφορετικά από
136
+    εκείνα της αγοράς λογισμικού. Ενώ η είσοδος στην αγορά υλικού
137
+    απαιτεί πολύ ουσιαστικές επενδύσεις, οι εταιρίες λογισμικού
138
+    μπορούν να ξεκινήσουν με πολύ μικρά ποσά κεφαλαίων. 
139
+    Η απαίτηση από μια νέα μικρή εταιρία λογισμικού να πληρώσει
140
+    δικαιώματα για να υλοποιήσει πρότυπα λογισμικού, θα ανύψωνε
141
+    σημαντικά τον πήχυ για είσοδο στην αγορά, θα μείωνε την καινοτομία
142
+    και θα εμπόδιζε τον ανταγωνισμό, και επίσης θα αύξανε τις τιμές
143
+    για τον καταναλωτή (και για τους οργανισμούς του δημόσιου τομέα).</p>
144
+
145
+    <p>Για το λογισμικό, ωστόσο, είναι ξεκάθαρο ότι επιτρέποντας σε
146
+    πατέντες να περιλαμβάνονται σε πρότυπα λογισμικού με όρους (F)RAND 
147
+    θα αύξανε υπερβολικά και χωρίς να είναι απαραίτητο τα εμπόδια εισόδου
148
+    στην Ευρωπαϊκή αγορά λογισμικού, κάνοντας την οικονομία των τεχνολογιών
149
+    πληροφορικής και επικοινωνιών της Ευρώπης λιγότερο ανταγωνιστική.</p>
150
+
151
+    <h2 id="3">Η (F)RAND αδειοδότηση στα πρότυπα λογισμικού 
152
+    είναι άδικη και μεροληπτική</h2>
153
+
154
+    <p>Η BSA υποστηρίζει ότι «[Οι] απαιτήσεις για τις ανοικτές προδιαγραφές 
155
+    να είναι «ελεύθερα υλοποιή[σιμες]» και με δυνατότητα διαμοιρασμού
156
+    και επαναχρησιμοποίησης είναι ασαφείς και υποδηλώνουν ότι τα πρότυπα
157
+    πρέπει να είναι ελεύθερα δικαιωμάτων πνευματικής ιδιοκτησίας 
158
+    (intellectual property rights, IPR)».</p>
159
+
160
+    <p>Η BSA στη συνέχεια υποστηρίζει ότι «[οι όροι FRAND διασφαλίζουν ότι] 
161
+    οι τεχνικοί υλοποίησης ενός προτύπου μπορούν να κάνουν χρήση αυτών των
162
+    καινοτομιών με δίκαιους όρους. Επιτρέπουν σε εφευρέτες να χρεώνουν ένα
163
+    εύλογο αντίτιμο όταν οι τεχνολογίες τους ενσωματώνονται σε προδιαγραφές[.]»
164
+    Στα πρότυπα λογισμικού, οι όροι (F)RAND στην πράξη μεροληπτούν εναντίον
165
+    του Ελεύθερου Λογισμικού και κάθε επιχειρηματικού μοντέλου που βασίζεται
166
+    σε αυτό. Οι πιο διαδεδομένες άδειες χρήσης Ελεύθερου Λογισμικού δεν
167
+    επιτρέπουν την επιβολή πρόσθετων όρων στους παραλήπτες του λογισμικού. 
168
+    Και όμως οι (F)RAND απαιτούν την επιβολή τέτοιων συνθηκών, συνήθως
169
+    με τη μορφή της χρέωσης δικαιωμάτων, καθιστώντας τις (F)RAND πολιτικές
170
+    αδειοδότησης ασύμβατες με το Ελεύθερο Λογισμικό. Όπου αφορά τα
171
+    πρότυπα λογισμικού, αυτή η πρακτική δεν καθιστά την (F)RAND προσέγγιση
172
+    ούτε εύλογη ουτε αμερόληπτη.</p>
173
+
174
+    <p>Αντίστροφα, η «μηδενική χρέωση δικαιωμάτων» δεν αποκλείει
175
+    τις ιδιοκτησιακές (και τις επαχθώς πατενταρισμένες) υλοποιήσεις. 
176
+    Πράγματι «μηδενική χρέωση δικαιωμάτων» σημαίνει ότι αν ορισμένες
177
+    τεχνολογίες εξουσιοδοτούνται από ένα πρότυπο, αυτές πρέπει να είναι
178
+    διαθέσιμες σε όλους χωρίς να απαιτούν δικαιώματα. Στο μεταξύ οι
179
+    υλοποιήσεις θα μπορούν να διανέμονται με οποιαδήποτε άδεια χρήσης
180
+    και θα περιλαμβάνουν οποιαδήποτε τεχνολογία, με δεδομένο ότι το
181
+    πρότυπο γίνεται σεβαστό.</p>
182
+
183
+    <p>Το ελεύθερο δικαιωμάτων πρότυπο HTML για παράδειγμα,
184
+    έχει εφαρμοστεί σε ένα πλήθος περιηγητών ιστού και ελεύθερου και 
185
+    ιδοκτησιακού λογισμικού. Αυτό δείχνει με σαφήνεια ότι ένα ελεύθερο 
186
+    δικαιωμάτων πρότυπο λογισμικού επιτρέπει την ευρεία υιοθέτηση και 
187
+    οδηγεί την καινοτομία μέσα από τον ανταγωνισμό.</p>
188
+
189
+    <h2 id="4">Η BSA δεν αντιπροσωπεύει ούτε τα ίδια τα μέλη της, 
190
+     πολύ λιγότερο το σύνολο της βιομηχανίας λογισμικού</h2>
191
+
192
+    <p>Η BSA υποστηρίζει ότι «[το EIF] μπορεί να αναγνωστεί ώστε 
193
+    να σημαίνει ότι οι πιο καινοτόμες Ευρωπαϊκές και ξένες εταιρείες
194
+    δεν είναι ευπρόσδεκτες να συμμετάσχουν στις διαδικασίες
195
+    προτυποποίησης αν κατέχουν διπλώματα ευρεσιτεχνίας σε σχετικές
196
+    τεχνολογίες και επιδιώκουν αποζημίωση για τις εφευρέσεις τους
197
+    αν αυτά τα διπλώματα ευρεσιτεχνίας γίνουν τμήμα του προτύπου.»</p>
198
+
199
+    <p>Η BSA στη συνέχεια υποστηρίζει ότι «[Τα] ενδιαφερόμενα μέρη 
200
+    [αναγνωρίζουν] τον σημαντικό σύνδεσμο ανάμεσα στα IPR και την
201
+    προτυποποίηση - και επίσης [αναγνωρίζουν] ότι τα βασισμένα σε όρους
202
+    FRAND πρότυπα είναι πολύ ευέλικτα και μπορούν να υλοποιηθούν σε
203
+    μια ευρεία γκάμα λύσεων ανοικτού κώδικα και ιδιοκτησιακών».</p>
204
+
205
+    <p>Σε αντίθεση με τον ισχυρισμό της BSA ότι εκπροσωπεί την ενιαία
206
+    θέση της βιομηχανίας λογισμικού, σημειώνουμε ότι η ECIS, η οποία
207
+    έχει σχηματιστεί από σημαντικούς εκπροσώπους της βιομηχανίας
208
+    (ορισμένοι από τους οποίους είναι και μέλη της BSA) λέει 
209
+    τα αντίθετα<a class="fn" href="#refs">3</a>. Παρά το ότι διαθέτουν
210
+    ένα μεγάλο χαρτοφυλάκιο πατεντών, τα μέλη της ECIS επιθυμούν
211
+    τα πρότυπα για τη διαλειτουργικότητα στο λογισμικό να παραμείνουν
212
+    χωρίς επιβαρύνσεις από απαιτήσεις δικαιωμάτων για πατέντες []. 
213
+    Για να ανφέρουμε μόνο ένα παράδειγμα, η Google έχει ισχυρή
214
+    συμβολή στα πρότυπα μηδενικής χρέωσης δικαιωμάτων με την
215
+    προσφορά μιας υποστηριζόμενης από τη βιομηχανία εναλλακτικής
216
+    λύσης στο MPEG.</p>
217
+
218
+    <h2 id="5">Η (F)RAND είναι ασύμβατη με τις περισσότερες 
219
+    από τις άδειες χρήσης Ελεύθερου Λογισμικού</h2>
220
+
221
+    <p>Η BSA ισχυρίζεται ότι «οι περισσότερες άδειες χρήσης 
222
+    λογισμικού ανοιχτού κώδικα είναι πλήρως συμβατές με την 
223
+    αδειοδότηση με όρους FRAND.»</p>
224
+
225
+    <p>Με οποιοδήποτε εύλογο μέτρο (ανεξάρτητα αν βασίζεται στην 
226
+    ποσότητα του διαθέσιμου κώδικα ή στη σημαντικότητά του ή και στα δύο) 
227
+    οι πιο σχετικές άδειες χρήσης Ελεύθερου Λογισμικού (ανοιχτού κώδικα) είναι:</p>
228
+
229
+    <ol>
230
+
231
+      <li>GNU GPL και LGPL</li>
232
+      <li>Mozilla Public License</li>
233
+      <li>Apache Public License</li>
234
+      <li>BSD/MIT και άλλες υπέρ-το-δέον ανεκτικές άδειες χρήσης</li>
235
+      <li>EUPL</li>
236
+
237
+    </ol>
238
+
239
+    <p>Όλες αυτές, με την μόνη βάσιμη αλλά αβέβαιη εξαίρεση της
240
+    υπερ-το-δέον ανεκτικής κατηγορίας, είναι ξεκάθαρα ασύμβατες
241
+    με το καθεστώς των δικαιωμάτων σε διπλώματα ευρεσιτεχνίας.
242
+    Σύμφωνα με τις στατιστικές που ανακοίνωσε η 
243
+    <a href="http://www.blackducksoftware.com/oss/licenses#top20">Black 
244
+    Duck Software</a>, περισσότερα από 85% των έργων Ελεύθερου Λογισμικού
245
+    διανέμονται με άδειες χρήσης οι οποίες είναι ασύμβατες με καθεστώτα
246
+    δικαιωμάτων σε διπλώματα ευρεσιτεχνίας. Η GNU Γενική Άδεια 
247
+    Δημόσιας Χρήσης (GNU General Public License, GPL) έχει αποδειχθεί
248
+    ότι είναι μακράν η πιο διαδεδομένη άδεια χρήσης Ελεύθερου Λογισμικού
249
+    και αντιπροσωπεύει σχεδόν τα μισά από όλα τα έργα. Η ενσωμάτωση
250
+    πατενταρισμένων τεχνολογιών σε προϊόντα Ελεύθερου Λογισμικού,
251
+    όπου είναι δυνατή, απαιτεί από τους τεχνικούς να αναμείξουν ιδιοκτησιακά
252
+    τμήματα με Ελεύθερο Λογισμικό με αδέξιους τρόπους. Σε τέτοιες περιπτώσεις
253
+    ο παραγόμενος κώδικας είναι αναγκαστικά 
254
+    ιδιοκτησιακό λογισμικό<a class="fn" href="#refs">5</a>.</p>
255
+
256
+    <h2 id="6">Η σύσταση προτίμησης για Ανοιχτά Πρότυπα είναι εντελώς άσχετη 
257
+    με τη διαπραγματευτική θέση της ΕΕ απέναντι στην Κίνα</h2>
258
+
259
+    <p>Η BSA ισχυρίζεται ότι «[η] ασάφεια στην προτεινόμενη προτίμηση 
260
+    του EIF αναμφίβολα θα υπονομεύσει την ικανότητηα της Επιτροπής
261
+    να συντηρήσει τη σθεναρή άμυνα των κατόχων δικαιωμάτων 
262
+    πνευματικής ιδιοκτησίας [ενάντια στις Κινεζικές απειλές].»</p>
263
+
264
+    <p>Ισχυρισμοί ότι μια σύσταση εκδήλωσης προτίμησης για ανοικτές
265
+    προδιαγραφές θα αποδυνάμωνε τη διαπραγματευτική θέση της ΕΕ
266
+    απέναντι στην Κίνα είναι απλώς λαθεμένοι. Οι συστάσεις σχετικά
267
+    με τη χρήση ανοικτών προδιαγραφών λογισμικού στον δημόσιο τομέα
268
+    δεν έχουν καμία επίπτωση στη στάση της Επιτροπής. Επιπλέον,
269
+    έχει σημασία να επαναληφθεί ότι πρότυπα με «μηδενικής χρέωσης δικαιώματα» 
270
+    δεν αντιστρατεύονται καμία «σθεναρή άμυνα» πατεντών, πνευματικών
271
+    δικαιωμάτων ή εμπορικών σημάτων.</p>
272
+
273
+    <p>Σημειώνουμε ότι στις Ηνωμένες Πολιτείες, παρόμοιες ανησυχίες
274
+    κατατέθηκαν στο Υπουργείο Εμπορίου κατά την προετοιμασία της
275
+    ειδικής έκθεσης 301 για το 2010 σχετικά με τα εμπόδια στο εμπόριο.
276
+    Η επιλογή του Υπουργείου Εμπορίου ήταν να μην συμπεριλάβει αυτές
277
+    τις ανησυχίες στην έκθεση, δείχνοντας ξεκάθαρα ότι η κυβέρνηση των
278
+    Ηνωμένων Πολιτειών θεωρεί ότι δεν αποτελούν ζήτημα. Ενώ τέτοιοι
279
+    ισχυρισμοί γίνονται σε προσπάθειες επηρεασμού της δημόσιας πολιτικής,
280
+    υπάρχει μια αξιοσημείωτη απουσία προσπαθειών να αφαιρεθούν τέτοιες
281
+    προτιμήσεις με νομικά μέσα - προφανώς επειδή όσοι διατυπώνουν αυτούς
282
+    τους ισχυρισμούς γνωρίζουν άριστα ότι δεν στηρίζονται στα γεγονότα.</p>
283
+
284
+    <h2 id="7">Οι ελεύθερες περιορισμών προδιαγραφές θα προωθήσουν 
285
+    την προτυποποίηση, τον ανταγωνισμό και τη διαλειτουργικότητα</h2>
286
+
287
+    <p>Η BSA ισχυρίζεται ότι «η προτεινόμενη προτίμηση του EIF για 
288
+    «ελεύθερες πνευματικής ιδιοκτησίας» ("IP-free") προδιαγραφές θα 
289
+    υπονομεύσουν...την προτυποποίηση, την ανταγωνιστικότητα και τη 
290
+    διαλειτουργικότητα μακροπρόθεσμα.»</p>
291
+
292
+    <p>Δεν είμαστε σε θέση να εξηγήσουμε τι εννοεί η BSA με τον όρο
293
+    "IP-free" προδιαγραφές, αν και θεωρούμε ότι τέτοια διατύπωση
294
+    υποδηλώνει ανεπαρκή κατανόηση από την πλευρά της BSA
295
+    της διαδικασίας θέσπισης προτύπων.</p>
296
+
297
+    <p>Ο ισχυρισμός ότι η τρέχουσα διατύπωση στο EIF θα μπορούσε να
298
+    υπονομεύσει τη διαλειτουργικότητα είναι απλώς απαράδεκτος. Έρχεται
299
+    από αναπόδεικτες υποθέσεις για τις οποίες έχουμε δείξει ότι είναι
300
+    λαθεμένες στη συζήτηση παραπάνω. Τώρα, οι συνέπειες του κλειδώματος
301
+    που απορρέουν από τη χρήση ιδιοκτησιακών προγραμμάτων και τύπων
302
+    αρχειοθέτησης συχνά παρεμποδίζουν τη δημόσια διοίκηση από την
303
+    ελεύθερη επιλογή λύσεων Πληροφορικής. Αντίθετα, τη διατηρούν
304
+    δέσμια ενός συγκεκριμένου προμηθευτή. Οι δυσκολίες του Δημοτικού
305
+    Συμβουλίου του Brighton και του καντονιού Solothurn στην Ελβετία 
306
+    (για να αναφέρουμε μόνο δύο παραδείγματα από τους πρόσφατους μήνες)
307
+    μαζί με πολυάριθμες άλλες δημόσιες υπηρεσίες κατά τη μετάβαση από 
308
+    μία λύση Πληροφορικής σε άλλη δείχνουν πώς το κλείδωμα σε προμηθευτή
309
+    που προκάλεσαν πρότυπα λογισμικού επιβαρυμένα με πατέντες προσδένει
310
+    τους χρήστες σε υποδεέστερες λύσεις, με μεγάλη επιβάρυνση για
311
+    τους φορολογούμενους.</p>
312
+
313
+    <p>Αντίθετα, πρότυπα λογισμικού τα οποία μπορούν να εφαρμοστούν
314
+    χωρίς περιορισμούς, επιτρέπουν τη διαλειτουργικότητα πολλών
315
+    ανταγωνιστικών υλοποιήσεων. Με αυτήν την πρακτική, τα μονοπωλιακά
316
+    κέρδη ενός πολύ περιορισμένου αριθμού μεγάλων παικτών αντικαθίστανται
317
+    από μια ζωντανή, καινοτόμα αγορά την οποία οδηγεί ο άγριος ανταγωνισμός.
318
+    Αυτό έχει ως αποτέλεσμα καλύτερες λύσεις και υπηρεσίες σε χαμηλότερες τιμές.</p>
319
+
320
+    <h2 id="8">Συστάσεις</h2>
321
+
322
+    <p>Υπό το φως της παραπάνω ανάλυσης, παροτρύνουμε την Επιτροπή
323
+    να ενθαρρύνει τη διαλειτουργικότητα και τον ανταγωνισμό στην Ευρωπαϊκή
324
+    αγορά λογισμικού αντί να δίνει σε κατεστημένες κυρίαρχες εταιρείες 
325
+    ένα πρόσθετο εργαλείο διατήρησης του ελέγχου τους στην αγορά. Τέλος, 
326
+    ζητάμε από την Επιτροπή να μην προσυπογράψει πολιτικές αδειοδότησης
327
+    (F)RAND για τα πρότυπα λογισμικού. Αντίθετα, παροτρύνουμε την 
328
+    Επιτροπή να διατηρήσει τις συστάσεις ότι οι προδιαγραφές μπορούν να
329
+    θεωρηθούν ανοικτές μόνο αν είναι δυνατό να υλοποιηθούν και να διαμοιραστούν
330
+    με διαφορετικά μοντέλα αδειοδότησης λογισμικού, συμπεριλαμβανομένου
331
+    Ελεύθερου Λογισμικού<a class="fn" href="#refs">6</a> με αδειοδότηση Gnu GPL.</p>
332
+
333
+    <p>Επίσης παροτρύνουμε την Επιτροπή να συμπεριλάβει στο αναθεωρημένο
334
+    Ευρωπαϊκό Πλαίσο Διαλειτουργικότητας μια σταθερή σύσταση προς τις 
335
+    δημόσιες υπηρεσίες να επωφεληθούν από τα πλεονεκτήματα λογισμικού
336
+    που βασίζεται σε Ανοιχτά Πρότυπα<a class="fn" href="#refs">7</a> 
337
+    με όρους επιλογής, ανταγωνισμού, ελευθερίας από κλειδώματα και 
338
+    μακροπρόθεσμης πρόσβασης στα δεδομένα.</p>
339
+
340
+    <h2 id="fn">Υποσημειώσεις</h2> 
341
+
342
+    <ol id="refs"> 
343
+
344
+      <li>Δείτε π.χ. Rishab Aiyer Ghosh, Philipp Schmidt (2006): 
345
+      United Nations University Policy Brief, Number 1, 2006: 
346
+      "Open standards, properly defined, can have the unique economic 
347
+      effect of allowing "natural" monopolies to form in a given technology, 
348
+      while ensuring full competition among suppliers of that technology." 
349
+      [emphasis added]</li>
350
+      
351
+      <li>Το MPEG έχει ειδικά σχεδιαστεί για τη ρητή εξουσιοδότηση 
352
+      πατενταρισμένων τεχνολογιών ακόμη και εκεί όπου αυτές είναι κατά 
353
+      μεγάλο μέρος αναπληρώσιμες από (βάσιμα) εναλλακτικές λύσεις που 
354
+      δεν επιβαρύνονται από διπλώματα ευρεσιτεχνίας. Αυτό είναι κατανοητό 
355
+      εξαιτίας της ανάγκης απόσπασης όσο το δυνατό περισσότερων κερδών 
356
+      από τη χρήση μιας ιδιόμορφης υλοποίησης, που έχουν επιλέξει, ορισμένων 
357
+      μαθηματικών αρχών αντί να αναπτύξουν μια κοινή και πρότυπη πλατφόρμα 
358
+      για τους σκοπούς της διαλειτουργικότητας.
359
+      <br />
360
+      Επιπλέον, τα περισσότερα από τα MPEG πρότυπα εμφανίστηκαν σε μια 
361
+      εποχή που οι κωδικοποιητές ήταν μέρη του υλικού επειδή το διαθέσιμο 
362
+      εύρος ζώνης ήταν περιορισμένο αλλά και διότι το γενικής χρήσης υλικό 
363
+      δεν ήταν επαρκώς ισχυρό</li>
364
+      
365
+      <li>Δείτε <a href="http://www.ecis.eu/documents/ECISStatementreEIF13.10.10.pdf">την αντίδραση της ECIS</a> 
366
+      από τις 13 Οκτωβρίου 2010 στην επιστολή της BSA</li>
367
+	  
368
+      <li>Για μια συζήτηση για τις υβριδικές λύσεις στα δικτυακά πρωτόκολλα δείτε 
369
+      <a href="/projects/ms-vs-eu/fsfe_art18_reply_published_sourcecode.pdf">Η 
370
+      απάντηση του FSFE και της Ομάδας Samba στο Άρθρο 18</a>.</li>
371
+      
372
+      <li>Δείτε <a href="http://fsfe.org/about/basics/freesoftware.en.html">Ο 
373
+      ορισμός του FSFE για το Ελεύθερο Λογισμικό</a></li>
374
+      
375
+      <li>Όπως έχει δοθεί στη σελίδα : <a href="/projects/os/def.html">οι 
376
+      ορισμοί του FSFE για το ανοιχτό πρότυπο</a></li>
377
+    
378
+    </ol>
379
+	
380
+  </body>
381
+
382
+  <timestamp>$Date: 2010-10-05 16:30:51 +0200 (Tue, 05 Oct 2010) $ $Author: samtuke $</timestamp>
383
+<tags> 
384
+<tag>open-standards</tag> 
385
+</tags>
386
+  <author id="gerloff" />
387
+  <author id="piana" />
388
+  <author id="tuke" />
389
+  <date>
390
+      <original content="2010-10-15" />
391
+  </date>
392
+ <download type="pdf" content="/projects/os/bsa-eif-letter-fsfe-response.pdf" />
393
+
394
+</html>

+ 162
- 0
projects/os/bsa-letter-analysis.en.xhtml View File

@@ -0,0 +1,162 @@
1
+<?xml version="1.0" encoding="UTF-8" ?>
2
+
3
+<html>
4
+  <head>
5
+    <meta name="keywords" content="eif,european interoperability framework,open standards,fsfe,open source,commission,europe,standards" />
6
+    <meta name="description" content="The Business Software Alliance (BSA) is pressuring the European Commission to remove the last vestiges of support for Open Standards from the latest version of the EU's interoperability recommendations, the European Interoperability Framework (EIF)" />
7
+    <title>EIF BSA Letter</title>
8
+  </head>
9
+  <body>
10
+    <p id="category"><a href="/projects/os/os.html">Open Standards</a></p>
11
+    <h1>Defending Open Standards: FSFE refutes BSA's false claims to European Commission</h1>
12
+
13
+    <p id="introduction">The Business Software Alliance (BSA) is pressuring the European Commission to remove the last vestiges of support for Open Standards from the latest version of the EU's interoperability recommendations, the European Interoperability Framework.
14
+    <br /><br />
15
+    FSFE has obtained a copy of <a href="/projects/os/bsa-letter-ec.pdf">a letter sent to the Commission</a> by the BSA last week. In the following paragraphs we analyse the BSA's arguments and explain why their claims are false, and why Open Standards are key to interoperability and competition in the European software market. We have <a href="/projects/os/bsa-eif-letter-fsfe-response.pdf">shared this analysis</a> with the European Commission.</p>
16
+    
17
+    <ol>
18
+    
19
+      <li><a href="#1">Royalty-free patent licensing opens up participation and promotes innovation</a></li>
20
+      
21
+      <li><a href="#2">The BSA's example standards are irrelevant to the software field</a></li>
22
+      
23
+      <li><a href="#3">(F)RAND licensing in software standards is unfair and discriminatory</a></li>
24
+      
25
+      <li><a href="#4">BSA not representative of even its own membership, much less of software industry as a whole</a></li>
26
+      
27
+      <li><a href="#5">(F)RAND incompatible with most Free Software licenses</a></li>
28
+      
29
+      <li><a href="#6">Recommended preference for Open Standards is entirely unrelated to EU's negotiating position vis-a-vis China</a></li>
30
+      
31
+      <li><a href="#7">Restriction-free specifications will promote standardisation, competition and interoperability</a></li>
32
+      
33
+      <li><a href="#8">Recommendations</a></li>
34
+    
35
+    </ol>
36
+
37
+    <h2 id="1">Royalty-free patent licensing opens up participation and promotes innovation</h2>
38
+
39
+    <p>In its letter, the BSA argues that "[I]f the EU adopts a preference for royalty/patent-free specifications, this undermines the incentives that firms have to contribute leading-edge innovations to standardization - resulting in less innovative European specifications, and less competitive European products."</p>
40
+
41
+    <p>Actually this reflects a gross misconception of standards, their role and their working.</p>
42
+
43
+    <ol>
44
+
45
+      <li>Zero-royalty licensing conditions do not prevent patented technologies to be included in standards. Rather the contributor is required to avoid imposing running royalties on implementations.</li>
46
+
47
+      <li>The single most successful technology platform on Earth, the Internet, is built on standards that have been made fully available under zero-royalty licensing conditions. Indeed the W3C, the standard setting organization (SSO) that governs the web standards has through consensus adopted a zero-royalty "IPR policy", where royalty bearing technologies are allowed to be contributed only on a very exceptional base. Rather than stifling inventive activity, as the BSA claims, this has turned the Internet into a hotbed of innovation. Indeed, it is the very nature of standards that they stabilise a platform on top of which competitors can create innovative and interoperable solutions<a class="fn" href="#refs">1</a>.</li>
48
+
49
+      <li>Contrary to the BSA's claim, zero-royalty patent licensing policies open up participation in software standard-setting to the widest possible group of market players and implementers. As a result, software standards coming out of standard-setting organisations with zero-royalty patent licensing policies such as the W3C have been widely adopted, with the HTML standard only being the most prominent example.</li>
50
+
51
+    </ol>
52
+
53
+    <p>From a broader policy perspective, it is also questionable that innovators, who are already receiving an incentive through a patent, would need to be further incentivised by having that patent included in a standard. A patent does not equal a right to a guaranteed revenue stream.</p>
54
+
55
+    <h2 id="2">The BSA's example standards are irrelevant to the software field</h2>
56
+
57
+    <p>The BSA argues that "[m]any of today's most widely-deployed open specifications incorporate patented innovations that were invented by commercial firms...including WiFi, GSM , and MPEG." </p>
58
+
59
+    <p>This is an attempt to create a false dichotomy between "commercial" companies inventing patented technology, in contrast to "non-commercial" inventions which are not patented. In reality a great wealth of unpatented modern technology originating in commercial companies constitute globally implemented standards (such as HTML5), whilst continuing to provide their creators with revenue.
60
+    There is no such divide, either economical or ideological, between hardware and software technologies which are patented, and those which are not. Yet the BSA divisively implies there is a difference between conventional and accepted business methods, which they associate with patents, and un-businesslike non-commercial organisations, which they associate with patent-free technology. Given the increasing prevalence of Free Software in Europe's IT service market, such a claim is plainly false.</p>
61
+
62
+    <p>The standards which the BSA cites as examples (with the exception of MPEG<a class="fn" href="#refs">2</a>) relate to hardware based technologies. The economics of the hardware market are very different from the software market. While entry into the hardware market requires very substantial investments, software companies can be started with very small amounts of capital. Requiring such software start-up to pay royalties for implementing software standards would significantly raise the barriers to market entry, reduce innovation and hinder competition, as well as raising prices for consumers (including public sector organisations).</p>
63
+
64
+    <p>For software, however, it is clear that allowing patents to be included in software standards on (F)RAND terms will unduly and unnecessarily increase the barriers to entry into the European software market, making Europe's ICT economy less competitive.</p>
65
+
66
+    <h2 id="3">(F)RAND licensing in software standards is unfair and discriminatory</h2>
67
+
68
+    <p>The BSA argues that "[R]equirements that an open specification be "freely implement[able]" and capable of being shared and re-used are ambiguous, and suggest that the standard must be free of intellectual property rights (IPR)".</p>
69
+
70
+    <p>The BSA further argues that "[FRAND ensures that] implementers of a standard can utilize those innovations on fair terms. It allows inventors to charge a reasonable fee when their technologies are incorporated into specifications[.]"
71
+    In software standards, (F)RAND terms in fact discriminate against Free Software and any business model based on it. Most widely used Free Software licenses do not allow for imposing additional conditions upon downstream recipients. Yet (F)RAND would require such conditions to be imposed, usually in the form of running royalties, rendering (F)RAND licensing policies incompatible with Free Software. Where software standards are concerned, this renders the (F)RAND approach neither reasonable nor non-discriminatory.</p>
72
+
73
+    <p>Conversely, "zero-royalty" does not exclude proprietary (and even heavily patented) implementations. Indeed "Zero-royalty" means that if certain technologies are mandated by a standard, they must be available to everybody without requiring running royalties. Meanwhile the implementations can be distributed under any given license and include any technology, provided that the standard is respected.</p>
74
+
75
+    <p>The royalty-free HTML standard for example has been implemented in a plethora of browsers, both Free Software and proprietary. This clearly demonstrates that a royalty-free software standard can enable widespread adoption, and drive innovation through competition.</p>
76
+
77
+    <h2 id="4">BSA not representative of even its own membership, much less of software industry as a whole</h2>
78
+
79
+    <p>The BSA argues that "[EIF] could be read to mean that the most innovative European and foreign companies are not welcome to participate in standards processes if they own patents in the relevant technologies and seek compensation for their inventions if those patents are made part of the standard."</p>
80
+
81
+    <p>The BSA further claims that "[S]takeholders [recognize] the important link between IPR and standardization - and also [recognize] that FRAND-based standards are highly flexible and can be implemented in a broad range of solutions, open source and proprietary".</p>
82
+
83
+    <p>Contrary to the BSA's claim to represent a unified position of the software industry, we note that ECIS, which is formed by important industry stakeholders (some of which are also members of BSA) say the opposite<a class="fn" href="#refs">3</a>. Despite having a large patent portfolio, ECIS' members want standards for software interoperability to remain unencumbered of running patent royalty requirements []. To name just one example, Google has heavily contributed to zero-royalties standards by offering an industry-backed alternative to MPEG.</p>
84
+
85
+    <h2 id="5">(F)RAND incompatible with most Free Software licenses</h2>
86
+
87
+    <p>The BSA claims that "most OSS license are entirely compatible with FRAND-based licensing."</p>
88
+
89
+    <p>By any reasonable metric (whether based upon the quantity of code available or the importance of it, or both) the most relevant Free (open source) Software licenses are:</p>
90
+
91
+    <ol>
92
+
93
+      <li>GNU GPL and LGPL</li>
94
+      <li>Mozilla Public License</li>
95
+      <li>Apache Public License</li>
96
+      <li>BSD/MIT and other ultrapermissive licenses</li>
97
+      <li>EUPL</li>
98
+
99
+    </ol>
100
+
101
+    <p>All of which, with the only arguable but uncertain exception of the ultrapermissive category, are clearly incompatible with a patent royalty bearing regime. According to the statistics released by <a href="http://www.blackducksoftware.com/oss/licenses#top20">Black Duck Software</a>, more than 85% of Free Software projects are distributed under licenses that are incompatible with patent royalty-bearing regimes. The GNU General Public License (GPL) is demonstrated to be the most widely used Free Software license by far, accounting for almost half of all projects.
102
+    Including patented technologies in Free Software products, where it is possible, requires implementers to mix proprietary parts with Free Software in awkward ways. In such cases the resulting code is necessarily proprietary software<a class="fn" href="#refs">5</a>.</p>
103
+
104
+    <h2 id="6">Recommended preference for Open Standards is entirely unrelated to EU's negotiating position vis-a-vis China</h2>
105
+
106
+    <p>The BSA claims that "[t]he ambiguity of the EIF's proposed preference will no doubt compromise the Commission's ability to maintain its robust defence of Europe's IPR holders [against Chinese threats]."</p>
107
+
108
+    <p>Claims that a recommendation to express preference for open specifications will weaken the EU's negotiating position vis-a-vis China are plainly false. Recommendations regarding the use of open software specifications in the public sector have no bearing whatsoever on the Commission's stance. Moreover, it bears repeating that "zero royalty" standards do not contradict any "robust defence" of patents, copyright and trademarks.</p>
109
+
110
+    <p>We note that in the United States, similar concerns were submitted to the US Trade Representative in the preparation for the 2010 US Special 301 report on obstacles to trade. The US Trade Representative chose not to include those concerns in the report, clearly demonstrating that the government of the United States considers this a non-issue. While such claims may be made during efforts to influence public policy, there is a marked absence of attempts to get such preferences removed by legal means - presumably because those making these claims know full well that they have no backing in fact.</p>
111
+
112
+    <h2 id="7">Restriction-free specifications will promote standardisation, competition and interoperability</h2>
113
+
114
+    <p>The BSA claims that "the EIF's proposed preference for IP-free specifications will undermine...standardization, competitiveness and interoperability over the longer term."</p>
115
+
116
+    <p>We are unable to determine what the BSA means by "IP-free" specifications, although we do believe that such wording suggests an insufficient understanding of the standard-setting process on the BSA's part.</p>
117
+
118
+    <p>The claim that the current wording of EIF could undermine interoperability is simply unacceptable. It flows from unproven assumptions that we have shown to be false in the above discussion. Currently, lock-in effects resulting from the use of proprietary programs and file formats often prevent public administrations from freely choosing their IT solutions. Instead, they remain tied to a particular vendor. The difficulties of Brighton City Council and the Swiss canton of Solothurn (to name only two examples from recent months) along with numerous other public bodies in migrating from one IT solution to another illustrate how vendor lock-in caused by patent-encumbered software standards ties users to suboptimal solutions, at great cost to taxpayers.</p>
119
+
120
+    <p>Conversely, software standards which can be implemented without restrictions allow many competing implementations to interoperate with one another. In this setting, monopoly profits for a very limited number of big players are replaced with a vibrant, innovative market driven by fierce competition. This results in better solutions and services at lower prices.</p>
121
+
122
+    <h2 id="8">Recommendations</h2>
123
+
124
+    <p>In the light of the above considerations, we urge the Commission to encourage interoperability and competition in the European software market, rather than giving incumbent dominant companies an additional lever to maintain their control of the market. To this end, we ask the Commission not to add an endorsement of (F)RAND licensing policies for software standards. 
125
+    Instead, we urge the Commission to maintain the recommendation that specifications can be considered only open if they can be implemented and shared under different software licensing models, including Free Software<a class="fn" href="#refs">6</a> licensed under the Gnu GPL.</p>
126
+
127
+    <p>We also urge the Commission to include in the revised European Interoperability Framework a robust recommendation for public bodies to avail themselves of the advantages of software based on Open Standards<a class="fn" href="#refs">7</a> in terms of choice, competition, freedom from lock-in and long-term access to data.</p>
128
+
129
+    <h2 id="fn">Footnotes</h2> 
130
+
131
+    <ol id="refs"> 
132
+
133
+      <li>See e.g. Rishab Aiyer Ghosh, Philipp Schmidt (2006): United Nations University Policy Brief, Number 1, 2006: "Open standards, properly defined, can have the unique economic effect of allowing "natural" monopolies to form in a given technology, while ensuring full competition among suppliers of that technology." [emphasis added]</li>
134
+      
135
+      <li>MPEG is specifically designed to expressly mandate patented technologies even where they are largely replaceable by (arguably) non patented encumbered alternatives. This is conceivably due to the need to extract as much profits as possible from the use of their peculiar implementation of certain mathematical principles than to the need to create a common and standardized platform for interoperability purposes.
136
+      <br />
137
+  Moreover, most of the MPEG standards were established in a time when codecs were made in hardware both because the available bandwidth was limited, the generic hardware was not sufficiently powerful and</li>
138
+      
139
+      <li>See <a href="http://www.ecis.eu/documents/ECISStatementreEIF13.10.10.pdf">ECIS' reaction</a> from October 13, 2010 to the BSA's letter</li>
140
+	  
141
+      <li>For a discussion on hybrid solutions in network protocols see <a href="/projects/ms-vs-eu/fsfe_art18_reply_published_sourcecode.pdf">FSFE and Samba Team's response to Article 18</a>.</li>
142
+      
143
+      <li>See <a href="http://fsfe.org/about/basics/freesoftware.en.html">FSFE's definition of Free Software</a></li>
144
+      
145
+      <li>As defined in <a href="/projects/os/def.html">FSFE's definitions of an open standard</a></li>
146
+    
147
+    </ol>
148
+	
149
+  </body>
150
+
151
+  <timestamp>$Date: 2010-10-05 16:30:51 +0200 (Tue, 05 Oct 2010) $ $Author: samtuke $</timestamp>
152
+<tags>
153
+<tag>open-standards</tag>
154
+</tags>
155
+    <author id="gerloff" />
156
+    <author id="piana" />
157
+    <author id="tuke" />
158
+    <date>
159
+        <original content="2010-10-15" />
160
+    </date>
161
+    <download type="pdf" content="/projects/os/bsa-eif-letter-fsfe-response.pdf" />
162
+</html>

+ 155
- 0
projects/os/bsa-letter-analysis.es.xhtml View File

@@ -0,0 +1,155 @@
1
+<?xml version="1.0" encoding="UTF-8"?>
2
+
3
+<html>
4
+  <head>
5
+    <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
6
+    <meta name="author-name-1" content="Karsten Gerloff" />
7
+    <meta name="author-link-1" content="/about/gerloff/gerloff.html" />
8
+    <meta name="author-name-2" content="Carlo Piana" />
9
+    <meta name="author-name-3" content="Sam Tuke" />
10
+    <meta name="author-link-3" content="/about/tuke/tuke.html" />
11
+    <meta name="publication-date" content="2010-10-15" />
12
+    <meta name="pdf-link" content="/projects/os/bsa-eif-letter-fsfe-response.pdf" />
13
+    <title>Carta de la BSA sobre el FEI</title>
14
+  </head>
15
+  <body>
16
+    
17
+    <h1>Defendiendo los Estándares Abiertos: la FSFE refuta las falsedades que la BSA transmitió a la Comisión Europea</h1>
18
+
19
+    <p id="introduction">La Business Software Alliance (BSA) está presionando a la Comisión Europea para eliminar los últimos vestigios de apoyo a los Estándares Abiertos de la última versión de las recomendaciones de la UE en cuestión de interoperabilidad, el Marco Europeo de la Interoperabilidad. <br /><br /> La FSFE obtuvo una copia de <a href="/projects/os/bsa-letter-ec.pdf">una carta enviada a la Comisión</a> por la BSA la semana pasada. En los párrafos siguientes vamos a analizar los argumentos de la BSA y explicar por qué sus alegaciones son falsas, y por qué los Estándares Abiertos son esenciales para la interoperabilidad y la libre competencia en el mercado europeo de software. Hemos <a href="/projects/os/bsa-eif-letter-fsfe-response.pdf">compartido este análisis</a> con la Comisión Europea.</p>
20
+    
21
+    <ol>
22
+    
23
+      <li><a href="#1">El licenciamiento de patentes libre de royalties abre la participación y promueve la innovación</a></li>
24
+      
25
+      <li><a href="#2">Los estándares que la BSA pone como ejemplo son irrelevantes para el área del software</a></li>
26
+      
27
+      <li><a href="#3">El licenciamiento (F)RAND en estándares de software es injusto y discriminatorio</a></li>
28
+      
29
+      <li><a href="#4">La BSA no es representativa ni siquiera de sus propios miembros, y mucho menos de la industria del software como un todo</a></li>
30
+      
31
+      <li><a href="#5">L (F)RAND es incompatible con la mayoría de las licencias de Software Libre</a></li>
32
+      
33
+      <li><a href="#6">La preferencia recomendada por los Estándares Abiertos es totalmente ajena a la posición en la negociación vis-a-vis entre la UE y China</a></li>
34
+      
35
+      <li><a href="#7">Las especificaciones sin restricciones promoverán la libre competencia, la normalización y la interoperabilidad</a></li>
36
+      
37
+      <li><a href="#8">Recomendaciones</a></li>
38
+    
39
+    </ol>
40
+
41
+    <h2 id="1">El licenciamiento de patentes libre de royalties abre la participación y promueve la innovación</h2>
42
+
43
+    <p>En su carta, la BSA argumenta que "[] Si la UE adopta una preferencia por especificaciones libres de patentes y/o royalties, eso perjudica a los incentivos con los que las empresas contribuyen a innovaciones punteras para la normalización - lo que deriva en especificaciones europeas menos innovadoras y productos europeos menos competitivos. []"</p>
44
+
45
+    <p>La verdad es que eso refleja un desconocimiento grave de los estándares, de su papel y de su funcionamiento.</p>
46
+
47
+    <ol>
48
+
49
+      <li>Las condiciones de licenciamiento libres de royalties (Zero-royalty) no impiden que las tecnologías patentadas sean incluidas en los estándares. En cierto grado, se obliga al proponente a evitar la imposición de royalties sobre las implementaciones.</li>
50
+
51
+      <li>La plataforma de tecnología de mayor éxito en la Tierra, Internet, está basada en estándares que fueron puestos a disposición íntegramente en condiciones de licenciamiento zero-royalty. La verdad es que el W3C, la organización de normalización (SSO) que rige los estándares en la web ha adoptado por consenso una "política de derechos de propiedad intelectual" zero-royalty, donde los royalties sobre las tecnologías pueden ser aceptados sólo sobre unos fundamentos muy excepcionales. En vez de sofocar la actividad inventiva, como afirma la BSA, esto transformó internet en un foco de innovación. Verdaderamente, es la propia naturaleza de los estándares la que estabiliza una plataforma sobre la cual los competidores pueden crear soluciones innovadoras y interoperables<a class="fn" href="#refs">1</a>.</li>
52
+
53
+      <li>Contrariamente a lo que la BSA reclama, las políticas de licenciamiento de patentes zero-royalty abren la participación en la configuración de los estándares de software para el mayor número posible de participantes e implementadores del mercado. Como resultado, los estándares de software que salen de las organizaciones de normalización con políticas de licenciamiento de patentes zero-royalty, como el W3C, han tenido una amplia aceptación, como el patrón HTML, sólo por ser el ejemplo más notable.</li>
54
+
55
+    </ol>
56
+
57
+    <p>Desde una perspectiva política más amplia, también es cuestionable que los innovadores, que ya están recibiendo un incentivo a través de una patente, necesiten ser más incentivados por tener esa patente incluida en un estándar. Una patente no es igual a tener derecho a un flujo de rentas garantizado.</p>
58
+
59
+    <h2 id="2">Los estándares que la BSA pone como ejemplo son irrelevantes para el área del software</h2>
60
+
61
+    <p>La BSA argumenta que "[] muchas de las especificaciones abiertas que en la actualidad están más ampliamente implantadas incorporan innovaciones patentadas que fueron inventadas por empresas comerciales... incluyendo el WiFi, el GSM y el MPEG."</p>
62
+
63
+    <p>Esta es una tentativa de crear una falsa dicotomía entre las empresas "comerciales" que inventan una tecnología patentada, en contraste con las "no-comerciales" que no son invenciones patentadas. En realidad, un gran banco de riqueza de modernas tecnologías no patentadas con origen en empresas comerciales constituyen estándares aplicados a nivel mundial (como HTML5), aunque sigan proporcionando a sus creadores una renta. No hay forma de hacer la división, sea a nivel económico o ideológico, entre tecnologías de hardware y software que son patentadas, y aquellas que no lo son. Sin embargo, la divisibilidad de la BSA implica que hay una diferencia entre los métodos de negocio convencionales y aceptados, a los que asocian con las patentes, y las organizaciones no-eficientes y no-comerciales, que ellos asocian con la tecnología libre de patentes. Dada la creciente presencia del Software Libre en el mercado europeo de servicios de TI, tal afirmación es claramente falsa.</p>
64
+
65
+    <p>Las normas que la BSA cita como ejemplos (con excepción de MPEG <a class="fn" href="#refs">2</a>) están relacionadas con tecnologías basadas en hardware. La economía del mercado de hardware es muy diferente a la del mercado de software. Mientras que la entrada en el mercado de hardware requiere inversiones muy sustanciales, las empresas de software pueden iniciar su actividad con pequeñas cantidades de capital. Exigir a estos iniciantes en el software el pago de royalties para la implementación de estándares de software elevaría significativamente las barreras para entrar en el mercado, reduciría la innovación y dificultaría la libre competencia, y también aumentaría los precios para los consumidores (incluyendo las organizaciones del sector público).</p>
66
+
67
+    <p>Para el software, sin embargo, está claro que permitir la inclusión de patentes en los estándares de software bajo las condiciones (F)RAND va a aumentar indebidamente e innecesariamente las barreras para entrar en el mercado europeo de software, haciendo que la economía de las TIC de Europa sea menos competitiva.</p>
68
+
69
+    <h2 id="3">El licenciamiento (F)RAND en estándares de software es injusto y discriminatorio</h2>
70
+
71
+    <p>La BSA argumenta que "[] Los requerimientos de que una especificación abierta sea "libremente implementable" y capaz de ser compartida y reutilizada son ambiguas, y sugieren que el estándar debe estar libre de derechos de propiedad intelectual (IPR)."</p>
72
+
73
+    <p>La BSA también argumenta que "[La FRAND garantiza que] los implementadores de un estándar puedan utilizar las innovaciones en términos justos. Esto permite que los inventores cobren una tasa razonable cuando las tecnologías son incorporadas a las especificaciones[.]" En los estándares de software, las condiciones (F)RAND, de hecho, discriminan al Software Libre y a cualquier modelo de negocio basado en él. Las licencias de Software Libre más ampliamente utilizadas no permiten la imposición de condiciones adicionales a los posteriores receptores. Sin embargo, las (F)RAND exigirían que tales condiciones fueran impuestas, generalmente bajo la forma de royalties, interpretándose que las políticas de licenciamiento (F)RAND son incompatibles con el Software Libre. Cuando hablamos de estándares de software, se interpreta que el enfoque de las (F)RAND no es razonable ni no-discriminatorio.</p>
74
+
75
+    <p>Por otro lado, el "zero-royalty" no excluye las implementaciones privativas (ni siquiera las fuertemente patentadas). En realidad, "Zero-royalty" significa que, si ciertas tecnologías están comprometidas por un estándar, éstas deberán estar a disposición de todos sin exigir royalties. Sin embargo, las implementaciones pueden ser distribuidas bajo cualquier licencia e incluir cualquier tecnología, siempre que la norma sea respetada.</p>
76
+
77
+    <p>El estándar HTML libre de royalties, por ejemplo, fue implementado en una infinidad de navegadores, tanto en Software Libre como privativo. Esto demuestra claramente que un estándar de software libre de royalties puede permitir la adopción generalizada, e impulsar la innovación a través de la libre competencia.</p>
78
+
79
+    <h2 id="4">La BSA no es representativa ni siquiera de sus propios miembros, y mucho menos de la industria del software como un todo</h2>
80
+
81
+    <p>La BSA argumenta que "El Marco Europeo de la Interoperabilidad (EIF) puede ser leído con la interpretación de que las empresas europeas y extranjeras más innovadoras no son invitadas a participar en procesos de normalización si tienen patentes propias en tecnologías relevantes y buscan compensaciones por sus invenciones si esas patentes son integradas en el estándar."</p>
82
+
83
+    <p>La BSA además reivindica que "Los inversores reconocen que existe un vínculo importante entre el DPI y la normalización - y también reconocen que los estándares basados en las FRAND son altamente flexibles y pueden ser implementados en una amplia gama de soluciones de código abierto y privativo".</p>
84
+
85
+    <p>Contrariamente a lo alegado por la BSA para representar una posición unificada del sector del software, acordémonos de que la ECIS, que está formada por importantes miembros de la industria (algunos de los cuales también son miembros de la BSA) dice lo contrario<a class="fn" href="#refs">3</a>. A pesar de tener una grande cartera de patentes, los miembros de la ECIS quieren estándares para que la interoperabilidad del software permanezca sin las cargas de funcionar bajo los requisitos de royalties de las patentes []. Para citar sólo un ejemplo, Google ha contribuido enormemente a los estándares zero-royalty, ofreciendo una alternativa para MPEG patrocinada por la industria.</p>
86
+
87
+    <h2 id="5">Las (F)RAND son incompatibles con la mayoría de las licencias de Software Libre</h2>
88
+
89
+    <p>La BSA afirma que "la mayoría de las licencias de las OSS son totalmente compatibles con el licenciamiento basado en las FRAND."</p>
90
+
91
+    <p>Desde un punto de vista razonable (bien sea basado en la cantidad de código disponible, en la importancia del mismo o en ambas cosas) las licencias de Software Libre u open souce más relevantes son:</p>
92
+
93
+    <ol>
94
+
95
+      <li>La GNU GPL y LGPL</li>
96
+      <li>La Mozilla Public License</li>
97
+      <li>La Apache Public License</li>
98
+      <li>La BSD/MIT y otras licencias ultra-permisivas</li>
99
+      <li>La EUPL</li>
100
+
101
+    </ol>
102
+
103
+    <p>Todas ellas, con la única excepción discutible pero incierta de la categoría ultra-permisiva, son claramente incompatibles con un régimen de patentes con royalties. En consonancia con las estadísticas publicadas por <a href="http://www.blackducksoftware.com/oss/licenses#top20">Black Duck Software</a>, más del 85% de los proyectos de Software Libre son distribuidos bajo licencias que son incompatibles con los regímenes de patentes con royalties. Está demostrado que la GNU General Public License (GPL) es, de lejos, la licencia de Software Libre más ampliamente utilizada, por ser usada por casi la mitad de todos los proyectos. Incluir las tecnologías patentadas en productos de Software Libre, cuando es posible, exige que los implementadores mezclen partes privativas con Software Libre de forma inapropiada. En esos casos, el código resultante es necesariamente software privativo<a class="fn" href="#refs">5</a>.</p>
104
+
105
+    <h2 id="6">La preferencia recomendada por los Estándares Abiertos es totalmente ajena a la posición en la negociación vis-a-vis entre la UE y China</h2>
106
+
107
+    <p>La BSA afirma que "[la] ambigüedad de la preferencia propuesta por el EIF, sin ninguna duda, compromete la capacidad de la Comisión para mantener su firme defensa de los titulares de derechos de propiedad intelectual de Europa [contra las amenazas de China]."</p>
108
+
109
+    <p>Las alegaciones de que una recomendación para expresar preferencia por especificaciones abiertas va a debilitar la posición en la negociación vis-a-vis entre la UE y China son claramente falsas. Las recomendaciones relativas a la utilización de especificaciones de software abiertas en el sector público no tienen influencia alguna sobre la posición de la Comisión. Además de eso, merece la pena repetir que las normas "zero royalty" no están enfrentadas con la "defensa robusta" de las patentes, del copyright y de las marcas comerciales.</p>
110
+
111
+    <p>Nótese que en los Estados Unidos, preocupaciones semejantes fueron sometidas a la US Trade Representative en la preparación para el informe 2010 US Special 301 sobre los obstáculos al comercio. La US Trade Representative optó por no incluir estas preocupaciones en el informe, demostrando claramente que el gobierno de los Estados Unidos considera que esto no es un problema. Aunque tales alegaciones pueden ser hechas como esfuerzos para influenciar políticas públicas, hay una marcada ausencia de tentativas para suprimir esas preferencias por medios jurídicos - presumiblemente porque aquellos que hacen estas afirmaciones saben muy bien que ellos, de hecho, no tienen respaldo.</p>
112
+
113
+    <h2 id="7">Las especificaciones sin restricciones promoverán la libre competencia, la normalización y la interoperabilidad</h2>
114
+
115
+    <p>La BSA afirma que "la preferencia propuesta por la EIF por las especificaciones libres de PI va a minar... la normalización, la competitividad y la interoperabilidad, a largo plazo."</p>
116
+
117
+    <p>Nosotros somos incapaces de determinar lo que la BSA entiende por especificaciones "libres de PI", aunque creemos que tal formulación sugiere un conocimiento insuficiente del proceso de normalización por parte de la BSA.</p>
118
+
119
+    <p>La alegación de que la actual formulación de la EIF podría perjudicar a la interoperabilidad es simplemente inaceptable. Ella fluye de hipótesis no comprobadas que hemos demostrado que son falsas en la exposición anterior. Actualmente, los efectos de bloqueo resultantes de la utilización de programas y formatos de archivo privativos muchas veces impiden que las administraciones públicas escojan libremente sus soluciones de TI. En vez de eso, ellos permanecen atados a un determinado proveedor. Las dificultades del Municipio de Brighton y del cantón suizo de Solothurn (por citar sólo dos ejemplos de los últimos meses), junto con incontables otras entidades públicas, en la migración de una solución de TI para otra, ilustra como el aprisionamiento tecnológico causado por estándares de software cubiertos por patentes, vinculan a los usuarios con soluciones precarias, con un gran coste para los contribuyentes.</p>
120
+
121
+    <p>Por otro lado, los estándares de software que pueden ser implementados sin restricciones permiten muchas implementaciones concurrentes para interactuar unas con las otras. En este escenario, los lucros de los monopolios para un número muy limitado de grandes competidores son sustituidos por un mercado vibrante e innovador impulsado por una competencia feroz. Eso tiene como resultado mejores soluciones y servicios a precios más bajos.</p>
122
+
123
+    <h2 id="8">Recomendaciones</h2>
124
+
125
+    <p>En vista de las consideraciones expuestas, instamos a la Comisión a promover la interoperabilidad y la libre competencia en el mercado europeo de software, en vez de dar a la empresas dominantes un impulso adicional para mantener su control sobre el mercado. Con esta finalidad, pedimos a la Comisión que no apruebe las políticas de licenciamiento (F)RAND para los estándares de software. En vez de eso, instamos a la Comisión a mantener la recomendación de que las especificaciones puedan ser consideradas abiertas sólo si pueden ser implementadas y compartidas bajo diferentes modelos de licenciamiento de software, incluyendo el Software Libre <a class="fn" href="#refs">6</a> licenciado bajo la GNU GPL.</p>
126
+
127
+    <p>Pedimos también a la Comisión que incluya en la revisión del Marco Europeo de la Interoperabilidad una robusta recomendación para que los organismos públicos se beneficien de las ventajas del software basado en Estándares Abiertos <a class="fn" href="#refs">7</a> en términos de elección, libre competencia, libertad de aprisionamiento tecnológico y acceso a largo plazo a los datos.</p>
128
+
129
+    <h2 id="fn">Notas a pie de página</h2> 
130
+
131
+    <ol id="refs"> 
132
+
133
+      <li>Ver por ej. Rishab Aiyer Ghosh, Philipp Schmidt (2006): Documento de
134
+Política de la Universidad de las Naciones Unidas, Número 1, 2006: "Los estándares abiertos, definidos consistentemente, pueden tener el excepcional efecto económico de permitir que se formen monopolios "naturales" en una tecnología dada, al tiempo que se asegura una libre competencia completa entre los proveedores de tal tecnología."
135
+ [énfasis añadido]</li>
136
+      
137
+      <li>El MPEG está diseñado específicamente para usar de manera explícita tecnologías patentadas, aún cuando son en gran medida substituibles (probablemente) por alternativas no patentadas que son menospreciadas. Esto es concebible debido a la necesidad de extraer el máximo lucro posible con la utilización de su peculiar aplicación de ciertos principios matemáticos, antepuesta a la necesidad de crear una plataforma común y normalizada para fines de interoperabilidad. <br /> Además de eso, la mayoría de los estándares MPEG fueron establecidos en una época en que los códecs fueron hechos en hardware tanto porque el ancho de banda disponible era limitado como porque el hardware genérico no era lo suficientemente potente.</li>
138
+      
139
+      <li>Vea <a href="http://www.ecis.eu/documents/ECISStatementreEIF13.10.10.pdf">la reacción de la ECIS</a> ante la carta de la BSA, del 13 octubre de 2010</li>
140
+	  
141
+      <li>Para una exposición sobre soluciones híbridas en protocolos de red, vea <a href="/projects/ms-vs-eu/fsfe_art18_reply_published_sourcecode.pdf">la respuesta de la FSFE y el Samba Team al artículo 18</a>.</li>
142
+      
143
+      <li>Vea la <a href="http://fsfe.org/about/basics/freesoftware.en.html">definición de Software Libre de la FSFE</a></li>
144
+      
145
+      <li>Como definimos en las <a href="/projects/os/def.html">definiciones de la FSFE de un estándar abierto</a></li>
146
+    
147
+    </ol>
148
+	
149
+  </body>
150
+
151
+  <timestamp>$Date: 2010-10-21 01:11:07 +0200 (Thu, 21 Oct 2010) $ $Author: guest-pcgaldo $</timestamp>
152
+  <translator>pcgaldo</translator>
153
+
154
+<translator></translator>
155
+</html>

+ 154
- 0
projects/os/bsa-letter-analysis.pt.xhtml View File

@@ -0,0 +1,154 @@
1
+<?xml version="1.0" encoding="UTF-8"?>
2
+
3
+<html>
4
+  <head>
5
+    <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
6
+    <meta name="author-name-1" content="Karsten Gerloff" />
7
+    <meta name="author-link-1" content="/about/gerloff/gerloff.html" />
8
+    <meta name="author-name-2" content="Carlo Piana" />
9
+    <meta name="author-name-3" content="Sam Tuke" />
10
+    <meta name="author-link-3" content="/about/tuke/tuke.html" />
11
+    <meta name="publication-date" content="2010-10-15" />
12
+    <meta name="pdf-link" content="/projects/os/bsa-eif-letter-fsfe-response.pdf" />
13
+    <title>Carta da BSA sobre o EIF</title>
14
+  </head>
15
+  <body>
16
+    
17
+    <h1>Defendendo os Padrões Abertos: a FSFE refuta as falsidades que a BSA transmitiu à Comissão Europeia</h1>
18
+
19
+    <p id="introduction">A Business Software Alliance (BSA) está a pressionar a Comissão Europeia para eliminar os últimos vestígios de apoio aos Padrões Abertos da última versão das recomendações da UE em matéria de interoperabilidade, o Quadro Europeu da Interoperabilidade. <br /><br /> A FSFE obteve uma cópia de <a href="/projects/os/bsa-letter-ec.pdf">uma carta enviada à Comissão</a> pela BSA na semana passada. Nos parágrafos seguintes vamos analisar os argumentos da BSA e explicar por que as suas alegações são falsas, e por que os Padrões Abertos são essenciais para a interoperabilidade e a livre concorrência no mercado europeu de software. Temos <a href="/projects/os/bsa-eif-letter-fsfe-response.pdf">compartilhado esta análise</a> com a Comissão Europeia.</p>
20
+    
21
+    <ol>
22
+    
23
+      <li><a href="#1">O licenciamento de patentes livre de royalties abre a participação e promove a inovação</a></li>
24
+      
25
+      <li><a href="#2">Os padrões que a BSA põe como exemplo são irrelevantes para a área do software</a></li>
26
+      
27
+      <li><a href="#3">O licenciamento (F)RAND em padrões de software é injusto e discriminatório</a></li>
28
+      
29
+      <li><a href="#4">BSA não é representativa tão sequer dos seu próprios membros, e muito menos da indústria do software como um todo</a></li>
30
+      
31
+      <li><a href="#5">A (F)RAND é incompatível com a maioria das licenças de Software Livre</a></li>
32
+      
33
+      <li><a href="#6">A preferência recomendada pelos Padrões Abertos é totalmente alheia à posição na negociação vis-a-vis entre a UE e a China</a></li>
34
+      
35
+      <li><a href="#7">As especificações sem restrições promoverão a livre concorrência, a padronização e a interoperabilidade</a></li>
36
+      
37
+      <li><a href="#8">Recomendações</a></li>
38
+    
39
+    </ol>
40
+
41
+    <h2 id="1">O licenciamento de patentes livre de royalties abre a participação e promove a inovação</h2>
42
+
43
+    <p>Na sua carta, a BSA argumenta que "[] Se a UE adota uma preferência por especificações livres de patentes e/ou royalties, isso prejudica os incentivos com os que as empresas contribuem a inovações ponteiras para a padronização - o que resulta em especificações europeias menos inovadoras, e produtos europeus menos competitivos. []"</p>
44
+
45
+    <p>Na verdade isso reflete um desconhecimento grave dos padrões, do seu papel e do seu funcionamento.</p>
46
+
47
+    <ol>
48
+
49
+      <li>As condições de licenciamento livres de royalties (Zero-royalty) não impedem que as tecnologias patenteadas sejam incluídas nos padrões. Em certo grau, o contribuinte é obrigado a evitar a imposição de royalties sobre as implementações.</li>
50
+
51
+      <li>A plataforma de tecnologia de maior sucesso na Terra, a Internet, está baseada em padrões que foram disponibilizados integralmente em condições de licenciamento zero-royalty. Na verdade, o W3C, a organização de padronização (SSO) que rege os padrões na web tem adotado por consenso uma "política de direitos de propriedade intelectual" zero-royalty, onde os royalties sobre as tecnologias podem ser aceitadas apenas sobre uns fundamentos muito excepcionais. Ao invés de sufocar a atividade inventiva, como afirma a BSA, isso transformou a internet em um foco de inovação. Na verdade, é a própria natureza dos padrões a que estabiliza uma plataforma sobre a qual os concorrentes podem criar soluções inovadoras e interoperáveis<a class="fn" href="#refs">1</a>.</li>
52
+
53
+      <li>Contrariamente ao que a BSA reclama, as políticas de licenciamento de patentes zero-royalty abrem a participação na configuração dos padrões de software para o maior número possível de partícipes e implementadores do mercado. Como resultado, os padrões de software que saem das organizações de padronização com políticas de licenciamento de patentes zero-royalty, como o W3C foram amplamente aceites, como o padrão HTML, só por ser o exemplo mais notável.</li>
54
+
55
+    </ol>
56
+
57
+    <p>Desde uma perspectiva política mais ampla, também é questionável que os inovadores, que já estão recebendo um incentivo através de uma patente, precisem ser mais incentivados por ter essa patente incluída em um padrão. Uma patente não é igual a ter direito a um fluxo de rendas garantido.</p>
58
+
59
+    <h2 id="2">Os padrões que a BSA põe como exemplo são irrelevantes para a área do software</h2>
60
+
61
+    <p>A BSA argumenta que "[] muitas das especificações abertas que na atualidade estão mais amplamente implantadas  incorporam inovações patenteadas que foram inventadas por empresas comerciais... incluindo o WiFi, a GSM e a MPEG."</p>
62
+
63
+    <p>Esta é uma tentativa de criar uma falsa dicotomia entre o empresas "comerciais" que inventam uma tecnologia patenteada, em contraste com as "não-comerciais" que não são invenções patenteadas. Na realidade um grande banco de riqueza de modernas tecnologias não patenteadas com origem em empresas comerciais constituem padrões aplicados a nível mundial (como HTML5), embora continuem a proporcionar aos seus criadores uma renda. Não há como fazer a divisão, seja a nível econômico ou ideológico, entre tecnologias de hardware e software que são patenteadas, e aquelas que não são. No entanto, a divisibilidade da BSA implica que há uma diferença entre os métodos de negócio convencionais e aceites, aos que associam com as patentes, e as organizações não-eficientes e não-comerciais, que eles associam com a tecnologia livre de patentes. Dada a crescente prevalência do Software Livre no mercado europeu de serviços de TI, tal afirmação é claramente falsa.</p>
64
+
65
+    <p>As normas que a BSA cita como exemplos (com excepção da MPEG <a class="fn" href="#refs">2</a>) estão relacionadas com tecnologias baseadas em hardware. A economia do mercado de hardware é muito diferente da do mercado de software. Embora a entrada no mercado de hardware requer investimentos muito substanciais, as empresas de software podem iniciar a sua atividade com pequenas quantidades de capital. Exigir a estes iniciantes no software o pago de royalties para a implementação de padrões de software elevaria significativamente as barreiras à entrada no mercado, reduziria a inovação e dificultaria a livre concorrência, e também aumentaria os preços para os consumidores (incluindo as organizações do sector público).</p>
66
+
67
+    <p>Para o software, no entanto, é claro que permitir a inclusão de patentes nos padrões de software baixo as condições (F)RAND vai aumentar indevidamente e desnecessariamente as barreiras à entrada no mercado europeu de software, tornando a economia das TIC da Europa menos competitiva.</p>
68
+
69
+    <h2 id="3">O licenciamento (F)RAND em padrões de software é injusto e discriminatório</h2>
70
+
71
+    <p>A BSA argumenta que "[] Os requerimentos de que uma especificação aberta seja "livremente implementável" e capaz de ser compartilhada e reutilizada são ambíguas, e sugerem que o padrão deve estar livre de direitos de propriedade intelectual (IPR)."</p>
72
+
73
+    <p>A BSA também argumenta que "[A FRAND garante que] os implementadores de um padrão podem utilizar as inovações em termos justos. Isto permite que os inventores cobrem uma taxa razoável quando as tecnologias são incorporadas as especificações[.]" Nos padrões de software, as condições (F)RAND, de facto, discriminam o Software Livre e qualquer modelo de negócio baseado nele. As licenças de Software Livre mais amplamente utilizadas não permitem a imposição de condições adicionais aos posteriores receptores. No entanto, as (F)RAND exigiria que tais condições foram impostas, geralmente sob a forma de royalties, interpretando-se que as políticas de licenciamento (F)RAND são incompatíveis com o Software Livre. Quando falamos de padrões de software, interpreta-se que a abordagem das (F)RAND não é razoável nem não-discriminatória.</p>
74
+
75
+    <p>Por outro lado, o "zero-royalty" não exclui as implementações privativas (nem sequer as fortemente patenteadas). Na verdade, "Zero-royalty" significa que, se certas tecnologias estão comprometidas por um padrão, estas deverão estar disponíveis para todos sem exigir royalties. Entretanto, as implementações podem ser distribuídas sob qualquer licença e incluir qualquer tecnologia, desde que a norma seja respeitada.</p>
76
+
77
+    <p>O padrão HTML livre de royalties, por exemplo, foi implementado em uma infinidade de navegadores, tanto em Software Livre como em privativo. Isto demonstra claramente que um padrão de software livre de royalties pode permitir a adoção generalizada, e impulsionar a inovação através da livre concorrência.</p>
78
+
79
+    <h2 id="4">BSA não é representativa tão sequer dos seu próprios membros, e muito menos da indústria do software como um todo</h2>
80
+
81
+    <p>A BSA argumenta que "O Quadro Europeu da Interoperabilidade (EIF) pode ser lido com a interpretação de que as empresas europeias e estrangeiras mais inovadoras não são convidadas a participar de processos de padronização se têm patentes próprias em tecnologias relevantes e buscam compensações pelas suas invenções se essas patentes são integradas no padrão."</p>
82
+
83
+    <p>A BSA ainda reivindica que "Os investidores reconhecem que existe um vínculo importante entre o DPI e a padronização - e também reconhecem que os padrões baseados nas FRAND são altamente flexíveis e podem ser implementados em uma ampla gama de soluções de código aberto e privativo".</p>
84
+
85
+    <p>Contrariamente ao alegado pela BSA para representar uma posição unificada do setor de software, lembremos que a ECIS, que está formado por importantes membros da indústria (alguns dos quais também são membros da BSA) diz o contrário<a class="fn" href="#refs">3</a>. Apesar de ter um grande portfólio de patentes, os membros da ECIS querem padrões para que a interoperabilidade do software permaneça sem as cargas de funcionar baixo os requisitos de royalties das patentes []. Para citar apenas um exemplo, a Google tem contribuído fortemente com os padrões zero-royalty, oferecendo uma alternativa para a MPEG patrocinada pela indústria.</p>
86
+
87
+    <h2 id="5">A (F)RAND é incompatível com a maioria das licenças de Software Livre</h2>
88
+
89
+    <p>A BSA afirma que "a maioria das licenças das OSS são totalmente compatíveis com o licenciamento baseado nas FRAND."</p>
90
+
91
+    <p>Desde um ponto de vista razoável (quer seja baseado na quantidade de código disponível ou a importância do mesmo, ou ambos) as licenças de Software Livre ou open souce mais relevantes são:</p>
92
+
93
+    <ol>
94
+
95
+      <li>A GNU GPL e LGPL</li>
96
+      <li>A Mozilla Public License</li>
97
+      <li>A Apache Public License</li>
98
+      <li>A BSD/MIT e outras licenças ultra-permissíveis</li>
99
+      <li>A EUPL</li>
100
+
101
+    </ol>
102
+
103
+    <p>Todas elas, com a única excepção discutível mas incerta da categoria ultra-permissiva, são claramente incompatíveis com um regime de patentes com royalties. De acordo com as estatísticas publicadas pelo <a href="http://www.blackducksoftware.com/oss/licenses#top20">Black Duck Software</a>, mais do 85% dos projetos de Software Livre são distribuídos sob licenças que são incompatíveis com os regimes de patentes com royalties. Está demostrado que a GNU General Public License (GPL) é, de longe, a licença de Software Livre mais amplamente utilizada, por ser usada por quase a metade de todos os projetos. Incluir as tecnologias patenteadas em produtos de Software Livre, quando é possível, exige que os implementadores misturem partes privativas com Software Livre de forma desajeitada. Nesses casos, o código resultante é necessariamente software privativo<a class="fn" href="#refs">5</a>.</p>
104
+
105
+    <h2 id="6">A preferência recomendada pelos Padrões Abertos é totalmente alheia à posição na negociação vis-a-vis entre a UE e a China</h2>
106
+
107
+    <p>A BSA afirma que "[a] ambiguidade da preferência proposta pelo EIF, sem dúvida compromete a capacidade da Comissão para manter a sua firme defesa dos titulares de direitos de propriedade intelectual da Europa [contra as ameaças da China]."</p>
108
+
109
+    <p>As alegações de que uma recomendação para expressar preferência por especificações abertas vai enfraquecer a posição na negociação vis-a-vis entre a UE e a China são claramente falsas. As recomendações relativas à utilização de especificações de software abertas no setor público não têm influência alguma sobre a posição da Comissão. Além disso, vale a pena repetir que as normas "zero royalty" não colidam com a "defesa robusta" das patentes, do copyright e das marcas comerciais.</p>
110
+
111
+    <p>Note-se que nos Estados Unidos, preocupações semelhantes foram submetidas à US Trade Representative na preparação para o relatório 2010 US Special 301 sobre os obstáculos ao comércio. A US Trade Representative optou por não incluir estas preocupações no relatório, demonstrando claramente que o governo dos Estados Unidos considera que este não é um problema. Embora tais alegações podem ser feitas como esforços para influenciar políticas públicas, há uma marcada ausência de tentativas para suprimir essas preferências por meios jurídicos - presumivelmente porque aqueles que fazem estas afirmações sabem muito bem que eles, de fato, não têm respaldo.</p>
112
+
113
+    <h2 id="7">As especificações sem restrições promoverão a livre concorrência, a padronização e a interoperabilidade</h2>
114
+
115
+    <p>A BSA afirma que "a preferência proposta pela EIF pelas especificações livres de PI vai minar... a padronização, a competitividade e a interoperabilidade, a longo prazo."</p>
116
+
117
+    <p>Nós somos incapazes de determinar o que a BSA entende por especificações "livres de PI", embora acreditamos que tal formulação sugere um conhecimento insuficiente do processo de normalização por parte da BSA.</p>
118
+
119
+    <p>A alegação de que a atual formulação da EIF poderia prejudicar a interoperabilidade é simplesmente inaceitável. Ela flui de hipóteses não comprovadas que temos demonstrado ser falsas na discussão exposta anteriormente. Atualmente, o efeitos de bloqueio resultantes da utilização de programas e formatos de arquivo privativos muitas vezes impede as administrações públicas escolherem livremente as suas soluções de TI. Em vez disso, eles permanecem ligados a um determinado fornecedor. As dificuldades do Município de Brighton e do cantão suíço de Solothurn (por citar apenas dois exemplos dos últimos meses), juntamente com inúmeras outras entidades públicas, na migração de uma solução de TI para outra ilustra como o aprisionamento tecnológico causado por padrões de software coberto por patentes, vinculam os usuários a soluções precárias, com um grande custo para os contribuintes.</p>
120
+
121
+    <p>Por outro lado, os padrões de software que podem ser implementados sem restrições permitem muitas implementações concorrentes para interagir umas com as outras. Neste cenário, os lucros dos monopólios para um número muito limitado de grandes competidores são substituídos por um mercado vibrante e inovador impulsionado por uma concorrência feroz. Isso resulta em melhores soluções e serviços a preços mais baixos.</p>
122
+
123
+    <h2 id="8">Recomendações</h2>
124
+
125
+    <p>À luz das considerações expostas, instamos a Comissão a promover a interoperabilidade e a livre concorrência no mercado europeu de software, ao invés de dar às empresas dominantes uma alavanca adicional para manter o seu controle sobre o mercado. Para este fim, pedimos à Comissão que não aprove as políticas de licenciamento (F)RAND para os padrões de software. Em vez disso, instamos a Comissão a manter a recomendação de que as especificações podam ser consideradas abertas apenas se podem ser implementadas e compartilhadas baixo diferentes modelos de licenciamento de software, incluindo o Software Livre <a class="fn" href="#refs">6</a> licenciado sob a GNU GPL.</p>
126
+
127
+    <p>Pedimos também à Comissão que inclua na revição do Quadro Europeu da Interoperabilidade uma robusta recomendação para que os organismos públicos se beneficiem das vantagens do software baseado em Padrões Abertos <a class="fn" href="#refs">7</a> em termos de escolha, livre concorrência, liberdade de aprisionamento tecnológico e acesso a longo prazo aos dados.</p>
128
+
129
+    <h2 id="fn">Notas de rodapé</h2> 
130
+
131
+    <ol id="refs"> 
132
+
133
+      <li>Ver, por exemplo: Rishab Aiyer Ghosh, Philipp Schmidt (2006): Documento da
134
+Política da Universidade das Nações Unidas, Número 1, de 2006: "Os padrões abertos, definidos de forma consistente, podem ter o efeito econômico excepcional de permitir a formação de monopólios "naturais" em uma determinada tecnologia, garantindo a livre concorrência plena entre os fornecedores dessa tecnologia." [ênfase adicionada]</li>
135
+      
136
+      <li>A MPEG está desenhada especificamente para usar de maneira explícita tecnologias patenteadas, mesmo quando são em grande parte substituíveis (provavelmente) por alternativas não patenteadas que são menospreçadas. Isto é concebível devido à necessidade de extrair o máximo lucro possível com a utilização da sua peculiar aplicação de certos princípios matemáticos, anteposta à necessidade de criar uma plataforma comum e padronizada para fins de interoperabilidade. <br /> Além disso, a maioria dos padrões MPEG foram estabelecidos em uma época em que os codecs foram feitos em hardware tanto porque a largura de banda disponível era limitada como porque o hardware genérico não era suficientemente potente.</li>
137
+      
138
+      <li>Veja <a href="http://www.ecis.eu/documents/ECISStatementreEIF13.10.10.pdf">a reação da ECIS</a> à carta da BSA, do 13 outubro de 2010</li>
139
+	  
140
+      <li>Para uma discussão sobre soluções híbridas em protocolos de rede, veja <a href="/projects/ms-vs-eu/fsfe_art18_reply_published_sourcecode.pdf">a resposta da FSFE e o Samba Team ao artigo 18</a>.</li>
141
+      
142
+      <li>Veja a <a href="http://fsfe.org/about/basics/freesoftware.en.html">definição de Software Livre da FSFE</a></li>
143
+      
144
+      <li>Como definimos nas <a href="/projects/os/def.html">definições da FSFE de um padrão aberto</a></li>
145
+    
146
+    </ol>
147
+	
148
+  </body>
149
+
150
+  <timestamp>$Date: 2010-10-21 01:11:07 +0200 (Thu, 21 Oct 2010) $ $Author: guest-pcgaldo $</timestamp>
151
+  <translator>pcgaldo</translator>
152
+
153
+<translator></translator>
154
+</html>

BIN
projects/os/bsa-letter-ec.pdf View File


+ 105
- 0
projects/os/bt-open-letter.en.xhtml View File

@@ -0,0 +1,105 @@
1
+<?xml version="1.0" encoding="UTF-8" ?>
2
+
3
+<html>
4
+  <head>
5
+    <title>Open letter to BT</title>
6
+  </head>
7
+  <body>
8
+    <h1>British Telecom: please include freedom in your new music service</h1>
9
+
10
+    <p>Dear BT,</p>
11
+
12
+    <p>
13
+      British Telecom is a leader of telecommunication and digital
14
+      content markets, and has a reputation for product innovation.
15
+      Plans recently reported for a new not-for-profit music download
16
+      service<a class="fn" href="#fn-1">1</a> for BT's 5.5 million
17
+      broadband customers have sparked much discussion, and once again
18
+      placed BT at the fore of the future of digital content delivery in
19
+      the UK.
20
+    </p>
21
+
22
+    <p>
23
+      Amongst those speculating about the nature of the new service are
24
+      the growing number of BT customers who use Free Software<a
25
+        class="fn" href="#fn-2">2</a> web-browsers, operating systems, and
26
+      multimedia players. Currently these and other Free Software users
27
+      are unable to enjoy many popular content delivery systems such as
28
+      Spotify, Steam, and iTunes, because they are not compatible with
29
+      Free Software, or require the waiving of users' rights and freedoms
30
+      in order to use them<a class="fn" href="#fn-3">3</a> <a class="fn"
31
+        href="#fn-4">4</a> <a class="fn" href="#fn-5">5</a>.  The nature of
32
+      BT's new service, and the extent to which it respects the freedom of
33
+      it's users, are therefore of particular concern.
34
+    </p>
35
+
36
+    <p>
37
+      Powerful new Open Standards<a class="fn" hreF="#fn-6">6</a> like
38
+      HTML5 and CSS3, combined with widely used Free Software codecs for
39
+      rich multimedia like VP8 and Ogg Vorbis, make it easier than ever
40
+      to build powerful cross-platform applications which respect user
41
+      freedom whilst maintaining long term accessibility.  Recent
42
+      adoption of these technologies by established content providers
43
+      such as YouTube, the Norwegian Broadcasting Corporation,
44
+      Dailymotion, and Deutschlandradio, reflect a growing industry
45
+      trend towards platform independence through use of Free Software
46
+      and Open Standards<a class="fn" href="#fn-7">7</a> <a class="fn"
47
+        href="#fn-8">8</a> <a class="fn" href="#fn-9">9</a> <a
48
+        class="fn" href="#fn-10">10</a>.
49
+    </p>
50
+
51
+    <p>
52
+      In addition to these web-based technologies exists Free Software
53
+      tools like Qt and Gtk, which continue to be used by thousands of
54
+      companies<a class="fn" href="#fn-11">11</a> to develop world-class
55
+      desktop applications compatible with all major operating systems.
56
+    </p>
57
+
58
+    <p>
59
+      BT already makes wide use of Free Software<a class="fn"
60
+        href="#fn-12">12</a>, and “recognises,
61
+      and welcomes the use of open source software”<a class="fn"
62
+        href="#fn-13">13</a>.  Therefore we
63
+      ask that you recognise the value of your customer's freedom as you
64
+      design and deploy your new subscription service, and take the
65
+      opportunity to benefit from one of the many Free Software
66
+      technologies which will allow you to achieve this.
67
+    </p>
68
+
69
+    <p>
70
+      The Free Software Foundation Europe is happy to assist you with
71
+      any questions regarding this issue or Free Software and Open
72
+      Standards in general.
73
+    </p>
74
+
75
+    <p>
76
+      Yours Sincerely,
77
+    </p>
78
+
79
+    <p>
80
+      <strong><a href="/uk/">UK Team</a>, Free Software Foundation
81
+        Europe</strong>
82
+    </p>
83
+
84
+    <h2 id="fn">Footnotes</h2>
85
+
86
+    <ol>
87
+      <li id="fn-1"><a href="http://www.guardian.co.uk/technology/pda/2011/mar/28/bt-illegal-filesharing-music">http://www.guardian.co.uk/technology/pda/2011/mar/28/bt-illegal-filesharing-music</a></li>
88
+      <li id="fn-2"><a href="/about/basics/freesoftware.en.html">http://fsfe.org/about/basics/freesoftware.en.html</a></li>
89
+      <li id="fn-3"><a href="http://www.spotify.com/int/legal/end-user-agreement/#section-12">http://www.spotify.com/int/legal/end-user-agreement/#section-12</a></li>
90
+      <li id="fn-4"><a href="http://www.gamesindustry.biz/articles/2010-08-12-valve-on-steam-part-two-interview">http://www.gamesindustry.biz/articles/2010-08-12-valve-on-steam-part-two-interview</a></li>
91
+      <li id="fn-5"><a href="http://images.apple.com/legal/sla/docs/itunes.pdf">http://images.apple.com/legal/sla/docs/itunes.pdf</a></li>
92
+      <li id="fn-6"><a href="/projects/os/os.html">http://fsfe.org/projects/os/os.html</a></li>
93
+      <li id="fn-7"><a href="http://www.youtube.com/html5">http://www.youtube.com/html5</a></li>
94
+      <li id="fn-8"><a href="http://www.fsf.org/campaigns/playogg/sites/norway">http://www.fsf.org/campaigns/playogg/sites/norway</a></li>
95
+      <li id="fn-9"><a href="http://www.dailymotion.com/html5">http://www.dailymotion.com/html5</a></li>
96
+      <li id="fn-10"><a href="http://www.dradio.de/wir/ogg/">http://www.dradio.de/wir/ogg/</a></li>
97
+      <li id="fn-11"><a href="http://www.digia.com/C2256FEF0043E9C1/0/405002251">http://www.digia.com/C2256FEF0043E9C1/0/405002251</a></li>
98
+      <li id="fn-12"><a href="http://opensource.bt.com/ under 'products and projects'">http://opensource.bt.com/ under "products and projects"</a></li>
99
+      <li id="fn-13"><a href="http://www.selling2bt.bt.com/Downloads/BTOpenSourcePolicyextractsforsuppliersIssue1.pdf">http://www.selling2bt.bt.com/Downloads/BTOpenSourcePolicyextractsforsuppliersIssue1.pdf</a> ("Open source software" and "Free Software" refer to the same thing <a href="/documents/whyfs.en.html">with different connotations</a>)</li>
100
+    </ol>
101
+  </body>
102
+
103
+  <timestamp>$Date: 2010-10-05 16:30:51 +0200 (Tue, 05 Oct 2010) $ $Author: samtuke $</timestamp>
104
+  <translator></translator>
105
+</html>

+ 112
- 0
projects/os/def.de.xhtml View File

@@ -0,0 +1,112 @@
1
+<?xml version="1.0" encoding="UTF-8"?>
2
+<html>
3
+ <head>
4
+  <title>Definition – Offene Standards – FSFE</title>
5
+  <meta content="Definition Offener Standards mit einem Kommentar über aufkommende Standards und Links zu anderen Defintionen." name="description"/>
6
+  <meta content="Open Standards certified open European interoperability framework SELF EU Project Geneva Declaration on Standards Future of the Internet Document Freedom Day Definition Emerging Standards FSFE pdf" name="keywords"/>
7
+ </head>
8
+ <body>
9
+  <p id="category"><a href="/projects/work.html">Unsere Arbeit</a> / <a href="/projects/os/os.html">Überblick zu Offenen Standards</a></p>
10
+
11
+  <h1>Offene Standards</h1>
12
+
13
+  <div id="introduction">
14
+   <p>Es gibt keine allgemein gültige Definition darüber, was 
15
+    einen Offenen Standard ausmacht, aber eine Vielzahl von Vorschlägen.
16
+    Links zu einigen dieser Vorschläge sind unten aufgeführt. </p>
17
+  </div>
18
+
19
+  <p>Die FSFE wollte nicht noch eine weitere Definition vorschlagen.  Wir
20
+    beschlossen, uns der Definition eines Offenen Standards anzuschließen, die
21
+    im Rahmen der Vorbereitungen
22
+    für <a href="http://www.certifiedopen.com">Certified Open</a> geschaffen
23
+    wurde. Die Arbeit an der Definition begann, bevor die FSFE sich an diesem
24
+    Projekt beteiligte und basierte zu Beginn auf der Definition des
25
+    <a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">Europäischen
26
+    Rahmenprogramms zur Interoperabilität (EIF)</a> der Europäischen
27
+   Kommission.</p>
28
+
29
+  <p>Im Gespräch mit mehreren Schlüsselfiguren der Industrie, Politik und
30
+    Gemeinschaft wurde die Definition überarbeitet und in eine Definition von
31
+    fünf Punkten, denen alle Beteiligten zustimmten, umgearbeitet. Diese
32
+    Definition fand schließlich Anwendung
33
+    beim <a href="http://selfproject.eu/OSD">SELF-EU-Projekt</a>, der
34
+    Genfer <a href="http://www.openforumeurope.org/library/geneva/declaration/manifesto-with-logos-final.pdf">Erklärung
35
+    zu Standards und der Zukunft des Internets</a> 2008 oder
36
+    dem <a href="http://documentfreedom.org/openstandards.de.html">Document Freedom
37
+     Day</a>.</p>
38
+
39
+  <h2>Definition</h2>
40
+
41
+  <p>Ein Offener Standard ist ein Format oder Protokoll, das</p>
42
+  <ol>
43
+   <li>von der Öffentlichkeit vollinhaltlich geprüft und verwendet werden kann;</li>
44
+   <li>ohne jegliche Komponenten oder Erweiterungen ist, die von
45
+      Formaten oder Protokollen abhängen, die selbst nicht der Definition
46
+      eines Offenen Standards entsprechen;</li>
47
+   <li>frei von rechtlichen Klauseln oder technischen Einschränkungen ist,
48
+      die seine Verwendung von jeglicher Seite oder mit jeglichem
49
+      Geschäftsmodell behindern;</li>
50
+   <li>unabhängig von einem einzelnen Anbieter koordiniert und weiterentwickelt
51
+      wird, in einem Prozess, der einer gleichberechtigten Teilnahme von
52
+      Wettbewerbern und Dritten offen steht;</li>
53
+   <li>in verschiedenen vollständigen Implementierungen von
54
+      verschiedenen Anbietern oder als vollständige Implementierung
55
+      gleichermaßen für alle Beteiligten verfügbar ist.</li>
56
+  </ol>
57
+
58
+  <h3>Kommentar zu Entwicklungsstandards</h3>
59
+
60
+  <p>Wenn ein neues Format oder Protokoll entwickelt wird, kann der fünfte
61
+    Punkt wahrscheinlich nicht eingehalten werden. Die FSFE hält dies für
62
+    korrektes Verhalten, wenn technologische Reife benötigt wird. In
63
+    verschiedenen Szenarien wie etwa die Verwendung durch Regierungen können
64
+    Ausfallkosten sehr hoch ausfallen.</p>
65
+
66
+  <p>In Szenarien, die das Wachstum Offener Standards fördern wollen, könnte
67
+    eine strikte Anwendung der Klausel neue Offene Standards verhindern. Aus
68
+    Sicht der Definition würden solche Standards mit herstellergesteuerten
69
+    proprietären Formaten direkt konkurrieren. In solchen Fällen kann es sinnvoll
70
+    sein, „Entwicklungsstandards“ zu erlauben, der fünften Klausel nicht zu
71
+    entsprechen.</p>
72
+
73
+  <p>Welche Behandlung solche „Entwicklungsstandards“ erhalten, hängt zum
74
+    größten Teil von der Situation ab. Wo hohe Ausfallkosten anfallen, sollten
75
+    nur vollständig Offene Standards verwendet werden. Wo eine Förderung
76
+    Offener Standards erwünscht ist, sollten Entwicklungsstandards eine
77
+    besondere Förderung erhalten.</p>
78
+
79
+  <p>Allgemein formuliert: Offene Standards sind besser als
80
+    Entwicklungsstandards und Entwicklungsstandards sind besser als
81
+    herstellerspezifische Formate. Je mehr ein Format allen Punkten der
82
+    Definition entspricht, desto höher sollte es in Szenarien eingestuft
83
+    werden, bei denen Interoperabilität und zuverlässige
84
+    Langzeit-Datenspeicherung entscheidend sind.</p>
85
+
86
+  <h3>Links zu anderen Definitionen</h3>
87
+  
88
+  <p>Wikipedia gibt einen Überblick zum Begriff <a
89
+   href="http://de.wikipedia.org/wiki/Offener_Standard">Offener Standard</a> und
90
+  führt verschiedene Definitionen an. Nachfolgend einige Bespiele für eine
91
+  Definition:</p>
92
+
93
+  <ul>
94
+   <li>
95
+    <a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">Europäisches Rahmenprogramm</a>
96
+   </li>
97
+   <li>
98
+    <a href="http://www.ft.dk/Samling/20051/beslutningsforslag/B103/index.htm">Motion B 103 des Dänischen Parlaments</a>
99
+   </li>
100
+   <li><a href="http://perens.com/OpenStandards/Definition.html">Open Standards - Principles and Practice</a> von Bruce Perens</li>
101
+   <li><a href="http://www.digistan.org/open-standard:definition">Open Standards Definition</a> von Digistan</li>
102
+  </ul>
103
+
104
+ </body>
105
+ <timestamp>$Date$ $Author$</timestamp>
106
+ <translator>Andreas Aubele</translator>
107
+</html>
108
+<!--
109
+Local Variables: ***
110
+mode: xml ***
111
+End: ***
112
+-->

+ 111
- 0
projects/os/def.el.xhtml View File

@@ -0,0 +1,111 @@
1
+<?xml version="1.0" encoding="UTF-8" ?>
2
+
3
+<html>
4
+  <head>
5
+    <title>FSFE - Ανοιχτά Πρότυπα - Ορισμός</title>
6
+<meta content="Ορισμός για τα Ανοιχτά Πρότυπα, με σχόλιο σχετικά με τα αναδυόμενα πρότυπα και συνδέσμους σε άλλους ορισμούς." name="description" /> 
7
+<meta content="Ανοιχτά Πρότυπα certified open Ευρωπαϊκό Πλαίσιο Διαλειτουργικότητας SELF EU Project Διακήρυξη της Γενεύης για τα Πρότυπα Μέλλον του Διαδικτύου Ημέρα Ελευθερίας Εγγράφων Ορισμός Αναδυόμενα Πρότυπα FSFE pdf" name="keywords" /> 
8
+  </head>
9
+
10
+  <body>
11
+ <p id="category"><a href="http://www.fsfe.org/projects/work.html">Η Εργασία 
12
+ μας</a> / <a href="/projects/os/os.html">Επισκόπηση στα Ανοιχτά Πρότυπα</a></p>
13
+    <h1>Ανοιχτά Πρότυπα</h1>
14
+
15
+<div id="introduction">
16
+
17
+    <p>Δεν υπάρχει ένας κοινά αποδεκτός ορισμός για τα Ανοιχτά Πρότυπα,
18
+    αντίθετα υπάρχει μια πληθώρα προτάσεων. Σύνδεσμοι σε μερικούς από
19
+    αυτούς περιλαμβάνονται πιο κάτω.</p>
20
+</div>
21
+    <p>Το FSFE δεν ήθελε να προτείνει άλλον έναν ορισμό. Αποφασίσαμε να
22
+    ακολουθήσουμε τον ορισμό του Ανοιχτού Προτύπου που τέθηκε ως τμήμα
23
+    της προετοιμασίας για το <a href="http://www.certifiedopen.com">Certified
24
+    Open</a>. Η εργασία για αυτόν τον ορισμό ξεκίνησε πριν την ανάμειξη του
25
+    FSFE στο πρόγραμμα και αρχικά βασίστηκε στον ορισμό του
26
+    <a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">
27
+    Ευρωπαϊκού Πλαισίου Διαλειτουργικότητας (EIF)</a> 
28
+    της Ευρωπαϊκής Επιτροπής.</p>
29
+
30
+    <p>Σε έναν διάλογο που περιείχε διάφορους παίκτες κλειδιά από τη
31
+    βιομηχανία, την πολιτική και τις κοινότητες, ο ορισμός αναθεωρήθηκε
32
+    σε ένα σύνολο πέντε σημείων το οποίο κέρδισε τη συναίνεση όλων των
33
+    ενδιαφερομένων. Ακολούθως, ο ορισμός υιοθετήθηκε από το
34
+    <a href="http://selfproject.eu/OSD">Πρόγραμμα SELF της ΕΕ</a>, τη
35
+    <a href="http://www.openforumeurope.org/library/geneva/declaration/manifesto-with-logos-final.pdf">
36
+    Διακήρυξη σχετικά με τα Πρότυπα και το Μέλλον του Διαδικτύου</a> της Γενεύης του 2008 και
37
+    την
38
+    <a href="http://documentfreedom.org/openstandards.el.html">Ημέρα Ελευθερίας Εγγράφων</a>.</p>
39
+
40
+  <h2>Ορισμός</h2>
41
+
42
+    <p>Ένα Ανοιχτό Πρότυπο αναφέρεται σε έναν τύπο αρχειοθέτησης ή ένα 
43
+    πρωτόκολλο</p>
44
+    <ol>
45
+      <li>το οποίο υπόκειται σε πλήρη δημόσια αξιολόγηση και χρήση χωρίς
46
+      περιορισμούς με τρόπο ισότιμα διαθέσιμο σε όλους τους 
47
+      ενδιαφερόμενους·</li>
48
+      <li>χωρίς τμήματα ή επεκτάσεις που να εξαρτώνται από τύπους αρχειοθέτησης
49
+      ή πρωτόκολλα τα οποία δεν πληρούν τα ίδια τον ορισμό του Ανοιχτού 
50
+      Προτύπου·</li>
51
+      <li>ελεύθερο από νομικές ή τεχνικές διατυπώσεις που περιορίζουν τη 
52
+      χρηστικότητά του από οποιονδήποτε ενδιαφερόμενο ή επιχειρηματικό 
53
+      μοντέλο·</li>
54
+      <li>με διαχείριση και επιπλέον ανάπτυξη ανεξάρτητα από οποιονδήποτε
55
+      μοναδικό προμηθευτή σε μια διαδικασία ανοιχτή στην ισότιμη συμμετοχή
56
+      ανταγωνιστών και τρίτων·</li>
57
+      <li>διαθέσιμο σε πολλαπλές πλήρεις υλοποιήσεις από ανταγωνιστικούς
58
+      προμηθευτές ή ως πλήρης υλοποίηση ισότιμα διαθέσιμο σε όλους τους
59
+      ενδιαφερόμενους.</li>
60
+    </ol>
61
+
62
+    <h3>Σχόλιο για τα Αναδυόμενα Πρότυπα</h3>
63
+
64
+    <p>Όταν ένα νέος τύπος ή πρωτόκολλο είναι σε φάση ανάπτυξης, το σημείο 5
65
+    δεν είναι δυνατό να πληρείται. Το FSFE θεωρεί ότι αυτή είναι η σωστή
66
+    συμπεριφορά σε περιπτώσεις στις οποίες απαιτείται τεχνολογική ωριμότητα.
67
+    Σε διάφορα σενάρια, όπως στη περίπτωση ανάπτυξης κυβερνητικών έργων, το
68
+    κόστος της αποτυχίας μπορεί να είναι πολύ υψηλό.</p>
69
+
70
+    <p>Σε σενάρια όπου το ζητούμενο είναι η προώθηση των Ανοιχτών Προτύπων,
71
+    η αυστηρή εφαρμογή του σημείου θα εμπόδιζε νέα Ανοιχτά Πρότυπα. Από
72
+    την άποψη του ορισμού, τέτοια πρότυπα θα ανταγωνίζονταν απ' ευθείας με
73
+    ιδιοκτησιακούς τύπους που προτείνουν προμηθευτές. Σε τέτοιες περιπτώσεις
74
+    μπορεί να έχει νόημα να επιτρέπεται η αποτυχία του σημείου 5 για τα
75
+    ''Αναδυόμενα Πρότυπα''</p>
76
+
77
+    <p>Ποια μεταχείριση επιδέχονται τέτοια ''Αναδυόμενα Πρότυπα'' εξαρτάται
78
+    από την περίπτωση. Όπου το κόστος της αποτυχίας είναι υψηλό, μόνο
79
+    πλήρως Ανοιχτά Πρότυπα πρέπει να χρησιμοποιούνται. Όπου η προώθηση των
80
+    Ανοιχτών Προτύπων είναι το ζητούμενο, τα Αναδυόμενα Πρότυπα πρέπει να
81
+    τυγχάνουν ειδικής προβολής.</p>
82
+
83
+    <p>Σε γενικές γραμμές: Τα Ανοιχτά Πρότυπα είναι καλύτερα από τα Αναδυόμενα
84
+    Πρότυπα και τα Αναδυόμενα Πρότυπα είναι καλύτερα από τους τύπους που
85
+    εξαρτώνται από προμηθευτές. Όσο πιο κοντά ένας τύπος βρίσκεται στο να
86
+    πληρεί όλα τα σημεία του ορισμού, τόσο υψηλότερα θα πρέπει να κατατάσσεται
87
+    σε σενάρια όπου η διαλειτουργικότητα και η αξιόπιστη μακροπρόθεσμη
88
+    αποθήκευση είναι το ουσιαστικό.</p>
89
+
90
+    <h3>Σύνδεσμοι σε άλλους ορισμούς</h3>
91
+
92
+    <p>Η Wikipedia έχει μια επισκόπηση του όρου
93
+    <a href="http://en.wikipedia.org/wiki/Open_standard">Ανοιχτό Πρότυπο</a>
94
+    και διάφορους ορισμούς. Οι ακόλουθοι είναι ένα δείγμα από αυτούς:</p>
95
+
96
+    <ul>
97
+      <li><a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">European Interoperability Framework</a></li>
98
+      <li><a href="http://www.ft.dk/Samling/20051/beslutningsforslag/B103/index.htm">Motion B 103 of the Danish Parliament</a></li>
99
+      <li><a href="http://perens.com/OpenStandards/Definition.html">Open Standards - Principles and Practice</a> by Bruce Perens</li>
100
+      <li><a href="http://www.digistan.org/open-standard:definition">Open Standards Definition</a> by Digistan</li>
101
+    </ul>
102
+
103
+  </body>
104
+
105
+  <timestamp>$Date$ $Author$</timestamp>
106
+</html>
107
+<!--
108
+Local Variables: ***
109
+mode: xml ***
110
+End: ***
111
+-->

+ 106
- 0
projects/os/def.en.xhtml View File

@@ -0,0 +1,106 @@
1
+<?xml version="1.0" encoding="UTF-8" ?>
2
+
3
+<html>
4
+  <head>
5
+    <title>FSFE - Open Standards - Definition</title>
6
+<meta content="Definition of Open Standards, with comment on emerging standards and links to other definitions." name="description" />
7
+<meta content="Open standards certified open European interoperability framework SELF EU Project Geneva Declaration on Standards Future of the Internet Document Freedom Day Definition Emerging Standards FSFE pdf" name="keywords" />
8
+  </head>
9
+
10
+  <body>
11
+ <p id="category"><a href="http://www.fsfe.org/projects/work.html">Our Work</a> / <a href="/projects/os/os.html">Overview of Open Standards</a></p>
12
+    <h1>Open Standards</h1>
13
+
14
+<div id="introduction">
15
+
16
+    <p>There is no universally accepted definition of what constitutes
17
+    an Open Standard and no shortage of proposals. Links to some of
18
+    them have been included below. </p>
19
+</div>
20
+    <p>FSFE did not want to propose yet another definition. We decided
21
+    to go with the definition of an Open Standard that was developed
22
+    as part of the preparations
23
+    for <a href="http://www.certifiedopen.com">Certified
24
+    Open</a>. Work on this definition began before FSFE's involvement
25
+    on the project and was initially based on the definition in
26
+    the <a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">European
27
+    Interoperability Framework (EIF)</a> of the European
28
+    Commission.</p>
29
+
30
+    <p>In a dialog involving various key players in industry, politics
31
+    and community, the definition was reworked into a definition of
32
+    five points that found consensus among all the involved. The
33
+    definition has subsequently been adopted by
34
+    the <a href="http://selfproject.eu/OSD">SELF EU Project</a>, the
35
+    2008 Geneva
36
+    <a href="http://www.openforumeurope.org/library/geneva/declaration/manifesto-with-logos-final.pdf">Declaration
37
+    on Standards and the Future of the Internet</a> or
38
+    the <a href="http://documentfreedom.org/openstandards.en.html">Document
39
+    Freedom Day</a>.</p>
40
+
41
+    <h2>Definition</h2>
42
+
43
+    <p>An Open Standard refers to a format or protocol that is</p>
44
+    <ol>
45
+      <li>subject to full public assessment and use without
46
+      constraints in a manner equally available to all parties;</li>
47
+      <li>without any components or extensions that have dependencies
48
+      on formats or protocols that do not meet the definition of an
49
+      Open Standard themselves;</li>
50
+      <li>free from legal or technical clauses that limit its
51
+      utilisation by any party or in any business model;</li>
52
+      <li>managed and further developed independently of any single
53
+      vendor in a process open to the equal participation of
54
+      competitors and third parties;</li>
55
+      <li>available in multiple complete implementations by competing
56
+      vendors, or as a complete implementation equally available to
57
+      all parties.</li>
58
+    </ol>
59
+
60
+    <h3>Comment on Emerging Standards</h3>
61
+
62
+    <p>When a new format or protocol is under development, clause 5
63
+    cannot possibly be met. FSFE believes this is the correct
64
+    behaviour in cases where technological maturity is required. In
65
+    several scenarios, e.g. governmental deployment, the cost of
66
+    failure can be very high.</p>
67
+
68
+    <p>In scenarios that seek to promote the growth of Open Standards,
69
+    strict application of the clause could prevent new Open
70
+    Standards. From the view of the definition, such standards would
71
+    compete directly against vendor-driven proprietary formats. In
72
+    such cases, it can make sense to allow failure of clause 5 for
73
+    "Emerging Standards."</p>
74
+
75
+    <p>Which treatment such "Emerging Standards" receive is largely
76
+    dependent on the situation. Where cost of failure is high, only
77
+    fully Open Standards should be used. Where promotion of Open
78
+    Standards is wanted, Emerging Standards should receive special promotion.</p>
79
+
80
+    <p>Generally speaking: Open Standards are better than Emerging
81
+    Standards and Emerging Standards are better than vendor-specific
82
+    formats. The closer a format comes to meeting all points of the
83
+    definition, the higher it should be ranked in scenarios where
84
+    interoperability and reliable long-term data storage is
85
+    essential.</p>
86
+
87
+    <h3>Links to other definitions</h3>
88
+
89
+    <p>Wikipedia has an overview of the term <a href="http://en.wikipedia.org/wiki/Open_standard">Open Standard</a> and various definitions. The following is a sample of some definitions:</p>
90
+
91
+    <ul>
92
+      <li><a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">European Interoperability Framework</a></li>
93
+      <li><a href="http://www.ft.dk/Samling/20051/beslutningsforslag/B103/index.htm">Motion B 103 of the Danish Parliament</a></li>
94
+      <li><a href="http://perens.com/OpenStandards/Definition.html">Open Standards - Principles and Practice</a> by Bruce Perens</li>
95
+      <li><a href="http://www.digistan.org/open-standard:definition">Open Standards Definition</a> by Digistan</li>
96
+    </ul>
97
+
98
+  </body>
99
+
100
+  <timestamp>$Date$ $Author$</timestamp>
101
+</html>
102
+<!--
103
+Local Variables: ***
104
+mode: xml ***
105
+End: ***
106
+-->

+ 115
- 0
projects/os/def.es.xhtml View File

@@ -0,0 +1,115 @@
1
+<?xml version="1.0" encoding="UTF-8" ?>
2
+
3
+<html>
4
+  <head>
5
+    <title>FSFE - Estándares Abiertos - Definición</title>
6
+  </head>
7
+
8
+  <body>
9
+ <p id="category"><a href="http://www.fsfe.org/projects/work.html">Nuestra Acción</a> / <a href="/projects/os/os.html">Estándares Abiertos</a></p>
10
+    <h1>Estándares Abiertos</h1>
11
+
12
+<div id="introduction">
13
+
14
+    <p>No hay una definición universalmente aceptada de qué constituye
15
+    un Estándar Abierto, aunque hay muchas propuestas al respecto. Más
16
+    abajo hay enlaces a algunas de ellas.</p>
17
+
18
+</div>
19
+    <p>La FSFE no quiere proponer una definición más. Hemos decidido
20
+    usar la definición de Estándar Abierto desarrollada como parte de
21
+    los preparativos para el
22
+    <a href="http://www.certifiedopen.com">Certified Open</a>. Se
23
+    empezó a trabajar en esta definición antes de que la FSFE se
24
+    involucrara en el proyecto y estaba basada en la definición de la
25
+    <a href="http://ec.europa.eu/idabc/en/document/3473/5585.html#finalEIF">European
26
+    Interoperability Framework (EIF)</a> de la Comisión Europea.</p>
27
+
28
+    <p>En un diálogo en el que intervinieron varios actores
29
+    principales de la industria, la política y la comunidad, la
30
+    definición fue convertida en una definición de cinco puntos que
31
+    consiguió el consenso de las partes implicadas. Posteriormente, la
32
+    definición ha sido adoptada por el
33
+    <a href="http://selfproject.eu/OSD">SELF EU Project</a>, la
34
+    <a href="http://www.openforumeurope.org/library/geneva/declaration/manifesto-with-logos-final.pdf">Declaration
35
+    on Standards and the Future of the Internet</a> de 2008 en Genova
36
+    o el <a href="http://documentfreedom.org/openstandards.es.html">Document
37
+    Freedom Day</a>.</p>
38
+
39
+    <h2>Definición</h2>
40
+
41
+    <p>Un Estándar Abierto hace referencia a un formato o protocolo
42
+    que</p>
43
+    <ol>
44
+      <li>esté sujeto a una evaluación pública completa,
45
+      se pueda usar sin restricciones y esté disponible por igual para
46
+      todas las partes;</li>
47
+      <li>no necesite ningún componente o extensión adicional que
48
+      tenga dependencias con formatos o protocolos que no cumplan la
49
+      definición de un Estándar Abierto;</li>
50
+      <li>esté libre de cláuslas legales o técnicas que limiten su
51
+      utilización por cualquier parte o en cualquier modelo de
52
+      negocio;</li>
53
+      <li>esté gestionado y pueda ser desarrollado independientemente
54
+      por cualquier compañía en un proceso abierto a la participación
55
+      equitativa por parte de competidores y terceras partes;</li>
56
+      <li>esté disponible en varias implementaciones completas por
57