Really, this should just be a big sign saying "use the MIT license".
This is a site for beginners to OSS licensing. If this is your first time, just choose the MIT. If it's not the first time, you get to worry about whether you want to restrict reuse with the GPL, whether you prefer the BSD (2-clause or 3?), whether you agree with Stallman's philosophy enough to put up with the downsides of imposing GPL on your users, whether patents affect you, whether you need copyright assignment, whether to set up an entity to own your code, and all sort of other license bullshit.
No way. GPL or LGPL every time IMHO. It protects your work from proprietary embrace and extend methods. That in turn helps keep it free for all to use and modify. Commercial licenses can still be compatible with the LGPL and GPL if done properly by the copyright owners of the code.
For an example of embrace and extend look at some of the libraries usurped by Microsoft such as Kerberos. I bet they wish they'd have used the GPL.
Cynical comment: do you really expect that on a startup forum, where people are explicitly trying to make businesses on a shoestring, people will advocate for not allowing proprietary embrace and extend methods?
So you're someone who clearly has spent a bit of time thinking through all the licenses, and has a good philosophical position on them. However, if you haven't done all that research, and just need a license right now, I think it's not wise to tell people to use the GPL, as it will have side-effects they don't intend, for features they're not interested in (perhaps, not interested in _yet_, of course).
This is a big decision. What is so bad about taking an hour or two to read about the differences? I know a lot about the different licenses because I went through this same decision when I decided to release a library I built under LGPL: http://sourceforge.net/projects/opensmtp-net/
I spent a little time and made a decision. I think everyone should do the same. Don't let someone embrace and extend your work unless you want them to.
So you're saying that a quick decision can't be made? I agree. A couple of hours is the bare minimum to at least try to discover them. But I still think people should try and understand the differences. I feel that the GPL is very important to OSS.
Probably true. I'd bet it's also unlikely that someone so new to free software will attract many collaborators. So they'll be likely to own the copyright anyway (for at least the vast majority of the project) and can relicense it later.
But, yes, if they're hell bent on not learning about the differences between the licenses, they probably don't want the GPL.
That's a big probably. I could just as easily say that people would probably be surprised that someone could not contribute back. After all, it's sharing code!
My personal view is that I should optimize for people getting involved. If it gets so successful that a company wants to use it without contributing back, its a nice problem to have (and it doesn't particularly bother me).
I know you have a lot more in OSS than I. Has this affected you much? Would love to hear any experiences - it seems you're sour on it and there might be a story there?
From my point of view, your free software license represents a marketing effort. But it's a highly specialized kind of marketing - it's your marketing to development communities.
From another point of view (also one of mine), your license says something about the kind of community you see yourself being a part of. And, when you make this choice, you are excluding certain kinds of participants and inviting others. But community is not just a license, it's also how you treat others, how you see them, and how they see you, and the kinds of activities they find interesting (and/or sustainable - sometimes but not often the same thing).
A license is also a cost. For some people this will be a moral or ethical cost. The more desperate the startup the bigger an issue cost starts to become. Related is whatever small bit of return the startup can get - this is the babyfood that it will need to survive and grow.
Ultimately, I think our systems of economics (and if you pretend we only have one you are fooling yourself) demand diversity. There cannot be only one good choice when talking about all startups. There can be one good choice when talking about a specific startup (but for a few, multiple licenses might be a good thing).
Not that I have ever spent any time thinking about these kinds of issues...
Finally, note that while what I am saying here is so overly general as to be entirely useless, there are other [almost conflicting] ways of thinking about these issues which can also have value for a startup.
> For an example of embrace and extend look at some of the libraries usurped by Microsoft such as Kerberos
Unless Microsoft tracked down and managed to wipe out all places that were distributing the code that Microsoft started from, they did not "usurp" the code. Anyone is still free to start with the same code Microsoft started with.
Yes one could do the same and create a new kerberos library that is slightly incompatible with the other library as Microsoft did. That, IMHO, was trying to usurp the kerberos project in the sense that it wanted to be the new standard. I don't see how that's off.
It depends what you want, though. Many developers are more interested in maximizing the popularity of their code rather than making sure it is always available under OSS terms. In this case, MIT is a much better choice.
The GPL restricts all non-GPL open source developers by stopping them from changing the license (except to a later version). The converse is hardly true since almost all non-GPL open source code can be relicensed as GPL.
Since this erupted into a fireball, here is a link explaining how code licensed under a permissive license can be included in a project that accepts GPL contributions:
Second, changing the license is a permission granted only to the copyright owner. Otherwise I could take BSD-licensed code, relicense it to WTFPL, and then include it in my code without any credit to the original author.
Most licenses do not permit any sort of modification or version upgrade. The standard GPL boilerplate is extremely unusual for giving third parties a range of permitted versions.
> almost all non-GPL open source code can be relicensed as GPL.
This is absolutely wrong. You do not have the right to change the license of someone else's code.
For what it is worth, this is where this argument often ends up.
You can reason that developers are users if you can reason that software is a tool.
You can reason that developers are not users if you can reason that software is a product.
You can reason that developers are both users and not users if you can reason that software is an ingredient.
And that is where it gets tangled.
There is absolutely no incentive to build GPL software into products because of the covenants it requires.
There is little incentive to not use GPL tools because the covenants result in a lower cost for the tools if they are covered by the GPL.
The effect of this is that the majority of users of products which contain GPL'd software, are developers. [1]
[1] Or family members of developers, my Dad has a router with OpenWRT running on it but he could not have installed it, nor would the company that sold the router ever use OpenWRT as the supported firmware for the product.
Okay, so changing a license to GPL does not violate the conditions of the BSD. You just have to maintain the little notice and the copyright. If you want you can call it GPL+BSD but it's obviously identical to GPL.
Basically, you can convert the same code from BSD to LGPL to GPL to AGPL, but you cannot go in the other direction.
> Okay, so changing a license to GPL does not violate the
> conditions of the BSD.
Yes, it does. Just because code is under the BSD license doesn't put it in the public domain. I still need to comply with its terms, and I'm not allowed to change the terms of other people's code.
> You just have to maintain the little notice and the
> copyright.
In other words, I have to continue to comply with the terms of the BSD license.
> If you want you can call it GPL+BSD but it's
> obviously identical to GPL.
It's not identical to the GPL, because all of the terms of the BSD license remain in force. I have to give attribution, I have to include the text of the BSD license, and (for the 3-clause version) I can't use the identity of the BSD'd library authors to promote my own work.
When two works are combined, it is very important to know that their licenses are combined.
> Basically, you can convert the same code from BSD to
> LGPL to GPL to AGPL, but you cannot go in the other
> direction.
The LGPL -> GPL -> AGPL path exists because these licenses explicitly state that code they cover can be used under the terms of the "stricter" license.
> Are you disagreeing with the FSF's lawyers here?
You linked to a source which has nothing to do with your argument, which makes me think you don't really understand the position you're claiming.
If you say that it's legal to change the license of BSD-licensed code to GPL, that means you think it would be legal to:
1. Download the FreeBSD kernel.
2. Replace the LICENSE file with the GPL.
3. Replace the authorship and copyright comments with your own name.
4. Publish the resulting code online.
Do you really believe that doing that would be legal? If so, that is such an extremely unusual position that I do not know what evidence would be required to correct you.
I'm sure that one could contrive a GPL wrapper project to contain the BSD kernel. Nobody ever said anything about removing copyright notices or breaking license terms.
I agree that I could have been more precise. Again, I thought this was widely understood. I apologize for my lack of clarity. I was never suggesting some extra-legal method; it simply didn't occur to me because I would never consider this in a software licensing discussion.
When I say relicense a BSD project under the GPL, I mean take the existing codebase and go through whatever legal steps are necessary (without additional permission from the copyright owners) such that the resulting distribution can accept future contributions under the GPL.
So do you now understand what I mean, and see that it's possible with the right legal wrangling, per the link from the Software Freedom Law Center?
> Okay, so changing a license to GPL does not violate the conditions of the BSD. You just have to maintain the little notice and the copyright.
Not requiring this downstream violates the BSDL, but requiring it downstream, violates the GPL, at least in GPLv2, which does not itself require it, and prohibits additional terms to its own.
I think the GPLv3's allowance of additional terms is broad enough to actually make some of the licenses that the FSF promoted as GPL compatible under GPLv2 but which were clearly not on a reasonable reading of the terms of the licenses compatible with the GPLv3.
> The converse is hardly true since almost all non-GPL open source code can be relicensed as GPL.
While the FSF has actively promoted this view, for many actual open source licenses for which they promote the view, it requires a rather creative (at best) reading of one or both of the two licenses involved to support this claim.
The GPL restricts all non-GPL open source developers.
Nope, only those that want to distribute their changes of GPL licensed projects. You're free to do whatever you want and keep the changes to yourself as long as you never distribute outside your machines or your organization (this allows closed in-house development).
I'm sorry I was hasty. I said that the GPL restricts all developers from relicensing the code as BSD, I thought that it was obvious that this meant only the ones that want to. So we agree about that.
"The converse is hardly true since most non-GPL open source code can be relicensed as GPL."
Which non-GPL open source licenses allow relicensing of the code? I've heard this claimed about the BSD code in a GPL project, but I was unaware the license permits that code to be relicensed as GPL.
Obviously if you can include BSD code in a GPL project, you can include all of it. There is no "50% limit" on contributed code, for instance. And the target GPL project can have zero lines of code. The reason you can do this is because the GPL has more restrictions that do no conflict with the BSD restrictions, and it doesn't violate the BSD license to slap the GPL on top of it.
Think about it: if you can release BSD code as closed source software, how is that okay but relicensing as GPL is not?
> Think about it: if you can release BSD code as closed source software, how is that okay but relicensing as GPL is not?
You are confusing source with binary on the close source side. The source is BSD and cannot be relicensed without the copyright holders permission. The closed source project has BSD-licensed source code that has no restrictions on distribution of the binary including adding a EULA.
The GPL project that has included BSD code cannot relicense the code to GPL without permission of the copyright holders. The BSD gives you no permission to relicense.
So what this means is that the license for the entire project is now effectively GPL. You cannot ship a binary without the source code. If you work on the codebase long enough such that you change every line, it will now be 100% GPL. Basically, it behaves exactly like a GPL project, along with all the restrictions, because the GPL modifications are mixed in with the BSD code.
No, its not exact - I can still extract the BSD code out of the project and use it without the GPL restrictions. You didn't relicense the BSD code, you just included some code that has its own license.
It would be legal to take BSD code and add an additional clause that said, "Not for military use." It's the same idea. You've changed the license by adding restrictions. The old version is under the old license. It's the same if you convert public domain code to the GPL.
> You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
The BSD does not say anything like that, so you are allowed to add restrictions. This is why you can place the GPL alongside the BSD, because you are adding restrictions. The BSD has nothing that isn't already present in the GPL (it is "GPL-compatible"), whereas the GPL has lots of additional restrictions, but since the BSD does not prohibit this, it is fine.
> The BSD does not say anything like that, so you are allowed to add restrictions.
That is not how copyright or the BSD license works. You don't get to change the terms, since BSD doesn't give you permission to change the terms. Only the copyright holder can change the terms.
The analysis is clear that it is contrary to the consensus opinion, and there is further discussion refuting it in the comments. It has never been tested in court.
Since the commenters over at Groklaw are much more informed than either of us, and there is much more written than we could ever hope to figure out going back and forth like this, I propose we call a truce.
What I meant was that you can stick an EULA on top of BSD binaries. The conditions of the GPL are not incompatible with the BSD conditions, and GPL + BSD = GPL, because it's a superset of restrictions.
All the distinction in each open source and free software license is about the legal contract (EU) or legal document (US) that developer gives in tangent with software distribution. The legal information describes the circumstances that further distribution can be made by the recipient.
First timer or not, either they care or they don't about said legal details. If they don't care, then the choice doesn't matter. Pick what ever license is used by libraries, or pick randomly by dart. If they do care, then they surely care enough to read up on the subject and pick based on their (or their community's) liking.
This. GPL "code sharing" sounds harmless until you realize that it is enforced with a 500 pound ball of red tape that prevents commercial use in numerous typical development scenarios.
What it ensures is that the source code will be released along with any uses. If a products uses your code and someone requests that code from them, they should be able to point to your repository, or theirs, and provide a copy.
Now let's say one day you change course and want to close the source for future development. That is completely okay. Only the code you have already released will be out there under the GPL and the future work will be covered under your new license. Any open source libs you use, you of course have to provide the source for. What this does for all of us is it ensures the source code is available to the developer/consumer and they can modify it as needed.
Just some background, I released an OSS SMTP library in 2000 and I've never had a problem using the same library in any commercial product and in fact I went on to build a small component business on it by offering new closed-source features, such as S/MIME, and support contracts to go along with the purchase.
This is so factually misleading, I don't know where to begin.
On the subject of:
Now let's say one day you change course and want to close the source for future development. That is completely okay.
It may not be okay though. If your code incorporates other people's GPL code, you are unable to close that. And due to the "viral" nature of the GPL, the fact that your code may work together with someone else's GPL code could mean that you can't close your own code either. So you have to be very careful.
It is true that the GPL does not explicitly prohibit commercial use, but this is not the same thing as being broadly compatible with commercial use. In general, the GPL is hostile to commercial use by a whole variety of restrictions, including the requirement to share source code. This may not be immediately obvious to OSS newcomers who just want to share their code and have people use it freely.
At some point in the distant past, there used to be a site that had a huge matrix of licenses, that allowed you to look across one axis for one license, down the other axis for a different license and then basically read the consequences of combining code with those two licenses.
I liked that site and for the life of me cannot find it again. Things like "can I copy Apache licensed code into this LGPL code" were answered really simply, even when the answer included comments around making changes available, impact on copyright notices etc.
Does anyone know of anything similar these days? Don't get me wrong, the site linked here is great, but for me, at least, the fuzziness is in the legalities of combining code...
I'm not familiar with the site you're thinking of, but the Open Source Initiative has one of the largest treasure troves of license information I know of: http://opensource.org/licenses
Every one of those licenses is more pretentious than I'd like. Does anybody know the closest one to: "Here's some code. Do what you want with it?"
As a guy releasing code, I don't want you to feel obligated to me in any way. I don't want you to have to attribute back to me, or even acknowledge in any form that you've used my thing. I certainly don't want to do anything silly like force you to open source the rest of your code.
I just want to give stuff away. It doesn't seem like that's very possible these days.
Giving stuff away without a license can be hazardous to your livelihood. This is due to the concept of "Implied Warranty" (http://en.wikipedia.org/wiki/Implied_warranty), which says that anything you sell must be suitable for its intended purpose. This means that the fruit that you buy at the store cannot be spoiled, and the software that you sell should be free of serious bugs.
"Wait," you're thinking, "I didn't say sell. I said give away!"
Ah, yes, but were you planning on accepting pull requests? Because exchange of money is not the only way to sell something. There is also the concept of "In Kind" payment (http://en.wikipedia.org/wiki/In_kind). So, you make a library with something like a WTFPL license attached. I download your library and use it for my product. Then, to show my gratitude, I submit a pull request with a new feature to one of your other projects (an "In Kind" payment). Later, I find that your first library has a bug that's causing problems for my customers...
...so I sue you for violating the Implied Warranty that you didn't disclaim in your WTFPL license.
This is why all of those open source licenses have the ANNOYING ALL CAPS clauses explicitly disclaiming any implied warranty.
In kind is particular tricky legal aspect regarding software. In a previous comment, I wonder if services that take data as payment in exchange for service should be taxed. It would put pressure on companies like google to either stop taking in data, or pay per data point. I can see however that taking that viewpoint would put many other tit for tat in question.
So, as far as in kind is viewed by the state, software has been left alone.
Anyone who wants to take it and use it in their own project (whether open source or not) is free to do so.
For me, this provides more "freedom" than the GPL does. I don't care if others provide their changes back to me or if they take it and incorporate it into a successful commercial project and make a few dollars from it.
I'm a big fan of OS X (as are many others on here). I don't think it would exist today if not for the BSD license.
I write free software, and share it with other people who write free software. I don't share it with people who write closed source software. They are free to write their own versions of my software. After all, that's exactly what they expect me to do, write my own versions of their software.
I'm a big fan of Linux (as are many others on here). I don't think it would exist today if not for the GPL license.
I would just like to say that I am increasingly in agreement with you. I'm starting to think that many of my new projects will be AGPL. Congrats on being calm and explaining your position well downthread, even though there's a lot of GPL hatred here.
> After all, that's exactly what they expect me to do, write my own versions of their software.
This part is particularly well explained, thank you.
> I don't share it with people who write closed source software.
Of course you do. GCC was shared to great effect with Apple.
Furthermore, when somebody writes MIT/BSD code (for example Apple), they share it with you because you can put it under the GPL. But when you write GPL code, you don't share it with them because they can't relicense it as MIT/BSD code.
"Of course you do. GCC was shared to great effect with Apple." - Obviously when I said "sharing" I was talking about using my code in their products. But you knew this.
"Furthermore, when somebody writes MIT/BSD code (for example Apple), they share it with you because you can put it under the GPL. But when you write GPL code, you don't share it with them because they can't relicense it as MIT/BSD code."
That's fine. They're happy for me to not share any changes I make with them. They explicitly told me this when they released it under MIT/BSD. That's their choice, and they are free to make it.
I wouldn't be happy with that arrangement if it were my code, so I choose a different license. As is my choice. If I spend time working on their code, my changes are going to be released under the GPL, because I don't want my code to be used in closed source software. Where's the problem?
So yeah, it sucks that they can't re-use my code. But that's their choice. And I'm assuming they're happy with their choice because of the license they chose. if they weren't happy with this arrangement, they'd have chosen the GPL.
[edit] Also, even if I do this, I am still sharing my code with them, as long as they are happy to keep it out of closed source products. If they think it's more important that people can write closed source software with their code, than integrate my code into theirs, that's fine. Again, their choice. Everyone is free to do what they want. Even people who write closed source software. They are free to open up their code to me if they want to use mine.
>That's fine. They're happy for me to not share any changes I make with them. They explicitly told me this when they released it under MIT/BSD. That's their choice, and they are free to make it.
Thank you for putting it so well. I'm amazed by the number of comments on this page that disparage GPL developers for not sharing reciprocally, while promoting licenses that intentionally don't require reciprocal sharing. It's nuts.
The GPL developer's idea of sharing is sharing on his terms. The BSD developer's idea of sharing is sharing on the other person's terms. Of course BSD developers would like GPL developers to share on BSD terms instead of GPL terms, and of course GPL developers have no problem whatsoever with BSD developers sharing on GPL terms, because they already do. So it's quite easy to see how from the BSD developer's perspective, GPL developers are greedy. To counter this, the BSD developers don't want to enforce the four freedoms, which is unprincipled from the GPL developer's perspective.
Here's a different perspective. For context, I don't write much general-purpose software, but I am writing one or two free/open textbooks[1,2] (for statistics/econometrics) and I've thought a lot about how they should be licensed. I think the issues are similar.
My biggest concern in this project is "abandonment." There are lots of fantastic books that have since been abandoned by their authors and are no longer suitable to assign for a class---sometimes the author died, sometimes they moved onto other projects; a few key chapters might still be relevant, but I can't expect students to buy 9 different textbooks and read one or two chapters from each one. There are even completely free textbooks (Bruce Hansen, an extremely well-respected econometrician, has one[3]), lots of teachers have online lecture notes that are quite good, some of the stuff on MIT's OCW are excellent, etc. But I don't know what anyone's plans are for maintaining those resources, what direction they plan to go, whether they will keep them free in the future, and so on.
What I'd really like to do is be able to maintain my own copy of this material so that I can continue to add to it if the original author loses interest, correct typos, etc. For most of these books that's impossible because they aren't licensed for that (even if the book is out of print). But even for Creative Commons books it's not feasible, because they only distribute the pdf. If you look at Hansen's book (link below; it's not CC, but it's representative of the material), you'll see that there's a lot of math in these books, so backing out a human editable version of the text from the binary would be a lot of work.
So, I think that there should be free textbooks and I know that textbook projects are often abandoned (or eventually made non-free) by their authors. So it's pretty clear to me that the best way to have there be free textbooks is to write one (unfortunately, since it's a lot of work, but I do have lecture notes from when I've taught these classes as a starting point) and to use a license that entitles anyone who gets a copy of the book to also have a version they can edit and maintain. The GNU Free Documentation License[4] is the only license I know of that does it (it's the GPL of documentation), so I chose it instead of any of the CC licenses.
The FDL is more burdensome than I need it to be; if someone prints out a chapter of the book and hands it out to his or her class, I don't really need every student to get a printed version of the FDL (I'm fine with the professor just telling them about the FDL), but on balance I think the license makes the project stronger. No one needs to worry that I'll abandon or derail these books, because the license guarantees that they can fork them (no matter how they originally got a copy of the books).
I don't think that people who use CC licenses for educational material are unprincipled. Even though I think that the FDL is a better for projects like mine, it's great that they're making the material widely available (even if I worry that it will eventually be abandoned, the fact that I can redistribute their binaries is very nice); and I definitely don't see why they'd think that I'm greedy for choosing the FDL.
It's a fine option, but over, say, 30 years (well within the lifespan of a good textbook if it's getting updates) there are likely to be copies of the book that aren't accompanied with the source code. Especially for books where instructors might want to make printed copies available (less so for my books, but definitely a possibility for textbooks for 300 student introductory classes). IMO the FDL makes that scenario less likely and so strengthens the project which is worth the added inconvenience of the license.
The FDL also allows commercial use and textbooks can be expensive; I think it's likely that a publisher would try to bundle or repackage a free book if they could make money off it, and I don't think they're too likely to make it obvious that the book could be downloaded for free unless they're required to. CC NonCommercial would be less free than the FDL; I don't mind someone else making money off the books per se (especially if they are providing real value, but even if they're not), but a lot of the strategies that many textbook publishers use to generate revenue don't serve students very well and would weaken the project.
Like I said, I appreciate the effort put out by people making educational material CC, and I appreciate it even more if they make the source available. But for this type of project I think the source being available is the most important thing so I've chosen a license that makes it mandatory. For other projects I might decide differently.
I think for physical books it's much easier to make money with a copyleft license, so it does weaken the argument for allowing closed source books.
I would still personally choose a permissive CC equivalent of a BSD license though (CC BY 3.0), if only because I want other people writing books with permissive CC licenses to be able to incorporate my material. Also, for a closed textbook, a publisher might want to take a couple chapters out of my book, or 10 of the images, and I'm not okay with limiting the amount of quoting.
> I wouldn't be happy with that arrangement if it were my code, so I choose a different license.
If you're approaching this from an "ethics of sharing" stance, then what what you're actually restricting is somebody else's use of their own code. Your code never disappears/changes/gets relicensed, it's their code that you're staking a claim to.
Now, if you're approaching this from a stance of withholding certain valuable rights to your code, such as the ability to be the only person that licenses closed source usage, then the argument is a bit more logical.
> They are free to open up their code to me if they want to use mine.
"then what what you're actually restricting is somebody else's use of their own code. Your code never disappears/changes/gets relicensed, it's their code that you're staking a claim to."
This is some very bizarre reasoning. They still have their code. They are still free to do whatever they want with it. If they want my contributions in their product, they made a serious error in their license choice. Maybe they should have used the GPL.
But do you know what? They can use my code. They are completely free to use my code. As long as they only use it in GPL software.
"I do. Under the MIT license."
By saying this, you are saying to me that I am free to re-release your code under the GPL and add my own contributions. If you are not happy with this arrangement, you have made an error in your license choice.
I have not made any errors in my license choice. It behaves exactly in the manner I want it to.
It's like this. You have different ethics than I do or pbsdp does. We believe it's unethical to impose restrictions on developers, and if that means we can't guarantee the freedom of users then so be it. You don't have a problem with imposing restrictions on developers (at least restrictions that you like), but you do believe it's unethical not to guarantee the freedoms of users.
There's no way to resolve the conflict. We just have incompatible values and understandings about what sharing means. Our values are more liberal (the FSF uses the word permissive), so that means that you're free to exist in our world. We'd like to be part of your world as developers, but we aren't willing to embrace your restrictions.
Absolutely. Like I said, I have no problem with other people choosing other licenses which meet their requirements. My requirements are different. The GPL is most appropriate for myself.
I don't choose a license to meet my requirements. I choose a license to meet everybody's requirements. So when you don't choose a license that meets everybody's requirements, it makes me question the value of the freedoms it provides, and I end up wishing you'd chosen something more open.
It's funny that you think your license choice meets everybodies "requirements" and mine doesn't. I think the exact opposite: I think yours meets the requirements of yourself and other developers. In comparison, I think my choice meets the requirements of humanity. Especially in the long run.
You wish I'd chosen differently. I also wish you had chosen differently, as currently from my point of view, you're helping the propagation and spread of closed source software.
Simply: I don't want my code to be used in closed source software, so I can't use your license. That choice is simply not open to me.
The pros of GPL software address the cons of closed source software, and the pros of closed source software address the cons of GPL software. So by choosing the BSD I'm actually helping spread both of these things, because they can both incorporate my code. It's a neutral position philosophically.
> By saying this, you are saying to me that I am free to re-release your code under the GPL and add my own contributions. If you are not happy with this arrangement, you have made an error in your license choice.
No, I'll remain content with my license agreement, I'll just think that you're a dick.
That's OK, though -- some people behaving like dicks is simply the cost of collaborating openly.
I wasn't attacking your choice. I was explaining what your choice consists of and why I made a different one.
If you don't want people to do something particular with your code, yet you choose a license that permits it, then by definition, you chose the wrong license.
I'm going to chalk your childish, immature and unprofessional insults down to frustration. And to prevent further noise, I am not going to reply to any further comments made by you.
I'm also a big fan of Linux (I've been a user for ~18 years now) and of free software and the GPL (click on my username).
I don't write (or publicly release) much code but I truly want anyone to be able to do whatever they wish with it (whether the result is open or closed). Unfortunately, the GPL doesn't allow that.
That's cool. I'm not saying that is a bad choice. I'm just saying that for me, if you want to use my code in your project, I expect you to reciprocate.
I think a World full of closed source software would be dramatically worse than a World full of open source software. This is why I love the viral nature of the GPL.
You know what's more important to me than to do whatever I wish to with your code? Doing whatever I wish to do the code of every single person using your code.
Of course, the chain can't end with me and I'll have to publish my own changes. But it's worth it, I'm not a proprietary software asshole, and in the end I'll benefit from other people's changes and insert it back in my own code and improve my sales that way. You, me, the other programmers, Stallman, the users, everybody wins!
That's how I see it anyway. In the end, you have your own priorities and if you like to give without always receiving, that's understandable too. Ah, tradeoffs...
Still require copyright notice and permission notice to be included in all copies. If you are a embedded developer, that requirement is still very much there.
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
Then that annoying all caps standard 'I AM NOT HELD LIABLE' sentence:
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
You're actually creating more obstacles to using your code if you release it under a license that hasn't been vetted by any lawyers. Many companies have their lawyers approve of a given license before adopting code under it, and because of this friction, often it's simpler to just have a company-wide policy to only allow use of code under X, Y or Z licenses and none others. Please just use MIT or BSD.
Exactly that. I've licensed a couple of things as WTFPL. It says: not only can you do what you want, I reject all this GPL-style "my freedom is better than your freedom" buffoonery.
If you're afraid of offending people and therefore want to relicense under CC0 or MIT or whatever, you can, because WTFPL allows you to do WTF you like. Obviously.
My understanding is that CC0 was created in response to a lack of clear method (perhaps in some jurisdictions?) for placing a work in the public domain.
The license combination feature is quite flawed too, as it fails to tell you which license of two you must use in the case where it's required; and in some cases where licenses are not compatible, it fails to mention. (eg, MS-PL and GPL)
If you want your library to be usable on iOS, Windows Phone OS, most game consoles, you should avoid the GPL as they are incompatible with the stores that the applications are sold through.
Excellent page. Only thing missing is the GPL vs LGPL issue about viral and non-viral copyleft. I am not saying that being viral is a good or bad thing, it is just a choice a developer must make when picking a license.
I'd argue that omitting such important differences like the differences between LGPLv3, GPLv3 and AGPLv3 is detrimental to the effort of making licensing "less scary". Given the summaries for GPLv3 and AGPLv3 for example, somebody might think they have identical terms. The only additional information they give is a link to the license text (which is a terrible light grey font on white background). The original license text is what might be scary about licensing: because people struggle to read the legalese.
There needs to be a concise summary of how these licenses differ, one that they can comprehend without reading the whole license text. Website is a good idea, but IMO, needs a lot of work, and may even be harmful in it's current state.
I'm also not sure why they promote the GPLv2 (without + clause) over the GPLv3 either. That may convince someone that people will always share their code, and doesn't mention tivoization. Seems like a deliberate ploy from someone who dislikes the strong copyleft of GPLv3 family to prevent people using them.
I think an improvement would be to have multiple options and to filter down licenses until only a few remain: so eg, when I click "I care about sharing improvements" on the front page, it gives me another few options, like "I want people to share their modifications for hosted websites", or "I want people to be able to use in commercial apps" - which would filter to AGPL and LGPL respectively.
The GPL is not more "viral" than any other software license.
To distribute a product that uses GPL'd code, the rest of that product must also be under an open-source license, but there is no requirement that everything be licensed under the GPL.
There are plenty of licenses that are less viral than the GPL, such as BSD, MIT, etc. Furthermore, if you're pulling code from multiple sources, there are licenses, such as CDDL, that are mutually incompatible with the GPL. So yes, looking at virality very much does matter.
For most discussions about the GPL, people call the GPL "viral" from a misconception that it can't be combined with or depended on by non-GPL code. This belief is obviously wrong, but it persists.
Both the GPL and LGPL can be combined with and depended on by non-GPL code, so if the LGPL is not "viral", then neither is the GPL.
Viral as in requiring my code to be compatible with the GPL ecosystem, and in restricting my choice of licenses.
As I gave as my example, I can use a library licensed under the LGPL, and link it with code licensed under the CDDL. I cannot do that with a library licensed under the GPL. With that GPLed library, I'd have to use a license that the GPL is compatible with. So, if I had a product that I wanted to link with both sides, I would need to license my code under a license that is mutually compatible, such as BSD or MIT; I would be restricted from using certain other copyleft licenses.
> Viral as in requiring my code to be compatible with the
> GPL ecosystem, and in restricting my choice of licenses.
By that reasoning, all software licenses are viral. Even the 2-clause BSD license would be viral, because you're not permitted to distribute it combined with code that it's incompatible with.
> As I gave as my example, I can use a library licensed
> under the LGPL, and link it with code licensed under
> the CDDL. I cannot do that with a library licensed
> under the GPL.
That's simple license incompatibility. There are many licenses that are incompatible with the LGPL, and you wouldn't be able to distribute the combined work any more than you could a combined CDDL/GPL work.
> So, if I had a product that I wanted to link with both
> sides, I would need to license my code under a license
> that is mutually compatible
Again, this is true of every copyright license ever created. That's what "incompatible" means.
> By that reasoning, all software licenses are viral. Even the 2-clause BSD license would be viral, because you're not permitted to distribute it combined with code that it's incompatible with.
You're reinventing definitions to suit your argument. The BSD license creates no restrictions on what you can combine it with. The restrictions are defined by to the GPL.
All licenses (except, in some jurisdictions, the public domain) have restrictions. They may be minor, they may be "common sense", but they are still restrictions. The BSD license has restrictions on how code may be redistributed, in particular its requirements regarding attribution and non-endorsement.
If I released some code with a license that said:
This work may not be combined with any work which has a
license containing more than twenty capitalized letters.
Then that license would be incompatible with the BSD license, and it would be illegal to combine the two works.
So if you define "viral" to mean "a license which can be incompatible with other licenses", then the GPL would fit that definition, but so would many other licenses (including the BSD license). Thus, it is not a useful definition.
There is no useful definition of "viral" which covers the GPL but excludes the LGPL.
You're engaging in standard GPL goal-post moving; somehow if you redefine all the words we'll all accept that the GPL isn't a restrictive viral license.
> For most discussions about the GPL, people call the GPL "viral" from a misconception that it can't be combined with or depended on by non-GPL code. This belief is obviously wrong, but it persists.
Debian obviously thinks this is a problem, or else they would not have any problems with the GPL incompatible OpenSSL license.
The problem of license incompatibility isn't unique to the GPL. You could have software under a license that's incompatible with 2-clause BSD, but that doesn't mean the BSD license is "viral".
For example, the OpenSSL license is also incompatible with the LGPL; does that mean the LGPL is "viral"?
> For example, the OpenSSL license is also incompatible with the LGPL; does that mean the LGPL is "viral"?
I am not anti-GPL. My original and only point was that the distinction between GPL and LGPL is important to explain, and the situation with PostgreSQL at Debian shows there are real world implications of this.
> For example, the OpenSSL license is also incompatible with the LGPL; does that mean the LGPL is "viral"?
You have any source for this? LGPL was created to allow linking with any software. If you just copy paste source they are not compatible.
> My original and only point was that the distinction
> between GPL and LGPL is important to explain
It's actually pretty easy. The most important difference is that the LGPL permits bundling of your code with the LGPL'd code into a single combined work. The GPL would require your code to be open-sourced, but the LGPL has special provisions to permit bundling.
This is most relevant when using static linking, but also applies if you're distributing your program with a bunch of included dynamic libraries. The LGPL is important for proprietary applications because it lets them (for example) bundle a version of GTK+ that they know will work properly, so they don't have to depend on whatever version is installed on the user's system.
> You have any source for this? LGPL was created to allow
> linking with any software. If you just copy paste
> source they are not compatible.
"Compatibility" is typically considered when there's going to be works under two licenses combined into a derived work. The OpenSSL license is incompatible with the GPL and LGPL because it has requirements (the advertising clause) that the GPL/LGPL prohibit. So if you want to take some OpenSSL code and some LGPL'd code and compile them both together, you wouldn't be permitted to distribute the result.
The LGPL offers a workaround, which is to separate out the LGPL'd code entirely into a separate library, and then set up your build system so users can relink against a modified version of the LGPL'd code. In this case, the OpenSSL code is being treated as if it were a proprietary blob. So it solves the problem of distribution, but with the hassle of maintaining that clean library separation.
There's only one way compatibility where combination is concerned w.r.t the GPL. You can combine several different licenses, but the end result must be GPL licensed if it depends on GPL code.
I'm afraid you are wrong. I implore you to read section 5 of the GPL text. Particularly:
> You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
> c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
> If a library is released under the GPL (not the LGPL),
> does that mean that any software which uses it has to
> be under the GPL or a GPL-compatible license?
>
> Yes, because the software as it is actually run
> includes the library.
For this argument, the relevant part is "or a GPL-compatible license". The BSD license is GPL-compatible, therefore I can license my work under the BSD license, and not under the GPL.
For section 5, consider the implications of your quote, especially the final sentence:
> This License [...] does not invalidate such permission
> if you have separately received it.
Section 5 means that anyone who obtains a copy of the work is automatically entitled to a license under the terms of the GPL. It does not prevent additional licenses from being offered, and does not replace additional licenses present on a combined work.
This isn't wholly true - the compatibility is only one way, which was back to my original point. "Compatibility" with the GPL is, according to the FAQ:
> In order to combine two programs (or substantial parts of them) into a larger work, you need to have permission to use both programs in this way. If the two programs' licenses permit this, they are compatible. If there is no way to satisfy both licenses at once, they are incompatible.
A BSD work which depends on a GPL work therefore, cannot be "Compatible" with the GPL because it fails to meet the criteria previously quoted: "You must license the entire work, as a whole, under this License ...".
What you are trying to claim is that you can write BSD code which is API compatible with readline, but if you are not distributing readline with it, it is not a dependent work. (ie, there are other works which are API compatible with readline). The condition here is that APIs cannot be copyrighted. In that case, you can distribute only your code which uses the API under your license of choice, but you cannot distribute the work as a whole under anything but the GPL.
The only point that matters about Readline is that if you link your BSD program to it, then when you distribute the binary, you also have to provide the source to your entire program. This makes it effectively GPL, because the BSD license has no such requirement. That is what the term "viral" refers to.
That's not the case: you cannot distribute the linked binary under any license other than GPL. You can only distribute the BSD code (or compiled, unlinked object code) which calls readline functions, only if you do not distribute readline with it.
If your code makes calls to readline functions, and you distribute readline with it, it is undoubtedly a "covered work" as described by the GPL, and is subject to section 5.c of the license which states that the whole work must be GPL if distributed
5.c says "This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it."
So you can distribute a BSD project with readline, and recipients are free to choose the BSD license for the BSD part and then distribute a closed source binary linked against a compatible readline replacement. The GPL does not invalidate the permissions granted by the BSD license.
The only goal of the FSF here is that the source code for anything distributed linked with readline be made available under the GPL. They don't stipulate that it only be made available under the GPL and not any other license.
The use of the term "viral" is generally considered inflammatory and unhelpful. An uninformed reader might be led to believe that the act of linking with GPL software can somehow "infect" proprietary software, causing it to be open source. This is incorrect. The GPL restricts distribution (i.e. the combined work may not be legally distributable to anyone), it doesn't "infect" things.
"Viral" was the only word which sprung to my mind when looking for the right word. And personally I think viral is a mostly neutral word (see viral marketing) which describes the situation. Would "share alike" be a better word perhaps?
But isn't LGPL is copyleft too, but not viral on linking. The only reason I used "viral" is because that is the clearest word I could think of, and still is.
If you "care about sharing improvements" then choose a license to maximise contributions.
The GPL imposes major headaches / restrictions on potential adopters. This reduces uptake, which reduces contributions, thereby reducing sharing of improvements.
As a counterexample, look at Apple's opinion of GPLv3. Because there are certain clauses that have open legal questions, such as the ones regarding patents, Apple has very strict requirements for internal developers wishing to use GPLv3 code for any task, with a requirement that no published code be GPLv3. Thus, regardless of quality, Apple decided to switch to, and contribute to, projects that did not have such restrictive legal terms attached to it, giving back even when they had no requirement to.
> Thus, regardless of quality, Apple decided to switch to, and contribute to, projects that did not have such restrictive legal terms attached to it, giving back even when they had no requirement to.
There is something contradictory about requiring others to act "more freedom promoting."
It depends on your perspective though: is your license aimed at developers only, or all end users. The GPL makes it quite clear that there's no distinction between them, everyone is an end user who may not restrict another end user.
Other more "permissive" licenses can be used to constrain anyone though, because the developer sees the license was only for him, and those permissions are not relevant for his end user.
This is great, and something we as a community need. I work on CocoaPods the objc dependency manager and we have a strict rule of no-unlicensed code. Meaning for a lot of libraries adding themselves to our toolchain is the first time they've ever had to think of the license.
As this is a github project, I'd definitely like to make it known that it would be really cool to have some integration with the license on github's side on a per-repo basis. Asking people to create a license when creating a public repos at the same time as a README could really help get people thinking about licensing.
Their new repo page points to choosealicense.com and lets you choose any of the major OSS licenses, though it does show the MIT, GPL3, and Apache ones in bold.
I'd definitely like the option to add a license to my repo after creation though, instead of having to manually add a license to the repo and then pushing it. A UI for asking collaborators if it's okay to retroactively open-source their work under a specific license would be useful too.
I have a question about the Apache license....I'm trying to understand if an end user must accept the Apache license if I use a library under it in my software. I do understand that I cannot remove the license from the module source, but I'm not sure what needs to provided to the actual software user.
Primarily, the license need to be provided to the software user. No user need to accept the license, as it only impact those who redistribute the work. If the user redistribute the work, then they are also bound by the license.
Additionally, If you are distributing any source material (images, source code and so on), then any modified file need to include a notices stating that the file has changed. You may also not remove copyright, patent, trademark, and attribution notices in said files.
If the Work includes a "NOTICE" text file (also any credit buttons with similar content), you may not remove it.
Hey this site is biased. GPL doesn't restrict end-users or contributors. It only restricts distributors (middleman). While permissive licenses such as APL, MIT don't restrict the distributors, even if they remove the rights of end users.
They are more or less incompatible. If you want to specify patent protection and/or source sharing requirements, it can't be simple like MIT. And if you want permissive, it makes no sense to demand for source sharing as well.
This is a site for beginners to OSS licensing. If this is your first time, just choose the MIT. If it's not the first time, you get to worry about whether you want to restrict reuse with the GPL, whether you prefer the BSD (2-clause or 3?), whether you agree with Stallman's philosophy enough to put up with the downsides of imposing GPL on your users, whether patents affect you, whether you need copyright assignment, whether to set up an entity to own your code, and all sort of other license bullshit.
First timers should use MIT, every time.