>As they say, not all open source is FOSS
This isn't true - you mean "not all open source is copyleft".
>> Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors.
>This is not the case of all open source licenses
This is also not true. You should review the open source definition:
>I am all-for the FOSS movement but there is no need to go full Stallman and say that everything but GPL is evil
I did not say that, nor do I believe it, nor is it really related.
>When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged upstream than having to maintain our own private fork.
This is definitely a valid position to hold, and I have signed CLAs on behalf of my employer before for this very reason. I suppose my article is targeted more at people contributing in their spare time, and to discourage maintainers from adopting a CLA in the first place.
> This isn't true - you mean "not all open source is copyleft".
Yes it is, and I'm not sure the commenter does. Software may be free but not open-source, and it may be open-source but not free. The term "free and open-source" signifies both.
> This is also not true. You should review the open source definition:
That is not the definition of open-source (or even "open source"), a common term for software the source code of which is available; it is the Open Source Definition, a copyrighted work published by The Open Source Initiative.
Contrary to the confusing rhetoric of the Open Source Initiative, they have no claim on how anyone uses common words in the English language like open and source. Putting the two together is trivial. Open-source is an adjective referring to the fact that that source code is available. It need not refer to some particular organization's ideology.
https://haacked.com/archive/2006/07/26/CodeAvailableVsOpenSo...
The point is the adjective is commonly used imprecisely, despite a minority’s desire for it to be only used to describe a precise circumstance.
Genie, meet bottle.
‡ In "Through the Looking Glass" Humpty Dumpty asserts that "When I use a word, it means just what I choose it to mean—neither more nor less".
So it matters whether it's, say, one pundit who thinks "Source code available to certain parties under license" (e.g. Microsoft Windows has been handled this way in the past) counts as Open Source, or so common that you can find dozens of erroneous examples in every major software publication of the last five years.
People writing "free reign" when they mean "free rein" might be unsalvageable at this point, whereas people saying "backslash" when they mean a forward slash - probably we can still say those people are just wrong and need to sort it out.
The vast majority of the software industry uses "open source" correctly. A small minority of people and companies with a vested interest in sowing confusion to promote their "source available" business models misuses the term and creates FUD.
Free and Open source software are basically mean to be synonyms, the latter being put forth by people to eliminate the ambiguity in English about the use of the word Free.
The "free" in "free software" means libre software, not gratis software.
Tangential rant: "Copyleft" licenses aren't actually free. The GNU claims they are, that the restrictions that copyleft licenses add don't conflict with the "central freedoms" but simply protects them. But they do restrict my freedom. If a piece of source was truly free, I should be allowed to make significant modifications and sell the resulting software (without giving out the source). Copyleft expressly prohibits this. I get that the GNU is dreaming of a utopia in which all software is open source and "free" and nobody ever makes closed-source software or charges for software. But we don't live in that utopia, and we probably never will; the closest we'll come is when we hit a post-scarcity society and do away with money, so no more keeping software closed-source in order to sell it, but there will still be reasons to keep software closed-source other than wanting to charge money for it. But I digress. The point is, Copyleft licenses rather significantly restrict my freedom as a developer. I'm not trying to debate as to whether or not that restriction is a good thing, just taking issue with calling the result "freedom".
It's like "those people told me that they are free, but I cannot sell them, so in reality they are non-free".
Really about the only scenario I can think of where I'd reasonably expect to hit this case is if I were tasked with building the software stack for some kind of appliance that would be greatly simplified by throwing Linux on there. And even then, the custom software running as a process on the box would presumably not have to be Copyleft-licensed, just any changes to the Kernel or any other bundled GPL'd software would have to be made available (if in fact there are any changes), and if GPLv3 is involved then the box would have to have some way for the user to replace the software (but the Linux Kernel is GPLv2 so that may not be an issue).
Barring that scenario, if your idea is "I'll develop something for customer#1 and slap the GPL license on it, then customer#1 has no choice but to release the source and I can reuse it for customer#2", unfortunately that's incorrect. Work done for hire is owned by the employer, not the employee, so you can't slap the GPL license on work you do for customer#1 unless customer#1 authorizes it. And in fact if the entire work is built in-house (rather than pulling in GPL'd libraries), then it doesn't even matter if you claim that it's GPL'd because the customer would be the sole copyright owner and would be able to relicense it. The only reason they couldn't relicense it is if it pulls in third-party GPL'd code or libraries, but if I were customer#1 and I hired a developer who pulled in GPL'd libraries without permission in order to try and force the entire work to be released as open source, you can bet I'd be firing that developer on the spot.
No, I cannot. Work done for hire is owned by the employer, not the employee. But, if employer chose GPL-covered software, e.g. Linux kernel, then he is forced to release code under GPL, so I can develop my code, e.g. kernel module for customer #1 and then use it with customer#2, because GPL protects my freedom. I don't need to reinvent the wheel, like with proprietary code.
"Customer" implies a much looser relationship, but you should still make sure appropriate contracts defining ownership are in place.
https://opensource.com/article/18/2/coining-term-open-source...
This is blatantly false. You will find it very difficult to find any respected authority whose definition of open source differs from the OSI's definition.
It's not. Let's not muddy the waters that this term was already introduced to further.
I've never seen anyone advocate the term as open-but-not-free beyond those stating it to defend a point.
Other than version 1 of the Apple Public Source license, which is considered open source but not free (and also now entirely unused), what cases are you thinking of?
Then there are disagreements on specific licenses. OSI approves licenses GNU does not classify as Free, and GNU classifies licenses as Free that OSI does not approve.
Then there's GitHub, which publishes a site to help you "choose an open source license," which includes a license not approved by OSI (the Unlicense), and only makes a reference to OSI as an "additional resource". Likewise, GitHub lists FSF as an "additional resource," while consistently using the term open source, not free, and not free and open.
Digital Ocean explains the difference between free and open-source software: https://www.digitalocean.com/community/tutorials/Free-vs-Ope....
Eliah Kagan answers the question on AskUbuntu with some explanation of the history and plenty of links: https://askubuntu.com/questions/78958/is-there-a-difference-....
What is the practical difference between contributing under a CLA to a project that's currently under an open-source license and contributing under a non-copyleft open-source license while retaining the copyright yourself? In both cases the project's ability to "go closed source" seems substantially the same, so it seems to me that your arguments against signing a CLA apply equally to contributing to non-GPLed software projects.
Sometimes, CLAs are bad. Oracle loves CLAs. Sun Microsystems loved CLAs. Pretty sure you have to sign one to contribute to OpenJDK now...
Open source licenses can be just awful too. AGPL, for example. CLAs are not an immediate "no," but they should make you ask "Why am I signing this?" If you can't come up with a good reason, fine, don't sign it. But don't for a second think you'll get code into a project run by Oracle without signing one.
There's nothing wrong with this if it's what you want to do especially say if it's for work. But depending on your priorities, it may not be in your best interests.
That's not true. With most CLAs, you retain all rights to your submission. You just give the maintainer a very generous license. I haven't seen a CLA that requires you to give up any rights to your own contribution.
If the maintainer decides to switch to a closed source license, you are free to fork and maintain an open source version with your changes.
This is the difference to copyright assignment. If you produce something as contractor or employee, usually whoever pays for your work owns it, and you can't go and publish your work under an open source license.
Indeed, but submitting a contribution under an MIT-style permissive license grants that entity a very similar set of rights.
Not my experience at all.
> Oracle is practically a textbook example of why this is usually a bad thing for developers/users.
What would have happened differently there if people had contributed under an MIT license instead of signing a CLA?
https://opensource.org/licenses/MIT
If you change the license, all of the original work must still be distributed under MIT and only the work done after the cutover can use a new license. The GPL differs in that the new work must also be licensed as GPL.
That's pretty meaningless given that there is no obligation to distribute the source code to the new version, or to provide any way that "substantial portions" that are used in the new version can be extracted and used separately from the new-license work.
Meanwhile if you contribute to a currently-MIT-licensed project under a CLA, you have a copy of the current version under the MIT license and can continue to redistribute that indefinitely.
So what practical difference does it make?
Hopefully they can't relicence retroactivelly, so the previous version of the software stays available, but any following versions can be entirely closed source (but they keep your MIT licence notice).
My understanding of MIT and other permissive licenses like it is that if I license that code under the MIT license, I can never "undo" that (for the code as it existed in that moment), even if I own all the copyright to a work myself. So a CLA cannot override the MIT license in that way either.
The "without limitation" part of the MIT license guards against this doesn't it?
>The "without limitation" part of the MIT license guards against this doesn't it?
Ah, but it reads "without limitation [...] subject to the following conditions"
MIT already allows sublicensing, so a CLA for an MIT project (assuming nothing else shady is going on) really only buys them the ability to change future licenses to something incompatible with MIT (would that be called superlicensing?), and possibly remove your attribution in future versions.
That to me is philosophically what I want out of a permissive license, so I personally am fine with CLAs in those cases, however I can understand why some would be against that.
Read carefully:
>copyright notice and this permission notice
>MIT already allows sublicensing
IANAL, but sublicensing can only impose additional clauses, it cannot roll back any grants or restrictions of the original license.
>IANAL, but sublicensing can only impose additional clauses, it cannot roll back any grants or restrictions of the original license.
Yeah, so a CLA allows that to move to a "superlicense" kind of thing (still not sure if that word makes sense there), so they could rollback those grants or restrictions of the MIT license in the future, but they cannot do so for the past.
Which, I'm okay with in a lot of cases, as that is what I philosophically want from a permissive license. However I can see how many would not be.
Most non-copyleft open-source licenses have their own requirements that must be followed even when re-licensing.
Also, technically if you don't pay for code the copyright holder can revoke the license at any time. So if you sign a CLA the project can retroactively stop you from using your own code. Unfortunately, this is a major argument for projects to require a CLA in the first place.
I'm pretty sure this is a myth.
The license does have consideration.
You provide some code. The other entity (the project) provides attribution and other things depending on the specific license.
Promissory Estoppel only comes in to play if one side doesn't provide anything of value, and so the bar of consideration isn't met. But to my knowledge, licenses already meet the bar of consideration, so promissory estoppel doesn't matter.
Money isn't the only thing of value. The exchange of one good or service for another good or service is still consideration, no matter what. And "attribution" and "the promise to hold harmless" are of value.
(IANAL and obviously this comes with the usual truck full of caveats that all legal issues do, but this is my understanding of the general state of US law at least.)
There are two issues (at least).
The first is that some such licenses may be "bare licenses". A bare license is a license to use someone else's property that is not coupled with an equitable interest in that property. Bare licenses can be revoked at will unless they state they are irrevocable.
Of course, you could have a bare license, and separate from that a contract with the copyright owner in which the copyright owner agrees not to revoke the bare license, so a license being a bare license is not necessarily a big deal except when it stands alone. I think that such an associated contract is reasonably likely to be found in most cases.
The second, and more serious issue is where does your license come from when you use FOSS software? This, as far as I know, is largely unexplored in the courts.
Let's say I've released Foo under a FOSS license. The license says it is irrevocable. You get a copy of Foo from me. You've got a license to Foo, from me, and it is yours forever.
Now you give a copy of Foo to Bob. Where does Bob's license come from?
There are two possibilities. (1) It comes from me. Whenever you, or anyone else, no matter how many steps removed from me distributes Foo the recipient automatically receives a license from me. (2) The Foo license allows sublicensing, and you use your sublicensing right to create a license for Bob.
The big question is what happens if it some point I announce that I am no longer issuing new licenses.
The sublicensing case is the most clear. Everyone who already has Foo retains they license (remember, I made the Foo license irrevocable). Their licenses allow sublicensing, so they can continue to distribute, giving their distributees a license (which includes the sublicensing right).
Unfortunately only a couple major FOSS licenses, I believe, allow sublicensing (Apache and MIT). Most of the rest either are silent on it or explicitly say it is not allowed (GPL).
So lets assume non-sublicensable Foo...Bob gets a copy of Foo from you after I have purportedly stopped issuing licenses. I sue Bob for copyright infringement. What is Bob's defense?
Note that I am not attempting to revoke the irrevocable Foo license with anyone--I'm just trying to stop create new* Foo licenses with anyone else.
Bob can't really argue that you gave him a Foo license, because the Foo license does not allow sublicensing.
I think Bob is going to have to argue that there is a contract between me and you, and part of that contract is that I will issue new Foo licenses to anyone you give the software to, and by not issuing Bob a license I'm in breach of my contract with you, and that Bob is a third party beneficiary of my contract with you, and has standing to counter sue to enforce my contract with you to issue him a license. But third party beneficiaries only have standing when they are an intended beneficiary, not when they are incidental beneficiaries.
It would be a big, very unclear, mess.
There's not much in the way of substantial requirements that can be effectively included in a non-copyleft license, because to grant rights to end users in ways that will ensure that they can actually exercise them you have to put significant restrictions on the distributor. E.g. the LGPL managed to be "copyleft enough" to be incompatible with app stores, and still offers the end user very little that they wouldn't get from an MIT-like permissive license.
So Linus can all of a sudden say that Linux is no longer GPL?!
> I did not say that, nor do I believe it, nor is it really related.
Not even Stallman believes this [0]. He has even explicitly endorsed the use of a "lax license" when pragmatic concerns justify it [1].
[0] http://openbsd-archive.7691.n7.nabble.com/Real-men-don-t-att...
> I did not say that, nor do I believe it, nor is it really related.
Sorry for putting words in your mouth, but that's kind of how it came across as I read it.
But what if somebody was changed the license from BSD to proprietary after you've contributed to the project? Would you still be happy about it then?
I think the idea was: I have my code contributed under BSD, so you cannot re-license my code without clearance from me.
If you want to contribute under your secret license, what it means is that you don't want to spend any time in the first place contributed to the BSD-licensed project. Make your changes and use them, but don't contribute them back. The BSD license permits this fully, including your ability to distribute and sell the resulting software, subject to the advertising clause as appropriate. So it's not like there's anything onerous about this idea.
I understand what you're saying, but even if you do release BSD software along with code under a different license, you are still bound by the (very minimal) requirements of the BSD license.
To do this, the actual copyright ownership has to be transferred. A copyright licence is a grant of permission by a copyright owner who retains that ownership. It is not a transfer of ownership.
* http://uscode.house.gov/view.xhtml?path=/prelim@title17/chap...
2. As the code is not relicensed you have to follow the terms. Generally for example even BSD licensed code (other than BSD0) requires that you include attribution both in source code and binaries or documentation, so you need to keep a full list of licenses and authors and list them out in the docs.
There is no way they can change the past - my contribution is still open source and so is the project up until the version where they introduced the license change. The version I made my contribution to is still BSD but the current upstream master might not be.
In my experience, a lot of the projects with large numbers of CVEs also have a rather sprawling project with lots of things that can (and should) be disabled if they don't apply to your environment; most of the CVEs will happen in parts you don't use. (That's clearly not the case for all projects, openssl is a joy to have as a critical dependency, but there are some options now)
In such event, you can still distribute the existing source code, or fork the project in order for it to remain BSD-only.
If you signed a CLA then presumably you're either happy about it or you've just signed a contract you had literally zero understanding of.
If you're more concerned about getting your fix in upstream or the kudos that comes with being a committer to "x project" then yeah, you probably wouldn't mind.
I personally view Microsoft's use of CLAs as a trap that highlights just how disingenuous their "turning over a new open source leaf" was but I don't really have a problem with open source projects using them in general. The maximalist approach to open source would mean a lot of really great open source would never get written. Authors have gotta eat.
> This is not the case of all open source licenses. And that is fine. Don't assume all my work has to be part of your crusade.
Indeed, I've contributed to one open source project with a CLA, it had an Apache v2 license... So It didn't really seem to make any practical difference to that license. The very short agreement basically just made it explicit that they are not responsible of a contributor submitting code they don't own copyright to - which seems a little overly defensive but fair enough as Apache doesn't explicitly protect against that.
That said, I don't like the barrier CLAs impose on open source projects. Has anyone seen GPL+CLA in the wild?
This is often times called a "DCO" — Developer Certificate of Origin. I think that is a better name for these, as the term "CLA" is very much associated with the controversial copyright reassignment/relicensing clauses.
Does FSF copyright assignment count? They do that on many of their projects (including Emacs).
He even concludes: "if you are contributing to open source and you want it to stay that way, you should not sign a CLA."
if, if, if.
I generally agree with you (!), BTW, but the author does a great job justifying the when and why of his own opinion, and I find it sound.
IOW, if I want to contribute back because I don't want to maintain a private fork or spearhead a public fork, I just want to be done with it, totally fine, even by the author's opinion, which is fully qualified with the statement "and you want it to stay that way". This is reasonable and not at all forceful like Stallman.
You are reacting to something that isn't written nor implied.
>This is not the case of all open source licenses.
false. open source is literally just a friendlier name and otherwise rebranding of free software. all open source is free software and all free software is open source. if you are contributing to FOSS qua FOSS, then you want it to remain FOSS. FOSS refers to that software which guarantees your right to change it, so if you are making changes, you clearly benefit from it remaining FOSS.
note further the game theoretic implications: if a minority of projects use CLAs, it is possible to avoid contributing to such projects. If people are willing to contribute to such projects, then their number might expand. Those interested in the continuation of FOSS, which should be anyone, especially those interested in software development, should therefore be interested in not signing CLAs.
This is not how anyone I have ever talked to thinks about it. You are probably confusing Free Software[0] with open source software[1]. If you still hold your point we are arguing semantics and stating that your interpretation (a minority interpretation) is right and that most of the software industry and open source community is wrong.
> if you are contributing to FOSS qua FOSS, then you want it to remain FOSS
Not necessarily.
> note further the game theoretic implications: if a minority of projects use CLAs, it is possible to avoid contributing to such projects. If people are willing to contribute to such projects, then their number might expand. Those interested in the continuation of FOSS, which should be anyone, especially those interested in software development, should therefore be interested in not signing CLAs.
You're completely right. Important factor to be aware of as a contributor for sure.
[0]: https://www.gnu.org/philosophy/free-sw.en.html [1]: https://opensource.org/osd
But in practical terms, "free software" and "open source software" as used by the FSF and the OSI describe the same set of software. Consider their respective license lists:
https://www.gnu.org/licenses/license-list.html https://opensource.org/licenses/alphabetical
OSI #5-10 are kind of a spelled out form of Freedom 0
OSI #2 maps pretty much directly onto Freedom 1 (The title of OSI #2 just says source code, but the body text specifies more)
OSI #1 is Freedom 2
OSI #3 maps to Freedom 3, with #4 being a clarification of what is allowed.
>Not necessarily.
Perhaps you missed the "qua FOSS"? This is latin for "because it is", in this context "contributing to FOSS because it is FOSS".
the osd guarantees the relevant right for an individual to change the software. if you apreciate this right, then you should work to preserve it.
Can you provide a quote where he says or implies such a thing?
And this, regardless of how you weigh the post's other objections to a CLA, is a very good reason to sign one for many contributions.
> Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors.
This is not the case of all open source licenses...
Wrong. FOSS = Free Open Source Software, which is really redundant, because all Open Source Software is Free Software. Open Source is essentially the marketing branch of Free Software. The Open Source Definition, and the Four Freedoms are basically the same thing. The only difference is that Open Source cares more about being practical, and Free Software is trying to save the world.
EDIT: I am always surprised by the number of people on HN who seem to not understand this. I know there has been a push the last 10 years or so against copyleft, and specifically the GPL. I didn't think it extended to forgetting what these words in our industry actually mean.
It's exactly the opposite: All Free Software is open source, but not vice versa [1].
[1] https://www.gnu.org/philosophy/open-source-misses-the-point....
https://www.gnu.org/licenses/license-list.html#OriginalBSD
https://web.archive.org/web/20160116183019/https://opensourc...
I never heard of the “Open Watcom” license before. But if it really does not allow modified copies to run locally then it is violating criteria 1, and 3 of the Open Source Definition. I am surprised the OSI approved it.
* http://perforce.openwatcom.org:4000/@md=d&c=GxS@//depot/open...
As you can see, it says the opposite. Per §2 you must publish your modified source if you deploy it per §1 in ways including "any and all internal use or distribution of Covered Code within Your business or organization except for R&D use and/or Personal Use".
Richard Stallman dislikes the idea of being forced to publish source code when the modified application is being published internally within a business. Ironically, and rather confusingly, being required to publish source in such additional circumstances he deems "too restrictive", right after calling open source licensing "looser" than free software. (Pick one direction for the metaphor and stick with it, M. Stallman. (-:)
This oddity comes about because freedom is also the freedom to not give one's software source code to other people. Whereas the Sybase licence makes it mandatory to publish modified source even when the compiled modified software is not being given to the public at large.
It's not hard, furthermore, to see why terms that require giving people the source code in more circumstances remain compatible with the principles of open source.
I guess it really comes down to Criteria 1 of the open source definition being worded as "...shall not restrict any party from selling or giving away..."
But this is surely an oddity. It's almost like someone went out of their way to come up with a license to prove they're different.
As they say, not all open source is FOSS. And some people are OK with that. Let them contribute, as long as they are aware of the implications.
When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged upstream than having to maintain our own private fork.
> Free and open source software licenses grant explicit freedoms to three groups: the maintainers, the users, and the contributors.
This is not the case of all open source licenses. And that is fine. Don't assume all my work has to be part of your crusade. I will save that for the parts of my life where it makes sense - I am all-for the FOSS movement but there is no need to go full Stallman and say that everything but GPL is evil. If I believed that, I wouldn't be working on a closed-source project in the first place and then this piece would be fully relevant.
A much better title would be "Why I don't sign CLAs" or "The dangers of signing CLAs".