Despite the assumption of some newer open-source developers that
sending a pull request on GitHub “automatically” licenses the
contribution for distribution on the terms of the project’s existing
license—what Richard Fontana of Red Hat calls
“inbound=outbound”—United States law doesn’t recognize any such
rule. Strong copyright protection, not permissive licensing, is the
default.
That isn't quite what I mean by "inbound=outbound". Rather,
inbound=outbound is a contribution governance rule under which inbound
contributions, say a pull request for a GitHub-hosted project, are
deemed to be licensed under the applicable outbound license of the
project. This is, in fact, the rule under which most open source
projects have operated since time immemorial. The DCO is one way of
making inbound=outbound more explicit, and I increasingly think one
that should be encouraged (if only to combat the practice of using
CLAs and the like). But under the right circumstances it works even where the contribution is not
explicitly licensed (I think this is what Kyle may be
questioning). There are other ways besides the DCO of creating greater
certainty, or the appearance of greater certainty, around the inbound
licensing act, such as PieterH's suggestion of using a copyleft
license like the MPL, or the suggestion of using the Apache License
2.0 (whose section 5 states an inbound=outbound rule as a kind of
condition of the outbound license grant).
Thanks for this comment! I'm glad somebody told me this was on HN.
It's a problem with the sentence, which I'll correct shortly. I wanted to mention inbound=outbound, and tried to do so in passing, in the middle of a sentence performing other work. It ends up reading like inbound=outbound is the assumption about GitHub and fora like it, rather than the governance idea of same terms in and out. I definitely don't want to dilute the term or the idea as you've developed it!
I _do_ question whether US courts will reliably imply inbound=outbound when the contributor is silent on license. There will be circumstantial and perhaps specific conduct evidence for abandonment, estoppel, or both. But that's the same line of thinking that applies to unlicensed projects. Not good enough.
For what it's worth, I support the idea of the DCO, but never recommend it. I'd like to think my criticisms are best summed up in the alternative I've been working on:
It was an excellent article. I'd have liked to have seen more on sublicensing vs. direct licensing, but that's probably a big enough subject that it deserves its own article.
In particular, I don't think there's been enough discussion on what this means in the case where the copyright owner decides that they no longer wish to have their code distributed under the original license.
If I distribute my code under a license using the direct model, and subsequently announce that I'm no longer granting licenses, and you (who obtained my code before I made that announcement) distribute a copy, I think there is little question you are OK. You've got your direct license from me. But what about the person you distribute to? I think they would be OK to use it, but I'm not sure they could redistribute.
Maybe someone could make an argument involving third party beneficiaries that could force me to license your recipients under the original license, but that's going to be an ugly fight.
If I had originally used a license that allowed sublicensing, wouldn't things be a lot cleaner? People you distribute to after I stop issuing new licenses would simply get their license from you via you exercising the sublicensing right I gave you.
Some free/open licenses now say in the license text that they are irrevocable, which would seem to address this problem, but thinking about it more I'm not so sure. If my original license using the direct model said it was irrevocable, does that really mean I have to keep granting new direct licenses to anyone who obtains the software from a prior licensee, or does it just mean that I cannot cancel the license of someone once they obtain a license from me?
But a pull request on github invariably come from a branch that has the same license file. Before you can even make a pull request you have to publish your changes, and that version is clearly licensed by the license file.
A better example would be emailed patch sets, which are still popular in some projects.
Good point about github pull requests, I've made that argument as well recently. It's somewhat akin to Pieter's point about MPL. Github gets criticized for the phenomenon of 'POSS' (post-open-source software, https://en.wikipedia.org/wiki/Post_Open_Source), but there's a sense in which the Github workflow has provided greater clarity around licensing of diverse-contributor projects that are sufficiently explicit about outbound licensing.
This is a really good article. There's one part in particular that struck me:
"Despite the assumption of some newer open-source developers that sending a pull request on GitHub “automatically” licenses the contribution for distribution on the terms of the project’s existing license—what Richard Fontana of Red Hat calls “inbound=outbound”—United States law doesn’t recognize any such rule. Strong copyright protection, not permissive licensing, is the default."
In other words the fork + pull request + merge flow does not work on a project unless you have an explicit step like a CLA, or an alternative solution.
We faced this problem early on in ZeroMQ, that asking contributors to take this extra step increased the work for maintainers (to check, is this the first time person X contributes, and have they made a CLA?) It also scared off contributors from businesses, where this often took approval (which took time and was often denied).
Our first solution in ZeroMQ was to ask contributors to explicitly state, "I hereby license this patch under MIT," which let us safely merge it into our LGPL codebase. Yet, again, another extra step and again, needs corporate approval.
Our current solution is I think more elegant and is one of the arguments I've used in favor of a share-alike license (xGPL originally and MPLv2 more these days) in our projects.
That works as follows:
* When you fork a project ABC that uses, say, MPLv2, the fork is also licensed under MPLv2.
* When you modify the fork, with your patch, your derived work is now also always licensed under MPLv2. This is due to the share-alike aspect. If you use MIT, at this stage the derived work is (or rather, can be) standard copyright. Admittedly if you leave the license header in the source file, it remains MIT. Yet how many maintainers check the header of the inbound source file? Not many IMO.
* When you then send a patch from that inbound project, the patch is also licensed under MPLv2.
* Ergo there is no need for an explicit grant or transfer of copyright.
I wonder if other people have come to the same conclusion, or if there are flaws in my reasoning.
For Microsoft GitHub repos, there's some kind of automated tool that enforces CLAs. Whenever there's a new pull request, it checks whether the author is a Microsoft employee or not. If not, it checks whether there's a CLA for that person, and if there isn't one, posts a link to a page that handles signing, and records the result for future uses. Repo owners are also notified accordingly.
It also seems to have some kind of threshold for code size, because for small contributions, it says that CLA was not required.
You can see it in action from users' perspective in pretty much any repo under https://github.com/Microsoft/, if you search for "MSBOT" in pull requests. E.g.:
And note the Microsoft CLA says "you grant Microsoft a patent license covering your contribution", while Microsoft grants no patent licenses over (edit: most) of their open source code, and are currently profiting from patent licenses against open source code in android etc.
When it comes to patents, MIT is a closed source proprietary license, while Apache 2.0 and GPL are open source and free software. All these companies spewing bs about how open MIT is bugs me to no end.
It takes a really warped interpretation of open source to claim MIT is a closed source license. Not even Stallman agrees with that. In his essay on selling exceptions to GPL he gave this argument[0]:
"
If that implication is valid, it would also apply to releasing the same program under a noncopyleft free software license, such as the X11 license. That also permits such embedding. So either we have to conclude that it's wrong to release anything under the X11 license -- a conclusion I find unacceptably extreme -- or reject this implication. Using a noncopyleft license is weak, and usually an inferior choice, but it's not wrong.
In other words, selling exceptions permits some embedding in proprietary software, and the X11 license permits even more embedding. If this doesn't make the X11 license unacceptable, it doesn't make selling exceptions unacceptable
"
It seems everyone except you, including the father of copyleft, agrees that the MIT license is a free and open source license.
And many open source developers are just fine with that. If someone finds a use for my code and even if they make lots of money off it then good for them. It's not like they've stopped me from using it in the original form. I've also had cases at work where we want to use open source and copyleft licences have caused clueless managers to get panicky despite the fact that we don't redistribute anything, only make use of it internally. They also often initially tell me not to contribute anything back but after the work is done and I explain multiple times about the effort of porting the changes to subsequent newer releases they agree (often with the proviso of using my personal e-mail). In summary, I don't follow the RMS line of closed source being morally evil or whatever so a license like ISC or MIT is the best practical match to my wishes when I release stuff.
Most of the big MIT licensed Microsoft projects I know (.Net Core VM and libraries) are licensed under MIT with a separate, explicit patent grant. For example look at the PATENTS.TXT file in this repo: https://github.com/dotnet/corefx
Interesting. It's a non-legally binding patent promise. But honestly, I think MS has waded too far into open source to have the bad publicity of breaking that promise, unless MS gets into very bad finances. Anyways, good enough for me.
And it actually makes my point about the MIT license, it's inadequate for patents.
According to these links, they will probably work in an actual case. They can be revoked at any time, making them inapplicable to future patent use which was not already going on for some period of time.
Definitely not anywhere near as binding as the MIT license, but it's not a good comparison anyways, MIT addresses only covers only copyright and patent law is a very different and separate area of law.
> It also seems to have some kind of threshold for code size, because for small contributions, it says that CLA was not required.
That's because all this copyright stuff is needed only for things that can be protected by copyright in the first place. One of the elements required is creativity of the work and if you only make a trivial change, e.g. Adding an obvious make file rule or adding a file to a project, that's not creative (there's just one obvious way to do it), so not protected, so not needing a CLA.
> In other words the fork + pull request + merge flow does not work on a project unless you have an explicit copyright assignment step (CLA), or some alternative.
> I wonder if other people have come to the same conclusion, or if there are flaws in my reasoning.
Unfortunately, it doesn't work the way you've hoped. Although there are some licenses (e.g., Apache) that purport to apply automatically to new code submitted to the licensed codebase, the MPL doesn't make that claim, and such clauses are legally dubious anyway.
So just because I write some code that can be applied as a patch to your MPL-licensed codebase, my code is not automatically subject to the MPL. By default, I hold the copyright, with all rights reserved, and the MPL license on your code does nothing to change that. You still need explicit agreeement from me to place my code under a compatible license.
Github, Gitlab, et al., should really put a checkbox on pull requests that says, "I hereby license this code under $REPO_LICENSE."
Actually, you're wrong about the MPL. The MPL is a file based copyleft license, the share-alike clause applies to any modifications made to a file already containing MPL'ed code. This is only an issue when you add new files to the project, and any MPL project should be vigilant about accepting patches to ensure new files added contain the MPL header.
Yes, there's a good argument that the license would apply automatically to modifications to an existing file, but even in that case it is somewhat questionable. Is the modification substantial enough that it could be considered a new, stand-alone, derived work? If so, the pre-existing license may not apply. Was the modification submitted as a patch in a file format that does not incorporate all of the pre-existing code? If so, it may be a new, stand-alone work to which the pre-existing license does not apply. Etc., etc. Very little of this stuff has been well tested in court, so there's a lot of room for facially plausible legal challenges.
And it's fairly clear that new files are new works. So, really, in all cases, unless you're getting an explicit statement from contributors that they have placed their contributions under the relevant license, there will be a a lot of uncertainty about whether they really have been—particularly if the contributor (or his or her employer) later challenges your claim.
That's why Github and other platforms for projects on the pull-request model should really build explicit consent to licensing into the process.
> And it's fairly clear that new files are new works. So, really, in all cases, unless you're getting an explicit statement from contributors that they have placed their contributions under the relevant license, there will be a a lot of uncertainty about whether they really have been
For a project using the MPLv2, new files added to the project would include the following header at the top:
> This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/.
Yes, absolutely a code file can be transformed enough that the original license no longer applies. Copyright law in the United States applies the same tests to code as to textual works and works in other media: is the transformation substantial enough to consider the transformation a new (derived) work, copyrightable in its own right? If so, its author holds its copyright completely independently of any copyrights or licenses attached to the work from which it is derived.
The case law on what constitutes a new, derived work is not at all well developed in the context of software. But looking at analogues from other media—and that's what the law does—it is easy to imagine that a very substantial refactor, touching basically every line, or a less substantial refactor with substantial additions, might qualify as a new, separately copyrightable work.
The claims of copyleft are almost entirely untested in court, and it's very likely that many of them will prove empty if they're ever challenged. Indeed, many of copyleft's claims, those which place obligations on users and contributors, are more TOS-style claims than claims that look like ordinary "reserved rights" under copyright law, and therefore presumably have a legal basis of enforcement in contract law, not in copyright law.
Explicit agreement by contributors to be bound by a license, however, covers most bases, whether the license is interpreted as a license per se, pursuant to copyright law, or whether it's ibstead interpreted as a contract under contract law (or both).
I was discussing this once with the maintainer of an MIT licensed scientific software. The solution in the end IIRC was to require all first-time contributors to agree in writing to a Contributor Agreement that states (among other things) that all code submitted to the project would be licensed under the project license.
It's not much of an obstacle really, just whenever someone submits a PR for the first time, say "I'll look at your code and comment anything that may need improvements. Also, you have to agree to these conditions [link]."
I imagine that issue will give some lawyers a hell of a time if it comes up, because by sending someone a pull request on GitHub you're actually sending them a copy of the modified file including any header claiming that the contents are under the MIT license or whatever other license it was under - even though the pull request displayed as a simple diff. Except that behind the scenes it may be stored as some kind of diff again.
> It also scared off contributors from businesses, where this often took approval (which took time and was often denied).
This is one of my biggest reasons for not working at Google/Facebook/etc. I really don't want to have to get management approval for every random PR I submit in my free time.
For people working at big companies, how do you handle this? Do you just stop contributing to open source?
I'm not from the US and don't know the US employment law, but you generally don't have to ask permission from your employer on things you do in your free time.
Unless you signed a contract that specifically forbids you from contributing to open source / other software projects (why would you do that? what is the exact wording? is such clause even legal?), your free time is your own, to freelance or work for other employers.
Working on open source on your employer's time and money is a different thing, and asking for permission makes perfect sense there.
> I'm not from the US and don't know the US employment law, but you generally don't have to ask permission from your employer on things you do in your free time.
Employment contracts for developers in the US, particularly at big companies, are very broad and try to lay claim to any development work you do (regardless of whether it's in your "free time" or not). They often expressly forbid freelancing or open source work unless it is approved by the company.
In most European countries those type of clauses are anyway invalid, even if written in the contract, as the company doesn't have a say on how you are supposed to live your private life.
Small correction, but a CLA is a contributor licensing agreement, not a copyright assignment. The contributor still owns the copyright to their code, they've just explicitly allowed the project to license their code under the terms of the project license.
Depends on the CLA. Many CLAs (for example the one that RoboVM used that allowed them to switch their GPL licensed compiler to a closed source model more easily) do require copyright assignment.
> The phrase “arising from, out of or in connection with” is a recurring tick symptomatic of the legal draftsman’s inherent, anxious insecurity.
Indeed. I'm trying to imagine a court saying "Well... there were damages, but they arose out of the software and not from the software, so therefore- oh, wait! The license actually includes arising "out of" the software as well as "from" the software, so I guess the limitation of liability stands. Case dismissed!"
Lawyers are rather fond of such doublets and triplets. Consider free and clear, null and void, terms and conditions, and even law and order. The origin of a lot of legalisms is the historical confusion over language in ancient English courts: Latin, French, or English? Most odd legal grammar is actually of French origin.
It seems to be missing "aid and comfort" (from the clause of the U.S. Constitution about treason). Not sure if this is used anywhere else, but it seems similarly redundant from my non-lawyer perspective, in that if were only "aid" and not comfort, it seems absurd that it would be functionally different
> A legal doublet is a standardized phrase used frequently in English legal language consisting of two or more words that are near synonyms.
...
> power and authority
Should that really be on the list? Power is the capability to do something, authority is the permission to do it. Sometimes power and authority are near synonyms, such as in frontier areas with little government, but generally in a functioning, civilized society they are quite distinct.
I'd say you're quite optimistic in thinking that not little government implies power =/= authority, and quite pessimistic in thinking that little government does not imply a civilized, functioning society.
But even without getting into political debates which could get really nuanced, can't authority mean capability in this context? I'm not a native English speaker so I'm not sure, but I don't find it odd. It is also possible that these two words have different (Anglo-Saxon vs French) origin, as most of the examples listed, and that their original meaning was synonymous (of course, I'm far too lazy and tired to check that now).
Law is old; in Medieval times such redundancy was considered normal - usually triple - and was very common; presumably it was considered a literate flourish, embellishment and arabesque (sorry couldn't resist a go at it myself.)
While much legal jargon can be dispensed with because the intent is clear from simpler language, this one actually has some purpose.
"Arising from/out of X" implies that the claim was caused by X (here, the from/out of is redundant as you point out)
But "in connection with X" implies something more broader, merely that it has a nexus to X.
By joining the two, the drafter sends the signal that the intended scope is as broad as it can reasonably be. If it only said "arising from," some claims that only have a tenuous relationship to X do not fall within the scope. Parties may decide that they want the scope to be narrow, or they want to be be broad, and the language matters.
It's funny that the MIT license has the reputation of being "The license you choose when you don't care about attribution, or it would be unreasonable to require attribution".
As the article points out, copies of MIT licensed code must include not only the copyright line but the whole damn license.
Indeed, for works where I don't care about attribution for binary users I use the zlib license [0] which says "This notice may not be removed or altered from any source distribution."
You'd still have to include the notice in any source distribution, but that's not really as onerous in my opinion, since you're already having to distribute all your source files, so what's just one more notice.
Of course, my projects normally use a language with a compiler that produces binaries. I'm not sure how this would apply to a language that keeps things in source form like javascript. Maybe webasm will become the new binary form? asm.js? minified javascript?
You'd still have to include the notice in any source distribution, but that's not really as onerous in my opinion, since you're already having to distribute all your source files, so what's just one more notice.
But neither MIT nor zlib require you to distribute any source files. With zlib it's pretty clear what's expected, but with MIT, I'm actually not sure what attribution if any is required in a binary-only distribution.
Just to clarify my previous statement. I didn't mean to imply that zlib or MIT require you to distribute your source. I meant that if you are distributing your source code (for reasons other than any requirement from zlib or MIT licenses), then it's not too much of an additional burden to include the zlib license attribution, because you'd already be including the files that I had licensed under zlib, and each of those files has a little header saying it's licensed under zlib. Including the zlib license is then not much more work than including another source file from the project.
The way I've seen MIT interpreted most often is that you have to distribute the license and attribution even for binary only distribution, or distribution in binary form as part of a larger work.
But you're right the language does seem kind of vague on what "The Program" actually means.
That would be incredible, but if he spends 4600 words explaining those 171 words, I can't imagine the time investment involved in the GPLv2 (2910), GPLv3 (5644), or MPLv2 (2346).
Those licenses are very wordy, but not as dense. For example, about a third of the GPLv2 is the preamble that explains the FSF's "four freedoms" of free software philosophy and the ending section after the legal terms that explains how to apply the license to your own product. Cutting those out reduces the GPLv2 to only 2017 words of actual legal text.
I also feel like it might be easier to explain a more legalese license like GPLv3, MPLv2 or Apachev2. Like the article explains, the MIT license doesn't use the "language of the law" and uses more common language and language familiar to academics and programmers. A license written with more lawyer-oriented langauge, actually using the same wording as the original laws use, might be much easier for a lawyer like Mr. Mitchell to explain. I'm thinking it's an explicit vs implicit type situation, where even though some licenses are longer they define more things explicity, which means the explanation doesn't have to fill in as many gaps.
There are also plenty of simpler licenses that would be great for an explanation. And as part of a series, the author could assume that you are familiar with his MIT license explanation so as to not repeat the same things. Other good candidates I'm thinking would be the BSD licenses, the ISC license, the zlib license, maybe even Apache v2.
A bit off-topic, but I would be very interested in somebody making a case for why an OS license is better than a simple line like "This code is free for everybody to use as they wish." I've read about it plenty, but remain unconvinced.
The OS software I write is for the good of everybody, not just its own popularity or the OS community. I'm fine with all uses of it, in whole or in part, whether or not I'm credited. The license reproduction requirement therefore feels like unnecessary noise, and I'd like to think that courts are sane enough that the warranty disclaimer is unnecessary too - is there any real court case where somebody has been sued for a defect in free, OS software, without an explicit warranty, and lost?
One thing to consider is that some provisions (and overall clarity) protect users of your code. The best example is including patent grants in the license terms (like those in Apache v2 and GPLv3) that may not be covered in that one liner.
There's also provisions (or implications thereof) that can protect the community around your project, like how the Apache license includes a clause that specifies that contributions back to the project are assumed to be under the Apache license by default.
Not a lawyer, but I always thought maybe someone could take your code, modify it to produce variations A, B, C, the three major use cases of your code, and slap patents on those modified versions of your code. So then anyone who wants to use your code with any of those three use cases in mind (i.e., most people who would want to use your code) would then likely be in trouble.
Or something like that.
A second issue would be one the author of the article seems worried about, which is that without a warranty-free clause people might sue you for bugs in the code. If you're distributing your code, with a line like "free for everybody to use," there may or may not be implicit quality guarantees, according to the article.
Every company that releases free software has a legal department, and that legal department usually advises them to:
1. Use a proper license (drafted by lawyers).
2. Include the license information in every source file.
3. Reference the license in the documentation / metadata.
Now, is this overly cautious? Maybe. But I think that following what an actual legal team's recommendation is is much more preferable to doing anything else.
Not to mention that company lawyers will be very worried about code under a license as brief as the one you wrote (especially since it was not written by a lawyer). So just use CC-0 or something and call it a day if you really don't care -- it is never a good idea to write your own license and it will actually result in less people using your code because they cannot be sure it would be interpreted as a free software license.
If you use an already established license people know what to expect and can easily reuse your work, do-it-yourself licenses frequently run into problems of being imprecise and needing further clarifications. A lot of jurisdictions also don't allow you to easily release something in the public domain, you automatically retain some rights even when you don't want them, the license has to explicitly state that you waive those rights.
I'm not sure about the what advantages the MIT license has over your one-liner, but some people (eg Stallman) believe in using more restrictive mechanisms like https://en.m.wikipedia.org/wiki/Copyleft, and your one-liner is inadequate for them
"This code is free for everybody to use as they wish", but it doesn't state that it is free to distribute, free to modify, free to sell copies, so I wouldn't consider this an open source license. I'm not a lawyer and already I've found holes.
It sounds like you want to place your code in the public domain rather than publishing it under a permissive copyright. Have you looked at the unlicense?
These licenses have little flaws upon closer examination. One day I was reading the BSD license closely, in the context of its use in the TXR project, and was astonished to find that it was buggy and required tweaking to make it more internally consistent and true to its intent. I added a METALICENSE document where the changes are detailed:
The main problem is that the original says that both the use and redistribution of the software are permitted provided that the "following conditions are met", which is followed by two numbered conditions, 1 and 2. But the two conditions do not govern use at all; they are purely about redistribution! Rather, the intended legal situation is that use of the software means that the user agrees to the liability and warranty disclaimer (which is not a condition). But the BSD license neglects to say that at all; it says use is subject to the conditions (just that 1 and 2), not to the disclaimer.
You shouldn't touch these licenses unless you're a professional.
I'm no lawyer either, but I believe that clauses such as "use of this software constitutes agreement to" change its nature from a license grant to a contract.
I have no idea what the practical difference could be, but I don't want to find out, either.
Additionally, making changes in licenses makes it harder to reuse code. The license may be incompatible or it may just run afoul of procedures in larger organizations who sometimes have whitelists of approved licenses.
> I believe that clauses such as "use of this software constitutes agreement to" change its nature from a license grant to a contract.
I have thought about this potential issue, and concluded that it is quite obvious that the text effectively says "Use of this software constitutes agreement with the fact that it is not a contract, as spelled out in the disclaimer, which clearly asserts the non-existence of anything resembling contractual obligations."
(Agreement with the fact that it's not a contract is not itself a contractual obligation.)
[EDIT]
Ah, okay, wait. Here is another way of looking at it. We have a certain piece of text (the disclaimer) which we hope is somehow in legal force.
Either it is in force when someone in a given jurisdiction uses the software, or else it isn't. Or maybe some of it is in force. Whatever.
Whether or not it is in force or to what extent doesn't depend on whether the user agrees with it; it depends rather on the laws of that land.
Therefore, use doesn't have to be conditional on it; the license doesn't have to assert "if you don't agree with the disclaimer the license grant is off the table".
If the user doesn't agree with the disclaimers and goes ahead and uses, we would like the license grant to still be on the table (which is, in fact, neither here nor there, this being free software) but we would like the disclaimers to be in force anyway.
In that case, I might as well just go back to the original BSD license then.
The point of the liability disclaimer is that if someone, say, uses the software and happens to lose data due to a bug, the authors (original ones or downstream modifiers or whoever) are not held liable. That requires agreement; it has to be spelled out: if you do not agree with this disclaimer of liability, then you are not licensed to use the software. If you use it anyway, it is an unlicensed use. This is exactly how it works in shrink-wrap EULA's in proprietary software; by opening the shrink wrap, or clicking on some button or whatever the heck, you agree to those things. (If that's a contract, then let it be a contract.) I'm confident that I nailed it to the way it should be, and that "constitutes agreement" is excellent wording.
The difference is that I'm covered, liability wise, better than someone just using the original BSD license, which has a possible interpretation that it allows the use of the software without the user agreeing to the disclaimers, since the license doesn't appear to require acceptance of the disclaimer.
From the developer's POV, that's the only part of a BSD-like license that actually matters. You've already given away the code, and allowed it to be used in proprietary code, so you're not going to be harmed by anyone stealing anything from you. At best, your code could be plagiarized: copied in source code form without you being credited, which isn't very significant. The one way you can be harmed, as in financially, is that someone wants to sue you because of some alleged bug in your code having caused some alleged loss.
By the way, here is how we can be certain that in the BSD license, the disclaimer is not one of the conditions which require agreement. It's because the second condition says: ".. must reproduce the above copyright notice, this list of conditions and the following disclaimer ...". I.e. the following disclaimer is clearly distinct from the conditions, and not one of them. Since it is not one of the conditions, it is not a condition! The license might effectively not be conditional on the disclaimer.
In contrast, in the GPL v2, the two disclaimers are one of the numbered conditions (11 and 12). There is nevertheless a slight flaw in the GPL v2 I just noticed. It introduces the conditions like this: "The precise terms and conditions for copying, distribution and modification follow." But unless "copying" is construed as use, conditions clauses 11 and 12 are not related to copying, distribution and modification. These disclaimers apply purely to use. A bug in the program isn't going cause harm while you're copying, modifying or redistributing it.
In the past I've seen misinformation disseminated about the GPL like "you don't have to agree with it to use the software", which is complete nonsense; you agree with the disclaimers when you use the software.
This reminds me of an anecdote about Godel, not sure if it's true or not, but here goes. When he was taking the Constitution exam to get the US citizenship, he proceeded to explain to the judge how he has a formal proof that the US Constitution is inconsistent and allows for a dictatorship to take over completely legally. Einstein was accompanying him and he somehow managed to quickly shut him up and continue to go through the motions of the exam.
It also, for some reason, reminds me of what Peter Thiel once said about physics PhDs: “Because they know fundamental things, they think they know everything.”
> This reminds me of an anecdote about Goedel, not sure if it's true or not, but here goes.
It's true, according to a recounting [1] by Oskar Morgenstern, one of two friends who were present at Gödel's citizenship examination to vouch for his good character (the other was Albert Einstein).
A single clause for emergencies in the Weimar constitution is what allowed Hitler (via Hindenberg) to assume dictatorial power, so Godel's concern wasn't abstract or abstruse, instead it reflected his recent European experience.
Well lwn.net says "The GPL is a license, not a contract", and that distinction makes a difference[1]. The same applies to the BSD license.
But whatever... Good luck. It's not like these things are the result of decades of lawyers scrutinizing every word.
Oh, regarding your other objection, i. e. the two requirements actually not applying to use but only redistribution, that is just a bit of convoluted logic to make the text shorter. Logically, it's:
>by opening the shrink wrap, or clicking on some button or whatever the heck, you agree to those things.
I don't see why anybody should take seriously the claim that doing something so simple that it can be done accidentally and without reading/listening/or communicating anything at all should constitute an agreement to anything whatsoever.
I wish people would stop telling me what I agree to and start telling me what they're willing to do if I violate their expectations, because that's what's actually intended by an EULA.
With regard to this specific situation, I have changed my mind.
However, the validity of click-through agreements or implied agreement when you use something does seem valid. It's applied all over the place, so lawyers must have come up with it and have a rationale.
Would you extend your reasoning to a signature? You can sign something without reading it. Perhaps not accidentally, though.
I do now agree with you that simply using a program doesn't constitute agreement with its liability disclaimers, even if the license appears to require it as a grant condition. Or rather, that is probably irrelevant.
> start telling me what they're willing to do if I violate their expectations
This is not easy in the case of disclaimers. Ok, you're violating my expectations because you ran into some bug that cost you money and are suing me (whereas my expectations were that you would understand that the program is offered "as is"). Poor silly me! What do I do? Lose and pay up, I guess, if that disclaimer doesn't hold up.
So basically, why bother. There isn't anything you can add to a license to increase the strength of any liability or warranty disclaiming text. Adding text like "using the program constitutes agreement with the disclaimer" serves no purpose.
Canadian courts have agreed in some cases, such as conditions that can't be accessed until a package is opened (this was some time ago, before software was commonly downloaded after purchase.) They have ruled such "contracts" unenforceable or illegal - I don't recall which.
Ah, that explains why TXR isn't more commonly distributed and used - it uses a custom license (which is probably a full-on contract now) and nobody understands it without having to ask a lawyer now.
TXR 151 is released now, and uses a stock 2-Clause BSD license again.
I made other changes, such as that for instance the license boxes in the Windows installer only have an "Acknowledge" button rather than "Agree". No mention is made anywhere that anyone has to agree to anything to use the software. A misleading diagnostic was also fixed in the program: if "txr --license" cannot find the LICENSE file it no longer falsely insinuates that the installation might be "unlicensed" (since there is no such licensing requirement that any copyright or license notice be present in executable images).
Whereas everyone understands the Windows 7 license, which is why that is so widely used.
You've hit the nail right on the head there.
Anyway, I only made these changes July 2014. I saw only a slight concern from the Fedora people, then haven't heard anything about it. (Actually they were more concerned with the sub-licensed MPI library whose README says that it is in the public domain, yet there are some stray copyright notices with "all rights reserved" text in the files.)
You're not writing Windows 7, is the thing, and there's other common tools in the area of text parsing/mangling which have much more standard licenses.
To frame things more constructively, what imagined situation are you most concerned about?
"Here I am, using this program five years from now when, due to the licensing, <bad thing> happens."
What is <bad thing>?
For example, is it something you would suddenly like to do with the program, but are not permitted (yet would be if it used the original BSD license verbatim?)
The <bad thing> is this: "I've been using this nice program for a while now and started redistributing it, and now my organization/customers/whoever are giving me grief due to its weirdly modified BSD-ish license." Grief is grief, even if those people are inflicting it for an unsubstantiated reason (fear of the unknown).
Indeed. I'm an occasional packager for a small Linux distro, and there's a reasonable chance this counts as a non-free license with your modifications... which in this distro means we couldn't distribute binary packages and installing it from source would have to have a user manually enable non-free packages.
There's no bug there. Copyright is about distribution, not use, so the “use” part is probably unnecessary anyway. And the warranty part is not conditional upon the two conditions. The MIT license is practically the same, and the analysis given in the article does not make note of this supposed bug, so we can consider that lawyer-confirmed. IANAL, so it's just my understanding of the issue.
I remember people mentioning another possible bug in BSD licenses: if you try to split hairs, and depending on the way you do it, it's questionable if the sentence before the enumerated conditions is part of those conditions or not. If not, that sentence needs not be distributed in copies, so it makes the whole thing meaningless.
But licensing isn't purely about copyright! (In the area of proprietary software, it's not even important; the vendor has all the rights and that is clear from the beginning.)
A license is not simply a copyright notice, even if it is on free software. (Though of course it includes one.)
When you give stuff away for free, you can still be liable for harm arising from it. This applies in ordinary situations, like giving your neighbor an old toaster you don't want, and it causing a fire.
So the use aspect of the license with the disclaimer is equally necessary to the rights-granting part.
> If you try to split hairs, and depending on the way you do it, it's questionable if the sentence before the enumerated conditions is part of those conditions or not.
You raise and excellent point, and I'm going to fix it. I can't see any reason why it should not say "... the above copyright notice, all the introductory text which follows, this list of conditions ...". Really, why isn't it simplified to "this entire license". The GPLv2 cheerfully does this, with the wording "... give any other recipients of the Program a copy of this License along with the Program." That puts an end to any hair splitting about possibly omitted parts.
Ah, not quite so fast! If you write: “all the introductory text which follows”, that might be construed as meaning not the part between the notice and the text which follows these words. So we have to have a terminating condition for this recursion of uncertainty. I agree, “this entire license” is probably the best form.
But anyway, my point, in the above and in my other reply with the anecdotes, is that while you may be perfectly right from the stand point of common sense and logic, it may not translate to being legally right. Of course, I think you modifications are reasonable, but I have to agree with matt4077 – it creates problems and uncertainty for others, you're (I guess?) not a lawyer, and even if you were, they would still need to consult lawyers about it. It adds friction.
Licenses like MIT and BSD should be avoided due to the patent risk in favor of licenses that explicitly grant patent protection like Apache 2.0. The patent troll risk is just way too high. As rando said, companies like Microsoft are even open-sourcing code while raking in hundreds of millions from patent suits against open-source software. That this is even working for them shows the permissive licenses need to eliminate that tactic entirely.
I also think there could be room for something similar about code (but I haven't had time to read aosabook.org yet, so maybe that is wheree I'll find it.)
A note on the Crockford joke:
I think it is on IBM, not the lawyers: I think he describes somewhere the fun of getting a payment from IBM followed by sending an additional license entitling IBM to use the software for evil.
A very lovely article, I enjoyed it very much since it gives insight into the "syntax" of legal documents in the US.
This article brought up a point I find very interesting. The MIT license (and a bunch of other licenses as well) are very US-oriented when it came to their writing, provisions, etc. I'd love to read a similar article exploring licenses like these from a, say, European point of view. Would the same constructs hold up in a German court, for example. What language is missing or superfluous?
I can talk for France. I used to work in a lab depending from the CNRS and arriving there I learned about the French version of the GPL, BSD and LGPL, the CeCILL familly (CeCILL-A, -B or -C respectively) ( https://en.wikipedia.org/wiki/CeCILL )
They claim compatibility with GPL, BSD and LGPL and also that CeCILL was necessary for valid open source licenses in France. That made me raise eyebrows on many levels:
- Does it mean the GPL/BSD/LGPL is unenforceable in France?
- Does it mean the CeCILL is unenforceable in other countries?
- The CeCILL allows to relicense a work under a future revision of the license. I know some GPL projects do that, I personally am extremely suspicious of this possibility.
I raised these points but never got good answers from law specialists. The guys I could reach were specialized in "intellectual property valorization" and actually did not know anything about open source. They also made me realize in the french version of the law, the notion that copyright protects a source code is extremely disputable:
In France you can't patent or copyright an idea, and numbers and mathematical formulas are recognized as ideas. It is accepted that a computer algorithm is equivalent to a mathematical formula. Ergo, in a source code, you can't protect an algorithm but an implementation. That is, as I understood when pushing a bit more, variable names and whitespace structure are the only copyrightable things in a program.
My understanding is that an obfuscater or a code formatter would likely remove any copyright claim from a source code when it comes to french laws.
I wish we had an actually active Pirate Party or EFF to try push the limits over that nonsense.
AFAIK German courts specifically have hold up the GPL, but there are some interesting points with other open-source:
- CC0 exists because in German (and other countries') laws the only way for something to become public domain is expiry of copyright. CC0 puts it in clearer legal terms that you wish to give up all rights you can give up and not make use of all others.
- German law added a "Linux-paragraph" that made it clear that if you grant usage rights to everyone, you can relinquish the right for "appropriate" payment, which added legal security. (Otherwise, if I perform work for you and you don't pay me, I could attempt to force you to pay a fair rate for my work, after the fact)
- other licenses might not be as well-tested, and I've seen code offered under "MIT license translated and adapted to German legal concepts" or things like that. Which of course doesn't exactly make it easier to use in other contexts...
a) It doesn't meet the Free Software Definition or Open Source Definition. What if you want to use the software for evil?
b) Who defines what Evil is? What if the author sues you on the grounds that you're using their software for a perfectly legal activity, the morality of which is widely accepted by the general public, but which they personally disagree with? For example, many authors who have written these types of licences are pacifists who disagree with the actions of Western military forces. Are said military applications "Evil"?
It adds conditions which make it incompatible with GPL, and similar licenses. And in general, it adds a completely arbitrary and uncertain condition, i.e. you can't be legally sure about what you can do with such software, i.e. you can more or less be sued by the author at his whim.
This has been discussed many times before, so search for more details. But the gist is that nobody agrees on what good and evil are, and they are not legally defined terms. For example, some people consider deaths caused by their own country's military as net good, while others believe all military killing is unquestionably net evil. Most people consider blood transfusions good, while some religious groups consider blood transfusions evil. Etc.
The link provides the API on how to poll github repositories for license data, but is a far cry from being a reliable method in measuring usage.
Lets suggest following criteria for a survey:
1#, no duplicates. A survey with duplicate has no meaning. Github data in the blog post do not exclude dubplicates.
2#, no empty projects. A project with no data in it is not actually a project. The Github data do not exclude such projects.
3#, only project with code in them. A lot of github projects is text collaboration, like party planning, discussion around the latests online drama, and so on. Github data do not exclude those.
4#, only project with running code that is useful for at least 1 person. Random data, incomplete or abandon attempts is not actually "a software project". Github data do not attempt to run projects, and very much do not limit its data storage to only code that works.
To my knowledge, only one license survey exist that passes those criteria, and that one was based on the curated repository of Debian. The study showed GPL to be heavily favored (80%), but the study concluded that more such studies (and discussion on research methodology) is highly needed.
On my local machine (since I have texlive installed and each texlive package is a separate package in openSUSE ignore the fact that `LPPL` is the most popular). GPL-2.0+ is ~2x more popular than MIT (and all of the *GPLs together are ~4x more popular) in my admittedly small sample size of packages.
That isn't quite what I mean by "inbound=outbound". Rather, inbound=outbound is a contribution governance rule under which inbound contributions, say a pull request for a GitHub-hosted project, are deemed to be licensed under the applicable outbound license of the project. This is, in fact, the rule under which most open source projects have operated since time immemorial. The DCO is one way of making inbound=outbound more explicit, and I increasingly think one that should be encouraged (if only to combat the practice of using CLAs and the like). But under the right circumstances it works even where the contribution is not explicitly licensed (I think this is what Kyle may be questioning). There are other ways besides the DCO of creating greater certainty, or the appearance of greater certainty, around the inbound licensing act, such as PieterH's suggestion of using a copyleft license like the MPL, or the suggestion of using the Apache License 2.0 (whose section 5 states an inbound=outbound rule as a kind of condition of the outbound license grant).