Kyle Mitchell's blog is an excellent source for the intersection between copyright law and software. Some of his recent interesting posts were on the MIT License[1], his takes on 'open source'[2] and on the ubiquitous LICENSE file[3].
So I get that they equal Strictness with Pain. That's just the perspective of somebody who want to include free software in their nonfree software.
However I don't get why every copyleft licence get a minimum of two ?'s. They write that it is a measure of popularity and quality, but for example
"EPL-1.0 Best copyleft license. Clear patent license. Professionally drafted."
"GPL-2.0 Most popular “community” copyleft license. Can hire compliance pros."
Those have quality and popularity, but they still get a double ?? in Confusion?
Yes, that article doesn't read much like "Lawyer's perception of open source licenses" and more like "Licenses liked by companies”. Companies don't like copyleft or responsibility, and want a clear patent clause, that's it.
The pain rating is "how difficult is compliance" and the confusion rating is "do I trivially understand the concepts" (and apparently copyleft is hard). It was a bit of a disappointing read as I was expecting some more analysis than one-line descriptions.
edit: that was probably a bit unfair of me, since the author has dissected several free software licenses on their blog in separate articles, which I recommend reading
Why just companies? Surely the pain and confusion applies to anyone wanting to incorporate open source code into something else that may or may not carry the same licence. The patent granting is rather critical even to other open source projects.
Software patents are a US thing, and it's a good thing many don't care about them.
I should have said for-profit software instead of companies, really; the legal entity is quite irrelevant in this case. I said companies because they are entities that: 1) stand to be sued in case of license violations (you typically don't sue a hobbyist project) 2) have the perceived need to maximize profits, and as a consequence want to veer off from anything that might require releasing source code, which might offset a competitive advantage. Thus a hobbyist project being a licensing clusterfuck is a less critical issue, although it is of course an important one (and certainly, depending on the project’s popularity, there may be a vocal portion of people wanting to clarify the situation).
The pain and confusion ratings also do not go into the details which are useful for OSS projects, such as how do licenses interact with each other, how is attribution and re-licensing managed, etc. Not to mention the ratings do not differentiate between pain/confusion for the developer, and pain/confusion for other future developers (e.g. in case of a lib).
(I admit that I tend to forget that there is also hobbyist closed-source software, for reasons I never understand)
Software patents also exist in most of the EU and Asia as well, unfortunately. Check out one of the MPEG-LA license portfolios and look at the countries represented if you want your day ruined.
Because most for-profit closed-source software is made by companies. It's in their best interest to use Open Source libraries in their software - it's free work and they don't have to give anything back.
I've heard this again and again, and yet every time I see open source used by a company, there are patches being applied, compliance concerns and audits, and integration efforts.
Sometimes this effort costs less than writing the code yourself (such as integrating with a database), but not always.
> It was a bit of a disappointing read as I was expecting some more analysis than one-line descriptions.
Fair criticism. This was by design.
I'd originally set out to follow the table with a commentary section on each license. But judging by the first few sections drafted, that was shaping up to be a very long read. The pain-and-confusion bit is terse and cartoonish to begin with. Blocks of additional text weren't going to change that. So I erred on the side of brevity.
No, it wasn't unfair of you. He puts ?? for all the GPL variants while also saying it's easy to hire compliance experts. In other words, GPL is one of the most widely understood licenses and yet he finds it confusing.
The GPL variants are not widely understood. They are closer to widely misunderstood. But due to their popularity and importance, specialized experts who do understand them, well and in detail, are available for hire. Heather Meeker, for example.
I like the GPLs and what they stand for. In another post, also popular here on HN, I wrote:
> The last [great idea in open-source licensing], not found in The MIT License, builds off license conditions: “Copyleft” licenses like the GNU General Public License use license conditions to control how those making changes can license and distribute their changed versions.
In another post, again channeling my own thoughts and feelings, rather than those of a broader, abstracted business community, I wrote:
> As an attorney, for one, and a coder who came up on FSF software, for two, it kills me to see students and pre-exit programmers write off good licensing hygiene as unnecessary. It makes me queasy to read, via the closed, hood-welded-shut social network du jour, that "open source has won". How smoothly both disdain for "corporate interests" assailing community values, on the one hand, and utter disdain for the GPL, its politics and its moralism, on the other, roll off the tongue. It’s a cruel, cruel world.
Copyleft licenses are more complex than permissive licenses by design. GPL-family licenses add idiosyncratic style and politics to that mix. There is a whole body of signals and accepted practices filling in interpretive fissures in that complexity---for FSF projects, for Linux, for MongoDB (AGPL). Consider the recent "enforcement principles" release and the disagreements that led to it. Corporate copyleft users have to do that homework. Corporate permissive users get the night off.
> I don't get why every copyleft licence get a minimum of two ?'s.
Probably because of the patent uncertainty. You can copy the code legally and still get in trouble for using another entity's IP. Practically speaking, that will probably be more costly than a battle over copyright.
Every copyleft license gets at least a double-question-mark. I don't know for certain why he did that, of course, but experience has taught me that copyleft licenses are inherently more confusing than permissive ones.
Copyleft licensing is permissive licensing with additional conditions. Larry Rosen made this point with his Academic Free License and Open Software License. They're the same form, with just one difference, in 1(c). That difference turns the AFL, a permissive license, into the OSL, a copyleft license.
Copyleft license conditions beg interpretive questions about what actions trigger copyleft requirements and what actions satisfy those requirements. Common copyleft licenses differ in their triggers and requirements, as well as how they express them in the legal text.
No, they are not confusing. Nothing is confusing about copyleft, especially to a lawyer. I mentioned offhand the concept of copyleft to my completely non-technical lawyer mother, who hasn't looked at copyright law since she was at university in the 1970s and she immediately understood the concept. It's a very obvious concept.
They're not liked by companies that want to be able to take everything for themselves and never give back. This article is just typical anti-copyleft FUD.
I'm a committer to a major piece of open-source software, and author of many more pieces of open-source software. I think it's pretty difficult to call me someone who wants "to be able to take everything...and never give back".
And I've talked to lawyers! And I still stay far away from the popular copyleft licenses. There's far too much gray area in what constitutes a derivative work and what obligations I might unwittingly take on even when well-advised.
Well it's good that I never said you were then. Maybe actually read and understand my comment before responding to it next time.
I said that they aren't liked by companies that want to be able to take everything and never give back. I never said that they were ONLY liked by those companies, and I can't believe you're both capable of writing software and not capable of understanding that distinction, which leads me to believe that you must be either lying (about writing software) or trolling.
You can stay away from whatever licences you like. Their interpretation is very clear and well-known. If you think that something might be 'borderline' then don't do it. Even if it's technically fine it's almost certainly going against the intent of the licence, which is morally wrong.
The only obligation you could possibly take on is the conditional obligation that if you convey a derived work then you must make the source code available. That's not a difficult obligation, because you are already distributing the source code, because you aren't a fucking terrible human being (right?).
What you did was try to break out a cheap rhetorical trick to try to paint anyone who expresses a concern about copyleft, knowing you could always back out with "well, I never said that..."
And of course in your most recent comment you did it once again, sneaking in a back-door assumption that people who would have a problem with copyleft are "fucking terrible human beings".
You should stop doing that. Because you aren't "a fucking terrible human being", right?
Meanwhile, I'm pretty sure I've had this exact debate on HN before, but:
We went any number of rounds of this with Django a while back, precisely because there's such a large gray area. I still don't honestly know whether someone could claim we've accidentally triggered the GPL by providing a database backend module in Django that can talk to GPL'd MySQL drivers. We've just navigated as carefully as we can, there.
And no, it is not some sort of simple, settled, well-understood thing, so maybe you could stop presenting it as if it is? That'd be great.
Any CDDL-related pain is totally self-inflicted. There's no good reason to be creating projects and licensing them under CDDL in 2017, and there was even less reason to use CDDL in 2004. If people and orgs are experiencing pain with the CDDL, it's well-deserved.
The urban legend is that Sun invented the CDDL explicitly to prevent GPL-licensed competitors, Linux in particular, from benefiting from their work. I've not studied the CDDL at all, but I never hear anyone claim there's any other benefit to it.
I'm not sure what the rightsholder situation is with regard to ZFS (that is, I don't know if they had a copyright assignment for contributors), but it'd be really interesting if someone could convince Oracle, who I assume is the owner, to re-license it under the GPL. Oracle seems to have at least equal commercial interest in Linux as Solaris at this point. I'm not sure what the benefit is in keeping the license incompatible anymore.
Oracle used to have a copyright assignment policy that covered ZFS contributions, but it went away when they officially killed OpenSolaris. Any contributions since then have been under CDDL and the standard copyright mechanism where authors retain ownership is operating as normal.
It's true that Oracle can issue an update to the CDDL that would automatically apply to (past) versions of ZFS, since the CDDL delegates to them (nee Sun) as the license steward and ZFS was being distributed with "or later" terms. Last I checked, though, the current ZFS project maintainers decided to patch that by opting out of the "or later" terms for future versions. At least this was true when I spoke to ryao about it last year.
This was around the time that there was a lot of attention on ZFS on Linux. Eben Moglen did a compelling writeup at that time arguing that ZFS is most likely freely mixable with GPL nowadays, because users have been able to accept it on GPL terms ever since Oracle has shipped Linux versions that include ZFS and doing so without making it available under GPL would be a violation of the kernel's rightsholders' copyright.
CDDL is still a total quagmire. I'll repeat: there's no good reason to adopt CDDL today, and there's lots of reasons to avoid it.
The real "legend" is more that they were trying to open source something that was riddled with proprietary 3rd party stuff. So they had to get around it.
So while I previously had regarded the MIT license as the one to generally use for any project where one has decided not to go the copyleft route, this guy seems to be saying it's fine but Apache 2.0, being a little clearer about some edge cases, is the best of all permissive licenses and the one that should ideally be used.
The Apache 2.0 license isn't compatible with the GPLv2 (according to the FSF's compatibility list), whereas MIT is -- that may or may not be important to you. Apache 2.0 is compatible with GPLv3, and thus also with GPLv2-or-later code (in the latter case the combined work will end up under gpl3, obviously).
There's been massive discussion about this in multiple places, in short "or later" fear-mongering is just FUD.
1. Nobody forces you to upgrade to the latest version, it's only an option that people can exercise if they have a copy of your code.
2. In GPLv2 the FSF is the only entity that can create new versions, while in GPLv3 there are provisions for the original author to create a proxy (allowing them to delay the application of a newer GPL).
3. If the FSF goes corrupt, it is unlikely the new GPL will apply because the GPL states that newer licenses will be "in a similar spirit to this license". Given how much documentation the FSF has on their philosophy, it would be very clear if a newer GPL version violates their stated philosophy.
Also, finally, you can't have a license that "assigns all ownership". Copyright licenses and CLAs aren't the same thing -- and I doubt that you can retro-actively force people to give up their copyrights like that.
You should always use or-later because if you don't then you're just asking for trouble when the next GPL version is released and you have to ask every contributor whether they want to relicense their contributions. If you make it or-later in the beginning then there's no issue. If you don't like a GPL version you can always add restrictions to the all-later clause.
Well, it's essentially multi-licensing without knowing what all the licenses are. It gives some power to the FSF to choose what the next license for your work will look like. If you like what one license says but you don't know whether you'll like the next license the FSF releases, it makes sense to wait until you see it before deciding to use it, and that means not putting "or later".
I think Linux is a good example of this. Maybe users would be better off with GPLv3, but the copyright holders decided not to relicense. It's not asking for trouble to avoid relicensing until you can see the new license.
> It's not asking for trouble to avoid relicensing until you can see the new license.
Legally speaking, you're right.
Practically speaking, if you're running a project with a lot of contributors, hunting them/their heirs down and getting buy-in for a license change could be a huge project in and of itself.
In late 2012, the OpenStreetMap project changed it licence from CC to the current ODbL. Every user who had contributed to OSM had to be contacted and asked if they accepted the new one, and if not, their contributions had to be deleted and retracted. It was very annoying.
> Well, it's essentially multi-licensing without knowing what all the licenses are. It gives some power to the FSF to choose what the next license for your work will look like.
Sure, but the FSF's drafting process is open. Not to mention that if you don't like the drafts (or the final version) you can always restrict "or any later version" by saying "or any later version, except versions X, Y, Z". Sure, this'll mean your old code could be used under that license, but new code won't. By the way, the MPL (and CDDL) has the "or any later version" clause built into the license without an option -- by using MPL you are allowing Mozilla to relicense your code whenever they want.
> It's not asking for trouble to avoid relicensing until you can see the new license.
Until you find out that some of your contributors have passed away, and either:
a) Their copyright is in an estate, making it effectively impossible to get anything re-licensed.
b) Their copyright has passed to their next of kin, who might have no understanding of what the deceased's views on free software were and thus probably will do something like ask for money to relicense it (or just refuse outright).
Not to mention that if you're a large project, you're asking for trouble. In most cases, the only contact information you have about a person is their email address -- and since email addresses change all the time it's unlikely you'll be able to contact everyone. Mozilla went through a bunch of trouble trying to re-license all of their code because of problems like this.
Well, you can't really assign ownership in that fashion. First off, the "any later version" provision only applies to licenses published by the FSF:
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation.
Secondly, you can't revoke rights previously granted. A project licensed under GPLv2 will continue to be distributable under the GPLv2 regardless of future license versions. So even if the GPLv4 says 'You have to sign your copyright over to the FSF, mwahahah' then you are free to ignore that change.
> say I'm releasing a document that say it's gpl v4 and assign all ownership to me. or the FSF goes corrupt.
That would be a voilation of GNU GPLv3 itself (by FSF which is legally wrong). Such a GPL v4 license won't be considered as a later version of GNU GPLv3.
See section 14 of GNU GPL v3:
The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
If the later version is not similar (Of course, it is hard to explain this term) to the spirit of the present version, it will not be considered as a later version of current license.
Also, by having 'or later' in the license won't revoke the previously granted permissions.
Not a lawyer, but MIT/BSD ignore patents,
(software patents IIRC didn't exist when these licenses were created)
whereas Apache2 provides indemnity against any users from related patent suits by contributors.
(Sort of 'copylefting' associated patents, in a limited sense)
This isn't really an 'edge case' at scale - many large tech entities have patents.
Again, not a lawyer, I'd suspect this is 'best' here for adoptors of software using this license at smaller firms because lawyers reading the license know they are clearly protected from patent litigation by other contributors - that doesn't necessarily imply it's best overall - e.g. large companies with a large patent portfolio which is largely unrelated might not wish to even theoretically weaken their ability to use patents, or this might be a block to software adaptation/contribution due to bureaucratic reasons (e.g. all licenses must be approved by legal, who won't consider anything that mucks with their patents, even if it's not an issue here).
Further, there is potential for the patent indemnity clause to make litigation murky - for example, if a patent is covered by this license, but a user further expands the code in an 'infringing' capacity, or infringes elsewhere, the indemnity provided by the base code might protect them against litigation where it is actually warranted..
Probably some things on the flip side too - e.g. by accepting the indemnity clause, you might be recognizing the validity of the customers patent which could then be applied elsewhere against you, etc.
And as best I know (again, not lawyer and not up on details here) there isn't much case law around these licenses to clarify the murkyness.
Again, not a lawyer at all, but 'best' is dubious - I do have a preference for the BSD/MIT because they avoid this whole quagmire - although I'm somewhat anti-software patents for most cases, and licenses such as this also legitimize them, the biggest thing for me here is that this clause makes the 'free use' of the software itself much more dubious and less clear cut.
It would be interesting to have some more fine-grained information about biases/perspectives/rationales in this survey to help quantify the summary data..
> Further, there is potential for the patent indemnity clause to make litigation murky - for example, if a patent is covered by this license, but a user further expands the code in an 'infringing' capacity, or infringes elsewhere, the indemnity provided by the base code might protect them against litigation where it is actually warranted..
Yeah, this is an issue with Apache 2 License. Say, the user can take only the patented code (and modify to meet his/her needs) and keep the rest of the code to have any license (including proprietary), and the user is at the safe side.
In the case the code is licensed under GNU [A]GPLv3, the whole (modified and linked) code requires to be in [A]GPLv3. So no non-free derivations possible. If the user didn't free the code, the original author (who owns the patent AND wrote the [A]GPLv3 code) can sue the user (because the user has violated GNU [A]GPL).
I'd like an assessment of the EUPL [1]. IANAL, but supposedly it's an AGPL-like copyleft license adapted to EU (Code Civil-derived) law eg.
- with American and Common Law concepts and terms such as "copyright" translated to concepts meaningful in the EU
- covering "moral rights" (like German UrhG law which has certain rights that you can't transfer at all, such as claiming to be the author of something)
- with provision to determine the venue/court to bring cases to.
The EUPL has provisions to integrate EUPL-licensed works into other works and for relicensing under more liberal/non-copyleft licenses, but the cavalier attitude when it comes to copyleft makes it unclear to me whether the EUPL actually is a strong copyleft license (cf what the FSF says about it [2]).
The EUPL also has legally binding translations (since they are legally equivalent, is "translation" the technically correct term?) into a lot of languages and a comprehensive compatibility chart.
It would be interesting to draft a wide array of ISC-equivalent licenses in different languages+jurisdictions. If you could make sure licensees reference the right license text for their jurisdiction, then you could even remove some of the duplicate language like the warranty distinction between DIRECT and CONSEQUENTIAL, which are apparently interchangeable in some jurisdictions.
I guess "not applicable" because the op's list is clearly referring to the US only. You'd need a whole new list for those licenses as applicable in the EU or other places.
While Kyle Mitchell seems to discourage the use of the AGPL, the description on the FSF site seems to be pretty much what I as a developer who cares about free software would want for server software.
Many, many years ago there were already FSFE presentations by lawyers who encouraged everyone to prefer AGPL to GPL, because in most applications this is closer to what you actually want.
- GPL wants to care about the users, but actually cares only about those who install the software on their computer. Back then, these groups were identical, but in the time of remote applications (web apps, services, etc.) this means: The owner of the server, not the end user, receives the rights granted by GPL.
- AGPL actually does care about the users, no matter how they interact with your application. The rights given by the AGPL are granted to everybody down the chain.
Of course, this line of thinking only applies if you want a strong copyleft license. If you want non-copyleft, e.g. for very small projects, just stick with the ISC license (which is a more modern and slightly shorter version of MIT license).
Sorry to be nit-picky, but software released under the Apache 2.0 _is_ also free/libre software. Free software ≠ copylefted software (the latter is, approximately, a subset of the former). In most cases (vast majority?), Open Source software (as defined by the OSI) is also Free (as defined by the FSF).
> In most cases (vast majority?), Open Source software (as defined by the OSI) is also Free (as defined by the FSF).
It is a bit tricky here. Based on the situation, the same software can be some times be open source AND free software, or open source only (ie, not free software).
Eg: Linux kernel. When it is run on your computer, usually it is mostly free-software (linux-libre would be fully free). When it is run on your router, they (vendor) shall give you the source code, but may not allow you to modify it. This is violation of freedom 1 (The freedom to study how the program works, and change it so it does your computing as you wish). Then it won't be a free software, but just open source. You can't even confirm whether the source code they gave corresponds to the binary run in the router.
Thanks for the reference, I missed that section! 300 lines, so mostly scripts that this recommendation applies to. That's not 'small projects' if you ask me.
Rare exceptions include CC0 and WTFPL, which are not OSI-approved and thus are free software licenses but maybe not open source licenses, and Artistic 1.0, which is not FSF-approved and thus open source but not free software.
> I like the MIT/BSD licenses. Short, clear, understandable.
We might think short lines are clear and understandable and the best. But that is just for us. When it comes to law(yers), it might be interpreted in extremely insane ways.
So the terms has to be explicit, and this is why GPL/Apache have very long lines, stating each detail explicitly.
Have you ever seen any serious EULA for any proprietary software (or service) short and clear?
The "wall of legalese" is what ensures that you are protected from lawsuits. MIT/BSD licenses are shorter because they are more vague. That vagueness means they are easier to read, but harder to understand the implications of.
The linked post tries to channel the views of business, as I see them. My personal views on the licenses differ.
It's up to every publisher of open source software to weight business, community, personal, political, and other preferences to their taste in picking a form license. I tried to make big-co preferences more accessible, in a distilled form. Not to elevate them above all other concerns.
I agree. I always feel that the AGPL maintains the "spirit" of the GPL, namely that (external) users get the complete source code for the software they are using. In the past, external users physically got the software, hence the GPL's clause kicking in on "distribution", but the rise of SaaS means many don't, so the licence adapted.
Now there are those who always preferred the BSD-style over the GPL-style, which is fine. But I find it strange to prefer the GPL over the AGPL...
Except AGPL has very few resources and is incredibly unclear on what it actually covers. Mainly because of the huge conflict of interest that the few adopters have with their commercial dual-license.
E.g.
- I have a database.
- I have a closed-source website that uses this database
- I have an APGL service that uses this database
Do I have to opensource the website? APGL companies say yes.
Every hypothetical I've seen addressed with the AGPL involves a company running a server for users and then modifying that server and having to give the code to those users. But rarely is anything that clear: if I have a task queue that processes internal jobs, do I need to provide the code to end-users? Or are the "clients" just my app and the queue workers? If I don't, can't the whole AGPL be trivially circumvented with a reverse proxy?
I thought the AGPL only applied to modifications of the AGPL'd software? E.g. you'd have to open source any modifications of the AGPL service you make.
Except those pioneering web-services companies which provide AGPL code for their services but require copyright attribution to contribute to the main tree and at the same time maintain a proprietary paid version. In this case, they essentially prohibit anyone else from running a similar business - since the founders will have the leading edge on the 'main fork', and competitors can't maintain their own private paid versions, business competition will always be playing catch up to them.
This particular use case is where the implicit dualism of GPL software-centricity (vs people-centricity) falls apart/becomes absurd in my opinion - yes, the OSS version of the software is 'always free as in libre', but it is also always controlled by a creating entity who is using the license to create a defacto monopoly on it's commercial use, so the people are always beholden in some sense to the original code owners.
Free software is not about the right to contribute to the main tree or about the right to compete with businesses on equal footing, it's about the rights of the user to use, modify and distribute the software and derivatives as they see fit.
It's interesting that his perception of the GPL v3.0 and LGPL v3.0 is that it has higher "confusion" than the v2.0 versions (and the highest confusion rating of any of the licenses, only matched by WTFPL, which even I, a laymen, lack confidence in).
I get that the 2.0 versions have been in use a lot longer, and have had some tests in court. But, my understanding was that part of v3.0's purpose was to clarify the license and remove uncertainty about its meaning. They certainly had a lot more resources and experience when constructing the v3.0 versions. It's been many years since I read them side-by-side, but I recall liking the language in 3.0 more than in 2.0.
The v3 versions also have the additions that require to provide the end user with the means to update/exchange the [L]GPLed software binaries with custom ones. Which is mostly interpreted as "I have to provide my customer not only my application sources (in case of GPL), but also a way to deploy custom binaries of with arbitrary code and behavior". This causes gigantic headaches for most embedded device manufactureres, and the outcome is ususally the the [L]GPLv3 licenses are strictly avoided.
Technically it's of course doable without too much headaches. But it causes some other headaches: One is IP protection: If you provide the enduser with a way to upload arbitrary code which might often get run with root rights (because that's what the application requires) then you essentially provide the user a backdoor that gives access to the whole system. Which then can be used extract everything including proprietary code and also exchange other components and not only the GPL ones. It also causes headaches regarding device qualification and associated warranties: In many industries (automotive, medical, etc.) devices have to go through a very rigorous qualification and test process, which ensures that exactly the 1 software snapshot on the device is OK. The manufacturer then takes liability for that and gives warranties. If the customer can exchange some parts of it then the device basically counts as untested, and nobody can and will guarantee anything. Device manufacturers will be scared, that they could get sued for device malfunctions that are caused by arbitrary code injection. It might of course be a solution that the user-code upload process triggers some anti-tamper switch which auto-revokes the warranty/liability. But I think as a car manufacturer you don't want to give the user a way to drive around with untested code, which might cause really really big headaches if an accident happens with it. Lawyers will discuss endlessly if the tempered software could have been the root cause or not, and even if it is the manufacturer might get bad press why he allows endusers to decrease safety levels.
I understand what you're saying but it's not like the user couldn't physically change the device and create similar dangers. This is why uploading custom firmware on most devices voids the warranty, but I don't think you can make it impossible for someone to "break" their device if they really want to.
What confidence is there to lack in the WTFPL? Saying I license you to use this source code/software however you see fit seems pretty straight forward to me.
It doesn't actually say anything. It doesn't say you have permission to do anything, it doesn't say "If you do this I won't sue you", it doesn't license patents, it doesn't promise that as long as you conform to the license that you won't get in trouble in the future (that's the "estoppel" comment in the article [1]).
A normal human being reading the license will get the almost-certainly-correct impression that the author of the code will not come after them for anything they do, especially if it's a small usage. Lawyers must worry about two reasonable scenarios: First, some large usage causing the original licenser to decide to change their mind [2]. To put it in terms most of HN will understand, what if you release some code under the WTFPL license and discover that the Trump administration is using it. Would you be tempted to wedge your way into the legal ambiguity and sue them over it? Your specific answer doesn't matter; you need merely believe that there are plenty of people jumping out of their seats and yelling YES! to make my point, as that is enough to send shivers down a big-company lawyer's spine.
And second, even if you are confident that the original author wouldn't sue, if the rights to the package get transferred to someone else, you have to worry about whether that licenser will change their mind as above. If a new party changes their mind about the license, some of your legal defenses get a lot harder. The bigger you are as a target, the more you have to worry about being a bit, juicy target. A 5-person unfunded startup doesn't have a problem where Google does.
It isn't really a license so much as an assertion that the author won't come after you if you use or modify their code with no legal meaning.
Note that as gratuitous licenses are, irrespective of their language, revocable at will (in US law), basically everything you say applies to any license that is not a contract, it's not special to the WTFPL.
You can revoke a license at will, but I'm not aware of any case where someone took something that was open source and successfully retroactively closed it. You can close your future development but if someone takes the old code under the old license and continues work on it, I can think of no case where that was stopped, or even challenged.
So it seems to me there is a real difference here between licenses that proactively are clearly giving you some sort of rights, even if what those rights are may be up for debate, vs. the WTFPL license, which is still technically probably establishes that the author meant to grant you some stuff, but it is not terribly clear what.
> You can revoke a license at will, but I'm not aware of any case where someone took something that was open source and successfully retroactively closed it.
Revoking a license means that permissions previously granted are no longer applicable to any acts taken in the future, so no action requiring a license under copyright (such as copying) would generally be permitted (promissory estoppel protects, to a limited extent, those who initially relied on a promise that the license would not be revoked before it actually was revoked, but generally only to the extent that they had reasonably expended resources in that reliance and would be suffer unjust loss due the violation of the non-binding promise.)
> You can close your future development but if someone takes the old code under the old license and continues work on it, I can think of no case where that was stopped, or even challenged.
Thats because no one has ever actually revoked an open source license on code in significant use, rather than merely not offering it for future versions. And there's a good reason: most people offering open source licenses, even if they change their mind on a particular work, want open source to keep working, which actually relies very much on the shared belief that gratuitous open source licenses won't be revoked, even though the law of gratuitous licenses clearly allows that.
If it ever happens (and courts don't just completely rewrite the law on gratuitous licenses in defiance of precedent to save open source), the whole illusion of safety comes crashing down.
This is the first I've heard of the EPL. I'd love to hear someone elaborate on why it's listed as the "best copyleft license", specifically with regard to the GPL.
The EPL is roughly in the middle of MPL and LGPL in terms of copyleft scope. MPL requires per-'file' source sharing. EPL requires per-'module' source sharing. LGPL requires per-'module' source sharing and separating the module to permit the user to use/replace it without additional restrictions.
The one downside that EPL has is that, unlike MPL (without "Incompatible With Secondary Licenses" notice) or LGPL, it is incompatible with the GPL-family of licenses. It specifies different conditions for providing the source code and has a governing law clause (New York).
It is popular in the Java ecosystem (Eclipse, Clojure, etc).
A note to founders out there working with a heavily open source influenced stack: take a few hours to read through and really understand the history of these licenses and how they work. It's likely to come up in fundraising and m&a due diligence and can cause panic from others (even lawyers) involved in the process who don't understand the fine points and assume that your proprietary code is laden with all sorts of burdensome obligations inherited from open source components.
As the author also noted, the MPL is a rather rare license, tho I always ask myself why.
I use the MPL for most of my projects that aren't under MIT simply based on the fact that it feels like the GPL but without infecting any larger projects that want to use my code.
There are a bunch of projects dual licensing, such as "MIT or Apache 2.0"; I'd love feedback on the legal aspects of this.
That is, does a downstream user have option to choose either license ever, or would best practice be to announce which license you default to on usage?
A downstream user gets to choose which license applies. That's the whole point. If I publish something that's dual-licensed, I'm giving you two licenses and you can pick whichever one you prefer for your usage.
And the magic pixie dust of dual-licensing appears to be that you don't need to immediately select one license or the other: you can simply assume a superposition of both licenses until such time as someone decides to sue you for license-related reasons (which is to say, you remain in this superposition for basically eternity), at which point you could just point to one and say, "aha, look, we've been using this one all along". It's the sort of thing that feels like it shouldn't fly, but yet I don't think it's ever been challenged and at least Mozilla (which tri-licenses Firefox) appears to be fine with it.
None of those licenses put restrictions on use of the software, only redistribution. So if someone makes Firefox derivative and distributes it they will have to either collapse the license wave function by choosing one, or they can offer their users the same multiple-license. At least that's the way I think it works. They can't redistribute without stating their terms to the recipients.
It is confusing for me. If the project has GPL and MIT license I can't contribute GPL code to it, can I? Because it has to be also MIT.
Generally more restrictive license is more important in case of contributions. More permissive license is more important in case of use and modifications not contributed back. It is a fork welcoming licensing.
If I'm reading this right, and I'd need more information on the references used to make the judgments, then a MIT License with a definitive statement on patents (positive or negative) would be a fantastic copyleft license that is:
* Easy for nonlegally minded people to read
* Legally obvious with little room for interpretation
To me, the Apache 2.0 License seems to have too much verbiage. I'd much rather see a license similar to MIT/BSD/ISC but with a patent grant. Could someone write that up in a way that lawyers like it?
Think of legalise as a low level language for defining law. It has to cover not only the common cases, but also the corner cases, account for differences in running environments (i.e. courts), cover bugs found in previous versions, and so forth.
Even simple programs, made robust enough to run anywhere, get pretty damned big.
That makes the Apache 2.0 license a simpler choice than a MIT style license (from the point of view of a lawyer), as it's incredibly explicit and battle tested.
Mikeal Rogers of the Node Foundation has been in my ear about this more than once. I've done some work on new, plain-language permissive terms with clear patent license, but haven't anything to show publicly for it yet.
Licensors perspective (I know, many licensees will disagree with the first part)
1. If you want to dual license, use either AGPL or GPL (possibly even EUPL) Choice depends on what's your intent is. Choose carefully (EUPL has licensor warrant requirement). AGPL can be perfect for small companies who want to use licensing to generate revenue. Remember to be clear that dual licensing is an option. You can always switch to more permissible license later when you own all the code.
2. Use Apache-2.0, or MIT if you want the code just to be open source.
I agree with your intent. I've always advocated for the following:
1)GPL or LGPL for things you want to stay free.
2)BSD or MIT for everything else. This is important for things like firmware, where offering source code can be rather silly. Also, some people don't have an issue with companies incorporating their code into closed products and these offer an easy way to allow that.
I always felt the OSI did a huge disservice by encouraging companies to create their own licenses. There really aren't that many things people want from a source code license, so a few that broadly cover those cases is important. All the others just create license-compatibility issues that limit the usefulness of the code.
@tannhaeuser requesting an assessment of the EUPL (strong or weak copyleft).
Recital (10) of Directive 2009/24/EC on the legal protection of computer programs reminds that the function of a computer program is to communicate and work together with other components of a computer system (a logical and, where appropriate, physical interconnection, done by interfaces). This is known as “interoperability”. Recital (15) of the same directive states that the reproduction of the source code that is indispensable to achieve interoperability does not require the authorisation of the right holder, provide it is done by a person having the right to use that code and provide this use does not conflicts with a normal exploitation of that source code. Therefore, it seems that the directive implements an exception to the author’s exclusive rights. The objective of this exception is to make it possible to connect all components of a computer system, including those of different authors or manufacturers, so that they can work together. Notwithstanding the “strong” copyleft provision of the licence covering one or more of these components, it seems therefore that the legitimate recipient can always link two programs or link (logically or statically) any received code with its own code without being restricted by the copyleft provisions. The recitals of the directive are not transposed as such in the various national laws, but it makes little doubt that the Court of Justice of the EU will find there a motivation for rejecting any claim that “linking makes derivative” or that “linking extends the coverage of a copyleft licence”. This does not invalidate the concept of copyleft, that remains valid on the covered code, but it invalidates the so-called “viral” pretention of some copyleft licensors to extend the coverage of their licence to any linked program.
In other words, the famous distinction between “strong” and “weak” copyleft has little reality according to the EU legal framework.
I really dont see whats the confusion on WTFPL, the license states you "CAN DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE", this is code/work i don't want to be entitled nor endorsed nor looking for "royalties". Most corporate people will probably relicense under their own terms the code/work and I (as a developer/creator) couldn't care about it... so whats the "pain" and "confusion" on this lawyer?
Okay, is there evidence of this? who else has done it? is there existing legal precedence for this action? will presenting something that says "WHAT THE FUCK" in it cause me embarrassment in a corporate setting? how is our exposure for implicit vs explicit license agreements?
You are thinking as if there were a "litigation in process", licenses are looked only if one the parties decided to sue, usually the "creator" or "author" of the work are the ones which are "suing" because he wants to gain royalties for the "work" he is done but in the context of WTFPL, given that "i license my work under this license" this non-existant because m licensing "my work" as something near "public domain" (if you accept the premise that even such us-specific legal term applies, which usually isn't) so pretty much all your question don't matter, there won't be a legal precedence if there isn't something to "sue" maybe for liabilities but this is something rare to see outside us.
This very much fits with my perception on how most company's lawyers understand open source licenses today. But then I would say that, as my organization (CNCF) requires our projects to be licensed under ASLv2 and I wrote this justification for it: https://www.cncf.io/blog/2017/02/01/cncf-recommends-aslv2/
Strange document. I don't get why Lawyers would be bothered by the GPL or the MIT licenses... in 2017 !
As a Lawyer myself, I am certainly not. Free Software and Open Source Licenses are a great way for developers to get protected, worldwide, at a very low cost - and to achieve their goals and values besides their software itself.
MIT licenses don't assign any rights to use patents associated with the code, which is a pretty hairy situation for most larger corporations (those who would hire lawyers regarding license compliance in the first place).
That is just FUD. They're only "hairy beasts" if you didn't care enough about the licenses of software you were using in the first place and suddenly a user exercised their rights which you weren't equipped to deal with. There is so many resources available from the Free Software Law Society that being ignorant as a lawyer is not excusable.
I wish he would of included the MS-PL which is not as common but a very decent license if you worry about patent based claims, otherwise has an MIT License vibe.
Figures that a lawyer would give a single question mark to some licenses which say "you can use the patents in this code (well, those that are ours, that is), and this license terminates if you litigate us for any reason" but two question marks to the BSD 2 Clause.
A tactical position in the legal arms race is of course clearer than some implicit assurances of peace.
I'm proud of that one, but you're the first person I've seen even _mention_ it!
It takes at least a full working day to round up all the FTC actions for a year, read them, code them, categorize them, synthesize, write it up, and proofread. I had that kind of time back in early 2015, when I'd just started my own practice, and wasn't backed up with client work to do. I holed myself up in the San Francisco Law Library for it, as I recall.
IANAL but I'd guess it depends on the wording. If it's an "AND" (as your question suggests), the most restrictive would apply while if it's an "OR" (as it's common when dual-licensing) the less restrictive would apply.
> If it's an "AND" (as your question suggests), the most restrictive would apply
Please note that it is not possible to do this with some License X and GNU [LA]GPL. Because it is an additional restriction which is not allowed as per the terms of GNU [LA]GPL.
What about Creative Commons Zero? I've been told that's a great way to make your small source, etc examples free. I use it on dozens of my github repos:
Is there any document that explains why the CC0 does that?
I've been using it for a long time as a "socially acceptable WTFPL" and thought it did, well, exactly the same as WTFPL, let any person in possession of the source do whatever the fuck they want. But apparently with CC0 there are some things they can't do even if the local law allows it?
> Unless expressly stated otherwise, the person who associated a work with this deed makes no warranties about the work, and disclaims liability for all uses of the work, to the fullest extent permitted by applicable law.
If you don't explicitly disclaim warranty then you can get hit by this in Common Law jurisdictions, see [0]
It's a socially and legally acceptable WTFPL — it includes:
- a "do not sue me" clause for jurisdictions with implied warranty
- a BSD-style permissive license for jurisdictions that do not recognize public domain or do not allow directly putting something into it (e.g. Russian law explicitly says that disclaiming authorship is bullshit)
If I recall right, it was written originally by Sun a long time ago, to allow them to open-source their software while giving clear terms to entreprise users to let them combine/integrate software together.
It is unique in some aspects and it is friendly for entreprise.
CDDL is basically like the MPLv1, but has some clauses that are worrysome. If you want file-based copyleft just use MPLv2 (which is also compatible with the GPL -- which CDDL is not).
Wow. As someone who pays little attention to open source licensing it seems like the whole system is just a confusing amalgamation of nonsense. By nonsense I mean that every little organization has their "thing" and you need a lawyer to do anything or keep track of it all.
Can we just simplify the licenses or does everyone need to write their own? Why not just have MIT for all open source and be done with it?
If you think open source/free software is full of complicated one-off licenses, check out proprietary software sometime!
The large majority of projects use MIT, GPLv2, GPLv3, Apache, or a common variant like LGPL or BSD. Older projects often use other licenses for historical reasons, and modules often use the same license as the core software.
Asking why everyone doesn't just use your favorite license is a good way to start a flame war. The MIT license doesn't address patents, and some people like copyleft.
[1]: https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...
[2]: https://writing.kemitchell.com/2016/05/13/What-Open-Source-M...
[3]: https://writing.kemitchell.com/2016/05/13/License-from-Who.h...