Location: guide/compliance-guide.tex

bkuhn
Spell check and correction. Seems there were a lot of correctly spelled words missing from the LocalWords lists as well.
   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
% compliance-guide.tex -*- LaTeX -*-
\part{A Practical Guide to GPL Compliance}
\label{gpl-compliance-guide}
{\parindent 0in
This part is: \\
\begin{tabbing}
Copyright \= \copyright{} 2008, 2014 \= \hspace{.2in} Bradley M. Kuhn. \\
Copyright \= \copyright{} 2014 \> \hspace{.2in} Free Software Foundation, Inc. \\
Copyright \> \copyright{} 2008, 2014 \> \hspace{.2in} Software Freedom Law Center. \\
\end{tabbing}
\vspace{1in}
\begin{center}
Authors of this part are: \\
Bradley M. Kuhn \\
Aaron Williamson \\
Karen M. Sandler \\
\vspace{1in}
Copy editors of this part include: \\
Martin Michlmayr
\vspace{3in}
The copyright holders of this part 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}
}
\bigskip
\chapter*{Executive Summary}
This is a guide to effective compliance with the GNU General Public
License (GPL) and related licenses. Copyleft advocates
usually seek to assist the community with
GPL compliance cooperatively. This guide focuses on complying from the
start, so that readers can learn to avoid enforcement actions entirely, or, at
least, minimize the negative impact when enforcement actions occur.
This guide introduces and explains basic legal concepts related to the GPL and its
enforcement by copyright holders. It also outlines business practices and
methods that lead to better GPL compliance. Finally, it recommends proper
post-violation responses to the concerns of copyright holders.
\chapter{Background}
Copyright law grants exclusive rights to authors. Authors who chose copyleft
seek to protect the freedom of users and developers to copy, share, modify
and redistribute the software. However, copyleft is ultimately implemented
through copyright, and the GPL is primarily and by default a copyright
license. (See \S~\ref{explaining-copyright} for more about the interaction
between copyright and copyleft.) Copyright law grants an unnatural exclusive
control to copyright holders regarding copyright-controlled permissions
related to the work. Therefore, copyright holders (or their agents) are the
ultimately the sole authorities to enforce copyleft and protect the rights of
users. Actions for copyright infringement are the ultimate legal mechanism
for enforcement. Therefore, copyright holders, or collaborative groups of
copyright holders, have historically been the actors in GPL enforcement.
The earliest of these efforts began soon after the GPL was written by
Richard M.~Stallman (RMS) in 1989, and consisted of informal community efforts,
often in public Usenet discussions.\footnote{One example is the public
outcry over NeXT's attempt to make the Objective-C front-end to GCC
proprietary. RMS, in fact, handled this enforcement action personally and
the Objective-C front-end is still part of upstream GCC today.} Over the next decade, the Free Software Foundation (FSF),
which holds copyrights in many GNU programs, was the only visible entity
actively enforcing its GPL'd copyrights on behalf of the software freedom
community.
FSF's enforcement
was generally a private process; the FSF contacted violators
confidentially and helped them to comply with the license. Most
violations were pursued this way until the early 2000's.
By that time, Linux-based systems such as GNU/Linux and BusyBox/Linux had become very common, particularly in
embedded devices such as wireless routers. During this period, public
ridicule of violators in the press and on Internet fora supplemented
ongoing private enforcement and increased pressure on businesses to
comply. In 2003, the FSF formalized its efforts into the GPL Compliance
Lab, increased the volume of enforcement, and built community coalitions
to encourage copyright holders to together settle amicably with violators.
Beginning in 2004, Harald Welte took a more organized public enforcement
approach and launched \href{http://gpl-violations.org/}{gpl-violations.org}, a website and mailing
list for collecting reports of GPL violations. On the basis of these
reports, Welte successfully pursued many enforcement actions in Europe, including
formal legal action. Harald earns the permanent fame as the first copyright
holder to bring legal action in a court regarding GPL compliance.
In 2007, two copyright holders in BusyBox, in conjunction with the
Software Freedom Conservancy (``Conservancy''), filed the first copyright infringement lawsuit
based on a violation of the GPL\@ in the USA. While lawsuits are of course
quite public, the vast majority of Conservancy's enforcement actions
are resolved privately via
cooperative communications with violators. As both FSF and Conservancy have worked to bring
individual companies into compliance, both organizations have encountered numerous
violations resulting from preventable problems such as inadequate
attention to licensing of upstream software, misconceptions about the
GPL's terms, and poor communication between software developers and their
management. This document highlights these problems and describe
best practices to encourage corporate Free Software users to reevaluate their
approach to GPL'd software and avoid future violations.
Both FSF and Conservancy continue GPL enforcement and compliance efforts
for software under the GPL, the GNU Lesser
Public License (LGPL) and other copyleft licenses. In doing so, both organizations have
found that most violations stem from a few common, avoidable mistakes. All copyleft advocates hope to educate the community of
commercial distributors, redistributors, and resellers on how to avoid
violations in the first place, and to respond adequately and appropriately
when a violation occurs.
\section{Who Has Compliance Obligations?}
All distributors of modified or unmodified versions of copylefted works
unmodified versions of the works have compliance obligations. Common methods
of modifying the works include innumerable common acts, such as:
\begin{itemize}
\item embedding those works as executable copies
into a device,
\item transferring a digital copy of executable copies to someone else,
\item posting a patch to the copylefted software to a public mailing list.
\end{itemize}
Such distributors have obligations to (at least) the users to whom they (or
intermediary parties) distribute those copies. In some cases, distributors
have obligations to third parties not directly receiving their distribution
of the works (depending on the distributors chosen licensing options, as
described later in \S~\ref{binary-distribution-permission}). In addition,
distributors have compliance obligations to upstream parties, such as
preservation of reasonable legal notices embedded in the code, and
appropriate labeling of modified versions.
Online service providers and distributors alike have other compliance
obligations. In general, they must refrain from imposing any additional
restrictions on downstream parties. Most typically, such compliance problems
arise from ``umbrella licenses:'' EULAs, or sublicenses that restrict
downstream users' rights under copyleft. (See \S~\ref{GPLv2s6} and
\S~\ref{GPLv3s10}).
Patent holders having claims reading on GPL'd works they distribute must
refrain from enforcing those claims against parties to whom they distribute.
Furthermore, patent holders holding copyrights on GPLv3'd works must further
grant an explicit patent license for any patent claims reading on the version
they distributed, and therefore cannot enforce those specific patent claims
against anyone making, using or selling a work based on their distributed
version. All parties must refrain from acting as a provider of services or
distributor of licensed works if they have accepted, or had imposed on them
by judicial action, any legal conditions that would prevent them from meeting
any obligation under GPL\@. (See \S~\ref{GPLv2s7}, \S~\ref{GPLv3s11} and
\S~\ref{GPLv3s12}.
\section{What Are The Risks of Non-Compliance?}
Copyleft experts have for decades observed a significant mismatch between the
assumptions most businesses make about copyleft compliance and the realities.
Possibly due to excessive marketing of proprietary tools and services from
the for-profit compliance industry, businesses perennially focus on the wrong
concerns. This tutorial seeks to educate those businesses about what
actually goes wrong, what causes disputes, and how to resolve those disputes.
Many businesses currently invest undue resources to avoid unlikely risks that
have low historical incidence of occurrence and low cost of remediation,
while leaving unmanaged the risks that have historically resulted in all the
litigation and other adverse outcomes. For example, some ``compliance
industry''\footnote{``Compliance industry'' refers to third-party for-profit
companies that market proprietary software tools and/or consulting services
that purport to aid businesses with their Free Software license compliance
obligations, such as those found in GPL and other copyleft licenses. This
tutorial leaves the term in quotes throughout, primarily to communicate the
skepticism most of this tutorial's authors feel regarding the mere
existence of this industry. Not only do copyleft advocates object on
principle to proprietary software tools in general, and to their ironic use
specifically to comply with copyleft, but also to the ``compliance
industry'' vendors' marketing messaging, which some copyleft advocates
claim as a cause in the risk misassessments discussed herein. Bradley
M.~Kuhn, specifically, regularly uses the term ``compliance industrial
complex''
\href{http://en.wikipedia.org/wiki/Military-industrial_complex}{to
analogize the types of problems in this industry to those warned against
in the phrase of origin}.} vendors insist that great effort must be
expended to carefully list, in the menus or manuals of embedded electronics
products, copyright notices for every last copyright holder that contributed
to the Free Software included in the product. While nearly all Free Software
licenses, including copylefts like GPL, require preservation and display of
copyright notices, failure to meet this specific requirement is trivially
remedied. Therefore, businesses should spend just reasonable efforts to
properly display copyright notices, and note that failure to do so is simply
remedied: add the missing copyright notice!
\section{Understanding Who's Enforcing}
\label{compliance-understanding-whos-enforcing}
The mismatch between actual compliance risk and compliance risk management
typically results from a misunderstanding of licensor intentions. For-profit
businesses often err by assuming other actors have kindred motivations. The
primary enforcers of the GPL, however, have goals that for-profit businesses
will find strange and perhaps downright alien.
Specifically, community-oriented GPL enforcement organizations (called
``COGEOs'' throughout the remainder of this tutorial) are typically
non-profit charities (such as the FSF and Software Freedom Conservancy) who
declare, as part of their charitable mission, advancement of software freedom
for all users. In the USA, these COGEOs are all classified as charitable
under the IRS's 501(c)(3) designation, which is reserved for organizations
that have a mission to enhance the public good.
As such, these COGEOs enforce GPL primarily to pursue the policy goals and
motivations discussed throughout this tutorial: to spread software freedom
further. As such, COGEOs are unified in their primary goal to bring the
violator back into compliance as quickly as possible, and redress the damage
caused by the violation. COGEOs are steadfast in their position in a
violation negotiation: comply with the license and respect freedom.
Certainly, other entities do not share the full ethos of software freedom as
institutionalized by COGEOs, and those entities pursue GPL violations
differently. Oracle, a company that produces the GPL'd MySQL database, upon
discovering GPL violations typically negotiates a proprietary software
license separately for a fee. While this practice is not one a COGEO would
undertaking nor endorsing, a copyleft license technically permits this
behavior. To put a finer point on this practice already discussed
in~\S~\ref{Proprietary Relicensing}, copyleft advocates usually find copyleft
enforcement efforts focused on extract alternative proprietary licenses
distasteful at best, and a corrupt manipulation of copyleft at worst. Much
to the advocates' chagrin, such for-profit enforcement efforts seem to
increase rather than decrease.
Thus, unsurprisingly, for-profit adopters of GPL'd software often incorrectly
assume that all copyright holders seek royalties. Businesses therefore focus
on the risk of so-called ``accidental'' (typically as the result of
unsupervised activity by individual programmers) infringe copyright by
incorporating ``snippets'' of copylefted code into their own proprietary
computer program. ``Compliance industry'' flagship products, therefore,
focus on ``code scanning'' services that purport to detect accidental
inclusions. Such effort focuses on proprietary software development and view
Free Software as a foreign interloper. Such approach not only ignores
current reality that many companies build their products directly on major
copylefted projects (e.g., Android vendor's use of the kernel named Linux),
but also creates a culture of fear among developers, leading them into a
downward spiral of further hiding their necessary reliance on copylefted
software in the company's products.
Fortunately, COGEOs regard GPL compliance failures as an opportunity to
improve compliance. Every compliance failure downstream represents a loss of
rights by their users. The COGEOs are the guardian of its users' and
developers' rights. Their activity seeks to restore those rights, and
to protect the project's contributors' intentions in the making of their
software.
\chapter{Best Practices to Avoid Common Violations}
\label{best-practices}
Unlike highly permissive licenses (such as the ISC license), which
typically only require preservation of copyright notices, licensees face many
important requirements from the GPL. These requirements are
carefully designed to uphold certain values and standards of the software
freedom community. While the GPL's requirements may initially appear
counter-intuitive to those more familiar with proprietary software
licenses, by comparison, its terms are in fact clear and quite favorable to
licensees. Indeed, the GPL's terms actually simplify compliance when
violations occur.
GPL violations occur (or, are compounded) most often when companies lack sound
practices for the incorporation of GPL'd components into their
internal development environment. This section introduces some best
practices for software tool selection, integration and distribution,
inspired by and congruent with software freedom methodologies. Companies should
establish such practices before building a product based on GPL'd
software.\footnote{This document addresses compliance with GPLv2,
GPLv3, LGPLv2, and LGPLv3. Advice on avoiding the most common
errors differs little for compliance with these four licenses.
\S~\ref{lgpl} discusses the key differences between GPL and LGPL
compliance.}
\section{Evaluate License Applicability}
\label{derivative-works}
Political discussion about the GPL often centers around determining the
``work'' that must be licensed under GPL, or in other words, ``what is the
derivative and/or combined work that was created''. Nearly ever esoteric
question asked by lawyers seek to consider that question
\footnote{\tutorialpartsplit{In fact, a companion work, \textit{Detailed Analysis of the GNU GPL and Related
Licenses} contains an entire section discussing derivative works}{This tutorial in fact
also addresses the issue at length in~\S~\ref{derivative-works}}.} (perhaps because
that question explores exciting legal issues while the majority of the GPL
deals with much more mundane ones).
Of course, GPL was designed
primarily to embody the licensing feature of copyleft.
However, most companies who add
complex features to and make combinations with GPL'd software
are already well aware of their
more complex obligations under the license that require complex legal
analysis. And, there are few companies overall that engage in such
activities. Thus, in practical reality, this issue is not relevant to the vast
majority of companies distributing GPL'd software.
Thus, experienced GPL enforcers find that few redistributors'
compliance challenges relate directly to combined work issues in copyleft.
Instead, the distributions of GPL'd
systems most often encountered typically consist of a full operating system
including components under the GPL (e.g., Linux, BusyBox) and components
under the LGPL (e.g., the GNU C Library). Sometimes, these programs have
been patched or slightly improved by direct modification of their sources,
and thus the result is unequivocally a modified version. Alongside these programs,
companies often distribute fully independent, proprietary programs,
developed from scratch, which are designed to run on the Free Software operating
system but do not combine with, link to, modify, derive from, or otherwise
create a combined work with
the GPL'd components.\footnote{However, these programs do often combine
with LGPL'd libraries. This is discussed in detail in \S~\ref{lgpl}.}
In the latter case, where the work is unquestionably a separate work of
creative expression, no copyleft provisions are invoked.
The core compliance issue faced, thus, in such a situation, is not an discussion of what is or is not a
combined, derivative, and/or modified version of the work, but rather, issues related to distribution and
conveyance of binary works based on GPL'd source, but without Complete,
Corresponding Source.
As such, issues of software delivery are the primary frustration for GPL
enforcers. In particular, the following short list accounts for at least 95\%
of the GPL violations ever encountered:
\begin{itemize}
\item The violator fails to provide required information about the presence
of copylefted programs and their applicable license terms in the product
they have purchased.
\item The violator fails to reliably deliver \hyperref[CCS
Definition]{complete, corresponding source} (CCS) for copylefted programs
the violator knew were included (i.e., the CCS is either delivered but
incomplete, or is not delivered at all).
\item Requestors are ignored when they communicate with violator's published
addresses requesting fulfillment of businesses' obligations.
\end{itemize}
This tutorial therefore focuses primarily on these issue.
Admittedly, a tiny
minority of compliance situations relate to question of derivative,
combined, or modified versions of the work. Those
situations are so rare, and the details from situation to situation differ
greatly. Thus, such situations require a highly
fact-dependent analysis and cannot be addressed in a general-purpose
document such as this one.
\medskip
Most companies accused of violations lack a basic understanding
of how to comply even in the straightforward scenario. This document
provides those companies with the fundamental and generally applicable prerequisite knowledge.
For answers to rarer and more complicated legal questions, such as whether
your software is a derivative or combined work of some copylefted software, consult
with an attorney.\footnote{If you would like more information on the
application of derivative works doctrine to software, a detailed legal
discussion is presented in our colleague Dan Ravicher's article,
\textit{Software Derivative Work: A Circuit Dependent Determination} and in
\tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related
Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of
this tutorial}.}
This discussion thus assumes that you have already identified the
``work'' covered by the license, and that any components not under the GPL
(e.g., applications written entirely by your developers that merely happen
to run on a Linux-based operating system) distributed in conjunction with
those works are separate works within the meaning of copyright law and the GPL\@. In
such a case, the GPL requires you to provide complete corresponding
source (CCS)\footnote{For more on CCS, see
\tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related
Licenses}'s Section on GPLv2~\S2 and GPLv3~\S1.}{\S~\ref{GPLv2s2} and \S~\ref{GPLv3s1} of
this tutorial}.}
for the GPL'd components and your modifications thereto, but not
for independent proprietary applications. The procedures described in
this document address this typical scenario.
\section{Monitor Software Acquisition}
Software engineers deserve the freedom to innovate and import useful
software components to improve products. However, along with that
freedom should come rules and reporting procedures to make sure that you
are aware of what software that you include with your product.
The most typical response to an initial enforcement action is: ``We
didn't know there was GPL'd stuff in there''. This answer indicates
failure in the software acquisition and procurement process. Integration
of third-party proprietary software typically requires a formal
arrangement and management/legal oversight before the developers
incorporate the software. By contrast, developers often obtain and
integrate Free Software without intervention nor oversight. That ease of acquisition, however,
does not mean the oversight is any less necessary. Just as your legal
and/or management team negotiates terms for inclusion of any proprietary
software, they should gently facilitate all decisions to bring Free Software into your
product.
Simple, engineering-oriented rules help provide a stable foundation for
Free Software integration. For example, simply ask your software developers to send an email to a
standard place describing each new Free Software component they add to the system,
and have them include a brief description of how they will incorporate it
into the product. Further, make sure developers use a revision control
system (such as Git or Mercurial), and
store the upstream versions of all software in a ``vendor branch'' or
similar mechanism, whereby they can easily track and find the main version
of the software and, separately, any local changes.
Such procedures are best instituted at your project's launch. Once
chaotic and poorly-sourced development processes begin, cataloging the
presence of GPL'd components becomes challenging.
Such a situation often requires use of a tool to ``catch up'' your knowledge
about what software your product includes. Most commonly, companies choose
some software licensing scanning tool to inspect the codebase. However,
there are few tools that are themselves Free Software. Thus, GPL enforcers
usually recommend the GPL'd
\href{http://fossology.org/}{FOSSology system}, which analyzes a
source code base and produces a list of Free Software licenses that may apply to
the code. FOSSology can help you build a catalog of the sources you have
already used to build your product. You can then expand that into a more
structured inventory and process.
\section{Track Your Changes and Releases}
As explained in further detail below, the most important component of GPL
compliance is the one most often ignored: proper inclusion of CCS in all
distributions of GPL'd
software. To comply with GPL's CCS requirements, the distributor
\textit{must} always know precisely what sources generated a given binary
distribution.
In an unfortunately large number of our enforcement cases, the violating
company's engineering team had difficulty reconstructing the CCS
for binaries distributed by the company. Here are three simple rules to
follow to decrease the likelihood of this occurrence:
\begin{itemize}
\item Ensure that your
developers are using revision control systems properly.
\item Have developers mark or ``tag'' the full source tree corresponding to
builds distributed to customers.
\item Check that your developers store all parts of the software
development in the revision control system, including {\sc readme}s, build
scripts, engineers' notes, and documentation.
\end{itemize}
Your developers will benefit anyway from these rules. Developers will be
happier in their jobs if their tools already track the precise version of
source that corresponds to any deployed binary.
\section{Avoid the ``Build Guru''}
Too many software projects rely on only one or a very few team members who
know how to build and assemble the final released product. Such knowledge
centralization not only creates engineering redundancy issues, but also
thwarts GPL compliance. Specifically, CCS does not just require source code,
but scripts and other material that explain how to control compilation and
installation of the executable and object code.
Thus, avoid relying on a ``build guru'', a single developer who is the only one
who knows how to produce your final product. Make sure the build process
is well defined. Train every developer on the build process for the final
binary distribution, including (in the case of embedded software)
generating a final firmware image suitable for distribution to the
customer. Require developers to use revision control for build processes.
Make a rule that adding new components to the system without adequate
build instructions (or better yet, scripts) is unacceptable engineering
practice.
\chapter{Details of Compliant Distribution}
Distribution of GPL'd works has requirements; copyleft will not function
without placing requirements on redistribution. However, some requirements
are more likely to cause compliance difficult than others. This
chapter\footnote{Note that this chapter refers heavily to specific provisions
and language in
\hyperref[GPLv2s3-full-text]{GPLv2\S3}
and \hyperref[GPLv3s6-full-text]{GPLv3\S6}.
It may be helpful to review \S~\ref{GPLv2s3} and \S~\ref{GPLv3s6} first,
and then have a copy of each license open while reading this
section.} explains some the specific requirements placed upon
distributors of GPL'd software that redistributors are most likely to
overlook, yielding compliance problems.
First, \hyperref[GPLv2s1]{GPLv2\S1} and \hyperref[GPLv2s4]{GPLv2\S4} require
that the full license text must accompany every distribution (either in
source or binary form) of each licensed work. Strangely, this requirement is
responsible for a surprisingly significant fraction of compliance errors; too
often, physical products lack required information about the presence of
GPL'd programs and the applicable license terms. Automated build processes
can and should carry a copy of the license from the the source distribution
into the final binary firmware package for embedded products. Such
automation usually achieves compliance regarding license inclusion
requirements\footnote{At least one COGEO recommends the
\href{https://www.yoctoproject.org/}{Yocto Project}, since its engineers
have designed such features into it build process.}
\section{Binary Distribution Permission}
\label{binary-distribution-permission}
% be careful below, you cannot refill the \if section, so don't refill
% this paragraph without care.
The various versions of the GPL are copyright licenses that grant
permission to make certain uses of software that are otherwise restricted
by copyright law. This permission is conditioned upon compliance with the
GPL's requirements.
This section walks through the requirements (of both GPLv2 and GPLv3) that
apply when you distribute GPL'd programs in binary (i.e., executable or
object code) form, which is typical for embedded applications. Because a
binary application derives from a program's original sources, you need
permission from the copyright holder to distribute it. \S~3 of GPLv2 and
\S~6 of GPLv3 contain the permissions and conditions related to binary
distributions of GPL'd programs.\footnote{These sections cannot be fully
understood in isolation; read the entire license thoroughly before
focusing on any particular provision. However, once you have read and
understood the entire license, look to these sections to guide
compliance for binary distributions.} Failure to provide or offer CCS is the
single largest failure mode leading to compliance disputes.
GPL's binary distribution sections offer a choice of compliance methods,
each of which we consider in turn. Each option refers to the
``Corresponding Source'' code for the binary distribution, which includes
the source code from which the binary was produced. This abbreviated and
simplified definition is sufficient for the binary distribution discussion
in this section, but you may wish to refer back to this section after
reading the thorough discussion of ``Corresponding Source'' that appears
in \S~\ref{corresponding-source}.
\subsection{Option (a): Source Alongside Binary}
GPLv2~\S~3(a) and v3~\S~6(a) embody the easiest option for providing
source code: including Corresponding Source with every binary
distribution. While other options appear initially less onerous, this
option invariably minimizes potential compliance problems, because when
you distribute Corresponding Source with the binary, \emph{your GPL
obligations are satisfied at the time of distribution}. This is not
true of other options, and for this reason, we urge you to seriously
consider this option. If you do not, you may extend the duration of your
obligations far beyond your last binary distribution.
Compliance under this option is straightforward. If you ship a product
that includes binary copies of GPL'd software (e.g., in firmware, or on a
hard drive, CD, or other permanent storage medium), you can store the
Corresponding Source alongside the binaries. Alternatively, you can
include the source on a CD or other removable storage medium in the box
containing the product.
GPLv2 refers to the various storage mechanisms as ``medi[a] customarily
used for software interchange''. While the Internet has attained primacy
as a means of software distribution where super-fast Internet connections
are available, GPLv2 was written at a time when downloading software was
not practical (and was often impossible). For much of the world, this
condition has not changed since GPLv2's publication, and the Internet
still cannot be considered ``a medium customary for software
interchange''. GPLv3 clarifies this matter, requiring that source be
``fixed on a durable physical medium customarily used for software
interchange''. This language affirms that option (a) requires binary
redistributors to provide source on a physical medium.
Please note that while selection of option (a) requires distribution on a
physical medium, voluntary distribution via the Internet is very useful. This
is discussed in detail in \S~\ref{offer-with-internet}.
\subsection{Option (b): The Offer}
\label{offer-for-source}
Many distributors prefer to ship only an offer for source with the binary
distribution, rather than the complete source package. This
option has value when the cost of source distribution is a true
per-unit cost. For example, this option might be a good choice for
embedded products with permanent storage too small to fit the source, and
which are not otherwise shipped with a CD but \emph{are} shipped with a
manual or other printed material.
However, this option increases the duration of your obligations
dramatically. An offer for source must be good for three full years from
your last binary distribution (under GPLv2), or your last binary or spare
part distribution (under GPLv3). Your source code request and
provisioning system must be designed to last much longer than your product
life cycle. Thus, it also increases your compliance costs in the long
run.
In addition, if you are required to comply with the terms of GPLv2, you
{\bf cannot} use a network service to provide the source code. For GPLv2,
the source code offer is fulfilled only with physical media. This usually
means that you must continue to produce an up-to-date ``source code CD''
for years after the product's end-of-life.
\label{offer-with-internet}
Under GPLv2, it is acceptable and advisable for your offer for source code
to include an Internet link for downloadable source \emph{in addition} to
offering source on a physical medium. This practice enables those with
fast network connections to get the source more quickly, and typically
decreases the number of physical media fulfillment requests.
(GPLv3~\S~6(b) permits provision of source with a public
network-accessible distribution only and no physical media. We discuss
this in detail at the end of this section.)
The following is a suggested compliant offer for source under GPLv2 (and
is also acceptable for GPLv3) that you would include in your printed
materials accompanying each binary distribution:
\begin{quote}
The software included in this product contains copyrighted software that
is licensed under the GPL\@. A copy of that license is included in this
document on page $X$\@. You may obtain the complete Corresponding Source
code from us for a period of three years after our last shipment of this
product, which will be no earlier than 2011-08-01, by sending a money
order or check for \$5 to: \\
GPL Compliance Division \\
Our Company \\
Any Town, US 99999 \\
\\
Please write ``source for product $Y$'' in the memo line of your
payment.
You may also find a copy of the source at
\url{http://www.example.com/sources/Y/}.
This offer is valid to anyone in receipt of this information.
\end{quote}
There are a few important details about this offer. First, it requires a
copying fee. GPLv2 permits ``a charge no more than your cost of
physically performing source distribution''. This fee must be reasonable.
If your cost of copying and mailing a CD is more than around \$10, you
should perhaps find a cheaper CD stock and shipment method. It is simply
not in your interest to try to overcharge the community. Abuse of this
provision in order to make a for-profit enterprise of source code
provision will likely trigger enforcement action.
Second, note that the last line makes the offer valid to anyone who
requests the source. This is because v2~\S~3(b) requires that offers be
``to give any third party'' a copy of the Corresponding Source. GPLv3 has
a similar requirement, stating that an offer must be valid for ``anyone
who possesses the object code''. These requirements indicated in
v2~\S~3(c) and v3~\S~6(c) are so that noncommercial redistributors may
pass these offers along with their distributions. Therefore, the offers
must be valid not only to your customers, but also to anyone who received
a copy of the binaries from them. Many distributors overlook this
requirement and assume that they are only required to fulfill a request
from their direct customers.
The option to provide an offer for source rather than direct source
distribution is a special benefit to companies equipped to handle a
fulfillment process. GPLv2~\S~3(c) and GPLv3~\S~6(c) avoid burdening
noncommercial, occasional redistributors with fulfillment request
obligations by allowing them to pass along the offer for source as they
received it.
Note that commercial redistributors cannot avail themselves of the option
(c) exception, and so while your offer for source must be good to anyone
who receives the offer (under v2) or the object code (under v3), it
\emph{cannot} extinguish the obligations of anyone who commercially
redistributes your product. The license terms apply to anyone who
distributes GPL'd software, regardless of whether they are the original
distributor. Take the example of Vendor $V$, who develops a software
platform from GPL'd sources for use in embedded devices. Manufacturer $M$
contracts with $V$ to install the software as firmware in $M$'s device.
$V$ provides the software to $M$, along with a compliant offer for source.
In this situation, $M$ cannot simply pass $V$'s offer for source along to
its customers. $M$ also distributes the GPL'd software commercially, so
$M$ too must comply with the GPL and provide source (or $M$'s \emph{own}
offer for source) to $M$'s customers.
This situation illustrates that the offer for source is often a poor
choice for products that your customers will likely redistribute. If you
include the source itself with the products, then your distribution to
your customers is compliant, and their (unmodified) distribution to their
customers is likewise compliant, because both include source. If you
include only an offer for source, your distribution is compliant but your
customer's distribution does not ``inherit'' that compliance, because they
have not made their own offer to accompany their distribution.
The terms related to the offer for source are quite different if you
distribute under GPLv3. Under v3, you may make source available only over
a network server, as long as it is available to the general public and
remains active for three years from the last distribution of your product
or related spare part. Accordingly, you may satisfy your fulfillment
obligations via Internet-only distribution. This makes the ``offer for
source'' option less troublesome for v3-only distributions, easing
compliance for commercial redistributors. However, before you switch to a
purely Internet-based fulfillment process, you must first confirm that you
can actually distribute \emph{all} of the software under GPLv3. Some
programs are indeed licensed under ``GPLv2, \emph{or any later version}''
(often abbreviated ``GPLv2-or-later''). Such licensing gives you the
option to redistribute under GPLv3. However, a few popular programs are
only licensed under GPLv2 and not ``or any later version''
(``GPLv2-only''). You cannot provide only Internet-based source request
fulfillment for the latter programs.
If you determine that all GPL'd works in your whole product allow upgrade
to GPLv3 (or were already GPLv3'd to start), your offer for source may be
as simple as this:
\begin{quote}
The software included in this product contains copyrighted software that
is licensed under the GPLv3\@. A copy of that license is included in this
document on page $X$\@. You may obtain the complete Corresponding Source
code from us for a period of three years after our last shipment of this
product and/or spare parts therefor, which will be no earlier than
2011-08-01, on our website at
\url{http://www.example.com/sources/productnum/}.
\end{quote}
\medskip
Under both GPLv2 and GPLv3, source offers must be accompanied by a copy of
the license itself, either electronically or in print, with every
distribution.
Finally, it is unacceptable to use option (b) merely because you do not have
Corresponding Source ready. We find that some companies choose this option
because writing an offer is easy, but producing a source distribution as
an afterthought to a hasty development process is difficult. The offer
for source does not exist as a stop-gap solution for companies rushing to
market with an out-of-compliance product. If you ship an offer for source
with your product but cannot actually deliver \emph{immediately} on that
offer when your customers request it, you should expect an enforcement
action.
\subsection{Option (c): Noncommercial Offers}
As discussed in the last section, GPLv2~\S~3(c) and GPLv3~\S~6(c) apply
only to noncommercial use. These options are not available to businesses
distributing GPL'd software. Consequently, companies that redistribute
software packaged for them by an upstream vendor cannot merely pass along
the offer they received from the vendor; they must provide their own offer
or corresponding source to their distributees. We talk in detail about
upstream software providers in \S~\ref{upstream}.
\subsection{Option 6(d) in GPLv3: Internet Distribution}
Under GPLv2, your formal provisioning options for Corresponding Source
ended with \S~3(c). But even under GPLv2, pure Internet source
distribution was a common practice and generally considered to be
compliant. GPLv2 mentions Internet-only distribution almost as aside in
the language, in text at the end of the section after the three
provisioning options are listed. To quote that part of GPLv2~\S~3:
\begin{quote}
If distribution of executable or object code is made by offering access to
copy from a designated place, then offering equivalent access to copy the
source code from the same place counts as distribution of the source code,
even though third parties are not compelled to copy the source along with
the object code.
\end{quote}
When that was written in 1991, Internet distribution of software was the
exception, not the rule. Some FTP sites existed, but generally software
was sent on magnetic tape or CDs. GPLv2 therefore mostly assumed that
binary distribution happened on some physical media. By contrast,
GPLv3~\S~6(d) explicitly gives an option for this practice that the
community has historically considered GPLv2-compliant.
Thus, you may fulfill your source-provision obligations by providing the
source code in the same way and from the same location. When exercising
this option, you are not obligated to ensure that users download the
source when they download the binary, and you may use separate servers as
needed to fulfill the requests as long as you make the source as
accessible as the binary. However, you must ensure that users can easily
find the source code at the time they download the binary. GPLv3~\S~6(d)
thus clarifies a point that has caused confusion about source provision in
v2. Indeed, many such important clarifications are included in v3 which
together provide a compelling reason for authors and redistributors alike
to adopt GPLv3.
\subsection{Option 6(e) in GPLv3: Software Torrents}
Peer-to-peer file sharing arose well after GPLv2 was written, and does not
easily fit any of the v2 source provision options. GPLv3~\S~6(e)
addresses this issue, explicitly allowing for distribution of source and
binary together on a peer-to-peer file sharing network. If you distribute
solely via peer-to-peer networks, you can exercise this option. However,
peer-to-peer source distribution \emph{cannot} fulfill your source
provision obligations for non-peer-to-peer binary distributions. Finally,
you should ensure that binaries and source are equally seeded upon initial
peer-to-peer distribution.
\section{Preparing Corresponding Source}
\label{corresponding-source}
Most enforcement cases involve companies that have unfortunately not
implemented procedures like our \S~\ref{best-practices} recommendations
and have no source distribution arranged at all. These companies must
work backwards from a binary distribution to come into compliance. Our
recommendations in \S~\ref{best-practices} are designed to make it easy to
construct a complete and Corresponding Source release from the outset. If
you have followed those principles in your development, you can meet the
following requirements with ease. If you have not, you may have
substantial reconstruction work to do.
\subsection{Assemble the Sources}
For every binary that you produce, you should collect and maintain a copy
of the sources from which it was built. A large system, such as an
embedded firmware, will probably contain many GPL'd and LGPL'd components
for which you will have to provide source. The binary distribution may
also contain proprietary components which are separate and independent
works that are covered by neither the GPL nor LGPL\@.
The best way to separate out your sources is to have a subdirectory for
each component in your system. You can then easily mark some of them as
required for your Corresponding Source releases. Collecting
subdirectories of GPL'd and LGPL'd components is the first step toward
preparing your release.
\subsection{Building the Sources}
Few distributors, particularly of embedded systems, take care to read the
actual definition of Corresponding Source in the GPL\@. Consider
carefully the definition, from GPLv3:
\begin{quote}
The ``Corresponding Source'' for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities.
\end{quote}
and the definition from GPLv2:
\begin{quote}
The source code for a work means the preferred form of the work for making
modifications to it. For an executable work, complete source code means
all the source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control compilation
and installation of the executable.
\end{quote}
Note that you must include ``scripts used to control compilation and
installation of the executable'' and/or anything ``needed to generate,
install, and (for an executable work) run the object code and to modify
the work, including scripts to control those activities''. These phrases
are written to cover different types of build environments and systems.
Therefore, the details of what you need to provide with regard to scripts
and installation instructions vary depending on the software details. You
must provide all information necessary such that someone generally skilled
with computer systems could produce a binary similar to the one provided.
Take as an example an embedded wireless device. Usually, a company
distributes a firmware, which includes a binary copy of
Linux\footnote{``Linux'' refers only to the kernel, not the larger system
as a whole.} and a filesystem. That filesystem contains various binary
programs, including some GPL'd binaries, alongside some proprietary
binaries that are separate works (i.e., not derived from, nor based on
freely-licensed sources). Consider what, in this case, constitutes adequate
``scripts to control compilation and installation'' or items ``needed to
generate, install and run'' the GPL'd programs.
Most importantly, you must provide some sort of roadmap that allows
technically sophisticated users to build your software. This can be
complicated in an embedded environment. If your developers use scripts to
control the entire compilation and installation procedure, then you can
simply provide those scripts to users along with the sources they act
upon. Sometimes, however, scripts were never written (e.g., the
information on how to build the binaries is locked up in the mind of your
``build guru''). In that case, we recommend that you write out build
instructions in a natural language as a detailed, step-by-step {\sc
readme}.
No matter what you offer, you need to give those who receive source a
clear path from your sources to binaries similar to the ones you ship. If
you ship a firmware (kernel plus filesystem), and the filesystem contains
binaries of GPL'd programs, then you should provide whatever is necessary
to enable a reasonably skilled user to build any given GPL'd source
program (and modified versions thereof), and replace the given binary in
your filesystem. If the kernel is Linux, then the users must have the
instructions to do the same with the kernel. The best way to achieve this
is to make available to your users whatever scripts or process your
engineers would use to do the same.
These are the general details for how installation instructions work.
Details about what differs when the work is licensed under LGPL is
discussed in \S~\ref{lgpl}, and specific details that are unique to
GPLv3's installation instructions are in \S~\ref{user-products}.
\subsection{What About the Compiler?}
The GPL contains no provision that requires distribution of the compiler
used to build the software. While companies are encouraged to make it as
easy as possible for their users to build the sources, inclusion of the
compiler itself is not normally considered mandatory. The Corresponding
Source definition -- both in GPLv2 and GPLv3 -- has not been typically
read to include the compiler itself, but rather things like makefiles,
build scripts, and packaging scripts.
Nonetheless, in the interest of goodwill and the spirit of the GPL, most
companies do provide the compiler itself when they are able, particularly
when the compiler is based on GCC\@ or another copylefted compiler. If you have
a GCC-based system, it is your prerogative to redistribute that GCC
version (binaries plus sources) to your customers. We in the software freedom
community encourage you to do this, since it often makes it easier for
users to exercise their software freedom. However, if you chose to take
this recommendation, ensure that your GCC distribution is itself
compliant.
If you have used a proprietary, third-party compiler to build the
software, then you probably cannot ship it to your customers. We consider
the name of the compiler, its exact version number, and where it can be
acquired as information that \emph{must} be provided as part of the
Corresponding Source. This information is essential to anyone who wishes
to produce a binary. It is not the intent of the GPL to require you to
distribute third-party software tools to your customer (provided the tools
themselves are not based on the GPL'd software shipped), but we do believe
it requires that you give the user all the essential non-proprietary facts
that you had at your disposal to build the software. Therefore, if you
choose not to distribute the compiler, you should include a {\sc readme}
about where you got it, what version it was, and who to contact to acquire
it, regardless of whether your compiler is Free Software, proprietary, or
internally developed.
\section{Best Practices and Corresponding Source}
\S~\ref{best-practices} and \S~\ref{corresponding-source} above are
closely related. If you follow the best practices outlined above, you
will find that preparing your Corresponding Source release is an easier
task, perhaps even a trivial one.
Indeed, the enforcement process itself has historically been useful to
software development teams. Development on a deadline can lead
organizations to cut corners in a way that negatively impacts its
development processes. We have frequently been told by violators that
they experience difficulty when determining the exact source for a binary
in production (in some cases because their ``build guru'' quit during the
release cycle). When management rushes a development team to ship a
release, they are less likely to keep release sources tagged and build
systems well documented.
We suggest that, if contacted about a violation, product builders use GPL
enforcement as an opportunity to improve their development practices. No
developer would argue that their system is better for having a mysterious
build system and no source tracking. Address these issues by installing a
revision system, telling your developers to use it, and requiring your
build guru to document his or her work!
\section{Non-Technical Compliance Issues}
Certainly, the overwhelming majority of compliance issues are, in fact,
either procedural or technical. Thus, the primary material in this chapter
so far has covered those issues. However, a few compliance issues do require
more direct consideration of a legal situation. This portion guide does not
consider those in detail, as a careful reading of the earlier chapters of
Part~\ref{gpl-lgpl-part} shows various places where legal considerations are
necessary for considering compliance activity.
For example, specific compliance issues related to
\hyperref[GPLv2s7]{GPLv2\S7}, \hyperref[GPLv3s7]{GPLv3\S7}, and
\hyperref[GPLv3s7]{GPLv3\S11} demand a more traditional approach to legal
license compliance. Of course, such analysis and consideration can be
complicated, and some are considered in the enforcement case studies that
follow in the next part. However, compliance issues related to such sections
are not rare, and, as is typical, no specific training is available for
dealing with extremely rare occurrences.
\section{Self-Assessment of Compliance}
Most companies that adopt copylefted software believe they have complied.
Humans usually have difficult admitting their own mistakes, particularly
systematic ones. Therefore, perhaps the most important necessary step to
stay in compliance is a company's regular evaluation of their own compliance.
First, exercise a request CCS for all copylefted works from all your upstream
providers of software and of components embedding software. Then, perform
your own CCS check on this material first, and verify that it meets the
requirements. This tutorial presents later a case study of a COGEO's CCS
check in \S~\ref{pristine-example}, which you can emulate when examining
their own CCS\@.
Second, measure all copyleft compliance from the position of the
users\footnote{Realizing of course that user very well may not be your own
customer.} downstream from you exercising their rights under GPL\@. Have
those users received notice of the copylefted software included in your
product? Is CCS available to the users easily (preferably by automated
means)? Ask yourself these questions frequently. If you cannot answer these
questions with certainty in the positive, dig deeper and modify your process.
Avoid ``compliance industry'' marketing distractions and concentrate on the
copylefted software you already know is in your product. Historically, the
risk from a copylefted code snippet that some programmer dropped in your
proprietary product careless of the consequences is a problem far more
infrequent and less difficult to resolve. Efficient management of the risks
of higher concern lies in making sure you can provide, for example, precisely
CCS for a copy of Coreboot, the kernel named Linux, BusyBox, or GNU tar that
you included in a product your company shipped two years ago than in the risk
of 10 lines of GPL'd Java code an engineer accidentally pasted into the
source of your ERP system.
Thus, reject the ``compliance industry'' suggestions that code scanners find
and help solve fundamental compliance problems. Consider how COGEO's tend to
use code scanners. FOSSology is indeed an important part of a violation
investigation, but such is the last step and catches only some (usually
minor) licensing notice problems. Thus, code scanners can help solve minor
compliance problems once you have resolved the major ones. Code scanners
do not manage risk.
\chapter{When The Letter Comes}
Unfortunately, many GPL violators ignore their obligations until they are
contacted by a copyright holder or the lawyer of a copyright holder. You
should certainly contact your own lawyer if you have received a letter
alleging that you have infringed copyrights that were licensed to you
under the GPL\@. This section outlines a typical enforcement case and
provides some guidelines for response. These discussions are
generalizations and do not all apply to every alleged violation. However,
COGEO's in particular universally follow the processes described herein.
\section{Communication Is Key}
GPL violations are typically only escalated when a company ignores the
copyright holder's initial communication or fails to work toward timely
compliance. Accused violators should respond very promptly to the
initial request. As the process continues, violators should follow up weekly with the
copyright holders to make sure everyone agrees on targets and deadlines
for resolving the situation.
Ensure that any staff who might receive communications regarding alleged
GPL violations understands how to channel the communication appropriately
within your organization. Often, initial contact is addressed for general
correspondence (e.g., by mail to corporate headquarters or by e-mail to
general informational or support-related addresses). Train the staff that
processes such communications to escalate them to someone with authority
to take action. An uninformed response to such an inquiry (e.g., from
a first-level technical support person) can cause negotiations to fail
prematurely.
Answer promptly by multiple means (paper letter, telephone call, and
email), even if your response merely notifies the sender that you are
investigating the situation and will respond by a certain date. Do not
let the conversation lapse until the situation is fully resolved.
Proactively follow up with synchronous communication means to be sure
communications sent by non-reliable means (such as email) were received.
Remember that the software freedom community generally values open communication and
cooperation, and these values extend to GPL enforcement. You will
generally find that software freedom developers and their lawyers are willing to
have a reasonable dialogue and will work with you to resolve a violation
once you open the channels of communication in a friendly way.
Furthermore, if the complaint comes from a COGEO, assume they are
well-prepared. COGEO's fully investigate compliance issues before raising
the issue. The claims and concerns will be substantiated, and immediate
denials will likely lead the COGEO to suspect malice rather than honest
mistake.
However, the biggest and most perennial mistake that all COGEOs see during
enforcement is this: failure to include the violators' software development
teams in the enforcement discussions and negotiations. As described above,
CCS verification and approval is the most time-consuming and difficult part
of resolving most compliance matters. Without direct contact between
software developers on both sides, the resolution of the technical issues
involved in demonstrating that the binary distributed was built from the
source provided is likely to be tortuous, expensive, and tense. Your lawyers
will certainly be understandably reluctant to expose your employees to direct
inquiry from potentially adverse parties. However, facilitated exchanges of
information among software engineers communicating on technical subjects
shortens the time to resolution, substantially reduces the cost of reaching
resolution, and prevents unnecessary escalation due to mutual
misunderstanding. Furthermore, such frank technical discussion will often be
the only way to avoid compliance litigation once a violation has occurred.
Fortunately, these frank discussions will improve your company's
relationships. Free Software development communities improve software to
benefit everyone, which includes you and your company. When you use
copylefted community software in your products, you are part of that
community. Therefore, resolving a compliance matter is an occasion to
strengthen your relationship to the community, by increasing communication
between your developers and the project whose work you use for business
benefit.
\section{Termination}
Many redistributors overlook the GPL's termination provision (GPLv2~\S~4 and
GPLv3~\S~8). Under v2, violators forfeit their rights to redistribute and
modify the GPL'd software until those rights are explicitly reinstated by
the copyright holder. In contrast, v3 allows violators to rapidly resolve
some violations without consequence.
If you have redistributed an application under GPLv2\footnote{This applies
to all programs licensed to you under only GPLv2 (``GPLv2-only'').
However, most so-called GPLv2 programs are actually distributed with
permission to redistribute under GPLv2 \emph{or any later version of the
GPL} (``GPLv2-or-later''). In the latter cases, the redistributor can
choose to redistribute under GPLv2, GPLv3, GPLv2-or-later or even
GPLv3-or-later. Where the redistributor has chosen v2 explicitly, the
v2 termination provision will always apply. If the redistributor has
chosen v3, the v3 termination provision will always apply. If the
redistributor has chosen GPLv2-or-later, then the redistributor may want
to narrow to GPLv3-only upon violation, to take advantage of the
termination provisions in v3.}, but have violated the terms of GPLv2,
you must request a reinstatement of rights from the copyright holders
before making further distributions, or else cease distribution and
modification of the software forever. Different copyright holders
condition reinstatement upon different requirements, and these
requirements can be (and often are) wholly independent of the GPL\@. The
terms of your reinstatement will depend upon what you negotiate with the
copyright holder of the GPL'd program.
Since your rights under GPLv2 terminate automatically upon your initial
violation, \emph{all your subsequent distributions} are violations and
infringements of copyright. Therefore, even if you resolve a violation on
your own, you must still seek a reinstatement of rights from the copyright
holders whose licenses you violated, lest you remain liable for
infringement for even compliant distributions made subsequent to the
initial violation.
GPLv3 is more lenient. If you have distributed only v3-licensed programs,
you may be eligible under v3~\S~8 for automatic reinstatement of rights.
You are eligible for automatic reinstatement when:
\begin{itemize}
\item you correct the violation and are not contacted by a copyright
holder about the violation within sixty days after the correction, or
\item you receive, from a copyright holder, your first-ever contact
regarding a GPL violation, and you correct that violation within thirty
days of receipt of copyright holder's notice.
\end{itemize}
In addition to these permanent reinstatements provided under v3, violators
who voluntarily correct their violation also receive provisional
permission to continue distributing until they receive contact from the
copyright holder. If sixty days pass without contact, that reinstatement
becomes permanent. Nonetheless, you should be prepared to cease
distribution during those initial sixty days should you receive a
termination notice from the copyright holder.
Given that much discussion of v3 has focused on its so-called more
complicated requirements, it should be noted that v3 is, in this regard,
more favorable to violators than v2.
However, note that most Linux-based systems typically include some software
licensed under GPLv2-only, and thus the copyright holders have withheld
permission to redistribute under terms of GPLv3. In larger aggregate
distributions which include GPLv2-only works (such as the kernel named
Linux), redistributors must operate as if termination is immediate and
permanent, since the technological remove of GPLv2-only works from the larger
distribution requires much more engineering work than the negotiation
required to seek restoration of rights for distribution under GPLv2-only
after permanent termination.
\chapter{Standard Requests}
As we noted above, different copyright holders have different requirements
for reinstating a violator's distribution rights. Upon violation, you no
longer have a license under the GPL\@. Copyright holders can therefore
set their own requirements outside the license before reinstatement of
rights. We have collected below a list of reinstatement demands that
copyright holders often require.
\begin{itemize}
\item {\bf Compliance on all Free Software copyrights}. Copyright holders of Free Software
often want a company to demonstrate compliance for all GPL'd software in
a distribution, not just their own. A copyright holder may refuse to
reinstate your right to distribute one program unless and until you
comply with the licenses of all Free Software in your distribution.
\item {\bf Notification to past recipients}. Users to whom you previously
distributed non-compliant software should receive a communication
(email, letter, bill insert, etc.) indicating the violation, describing
their rights under the GPL, and informing them how to obtain a gratis source
distribution. If a customer list does not exist (such as in reseller
situations), an alternative form of notice may be required (such as a
magazine advertisement).
\item {\bf Appointment of a GPL Compliance Officer.} The software freedom community
values personal accountability when things go wrong. Copyright holders
often require that you name someone within the violating company
officially responsible for Free Software license compliance, and that this
individual serve as the key public contact for the community when
compliance concerns arise.
\item {\bf Periodic Compliance Reports.} Many copyright holders wish to
monitor future compliance for some period of time after the violation.
For some period, your company may be required to send regular reports on
how many distributions of binary and source have occurred.
\end{itemize}
These are just a few possible requirements for reinstatement. In the
context of a GPL violation, and particularly under v2's termination
provision, the copyright holder may have a range of requests in exchange
for reinstatement of rights. These software developers are talented
professionals from whose work your company has benefited. Indeed, you are
unlikely to find a better value or more generous license terms for similar
software elsewhere. Treat the copyright holders with the same respect you
treat your corporate partners and collaborators.
\chapter{Special Topics in Compliance}
There are several other issues that are less common, but also relevant in
a GPL compliance situation. To those who face them, they tend to be of
particular interest.
\section{LGPL Compliance}
\label{lgpl}
GPL compliance and LGPL compliance mostly involve the same issues. As we
discussed in \S~\ref{derivative-works}, questions of modified versions of
software are highly fact-dependent and cannot be easily addressed in any
overview document. The LGPL adds some additional complexity to the
analysis. Namely, the various LGPL versions permit proprietary licensing
of certain types of modified versions. These issues are discussed in greater
detail in Chapter~\ref{LGPLv2} and~\ref{LGPLv3}. However, as a rule of thumb, once you have determined
(in accordance with LGPLv3) what part of the work is the ``Application''
and what portions of the source are ``Minimal Corresponding Source'', then
you can usually proceed to follow the GPL compliance rules that
discussed above, replacing our discussion of ``Corresponding Source'' with
``Minimal Corresponding Source''.
LGPL also requires that you provide a mechanism to combine the Application
with a modified version of the library, and outlines some options for
this. Also, the license of the whole work must permit ``reverse
engineering for debugging such modifications'' to the library. Therefore,
you should take care that the EULA used for the Application does not
contradict this permission.
Thus, under the terms of LGPL, you must refrain from license terms on works
based on the licensed work that prohibit replacement of the licensed
components of the larger non-LGPL'd work, or prohibit decompilation or
reverse engineering in order to enhance or fix bugs in the LGPL'd components.
LGPLv3 is not surprisingly easier to understand and examine from a compliance
lens, since the FSF was influenced in LGPLv3's drafting by questions and
comments on LGPLv2.1 over a period of years. Admittedly, LGPLv2.1 is still
in wide use, and thus compliance with LGPLv2.1 remains a frequent topic you
may encounter. The best advice there is careful study of
Chapter~\ref{LGPLv2}.
However, to repeat a key point here made within that chapter: Note though
that, since the LGPLv2.1 can be easily upgraded to GPLv2-or-later, in the
worst case you simply need to comply as if the software was licensed under
GPLv2. The only reason you must consider the question of whether you have a
``work that uses the library'' or a ``work based on the library'' is when you
wish to take advantage of the ``weak copyleft'' effect of the Lesser GPL\@.
If GPLv2-or-later is an acceptable license (i.e., if you plan to copyleft the
entire work anyway), you may find this an easier option.
\section{Upstream Providers}
\label{upstream}
With ever-increasing frequency, software development (particularly for
embedded devices) is outsourced to third parties. If you rely on an
upstream provider for your software, note that you \emph{cannot ignore
your GPL compliance requirements} simply because someone else packaged
the software that you distribute. If you redistribute GPL'd software
(which you do, whenever you ship a device with your upstream's software in
it), you are bound by the terms of the GPL\@. No distribution (including
redistribution) is permissible absent adherence to the license terms.
Therefore, you should introduce a due diligence process into your software
acquisition plans. This is much like the software-oriented
recommendations we make in \S~\ref{best-practices}. Implementing
practices to ensure that you are aware of what software is in your devices
can only improve your general business processes. You should ask a clear
list of questions of all your upstream providers and make sure the answers
are complete and accurate. The following are examples of questions you
should ask:
\begin{itemize}
\item What are all the licenses that cover the software in this device?
\item From which upstream vendors, be they companies or individuals, did
\emph{you} receive your software before distributing it to us?
\item What are your GPL compliance procedures?
\item If there is GPL'd software in your distribution, we will be
redistributors of this GPL'd software. What mechanisms do you have in
place to aid us with compliance?
\item If we follow your recommended compliance procedures, will you
formally indemnify us in case we are nonetheless found to be in
violation of the GPL?
\end{itemize}
This last point is particularly important. Many GPL enforcement actions are
escalated because of petty finger-pointing between the distributor and its
upstream. In our experience, agreements regarding GPL compliance issues
and procedures are rarely negotiated up front. However, when they are,
violations are resolved much more smoothly (at least from the point of
view of the redistributor).
Consider the cost of potential violations in your acquisition process.
Using Free Software allows software vendors to reduce costs significantly, but be
wary of vendors who have done so without regard for the licenses. If your
vendor's costs seem ``too good to be true,'' you may ultimately bear the
burden of the vendor's inattention to GPL compliance. Ask the right
questions, demand an account of your vendors' compliance procedures, and
seek indemnity from them.
In particular, any time your vendor incorporates copylefted software, you
\textit{must} exercise your own rights as a user to request CCS for all the
copylefted programs that your suppliers provided to you. Furthermore, you
must ensure that CCS is correct and adequate yourself. Good vendors should
help you do this, and make it easy. If those vendors cannot, pick a
different vendor before proceeding with the product.
\section{Mergers and Acquisitions}
Often, larger companies often encounter copyleft licensing during a Mergers
and Acquisitions (M\&A) process. Ultimately, a merger or acquisition causes
all of the other company's problems to become yours. Therefore, for most
concerns, the acquirer ``simply'' must apply the compliance analysis and
methodologies discussed earlier across the acquired company's entire product
line. Of course, this is not so simple, as such effort may be substantial,
but a well-defined process for compliance investigation means the required
work, while voluminous, is likely rote.
A few sections of GPL require careful attention and legal analysis to
determine the risk of acquisitions. Those handling M\&A issues should pay
particular attention to the requirements of GPLv2~\S7 and GPLv3~\S10--12 ---
focusing on how they relate to the acquired assets may be of particular
importance.
For example, GPLv3\S10 clarifies that in business acquisitions, whether by
sale of assets or transfers of control, the acquiring party is downstream
from the party acquired. This results in new automatic downstream licenses
from upstream copyright holders, licenses to all modifications made by the
acquired business, and rights to source code provisioning for the
now-downstream purchaser. However, despite this aid given by explicit
language in GPLv3, acquirers must still confirm compliance by the acquired
(even if GPLv3\S10 does assert the the acquirers rights under GPL, that does
not help if the acquired is out of compliance altogether). Furthermore, for
fear of later reprisal by the acquirer if a GPL violation is later discovered
in the acquired's product line, the acquired may need to seek a waiver and
release of from additional damages beyond a requirement to comply fully (and
a promise of rights restoration) if a GPL violation by the acquired is later
uncovered during completion of the acquisition or thereafter.
Finally, other advice available regarding handling of GPL compliance in an
M\&A situation tends to ignore the most important issue: most essential
copylefted software is not wholly copyrighted by the entities involved in the
M\&A transaction. Therefore, copyleft obligations likely reach out to the
customers of all entities involved, as well as to the original copyright
holders of the copylefted work. As such, notwithstanding the two paragraphs
in GPLv3\S10, the entities involved in M\&A should read the copyleft licenses
through the lens of third parties whose software freedom rights under those
licenses are of equal importance to then entities inside the transaction.
\section{User Products and Installation Information}
\label{user-products}
GPLv3 requires you to provide ``Installation Information'' when v3
software is distributed in a ``User Product.'' During the drafting of v3,
the debate over this requirement was contentious. However, the provision
as it appears in the final license is reasonable and easy to understand.
If you put GPLv3'd software into a User Product (as defined by the
license) and \emph{you} have the ability to install modified versions onto
that device, you must provide information that makes it possible for the
user to install functioning, modified versions of the software. Note that
if no one, including you, can install a modified version, this provision
does not apply. For example, if the software is burned onto an
non-field-upgradable ROM chip, and the only way that chip can be upgraded
is by producing a new one via a hardware factory process, then it is
acceptable that the users cannot electronically upgrade the software
themselves.
Furthermore, you are permitted to refuse support service, warranties, and
software updates to a user who has installed a modified version. You may
even forbid network access to devices that behave out of specification due
to such modifications. Indeed, this permission fits clearly with usual
industry practice. While it is impossible to provide a device that is
completely unmodifiable\footnote{Consider that the iPhone, a device
designed primarily to restrict users' freedom to modify it, was unlocked
and modified within 48 hours of its release.}, users are generally on
notice that they risk voiding their warranties and losing their update and
support services when they make modifications.\footnote{A popular t-shirt
in the software freedom community reads: ``I void warranties.''. Our community is
well-known for modifying products with full knowledge of the
consequences. GPLv3's ``Installation Instructions'' section merely
confirms that reality, and makes sure GPL rights can be fully exercised,
even if users exercise those rights at their own peril.}
GPLv3 is in many ways better for distributors who seek some degree of
device lock-down. Technical processes are always found for subverting any
lock-down; pursuing it is a losing battle regardless. With GPLv3, unlike
with GPLv2, the license gives you clear provisions that you can rely on
when you are forced to cut off support, service or warranty for a customer
who has chosen to modify.
% FIXME-soon: write a full section on Javascript compliance. Here's a
% potentially useful one-sentence introduction for such a
% section.
% Non-compliance with GPLv3 in the
% distribution of Javascript on the Web is becoming more frequent
%FIXME-soon: END
\section{Beware The Consultant in Enforcers' Clothing}
There are admittedly portions of the GPL enforcement community that function
somewhat like the
\href{http://en.wikipedia.org/wiki/Hacker_%28computer_security%29#Classifications}{computer
security and network penetration testing hacker community}. By analogy,
most COGEO's consider themselves
\href{http://en.wikipedia.org/wiki/White_hat_%28computer_security%29}{white hats},
while some might appropriately call
\hyperref[Proprietary Relicensing]{proprietary relicensing} by the name ``\href{http://en.wikipedia.org/wiki/Hacker_%28computer_security%29#Black_hat}{black hats}''.
And, to finalize the analogy, there are indeed few
\href{http://en.wikipedia.org/wiki/Grey_hat}{grey hat} GPL enforcers.
Grey hat GPL enforcers usually have done some community-oriented GPL
enforcement themselves, typically working as a volunteer as a COGEO, but make
their living as a ``hired gun'' consultant to find GPL violations and offer
to ``fix them'' for companies. Other such operators hold copyrights in some
key piece of copylefted software and enforce as a mechanism to find out who
is most likely to fund improvements on the software.
A few stories abound in the GPL enforcement community that companies have
often formed beneficial consulting or employment relationships with
developers they first encountered through enforcement. In some cases,
working together to alter the mode of use of the project's code in the
company's products was an explicit element in dispute resolution. More
often, the communication channels opened in the course of the inquiry served
other and more fruitful purposes later.
Feelings and opinions about this behavior are mixed within the larger
copyleft community. Some see it as a reasonable business model and others
renounce it as corrupt behavior. However, from the point of view of a GPL
violator, the most important issue is to determine the motivations of the
enforcer. The COGEOs such as the FSF and Conservancy have made substantial
public commitments to enforce in a way that is uniform, transparent, and
publicly documented. Since these organizations are public charities, they
are accountable to the IRS and the public at large in their annual Form 990
filings, and everyone can examine their revenue models and scrutinize their
work.
However, entities and individuals who do GPL enforcement centered primarily
around a profit motive are likely the most dangerous enforcement entities for
one simple reason: an agreement to comply fully with the GPL for past and
future products, which is always the paramount goal to COGEOs, may not be an
adequate resolution for a proprietary relicensing company or grey hat GPL
enforcer. Therefore, violators are advised to consider carefully who has
made the enforcement inquiry and ask when and where they have made public
commitments and reports regarding their enforcement work, perhaps asking them
to directly mimic the detailed public disclosures done by COGEOs.
\chapter{Conclusion}
GPL compliance need not be an onerous process. Historically, struggles
have been the result of poor development methodologies and communications,
rather than any unexpected application of the GPL's source code disclosure
requirements.
Compliance is straightforward when the entirety of your enterprise is
well-informed and well-coordinated. The receptionists should know how to
route a GPL source request or accusation of infringement. The lawyers
should know the basic provisions of Free Software licenses and your source
disclosure requirements, and should explain those details to the software
developers. The software developers should use a version control system
that allows them to associate versions of source with distributed
binaries, have a well-documented build process that anyone skilled in the
art can understand, and inform the lawyers when they bring in new
software. Managers should build systems and procedures that keep everyone
on target. With these practices in place, any organization can comply
with the GPL without serious effort, and receive the substantial benefits
of good citizenship in the software freedom community, and lots of great code
ready-made for their products.
\vfill
% LocalWords: redistributors NeXT's Slashdot Welte gpl ISC embedders BusyBox
% LocalWords: someone's downloadable subdirectory subdirectories filesystem
% LocalWords: roadmap README upstream's Ravicher's FOSSology readme CDs iPhone
% LocalWords: makefiles violator's Michlmayr Stallman RMS GPL'd Harald LGPL
%% LocalWords: GPL's resellers copylefted sublicenses GPLv unmanaged MySQL
%% LocalWords: misassessments licensor COGEOs COGEO LGPLv CCS Requestors
%% LocalWords: codebase Yocto distributees COGEO's Coreboot ERP reseller
%% LocalWords: redistributor reinstatements decompilation acquired's grey
%% LocalWords: upgradable unmodifiable Relicensing relicensing