Solution

• Use the Bootstrap JavaScript library as delivered by bootScore
• Use the JavaScript libraries as delivered by WordPress
• Create a table containing the JavaScript compliance information
• For each JavaScript library delivered by bootScore or WordPress create a respective row in your JS table.
• Embed this table into your Open Source Compliance Page
• Make this Open Source Compliance Page accessible by the footer of your pages

Background

bootSCore contains some JS components. For example, its own unfolded JavaScript libraries¹ — implicitly licensed under the MIT license but without any explicit licensing statement — and the minified Bootstrap JavaScript library² — explicitly licensed under the MIT by a respective licensing statement. But none of them contain the license text itself.

Also, WordPress brings with it some own and some minified 3rd party JavaScript libraries³, like the jQuery library⁴ that is licensed under the MIT and contains a respective licensing statement, but does not cover the license text itself. Regardless, of whom the site owner has got these libs — from bootScore or WordPress -, eventually it is she who has to fulfill the license requirements because it is her system that distributes the JavaScript libraries to her readers.

But what is actually the challenge?

Like the JavaScript libraries of Bootstrap and jQuery, most JS libraries are MIT licensed. It requires that the copyright line and the license text are distributed together with the open-source program. “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.“⁵

For (L|A)GPL-licensed JavaScript libraries it is nearly the same. These licenses permit the distribution of the source code “provided that one conspicuously and appropriately publishes on each copy an appropriate copyright notice and disclaimer of warranty […] and gives any other recipients of the Program a copy of this License along with the Program”.⁶

So, we see a contradiction between the claim of the licenses and the everyday practice. On the one side, a browser not only loads down the page text (HTML) but also the JavaScript library. This download distributes the code and hence triggers the necessity to fulfill the open-source license requirements. On the other side, usually, the compressed libraries — although as a package often offered by the authors — no longer contain the required license information: the smaller the libs, the faster the machine can display the site using that libs.

As site owners, we have two options to deal with this challenge. Either we subsequently (and (semi) manually) heal the packages we implicitly have taken over by using WordPress and bootScore. Or we use them as we’ve got them. It’s clear: Healing would imply that we redo that job whenever we update WordPress or bootScore. So, we tend to go the other way.

The solution is this:

Whenever developers decide to distribute minified JavaScript libraries, they also assume that their ‘customers’ use their work in that version. That is a reasonable assumption. So, we may derive that they implicitly permit that kind of use even if it violated the license they’ve chosen. Nevertheless, we should offer our users another option to get the required information. A substitute for bundling the license text, the copyright information, etc. with the JavaScript libraries themselves. However, we must take care only to include the minified JavaScript libraries the developers themselves have provided. In the case of the Bootstrap-JS-Lib in bootScore and the Jquery-JS-Lib etc. in WordPress, we may assume that they did so.

If we apply this process to our 3rd. party JS libraries, we have a strong argument for our position in case of a legal dispute — I’ve never heard of one — and we’re in good company: Even the FSF is proposing to do so.⁷ And the FSF really doesn’t have a reputation for taking license compliance lightly.

And in what way is this …

… part of the overarching topic FOSS Compliance? For fulfilling the requirements of FOSS licenses, we have to consider specific individual cases as well as side effects — for software, pictures, or documents. We should unhide trends and write guidelines. Above all, however, we must drive forward the automation of license fulfillment, make our licensing knowledge freely available, cast it into smaller tools, and bring it into larger systems: Because FOSS thrives on freedom through license fulfillment, large and small. That’s what also this article is about.

1. cf. ./bootscore/js/theme.js
2. cf. ./bootscore/js/lib/bootstrap.bundle.min.js
3. cf. https://codex.wordpress.org/Javascript_Reference respectively ./wp-includes/js
4. cf. wp-includes/js/jquery/
5. cf. MIT License
6. pars pro toto cf. GPL‑2.0. Additionally, the (A)GPL requires that we license our code that uses the (A)GPL-licensed library, etc. also under the (A)GPL (copyleft effect). But that’s not the point in this context.
7. cf. https://www.gnu.org/licenses/javascript-labels.html, https://www.gnu.org/licenses/javascript-labels-rationale.html, and https://www.iusmentis.com/computerprograms/opensourcesoftware/license-notices-web-applications

The post Using JavaScript Compliantly appeared first on FODINA 4 FOSS.

Solution

• First, use image databases whose pictures are released under the terms of the CC0 license.¹ E.g. pxhere² or openclipart.³
• Then evaluate image databases whose pictures have been published under any different Creative Commons license. E.g. Wikimedia⁴, flicker.com/creativecommons or piqs.de
• But avoid images that are licensed under a CC-??-NC-??⁵ license.⁶
• And meticulously fulfill the other conditions, such as attribution. A good place to do that is a page with image credits.
• Finally, be careful if you use an image database that distributes its images under its own license, which is equivalent to a CC0 license, but excludes certain uses after all.⁷. E.g. pexel⁸, unsplash⁹, or pixabay¹⁰)
• Avoid, if possible, image databases that mix commercial paid images with free.¹¹ E.g. freephotos or the nounproject
• Definitely avoid meta image databases in any case.¹²

Background

On the first attempt, it seems easy. After all, most of the time, the author will only want to ‘illustrate’ her posts. But if she has linked a web store or consulting offer to her site, she earns money indirectly with the images. And thus she uses the images commercially. So again the question is, what can she do?

I have outlined my way above. Two additions to this:

• When it comes to ‘logos’, I search the web presence of the logo owners. Often they tell us explicitly what we can and cannot do with their logos. And this is even true for non-profit organizations, like the OSI((for logo usage cf. https://opensource.org/logo-usage-guidelines/)) or those of the Gimp((for logo usage cf. https://github.com/GNOME/gimp/blob/master/docs/Wilber.xcf.gz.README)).
• When it comes to what is pictured, I follow two rules of thumb:
  • Be careful with people and products depicted — they’d rather not.
  • Caution with unknown buildings

And in what way is this …

… part of the overarching topic FOSS Compliance? For fulfilling the requirements of FOSS licenses, we have to consider specific individual cases as well as side effects — for software, pictures, or documents. We should unhide trends and write guidelines. Above all, however, we must drive forward the automation of license fulfillment, make our licensing knowledge freely available, cast it into smaller tools, and bring it into larger systems: Because FOSS thrives on freedom through license fulfillment, large and small. That’s what also this article is about.

1. We’re allowed to use those for no consideration, after all.
2. for licensing see https://pxhere.com/en/license
3. for licensing cf. https://openclipart.org/faq
4. for licensing cf. https://commons.wikimedia.org/wiki/Commons:Licensing/de
5. for the layer model of CC licenses, see https://creativecommons.org/licenses/
6. Because legally even the simplest blog can still be interpreted as a commercial enterprise.
7. Challengingly, these databases often allow commercial use, but at the same time prohibit the sale of the images, even in print, or their incorporation into other databases
8. for licensing cf. https://www.pexels.com/license/
9. for licensing cf. https://unsplash.com/license
10. for licensing cf. https://pixabay.com/de/service/license/
11. Too great the risk that you pick a non-free image.
12. What exactly applies here is very hard to track there.

The post Getting Nice Pictures — Where From, If Not Steal? appeared first on FODINA 4 FOSS.

For example, sometimes I have to say where I got the image, who its photographer is, and what license it is under. The right place to fulfill such conditions is a page for image credits¹:

Solution

A Table For Image Credits

• Create a page ‘Image Credits’ and include it on your site like your imprint
• Install the plugin TablePress.
• Create a table with the 4 columns ‘Picture’, ‘Download & Licensing’, ‘License’, and ‘Attribution’.
• Include this table in your page Image Credits by using the TablePress shortcode.

A New Image Reference

• Add a new row to the image reference table.
• Concerning the first column ‘IMAGE’
  • open the media library, click on the new image and remember its ID, which is displayed in the browser URL.
  • enter the already-known short code wrong image data.
• In the second column, link an appropriate text to the same image in the database. If the target page does not contain a licensing statement, add a second link in the same column that leads to the licensing statement of the picture database.
• In the third column, link the license name to the license text, preferably in the version from the image database.
• In the fourth column, enter all the information that the license requires.

Background

First things first: The WordPress plugin TablePress is actively maintained and is — according to the file readme.txt — GPL‑2.0 licensed. So this is a ‘flawless’ piece of Open-Source software.

Finally, the more complex aspects: Why do we need an image credit at all? Formally, we don’t! We just need to fulfill in some way every requirement of the license that has been linked to the image we are using. But the license compliance itself is non-negotiable for the sincere user: either she respects the terms of the license, or she does not use the image.²

That’s why I make things simple for myself: I enter every image into my table for image credits according to the marked pattern. Even those, where I am free to say nothing — like with PxHere pictures. And if I follow the pattern, nothing slips through my hands either. Hopefully.

To that end, I’ve written myself a set of short codes that make it a snap to add a new image to the table. I will gladly pass on these codes on request.

And how does this …

… support our migration to bootScore? Well, once started with improving the image handling, a web designer will also notice the blurred ‘featured images’ of bootScore. She will try and refine solutions. And she may also tackle them with new HTML‑5 techniques. Because with that, a fancier image strategy combined with an integrated license fulfillment process and its own logo will really make sense. However, pictures bring colors to reading. So they should be integrated into a customized color concept. This post also contributes something to this topic.

1. BTW: In the European legal space, there is no such thing as ‘public domain’. But we can usually use the images published in this way in America
2. I have already written about image trolls and their ‘business model’

The post A Picture Credit Page? Really? appeared first on FODINA 4 FOSS.

But what happens with original European works in the American legal area? Without claiming authorship, they probably fall into the public domain. So an author is well advised to mark her European publications with a copyright notice, even if this seems superfluous from the European viewpoint.¹ And so she should keep it with her Internet sites.

Solution

• Add the following line to the file scss/_bscore_custom.scss of your child theme:

.bootscore-copyright {display: none;}

• Add a text box to the new widget Footer Info arising under Appearance/Widgets.
• Enter a text line starting with ‘©’ YEAR Author-Name’.

Background

So, eventually, there is the question of location and copyright sign in the line. In this case, the form is rather secondary: you are not obliged to use the HTML tag $copy; for ©. You can also use images like or — very old-fashioned — the string (C). You also do not need to add a town or a country. In case of dispute, you only have to prove that You are You. That’s why I often add my place of residence and my nation. Does that work? No idea. I’m not a lawyer and I don’t give advice; I just tell. And I have never been involved in a dispute.

And how does this …

… support our migration to bootScore? Well, if a web designer must abandon her current WordPress theme, she needs a replacement. A free ‘off-the-shelf’ theme, she probably wants to personalize. First a bit cosmetically, then in terms of the gray value of her pages, multilingualism and internal reference techniques and linking. Finally, she perhaps enables special footers, a secondary menu or a copyright notice before checking the SEO features of the selected theme. This is a way that this post supports too.

1. Therefore the FSF says that the free GNU software is first put under copyright and then becomes copyleft software by means of the GPL.

The post A Copyright Line As Feeding For Your Footer appeared first on FODINA 4 FOSS.

For 6 years, the Bitkom Open Source Guide 2.0 was a tutorial for the appropriate use of open-source software. It was a benchmark for German companies. But it has aged over time, naturally. Good that Bitkom and its ‘Open Source’ working group have taken up the topic again: In June 2022, there was officially released an expanded and refined Bitkom Open Source Guide 3.0, — again intended to be a manual and a benchmark for companies

The one amazing thing is that with this guide, Bitkom has published a ‘handout’ under a (kind of) open-source license for the first time, that is to say: under a Creative Commons license (CC BY-ND 3.0 DE). Apparently, the idea of ​​a freely accessible service is also coming to the fore at Bitkom. That gives his voice even more weight. But it is understandable that Bitkom does not allow third parties to modify the work (ND = Non Derivation). It wants to preserve the gained quality and reliability. However, by using this CC license Bitkom permits any other type of use by third parties, including commercial use. And in the not-too-distant future, Bitkom will certainly bring itself to make the sources generally accessible, not just in a ‘closed’ GitHub organization.

The second astonishing thing is related to this. Bitkom has allowed its authors to organize themselves via and with GitHub. Anyone could take part. Anyone could become a member of the organization and thus access the GitHub repository containing the (partial) results. Bitkom has — again, for the first time and successfully — developed a book using the methods of open-source software development. The authors wrote the chapters of the Bitkom open-source guide in Markdown. Then they checked their modifications into the repository as snippets. Eventually, they combined them as a complete work via incidents and pull requests, although by no means all authors were familiar with GitHub from the beginning. This fact also points beyond itself: Git, GitHub or GitLab can significantly simplify (cross-company) cooperation and collaboration.

And the third amazing thing is the transformation of the content. While the release 2.0 still focused on the legal aspects of use, the new Bitkom Open Source Guide 3.0 is much more comprehensive and balanced: It discusses both, the benefits of FOSS and its development process. It analyzes the integration into business models and corporate strategies, explains open source compliance, and considers the FOSS history — each on almost the same number of pages. The other aspects of FOSS are no longer an appendage of compliance. The BOSL‑3.0 takes the prerequisites for the successful use of open-source software into account generally, without reducing the topic of ‘license compliance’. And each section, with only 10–20 pages, can easily be used to get a quick overview.

What does this mean for companies? Well, for the moment, BOSL‑3.0 is still a German guideline. But with it, the companies get another reliable guideline that external experts have reviewed several times.

And in what way is this …

… part of the overarching topic FOSS Compliance? For fulfilling the requirements of FOSS licenses, we have to consider specific individual cases as well as side effects — for software, pictures, or documents. We should unhide trends and write guidelines. Above all, however, we must drive forward the automation of license fulfillment, make our licensing knowledge freely available, cast it into smaller tools, and bring it into larger systems: Because FOSS thrives on freedom through license fulfillment, large and small. That’s what also this article is about.

The post The Bitkom Open Source Guide 3.0 appeared first on FODINA 4 FOSS.

A presentation without images sucks. Therefore, we are sometimes tempted to take some from the Internet for beautifying our work. There are so many excellent pictures on the World Wide Web. But to legally inserting a foreign picture in one’s own presentation is not that easy. Unfortunately, a new type of troll has emerged recently, the CC-BY image trolls:

If we reuse pictures from the Internet, we have to respect the copyrights of the painters or photographers, just as we have to pay license fees to the patent owners, if we use their techniques, or as we have to fulfill the license requirements if we reuse open-source software. Recently, a new type of troll has emerged, the ‘image troll’.[1] It is good to know how they work and how we can protect ourselves from falling victim to them:

Often, free pictures are released under one of the Creative-Commons Licenses. They are similar to Open-Source Licenses: both follow the principle of ‘Paying by Doing’. Instead of paying for getting the right to use licensed objects, you have to do something. Which rights you get and what you have to do depends on the license. There exists a complex system of creative commons licenses[2], but nearly all of them have a ‘BY’ clause indicating, that you must give the photographer’s name, state the license version, and include a link to download the image and a link to download the license text.[3]

These BY-conditions are — as the discoverer of the image trolls said — “[…] easy to get wrong”.[4] That’s the one ingredient an image troll needs: the easier it is to miss the conditions, the more potential victims he has.

The second ingredient is, that earlier versions of the CC-licenses — like the license CC-BY 2.0 or the license CC-BY 3.0 — contain a “Termination” clause: “This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License.”[5] The meaning of this clause is, that you ‘lose’ the rights of use the moment you fail to fulfill a condition.

One can recognize the explosiveness of such a clause from the fact that the license CC-BY 4.0 also contains a termination clause, but additionally provides the possibility to heal a violation: It says that the terminated rights “[…] reinstates automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation […]”.[6]

As a third ingredient an ‘image troll’ needs a method to automatically find the users of his pictures and to analyze whether he failed to fulfill the requirements. Meanwhile, the internet offers a very well-established technique to automatically search for similar images on the Internet.

The fourth ingredient an ‘image troll’ needs is a legal system granting him large compensation payments for rights violations. The USA has such a legal system.

So, how does an image troll work? He only must create nice pictures and publish them in a well-used image database under any CC license with a termination clause. That becomes his “honeypot”. After that, he must automatically crawl the internet for his picture and analyze whether his ‘customers’ have fulfilled his conditions. If not, he can file a lawsuit against the respective user — his next victim. And at least in the USA, we talk about “statutory damages” up to $150.000.[7]

What can we do to protect ourselves from such attacks, which are legal but at the very least go against the spirit of free software and documents?

• The best method to protect yourself is a) to perfectly know under which terms the pictures you are going to reuse are licensed, and b) to thoroughly fulfill all license requirements.
• A good method is to focus on CC0 licensed pictures[8] as — for example — offered by pxhere.com[9]: a license, which does not require anything, cannot be misused to file a lawsuit against you.
• Another good method is to focus on CC-BY-xyz 4.0 licensed pictures.[A] While you must also thoroughly comply with all licensing requirements, at least you have a chance to iron out your mistakes.
• If you want to use CC-BY-xyz 3.0 or earlier licensed pictures, you should read and apply the license text, not only the summaries, offered by creative commons.

But ignoring image copyrights altogether and just grabbing off the internet what you think you need is the most certain way that any copyright owner will catch you up in a lawsuit. Just as using Open Source Software without fulfilling the license requirements or using patented techniques without paying the license fees.

And in what way is this …

… part of the overarching topic FOSS Compliance? For fulfilling the requirements of FOSS licenses, we have to consider specific individual cases as well as side effects — for software, pictures, or documents. We should unhide trends and write guidelines. Above all, however, we must drive forward the automation of license fulfillment, make our licensing knowledge freely available, cast it into smaller tools, and bring it into larger systems: Because FOSS thrives on freedom through license fulfillment, large and small. That’s what also this article is about.

• [1], [4], [7]: cf. https://doctorow.medium.com/a‑bug-in-early-creative-commons-licenses-has-enabled-a-new-breed-of-superpredator-5f6360713299. This article reports on aspects that Cory Doctorow has outlined first. He talks about ‘copyleft trolls’. But I think that using pictures inadequately is the most dangerous.
• [2]: cf. https://creativecommons.org/about/cclicenses/
• [3]: cf. https://creativecommons.org/licenses/by/4.0/legalcode, Section 3 Attribution. It is worth to know the CC organization provide summaries that condense these conditions to the one sentence ‘Credit must be given to the creator’ (cf. https://creativecommons.org/licenses/by/3.0/). Hence, you are not free to acknowledge the author just as you want.
• [5]: cf. https://creativecommons.org/licenses/by/2.0/legalcode or https://creativecommons.org/licenses/by/3.0/legalcode
• [6]: cf. https://creativecommons.org/licenses/by/4.0/legalcode
• [8]: cf. https://creativecommons.org/publicdomain/zero/1.0/
• [9]: cf. https://pxhere.com/en/license
• [A]: cf. https://creativecommons.org/licenses/by/4.0

The post CC-BY Image Trolls appeared first on FODINA 4 FOSS.

By releasing the Open Source License Compendium and the Open Source Compliance Advisor, Deutsche Telekom has supported Open Source Compliance. At BOSL‑3.0 I was one of the co-authors — on behalf of DT. But DT offers so many complex Open Source based products that it is too expensive to create the necessary Open Source compliance artifacts manually. Thus, DT needs a practically usable automated toolchain. This post discusses a new method (TDOSCA) and a new tool (OSCake) for automating FOSS compliance that DT develops and contributes under the umbrella of the Open Chain Project.

3 simple questions for an Open Source Compliance tool

Without any doubt, there exist already many Open Source compliance tools. The Open-Chain-Reference-Tooling-Work-Group has compiled a list of relevant information:

• Some of the tools can be grouped by the offering organizations like the Apache Foundation, SPDX, Eclipse, or the About Code Initiative.
• Some of the tools are on the sidelines because they have a specific focus or are not really tools or anything else.
• Some other means are services, not tools.

Deutsche Telekom has a simple point of view on FOSS compliance tools. Whenever DT comes across such a tool, it asks: Does this tool deliver the FOSS compliance artifacts DT really needs? If not

• What part of them can it deliver?
• How much work does DT still have to do manually if it used the tool?

DT has a long tradition of evaluating FOSS compliance tools. Its employees met excellent tools and brilliant experts. They often thought they could essentially support DT. But in the end, DT mostly felt like they didn’t really understand what DT needed (and still needs). To clarify this point: Whoever delivers large lists of (found) FOSS items and says that a company now has to discuss each entry of the list with its legal department does not really help the company.

Nevertheless, DT has to deal with such large lists, today known as ‘Software Bill of Material’. Open-Source-Compliance is not a question of pleasure or displeasure. Either one uses Open-Source software and fulfills the respective requirements, or one does not use the software. Therefore DT can’t wait anymore. The complexity of its products enforces DT to advance the automation of open source compliance actively. For solving that issue, it doesn’t want to start the next greenfield approach but to participate in existing projects — entirely in the spirit of the open-source idea.

Setting up the Test-Driven environment

DT’s first step was to improve its own communication: it wants to clarify in a better way what it really needs — from the point of view of a large company dealing with many complex software stacks. Thus, DT tried to apply the idea of ‘Test-Driven Software Development’ to the development of compliance tools:

• On the one side, these test cases should contain really usable software, licensing statements, and dependency information — in a way that real projects use.
• On the other side, these test cases should contain those compliance artifacts that would allow the distribution of the software compliantly if added to the respective software package.

Additionally, DT thinks:

• Existing open-source projects are mostly too complex for being used as reference material.
• Artificially generated software could better focus on essential compliance issues.
• The reference software should functionally be a simple hello world program.
• And it should ‘implement’ sophisticated compliance issues in a way that real open-source projects use.

By using such test cases, DT wants to enable the community, the tools, and the companies to verify,

• with which compliance traps a tool can already successfully deal,
• which artifacts a tool already deliver (and which not),
• where there are still some open issues, and
• where deviating results are only a matter of interpretation.

The ‘Hello World’ Open Source Compliance Test Cases

All TDOSCA-test-cases are offered under the umbrella of the GitHub organization Open-Source-Compliance and clustered by the prefix tdosca. The README of main repository tdosca describes the general approach: one may expect that each test case offers the same structure. For example, take a look at tdosca-tc06-plainhw:

• On the top level, a test case-specific README describes its intention.
• In the directory input-sources, you find a compilable software package
  • that contains the licensing information just as real open source projects do
  • and can be installed by a standard technique (in this case: java + maven).
• On the top level, a compliance-trap file describes the challenges that are implemented in the source and should be managed by the tools.
• And in the directory reference-compliance-artifacts, one can find the compliance artifacts that a tool should deliver:
  • a BOM file listing the (sub) components of the package
  • a list of the packages that must be preinstalled on the target host
  • the Open Source Compliance File, which — added to the package — establishes a compliantly distributable open-source software package.

The test cases themselves are stored in the respective repositories tdosca-tc01 … tdosca-tc0n

The core reference entity of a test case is its Open Source Compliance File: Such a file shall contain all compliance artifacts so that a package is compliantly distributed if it is bundled with the respective OSCF. This idea was inspired by the file that CISCO adds to its jabber client: https://www.cisco.com/c/dam/en_us/about/doing_business/open_source/ docs/CiscoJabberforWindows-128–1578365187.pdf. This file is not completely sufficient. But it gives a good idea, how to deal with this issue. In the TDOSCA context, the meaning of such an Open Source Compliance File can be explained by looking at the OSCF of the 6th test case.

A summary and an addendum:

In general each TDOSCA test-case implements the following structure:

The TDOSCA initiative — hosted under the umbrella of OpenChain and the OpenChain Reference Tooling Work Group — could be a good method for the community to evaluate its tools by such test cases.

But if DT followed this approach purely, DT would easily slip into the role of a police officer or a judge. That’s not what DT wants to be; it wants to be a supportive part of the community. For that purpose, DT has already evaluated existing tools on the base of the TDOSCA test cases, has made some experiences, and decided on some consequences:

Applying the approach to ORT

First DT decided to use ORT — the Open Source Review Toolkit — for creating a break-through tool-chain-version which takes the test-case input and derives the compliance output:

In the picture you see

• the five components, ORT mentions in its README,
• the data they generate, and
• how they use the output of their predecessors.

Using this outline, we can now exemplify some of …

… and gaining experiences with ORT

• First, DT noticed that it could not evaluate even the first and most simple test case using the GNU Autotools
• Second, DT had to learn that in cooperation with Gradle, ORT — for the moment — can not decide which of the found licenses is the default license.
• Third, DT noticed that the standard templates included in ORT reader follow the principle of over fulfillment, the principle of over-fulfilling the license requirements.

What does the last point mean? If you have a software project completely and exclusively licensed under the MIT license, then it is sufficient to bundle the license text and its embedded copyright line with the package for making it compliantly distributable. Tools that follow the principle of over-fulfillment would also add the artifacts created based on the GPL requirements, such as ‘all copyright headers of all files’ and so on.

Many approaches apply the principle of over-fulfillment — and use a problematic strategy:

• On the one hand, the distributors must correctly create the required compliance artifacts. If they create them incorrectly, they have to expect that someone will approach them about it.
• On the other hand, the surplus compliance artifacts could overwrite or lever out the essential artifacts.

Fortunately, ORT follows the design principle to make everything configurable and extendable, which allows DT to adapt its needs in three ways:

Improving ORT

• Deutsche Telekom plans to implement and give back to ORT an evaluation technique of the Autotools scripts.
• It will define, implement, and give upstream to ORT a generally usable strategy to determine the default license of a package.

Extending the case structure

• DT will define more test cases according to the multi-dimensional room: complexity, programming language, and dependency manager.

Defining an Open Source Compliance artifact knowledge engine

• DT develops an intelligent component into which it embeds the Open Source License Compliance knowledge in a declarative manner by
  • adding respective writers into ORT
  • adding a FOSS compliance domain-specific language realized on the base of Eclipse, XText
  • adding a respective compliance artifact composer based on XTend.

DT names this new component of and for Open Source Compliance Chains OSCake — the Open Source Compliance artifact knowledge engine -, and develops it under the terms of the Eclipse Public License 2.0

OSCake shall close the gaps evoked by Open Source scanning tools that follow the principle of compliance over-fulfillment. It will take Open Source Compliance collections and deliver Open Source Compliance Files that really fit the requirements of the involved Open Source Licenses and their contexts. OSCake will become an agnostic compliance knowledge engine; it will not depend on a specific scanning tool but only on an error-tolerant input format. For being able to offer these features, OSCake will have an internal structure:

Fazit

TDOSCA and OSCake establish a promising goal set for the company itself as well as for the community and other commercial approaches:

• DT indeed wants to set up a practically usable FOSS compliance toolchain that automatically generates the compliance artifacts we need.
• DT wants to reduce the manual work as far as possible.
• And DT develops this chain (and its components) under the control of TDOSCA: the project to develop Test-Driven Open Source Compliance Artifact Gatherers and Compilers — including our own tool ‘OSCake’.

And it is an outstanding aspect that DT is going to develop both parts under the umbrella of OpenChain and its Open Chain Reference Tooling Workgroup.

And in what way is this …

… part of the overarching topic FOSS Compliance? For fulfilling the requirements of FOSS licenses, we have to consider specific individual cases as well as side effects — for software, pictures, or documents. We should unhide trends and write guidelines. Above all, however, we must drive forward the automation of license fulfillment, make our licensing knowledge freely available, cast it into smaller tools, and bring it into larger systems: Because FOSS thrives on freedom through license fulfillment, large and small. That’s what also this article is about.

• OSLiC sources: https://github.com/telekom/oslic
• OSLiC homepage: http://telekom.github.io/oslic/
• OSLiC version 1.0.2: https://telekom.github.io/oslic/releases/oslic.pdf
• OSCAd sources: https://github.com/telekom/oscad
• OSCAd homepage: https://telekom.github.io/oscad/
• OSCAd instance: http://oscad.fodina.de/
• OpenChain homepage: https://www.openchainproject.org/
• Respective Linux Foundation project page: https://www.linuxfoundation.org/projects/security-compliance/
• Introduction into the Open Chain Reference Tooling Work Group: https://www.openchainproject.org/news/2020/03/15/openchain-reference-tooling-work-group-in-2020
• Open Chain Reference Tooling Work Group homepage: http://oss-compliance-tooling.org/
• Existing Open Source license compliance tools: http://oss-compliance-tooling.org/Tooling-Landscape/OSS-Based-License-Compliance-Tools/
• Open-source Review Toolkit: https://github.com/oss-review-toolkit/ort
• Test Driven Open Source Compliance Initiative: https://github.com/Open-Source-Compliance/tdosca
• Open Source Compliance artifact knowledge engine: https://github.com/Open-Source-Compliance/OSCake
• Open Compliance Summit 2020: https://events.linuxfoundation.org/open-compliance-summit/program/schedule/

The post Automating FOSS Compliance: TDOSCA & OSCake appeared first on FODINA 4 FOSS.

• Some people say the CWA is not open-source software because it uses the (closed) API offered by Google or Apple. But the government has released the system under the terms of an officially approved open-source software license (Apache v2). And even Richard Stallmann published his Emacs as free software, although it used the underlying Unix system libs.
• Others state that one cannot trust the Corona Warn App because it nevertheless can secretly transmit protected data. But the principles of openness and voluntarism prevent this abuse. You can verify that the code does not do anything forbidden or undesirable — by analyzing the publicly accessible code. Additionally, no one enforces us to use this app: you decide whether you install the app or not, you decide whether you make your illness known or not, and you decide whether you call for notifications of illness or not.
• Finally, some assume that the corona warn app system later secretly will become a general tool of the Government to monitor the contacts of its citizens. But for doing so, the Governments must at least publish the apps themselves in the official Google and Apple stores. Thus, the skeptics can them with the binaries compiled on the base of the code in the publicly accessible repository: If there is a (big) difference, the reviewer would notice, that there is something strange

Hence, we may trust this work, and we should use it for preventing us from overloading our health system.

And in what way is this …

… part of the overarching topic FOSS ? Well, my professional life is dominated by free software and open source compliance. But sometimes I find more offbeat tools that are still worth sharing — at least with my forgetful future ‘me’. To whom I like to recommend — for example — suitable, advanced editors. Or ancient preparatory work. Or some free music editors for compositoy work. But with some posts, I just want to remind my later ‘me’ of attitudes, points of view, and attitudes. So that I don’t fall behind myself. That’s what it’s about in here too.

The post The Corona Warn App as Open Source Software appeared first on FODINA 4 FOSS.

This article talks about some side effects. It explains why it is a bit suboptimal to distribute LilyPond snippets under the terms of the GPL. Even, if one loves to create, share, and/or use free and open-source software. And believe me, I do so. The side effect is simple. Including GPL-licensed LilyPond snippets enforce you to distribute your own work under the terms of the GPL:

Let us start with some hopefully indisputable points: The program ‘LilyPond’ is licensed under the GPLv3 [⇒ 1]. It wants “[…] (to create) beautiful sheet music”. [⇒ 2] For that purpose, the program LilyPond takes a file containing a music sheet represented in and by the LilyPond language. And based on this input file, LilyPond compiles the output:

LilyPond is a compiled system: it is run on a text file describing the music. The resulting output is viewed on-screen or printed. In some ways, LilyPond is more similar to a programming language than graphical score editing software. [⇒ 3]

Hence, the language LilyPond pretends for writing a music sheet is a programming language executed by the LilyPond interpreter. Writing music in and by LilyPond is software programming. In other words: LilyPond is a programming system like PHP‑, PYTHON‑, or BASH. The interpreter (the PHP‑, python‑, bash‑, or LilyPond engine) takes its input code and creates the corresponding, but new output. Such (open source based) engines are often licensed under different licenses than the code they execute. For example, PHP is licensed under the PHP license. But there exist many PHP programs licensed under the MIT, the BSD, or even under the LGPL license.

This holds also true for LilyPond — as the LilyPond repository proves. This repository contains … [⇒ 4]

• a file named COPYING which contains the text of the GPLv3 license.
• a file named LICENSE, stating that LilyPond falls under the terms of the GPLv3.
• a file named LICENSE.Documentation stating that all document input falls under the GNU Free Documentation License except the files in the directory snippets. They are public domain.

From these facts we can conclude:

1. LilyPond itself is licensed under the terms of the GPL: You may run, study, modify and redistribute it. But in case of distributing a (modified) instance, you have also to distribute the License text, a list of the copyright owners, the source code and some other compliance artifacts — namely together with your instance.
2. But the GPLv3 does not say anywhere, that the input files (e.g. the snippets, written in the LilyPond language) or the output files (pdf, png, …) have also to be distributed under the terms of GPLv3.
3. Additionally, the LilyPond copyright holders DO NOT require anywhere that the input and output files also have to be released under the GPL (what they could have done, as for the example some code generators have done).
4. Moreover, the LilyPond copyright owners know and accept that the LilyPond input (and output) files are not automatically be covered by the ‘strong copyleft effect’ of the GPL. Otherwise, they could not have embedded a set of snippets into their repository while stating that these are part of the public domain.

Hence, we may generally conclude that — from the viewpoint of LilyPond and its developers — the LilyPond input and output files may be licensed under other licenses than the interpreting program itself.

Consequently, we now should ask, which license the LilyPond snippet authors should choose. We see two role models:

1. The first role model is the LilyPond Snippets Repository which hosts reusable snippets. In accordance to this LSR, all these snippets are public domain. [⇒ 5]
2. The second model is the Open LilyPond Library. [⇒ 6] Its homepage is mostly a site skeleton. It only says that “openLilyLib is an enhancement library for the GNU LilyPond music notation software”. [⇒ 7 ] But if one takes a look at the GitHub repositories collected under openlilylib [⇒ 6], one finds the main repository “oll-core”, which introduces itself as “the heart of openLilyLib” and promises to provide common functionality that any ‘openLilyLib’ package uses. [⇒ 8]

Although this repository does not contain any file named COPYING (containing the GPL) or a file LICENSE or LICENSING, the header of the central source code file ‘package.ily’ clearly states, that “[…] openLilyLib is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License”. [⇒ 9] This statement describes the will of developers (copyright owners) that each user of openlilylib has to respect.

But unfortunately the role model ‘GPLv3 licensed LilyPond snippets’ has some very unattractive consequences:

We know already, that the LilyPond snippet code itself is software. The command #include “ABC.ly” links a snippet into one’s own LilyPond music code. Or you copy the content of a snippet into your music code literally. Both modes of use trigger the strong copyleft effect of the GPL (v3 and v2): if my code functionally calls a method offered by a GPL-licensed snippet or if my code contains the GPL-licensed snippet literally, then my work depends on this GPL-licensed prework and I have to distribute my code also under the terms of the GPL, regardless whether I distribute it as source code or in form of compiled results.

Now, you might smell the rat: If I write my music by using the LilyPond description language and if I use any GPL-licensed snippet to do so, then I have to distribute my music under the terms of the GPL, namely the created pictures / pdfs as well as the code itself. Moreover, by distributing it under the GPL I grant anyone, who gets my results to use them, to study them, to modify them, and to redistribute them. And what does it mean to use music scores: Beside others, of course, to play the music.

Hence, using a GPL-licensed LilyPond snippet for creating your own music — regardless, of whether you use the include- or the copy & paste method — evokes that everyone who gets your work also and inherently gets the right to use it — for any purpose and without having to ask you again.

For being clear: Any author has the right to license his work under any license he likes. And the users of his work have to fulfill the requirements of the license he has chosen. No doubt. That’s the core of the Free Software World.

But what can those snippet developers do, who do not want to load such heavy consequences on their users?

• First, you might think that they could distribute their snippets/libs under the terms of the LGPL. [⇒ B] Then — due to the weak copyleft effect of the LGPL [⇒ B, §2/§4] — their users are free to distribute their own code/music under different conditions.

But that has also a — perhaps unwished — side effect: If I wrote a piece of music based on an LGPL licensed snippet, then I have to distribute together with my work the code of the snippet, the LGPL license text itself, a list of copyright owners [⇒ B, §4], and some other compliance artifacts. Distributing my work without these compliant artifacts would simply not be compliant. And for this it does not matter whether I distribute my work as Lilypond source code or binary pictures or pdfs!

• As a substitute, the snippet developers could explicitly state that distributing the music in the form of pictures / pdfs does NOT trigger the requirements of the LGPL.

Linking an open-source license with such an exception is a well-known practice. But using a really appropriate license is better than using an exception. Such a supplement states that the license text does not mean what it says.

• Third, they could license their LilyPond snippet under any other permissive open-source license.

But even these licenses enforce them to distribute compliance artifacts together with their music — in case of the Apache‑2.0 license, for example, the license text itself and the NOTICE file of their packages. [⇒ C §4]

• Finally, they could license the snippets/libs under the terms of one of the creative commons licenses [⇒ D]

By using the respective attributes they determine how the users shall show them respect (BY) and which additional requirements they have to fulfill [SA] or whether they do not have to fulfill any requirements [CC0]

• And very last they could shift their snippets into the public domain. In this case, they have to give up all copyrights.

The LSR chose this way to distribute the snippets. Unfortunately, this indeed does not hold for the European Legal Area: Here, we cannot give up our copyrights, we can only grant some of them to others: In Europe, there does not exist any ‘public domain’

Hence, what shall we do, if we — the snippet developers — want to support other musicians by simplifying their development work instead of burdening it by enforcing them to create some seldom recognized compliance artifacts?

• First, we can distribute our LilyPond snippets under the terms of the MIT license. This license is so small, that we can literally integrate it into our source code. Then, our source code contains already all artifacts the license requires: „The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.“ [⇒ E]
• Second, we can distribute our snippets under the terms of a creative commons license. But only the CC0 does not impose our users anything. [⇒ F]
• Third, we can use the method of dual licensing — just as I did in the case of my snippet ‘harmonyli.ly’.

Yes, if we do so, we can no longer enforce, that our users share their improvements with the community. But let us be honest with ourselves: are our snippets so important, that we must protect their worth? I think, sometimes it is better to give without requiring a return. Our users often give us something back voluntarily.

And in what way is this …

… part of the overarching topic FOSS Compliance? For fulfilling the requirements of FOSS licenses, we have to consider specific individual cases as well as side effects — for software, pictures, or documents. We should unhide trends and write guidelines. Above all, however, we must drive forward the automation of license fulfillment, make our licensing knowledge freely available, cast it into smaller tools, and bring it into larger systems: Because FOSS thrives on freedom through license fulfillment, large and small. That’s what also this article is about.

• [1] http://LilyPond.org/gpl.html
• [2] http://LilyPond.org/introduction.html
• [3] http://LilyPond.org/text-input.html
• [4] https://github.com/LilyPond/LilyPond
• [5] http://lsr.di.unimi.it/LSR/html/whatsthis.html
• [6] https://github.com/openlilylib/
• [7] https://openlilylib.org/
• [8] https://github.com/openlilylib/oll-core
• [9] https://github.com/openlilylib/oll-core/blob/master/package.ily
• [A] https://opensource.org/licenses/GPL‑3.0
• [B] https://opensource.org/licenses/LGPL‑3.0
• [C] https://opensource.org/licenses/Apache‑2.0
• [D] https://creativecommons.org/share-your-work/licensing-types-examples/
• [E] https://opensource.org/licenses/MIT
• [F] https://creativecommons.org/publicdomain/zero/1.0/

The post GPL-Licensed LilyPond Snippets — And Some Sideaffects appeared first on FODINA 4 FOSS.