Re: OpenChain Global Work Team Meeting - 2021 -11-22 (Today) @ 14:00 UTC / 06:00 PST / 15:00 CET / 19:30 IST / 22:00 CST / 23:00 KST + JST
Thanks Sebastian! Very useful input.
I concur that more information and knowledge is more helpful than less. Our only balancing act is to provide it without anyone thinking the OpenChain Project endorses X interpretation of a license. Have several sources and a disclaimer covers a lot (or all) of this ground.
Regards
Shane
Shane Coughlan
OpenChain General Manager
+818040358083
Book a meeting:
https://meetings.hubspot.com/scoughlan
toggle quoted message
Show quoted text
I concur that more information and knowledge is more helpful than less. Our only balancing act is to provide it without anyone thinking the OpenChain Project endorses X interpretation of a license. Have several sources and a disclaimer covers a lot (or all) of this ground.
Regards
Shane
Shane Coughlan
OpenChain General Manager
+818040358083
Book a meeting:
https://meetings.hubspot.com/scoughlan
On Nov 23, 2021, at 0:21, Sebastian Crane <seabass-labrax@...> wrote:
Dear Shane,
Thanks for leading the interesting discussion today; sorry for having to
leave early. During the meeting, my parents called me to ask if - A: I
knew what AnyDesk was, and B: why 'Amazon Customer Support' wanted them
to install it! All danger was averted, I am glad to say.
It's always good to share links about complex topics such as license
compatibility, as search engines are unfortunately not wont to promote
miscellaneous YAML files on GitHub!
As for the topic of whether OpenChain should be linking to license
compatibility information, I take the view that false negatives are
safer than false positives here. Compatibility information, even if not
100% correct, can still be useful for instance to quickly flag up issues
such as combining code under the CDDL with (GPL'ed) Linux.
For a company which would like to avoid risk, it's perfectly acceptable
to automatically reject any such 'incompatible' combinations whilst
taking the 'compatible' combinations with a grain of salt. However, in
the case of Canonical with ZFS [1], if there are no reasonable
alternatives for a certain piece of software, the company can still
spend time to manually review the license compatibility for their own
use-case.
When it comes to companies with more of a software development focus,
then using tools such as the OSS Review Toolkit with the DoubleOpen
machine-readable information that we discussed could be very
useful. Even if not a substitute for specific legal review, it can be
very good to produce noisy warnings in the CI/CD system when an upstream
software dependency changes its license to something incompatible, which
does happen now and then [2]. Again, this is using the information as
more of a source of warnings rather than a source of truth.
Hope this helps, and I look forward to seeing the playbook be published!
:)
Best wishes,
Sebastian
1: https://ubuntu.com/blog/zfs-licensing-and-linux
2: https://www.theregister.com/2021/03/25/ruby_rails_code/