Recent changes to Distribution

Distribution modified by Ingo

Ingo — Fri, 23 Mar 2018 22:44:05 -0000

--- v10
+++ v11
@@ -2,9 +2,9 @@

 [[include ref=IndexMain]]

-Even when we start programming on a totally new piece of software, we might quickly get in contact with 3rd party licenses, which are often Open Source licenses. We might face this issue already during development, but latest when we prepare the distribution of our software.
+Even when we start programming on a totally new piece of software, we might quickly get in contact with 3rd party licenses, which are often open source licenses. We might face this issue already during development, but latest when we prepare the distribution of our software.

-Because there we need to decide how we can prepare a package, containing all the dependencies to libraries or even programming language interpreters (e.g. Python), which the user might need to use our software.
+Because then we need to decide how we can prepare a package, containing all the dependencies to libraries or even programming language interpreters (e.g. Python), which the user might need to use our software.

 Even if licenses are very often standardized, you are recommended to read through the terms of every project that you will redistribute before doing so. The following shows the requirements of the most popular open source licenses:

@@ -49,12 +49,12 @@
 As a developer, it is important to know what a 3rd part licensed product allows me to do with it, before I integrates it into my project. There are several ways how the systems can interface with each other. But if we want to retain our freedom to choose our own license, we can't use every of them with every license.

 * Binary interface
-  * Call another binary
-  * ‎Interface via IPC
-  * ‎Use an interpreter
+    * Call another binary
+    * ‎Interface via IPC
+    * ‎Use an interpreter
 * Linking
-  * Dynamic
-  * ‎Static
+    * Dynamic
+    * ‎Static

  ...        |  binary interface | dynamic linking | static linking
 --------|--------------------------|--------------------------|---------------------
@@ -86,7 +86,7 @@
 * ‎in an about dialog of a software
 * ‎in a user manual

-## Software bill of material
+## Software bill of material (BOM)
 The american "Cyber Supply Chain Management and Transparency Act of 2014" forced all american software suppliers to provide a bill of material for their software. This typically included also a list of all licenses, which are involved. 

 Even if this act is pending now, it is still a good idea to keep such a list for every released software package. Even if you include already the license information in your installer, documentation, ... . Because this will make life of redistributers much easier.
@@ -114,6 +114,6 @@
 * ‎Pack the sources together
 * ‎Include the BOM and source package in every distribution

-This approach tries to be as complaint as possible, and will use the most strict license as a reference for all others. This way you don't need to deal with exceptions.
+This approach tries to be as compliant as possible, and will use the most strict license as a reference for all others. This way you don't need to deal with exceptions.

 There are some licenses which have more requirements (like advertising clauses, etc.). Make sure that you assess and respect them in your distributions.

Distribution modified by Ingo

Ingo — Fri, 23 Mar 2018 15:09:14 -0000

--- v9
+++ v10
@@ -2,9 +2,9 @@

 [[include ref=IndexMain]]

-Even when we start programming on a totally new piece of software, we might quickly get in contact with 3rd party licenses, which are often Open Source licenses. We might face this issue alrady during development, but latest when we prepare the distribution of your software.
+Even when we start programming on a totally new piece of software, we might quickly get in contact with 3rd party licenses, which are often Open Source licenses. We might face this issue already during development, but latest when we prepare the distribution of our software.

-Because there we need to decide how we can prepare a package containing all the dependencies to libraries or even programming language interpreters (e.g. Python), which the user might need to use our software.
+Because there we need to decide how we can prepare a package, containing all the dependencies to libraries or even programming language interpreters (e.g. Python), which the user might need to use our software.

 Even if licenses are very often standardized, you are recommended to read through the terms of every project that you will redistribute before doing so. The following shows the requirements of the most popular open source licenses:

@@ -14,10 +14,10 @@
 * ‎Apache
 * ‎MIT

-The instructions should provide you some ideas about how you can solve the typical problems which you will face. But be aware, that the legal aspects have to be assessed by yourself for every single case.
+The following instructions should provide you some ideas about how you can solve the typical problems which you will face. But be aware, that the legal aspects have to be assessed by yourself in every single case.

 # License owner / License holder
-By default the originator of a software is initially the license owner of the software. He can grant licenses to others. To grant the right to others in a structured way, many license owners are putting the software under a standard license.
+By default the originator of a software is initially the license owner of the software. He can grant licenses to others and even allow others to redistribute or sublicense the software. To grant the right to others in a structured way, many license owners are putting the software under a standard license, like the ones listed above.

 In this article, we will focus on a special type of those standard licenses, which are typically called "open source licenses".

@@ -28,9 +28,9 @@

 On the other hand, if we just installed the software on a server, and provide web services to others, we will not distribute but just use it.

-So, in one case, we are a user, in the other case we are a distributer. In both cases we will become a license holder. But in case we are distributing, we need the special right to issue licemses to others.
+So, in one case, we are a user, in the other case we are a distributer. In both cases we will become a license holder. But in case we are distributing, we need the special right to issue licenses to others.

-Here is an example text, from the apache license, which is granting us the right for sublicensing and distribution:
+Here is an example text, from the apache license, which is granting us the right for sub-licensing and distribution:

 ~~~
 2. Grant of Copyright License. 
@@ -64,12 +64,12 @@
 Apache | allowed | allowed        | allowed
 MIT        | allowed | allowed.       | allowed

-Note, that you can even use combinations, which are marked as "not allowed", but you loose some rights on your software im that case.
+Note, that you can even use combinations, which are marked as "not allowed", but you loose some rights on your software in that case.

 # Comply in distribution
 The actions that needs to be taken, actually depend on the kind of license.

-As the number of licenses are huge, we can't list all here. Here are the actions for the popular licenses, listet above:
+As the number of licenses are huge, we can't list all of them. Here are the actions for the popular licenses, listed above:

  ...    |  include license text | include NOTICE file | publish source code
 -------|------------------------|---------------------------|-----------
@@ -87,23 +87,23 @@
 * ‎in a user manual

 ## Software bill of material
-The american "Cyber Supply Chain Management and Transparency Act of 2014" forced all ammerican originators to provide a bill of material for their software. This typically included also a list of all licenses, which are involved. 
+The american "Cyber Supply Chain Management and Transparency Act of 2014" forced all american software suppliers to provide a bill of material for their software. This typically included also a list of all licenses, which are involved. 

-Even if this act is pending now, it still a good idea to keep such a list for every released software package. Even if you include already the license information in your installer, documentation, ... . Because this will make life of redistributers much easier.
+Even if this act is pending now, it is still a good idea to keep such a list for every released software package. Even if you include already the license information in your installer, documentation, ... . Because this will make life of redistributers much easier.

 So ideally you provide:

 * a list of all 3rd party software
-* the full license texts of this software
+* the full license texts for each software
 * ‎everything whats necessary to rebuild the software

 ## Source Code
-The source code typically needs to be provided on request, and in a form that it can be rebuild. But it is recommended to provide them to every user.
+The source code typically needs to be provided only on request, and in a form that it can be rebuild. But it is recommended to provide them to every user.

 * For open source software it can be published as a download
-* ‎For othe software it can be provided as part of the delivery
+* ‎For other software it can be provided as part of the delivery

-This is a way to make it easier for users to redistribute software.
+This way we make it easier for users of our software to redistribute it. As they can include our BOM, and our sources into their BOM and their sources.

 # Summary
 If you use open source software, and you want to safely redistribute it, the following is a good practice:
@@ -116,4 +116,4 @@

 This approach tries to be as complaint as possible, and will use the most strict license as a reference for all others. This way you don't need to deal with exceptions.

-There are some licenses which have more requirements (like advertising clauses), but those need to be assessed case by case.
+There are some licenses which have more requirements (like advertising clauses, etc.). Make sure that you assess and respect them in your distributions.

Distribution modified by Ingo

Ingo — Fri, 23 Mar 2018 07:33:40 -0000

--- v8
+++ v9
@@ -98,7 +98,7 @@
 * ‎everything whats necessary to rebuild the software

 ## Source Code
-The source code typically needs to be provided on request, and in an form that it can be rebuild. But it is recommended to provide them to every user.
+The source code typically needs to be provided on request, and in a form that it can be rebuild. But it is recommended to provide them to every user.

 * For open source software it can be published as a download
 * ‎For othe software it can be provided as part of the delivery

Distribution modified by Ingo

Ingo — Fri, 23 Mar 2018 07:32:34 -0000

--- v7
+++ v8
@@ -92,6 +92,7 @@
 Even if this act is pending now, it still a good idea to keep such a list for every released software package. Even if you include already the license information in your installer, documentation, ... . Because this will make life of redistributers much easier.

 So ideally you provide:
+
 * a list of all 3rd party software
 * the full license texts of this software
 * ‎everything whats necessary to rebuild the software

Distribution modified by Ingo

Ingo — Fri, 23 Mar 2018 07:28:52 -0000

--- v6
+++ v7
@@ -33,7 +33,14 @@
 Here is an example text, from the apache license, which is granting us the right for sublicensing and distribution:

 ~~~
-2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.
+2. Grant of Copyright License. 
+Subject to the terms and conditions of this License, each
+Contributor hereby grants to You a perpetual, worldwide,
+non-exclusive, no-charge, royalty-free, irrevocable
+copyright license to reproduce, prepare Derivative Works
+of, publicly display, publicly perform, sublicense, and
+distribute the Work and such Derivative Works in Source
+or Object form.
 ~~~

 As soon as you start to become a distributor, the below requirements will start to apply to you.

Distribution modified by Ingo

Ingo — Fri, 23 Mar 2018 07:27:45 -0000

--- v5
+++ v6
@@ -64,7 +64,7 @@

 As the number of licenses are huge, we can't list all here. Here are the actions for the popular licenses, listet above:

- ...    |  include license text | include NOTICE file | punlish source code
+ ...    |  include license text | include NOTICE file | publish source code
 -------|------------------------|---------------------------|-----------
 MIT        | yes | no  | no
 Apache | yes | yes | no

Distribution modified by Ingo

Ingo — Fri, 23 Mar 2018 07:14:55 -0000

--- v4
+++ v5
@@ -1,3 +1,7 @@
+[TOC]
+
+[[include ref=IndexMain]]
+
 Even when we start programming on a totally new piece of software, we might quickly get in contact with 3rd party licenses, which are often Open Source licenses. We might face this issue alrady during development, but latest when we prepare the distribution of your software.

 Because there we need to decide how we can prepare a package containing all the dependencies to libraries or even programming language interpreters (e.g. Python), which the user might need to use our software.

Distribution modified by Ingo

Ingo — Fri, 23 Mar 2018 07:14:02 -0000

--- v3
+++ v4
@@ -60,7 +60,7 @@

 As the number of licenses are huge, we can't list all here. Here are the actions for the popular licenses, listet above:

-        |  include license text | include NOTICE file | punlish source code
+ ...    |  include license text | include NOTICE file | punlish source code
 -------|------------------------|---------------------------|-----------
 MIT        | yes | no  | no
 Apache | yes | yes | no

Distribution modified by Ingo

Ingo — Fri, 23 Mar 2018 07:13:44 -0000

--- v2
+++ v3
@@ -45,7 +45,7 @@
   * Dynamic
   * ‎Static

-         |  binary interface | dynamic linking | static linking
+ ...        |  binary interface | dynamic linking | static linking
 --------|--------------------------|--------------------------|---------------------
 GPL.       | allowed | not allowed | not allowed
 LGPL.     | allowed | allowed        | not allowed

Distribution modified by Ingo

Ingo — Fri, 23 Mar 2018 07:12:59 -0000

--- v1
+++ v2
@@ -1,4 +1,3 @@
-
 Even when we start programming on a totally new piece of software, we might quickly get in contact with 3rd party licenses, which are often Open Source licenses. We might face this issue alrady during development, but latest when we prepare the distribution of your software.

 Because there we need to decide how we can prepare a package containing all the dependencies to libraries or even programming language interpreters (e.g. Python), which the user might need to use our software.
@@ -47,7 +46,7 @@
   * ‎Static

          |  binary interface | dynamic linking | static linking
-================================================
+--------|--------------------------|--------------------------|---------------------
 GPL.       | allowed | not allowed | not allowed
 LGPL.     | allowed | allowed        | not allowed
 BSD.       | allowed | allowed.       | allowed
@@ -62,7 +61,7 @@
 As the number of licenses are huge, we can't list all here. Here are the actions for the popular licenses, listet above:

         |  include license text | include NOTICE file | punlish source code
-================================================
+-------|------------------------|---------------------------|-----------
 MIT        | yes | no  | no
 Apache | yes | yes | no
 BSD        | yes | no  | no