Feedback 2023/12/11

The text:

Open source isn’t going away. As noted in "The State of Enterprise Open Source: A Red Hat report", open source software is more flexible, higher quality and has better security than commercial alternatives.

Another key benefit of open source is that it prevents vendor lock-in. This is where a software vendor can either force upgrades or charge license fees that increase over time against their customers’ wishes. As we will see, this practice is incompatible with the license that open source software is provided under.

Is present on both these pages:

• https://trainingportal.linuxfoundation.org/learn/course/open-source-contribution-in-finance-lfd137/important-concepts/what-is-open-source-software?page=1
• https://trainingportal.linuxfoundation.org/learn/course/open-source-contribution-in-finance-lfd137/important-concepts/what-is-open-source-software?page=2

Likely the page was split or merged - in any case you probably want to remove the duplication.

It may be worth adding a sentence or two, stating what does it mean for code to be in the public domain, and how does it differ from the permissive license. Even better a table summarizing the key differences between the four types of licenses (including proprietary).

I believe that it is an open question if an author can disclaim their responsibilities (regarding licensing, high tech export regulations) by putting a work in public domain.

I would love if we can start phasing out the cutesy "copyleft" and "viral" monikers and use the descriptive "reciprocal licenses".

https://trainingportal.linuxfoundation.org/learn/course/open-source-contribution-in-finance-lfd137/important-concepts/understanding-open-source?page=4

On OSS Criteria:

The program must include source code, or some easy way to get hold of it.

It is worth getting a bit more specific as that is very relevant to corporate OSS - reciprocal licenses require the _final modified source code _to be available to any user; permissive licenses require the upstream code that is being built on to be acknowledged and linked; public domain does not require any of these (and technically does not classify as OSS).

Furthermore, it is important to note that licenses require that code is offered to users of the software - hence if one reuses even a strong reciprocal license such as AGPL, but keeps the usage in the firm, there will be no external obligations.

--
https://trainingportal.linuxfoundation.org/learn/course/open-source-contribution-in-finance-lfd137/important-concepts/the-open-source-initiative?page=2

It is worth mentioning that Eclipse now hosts the Adoptium project, coordinating the activities of the the various Java builders and their artifacts, as well as Temurin - a vanilla OpenJDK runtime:

https://adoptium.net/marketplace/
https://adoptium.net/temurin/

--
https://trainingportal.linuxfoundation.org/learn/course/open-source-contribution-in-finance-lfd137/important-concepts/foundations?page=1

The linked ISO 27001 standard costs 124 CHF - I doubt anybody will be willing to spend this kind of money just to check the reference material. A summary would be very useful, as well as guidance in which cases is it worth reading the primary source.

https://trainingportal.linuxfoundation.org/learn/course/open-source-contribution-in-finance-lfd137/engagement/being-an-ambassador?page=5

Quiz 2:

What is the term used to describe communication related to a financial firm's products, services, investments, or other business matters?

also:

From an open source perspective, what’s the difference between public information and classified information?

This was probably in the 124CHF document, but I cannot meaningfully make a difference between "Internal", "Restricted" and "Firm business" - this doesn't line up with my company classification.

I'd rather have a question about what I should and should not do, over "what name did we give to..."

https://trainingportal.linuxfoundation.org/learn/course/open-source-contribution-in-finance-lfd137/engagement/knowledge-check?page=1

One more criteria:

• Value of reused functionality vs. maintenance/coupling/complexity cost of added dependencies

https://trainingportal.linuxfoundation.org/learn/course/open-source-contribution-in-finance-lfd137/using-dependencies/choosing-software-components?page=1

SVB is no more, and has somewhat negative associations - perhaps we can have a different example?

https://trainingportal.linuxfoundation.org/learn/course/open-source-contribution-in-finance-lfd137/regulatory-landscape/regulations-antitrust-regulations?page=3

This is a weird way to ask a question:

Popularity, community support, documentation, code quality, security and vulnerability management should be considered when selecting software components in addition to:

Pretty much all answers are correct to an extent and one has to guess what is intended.

Similar with:

Requiring approval before submitting personal OSS contributions is necessary to prevent:

The following sentence is hard to parse. (What risk? In what way does it challenge? What are "traditional ways"?)

A new technology has created risks regarding data leakage and challenges the traditional ways of contributing to an open source project involving this technology. What is the suggested action to manage these new scenarios?

Bottom line, very good as scope and content.

If I could change one thing, it would be to reduce the number of "slides" - as a guideline, 150-200 words per screen is a good amount. If I have to click "Next" for every sentence, I'm losing context.

Another minor pick is that it would be nice to make sure to minimize the number of questions requiring to memorize nomenclatures, especially when speaking of taxonomies that may vary between companies.