Using open source elsewhere is not relicensing, it’s overlaying a second license.
So you’re considering taking some open source code under a minimal, non-reciprocal OSI-approved license and putting it under a different open source license, hopefully in combination with your original code (or another form of larger project).
Don’t call this “relicensing” – it is not! The original license will continue to apply and you remain responsible for complying with its requirements. Only the copyright holder can change the license. You’re not relicensing – instead you are using the rights the license has given you and applying an additional license to the combination of the earlier work and your work.
All open source licenses are permissive. They give you permission in advance to use the software for any purpose, to improve the software any way you wish and to share the software with whoever you want. They are the opposite of proprietary licenses, which place restrictions on each of these freedoms. Any license with restrictions would not be considered OSD compliant.
All open source licenses include conditions. Some relate to attribution. Some relate to reciprocal licensing. None of them restrict how you can use, improve and share the software, although you must comply with the conditions in order to do so. Some people consider some conditions so onerous they rise to the level of restrictions, but the consensus of the community has been they are wrong.
Today’s licensing games are thus mainly about testing where the accumulated burden of conditions is effectively a restriction – “constructive restriction”. There’s certainly a line where that would become true – for example, where the conditions associated with deploying the software as a cloud service are so hard to comply with that the software is effectively unusable in that field of use.
The OSD doesn’t include much to help with this so it’s contentious every time and sometimes leads to sophistry. This is probably the area where the Open Source Initiative needs to do the most work to modernise the license approval process.
The lesson Elastic’s restrictive relicensing teaches is that those using open source to ratchet a software startup will forsake software freedom eventually if they’re aggregating rights. That’s no reason to believe open source needs updating.
Many of the responses to the decision of Elastic to drop open source licensing for their products and instead use restrictive commercial licensing have involved asking whether they were justified to do so based on market conditions (especially the provision of a service by Amazon Web Services) or diving into the minutiae of what they actually did. Some see it as support for the hypothesis that the very definition of “open source” is out of date. But to do so is to swallow the bait of distracting explanation and overlook the actual value of open source and why Elastic — and the cloud databases before them — no longer care about it.
It’s not enough for you to have the rights you need; your community needs the same rights.
A few people reacted negatively to my article on why Public Domain software is broadly unsuitable for inclusion in a community open source project. Most argued that because public domain gave them the rights they need where they live (mostly the USA), I should not say it was wrong to use it.
Choosing between licenses – even copyleft vs non-reciprocal – is less important than ensuring everyone has equal rights & responsibilities.
I’m often asked which open source licence is best for businesses who want to release a project as open source. Usually behind the question the issue is a desire for corporate control somewhere in the organisation. This tends to flow from a conviction the only way a business can succeed is by keeping some sort of copyright (or patent) control that creates an artificial scarcity. Continue reading →
Open source ensures developers already have permission to innovate and don’t need to ask first.
If you want your code to be open source, it needs an OSI-approved copyright license. Code with no license to the copyright isn’t open source. But project success needs more than just an OSI-approved license — it needs “permission in advance” for every developer and deployer. Continue reading →
Facebook’s BSD+Patent license combo fails not because of the license itself but because it ignores the deeper nature of open source.
In July 2017, the Apache Software Foundation effectively banned the license combination Facebook has been applying to all the projects it has been releasing as open source. They are using the 3-clause BSD license (BSD-3), a widely-used OSI-approved non-reciprocal license, combined with a broad, non-reciprocal patent grant but with equally broad termination rules to frustrate aggressors. Continue reading →
The Apache Software Foundation has moved the “Facebook BSD+Patent grant” license combination (FB+PL) to its “Category X” licensing list, effectively banning inclusion of any software under FB+PL from Apache projects. That included RocksDB, which has consequently just dropped FB+PL and added the Apache License v2 on Github, and React.JS which does not look like it will resolve the issue so fast.
Update, 22 September: Facebook has announced it will switch React to the MIT license.
Here’s what we know so far (subject to updates, last day’s in green, latest marked 🆕): Continue reading →
Individual judgement about the presence of software freedom in a license is not the same as community consensus expressed through OSI approval.
Does it really matter if a copyright license is OSI Approved or not? Surely if it looks like it meets the benchmark that’s all that matters? I think that’s the wrong answer, and that OSI license approval is the crucial innovation that’s driven the open source revolution. Continue reading →
Is the GNU GPL “dying” or is that just the prejudice of those whose open source exploitation would be hampered by its use?
At the huge FOSDEM developer meetup in Brussels in early February, I attended a panel where speakers discussed whether the use of “permissive” open source licenses like the Apache License is now outstripping use of “viral” licenses, such as the GPL. The discussion was spirited, with advocates associated with the Free Software Foundation pushing back on the assertion the GPL is “dying”.