-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathOS-Policy_Master.txt
1932 lines (1639 loc) · 91.7 KB
/
OS-Policy_Master.txt
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
%###########################################################################
% OSADL Open Source Policy Template
%
% Master template
%
% Copyright (c) 2020-2022 Open Source Automation Development Lab (OSADL) eG
% Authors: Carsten Emde, Caren Kresse
% Authors of the various subsections and annexes are listed
% separately in the header of the individual documents
%
%###########################################################################
Open Source Policy Template
The Basis for License Compliance
Version 1.3
Editorial note
This collection of explanations, templates and contract proposals was created in
close collaboration with OSADL's General Counsel Dr. Till Jaeger and other legal
professionals. However, the fact that legal professionals were involved in the
preparation of the documents does not mean that any of the assessments or
recommendations may be understood as individual legal advice that can only be
given on a per-case basis by a lawyer.
Licensing
Copyright (c) 2019-2022 Open Source Automation Development Lab (OSADL) eG
Licensed under the Creative Commons Attribution 4.0 International license
(CC-BY-4.0), https://creativecommons.org/licenses/by/4.0/.
Attribution: A project by the Open Source Automation Development Lab (OSADL) eG,
www.osadl.org/os-policy.
========================================
How to use the subsequent "Open Source Policy Template"
This OSADL Open Source Policy Template aims to facilitate the creation of a FOSS
policy; it contains
- Template texts for the various chapters of a FOSS policy that can be adapted
according to a company's requirements. These texts are made up of instructions
with brief explanations for anyone who reads and implements the FOSS policy.
Printed in regular font on normal background.
- Printed in regular font on a light grey background with a grey left bar.
- When there are various possibilities of interpreting or handling a situation,
possible options are given.
########################################
Preceded by the word "Option" and printed in italic font on normal background.
########################################
- Additional explanations for whoever creates a company's individual FOSS
policy from this template. These may be removed from the final document.
========================================
Printed in regular font on an orange background with a dark orange left bar.
========================================
- Ready made text block templates that may be used to modify or extend existing
company contracts and other documents, such as employment contracts.
++++++++++++++++++++++++++++++++++++++++
Printed in regular font on a light grey background with a grey left bar.
++++++++++++++++++++++++++++++++++++++++
- Templates for annexes to a company's FOSS policy listed in List of policy
annexes including processes and forms that can be completed to provide legal and
other information on projects and products.
Denoted by "-> Annex" and the respective document is linked with this FOSS
policy template.
- Supplements to provide technology background and explain relevant aspects of
copyright law and license compliance in more detail listed in List of
supplements for further reading.
Denoted by "-> Supplement" and the respective document is linked with this FOSS
policy template.
========================================
Preamble
What is FOSS?
Holders of rights of a particular software may decide to permit using, analyzing
and modifying the software freely and copying and distributing it under very
liberal conditions by employing a so-called "Open Source" license. The term
"Open Source" for such software was established around 1998 by Bruce Perens,
Eric S. Raymond, Tim O'Reilly and others and was based on "Free Software"
introduced by Richard Stallman about ten years before that date. Although the
social and political ambitions of the two movements differ substantially, the
legal implications of the two terms "Open Source Software" and "Free Software"
do not and can, at least in a legal context, be used interchangeably. However,
the coexistence of the two base terms and a number of combined terms with the
addition of the adjective "libre" such as
- Open Source software (abbreviated OSS)
- Free Software
- Free and Open Source software (abbreviated FOSS)
- Free, Libre and Open Source software (abbreviated FLOSS)
may lead to confusion, since users may conclude that these terms denote
different legal items, but in fact are legally equivalent. It, therefore, is
recommended to choose a unique term and use it throughout all documents of a
company. Here and in all related documents the term "Free and Open Source
Software" and the abbreviation "FOSS" will be used exclusively.
The definition whether a particularly licensed software may be called
"Free and Open Source Software" and the employed license be called "Free and
Open Source license" is ruled by an organization that meanwhile has reached a
certain authoritative status and is regularly releasing a list of licenses that
fulfill the requirements of FOSS in the so-called "Open Source Definitions (OSD)".
These definitions are publicly available at the URL http://opensource.org/OSD and
the eligible licenses at the URL http://opensource.org/licenses/alphabetical.
Relevance of FOSS in our company
One of the most important characteristics of FOSS licenses is that they are
completely compatible to copyright law, since they have holders of rights and
authors in a very conventional way, but grant - at the same time - unrestricted
use and very liberal distributions rights. This has led to a considerable change
of paradigms of software development and made it possible to establish
communities of software developers and users with more contributors and to
create software with a higher complexity and a better reliability than was
imaginable ever before. These properties are particularly attractive for
industry where it is additionally appreciated that FOSS cannot be discontinued
in the same way as manufacturers of proprietary software can force customers to
stop using a particular software by simply refusing to provide mandatory
software updates. In consequence, FOSS has become indispensable in virtually all
major industries.
Goals of this FOSS policy
As already mentioned FOSS can be employed without any restriction everywhere and
by everybody, but when FOSS is copied and distributed a permission from the
holders of right must be obtained just in the same way as with proprietary
software. Although everybody may conclude a FOSS license and the obligations are
relatively easy to fulfill, the obligations must be fulfilled completely and
meticulously, since any failure to do so will lead to a violation of the license
resulting in copyright infringement and may entail civil and criminal
consequences. Evidently, this not only applies immediately to individuals, but
in an identical way also to representatives of legal entities such as limited
liability and share holder companies. As the most effective way to ensure that
all employees of our company are safely informed and instructed on how to treat
incoming and outgoing software in general and FOSS in particular we have
released this company-wide authoritative FOSS policy. More specifically, the
goal of this FOSS policy is to
- create sustainable knowledge about FOSS related processes in our company
- avoid copyright infringement
- provide control about the licensing of our company's intellectual property
- meet customer requirements
- meet the OpenChain specification
(https://wiki.linuxfoundation.org/_media/openchain/openchainspec-current.pdf)
Overview
The structure of this FOSS policy is as follows:
What? The concrete task is outlined and explained.
How? The process for performing a specific task is outlined.
Who? The responsible role for each task is assigned.
General remarks
Our company is OSADL member. Therefore, whenever any uncertainty arises about
how to compliantly handle a FOSS licensing issue, the OSADL Legal FAQ
(https://www.osadl.org/FAQ) must be consulted. For a login to this member-only
content, if not yet available, the OSADL Office <[email protected]> may be
contacted. If the issue is not yet solved, it must be forwarded to the OSADL
Office and a new FAQ be requested.
Contents
Preamble
A Scope
B Responsibilities
Management (M)
Open Source Compliance Officer (OSCO)
Project Lead (PL)
Legal Department (LD)
Software Developer (SD)
Purchase Department (PD)
Quality Management (QM)
Human Resources (HR)
##################################
Optional: Open Source Board (OSB)
##################################
Training
C Communication of the FOSS policy
D Detection and analysis of third-party software
Goals
Main categorization of the handling of third-party software
Evaluation of technical suitability
Candidate for Use
Request for approval
Repository check-in
E Creating FOSS License Information
Use Case 1: Internal use
Use Case 2: Distribution of unmodified source code
Use Case 3: Distribution of modified source code
Use Case 4: Distribution of unmodified binaries
Use Case 5: Distribution of modified binaries
Use Case 6: Software as a Service (SaaS)
Use Case 7: Distribution of a Linux kernel in an embedded system
Use Case 8: Distribution of an entire Linux distribution
Use Case 9: Updates
Use Case 10: Yocto build system
Use Case 11: Container
Use Case 12: Encryption and GPL
Creating BOM
Documentation of compliance
Updating FOSS License Information
F Delivery of FOSS License Information
Delivery media
QA process
G Contribution to FOSS projects
Approval of contributor
Approval of FOSS project
Approval of contribution
Contribution permission
H Own FOSS projects
I Audits and certification
J Patent considerations
Third-party patents
Own patents
Abbreviations and definitions
List of policy annexes
Annex 1: OSADL Open Source License Obligations Checklists
Annex 2: Copyleft policy
Annex 3: Bill of Material (BOM)
Annex 4: Compatibility Matrix
Annex 5: Special purchase conditions Free and Open Source software
Annex 6: Approval process
Annex 7: List of known licenses
Annex 8: Deny List
Annex 9: Allow List
Annex 10: Approval request
Annex 11: SaaS licenses
Annex 12: Contribution permission
Annex 13: FOSS in Terms and Conditions
Annex 14: Encryption and GPL - Template texts
Annex 15: FOSS in external development
List of supplements for further reading
Supplement 1: What is copyleft?
Supplement 2: How to scan
Supplement 3: License compatibility
Supplement 4: What is a derivative work?
Supplement 5: How to archive and rebuild
Supplement 6: How to: Acknowledgments
Supplement 7: Selecting a FOSS license
Supplement 8: License compliance for containers and Containerfiles
Supplement 9: Third-party rights
A Scope
This FOSS policy is applicable to
########################################
Option 1: the entire corporation
========================================
To implement a FOSS policy for an entire corporation it is recommended to limit
the global content to high level provisions and establish complementary
policies in the individual subsidiaries.
========================================
########################################
Option 2: the entire company
########################################
Option 3: the subsidiaries
########################################
Option 4: the departments
########################################
Option 5: the projects
########################################
B Responsibilities
This chapter defines the roles of the various departments and individual staff
with respect to tasks provided by this FOSS policy.
========================================
The responsibilities described in this chapter can and most likely will be
taken over by already existing employees of a company taking on additional
responsibilities with regards to FOSS.
========================================
I. Management (M)
Our management is responsible for defining general company rules with respect to
software in general and FOSS in particular.
- Approval of initial adoption and substantial changes of this FOSS policy
- Decisions on overall risk management based on recommendations and risk
assessment provided by the Open Source Compliance Officer (OSCO)
- Appointment and dismissal of the OSCO
========================================
Since general rules largely depend on the individual industry the company
belongs to and on particular preferences of the management, no general
recommendation can be given. A company may, for example prohibit the use of a
software under a particular license or provide a general recommendation on how
to act in case of a legal question with respect to FOSS licensing issues. An
example for such general recommendations is given in General remarks.
========================================
II. Open Source Compliance Officer (OSCO)
========================================
Large companies or corporations are likely to have individual OSCOs for the
various departments or subsidiaries as well as a company-wide or group-wide
OSCO hierarchy. For details and suggestions for organizational structure see
Open Source Board (OSB) (Role: OSB).
========================================
The Open Source Compliance Officer (OSCO) represents the main contact person of
our company in the context of using, copying and distributing FOSS of any kind.
He or she coordinates all related activities and maintains a dedicated
communication with representatives of the other roles listed below. The OSCO
reports to the M and prepares decisions of the M with regard to the following
issues:
- (Unclear) interpretation of FOSS licenses that could result in license
violations are therefore relevant for the risk management of the company
- Modification of this FOSS policy
========================================
The role of the OSCO is often assigned to an employee who is already familiar
and actively engaged with FOSS. In many cases, the OSCO is also the company's
main contact person for OSADL.
The assignment of the OSCO can be documented here or for example on a company's
intranet or wiki pages. This decision might depend on how often the assignment
changes.
========================================
########################################
Option 1: Assignment of the OSCO for our company:
Assigned by: Signatory of the company
OSCO name: First name goes here Last name goes here
Department: Department
Phone number: Phone number
Email address: Email address
Beginning of the assignment: Day.Month.Year
End of the assignment: Day.Month.Year
Deputy in case of absence: First name goes here Last name goes here
Average week hours to dedicate to the OSCO role: N hours
########################################
Option 2: The current OSCO for our company is assigned at:
https://wiki.company.tld
########################################
The OSCO has the following responsibilities:
- Maintenance of our FOSS policy
- Organizing training for staff members
- Maintaining continuous contact to the Legal Department (LD)
- Selecting and purchasing software tools and technical infrastructure such as
tools and server for software scanning
========================================
Depending on the size of the company and the amount of different FOSS that is
used, the task of maintaining tooling and integrating it into the build process
may be quite extensive and may therefore be assigned to an additional person who
can support the OSCO, e.g. as Open Source Build and Release Engineer (OSBRE).
========================================
- Supervising and organizing Quality Management (QM) for FOSS
- Maintaining the contribution process, if any
- Providing a first contact point for internal requests
- Contact to the OSCO for external requests is communicated at our company
website at http://www.company.tld/osco
========================================
The following items may need to be investigated further:
- Required qualifications for the OSCO role (experience, certifications)
- Training requirements (continuing education once a year) and knowledge
management
- Financing and resources
========================================
++++++++++++++++++++++++++++++++++++++++
Addition to the work contract for an OSCO
As Open Source Compliance Officer for company / department the employee
takes on responsibilities in addition to his or her regular function. The scope
and nature of these additional responsibilities are outlined in our FOSS
policy. To be able to meet these responsibilities the OSCO is released from his
or her regular function for an average of hours per week.
========================================
How many hours / days per week the OSCO may spend on FOSS-related
responsibilities depends mainly on the size of a company. It is recommended to
estimate on average approximately one hour per week for every ten developers
with a limit of one day per week. If more time is required, it is recommended
to appoint a second OSCO.
========================================
++++++++++++++++++++++++++++++++++++++++
III. Project Lead (PL)
The Project Lead (PL) is responsible for the license compliant use of FOSS
within the products which he or she is in charge of. That includes the following
tasks:
- Implementing this FOSS policy within his or her projects
- Deciding or supporting the decision making on
- which FOSS, if any, to use
- which FOSS licenses are acceptable in general and/or in concrete use cases
(e.g. based on -> Annex 1: "OSADL Open Source License Obligations Checklists"
and -> Annex 2: "Copyleft policy")
- which particular FOSS tools and technical infrastructure to acquire
- whether own software shall be contributed to FOSS
- When ordering third-party software with or as a product through the Purchase
Department (PD) requesting a scan for additional requirements to detect
dependent software that may need to be acquired or at least licensed separately
(for details see -> Supplement 2: "How to scan", Section 2.4)
- Creating and maintaining the -> Annex 3: "Bill of Material (BOM)" for his or
her project with support from Software Developers (SD)
- Referring internal and external project participants to this FOSS policy
- Maintaining direct contact to the OSCO
IV. Legal Department (LD)
The Legal Department (LD) is responsible for FOSS license interpretation,
identifying license obligations and answering legal questions of M, OSCO and PD.
########################################
Option 1: "Internal Legal Department"
The contact for FOSS license issues at our LD is
First name Last name Email address
Requests are made by OSCO or PL according to their budgets.
########################################
Option 2: "External Legal Counsel"
Legal issues with respect to FOSS license issues are handled by the external
lawyer
First name Last name Email address
########################################
Particular competences and responsibilities are:
- Creating and reviewing license checklists
- License interpretation
- Consideration of FOSS in agreements with customers and suppliers. Text
templates are given in "FOSS in Terms and Conditions"
- Consideration of FOSS in employment and freelancer contracts
- Handling external requests (e.g. C&D letters)
- Decisions about license compatibility, confirming or adapting the template of
a compatibility matrix provided as part of the OSADL Open Source License
Obligations Checklists -> Annex 4: "Compatibility Matrix".
V. Software Developer (SD)
========================================
Within the scope of this policy the term "Software Developer" includes all staff
that actively and directly work with FOSS, e.g. software engineers, application
developers, system engineers, DevOps engineers, hardware developers, etc.
========================================
Every Software Developer (SD) has the following responsibilities when handling
software that is distributed under a FOSS license:
- Evaluating FOSS for technical suitability
- Introducing FOSS into internal repositories while complying with the process
described in Section C
- Supporting the PL in creating the BOM for a project
- Contributing when approved as contributor in compliance with the process
described in Section F
VI. Purchase Department (PD)
The staff of the Purchase Department (PD) has the following responsibilities:
- Requesting the BOM from any software provider as part of the commercial offer
of any kind of software
- Requesting the BOM and Bill of Dependencies from any software provider as part
of the commercial offer of any kinst of software.
- Requesting the BOM and BOD from any hardware provider for hardware that shall
be redistributed as part of the commercial offer of any kind of hardware that
might contain software, as built-in firmware.
- Taking care that FOSS standard clauses are used in purchase agreements, see
-> Annex 5: "Special purchase conditions FOSS"
VII. Quality Management (QM)
========================================
If a company does not have separate QM staff, the PL could take over the tasks
listed below.
========================================
The staff of the Quality Management (QM) has the following responsibilities:
- Ensuring that all license obligations of all licenses that are contained in a
product according to the internal BOM are correctly fulfilled. For this purpose,
the -> Annex 1: "OSADL Open Source License Obligations Checklists" may be
consulted.
VIII. Human Resources (HR)
The Human Resources (HR) department is involved in the organizational aspects of
FOSS-related company processes. It's responsibilities include
- adapting work contracts of affected staff when they are assigned FOSS-related
responsibilities,
- adapting contractual agreements with freelancers that create software (see->Annex 15:
"FOSS in external development"),
- documenting training attendance in personnel files,
- adapting contractual agreements with external trainers or anybody else interacting
with FOSS policy rules,
- referring internal and external staff to this FOSS policy.
IX. Optional: Open Source Board (OSB) (role: OSB)
========================================
Larger companies might be faced with the challenge to coordinate varying
requirements on a FOSS policy that different departments or subsidiaries might
have. To address this challenge, it should be considered to establish a
so-called "Open Source Board" (OSB). This can be made up of the OSCO of each
sub-organization and representatives of the LD. Given the appropriate authority,
the OSB can relieve demand on the LD and the M by handling individual requests
and making definite decisions with respect to FOSS licensing issues.
========================================
The Open Source Board (OSB) coordinates compliance efforts of our various
sub-organizations. To that end, it has the following responsibilities:
- Adapting this FOSS policy to the requirements of each sub-organization.
- Deciding on possible FOSS license interpretations.
- Overall classification of FOSS licenses, i.e. creating and maintaining -> Annex 7: "List of
known licenses", -> Annex 8: "Deny List" and -> Annex 9: "Allow List".
- Assessing and giving contribution permissions.
- Assessing and deciding practical questions of FOSS compliance in case of
doubt.
- Regularly synchronizing FOSS-related activities of all sub-organizations.
- Organizing shared training and conferences for the OSCOs (role: OSCO) of all
sub-organizations.
X. Training
Initial and continuous training is required to understand general and particular
copyright and FOSS licensing topics.
########################################
Option 1: Training requirements are specified in detail.
The OSCO is responsible for organizing staff training:
- The OSCO will provide a first overview about this FOSS policy and explain the
relevant topics of the policy in an at least 30-minute session during the first
30 days of the employment of every new employee who is immediately or indirectly
dealing with FOSS.
- The OSCO will offer training courses to all staff members who deal immediately
or indirectly with FOSS to ensure that 85 % of them are trained every 2 years.
- Additional external training is organized by the OSCO.
########################################
Option 2: Only a general recommendation is given.
There are various training possibilities available and staff should attend these
as required:
- internal training course
- external training course
- OSADL seminars
- webinars
- continuing education (books and internet resources)
- intranet information
- videos
########################################
C Communication of the FOSS policy
Our company's FOSS policy is communicated within the entire company and to
involved external parties in the following ways:
- Initial and updated versions are communicated via circular letter and on our
Intranet at the URL http://intranet.company.tld/FOSS-Policy.pdf (role: OSCO).
#########################################
Option 1: The following additional provisions are added to employment
contracts of any affected staff, of employed programmers,
freelancers, project managers, software purchase department, quality assessment
department, and trainees.
#########################################
+++++++++++++++++++++++++++++++++++++++++
English:
The "FOSS policy" contains the guidelines for the use of FOSS by all employees
and can be accessed through the Intranet at http://intranet.company.tld/FOSS-Policy.pdf.
The employee is obliged to take note of and follow the employer's FOSS policy
immediately after taking up his or her duties. The employer will inform the employee
about updates of the FOSS policy which the employee must also immediately take
note of and comply with.
+++++++++++++++++++++++++++++++++++++++++
#########################################
Option 2: This FOSS policy is communicated to every affected employee in an
obligatory training course.
#########################################
Option 3: Every affected employee must individually confirm the receipt and
acknowledgment of this FOSS policy.
#########################################
- When contracting external parties to develop software on behalf of our company, the
requirements of FOSS compliance must be considered in any contractual agreements. For
details and text templates when contracting external software development see "FOSS
in external development".
- The following section is added to instructions and/or contractual agreements with
external trainers and anybody else who is interacting with the rules in the FOSS policy
(role: OSCO)
++++++++++++++++++++++++++++++++++++++++
When mentioning or including topics that relate to handling any kind of incoming
or outgoing software our company's FOSS policy must be consulted. The authoritative
version of the FOSS policy is attached to this document or provided by email. For
any assistance with the FOSS policy and related company processes the Open Source
Compliance Officer (OSCO) must be contacted. Name and contact information of the
OSCO are provided in the FOSS policy.
++++++++++++++++++++++++++++++++++++++++
This FOSS policy itself and all documents that directly and indirectly refer to
it are documented in our company's archive and are considered and/or integrated,
if applicable, while undergoing quality certification such as ISO 9001 or
ISO 5230 (OpenChain) (role: OSCO).
Modifications and updates of this FOSS policy have to be communicated to all relevant
staff (role: OSCO).
D Detection and analysis of third-party software
There are different types of licenses of third-party software. A categorization
can be found in section Abbreviations and definitions.
This section describes the process to determine which FOSS is used in our
company, in particular for distribution in products. This includes FOSS
components contained in proprietary third-party software.
=======================================
These first two options of how to handle third-party software aim to
differentiate between any software (FOSS and otherwise) that is used in
products or in close connection with products, development or
testing tools, and software that is solely used internally, i.e.
company IT. For the differentiation between internal and distributed FOSS, see
-> Section D.II.
======================================
########################################
Option 1: This requires that all software acquired by us...
########################################
Option 2: This requires that all software acquired by us that is intended for
use in or for a product...
########################################
...in any of the possible forms
- as a purchased software product
- as a component to complement in-house development
- as a specimen for testing
- as a tool for a research project
- etc.
on any of the possible paths into our company
- on a data carrier (CD, DVD, USB memory stick)
- installed on hardware
- downloaded from the Internet
- on an employee's notebook
- etc.
must pass a bottleneck where the software is registered and a legal and
technical analysis is performed before the software is released for being used
in the company.
I. Goals
Creating and maintaining a company-wide (or at least project specific) archive
that lists all third-party software that is available in our company and
establishing a process to release the software under particular conditions has
a number of goals:
- Knowing what external software is used and what license conditions apply
- Avoiding the use of unlicensed software as FOSS
- Avoiding breach of customer agreements
- Collecting the necessary information for the creation of a BOM and BOD for products
that contain software: any distribution of FOSS requires a BOM, i.e. a list of
software components and their licenses -> Annex 3: "Bill of Material (BOM)"
II. Main categorization of the handling of third-party software
########################################
Option 1: "All FOSS is treated as equal"
There are common processes for all types of third-party software irrespective of
whether the software is only used in-house or whether it is conveyed as or along
with a product or made available as a service.
########################################
========================================
If the status of the company is not only looked at for the moment, but possible
future mergers and acquisitions are taken into account and it can be expected
that ownership of the company and, thus, of the software, is going to change,
the company may be well advised to establish identical procedures for employed
and conveyed third-party software. In another scenario, some software may, for
the time being, only be useful inside the company, but at a later date be
requested by customers so it may be decided to integrate the software into a
product. In both scenarios, it may be difficult, if not impossible, to
retrospectively procure the complete paperwork and, if applicable, the complete
corresponding source code, in order to compliantly fulfill the license
conditions that are only imposed when conveying the software and not when only
employing it. If every piece of software in a company is treated as if it were
conveyed as or along with a product, the above retrospective dilemma can be
avoided.
========================================
########################################
Option 2: "No rules apply to in-house FOSS"
FOSS that is only employed in-house and/or on computers owned by the company is
neither registered nor particularly treated in any way. Every employee of the
company is free to download and install FOSS on computers that belong to the
company and are not intended to be conveyed to third parties.
########################################
========================================
FOSS that was obtained by a legal entity such as a limited liability or stock
company can be used within the company and shared among all employees without
any restrictions or license obligations. At a given point in time, there is
probably nothing wrong when deciding to exempt such software completely from any
processes and measures. The option not to impose any rules on in-house FOSS has
the advantage that time and cost expenses for processes and administration are
avoided.
For larger companies it may be advisable to at least maintain a
company-wide directory where all employed third-party software is listed. This
may help avoid that an unnecessary large number of different software versions
is deployed and may bring users together to assist each other to get acquainted
with the software.
========================================
========================================
Please note that the legal situation is unclear about whether or not providing
affiliates (see definition in Abbreviations and definitions) with copies of FOSS
is considered as distribution. The various standpoints are:
########################################
Option 1: We consider the exchange of FOSS among affiliates as mere internal
use and FOSS License Information is provided only on request.
########################################
Option 2: We consider the exchange of FOSS among affiliates as distribution and
FOSS License Information is provided as described in the use cases below.
########################################
Option 3: We use a group-wide repository with access to the source code for all
affiliates.
########################################
Rationale for option 3: A common repository is in some cases the easiest way to
reduce risks with regard to compliance with FOSS license obligations without
creating administrative overhead.
========================================
III Evaluation of technical suitability
SD and PL are permitted to evaluate freely downloadable software for a first
technical assessment before the legal analysis and approval process is
initialized. However, the following conditions must be observed:
- Only for technical assessment
- Download is permitted if no acceptance of license agreement or "Terms of use"
is required. In case that any license or other legal document must be accepted
in the name of our company, an approval from LD is needed. In this case, a
request of SD to [email protected] with the subject "Request for
permission - evaluating software for technical suitability" must be submitted
and following items must be specified:
- Name of the software
- Download link
- Link to the legal text or copy of the legal text
- Referral to this section of the policy
- LD: Review license text and provide inquirer with approval or denial. Store
short explanatory statement with the name of the software in the archive on our
company's Intranet at the URL https://intranet.company.tld/directory
- Including in internal software repositories is not allowed: No software may be
stored in the internal development repositories without prior approval according
to Section C.V For evaluation, the server [Network name of the evaluation
server] may be used.
========================================
When developing software using third party components it is advised to not
restrict developers during the evaluation phase, but let them assess which
software would best fit a use case so that an informed decision can be made once
the technical space has been explored. However, this does not mean that rules
should not be applied, as there are situations where there are legal
implications, such as when a third party component needs a license agreement or
terms of use need to be accepted when downloading or purchasing. Such cases
would need to be controlled by the legal department. During the evaluation
phase, the components should (likely) also not be included in any internal
software repositories.
========================================
IV Candidate for Use
When a software component (hereafter referred to as "Candidate for Use") is
considered useful for our company, it will need to go through an approval
process. A downloaded or purchased software component may become a Candidate
for Use after successful technical evaluation or by being purchased as or along
with a product.
Purchased software from third-party suppliers
When downloading a particular software component from an online repository or
project website, the scope of the software that becomes the Candidate for Use
is obvious. In contrast, software that is purchased from a supplier may
encompass a much larger and less clearly defined scope. Therefore, particular
aspects have to be considered when collecting the information on the basis of
which the approval process is performed.
############################################
Option 1: The approval process is performed solely on the basis of the
license information provided by the supplier.
############################################
Option 2: The supplier is requested to provide information on contained
software in form of a BOM according to the
requirements of the purchase agreement (see
Annexes -> Purchase-Contract "Special purchase conditions FOSS", (role: PD))
############################################
Option 3: Individual rules apply to each supplier depending on our business
relationship and the quality of the supplied information.
############################################
There are various ways of confirming that purchased software is and continuously
can be distributed compliantly:
- Supplier audits
- OpenChain conformance of suppliers
- Collecting and analyzing pre-sales information
If a supplier claims that a product does not contain any FOSS, the
PL has to decide whether to
- perform a binary analysis scan of the product (role: SD), or
- request a written confirmation from the supplier (role: PD)
Approval process
The approval process is detailed in -> Annex 6: "Approval process", and the
documents -> Annex 7: "List of known licenses", -> Annex 8: "Deny List" and ->
Annex 9: "Allow List" must be consulted. If the conclusion of the approval
process is clearly positive, the Candidate for Use is checked into the company's
repository according to Section C.VI. If the outcome is clearly negative, the
Candidate for Use is entered into our company's database fully qualified name of
the database on our company's Intranet at the URL
http://intranet.company.tld/directory as "Not suitable for use" and
an alternative software component has to be found. If the outcome is not
definite, an individual approval request has to be made as outlined in Section
C.V.
========================================
The rationale for the approach suggested here is that every employee who wants
to use a particular software component (e.g. SD, PL or PD) will perform the
approval process (according to -> Annex 6: "Approval process"). Only if the
outcome is not clear, an individual approval request (according to Section C.V
and -> Annex 10: "Approval request") to the LD has to be made. This aims to
reduce the requests that need to be checked individually.
========================================
V Request for approval
If the outcome of the -> Annex 6: "Approval process" is not definite, an
individual approval request must be submitted. To do so, the information and
material given in -> Annex 10: "Approval request" must be submitted to..
########################################
Option 1: ...the LD...
########################################
Option 2: ...the OSCO...
########################################
who holds the approval authority. The approval authority then has to assess whether
the Candidate for Use can be approved. This includes:
- Are the conditions that the license of the Candidate for Use imposes generally
acceptable for the specified use case? License obligations are given in the ->
Annex 1: "OSADL Open Source License Obligations Checklists". If a license of the
Candidate for Use is not part of the Checklists, create a new checklist and
contribute it to the OSADL project.
- Checking for patents
- Checking for license compatibility of the various components of the Candidate
for Use (for details see -> Supplement 3: "License compatibility")
- If a combined work with other FOSS or proprietary software is formed (for
details see -> Supplement 4: "What is a derivative work?"), license
compatibility of relevant licenses of the project needs to be checked. For this,
our company's instance of the -> Annex 4: "OSADL Compatibility Matrix" is to be
consulted. Compatibility of FOSS licenses with each other are displayed in the
upper part of the matrix while compatibility with our company's proprietary
licenses is displayed in the bottom five rows. The final license of the combined
work denotes the row of the matrix. Compatibility between two licenses is
indicated with green color and incompatibility with red color.
Cases that need to be decided individually are indicated with grey color. If an
unclear (grey) compatibility has not been decided or if a license of the Candidate
for Use is not listed in the Compatibility Matrix, the LD has to make an individual
decision. If this decision is generally valid for our company, it must be noted
in our company's instance of the compatibility matrix.
If any obstacles come up during the license check, the Candidate for Use is
entered into our database fully qualified name of database on our Intranet at
the URL http://intranet.company.tld/directory as "Not suitable for use" and an
alternative software component has to be found. If a license is not only
unsuitable for a particular project or use case but can never be approved for
use in our company, it is entered into our company's -> Annex 8: "Deny List".
Alternatively, a proprietary license can be asked for from the copyright
holders (LD).
VI Repository check-in
When a FOSS component is approved for use in our products, it must be entered
into our repository in order to be able to reproduce the build process at a
later time. The following information has to be archived in our Intranet at the
URL http://intranet.company.tld/git/repository (role: PL or SD):
- product name and version
- source code
- (re)build instructions
- description of the environment:
- operating system and version
- installed packages (dependencies)
- environment variables, users, paths and permissions if changed from default
- expected results of the (re)build
- legal information (see Section D):
- outcome of license scan
- license texts
- legal notices
- SPDX file
- documentation:
- where the software came from
- when it was retrieved
- who performed which parts of the approval process
========================================
Storing all information about a project helps making the build process
reproducible. Reproducibility is highly recommended for various reasons,
including license compliance, technical support and security. A good way to do
this is using a version management system such as Git.
========================================
The archived material and instructions must be verified by performing a test
rebuild and comparing the binaries. More background information can be found in
-> Supplement 5: "How to archive and rebuild".
E Creating FOSS License Information
Goals
Any distribution of FOSS requires certain information and documentation material
to be delivered together with the software. This material includes for example
license texts, copyright notices, source code etc. and will be referred to as
"FOSS License Information". What information is required for particular FOSS
components is determined by the respective license. FOSS license obligations can
generally be categorized as
Information obligations: delivering license notices, license texts, copyright
notices, modification notices, warranty disclaimers, acknowledgments ->
Supplement 6: "How to: Acknowledgments"
Disclosure obligations: delivering or offering the complete corresponding source
code (CCSC), build instructions and installation information
Licensing obligations: adapting company documents (e.g. EULA and Terms of Use)
to account for the requirements of FOSS licenses; licensing own development
correctly if a derivative work with software under a copyleft license is created
-> Supplement 1: "What is copyleft?" and -> Annex 2: "Copyleft policy"
Such FOSS License Information has to be gathered or created and archived (see
Section C.VI) which requires a high level of due diligence. To account for
ongoing software development and the integration of new versions of FOSS
components the FOSS License Information must be updated and controlled before
distribution. For the definition of "distribution" with respect to copyright law
see Abbreviations and definitions. For the various ways of how we deliver FOSS
License Information see Section F.
The purpose of this chapter is to list the aspects that need to be considered
for various use cases of FOSS distribution.
###########################################
Option 1: The required FOSS License Information must be collected for all FOSS
that is distributed by us currently and in the future.
###########################################
Option 2: "Legacy arrangement": The required FOSS License Information must
only be collected for any new FOSS that enters the company.
###########################################
I Use Case 1: Internal use
Internal use does not require to provide FOSS License Information since all
known FOSS licenses do not trigger license obligations for mere internal use.
Internal use is the use of FOSS within the same legal entity (e.g. GmbH, Ltd,
AG). Some situations are similar to internal use and have to be treated as
follows:
1. Affiliates
The legal situation is unclear about whether or not providing affiliates (see
definition in Abbreviations and definitions) with copies of FOSS is considered
as distribution. Our standpoint is (role: PL):
########################################
Option 1: We consider the exchange of FOSS among affiliates as mere internal use
and FOSS License Information is provided only on request.
########################################
Option 2: We consider the exchange of FOSS among affiliates as distribution and
FOSS License Information is provided as described in the use cases below.
########################################
Option 3: We use a group-wide repository with access to the source code of all
affiliates.
########################################
========================================
Rationale for option 3: A common repository is in some cases the easiest way to
reduce risks with regard to compliance with FOSS license obligations without
creating administrative overhead.
========================================
2. Switching from internal use to distribution
In case that we consider distributing FOSS that was initially only used
internally (e.g. development tools) we have to start the full process for FOSS
license compliance as described in this policy. (role: PL)
3. Merger and acquisition of companies formerly part of the group
In case any action is taken that may result in a situation where an affiliate
ceases to be an affiliate or a company division is transferred to another
company we have to ensure that all FOSS that was given to such affiliate or
company division is accompanied by the respective FOSS License Information and
the CCSC and that all other companies of the group have been provided with the
respective FOSS License Information and the CCSC of software previously received
from that affiliate or company division. Any Due Diligence requires to provide
the BOM and the source code of all FOSS that is used by the entity that is
concerned by the Merger and acquisition. (role: LD, OSCO)
4. Outsourcing
Any transfer of internal software to an outsourcing provider needs prior legal
assessment whether or not FOSS license obligations apply. (role: LD, PL, OSCO)
5. External Development
Ordering individual software development by external providers and conveying
software to them for this purpose is usually not considered distribution if used
as an "extended workbench". Please clarify with LD if this applies in any