Location: guide/enforcement-case-studies.tex

bkuhn
Citations of third-party works in appendix only. As alluded to in 2ea19b71d4a917babb29024f06acabfe73309f40 's commit message on 2014-12-17 19:52:15 -0500, keeping any information on a part-by-part basis is difficult and error-prone, since there exists no reliable way to auto-generate such information accurately. Therefore, citations to third-party works, in addition to remaining fully documented in the commit log as they always have been, are now placed in specifically one location in the body of the text itself: a single appendix specifically designed for that purpose. In this manner, contributors have no house-keeping work regarding citations. Contributors need only list third party works and links in one place: third-party-citations.tex. Documentation in CONTRIBUTING.md for making contributions of third-party works is left as a TODO.
   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  62
  63
  64
  65
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954
 955
 956
 957
 958
 959
 960
 961
 962
 963
 964
 965
 966
 967
 968
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
% Tutorial Text for the Detailed Study and Analysis of GPL and LGPL course
% License: CC-By-SA-4.0
% The copyright holders hereby grant the freedom to copy, modify, convey,
% Adapt, and/or redistribute this work under the terms of the Creative
% Commons Attribution Share Alike 4.0 International License.
% This text is distributed in the hope that it will be useful, but
% WITHOUT ANY WARRANTY; without even the implied warranty of
% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
% You should have received a copy of the license with this document in
% a file called 'CC-By-SA-4.0.txt'. If not, please visit
% https://creativecommons.org/licenses/by-sa/4.0/legalcode to receive
% the license text.
\part{Case Studies in GPL Enforcement}
{\parindent 0in
This part is: \\
\begin{tabbing}
Copyright \= \copyright{} 2003, 2004, 2014 \hspace{1mm} \= \hspace{1.mm} \= \kill
Copyright \> \copyright{} 2014 \> Bradley M. Kuhn. \\
Copyright \> \copyright{} 2014 \> Denver Gingerich \\
Copyright \> \copyright{} 2003, 2004, 2014 \> Free Software Foundation, Inc. \\
\end{tabbing}
\vspace{.2in}
\begin{center}
The copyright holders hereby grant the freedom to copy, modify, convey,
Adapt, and/or redistribute this work under the terms of the Creative Commons
Attribution Share Alike 4.0 International License. A copy of that license is
available at \url{https://creativecommons.org/licenses/by-sa/4.0/legalcode}.
\end{center}
\vfill
This work is primarily composed of the many contributions it
receives as a public, collaborative project. Please
\href{https://gitorious.org/copyleft-org/tutorial/history/master:enforcement-case-studies.tex}{review
its Git logs} for full documentation of all contributions.
}
% =====================================================================
% START OF SECOND DAY SEMINAR SECTION
% =====================================================================
\chapter*{Preface}
This one-day course presents the details of five different GPL
compliance cases handled by FSF's GPL Compliance Laboratory. Each case
offers unique insights into problems that can arise when the terms of
the GPL are not properly followed, and how diplomatic negotiation between
the violator and the copyright holder can yield positive results for
both parties.
Attendees should have successfully completely the course, a ``Detailed
Study and Analysis of the GPL and LGPL,'' as the material from that
course forms the building blocks for this material.
This course is of most interest to lawyers who have clients or
employers that deal with Free Software on a regular basis. However,
technical managers and executives whose businesses use or distribute
Free Software will also find the course very helpful.
\bigskip
These course materials are merely a summary of the highlights of the
course presented. Please be aware that during the actual GPL course, class
discussion supplements this printed curriculum. Simply reading it is
not equivalent to attending the course.
%FIXME-LATER: write these
%\chapter{Not All GPL Enforcement is Created Equal}
%\section{For-Profit Enforcement}
%\section{Community and Non-Profit Enforcement}
\chapter{Overview of Community Enforcement}
The GPL is a Free Software license with legal teeth. Unlike licenses like
the X11-style or various BSD licenses, the GPL (and by extension, the LGPL) is
designed to defend as well as grant freedom. We saw in the last course
that the GPL uses copyright law as a mechanism to grant all the key freedoms
essential in Free Software, but also to ensure that those freedoms
propagate throughout the distribution chain of the software.
\section{Termination Begins Enforcement}
As we have learned, the assurance that Free Software under the GPL remains
Free Software is accomplished through various terms of the GPL: \S 3 ensures
that binaries are always accompanied with source; \S 2 ensures that the
sources are adequate, complete and usable; \S 6 and \S 7 ensure that the
license of the software is always the GPL for everyone, and that no other
legal agreements or licenses trump the GPL. It is \S 4, however, that ensures
that the GPL can be enforced.
Thus, \S 4 is where we begin our discussion of GPL enforcement. This
clause is where the legal teeth of the license are rooted. As a copyright
license, the GPL governs only the activities governed by copyright law ---
copying, modifying and redistributing computer software. Unlike most
copyright licenses, the GPL gives wide grants of permission for engaging with
these activities. Such permissions continue, and all parties may exercise
them until such time as one party violates the terms of the GPL\@. At the
moment of such a violation (i.e., the engaging of copying, modifying or
redistributing in ways not permitted by the GPL) \S 4 is invoked. While other
parties may continue to operate under the GPL, the violating party loses their
rights.
Specifically, \S 4 terminates the violators' rights to continue
engaging in the permissions that are otherwise granted by the GPL\@.
Effectively, their rights revert to the copyright defaults ---
no permission is granted to copy, modify, nor redistribute the work.
Meanwhile, \S 5 points out that if the violator has no rights under
the GPL, they are prohibited by copyright law from engaging in the
activities of copying, modifying and distributing. They have lost
these rights because they have violated the GPL, and no other license
gives them permission to engage in these activities governed by copyright law.
\section{Ongoing Violations}
In conjunction with \S 4's termination of violators' rights, there is
one final industry fact added to the mix: rarely does one engage in a
single, solitary act of copying, distributing or modifying software.
Almost always, a violator will have legitimately acquired a copy of a
GPL'd program, either making modifications or not, and then begun
distributing that work. For example, the violator may have put the
software in boxes and sold them at stores. Or perhaps the software
was put up for download on the Internet. Regardless of the delivery
mechanism, violators almost always are engaged in {\em ongoing\/}
violation of the GPL\@.
In fact, when we discover a GPL violation that occurred only once --- for
example, a user group who distributed copies of a GNU/Linux system without
source at one meeting --- we rarely pursue it with a high degree of
tenacity. In our minds, such a violation is an educational problem, and
unless the user group becomes a repeat offender (as it turns out, they
never do), we simply forward along a FAQ entry that best explains how user
groups can most easily comply with the GPL, and send them on their merry way.
It is only the cases of {\em ongoing\/} GPL violation that warrant our
active attention. We vehemently pursue those cases where dozens, hundreds
or thousands of customers are receiving software that is out of
compliance, and where the company continually offers for sale (or
distributes gratis as a demo) software distributions that include GPL'd
components out of compliance. Our goal is to maximize the impact of
enforcement and educate industries who are making such a mistake on a
large scale.
In addition, such ongoing violation shows that a particular company is
committed to a GPL'd product line. We are thrilled to learn that someone
is benefiting from Free Software, and we understand that sometimes they
become confused about the rules of the road. Rather than merely
giving us a postmortem to perform on a past mistake, an ongoing violation
gives us an active opportunity to educate a new contributor to the GPL'd
commons about proper procedures to contribute to the community.
Our central goal is not, in fact, to merely clear up a particular violation.
In fact, over time, we hope that our compliance lab will be out of
business. We seek to educate the businesses that engage in commerce
related to GPL'd software to obey the rules of the road and allow them to
operate freely under them. Just as a traffic officer would not revel in
reminding people which side of the road to drive on, so we do not revel in
violations. By contrast, we revel in the successes of educating an
ongoing violator about the GPL so that GPL compliance becomes a second-nature
matter, allowing that company to join the GPL ecosystem as a contributor.
\section{How are Violations Discovered?}
Our enforcement of the GPL is not a fund-raising effort; in fact, FSF's GPL
Compliance Lab runs at a loss (in other words, it is subsided by our
donors). Our violation reports come from volunteers, who have encountered,
in their business or personal life, a device or software product that
appears to contain GPL'd software. These reports are almost always sent
via email to $<$license-violation@fsf.org$>$.
Our first order of business, upon receiving such a report, is to seek
independent confirmation. When possible, we get a copy of the software
product. For example, if it is an offering that is downloadable from a
Web site, we download it and investigate ourselves. When it is not
possible for us to actually get a copy of the software, we ask the
reporter to go through the same process we would use in examining the
software.
By rough estimation, about 95\% of violations at this stage can be
confirmed by simple commands. Almost all violators have merely made an
error and have no nefarious intentions. They have made no attempt to
remove our copyright notices from the software. Thus, given the
third-party binary, {\tt tpb}, usually, a simple command (on a GNU/Linux
system) such as the following will find a Free Software copyright notice
and GPL reference:
\begin{quotation}
{\tt strings tpb | grep Copyright}
\end{quotation}
In other words, it is usually more than trivial to confirm that GPL'd
software is included.
Once we have confirmed that a violation has indeed occurred, we must then
determine whose copyright has been violated. Contrary to popular belief,
FSF does not have the power to enforce the GPL in all cases. Since the GPL
operates under copyright law, the powers of enforcement --- to seek
redress once \S 4 has been invoked --- lie with the copyright holder of
the software. FSF is one of the largest copyright holders in the world of
GPL'd software, but we are by no means the only one. Thus, we sometimes
discover that while GPL'd code is present in the software, there is no
software copyrighted by FSF present.
In cases where FSF does not hold copyright interest in the software, but
we have confirmed a violation, we contact the copyright holders of the
software, and encourage them to enforce the GPL\@. We offer our good offices
to help negotiate compliance on their behalf, and many times, we help as a
third party to settle such GPL violations. However, what we will describe
primarily in this course is FSF's first-hand experience enforcing its own
copyrights and the GPL\@.
\section{First Contact}
The Free Software community is built on a structure of voluntary
cooperation and mutual help. Our community has learned that cooperation
works best when you assume the best of others, and only change policy,
procedures and attitudes when some specific event or occurrence indicates
that a change is necessary. We treat the process of GPL enforcement in
the same way. Our goal is to encourage violators to join the cooperative
community of software sharing, so we want to open our hand in friendship.
Therefore, once we have confirmed a violation, our first assumption is
that the violation is an oversight or otherwise a mistake due to confusion
about the terms of the license. We reach out to the violator and ask them
to work with us in a collaborative way to bring the product into
compliance. We have received the gamut of possible reactions to such
requests, and in this course, we examine four specific examples of such
compliance work.
% FIXME: make this section properly TeX-formatted
\chapter{ThinkPenguin Wireless Router: Excellent CCS}
\label{pristine-example}
Too often, case studies examine failure and mistakes. Indeed, most of the
chapters that follow herein will consider the myriad difficulties discovered
in community-oriented GPL enforcement for the last two decades. However, to
begin, this is a case study in how copyleft compliance can indeed be done correctly.
This example is, in fact, more than ten years in the making. Since almost
the inception of for-profit corporate adoption of Free Software, companies
have requested a clear example of a model citizen to emulate. Sadly, while
community-oriented enforcers have vetted uncounted thousands of ``Complete,
Corresponding Source'' (CCS) candidates from hundreds of companies, this
particular CCS release described herein is the first ever declared a ``pristine
example''.
% FIXME (above): link to a further discussion of CCS in the compliance guide
% when a good spot exists, then (below) link to a ``CCS iteration''
% discussion in compliance-guide.tex when one exists. (the ``iteration
% process'' is discussed in~\ref{} of this guide)
Of course, most CCS examined for the last decade has (eventually) complied
with the GPL, perhaps after many iterations of review by the enforcer.
However, in the experience of the two primary community-oriented enforcers
(Conservancy and the FSF), such CCS results routinely
``barely comply with GPL's requirements''. To use an academic analogy:
while a ``C'' is certainly a passing grade, any instructor prefers to
disseminate to the class an exemplar sample that earned an ``A''.
Fortunately, thanks in large part to the FSF's
``Respects Your Freedom'' (RYF) certification campaign\footnote{\href{http://www.fsf.org/resources/hw/endorsement/respects-your-freedom}{RYF is
a campaign by FSF to certify products that truly meet the principles of
software freedom}. Products must meet
\href{http://www.fsf.org/resources/hw/endorsement/criteria}{strict
standards for RYF certification}, and among them is a pristine example of
CCS\@.}, a few electronics products on the market meet
a higher standard of copyleft compliance. As such, for the first
time in the history of copyleft, CCS experts have pristine examples to study
and present as exemplars worthy of emulation.
This case study therefore examines the entire life-cycle of a GPL compliance
investigation: from product purchase, to source request, to CCS review, and concluding
in a final compliance determination.
Specifically, this chapter discusses the purchase, CCS provision, and a
step-by-step build and installation analysis of a specific, physical,
embedded electronics product:
\href{https://www.thinkpenguin.com/gnu-linux/free-software-wireless-n-broadband-router-gnu-linux-tpe-nwifirouter2}{the
``TPE-NWIFIROUTER'' wireless router by ThinkPenguin}.\footnote{The FSF of
course performed a thorough CCS check as part of its certification process.
The analysis discussed herein was independently performed by Software
Freedom Conservancy without reviewing the FSF's findings. Thus, this
analysis is ``true to form'', and explains the typical procedures Conservancy
uses when investigating a potential GPL violation. In this case, obviously, no
violation was uncovered.}
\section{Consumer Purchase and Unboxing}
The process for copyleft compliance investigation, when properly conducted,
determines whether users inclined to exercise their rights under a copyleft
license will be successful in their attempt. Therefore, at every stage, the
investigator seeks to take actions that reasonably technically knowledgeable
users would during the ordinary course of their acquisition and use of
copyleft-covered products. As such, the investigator typically purchases the device on the
open market to verify that distribution of the copylefted software therein
complies with binary distribution requirements (such as those
\tutorialpartsplit{discussed in \textit{Detailed Analysis of the GNU GPL and
Related Licenses}}{discussed earlier in \S~\ref{GPLv2s3} and
\S~\ref{GPLv3s6}}).
% FIXME: Above is my only use of \tutorialpartsplit in this chapter. I just
% got lazy and that should be fixed by someone.
\label{thinkpenguin-included-ccs}
Therefore, the investigator first purchased the TPE-NWIFIROUTER through an
online order, and when the package arrived, examined the contents of the box.
The investigator immediately discovered that ThinkPenguin had taken advice
from \S~\ref{offer-for-source}, and exercised
\hyperref[GPLv2s3a]{GPLv2\S3(a)} and \hyperref[GPLv3s6]{GPLv3\S6}, rather than
using the \hyperref[offer-for-source]{problematic offer for source
provisions}. This choice not only accelerated the investigation (since there
was no CCS offer to ``test''), but also simplified the compliance requirements for
ThinkPenguin.
\section{Root Filesystem and Kernel Compilation}
The CD found in the box was labeled ``libreCMC v1.2.1 source code'', and
contained 407 megabytes of data. The investigator copied this ISO to a
desktop GNU/Linux system and
examined its contents. Upon doing so, the investigator immediately found a
file called ``README'' at the top-level directory:
\lstset{tabsize=2}
\begin{lstlisting}[language=bash]
$ dd if=/dev/cdrom of=libreCMC_v1.2.1_SRC.iso
$ mkdir libCMC
$ sudo mount -o loop ./libreCMC_v1.2.1_SRC.iso libCMC
mount: block device /path/to/libreCMC_v1.2.1_SRC.iso
is write-protected, mounting read-only
$ ls -1 libCMC
bin
librecmc-u-boot.tar.bz2
librecmc-v1.2.1.tar.bz2
README
u-boot_reflash
$ cat libCMC/README
...
\end{lstlisting}
\label{thinkpenguin-toplevel-readme}
The investigator therefore knew immediately to begin the CCS check should
begin with a study of the contents of ``README''. Indeed, that file contained the appropriate
details to start the build:
\begin{quotation}
In order to build firmware images for your router, the following needs to be
installed:
gcc, binutils, bzip2, flex, python, perl, make, find, grep, diff, unzip,
gawk, getopt, libz-dev and libc headers.
Please use ``make menuconfig'' to configure your appreciated configuration
for the toolchain and firmware. Please note that the default configuration is
what was used to build the firmware image for your router. It is advised that
you use this configuration.
Simply running ``make'' will build your firmware. The build system will
download all sources, build the cross-compile toolchain, the kernel and all
chosen applications.
To build your own firmware you need to have access to a GNU/Linux system
(case-sensitive filesystem required).
\end{quotation}
In other words, the first ``script'' that investigator ``ran'' was the above.
This was not a software script, rather the processor for the script was the investigator's own
brain --- like a script of a play. Less glibly stated: instructions written in
English are usually necessary for the build and installation operations
that demand actual intelligence.
In this case, the investigator ascertained the host system requirements
for construction of this embedded firmware.
GPL does not give specific guidance on the form or location of
``scripts used to control compilation and installation of the executable''
and/or ``Installation Information''. Community-oriented GPL enforcers apply a
``reasonableness standard'' to evaluate such instructions. If an investigator of
average skill in embedded firmware construction can surmise the proper
procedures to build and install a replacement firmware, the instructions are
likely sufficient to meet GPL's requirements. Fortunately, in this case, the
instructions are more abundant and give extra detail.
Nevertheless, these instructions offer more options than the reader
typically sees in other CCS candidates. More typically, top-level build
instructions name an exact host distribution to use, such as
``Debian 7 installed on an amd64 system with the following packages
installed''. Of course, if the build will fail on any other system,
instructions \textit{should} include such details. However, this CCS builds
on a wide range of distributions, and thus it was appropriate (and preferred)
that the build instructions do not specify a specific distribution.
\label{thinkpenguin-specific-host-system}
In this specific case, the developers of the libreCMC project (a Free
Software project that forms the base system for the TPE-NWIFIROUTER) have
clearly made an effort to ensure the CCS builds on a variety of host systems.
The investigator was in fact dubious upon seeing these instructions, since
finicky embedded build processes usually require a very specific host system.
Fortunately, it seems such doubts were generally unfounded (although the
investigator did find
\hyperref[thinkpenguin-glibc-214-issue]{a minor annoyance that could be
resolved with more detailed instructions}).
Anyway, since these instructions did not specify a specific host system, the
investigator simply used his own amd64 Debian GNU/Linux 6 desktop system. Before
beginning, the investigator used the following command:
\lstset{tabsize=2}
\begin{lstlisting}[language=bash]
$ dpkg --list | egrep '^iii' | less
\end{lstlisting}
to verify that the required packages listed in the README were
installed\footnote{The ``dpkg'' command is a Debian-specific way of
finding installed packages.}.
Next, the investigator then extracted the primary source package with the
following command:
\lstset{tabsize=2}
\begin{lstlisting}[language=bash]
$ tar --posix -jxpf libCMC/librecmc-v1.2.1.tar.bz2
\end{lstlisting}
The investigator did notice an additional source release, entitled
``librecmc-u-boot.tar.bz2''. The investigator concluded upon simple
inspection that the instructions found in ``u-boot\verb0_0reflash'' were
specific instructions for that part of the CCS\@. This was a minor
annoyance, and ideally the ``README'' would so-state, but the CCS filesystem
layout met the reasonableness standard; the skilled investigator determine the correct
course of action with a few moments of study.
The investigator then noted the additional step offered by the ``README'',
which read:
\begin{quotation}
Please use ``make menuconfig'' to configure your appreciated configuration
for the toolchain and firmware. Please note that the default configuration is
what was used to build the firmware image for your router. It is advised that
you use this configuration.
\end{quotation}
This instruction actually exceeds GPL's requirements.
Specifically, the instruction guides users in their first step toward
exercising the freedom to modify the software. While the GPL does contain
requirements that facilitate the freedom to modify (such as ensuring the CCS is
in the ``preferred form \ldots for making modifications to it''), GPL
does not require specific instructions explaining how to undertake
modifications. This specific instruction therefore exemplifies
the exceptional quality of this particular CCS\@.
%FIXME: add a \hyperref to some ``preferred for for modification'' stuff above.
However, for purposes of the CCS verification process, typically the
investigator avoids any unnecessary changes to the source code during the
build process, lest the investigator err and cause the build to fail through
his own modification, and thus incorrectly identify the CCS as inadequate.
Therefore, the investigator proceeded to simply run:
\lstset{tabsize=2}
\begin{lstlisting}[language=bash]
$ cd libCMC
$ make
\end{lstlisting}
and waited approximately 40 minutes for the build to complete\footnote{Build
times will likely vary widely on various host systems.}. The investigator
kept a
\href{https://gitorious.org/copyleft-org/tutorial/source/master:enforcement-case-studies_log-output/thinkpenguin_librecmc-complete.log}{full
log of the build}, which is not included herein due its size (approximately
7.2K of text).
\label{thinkpenguin-main-build}
Upon completion of the ``make'' process, the investigator immediately found
(almost to his surprise) several large firmware files in the ``bin/ar71xx''
directory. Typically, this step in the CCS verification process is
harrowing. In most cases, the ``make'' step will fail due to a missing
package or because toolchain paths are not setup correctly.
In light of such experiences, the investigator speculated that ThinkPenguin's engineers did
the most important step in self-CCS verification: test one's own instructions
on a clean system. Ideally, an employee with similar skills but
unfamiliar with the specific product can most easily verify CCS and identify
problems before a violation occurs.
% FIXME: Is there stuff about the above in the compliance guide? If so, link
% to it. If not, write it, then link to it. :)
However, upon completing the ``make'', the investigator was unclear which
filesystem and kernel images to install on the TPE-NWIFIROUTER hardware.
Ideally, the original ``README'' would indicate which image is appropriate
for the included hardware. However, this was ultimately an annoyance rather
than a compliance issue. Fortunately,
the web UI (see next section) on the TPE-NWIFIROUTER performs firmware image
installation. Additionally, the router's version number was specified on the
bottom of the device, which indicated which of the differently-versioned images
we should install. The investigator would prefer instructions such as
those found at
\url{http://librecmc.org/librecmc/wiki?name=Tp+MR3020}{instructions similar
to these} in the README itself; however, application of the reasonableness
standard here again indicates compliance, since a knowledgeable user can easily
determine the proper course of action.
\section{U-Boot Compilation}
%FIXME: link to u-boot reflash, maybe put it in log-output dir?
The investigator then turned his attention to the file,
``u-boot\verb0_0reflash''. These instructions explained how to
build and install the bootloader for the device.
The investigator followed the instructions for compiling U-Boot, and found
them quite straight-forward. The investigator discovered two minor
annoyances, however, while building U-Boot:
\begin{itemize}
\item The variable \verb0$U-BOOT_SRC0 was used as a placeholder for the name
of the extracted source directory. This was easy to surmise and was not a
compliance issue (per the reasonableness standard), but explicitly stating
that fact at the top of the instructions would be helpful.
\label{thinkpenguin-glibc-214-issue}
\item Toolchain binaries were included and used by default by the build
process. These binaries were not the appropriate ones for the
investigator's host system, and the build failed with the following error:
\lstset{tabsize=2}
\begin{lstlisting}
mips-librecmc-linux-uclibc-gcc.bin: /lib/libc.so.6:
version `GLIBC`_2.14' not found
(required by mips-librecmc-linux-uclibc-gcc.bin)
\end{lstlisting}
(The
\href{https://gitorious.org/copyleft-org/tutorial/source/master:enforcement-case-studies_log-output/thinkpenguin_u-boot-build_fail.log}{complete
log output from the failure} is too lengthy to include herein.)
This issue is an annoyance, not a compliance problem. It was clear from
context that these binaries were simply for a different host architecture, and
the investigator simply removed ``toolchain/bin'' and created a symlink to
utilize the toolchain already built earlier (during the compilation
discussed in \S~\ref{thinkpenguin-main-build}):
\lstset{tabsize=2}
\begin{lstlisting}
$ ln -s \
../../staging_dir/toolchain-mips_34kc_gcc-4.6-linaro_uClibc-0.9.33.2/bin \
toolchain/bin
\end{lstlisting}
After this change, the U-Boot build completed successfully.
\end{itemize}
The
\href{https://gitorious.org/copyleft-org/tutorial/source/master:enforcement-case-studies_log-output/thinkpenguin_u-boot-finish_build.log}{full
log of the build} is not included herein due its size (approximately 3.8K
of text). After that, the investigator found a new U-Boot image in the
``bin'' directory.
\section{Root Filesystem and Kernel Installation}
The investigator next tested installation of the firmware. In particular,
the investigator connected the TPE-NWIFIROUTER to a local network, and
visited \url{http://192.168.10.1/}, logged in, and chose the option sequence:
``System $\Rightarrow$ Backup / Flash Firmware''.
From there, the investigator chose the ``Flash new firmware image'' section
and selected the
``librecmc-ar71xx-generic-tl-wr841n-v8-squashfs-sysupgrade.bin'' image from
the ``bin/ar71xx'' directory. The investigator chose the ``v8'' image upon
verifying the physical router read ``v8.2'' on its bottom. The investigator
chose the ``sysupgrade'' version of the image because this was clearly a
system upgrade (as a firmware already came preinstalled on the
TPE-NWIFIROUTER).
Upon clicking ``Flash image\ldots'', the web interface prompted the
investigator to confirm the MD5 hash of the image to flash. The investigator
did so, and then clicked ``Proceed'' to flash the image. The process took
about one minute, at which point the web page refreshed to the login screen.
Upon logging in, the investigator was able to confirm in the ``Kernel Log''
section of the web interface that the newly built copy of Linux had indeed been
installed.
The investigator confirmed that a new version of ``busybox'' had also been
installed by using SSH to connect to the router and ran the command
``busybox'', which showed the newly-compiled version (via its date of
compilation).
%FIXME: dg: can you get me a screen shot for the Kernel Log above, and paste
%in the output of running busybox ?
%FIXME: bkuhn: the screen shot for the Kernel Log is in the log output dir at
%thinkpenguin_librecmc-built-kernel_log.png and the BusyBox output is in the
%same directory at thinkpenguin_librecmc-built-busybox_output.log - you may want
%to only use part of the BusyBox output (maybe even just the login) for brevity
\section{U-Boot Installation}
The U-Boot installation process is substantially more complicated than the
firmware update. The investigator purchased the optional serial cable
along with the TPE-NWIFIROUTER, in order to complete the U-Boot installation
per the instructions in ``u-boot\verb0_0reflash'' in its section ``Installing
u-boot to your router'', which reads:
\begin{quotation}
\begin{enumerate}
\item Install and configure any TFTP server on your PC (tftp-hpa).
Set a fixed IP address on your PC \ldots and connect it to the router,
using RJ45 network cable \ldots
\item Connect USB to UART adapter to the router and start any application to
communicate with it, like PuTTY. \ldots
\item Power on the router, wait for a line like one of the following and
interrupt the process of loading a kernel:
\begin{verbatim}
Autobooting in 1 seconds
(for most TP-Link routers, you should enter tpl at this point)
Hit ESC key to stop autoboot: 1 (for 8devices Carambola 2, use ESC key)
Hit any key to stop autoboot: 1 (for D-Link DIR-505, use any key)
\end{verbatim}
\item Set ipaddr and serverip environment variables:
\lstset{tabsize=2}
\begin{lstlisting}
hornet> setenv ipaddr 192.168.1.1
hornet> setenv serverip 192.168.1.2
\end{lstlisting}
\end{enumerate}
\end{quotation}
%FIXME: image of the serial cable available anywhere to put here:
% https://www.adafruit.com/images/970x728/954-02.jpg
The investigator used the purchased serial cable, which was a USB serial
adapter with a male USB type A connector to 4 female jumper wires. The
female jumper wires were red, black, white, and green.
The instructions here were slightly incomplete, since they did not specify
how to connect the wires to the router. However, the investigator found
general information available online at
\url{http://wiki.openwrt.org/toh/tp-link/tl-wr841nd#serial.console} which
described the proper procedure. While the ``power'' and ``ground'' cables
were obvious, some trial and error was necessary to find the RX and TX
cables, but this was easily determined since miswiring TX and RX yields no
I/O and proper wiring yields the output as expected. Using the pin gender
changer included with the adapter, the investigator was able to stably wire
the pins for use once the proper RX and TX connections were determined.
The investigator then used the recommended 115200 8N1 for serial console
settings, leaving all flow control off, and tested both with the
\verb0minicom0 and \verb0screen0 commands. The investigator found that if
all 4 wires were connected on the USB serial adapter that the router would
start without additional power and the console would receive the startup
messages. The investigator could replicate the same behavior by omitting the
power cable from the USB serial adapter (red wire) and connecting the main
power adapter to the router instead.
At this point, the on-screen messages as described in the installation
instructions appeared, but the investigator found that no key events sent via
the serial port appeared to reach the U-Boot console. In other words, while
the investigator saw both U-Boot and kernel boot messages in the serial
console, the investigator was unable to interrupt the boot process as
instructed by ``u-boot\verb0_0reflash''. Hitting a key simply did
\textit{not} interrupt the boot process and yield the \verb0hornet>0 prompt.
After additional trial and error over a period of hours, the investigator had
finally to consider this question for the first time during the process:
``Has ThinkPenguin violated the GPL?'' More specifically, the immediate
question was: ``Given this failure, has the distributor met
\hyperref[GPLv2s3-build-scripts]{the requirements for `scripts used to
control \ldots installation of the executable' (GPLv2)} and
\hyperref[GPLv3-installation-information]{necessary `Installation
Information' (GPLv3)}?''
The appropriate answer to the question (at this specific stage) is ``possibly,
but more information is needed''. Embedded installation and configuration is
a tricky and complex technical process. While the GPL requires documentation
and clear instructions for this process, the investigator did not immediately blame the distributor
for what may be an honest, correctable mistake, or an issue legitimately explained by
feasible alternative theories.
In this case, upon remembering the issues of wiring, the investigator wonder
if perhaps the power pin was accidentally connected for a moment to the RX
pin while live. Such action could easily fry the RX pin, and yield the
observed behavior. Since the investigator could not rule out the possibility
of accidental connection of power to the RX pin mentioned, the investigator
had to assume the instructions would work properly if he had not made that
error.
That conclusion, while correct, also left the investigator with only two
option to complete the final verification of the CCS:
\begin{itemize}
\item Purchase a new router and cable anew, and reattempt the installation
process while taking extra care not to miswire any cables.
\item Seek assistance from the libreCMC community to find an alternative
method of installation.
\end{itemize}
The investigator chose the latter and then contacted a libreCMC developer
familiar with the product. That developer, who agreed the the RX pin was
likely ruined, described an alternative method for console access using the
{\tt netcat}. The libreCMC developer described the process as follows:
\begin{quotation}
\begin{itemize}
\item Change the IP address of the router to 192.168.1.1.
\item Change the IP address of a desktop GNU/Linux system to 192.168.1.2.
\item Power on the router while holding the reset button for 7 seconds.
\item Use the {\tt netcat} command (as below) on the desktop, and press
enter to receive U-Boot's prompt:
\lstset{tabsize=2}
\begin{lstlisting}[language=bash]
$ nc -u -p 6666 192.168.1.1 6666
uboot>
\end{lstlisting}
\end{itemize}
\end{quotation}
Upon following this procedure, the investigator was able to confirm the
(original) shipped version of U-Boot was still installed:
\begin{lstlisting}[language=bash]
$ nc -u -p 6666 192.168.1.1 6666
uboot> version
U-Boot 1.1.4 (Jul 28 2014)
\end{lstlisting}
Thereafter, the investigator followed the instructions from
``u-boot\verb0_0reflash''. Specifically, the investigator configured a TFTP server
and placed the newly built firmware into \texttt{/srv/tftp}. The investigator
also followed the remaining instructions in ``u-boot\verb0_0reflash'', but
used the \texttt{netcat} console rather than the serial console, and
used U-Boot's \texttt{reset} command to reboot the router.
Upon reboot, the serial console (still connect with working output) showed
the message \texttt{U-Boot 1.1.4 (Oct 17 2014)}, and thus confirmed a
successful reflash of the U-Boot image built by the investigator.
\section{Firmware Comparison}
Next, to ensure the CCS did indeed correspond to the firmware original
installed on the TPE-NWIFIROUTER, the investigator compared the built
firmware image with the filesystem originally found on the device itself.
The comparison steps were as follows:
\begin{enumerate}
\item Extract the filesystem from the image we built by running
\href{https://gitorious.org/copyleft-org/gpl-compliance-scripts/source/master:find-firmware.pl}{find-firmware.pl}
on ``bin/ar71xx/librecmc-ar71xx-generic-tl-wr841n-v8-squashfs-factory.bin''
and then running
\href{http://www.binaryanalysis.org/en/content/show/download}{bat-extratools}'
``squashfs4.2/squashfs-tools/bat-unsquashfs42'' on the resulting
morx0.squash, using the filesystem in the new squashfs-root directory for
comparison.
\item Login to the router's web interface (at \url{http://192.168.10.1/ }) from a computer
connected to the router.
\item Set a password using the provided link at the top (since the router's
UI warns that no password is set and asks the user to change it).
\item Logged into the router via SSH, using the root user with the
aforementioned password.
\item Compared representative directory listings and binaries to ensure the set of
included files (on the router) is similar to those found in the firmware
image that the investigator created (whose contents are now in the local squashfs-root directory). In
particular, the investigator did the following comparisons:
\begin{enumerate}
\item Listed the /bin folder (``ls -l /bin'') and confirm the list of files is the same
and that the file sizes are similar.
\item Checked the ``strings'' output of ``/bin/busybox'' to confirm it is similar in both
places (similar number of lines and content of lines). (One cannot directly
compare the binaries because the slight compilation variations will cause
some bits to be different.)
\item Repeated the above two steps for ``/lib/modules'', ``/usr/bin'', and other directories with
a significant number of binaries.
\item Checked that the kernel was sufficiently similar. The investigator
compared the ``dmesg'' output both before and after flashing the new
firmware. As the investigator expected, the kernel version string was
similar, but had a different build date and user@host indicator. (The
kernel binary itself is not easily accessible from an SSH login, but was
retrievable using the U-Boot console (the start address of the kernel in
flash appears to be 0x9F020000, based on the boot messages seen in the
serial console).
\end{enumerate}
\end{enumerate}
\section{Minor Annoyances}
As discussed in detail above, there were a few minor annoyances, none of
which were GPL violations. Rather, the annoyances briefly impeded the
build and installation. However, the investigator, as a reasonably skilled
build engineer for embedded devices, was able to complete the process with
the instructions provided.
To summarize, no GPL compliance issues were found, and the CCS release was
one of the best ever reviewed by any investigator at any community-oriented
enforcement organization. However, the following annoyances were discovered:
\begin{itemize}
\item Failure to explain how to extract the source tarball and then where to run the
``make'' command.
\item Failure to explain how to install the kernel and root filesystem on the
device; the user must assume the web UI must be used.
\item Including pre-built toolchain binaries that don't work on all systems,
and failure to copy and/or symlink built toolchain binaries in the right location.
\item Failure to include information in the U-Boot installation instructions for
wiring the serial cable.
\item Ideally, the U-Boot installation instructions would also include the
{\tt netcat} method of installation.
\item Finally, the instructions should note that the new U-Boot firmware
should be placed into \texttt{/srv/tftp} when using TFTP on most GNU/Linux
desktops.
\end{itemize}
Thus, no CCS is absolutely perfect, but GPL violation investigators always
give the distributors the benefit of any doubts and seek to work with the
vendors and improve their CCS for the betterment of their users, customers,
and the entire software freedom community.
\section{Lessons Learned}
Companies that seek to redistribute copylefted software can benefit greatly
from ThinkPenguin's example. Here are just a few of the many lessons that
can be learned here:
\begin{enumerate}
\item Even though copyleft licenses have them,
\hyperref[thinkpenguin-included-ccs]{\bf avoid the offer-for-source
provisions}. Not only does including the CCS alongside binary
distribution make violation investigation and compliance confirmation
substantially easier, but also (and more importantly) doing so
\hyperref[offer-for-source]{completes the distributor's CCS compliance
obligations at the time of distribution} (provided, of course, that the
distributor is otherwise in compliance with the relevant copyleft license).
\item {\bf Include top-level build instructions in a natural language (such
as English) in a \hyperref[thinkpenguin-toplevel-readme]{clear and
conspicuous place}.} Copyleft licenses require that someone reasonably
skilled in the art can reproduce the build and installation. Typically,
instructions written in English are necessary, and often easier than writing
programmed scripts. The ``script'' included can
certainly be more like the script of a play and less like a Bash script.
\item {\bf Write build/install instructions to the appropriate level of
specificity}. The upstream engineers
in this case study \hyperref[thinkpenguin-specific-host-system]{clearly did
additional work to ensure functionality on a wide variety of host build
systems}; this is quite rare. When in doubt, include the maximum level
of detail build engineers can provide with the CCS instructions, but also
double-check to investigate if a more generalized solution (such as other
host systems) work just as well for the build.
\item {\bf Seek to adhere to the spirit of copyleft, not just the letter of
the license}. Encouragement of users to improve and
make their devices better is one of ThinkPenguin's commercial differentiators. Copyleft advocates
that other companies have undervalued the large and lucrative
market of
users who seek hackable devices. By going beyond the
mere minimal requirements of GPL, companies can immediately reap the
benefits in that target market.
\item Community-oriented enforcement organizations do not play ``gotcha''\footnote{For lack of a better
phrase.} with distributors regarding GPL
violations. The goal in the GPL enforcement process is to achieve
compliance and correct mistakes and annoyances. Such organizations
therefore take an ``innocent until proven guilty $\rightarrow$ assume guilty
due to honest error rather than malicious action '' approach. The goal
is compliance (in direct contrast with
the \hyperref[Proprietary Relicensing]{discussion in \S~\ref*{Proprietary Relicensing} about the
proprietary relicensing} business model).
\end{enumerate}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Bortez: Modified GCC SDK}
In our first case study, we will consider Bortez, a company that
produces software and hardware toolkits to assist OEM vendors, makers
of consumer electronic devices.
\section{Facts}
One of Bortez's key products is a Software Development Kit (``SDK'')
designed to assist developers building software for a specific class of
consumer electronics devices.
FSF received a report that the SDK may be based on the GNU Compiler
Collection (which is an FSF-copyrighted collection of tools for software
development in C, C++ and other popular languages). FSF investigated the
claim, but was unable to confirm the violation. The violation reporter
was unresponsive to follow-up requests for more information.
Since FSF was unable to confirm the violation, we did not pursue it any
further. Bogus reports do happen, and we do not want to burden companies
with specious GPL violation complaints. FSF shelved the matter until
more evidence was discovered.
FSF was later able to confirm the violation when two additional reports
surfaced from other violation reporters, both of whom had used the SDK
professionally and noticed clear similarities to FSF's GNU GCC\@. FSF's
Compliance Engineer asked the reporters to run standard tests to confirm
the violation, and it was confirmed that Bortez's SDK was indeed a
modified version of GCC\@. Bortez had ported to Windows and added a number
of features, including support for a specific consumer device chipset and
additional features to aid in the linking process (``LP'') for those
specific devices. FSF explained the rights that the GPL afforded these
customers and pointed out, for example, that Bortez only needed to provide
source to those in possession of the binaries, and that the users may need
to request that source (if \S 3(b) was exercised). The violators
confirmed that such requests were not answered.
FSF brought the matter to the attention of Bortez, who immediately
escalated the matter to their attorneys. After a long negotiation,
Bortez acknowledged that their SDK was indeed a modified version of
GCC\@. Bortez released most of the source, but some disagreement
occurred over whether LP was also derivative of GCC\@. After repeated
FSF inquiries, Bortez reaudited the source to discover that FSF's
analysis was correct. Bortez determined that LP included a number of
source files copied from the GCC code-base.
\label{davrik-build-problems}
Once the full software release was made available, FSF asked the violation
reporters if it addressed the problem. Reports came back that the source
did not properly build. FSF asked Bortez to provide better build
instructions with the software, and such build instructions were
incorporated into the next software release.
At FSF's request as well, Bortez informed customers who had previously
purchased the product that the source was now available by announcing
the availability on its Web site and via a customer newsletter.
Bortez did have some concerns regarding patents. They wished to include a
statement with the software release that made sure they were not granting
any patent permission other than what was absolutely required by the GPL\@.
They understood that their patent assertions could not trump any rights
granted by the GPL\@. The following language was negotiated into the release:
\begin{quotation}
Subject to the qualifications stated below, Bortez, on behalf of itself
and its Subsidiaries, agrees not to assert the Claims against you for your
making, use, offer for sale, sale, or importation of the Bortez's GNU
Utilities or derivative works of the Bortez's GNU Utilities
(``Derivatives''), but only to the extent that any such Derivatives are
licensed by you under the terms of the GNU General Public License. The
Claims are the claims of patents that Bortez or its Subsidiaries have
standing to enforce that are directly infringed by the making, use, or
sale of an Bortez Distributed GNU Utilities in the form it was distributed
by Bortez and that do not include any limitation that reads on hardware;
the Claims do not include any additional patent claims held by Bortez that
cover any modifications of, derivative works based on or combinations with
the Bortez's GNU Utilities, even if such a claim is disclosed in the same
patent as a Claim. Subsidiaries are entities that are wholly owned by
Bortez.
This statement does not negate, limit or restrict any rights you already
have under the GNU General Public License version 2.
\end{quotation}
This quelled Bortez's concerns about other patent licensing they sought to
do outside of the GPL'd software, and satisfied FSF's concerns that Bortez
give proper permissions to exercise teachings of patents that were
exercised in their GPL'd software release.
Finally, a GPL Compliance Officer inside Bortez was appointed to take
responsibility for all matters of GPL compliance inside the company.
Bortez is responsible for informing FSF if the position is given to
someone else inside the company, and making sure that FSF has direct
contact with Bortez's Compliance Officer.
\section{Lessons}
This case introduces a number of concepts regarding GPL enforcement.
\begin{enumerate}
\item {\bf Enforcement should not begin until the evidence is confirmed.}
Most companies that distribute GPL'd software do so in compliance, and at
times, violation reports are mistaken. Even with extensive efforts in
GPL education, many users do not fully understand their rights and the
obligations that companies have. By working through the investigation
with reporters, the violation can be properly confirmed, and {\bf the
user of the software can be educated about what to expect with GPL'd
software}. When users and customers of GPL'd products know their
rights, what to expect, and how to properly exercise their rights
(particularly under \S 3(b)), it reduces the chances for user
frustration and inappropriate community outcry about an alleged GPL
violation.
\item {\bf GPL compliance requires friendly negotiation and cooperation.}
Often, attorneys and managers are legitimately surprised to find out
GPL'd software is included in their company's products. Engineers
sometimes include GPL'd software without understanding the requirements.
This does not excuse companies from their obligations under the license,
but it does mean that care and patience are essential for reaching GPL
compliance. We want companies to understand that participating and
benefiting from a collaborative Free Software community is not a burden,
so we strive to make the process of coming into compliance as smooth as
possible.
\item {\bf Confirming compliance is a community effort.} The whole point
of making sure that software distributors respect the terms of the GPL is to
allow a thriving software sharing community to benefit and improve the
work. FSF is not the expert on how a compiler for consumer electronic
devices should work. We therefore inform the community who originally
brought the violation to our attention and ask them to assist in
evaluation and confirmation of the product's compliance. Of course, FSF
coordinates and oversees the process, but we do not want compliance for
compliance's sake; rather, we wish to foster a cooperating community of
development around the Free Software in question, and encourage the
once-violator to begin participating in that community.
\item {\bf Informing the harmed community is part of compliance.} FSF asks
violators to make some attempt --- such as via newsletters and the
company's Web site --- to inform those who already have the products as
to their rights under the GPL\@. One of the key thrusts of the GPL's \S 1 and
\S 3 is to {\em make sure the user knows she has these rights\/}. If a
product was received out of compliance by a customer, she may never
actually discover that she has such rights. Informing customers, in a
way that is not burdensome but has a high probability of successfully
reaching those who would seek to exercise their freedoms, is essential
to properly remedy the mistake.
\item {\bf Lines between various copyright, patent, and other legal
mechanisms must be precisely defined and considered.} The most
difficult negotiation point of the Bortez case was drafting language
that simultaneously protected Bortez's patent rights outside of the
GPL'd source, but was consistent with the implicit patent grant in
the GPL\@. As we discussed in the first course of this series, there is
indeed an implicit patent grant with the GPL, thanks to \S 6 and \S 7.
However, many companies become nervous and wish to make the grant
explicit to assure themselves that the grant is sufficiently narrow for
their needs. We understand that there is no reasonable way to determine
what patent claims read on a company's GPL holdings and which do not, so
we do not object to general language that explicitly narrows the patent
grant to only those patents that were, in fact, exercised by the GPL'd
software as released by the company.
\end{enumerate}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Bracken: a Minor Violation in a GNU/Linux Distribution}
In this case study, we consider a minor violation made by a company whose
knowledge of the Free Software community and its functions is deep.
\section{The Facts}
Bracken produces a GNU/Linux operating system product that is sold
primarily to OEM vendors to be placed in appliance devices used for a
single purpose, such as an Internet-browsing-only device. The product
is almost 100\% Free Software, mostly licensed under the GPL and related
Free Software licenses.
FSF found out about this violation through a report first posted on a
Slashdot\footnote{Slashdot is a popular news and discussion site for
technical readers.} comment, and then it was brought to our attention again
by another Free Software copyright holder who had discovered the
same violation.
Bracken's GNU/Linux product is delivered directly from their Web site.
This allowed FSF engineers to directly download and confirm the
violation quickly. Two primary problems were discovered with the
online distribution:
\begin{itemize}
\item No source code nor offer for source code was provided for a number
of components for the distributed GNU/Linux system; only binaries were
available
\item An End User License Agreement (``EULA'') was included that
contradicted the permissions granted by the GPL\@
\end{itemize}
FSF contacted Bracken and gave them the details of the violation. Bracken
immediately ceased distribution of the product temporarily and set forth
a plan to bring themselves back into compliance. This plan included the
following steps:
\begin{itemize}
\item Bracken attorneys would rewrite the EULA to comply with the GPL and
would vet the new EULA through FSF before use
\item Bracken engineers would provide source side-by-side with the
binaries for the GNU/Linux distribution on the site (and on CD's, if
ever they distributed that way)
\item Bracken attorneys would run an internal seminar for its engineers
regarding proper GPL compliance to help ensure that such oversights
regarding source releases would not occur in the future
\item Bracken would resume distribution of the product only after FSF
formally restored Bracken's distribution rights
\end{itemize}
This case was completed in about a month. FSF approved the new EULA
text. The key portion in the EULA relating to the GPL read as follows:
\begin{quotation}
Many of the Software Programs included in Bracken Software are distributed
under the terms of agreements with Third Parties (``Third Party
Agreements'') which may expand or limit the Licensee's rights to use
certain Software Programs as set forth in [this EULA]. Certain Software
Programs may be licensed (or sublicensed) to Licensee under the GNU
General Public License and other similar license agreements listed in part
in this section which, among other rights, permit the Licensee to copy,
modify and redistribute certain Software Programs, or portions thereof,
and have access to the source code of certain Software Programs, or
portions thereof. In addition, certain Software Programs, or portions
thereof, may be licensed (or sublicensed) to Licensee under terms stricter
than those set forth in [this EULA]. The Licensee must review the
electronic documentation that accompanies certain Software Programs, or
portions thereof, for the applicable Third Party Agreements. To the
extent any Third Party Agreements require that Bracken provide rights to
use, copy or modify a Software Program that are broader than the rights
granted to the Licensee in [this EULA], then such rights shall take
precedence over the rights and restrictions granted in this Agreement
solely for such Software Programs.
\end{quotation}
FSF restored Bracken's distribution rights shortly after the work was
completed as described.
\section{Lessons Learned}
This case was probably the most quickly and easily resolved of all GPL
violations in the history of FSF's Compliance Lab. The ease with which
the problem was resolved shows a number of cultural factors that play a
role in GPL compliance.
\begin{enumerate}
\item {\bf Companies that understand Free Software culture better have an
easier time with compliance.} Bracken's products were designed and
built around the GNU/Linux system and Free Software components. Their
engineers were deeply familiar with the Free Software ecosystem, and
their lawyers had seen and reviewed the GPL before. The violation was
completely an honest mistake. Since the culture inside the company had
already adapted to the cooperative style of resolution in the Free
Software world, there was very little work for either party to bring the
product into compliance.
\item {\bf When people in key positions understand the Free Software
nature of their software products, compliance concerns are as
mundane as minor software bugs.} Even the most functional system or
structure has its problems, and successful business often depends on
agile response to the problems that do come up; avoiding problems
altogether is a pipe dream. Minor GPL violations can and do happen
even with well-informed redistributors. However, resolution is
reached quickly when the company --- and in particular, the lawyers,
managers, and engineers working on the Free Software product lines
--- have adapted to Free Software culture that the lower-level
engineer already understood
\item {\bf Legally, distribution must stop when a violation is
identified.} In our opinion, Bracken went above and beyond the call of
duty by ceasing distribution while the violation was being resolved.
Under GPL \S 4, the redistributor loses the right to distribute the
software, and thus they are in ongoing violation of copyright law if
they distribute before rights are restored. It is FSF's policy to
temporarily allow distribution while compliance negotiations are ongoing
and only in the most extreme cases (where the other party appears to be
negotiating in bad faith) does FSF even threaten an injunction on
copyright grounds. However, Bracken --- as a good Free Software citizen
--- chose to be on the safe side and do the legally correct thing while
the violation case was pending. From start to finish, it took less
than a month to resolve. This lapse in distribution did not, to FSF's
knowledge, impact Bracken's business in any way.
\item {\bf EULAs are a common area for GPL problems.} Often, EULAs
are drafted from boilerplate text that a company uses for all its
products. Even the most diligent attorneys forget or simply do not
know that a product contains software licensed under the GPL and other
Free Software licenses. Drafting a EULA that accounts for such
licenses is straightforward; the text quoted above works just fine.
The EULA must be designed so that it does not trump rights and
permissions already granted by the GPL\@. The EULA must clearly state
that if there is a conflict between it and the GPL, with regard to GPL'd
code, the GPL is the overriding license.
\item {\bf Compliance Officers are rarely necessary when companies are
educated about GPL compliance.} As we saw in the Bortez case, FSF asks
that a formal ``GPL Compliance Officer'' be appointed inside a
previously violating organization to shepherd the organization to a
cooperative approach to GPL compliance. However, when FSF
sees that an organization already has such an approach, there is no
need to request that such an officer be appointed.
\end{enumerate}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Vigorien: Security, Export Controls, and GPL Compliance}
This case study introduces how concerns of ``security through obscurity''
and regulatory problems can impact GPL compliance matters.
\section{The Facts}
Vigorien distributes a back-up solution product that allows system
administrators to create encrypted backups of file-systems on
Unix-like computers. The product is based on GNU tar, a backup utility
that replaces the standard Unix utility simply called tar, but has
additional features.
Vigorien's backup solution added cryptographic features to GNU tar, and
included a suite of utilities and graphical user interfaces surrounding
GNU tar to make backups convenient.
FSF discovered the violation from a user report, and determined that the
cryptographic features were the only part of the product that constituted
a derivative work of GNU tar; the extraneous utilities merely made
shell calls out to GNU tar. FSF requested that Vigorien come into
compliance with the GPL by releasing the source of GNU tar, with the
cryptographic modifications, to its customers.
Vigorien released the original GNU tar sources, but kept the cryptographic
modifications proprietary. They argued that the security of their system
depending on keeping the software proprietary and that regardless, USA
export restrictions on cryptographic software prohibited such a release.
FSF disputed the first claim, pointing out that Vigorien had only one
option if they did not want to release the source: they would have to
remove GNU tar from the software and not distribute it further. Vigorien
rejected this suggestion, since GNU tar was an integral part of the
product, and the security changes were useless without GNU tar.
Regarding the export control claims, FSF proposed a number of options,
including release of the source from one of Vigorien's divisions overseas
where no such restrictions occurred, but Vigorien argued that the problem
was insoluble because they operated primarily in the USA\@.
The deadlock on the second issue was resolved when those cryptographic
export restrictions were lifted shortly thereafter, and FSF again raised
the matter with Vigorien. At that point, they dropped the first claim and
agreed to release the remaining source module to their customers. They
did so, and the violation was resolved.
\section{Lessons Learned}
\begin{enumerate}
\item {\bf Removing the GPL'd portion of the product is always an
option.} Many violators' first response is to simply refuse to
release the source code as the GPL requires. FSF offers the option to
simply remove the GPL'd portions from the product and continue along
without them. Every case where this has been suggested has led to
the same conclusion. Like Vigorien, the violator argues that the
product cannot function without the GPL'd components, and they
cannot effectively replace them.
Such an outcome is simply further evidence that the combined work in
question is indeed a modified version of the original GPL'd component.
If the other components cannot stand on their own and be useful without
the GPL'd portions, then one cannot effectively argue that the work as a
whole is not a based on the GPL'd portions.
\item {\bf The whole product is not always covered.} In this case,
Vigorien had additional works aggregated. The backup system was a suite
of utilities, some of which were the GPL and some of which were not. While
the cryptographic routines were tightly coupled with GNU tar and clearly
made a whole new combined work of both components, the various GUI utilities were separate and
independent works merely aggregated with the distribution of the
GNU-tar-based product.
\item {\bf ``Security'' concerns do not exonerate a distributor from GPL
obligations, and ``security through obscurity'' does not work anyway.}
The argument that ``this is security software, so it cannot be released
in source form'' is not a valid defense for explaining why the terms of
the GPL are ignored. If companies do not want to release source code
for some reason, then they should not base the work on GPL'd software.
No external argument for noncompliance can hold weight if the work as
a whole is indeed a modified version of a GPL'd program.
The ``security concerns'' argument is often floated as a reason to keep
software proprietary, but the computer security community has on
numerous occasions confirmed that such arguments are entirely specious.
Security experts have found --- since the beginnings of the field of
cryptography in the ancient world --- that sharing results about systems
and having such systems withstand peer review and scrutiny builds the
most secure systems. While full disclosure may help some who wish to
compromise security, it helps those who want to fix problems even more
by identifying them early.
\item {\bf External regulatory problems can be difficult to resolve.}
The GPL, though grounded in copyright law, does not have the power to trump
regulations like export controls. While Vigorien's ``security
concerns'' were specious, their export control concerns were not. It is
indeed a difficult problem that FSF acknowledges. We want compliance
with the GPL and respect for users' freedoms, but we certainly do not expect
companies to commit criminal offenses for the sake of compliance. We
will see more about this issue in our next case study.
\end{enumerate}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Haxil, Polgara, and Thesulac: Mergers, Upstream Providers and Radio Devices}
This case study considers an ongoing (at the time of writing) violation
that has occurred. By the end of the investigation period, three
companies were involved and many complex issues arose.
\section{The Facts}
Haxil produced a consumer electronics device which included a mini
GNU/Linux distribution to control the device. The device was of interest
to many technically-minded consumers, who purchased the device and very
quickly discovered that Free Software was included without source.
Mailing lists throughout the Free Software community erupted with
complaints about the problem, and FSF quickly investigated.
FSF confirmed that FSF-copyrighted GPL'd software was included. In
addition, the whole distribution included GPL'd works from hundreds of
individual copyright holders, many of whom were, at this point, up in
arms about the violation.
Meanwhile, Haxil was in the midst of being acquired by Polgara. Polgara
was as surprised as everyone else to discover the product was based on
GPL'd software; this fact had not been part of the disclosures made during
acquisition. FSF contacted Haxil, Polgara, and the product managers
who had transitioned into the ``Haxil division'' of the newly-merged
Polgara company. Polgara's General Counsel's office worked with FSF on
the matter.
FSF formed a coalition with the other primary copyright holders
to pursue the enforcement effort on their behalf. FSF communicated
directly with Polgara's representatives to begin working through the
issues on behalf of itself and the Free Software community at large.
Polgara pointed out that the software distribution they used was mostly
contributed by an upstream provider, Thesulac, and Haxil's changes to that
code base were minimal. Polgara negotiated with Thesulac to obtain the
source, although the issue moved very slowly in the channels between
Polgara and Thesulac.
FSF encouraged a round-table meeting so that high bandwidth communication
could occur between FSF, Polgara and Thesulac. Polgara and Thesulac
agreed, and that discussion began. Thesulac provided nearly complete
sources to Polgara, and Polgara made a full software release on their
Web site. At the time of writing, that software still has some build
problems (similar to those that occurred with Bortez, as described in
Section~\ref{davrik-build-problems}). FSF continues to negotiate with
Polgara and Thesulac to resolve these problems, which have a clear path to
a solution and are expected to resolve.
Similar to the Vigorien case, Thesulac has regulatory concerns. In this
case, it is not export controls --- an issue that has since been resolved
--- but radio spectrum regulation. Since this consumer electronic device
contains a software-programmable radio transmitter, regulations in (at
least) the USA and Japan prohibit release of those portions of the code
that operate the device. Since this is a low-level programming issue, the
changes to operate the device form a single combined work with the kernel named
Linux. A decade later, this situation remains largely unresolved.
\section{Lessons Learned}
\begin{enumerate}
\item {\bf Community outrage, while justified, can often make negotiation
more difficult.} FSF has a strong policy never to publicize names of
GPL violators if they are negotiating in a friendly way and operating in
good faith toward compliance. Most violations are honest mistakes, and
FSF sees no reason to publicly admonish violators who genuinely want to
come into compliance with the GPL and to work hard staying in compliance.
This case was so public in the Free Software community that both Haxil's
and Polgara's representatives were nearly shell-shocked by the time FSF
began negotiations. There was much work required to diffuse the
situation. We empathize with our community and their outrage about GPL
violations, but we also want to follow a path that leads expediently
to compliance. In our experience, public outcry works best as a last
resort, not the first.
\item {\bf For software companies, GPL compliance belongs on a corporate
acquisition checklist. } Polgara was truly amazed that Haxil had used
GPL'd software in a major new product line but never informed Polgara
during the acquisition process. While GPL compliance is not a
particularly difficult matter, it is an additional obligation that comes
along with the product line. When planning mergers and joint ventures,
one should include lists of GPL'd components contained in the products
discussed.
\item {\bf Compliance problems of upstream providers do not excuse a
violation for the downstream distributor.} To paraphrase \S 6, upstream
providers are not responsible for enforcing compliance of their
downstream, nor are downstream distributors responsible for compliance
problems of upstream providers. However, engaging in distribution of
GPL'd works out of compliance is still just that: a compliance problem.
When FSF carries out enforcement, we are patient and sympathetic when
the problem appears to be upstream. In fact, we urge the violator to
point us to the upstream provider so we may talk to them directly. In
this case, we were happy to begin negotiations with Thesulac. However,
Polgara still has an obligation to bring their product into compliance,
regardless of Thesulac's response.
\item {\bf It behooves upstream providers to advise downstream
distributors about compliance matters.} FSF has encouraged Thesulac to
distribute a ``good practices for GPL compliance'' document with their
product. Polgara added various software components to Thesulac's
product, and it is conceivable that such additions can introduce
compliance. In FSF's opinion, Thesulac is in no way legally responsible
for such a violation introduced by their customer, but it behooves them
from a marketing standpoint to educate their customers about using the
product. We can argue whether or not it is your coffee vendor's fault
if you burn yourself with their product, but (likely) no one on either
side would dispute the prudence of placing a ``caution: hot'' label on
the cup.
\item {\bf FSF enforcement often avoids redundant enforcement cases from
many parties.} Most Free Software systems have hundreds of copyright
holders. Some have thousands. FSF is in a unique position as one of
the largest single copyright holders on GPL'd software and as a
respected umpire in the community, neutrally enforcing the rules of the
GPL road. FSF works hard in the community to convince copyright
holders that consolidating GPL claims through FSF is better for them,
and more likely to yield positive compliance results.
A few copyright holders engage in the ``proprietary relicensing''
business, so they use GPL enforcement as a sales channel for that
business. FSF, as a community-oriented, not-for-profit organization,
seeks only to preserve the freedom of Free Software in its enforcement
efforts. As it turns out, most of the community of copyright holders
of Free Software want the same thing. Share and share alike is a
simple rule to follow, and following that rule to FSF's satisfaction
usually means you are following it to the satisfaction of the entire
Free Software community.
\end{enumerate}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% COMMENT OUT THIS CHAPTER.
% FIXME: is this material moot now that we include the compliance guide?
% Either way, it should be merged into compliance guide.
%\chapter{Good Practices for Compliance}
Generally, from the experience of GPL enforcement, we glean the following
general practices that can help in GPL compliance for organizations that
distribute products based on GPL'd software:
\begin{itemize}
\item Talk to your software engineers and ask them where they got the
components they use in the products they build. Find out if GPL'd
components are present.
\item Teach your engineering staff to pay attention to license documents.
Give them easy-to-follow policies to get approval for using a Free
Software component.
\item Build a ``Free Software Licensing'' committee that handles requests
and questions about the GPL and other Free Software licenses.
\item Add ``What parts of your products are under the GPL or other Free
Software licenses?'' to your checklist of questions to ask when you
consider mergers, acquisitions, or joint ventures.
\item Encourage your engineers to participate collaboratively with GPL'd
software development. The more knowledge about the Free Software world
your organization has, the better equipped it is to deal with this
rapidly changing field.
\item When someone points out a potential GPL violation in one of your
products, do not assume the product line is doomed. The GPL is not a virus;
merely having GPL'd code in one part of a product does not necessarily
mean that every related product must also be GPL'd. And, even if some
software needs to be released that was not before, the product will
surely survive. In FSF's enforcement efforts, we have not yet
seen a product line die because source was released to customers in
compliance with the GPL.
\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% LocalWords: proprietarize redistributors sublicense yyyy Gnomovision EULAs
% LocalWords: Yoyodyne FrontPage improvers Berne copyrightable Stallman's GPLs
% LocalWords: Lessig Lessig's UCITA pre PDAs CDs reshifts GPL's Gentoo glibc
% LocalWords: TrollTech administrivia LGPL's MontaVista OpenTV Mitek Arce DVD
% LocalWords: unprotectable protectable Unfreedonia chipset CodeSourcery Iqtel
% LocalWords: impermissibly Bateman faire minimis Borland uncopyrightable Mgmt
% LocalWords: franca downloadable Bortez Bortez's Gingerich Michlmayr LGPL
% LocalWords: Slashdot sublicensed Vigorien Vigorien's Haxil Polgara GPL'd
% LocalWords: Thesulac Polgara's Haxil's Thesulac's SDK CD's tpb CCS RYF cd
%% LocalWords: ThinkPenguin TPE NWIFIROUTER Unboxing copylefted GPLv mkdir
%% LocalWords: Filesystem libreCMC README tabsize libCMC sudo reflash gcc
%% LocalWords: binutils bzip perl getopt libz dev libc menuconfig amd dpkg
%% LocalWords: toolchain filesystem thinkpenguin egrep posix jxpf ar UI ln
%% LocalWords: ThinkPenguin's versioned bootloader SRC mips librecmc linux
%% LocalWords: uclibc symlink tl wr squashfs sysupgrade preinstalled TFTP
%% LocalWords: busybox tftp hpa IP RJ UART PuTTY ipaddr serverip setenv nc
%% LocalWords: miswiring minicom startup miswire netcat uboot extratools
%% LocalWords: morx Login dmesg login ccs toplevel readme differentiators
%% LocalWords: hackable Relicensing relicensing toolkits OEM reaudited
%% LocalWords: redistributor cryptographic