elce17-mission-impossible-os-compliance-for-1990-licenses

Mission Impossible: Open Source Compliance for 1990's Licenses in Today's World
Will the OS Community Soon Face OSS Trolls?
Dr. Hendrik Schöttle, Fachanwalt für IT-Recht, osborneclarke.com

Slides: https://schd.ws/hosted_files/osseu17/85/Osborne%20Clarke%20-%20Hendrik%20Sch%C3%B6ttle%20-%20Open%20Source%20Summit%20Europe%20-%2023%2010%202017.pdf

"First I will disappoint you: I won't have an out-of-box-solution" :(
compliance issues will likely increase in the next years

outline: 
	myths vs facts
	what are the aims of the oss community?
	solutions?

MIT (1988), BSD (1990), GPLv2 (1991) are rather old licenses

Myth 1: oss communities do everything correctly
	it's your own fault if you break your own license
	OSS licensor is not bound to comply with their own license terms (OLG Hamm, 4 U 72/16)
		http://www.justiz.nrw.de/nrwe/olgs/hamm/j2017/4_U_72_16_Urteil_20170613.html
	but a licensee distributing unmodified source tarball is automatically in breach of the license
	even linux kernel is not immune
		GPLv2 par. 1 states:
			on each copy: include with the program 
				appropriate copyright notice
				+ disclaimer of warranty
				+ license text
				+ attribution to GPL v2
		look on linux-4.13.4.tar.xz (and actually also latest version) with fossology
			90 unique licenses in the tarball
			tarball includes text for GPLv2, copyright notice of FSF
			but no warranty disclaimer in every source file
				see e.g. kernel/cred.c, kernel/ptrace.c, net/ipv4/netfilter/arp_tables.c
				kernel/params.c as a positive example

Myth 2: license obligations are easily fulfilled
	not that easy to compile all license texts, copyright notice etc into one report & give it to users
	tools still require lots of manual work
		(90 different unique licenses...)
	in 1990: software fit onto 1-2 floppy disks, with a paper manual
		not that big of a problem.
	in 2017: smartphones, embedded systems etc.
		sometimes without a screen, no paper manual, 100 GB of source code possible
		display warranties etc. "easily perceivable"?
			paper needs no power!
	some opinions in the GNU FAQ: https://gnu.org/licenses/gpl-faq.html
		e.g. on an audio interface, you could read the text aloud... :D

myth 3: no one will ever hunt you down.
	if companies are on good terms with the community, they'll be fine
	but: license trolls...
		number is increasing: make $$$ from basically nothing
	claims can be enforced by each single contributor
	see opensource.com article "Patrick McHardy and copyright profiteering"
		https://opensource.com/article/17/8/patrick-mchardy-and-copyright-profiteering

myth 4: GPL obligates me/others to contribute source code to the original source
	no! needs only to be provided to the recipient of the software!
	no "you have to give back to upstream"
		(even though most orgs understand why this is useful)

myth 5: OSS compliance is easily achievable (economically)
	see above
	if many licenses need to be assembled/printed on paper, this costs money/code space
	who is taking advantage of availability of the source code?
		real life example of a household appliance running linux
			only ~5 requests for the source in total

question: but MIT/BSD are easily enforcable/easy to follow?
	Yes. GPL (and apache license?) is a bit of an elephant in the room
		more strict terms also with GPLv3
	from a structural perspective it's the same issue, warranty disclaimers, copyright notices, etc

What are the aims of the open source community?
	building a thriving community?
		impossible solely through licenses
		rather but because the software "is good"
		"if you don't publish your source code, you'll burn in hell" is not very motivating.
	ability of users to amend & modify their software
		see above, extremely rare.
		"I don't want to modify it, it should work. I'm not a software developer"
			(users mostly cannot even use the toolchain etc)
	
open source community is like a castle: 
	heavily armed (with licenses)
	everyone who wants to can use those arms (every contributor)
	=> "get your cannons under control!" -> license enforcement is over the top.

GPL is not law, but individual agreement
	needs to be interpreted by courts => more difficult to enforce

Any solutions?
	closed communities, waive copyrights to project leader (e.g. apache)
		OTOH, you as the outsider (doing license compliance) would still not know whether/when the cannons are fired
	rethink OSS licenses as such?
		maybe even public domain?
	chart of 2011-2017: MIT usage increases 10% -> 30%, GPLv2 decreases 40% -> 20%
		(source: black duck open source resource center)

Q: how about GPL, but assign copyright to FSF?
A: yes, possible, same concept as above with apache in closed community
	
Q: did you read Kernel enforcement statement?
	http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
A: it's agreement, not law. interpretation of the court can vary.
	history: first ever GPL enforcement was in Germany in 2004, was recognized as a personal agreement

Q: could I add a clause "don't distribute my software if a clause is interpreted like this"?
A: Yes, but then not open source, would probably lead to more issues

elce17-mixed-license-foss-projects

Mixed License FOSS Projects: Unintended Consequences, Worked Examples, Best Practices
Lars Kurth, ELCE 17, Prague

(notes by rohieb)

Slides: http://schd.ws/hosted_files/osseu17/11/OSSEU17%20-%20Mixed%20License%20FOSS%20Projects.pdf

examples of projects that started out as single-license:
	linux (gplv2)
	qemu, xen (gplv2)
	freebsd (bsd)

now: 
	linux:		96% GPLv2
	qemu:		86% GPLv2
	freebsd:	less than 84% BSD-licensed...

why multi-license?
	need to interface with other projects under another license
	want to allow other projects interfacing with your project
	want to import code from other projects
	project may not have clear rules that govern license exceptions
		people assume it's ok to add differently-licensed code
	=> all good and valid reasons for license exceptions
	BUT without guidance, there may arise unintended consequences

"War Stories from the XEN project"
	Xen == several sub-projects
	financially supported by linux foundation
	want to enable guest support for non-gpl OSes
		=> header files need MIT or BSD or other permissive licenses
	possibility for such OSes to have Xen support also needs permissive licenses
	want to enable non-gpl tools to interface with xen (=> lgpl)
	want to import code from other projects
	we had no codified rules about licensing exceptions
		we assumed we had a single-license project

War Story 1: license-related information not easy to consume by lawyers
	2015: large $company reviewing xen, wants to allow their staff to contribute
	$company starts IP and patent review
		evalutate LICENSE, COPYING, runs fossology on xen codebase
			fossology finds some mismatches...
		lots of questions about rationale for licensing exceptions
		generates a lot of work for Xen people and IP lawyers
		but $company contribution is kind of important for the xen project...
		=> ended up in lots of code archaeology
	after 9 months, $company is finally ok with everything.
	why did this take so long?
		information was present, but not really consumable
			git commit logs
			references to mailing list posts
			mailing list archives were rebuilt a few times...
			changed from mercurial to git...
		licensing inconsistencies confusing the IP lawyers
		lawyers tend to work on multiple projects at the same time => long delays
	at the end of the process: let's cleanup all that mess!
		in-tree info on license exceptions
		license templates in CONTRIBUTING file
		when to use what license
		rationale for specific classes of license exceptions
		COPYING file for each single component
		README.source for every directory to document code imports (even for gpl imports)
			tracking rationale, source, other relevant info
			no time to maintain this at commit time rather than afterwards (TM)
		fix inconsistencies in existing documentation

War Story 2: Relicensing a key componnet
	patch series: "Make ACPI builder available to components other than hvmloader"
	basically: re-use architecture component in component B when it was only used in component A (under different licenses)
		-> GPL linking clause etc.
	options:
		clean-room reimplementation
			very much code, very much time...
			some original authors were not reachable for questions about the old code
		allow GPLv2 encumberment for component B
			too intrusive!
		relicense ACPI builder component to LGPL
			need to ask every single contributor
	in hindsight, relicensing could have been avoided with a bit more foresight when looking at the architecture view...

	step-by-step:
		1. identify copyright holders (Signed-off-by lines, file headers)
			easy? most of the time...
			VCS changed from mercurial to git in the meantime
			people just copied files, no git mv -> destroyed file history
			was the code maybe imported from elsewhere?
			potential issues of code imported from project which had Contributor License Agreements
		2. split into individuals and companies (can be treated differently)
			issue: use of private email addresses when really working for a company
		3. contact company stakeholders and private individuals
			corporate owbership of code: only need to ask one entity for several contributors
			private individuals need to be asked each individually
		4. ask for approval of all copyright holders
			e-mail adresses don't exist anymore...
				linkedin, phone, personal track-down through personal contacts... waaaaah!
		5. Approval?
			yes -> commit!
			no -> well, we need a workaround... :(
	
	Problem: one contributor (working for $COMPANY) couldn't be tracked down
		$COMPANY was based in china. but what is the chinese linkedin equivalent...? Don't know chinese, etc.
		$COMPANY was no OSS company, never contributed something in other projects o_O
		search for office staff, programs office, etc. of $COMPANY
			contingency plan: their contribution was not really used in the binary version
				=> was not really needed for LGPL compliance
				=> make two variants of the component with different licenses, only one including their code
		but phew, success! approval after 2 months!
	
War Story 3: unintended consequences of mixing GPL/LGPL "vversion X (or later)" with GPL/LGPL "version X only"
	(related to War Story 1, same context)
	$company says GPL v3 is problematic for them because patents
	our project is "v2 only". but apparently we have gplv2 "or later" in our code base...?
	huh, but why do we have that?
		contributors just copied the FSF's website text for file header, nobody noticed... -.-
	issue exists also in linux (14% of files), qemu (9%), xen (10%), freebsd (32%) o_O
	can't we drop the "or later" silently...?
		DON'T YOU DARE WITHOUT ASKING
	raise awareness in the project about the difference, hopefully we'll find a solution
	in the end, problem went away because $company had already contributed to "GPL v2 or later" projects elsewhere

Best Practices:
	if you wan to stay single-license, use tools to help you.
	document license exceptions!
	company vs. personal s-o-b lines
	plan for future architectural changes