[Flameeyes] has heard complaints (and at times, he admits, has complained himself) about big companies not contributing improvements to projects they seem to find useful, or rolling their own implementation rather than use and contribute to an existing code base. Having recently left Google after seven years, he has some insights into some of the reasons big corporations (at least Google, anyway) may sometimes seem to eschew making code contributions, and some of the reasons might come as a surprise.
There are things a corporation can do differently, but there are also some things that can be done on the project’s end to make accepting contributions easier. [Flameeyes] took some time to write out a few pointers on how to make it easier for others (particularly large corporations) to contribute code to a software project.
The biggest issue is the software license. Without one, there is no legal structure to use, distribute, or contribute to the code, and no corporate entity will want to touch it. Google specifically forbids creating patches for projects with either no license, or incompatible licenses. An example of an incompatible license is one that forbids commercial use, because everything a corporation like Google does — even research –is considered a commercial endeavor. In addition, on the corporate side making contributions might trigger a code review process of some kind for some licenses, but not for others. [Flameeyes] suggests the MIT license as one that is acceptable to pretty much everyone with a minimum of fuss. Another caution: if a project’s code resides in an online repository, make sure the repository is licensed as well.
A few other small suggestions (such as maintaining an AUTHORS file to track contributors in a tidy way) rounds out the advice. It sounds simple, but software licensing is so critical to the whole affair that it’s important to get it right — he suggests the REUSE tool for anyone wanting to make sure a project’s licensing is tidy.
[Flameeyes] makes a point that none of this guidance is based on secret or institutional knowledge. Google has a public document detailing exactly how they use and deal with open source, and it’s a solid guide for how to make your project more accepting of contributions from a corporate entity like Google. (Or, if you prefer, a guide on how to set up as many barriers as possible for your project.)
In case you missed it, we just want to remind you that our favorite recent open source project from Google is definitely Pigweed.
Other things to consider: Do you have an obvious way to submit bugs and patches (He covered that one a bit)? Have you thought through copyright assignment, and are you up-front about that?
Also fun is the one Open Source license that Google absolutely forbids anyone there to touch: AGPL. So pro tip, if you don’t want Google or Amazon to turn around and host your project in competition with your offering, use the AGPL.
Implied but not spoken in the article is simply that GPL is considered as Ebola-like license in most companies: never allowed to stay close or touch it unless unavoidable (ie linux kernel, gcc a very few others), and if you do you must follow strict process.
What is it in the GPL that is presumably not in other licenses that makes it Ebola-like to companies?
There are two kind of licenses: those that forces you to “share alike” your changes (the main example is the GPL), also called ‘viral’, and those that don’t (the main example are the BSD licenses, or the MIT). With a GPL license (and any other viral one), any code that you add to the project, or any project to which you add pieces of a GPL’ed program, must also be GPL. With BSD/MIT (or any other non-viral ones) you can take pieces of code with that license and use them in privative code (thus, non-free code). That’s why some companies love BSD/MIT, but hate GPL.
An example: Apple used the BSD kernel as the basis for MacOS X because if they wanted, they could close it and make it fully privative. Also it won’t impose restrictions with privative drivers (like nVidia). If they had used Linux instead, they would had a lot of problems for distributing preinstalled drives, and any change done to the kernel should have to be published to the buyers.
GPL infects everything. Link with GPL code in any way? Your code needs to be GPL as well.
OpenSource licences are generally about freedom.
MIT&BSD for example, is about freedom of the code, the code is free to be used by anyone, anywhere with very little restrictions.
GPL is about the freedom of the end-user. And specifically the freedom to modify&inspect. GPLv3 and AGPL go very far in that. GPLv3 requires patents to be open, AGPL requires access to the code if you have access to the service the code provide, not just the binary as normal GPL states. Which is why Google has a very strict reason not to touch anything AGPL. GPL/AGPL infect this freedom to the whole application. And this infective nature is what makes people shun from it.
LGPL goes a little less far, and just does the same as GPL, but limits itself to a “replaceable binary package” usually a DLL. And using that DLL does not infect the rest of your code.
On the contrary.
GPL is about the freedom of the code, because it ensures that the code stays free.
MIT/BSD are about the freedom of the user, because they allow users to close down the code.
“GPL infects everything. Link with GPL code in any way? Your code needs to be GPL as well.”
Steve Ballmer, is that you?
GPL and its variants are indeed rather infectious to be fair.
Copy left and share alike in general to be fully honest.
Now, the concept of copy left and share alike can technically work.
For an example, within media/art, a share alike license doesn’t apply in cases of fair use. (Ie, leaving people to option to build on a concept, if not invading on it. (Grossly oversimplified. And honestly, “fair use” is its own gigantic can of worms…))
The important thing one though needs to remove from copy left is its viral nature.
One thing that would make copy left licenses far less viral would be if one could use the code as if it were a tool. Ie, one makes no modifications to the code, imports it as one chunk of source code to include in one’s project, and then add an appendix to the program’s license, stating that one uses a component/snippet-of-code that uses X license, by Y author and that the source can be found at Z repository. (And obviously linking to the actual project. And for one’s own sake, ensure that one clearly documents what code belongs to what project, in case one removes the code later down the road.)
Making modifications to the code that we have imported on the other hand is another story. If its done for performance optimization, or adding new features, or fixing bugs. Then obviously the original project the code belongs to would benefit from those modifications. So please contribute those modifications to that project.
(Now, in the hardware world, we can grind down the side of our hammer to get into some odd tight spot, without needing to share that with the manufacturer. But software is a bit different.)
If copy left licenses let one use the code as if it were a tool, and not have its license infect everything. Then copy left licenses would be less scary to poke at for commercial ventures. (And also for projects that target commercial users. And also become less scary for people who has no clue where their project might go.)
Though, I am personally of the opinion that if one makes a snippet of code to do a “single” function, then maybe one should use a more permissive license to start with.
And why is that bad again? I mean, why shouldn’t companies that use code they get for free publish their part as well?
Isn’t the whole point of the GPL to allow freedom from companies trying to own you?
The main problem of copy left isn’t that a project remains open source. (Since that isn’t a problem.)
But rather that anything that desires to make use of the project also is required to fall under the same license. (A bit like Intel’s terms of service for having an account on their website. (their terms of service states that anything they post on their website that inspires you to make a patent, is then giving Intel the full right to have a royalty free license to use said patent however Intel desire. (Clearly overreaching.)))
GPL makes the argument that anything that uses GPL code also needs to be under a GPL license. This makes GPL incompatible with anything that for one reason or another can’t use the GPL license. (And that is quite a lot of stuff to be fair, even some other copy left licenses…)
GPL does make an exception to plugins. But since the GPL license also puts forth limits to how extensive the communication can be between a GPL licensed and non GPL licensed code, then this can render some plugins as violating the license. So plugins isn’t a silver bullet.
Now, I have already made a comment in regards to the fact that copy left licenses should likely make an exception that allows copy left licensed code to be included in other projects, without it demanding that the larger project should also be forced to use the same license. (While also requiring that any modifications/improvements of the copy left licensed code should still be contributing to the copy left licensed code’s original project. (ie, remain under the copy left license. (The larger application still has its own license, just read the other book of a comment above.)))
This is though only applicable to cases where the copy left licensed code is a tool. Not a full application. (Like one wouldn’t take all of GIMP and use in another application. A hashing algorithm is more along the lines where this “tool” analogy makes sense.)
In the end. A company isn’t really owning your code just because they can use it.
Copy left licenses on the other hand currently requires that the company gives up all their work for the sake of getting to partake in the open source field. (Ie, Copy left is currently offering an inch, in exchange for a mile. So that is why companies avoid especially GPL (the most popular copy left license) like the plague.)
That would very much depend on whether the software under consideration is a library or not. Obviously they’re not going to use libriaries that are GPL licensed, as that would require whatever it is used in to be GPL as well. But standalone programs that are GPL licensed shouldn’t be any problem (unless they can’t be bothered to take 10 seconds to understand the GPL enough to see that that is fine…).
They have teams of lawyers. You think they don’t understand the GPL?
No they don’t. Lawyers do not want to commit their advice, they will shy away, because “why bother”.
This is even more of a misconstruction of my posts than the Hackaday summary.
The documentation I commented on make it very clear that contributions to GPL projects is even covered by the blanket approval for any GitHub project.
I get Google (and Microsoft, and Apple, and…) *love* MIT. Millions of acres of virgin prairie to ram stakes in.
The occasional indigenous (*crunch*) uh… was there something?
Take at no cost and decide what you contribute back… oh, how magnanimous.
Thanks, but no, thanks. I’ll take the GPLs.
This
Not to all companies [0], definitely. Apple downright *hates* GPL (I think that’s in part Steve Jobs’s ghost, still butthurt from the Objective-C episode[1], those things tend to be somewhat cultural, and thus emotional), just to the point that they forked bash when upstream went GPLv3 — screwing their customers with one serious bash bug.
But every other predatory company like Google, Microsoft, etc — which like to take all and keep control do prefer non-copyleft licenses. Of course it isn’t hip to admit that openly, so here’s how I’ve watched it unfold:
Having worked for a while in a bigcorp, I remember my boss said it’s OK for us to use “open source”[2],
as far as it isn’t “GPL”. I asked him why, and he started waving hands and talking about “liabilities” — it was obvious he hadn’t any clue what he was talking about. That’s the usual fuzzy and fuddy way it happens, so it’s difficult to sink one’s teeth into it[3].
Sorry for the wall-o-text
[0] One counterexample among thousands (I’m not associated with them in any way) might be:
https://en.wikipedia.org/wiki/Igalia
For obvious reasons they don’t tend to be huge or fast-growing. But successful nevertheless.
Another example, of course, Red Hat. They contribute *a lot* to GPL-licensed projects, the Linux kernel, GCC and libc among many.
[1] https://en.wikipedia.org/wiki/Objective_C#Popularization_through_NeXT
[2] I prefer to spell it “free software”, because to me, it’s about the people using it
[3] It takes some discipline to think about those things. One tends to see conspiracies where there ain’t any, and generous use of Hanlon’s razor is essential to keeping one’s sanity. And remember: “just because you’re paranoid it doesn’t mean they ain’t after you”
Would have been nice to be asked for a once-over if I had any comments on this, as you’re slightly misrepresenting my point about MIT.
My recommendation for MIT is in the context of permissive licenses already: Google and Fedora (and a number of other actors taken two-by-two) have opposite viewpoints on some of the licenses such as CC-0, Unlicense, and WTFPL. So if you chose one of those extremely-permissive licenses, you may find yourself in a position where people part of one or another organization are unable to contribute (or sometimes even use) your code.
If your usage of CC-0, Unlicense, WTFPL, or other extremely-permissive licenses is related to an intention to make the code universally usable, you may want to rather use an option that has the highest likeliness to be usable by all, in form of MIT, which is not as strong a statement, but gives it more practical usability.
Aside from that, if GPL, LGPL, Apache, MSPL is your choice, go for it. Most of those will get contributions just as easily. AGPL won’t (and not just from Google), the same as CC-0.
None of my post had to do with discussing the copyleft ideology, it comments on one goal, and one goal only: if you want to have as wide _code contributions_ as you can, you need to follow some easy steps. If you want to make an art project that no-one else should ever touch, it’s fine! If your ideology is more important than the contributions, it’s fine!
Flameeyes, I wrote this post and I’m truly sorry for misrepresenting any details. I thought I grasped what you were getting at but it seems I missed the point more than once.
I cannot find any contact info for you on your blog, but you can email me if you want to reach out. (e: email address removed since it’s no longer needed and spammers are finding it)
I’d be happy to clear up problem statements — but you may need to walk me through the nuances because I clearly don’t grasp them if things I wrote are wrong.
Look at this Big Brain, writes a post on the Internet and then expects others to check with him to make sure he approves of their interpretation.
I think somebody is still trying to cope with life in the real world after spending the better part of a decade at Google.
Or, you know, I expected editorial integrity from a website like Hackaday who happens to profit from reporting on blog posts of individual community members, rather than throwing them under the bus.
A quaint, obsolete idea, I get it.
It’s always nice to see how the managers in service of the bourgeoisie hate GPL.
Please read my blog posts. No hatred for the GPL to be found. Hackaday misconstrued my suggestion of solving the different-organisation views over CC-0, Unlicences, & co. by using MIT rather than those others.
There’s the human thing as well, sometimes a project gets going with a group of excellent people and stays that way for years, managing to inculcate the project’s culture into the n00bs and staying that way. On the other hand, there’s those that get going with a few decent people and a few a-holes, or those that turn a-hole due to perceived grievances, then the project is in a state of civil war for a while. Then one side or the other wins and you’ve got a tight clique of the paranoid, anyone joining is a sock puppet of the evil one. This goes on for a couple of years, then enough people have fallen away that they’re publicly begging for contribs, but oh surprise, they’ve actually got the equivalent of a 2 mile deep minefield around their position. New people can’t even get close. Eventually, there’s few enough defenders left, or enough mines set off that someone can run from crater to crater and catch the flag as one of the last OGs drops it. A core of decent folks come in, resurrecting the project… maybe there’s a couple of a-holes in there though, repeat…
“An example of an incompatible license is one that forbids commercial use, because everything a corporation like Google does — even research –is considered a commercial endeavor.”
Then Google must be a big BSD user then? Can’t get more compatible than that.
“Another caution: if a project’s code resides in an online repository, make sure the repository is licensed as well.”
Seems a bit silly, unless one’s worried about access being restricted in some kind of future.
That part about the repository is not in my posts at all. It’s another misconstrued/misunderstood reference.
For reasons (which I don’t know, since I was never privy to that information), Google has a blanket approval for contributing to projects with certain licenses (including GPL, just to placate those loud voices), _as long as the project is on GitHub_. The same exact project on BitBucket wouldn’t get the blanket approval and would require at least a one-off review.
So my suggestion on the blog post was to have a *GitHub mirror* which is quite a different thing to “licensing a repository”, whatever the author of _this_ post meant.
I’m a little confused, there is a paragraph of your blog post that’s linked above which says:
“When it comes to licensing repositories, remember to license the repository with websites, too. Some time ago I wanted to send a correction for pdfreaders.org, but I couldn’t because the repository for the site didn’t have a license. Oops! (I believe this was fixed.)”
I think that’s what “Another caution: if a project’s code resides in an online repository, make sure the repository is licensed as well” above is referring to. It seems to be a pretty accurate summary of that paragraph, but I’m not familiar with the concept of licensing for repositories, only for the code itself. Can you clarify the difference, please? Thanks!
That’s about licensing the *website*.
You’re not licensing the repository per-se, but rather the content in it. The same way you do it for the code.
Hey, @FLAMEEYES — this wasn’t a comment on your text. As far as I can see, you just say corps prefer MIT, which is often true. I was replying to @BT’s question on why GPL is “Ebola-like to companies” — and tried to forward some examples (and some counterexamples).
I’m trying to understand why a corporation like Google would object to public-domain code such as CC-0 or Unlicense. I thought “public domain” meant “do anything at all”, which to me seems to say “free money!” to corporations. I’m thinking of 1977 when the designers of Radio Shack’s TRS-80 took the public domain Palo Alto Tiny Basic, modified it and called it Level I Basic, and made lots of money that they never had to share to Tiny Basic developer Lichen Wang. (Money that Wang did not expect or had hard feelings over, of course.)