What if your code is used for something bad?
It happened to Andrew Tanenbaum.
Table of Contents
- What happened to Andrew Tanenbaum? 🧐
- What’s wrong with Intel using open source code? 💻
- Did Intel fix their security problems? 🔐
- How does Andrew Tanenbaum feel? 🤔
What happened to Andrew Tanenbaum? 🧐
Andrew Tanenbaum released the third version of the MINIX operating system under the permissive Berkeley license.
When employees from Intel started asking Tanenbaum technical questions about the MINIX 3 operating system, he was happy to engage them. Eventually, Intel secretly modified the MINIX 3 operating system for use in Intel CPUs.
What’s wrong with Intel using open source code? 💻
On the fifth of May in 2017, Intel released a patch for the Intel CPUs running MINIX 3. Before this security patch, it was possible for hackers to remotely access computers that had an Intel CPU running MINIX 3 without a password.
Did Intel fix their security problems? 🔐
Although Intel’s CTO Steve Grobman has denied it, Intel’s Management Engine is a backdoor by definition. Hackers can bypass normal authentication and access a user’s computer by entering their computer through the Intel Management Engine.
The sheer number of exploits affecting the Intel Management Engine - six to date - can be used to make the argument that the Intel Management Engine was designed to be exploited, that is, that the Intel Management Engine is a backdoor.
How does Andrew Tanenbaum feel? 🤔
Even in 2017, the creator of MINIX had regrets working with Intel on the Intel Management Engine, saying he would not have worked with them on the Intel Management Engine if he knew they were building a “spy engine”.
Andrew Tanenbaum seems to regret his decision working with Intel, but most people who permissively license their code find it rewarding. The question remains: to license permissively or not?
Top comments (21)
FYI - The below opinion is not entirely directed at the author cos I don't know how much the person knows about licenses. But this is for people who don't know much about licenses and get the idea that MIT license is bad for open source. Spoiler alert, it is not. :)
Most people don't know about licenses and it's intricacies. But it is a very complicated topic. All open source licenses have its place and use cases. You should choose licenses based on what you want to accomplish. Not hate a license cos it was doing it's job. :)
For example, there is a fundamental difference between permissive licenses and copyleft licenses alone. Then there are other issues depending on the license you are using and for what you are using it.
With permissive licenses like ISC, MIT, BSD-2, BSD-3 etc, you give anyone the permission to do whatever you want. To put it very simply (They all have characteristics and differ in certain ways). You shouldn't be worried if someone copies your code and makes a commercial product or start a company with your code which is permissively licensed. In fact, if you are worried, then you are using the wrong license for your project.
There are very important use cases for permissive licenses like MIT. For example, most of the libraries and frameworks like Vue.js, Reactjs and TailwindCSS are MIT licensed, which is a permissive license. Permissive licenses make interoperability with other software with different licenses possible. This is why you can integrate an MIT licensed software into your project which is GPLv3/v2 based. But you cannot do it the other way around. Cos GPLv3 is not a permissive license. This means if Tailwindcss, React, Vue or other projects used a copy left license, you wouldn't have been able to use it in your personal project which is private or commercial. None of those companies wouldn't be using React, TailwindCSS to name a few if they were using non-permissive open source licenses. You will have to make the code public for one matter. Again, this is me putting it simply. There are ways in which copyleft licenses can be integrated for commercial use cases.
Some interesting things/instances I learned in the open source license land are:
Linus Torvald saying he won't move Linux which is a kernel from GPLv2 to v3
There are license provisions which says "GPL3 or more". By this the author is meaning this software will support GPLv3 and any new license version which comes after GPLv3. This to me is bonkers. Imagine trusting a license provider that you agree your software will support GPL3 and any version that comes after it. What if GPLv4 creates some terms you don't like? What if some terms disallow you move towards certain goals the project want to go? It is a messy thing to change your license once you make it public.
MacOS and Playstation uses/used FreeBSD which uses permissive license called BSD-2 IIRC. You might think it is radical or unfair for companies to just copy the FreeBSD code. But the thing is, since Linux uses GPLv2 which isn't permissive, companies now have to make Linux flexible for them by politics and other tactics to get what they want. This has good and bad effects. Meanwhile Apple, Playstation are all examples of FreeBSD's use of permissive licenses successfully avoiding political maneuvers better than Linux. IMO, One of the reason why Linux hasn't captured the Desktop by storm is because the companies working on it don't care. They are only worried about enterprise use cases. Take a look at Linux Foundation (which governs and make decisions for the project) website to see this in action. It's all numbers and product pitches. Most GUI and desktop oriented projects if not all are community based. This all comes from a SINGLE LICENSE ISSUE of License being non-permissive.
Meanwhile Playstation takes what they want and they have brought back code IIRC to FreeBSD. But the important thing is, they don't have to do any kind of tactics. This has kept FreeBSD more community oriented. Netflix works with FreeBSD too cause they use FreeBSD for making Netflix possible. They are not enforced by anyone. They do what they want by taking what they want and they contribute a lot of code back to FreeBSD and it's network stack (cos netflix is cool that way). This would've taken a different turn if FreeBSD was GPLv3 for example.
Plausible which is a analytics company which are open source is another example of a company choosing the wrong license for their project. Read - plausible.io/blog/open-source-lice....
An example of license compatibility issue - ZFS filesystem is not bundled in Linux Kernel like other filesystems BTRFS, EXT4 etc cos of license interoperability issue. So if you want your Linux distro to use ZFS file system, you have to load it separately. Only some linux distributions offer ZFS OOTB. Others have to manually load modules which is not so straight forward. Read -theregister.com/2020/01/13/zfs_linux/
But all in all it is the author's responsibility to choose a license which integrates well with their goals for the project. Not the responsibility of the license which does what it is intended to do. :)
Edit: Made some parts more clearer since this is making rounds now. FreeBSD uses BSD-2-Clause and not BSD-3 as mentioned earlier in this comment. Fixed that as well. Drop a comment if you see anything that needs to be fixed.
Did you forget that there is a lesser GPL?
Permissive licenses are fine, but they're not the only way to make software that can be combined and shipped with code licensed under different terms.
You are right. I didn't say it is the only way either. I told people to choose the licenses depending on what they are trying to accomplish.
Not really. I did indirectly convey about LGPL. But I don't know why it should be important since this post or my comment isn't about covering all OSS licenses.
I always go to this page choosealicense.com/licenses/ when I need to know the meaning of a license or which to choose on my projects.
I think it's the best page that explains each license in a simple way.
If your license its not permissive you will become what you hate, there are no "good" sides, political, philosophical, moral views do not belong to software. In open source one gives without expecting anything back. It is on you how you decide to monetize your knowledge. One must write OSS code like abstract puzzle pieces that can be used for whatever end. The piece integrated with a certain domain logic is what makes it closed source. Closed source is fine , its what gets engineers hired to work in companies. Let people do whatever they want with your code. Really hoping Andrew charged some money for those questions from Intel.
Out of interest, what license do you use for new projects now, and why did you choose it?
That was my question as well. This seems like a half thought out anti license piece.
This!
That's the great thing about open source, free as in freedom applies equality to people you like and people you don't like doing both things you like and things you don't like. That's kind of the entire point, that people (even company people) have the right to do what they wish with the software they have.
Developers are well within their rights to restrict who or how their software can be used, as MongoDB and others have done, just as long as they don't pretend to themselves or others that they are still open source.
This seems to be a pretty narrow case where one person regretted a decision given information that wasn't available at the time of his decision. I don't know that I would feel bad if I did my due diligence before partnering, and only found out later that our goals were not aligned. I would certainly not do business with them again, but I can't hold myself accountable for knowledge I couldn't have had.
All that said, I don't worry about what people might do with my code. An "as-is" license should pretty much cover my butt for any conceivable use of my code. But I don't write operating systems or security software. I suppose I might feel differently if I did.
One reason I use permissive licenses is because I am lazy. I don't feel the need to restrict people's use of whatever code I may leave publicly accessible, and I don't want to maintain it if I'm done with it. MIT seems to fit that scenario quite nicely. Again, I'd probably feel differently if I'd written something that people were dependant upon and I wanted to maintain some control over the source code.
FOSS is undoubtedly a great ecosystem. I think it's important that people take reasonable risks to keep it alive. If everyone closed up their code, and didn't write anything publicly for fear that someone would misuse it, I think we'd lose a lot of valuable knowledge in the public domain.
But the point made is not about "covering one's ass", it's more in the line of "not happy with the usage". Other than that, totally agree.
I used to be a smith making knives. One day, a person stabbed someone with a knife (not any of my knives, but still). Now I don't make knives anymore. Screw all the chef's that have a use case I approve.
I'm not really a smith, but I wanted to apply your logic to another example as a reflection ;)
I triple-license my software. At the top of every file is this:
See that "All Rights Reserved"? I was asked about it once upon a time in relation to the software license for the software.
Software internal to CubicleSoft is fully protected by copyright and owned by CubicleSoft. By default, no one else may use the software. This allows CubicleSoft to create both private/internal and commercial software products with its protected software. If anyone steals any software from those products, they are in direct and complete violation of copyright law even if portions of the software are also available on GitHub! Publicly available code on GitHub that happens to be part of CubicleSoft commercial software does not convey a license to make a product that competes directly with CubicleSoft commercial software products using CubicleSoft protected software because the license in the commercial product itself is fundamentally different.
For the most part and for most people, the previous paragraph might sound scary but is just a technical detail that few have to worry about unless they are thinking about directly competing with CubicleSoft. It is primarily intended to stop anyone from attempting to profit directly off of commercial CubicleSoft software via straight up software piracy.
So life for any given piece of software at CubicleSoft starts out as a completely protected work which no one else outside of CubicleSoft may use. When CubicleSoft software is made open source and published to GitHub as a set of very useful libraries and applications, it is usually made available under both the MIT and LGPL licenses. Users of the published software on GitHub choose which of the available licenses they wish to license the software from CubicleSoft via the GitHub repository in question.
Note that on rare occasions there are modifications to the available license(s). For example, the Portable Apps Mirror Proxy service has a slight adjustment to the MIT/LGPL license to avoid legal issues related to the associated registered trademark.
The end result is that the same piece of software, when published on GitHub, has not one license, but three distinct licenses: A version that is only usable by CubicleSoft for private/internal and commercial projects, a version published to GitHub that can be licensed under the MIT license, and a version published to GitHub that can be licensed under the LGPL. Since the published software to date that offers MIT vs. LGPL is identical, the software just happens to appear in a single repository on GitHub. I'm not sure what the use-case would be to create separate repos due solely to license differences, but it's not an impossibility!
Most end-users will simply choose to license published CubicleSoft software under the MIT license, where available, since it is the most permissive. Users who already mostly use LGPL software and prefer LGPL will license under LGPL where available.
IMO, most indie software developers should embrace a similar model of dual-licensing your own software when publishing to GitHub. Your local source code is the fully protected work while the published version uses a suitable open source license. This is basically "branching" your license. Doing this allows you to make money from your software via protected works and a formal EULA while still sharing useful libraries and applications with the world.
Finally, if you use any open source software in your own software products, you technically don't have to, but really should contribute back to the larger community of developers. If you don't contribute back with source code, there's always the monetary option (sponsorships, Amazon wishlists, buy a coffee, etc.) or at least drop in on Discord/email and take a moment to thank the developer(s) for their efforts.
I'm not a lawyer and this is not legal advice. However, I've known a number of software developers who have transitioned into practicing law after developing software for a while. Devs tend to be of similar mind as lawyers, so the transition seems somewhat natural. I recommend just getting comfortable with reading software licenses. Many software licenses have a number of similarities. MIT is a very permissive-use license but it is also very short and relatively easy to read and understand.
I don't think licensing is the problem here. What you're actually after is regulation. Regulation makes it the problem of governments, who can afford better lawyers than the average open source developer
can I change license after creating with a more strict one, I will like to change to a less strict one... just asking to know more, I understand if this is an open source project, it might affect those already using my project but let's say is not an open source project something am working on alone and no plan to make it open yet