people don’t think about it too much... • It is based upon copyright law, and involves rights holders ◦ In most countries content creators automatically get all rights ◦ Thanks to Mickey Mouse you retain these rights for a very long time! ◦ Licenses effectively relinquish a portion of your rights • Licenses have specializations, use the right type ◦ Software licenses make little sense for documentation, images, data, music ◦ Creative commons licenses make little sense for software • Getting things right upfront is always preferable ◦ Relicensing is possible if all rights holders agree, but it is a pain ◦ Your contributors may choose your project because of these choices • Don’t make up your own thing, this is not the place to “get creative”
◦ Written by the company for their use • “Homemade” open source licenses ◦ Not open by most interpretations, some claim to be ◦ Difficult to interpret/reuse as there is no track record • Open source OSI-approved ◦ Reviewed and approved as “Open” ◦ Comply with “open source definition” - allow reuse, modification, sharing • Free (or libre) licenses ◦ Generally FSF licenses, such as GPL, employ copyleft • No license means no right to use - huge problem on GitHub
can cause confusion ◦ Try to stick with an established open source license • Making exceptions is an “exception” ◦ By granting more rights the core license remains intact ◦ Interactions with other licenses remain unaffected ◦ Famous GPL link-time exception ▪ More permissive than the LGPL (static linking allowed) • Adding more restrictions is very bad ◦ “The Software shall be used for Good, not Evil” ▪ IBM sought and obtained an exception ▪ Evil is a legally ambiguous term ▪ The JSON License (MIT + do no evil)
◦ Do as you wish, often must retain copyright notice ◦ MIT, BSD, Apache 2, Boost • Copyleft seeks to “guarantee freedom” ◦ Derivative works must use the same/compatible licenses ◦ Definition of derivative work can be tweaked/interpreted ◦ GPL, AGPL • Weak copyleft limits the scope of derivative ◦ Linking allowed, or even limited at source file scope ◦ LGPL, MPL 2 • Copyleft usually demands you “share-alike” • Public domain is not OSI approved - waives all rights
longer and more complex ◦ Defining what a derivative work is ◦ Defining what counts as distribution ◦ Placing restrictions on any further restriction on use, distribution, etc • Permissive licenses tend to be very...permissive ◦ Often ask for attribution, listing in documentation ◦ Otherwise to a greater or lesser extent permit all reuse ◦ Much shorter, simpler licenses with few strings/conditions • Then there are licenses that are somewhere in the middle too ◦ MPL-2 weak copyleft at the file level, allows any kind of linking, inclusion, etc ◦ Apache 2 permissive but requires all software to be distributed under Apache 2 • License compatibility and interaction dominated by copyleft
Many won’t work with the GPL due to this • Not an isolated debate, many nuances • You can license your code MIT/BSD • The copyleft affects the complete work, i.e. the instance that is run on the server • The BSD/MIT license is compatible, hence legal, but the running plugin is “infected” • This would not give anyone the right to demand the entire work be BSD/MIT ◦ Not viral in that direction • It is the reason there is directionality ◦ GPL in BSD program results in GPL infection if program is distributed https://groups.drupal.org/node/290243
• We must ensure the final work is legal, and compliant with license terms • Compatibility is often a major concern ◦ Especially true in larger projects ◦ It may not be clear exactly what is being combined ◦ License compliance is a big problem ◦ Large companies have made mistakes in the past ◦ Some combinations are simply not allowed • Several grey areas, especially where copyleft is concerned ◦ Dynamic versus static linking ◦ Plugin loading, JavaScript running in an application ◦ Macro/template expansion
Strong copyleft, or proprietary license for a fee • Several aspects of licenses not tested yet ◦ Only the copyright holders can enforce the license • Clarifications/exceptions from rights holders ◦ This can help if you are in a murky area ◦ If stated in writing it holds more weight • Seeking relicensing, or additional exceptions ◦ Explain your case and reasons ◦ Rights holder(s) can relicense the entire work • Reimplementing/working around issues ◦ Never fun, but sometimes necessary
“You may not impose any further restrictions on the recipients' exercise of the rights granted herein.” • This leads to a number of incompatibilities! ◦ GPLv2 incompatible with original 4-clause BSD license ◦ GPLv2 incompatible with Apache 2 license ◦ GPLv2 and GPLv3 incompatible with the CPL license ◦ GPLv2 incompatible with GPLv3 license! • Allowed combinations include ◦ New and simplified BSD license OK with GPLv2/GPLv3 ◦ GPLv3 compatible with Apache 2 ◦ MPL 2, MIT, Boost compatible with GPLv2/GPLv3
Can ask for copyright assignment ◦ Also ask for additional rights • Google and Qt agreements in place at Kitware ◦ Both ask for legal rights to license work ◦ Clarifying legal right to contribute ◦ Under US law our work is copyright Kitware, Inc. ▪ Covers all work (paid and not) ▪ This varies by jurisdiction and contract ▪ Kitware must sign our rights over to other entities • Kitware projects do not use this mechanism • Precedence - contributions licensed under project’s license
◦ If you can, keep it simple ;-) ◦ If not then look for existing precedents • Avoid licenses that are not OSI approved • Try to use popular and established licenses ◦ Clearer interactions between these licenses ◦ More existing case law establishing precedents • No license is the absolute worst case! ◦ No rights granted to use, modify, or share ◦ Default is copyright holder retains all rights • Some projects use multiple licenses ◦ Enables you to choose the most appropriate one
major components ◦ Code generator parsing OpenGL headers ◦ Generated code used by other projects ▪ OpenGL Extension Wrangler library • Project uses three licences ◦ GNU GPLv2 only for the code generator ◦ 3-clause BSD or MIT for generated code • Most users of GLEW will use the generated code ◦ Choose between 3-clause BSD or MIT ◦ Resulting derivative work is permissively licensed • If extending the generator then that is GPLv2 only
LGPLv3+, now MPL2 • Both are weak copyleft licenses, MPL2 is weaker ◦ Draws distinct line at boundary of source files ◦ Removes ambiguity of GPL for template expansion • Assurance from the community over copyleft ◦ Publicly stated they only want it to apply to their source files ◦ FAQ attempted to address this issue before license change • Relicensed to MPL2 to make this clearer ◦ Ambiguous language in GPL led to pressure • Derivative work is permissively licensed • Must contribute Eigen changes back to Eigen
wrote their own license - QPL ◦ The KDE project developed a Linux desktop based on the toolkit ◦ Established the Free Qt Foundation with KDE - guaranteed releases ◦ Trolltech sold commercial licenses in addition to the “open” QPL version • The FSF was very unhappy, called for development of GTK/Gnome ◦ Unhappy that the license was not open, and had none of the guarantees • Later Trolltech released Qt under the GPL • Nokia purchased Trolltech, acquiring all copyrights, released LGPL • Digia bought Qt from Nokia, later founding the Qt Company ◦ Dual licensing LGPL with commercial, now with some GPL components • Dual licensing established a position of power for some entities ◦ Generally agreed that this reduces community participation, shared ownership
linking ◦ Considered the same as dynamic linking ◦ LGPL only covers the plugin - not the application ◦ GPL would make the application GPL when the plugin is loaded ◦ Could not load a GPLv2 only and GPLv3 plugin at the same time ▪ License compatibility • Static plugins are the same as static linking ◦ LGPL only makes exception for dynamic linking ◦ Would become GPL, apply to the complete derivative work • Shared memory generally considered linking, pipes not • Lots of grey areas, discussion of intent, tension around binary blobs ◦ See NVIDIA Linux drivers, kernel developers refuse to enforce
but not processes ◦ You can run multiple, possibly incompatibly licensed components • This allows reuse of code without “infection” • Data passed in and out of the process ◦ This can include web services, batch execution, use of QProcess in a Qt application • Added benefits of separate processes ◦ Can kill hung processes, won’t crash entire application • Application can still be permissively licensed • AGPL “fixes” this flaw, but only for the server ◦ This approach still enables non-GPL consumers of services
it? • The answer is “it depends” on what you do with it • If you run a server using modified GPL code then no ◦ The AGPL changes this, but most copyleft licenses do not • If you edit, compile and run locally you are not affected • It is at the point of “distribution” or in GPLv3 point of “convey”ance ◦ Creating an installer and offering it for download for example “The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.”
do this • Largely 3-clause BSD or Apache 2 licensed • Using GPL or LGPL components for some components • The installer should display licenses for all works ◦ BSD, Apache 2, etc ◦ This is distribution of software • We can distribute a work that links to GPL ◦ Application would be GPL at point of loading/linking GPL components ◦ BSD licensed software remains BSD licensed, even if distributed with GPL binaries ◦ Becomes a derivative work at link/dynamic load time ◦ About dialog should display effective license if practical ◦ It is all about linking/equivalents, the uncompiled source code does nothing
states that it must be distributed under Apache 2 ◦ If GPL work is included then that is not possible ◦ Work must be dual licensed Apache 2 and GPLv3+ (or GPL license) ◦ http://www.apache.org/licenses/GPL-compatibility.html explains • All hinges on interpretation of copyright law • See why it is useful to use established licenses ◦ Previous interpretations are available, interactions established • This is not necessary for other permissive licenses ◦ They make no requirements on distribution, just license of code • Some feel this is a strength of the Apache 2 license • Others see it as unnecessarily complex...
not all of which are “open” ◦ CC0 is as close to public domain as legally possible, no strings at all ◦ CC-BY is roughly equivalent to BSD - asks for attribution only ◦ CC-BY-SA is asking for “share-alike” and is roughly equivalent to GPL • Versions that are not open by most definitions ◦ ND - no derivatives, offers no right to modify and distribute derivatives ◦ NC - non-commercial, ill posed in many jurisdictions, restricts commercial uses • Open science largely settled on CC0 for data, CC-BY for publications • Wikipedia recently informed me CC-BY 4 is not compatible with CC-BY-SA 3, and removed Tomviz text we released CC-BY 4! ◦ Share-alike comes with the same baggage copyleft software licenses have ◦ Defining collections, derivative works, etc all become issues
to code, it is different to creative works • Often collated into larger collections, or derived data • Requiring attribution makes it much harder to reuse data ◦ Many unanswered questions on how far the requirement should be taken ◦ Most data collections do not have the resources/APIs to furnish attribution • Fairly widespread agreement on CC0 and similar licensing • This varies massively, with CC-BY being used in many placed ◦ Some large collections go further, adding the SA clause, is a database derived? • There are a number of data specific licenses • Figshare has chosen CC-BY for articles/posters, CC0 for data
forever...well, they aren’t, but they are for a long time • A longstanding debate between Luis Ibanez and me ◦ I won a fine bottle of single malt scotch after many years and a Red Hat lawyer • The copyright holder can change the license ◦ They cannot retroactively revoke previous permissions given in the past • The XFree86 license change, and subsequent fork of XOrg ◦ Dispute over license, forked last release before the license change • Widely agreed that revocation is not possible ◦ Some licenses build this into their terms ◦ No legal precedent showing that it is possible to retroactively revoke • There are no backsies, but copyright holders can relicense
kind of time • Selection of interactions I have come across • Only copyright holders can enforce the license ◦ FSF asks for copyright assignment for this very reason ◦ KDE optional FLA (Fiduciary License Agreement) • There are many more corner cases ◦ If you aren’t sure seek advice • Keeping it simple is always nice when you can ◦ Copyleft usually involves complex language ◦ Desire to enforce right to modify, distribute, etc ◦ Permissive seeks to offer same rights, but not to enforce/define derivatives • Creative Commons licenses have similar goals for creative works
cryos
seike460
tasuku43
hiro_ghap1
makihiro
hirobe1999
philipschwarz
niftycorp
yjszk
92thunder
sugi_0000
onihusube
ma_cho29
jponch
trallard
csswizardry
tammielis
lynnandtonic
mraible
davidbonilla
vanstee
mojombo
michaelherold
rocio
wjessup
