Agreed, but if you are the only user, serve yourself first on the project. If you determine that you can't serve yourself and others at the same time, it might be a bad road you are going down.
"2. Use a Share-Alike License"
First, RMS hates the term "open-source", so it's funny that the idea is to promote GPL here. On top of that, you call for a share-alike license, which is a term used mostly for creative commons licenses, which are usually for creative works.
The license matters, but most people suggest Apache. (L)GPL v3 (not v2) is also great if you don't want it to be integrated into business products. I'm not sure why you'd want to use MPL v2 unless you are writing something for a Mozilla product? If you don't give a crap about your rights, choose MIT. Then, use a Creative Commons license for creative works that aren't free.
"3. Use an Zero-Consensus Process"
"Merge first, fix later"
No, don't do that. I understand you are trying to keep other forks from taking over, but you shouldn't allow everything. I've rejected some bad PRs before because the developer didn't understand what they were doing. There's no reason to merge that and then undo it. Explain to them what they are doing wrong and refuse the merge- then they will either fix it or you save yourself the trouble of having to undo it.
"4. Problem, then Solution"
"Every patch must be a minimal solution to a solid problem" is wrong. New features may not relate to a problem you or others are trying to solve.
"5. Contracts Before Internals"
Not every project needs its API documented to be successful.
"7. Write Down the Rules"
Those rules for ZeroMQ are really aggressive sounding. You don't have to use those. I think it's fine to just point people to docs about the PR process and information on how to build, test, release, etc.
I agree with merge first fix later, if you have sufficient work hours to actually do the fix: in the Freenet project we lost many contributors, because their code wasn’t merged in time, so they just lost interest: “my effort is wasted here”.
Truth is: Those who get their code merged quickly are more likely to review other code, so they grow the community.
You can only do that if you actually have the time to keep quality up.
"Quality" is a false goal. Remember the first arguments over Wikipedia and article "quality"? It is exactly the same here. You need people, contributors, eyeballs. Get that, and quality will emerge smoothly over time. Losing a contributor because "quality" matters more is self-destructive.
The rules I explained work together. If you allow large confusing patches, or features that don't solve clear problems, then it won't work as well.
you can use GPL in commercial products. Just follow the GPL. It's not ant-commerce. Oh, you meant "proprietary" products? The set of commercial and proprietary is not a union, it only overlaps.
Though it would be great if you could, don't use blackduck as the measuring stick. (Used to be Ohloh now) Blackduck is not a full view into the current state of open source and free software. I gave up on trying to keep my projects updated not long after the transition from Ohloh to Blackduck.
Apache is suggested as a free-software-compatible alternative to GPL v3 by RMS himself. In the past 15 years of contributing to open-source/free code projects, Apache is the longest standing license that over and over people have recommended. It is an intense license, but it covers the bases legally, whereas others do not. Still- I've used GPL, MIT, and BSD in the past- just learn about the pros and cons and choose what you think you should use, though.
If you have a better source, feel free to share it. This is a datapoint which strongly disagrees with your claim. It might be flawed, but that does not make it invalid. Do you have data which supports your claim?
That RMS says that you can use Apache if you don’t want copyleft does not support that it’s the most widely suggested. You can be sure that RMS will not suggest using Apache over GPL where GPL can be used.
There are less people who are opposed to Apache than there are people who are opposed to the GPL (or strong copyleft in general), but that does not mean that there are more people who would suggest using Apache than people who would suggest using the GPL.
Free Software proponents will say “I would suggest GPL, but Apache is still Free Software, so it’s OK”. This is not the same as suggesting to use Apache.
When I say "most people suggest Apache", I mean that for as long as I have been contributing to and developing with various open-source projects most people that I have talked with about licensing open-source or free software projects have suggested using the Apache license. I have also had someone tell me that he wouldn't use my project since it was MIT licensed, and suggest I start writing code under the Apache license if I didn't want to use GPL. Personally I have frequently not chosen to use the Apache license, but that is changing and actually I've been using GPL v3 in some recent work.
I suggested not using Blackduck's stats because they are incomplete. I know this because I used Ohloh for a few years and found that there were many projects that weren't listed there, and I did not have time to list all of mine there, and I have quite a few.
I do not have enough information to say for certain that GPL or any other license is the most well used license. If I had to guess, I'd say that there would be quite a large amount of code that is available online that has no stated license, so I'd think that would be the most common. After that, it could be "any version of GPL"- I don't know. Maybe Google with all of their resources and analytics would be best suited for determining a good estimate.
It depends on your definition. API is application programming interface, which means that if your product doesn't intend for it's internals to be called or it is a DSL, etc. you don't necessarily need to have formal API docs- you just need usage docs. If it is a C, C++, Java library, then yes, you probably want API docs/Javadocs.
This is just my opinion, but if you want any other contributors besides yourself, I think you definitely want API docs. Just because it's not exposed to the public doesn't mean nobody cares what a function/class does.
If it has a DSL, or any sort of scripting, as a user you damn well want it to have API docs. It's super frustrating to have a use case the author didn't think about, and you have to figure it out via trial and error because the author didn't think it'd be worth spending a few hours documenting what each thing is supposed to do.
Don't think that just because some projects were successful without API documentation, maybe because they served a particular niche, that means you can just ignore documentation because you feel it's not necessary.
I think you and I have different idea of what API docs are.
I think that good documentation for usage is a great idea, but not all projects need formal API docs, because not all of them intend for the classes in their project to be used as a library.
I agree with you that if your code intends to be used as a library, you should provide API docs.
And, if you expose a service then you should probably provide API service documentation with examples.
I'd add also that usage examples can sometimes go much further than API docs to clarifying things.
> If you don't give a crap about your rights, choose MIT.
Can you elaborate on this, because as written here, this seems like a negative statement? As someone who doesn't know/care much for licensing, I just choose MIT when releasing code, because I don't care what someone else does with it.
Aside from someone using/modifying my code in a proprietary program without crediting me, can choosing MIT come back to me negatively?
So what do you recommend? I just open-sourced my first library and I chose MIT licence because I feel it was what was recommended by github when they ask you to choose a licence. I really didn't explore my options much.
Pretty sure hintjens is on (y)our side, he did after all give "free software" top billing. The "aka" part seems like an acknowledgement that in 2015 many people see the distinction as an ancient battle that perhaps doesn't need to be fought in every commentary on free software, and perhaps also a way to be more inclusive of people who don't see a distinction at all or have any trouble reconciling the terms as synonyms
The point of view of Peter Hinjens about free software licensing versus open-source, IIRC: with most open source license people can lock you out of your work via free software or proprietary licenses whereas with free software licenses your are protected against that. Also big companies devaluate what's code worth through very liberal licensing because any fork can be pulled back into their master because they have the required labor force to merge back changes, in a way or another, but you don't. So individual and small companies are better protected with free licenses. IIRC he doesn't stress the so called "philosophical" stand of free software license are.
This is something I never understood. If I put a piece of code out there under a BSD style license, how can others lock me out of my code? Yes, they can add non-free code to their copy and distribute it, but my original copy is still there. Unless they add a feature that I was also planning on adding, and they patent that feature, which would keep me from adding the same functionality to my copy of the code. But how likely is that to happen?
You can find yourself using a computer that is running code you've written but that you are not free to modify because you are either only provided with binaries or actively prevented by the software from modifying it.
See iOS for how common this is, which is to say very.
No, copyleft isn't the difference. There is no difference in the software or licenses. It's just like saying "solution" or "software". You call it a solution if you're selling it to execs but you call it software if you're selling it to hackers.
In the same vein, you call it "free software" when you're promoting it for the freedom and you call it "open source" when you're promoting it for the practicality.
Then I am a hacker selling to "execs". Software is part of the solution. If I produce something and the competition can legally use it without in a way or another to give back. It's not a good enough investment. Maximising ROI, minimizing effort reminds of algorithm complexity. Big5 have interest to choose liberal license because it's defacto political standard. They basically don't care whether it's free or open from a economical stance. They are so massive that a little improvement in the internet economy will bring back to them revenue.
> you call it software if you're selling it to hackers.
Wrong. You just don't pick up any software you look at the ecosystem: are they contributors, how many release, downloads etc.. it's not just a problem of software. Most hacker I know don't look at the code to say whether a software is good or not, but instead take the "execs" stance of looking at the ecosystem and quickly processed metrics.
I mean that "solution" is the pointy-haired boss way to say "software". The pointy-haired boss doesn't care how the problem is solved, just wants a solution. The hackers see the software itself as the fundamental thing, not some abstract buzzword "solution".
Another example: you may expand the "DRM" acronym as "digit rights management" if you think it's fundamentally about authors' rights or you expand it as "digital restrictions management" if you think it's fundamentally about user restrictions. Two different terms for the same thing.
My point here with these examples is that the only difference between "open source" and "free software" is how you're marketing the same software and the same licenses.
If you say Open Source it implies that the choice of a copyleft license is a strategy to improve your return of code, but the default is “just be open”. The goal is to get other people to support you.
If you say Free Software it implies that the choice of a lax license is a strategy to improve your spread, but the default is copyleft. The goal is Freedom. It sounds easy nowadays, since there is so much Free Software that if you have some free time you don’t feel the restrictions from proprietary software.
If you want to feel the restrictions from proprietary software again, try changing the layout of gmail and keeping it in working state for 5 years.
"In theory, theory and practice are the same. In practice, they're not."
Open source vs free software is the opposite. Free software is about trying to claim the moral high ground, and proponents see a huge difference. Open source is about what works, and as long as it works all that silliness isn't all that relevant.
I would say that thinking they're the same means he's on the "open source" side of that, except that his "share-alike" promotional FUD is very clearly a "free software"-side argument.
Free software is about trying to claim the moral high ground, and proponents see a huge difference. Open source is about what works, and as long as it works all that silliness isn't all that relevant.
No bias here whatsoever. Nope.
Though, ironically, your justification for "open source" could just as easily be applied to proprietary software, rendering open source completely devoid of meaning.
It wasn't relevant to the article and I'd rather avoid rabbit holes. One has to pick one's fights. You can read my views on software licensing on my blog (How to Capture an Open Source Project), or book (Culture & Empire, Chapter 2).
There isn't a difference other than emphasis. It refers to the same set of software, but describes this same set of software differently. It's like saying "African American" or "black". The intended meaning is the same set of people.
Indeed, the term "open source" was coined as a marketing term for promoting free software:
No, the difference is in how the arguments are derived. Free software uses ethical arguments, whereas open source uses consequentialist claims about software quality, "many eyes catching bugs" and business value.
I am totally for Open Source (and Open Science), but I dislike copyleft licenses (cf. "2. Use a Share-Alike License").
And while Share Alike have their (good) use-cases, IMHO it is bad to recommend them as the default; the best standard is CC-BY or MIT/BSD.
Why? For me "open" means "open" - i.e. can be used by anyone, for anything (not "open, but only for the openness believers... and only of the same creed"). All share-alike clauses have issues:
- viriality (you have to get infec... I mean: accept another license instead of the one you are using),
- kosher rules (e.g. you can't combine GPL with CC-BY-SA).
Please, please, please, do not use the WTFPL, especially if you say you care about "openness" and "kosher rules." The WTFPL is so poorly written no one knows what it really means. Consequentially, legally-sensitive people/organizations may actually have a harder time using a WTFPL-licensed project than a GPL-licensed project.
If someone wants to make the point that they think licensing legalese sucks, and wants to license their work accordingly, then fair enough.
It's a little absurd that I shouldn't be able to, in plain words, express "This is my own work, and you can do whatever you want with it". Eg. I shouldn't need 'warranty disclaimer' to not be at risk of liability, unless I was explicitly providing some kind of guarantee in the first place. (It's just a bit of freely available software, hardly leaving a dangerous item out on the streets.)
Any legal system that leaves its citizens unable to be protected by simply using clear, plain and unambiguous language is failing in its duty to some extent, so I'm perfectly sympathetic to developers who choose "fuck that shit" as a personal preference. :)
> If someone wants to make the point that they think licensing legalese sucks, and wants to license their work accordingly, then fair enough.
As a protest license, it makes some sense, but I do not think that's what draws most people to it. People choose it because they want their code to be used by anyone, because they think it's the most "open." This is the motivation that the parent commenter gave for the WTFPL. But as a protest license, it's ideologically motivated just like the GPL and does a poor job at letting anyone use their code.
> It's a little absurd that I shouldn't be able to, in plain words, express "This is my own work, and you can do whatever you want with it". Eg. I shouldn't need 'warranty disclaimer' to not be at risk of liability, unless I was explicitly providing some kind of guarantee in the first place. (It's just a bit of freely available software, hardly leaving a dangerous item out on the streets.)
As much as you may wish this to be the case, it's not. It would be a pretty expensive way to make a point if you end up being sued because of the lack of a warranty disclaimer. This is a risk which I think is not adequately conveyed to people who choose the WTFPL.
So sure, it's a personal choice, but if you do choose it you're not doing yourself or anyone else any favors.
> It's ideologically motivated just like the GPL and does a poor job at letting anyone use their code.
Agree that it isn't a good choice if what you want is the most permissive, inclusive license.
(Completely with you there, and hadn't noticed the misjudged "with the openness, you can't beat the WTFPL" above.)
> Sure, it's a personal choice, but if you do choose it you're not doing yourself or anyone else any favors.
I wouldn't and don't use it for my projects, but I'd absolutely defend anyone else's choice to do so.
The choice to go with a license that actively eschews the standard reliance on legalese is a form of self expression. If someone chooses to use it and disregard the supposed legal risk, then I totally respect that.
He even points out that using it could get you sued due to the lack of a warranty disclaimer by default.
I've heard other stories of companies refusing to use WTFPL-licensed code, and that alone should discourage you from using it if you goal is really to let anyone use the code with no hassle.
To be honest, I never used WTFPL, except for one April Fools' Day project.
As you say, CC0 is the way to go for transmitting things to the public domain (when it's applicable; many European countries do not have the concept of "public domain").
I'd like to see more open source software, but more importantly higher quality and much better designed open source software. To make that possible, open source software needs well paid developers. I'm tired of seeing open source software that has unreadable code from 20 years ago, and looks like it was designed 20 years ago, too. Such software from my point of view is unusable and therefore pointless.
That's why I think the best model is offering open source code that is freely available for other open source projects (to expand "freedom" and all that) OR free/gratis software (or perhaps only to non-profits), BUT if you get paid for it, you have to pay for a license. I think it's more than fair that if you make money off open source software you should give a cut back to the creators of that open source code.
Right now we're in the shameful situation where large companies making billions of dollars in profit every quarter don't even pay modest sums to projects such as OpenSSL (this changed a bit, but only after Heartbleed happened, and there are many more such projects that don't get the same benefit).
I know there are some disadvantages to this model, such as having hardware built with open source software cost more than it would otherwise, but let's face it the alternative would be hardware that comes with proprietary unverified code that may cost even more. So I think this "compromise" is well worth it, considering it can get the open source developers the money they need to keep working on it and expand the project.
Unreal Engine seems to have a fairly successful model of gratis for everyone except commercial products, and then it is 5% royalty on gross revenue per product. You don't have to mess around with non-profit status, or create a divide between people. A simple rule that state 5% royalty on revenue for each product, and if there is no revenue then its 5% of 0.
I agree that it’s important to have more paid developers of Free Software.
I disagree with your shism between open source projects and getting paid.
People should get paid for improving free software, because many others know that they benefit from that. Copyleft is a good tool to ensure that the improvements can flow back into the projects.
The old-style BSD license is considered rather awful due to requiring a notice in your documentation somewhere.
Requiring money based on what you're doing with the software is more complicated, and dividing it up between all the included and depended-on projects is even worse.
I think it varies massively with what the open source project is and what the goals of the project are.
If you're implementing an open standard to try and encourage use of higher quality implementations of that standard, a permissive license is probably the right choice.
If you're creating an open-source clone of some software (be it the GNU OS or LibreOffice), a copyleft license makes far more sense—the fact it is open-source is the defining characteristic of your software.
>the fact it is open-source is the defining characteristic of your software.
That's a terrible thing to aim for with your project, because anyone else can duplicate your defining attribute with the mere choice of a license. Why not aim to make the defining attribute that it's the best?
In my opinion, share-alike licenses are important when you want to establish a level playing field for competition. With a share-alike license nobody has more rights than anyone else. The exception is the copyright holder (if there is only one) who can re-license the work.
There are many situations where this level playing field is useful. For example, consider it like a consortium. If you have many groups in the consortium, you want each group to contribute equally. The only way they are likely to do that is if one group doesn't get an unfair advantage.
So the downside of permissive licenses (like MIT) is that it can (in some cases) discourage cooperation. Let's say you have a library that you license with a permissive license. Your competitor may not want to contribute (publicly) to that library because they fear that you will use their changes in your proprietary code to gain advantage over them. In fact, there is an advantage to consuming permissive code and keeping your changes to yourself as long as you don't mind paying the cost of merging upstream changes.
Conversely, there are times when a permissive license is more appropriate/beneficial. In some cases, there is no real risk that others will "horde changes". For example, if you are the author of a programming language, it is in everybody's best interest to continue to develop it. Nobody really gets any advantage by making their own proprietary Ruby implementation, for instance.
People should think very seriously about which free software license they choose, because it makes a difference. Permissive licenses lower the barrier to entry, but potentially create one-sided advantages for some players. Share-alike licenses ensure that everybody is working with from the same place, but makes the barrier to entry higher.
Generally speaking, if you look at the free software ecosystem, you will see natural divisions. Software that creates an entire application (like a word processor, or image editor, etc) tends to use a share-alike license. They do not want someone to take their work, add some proprietary icing to it and take mind-share from their project. On the other side are development tools and libraries which tend to use permissive licenses. Nobody benefits from making proprietary versions of these things. Even if some tries to do so, nobody will be interested in it.
There are people who feel that ensuring everybody has the same opportunities is morally a better choice. Obviously some people disagree, but I often find it surprising that the two sides can't at least understand the other's point of view.
Very well thought out. Yes, recommending one type of license for all open source projects is naive. Frameworks and libraries need a different type of license than 'application' type projects. If it's not a MIT/BSD or something similarly permissive, these types of projects will generally not get used as much. I need to be able to modify these things at will, without ever having to think about licenses, especially in the case of bugs or problems that I cannot wait for the community to solve (if they're even going in the direction I am). If I'm going to distribute copies of my app, the license choice becomes one of the definitive criteria points in my choice of framework or library. For 'apps,' it's a much less critical choice and it makes sense to have a license that encourages collaboration.
The whole justification for share-alike (as opposed to permissive) licensing is traced back to the UNIX wars, where uncertain copyright attribution was a huge hindrance to developers and a source of commercial wars battled through litigation.
Share-alike protects against such fragmentation, allowing any developer to always take any improvements made to a different branch and merge it back to your version; with MIT licenses, that is often not an option.
A modern paradigmatic example is KHTML, the LGPL rendering engine that was the basis for Safari. Without the share-alike, it's uncertain that Apple would have released Webkit, and it would have been almost certainly impossible for Google to fork it as Blink - most improvements would have been unavailable to the public, with Apple using hidden changes as a competitive advantage.
> Without the share-alike, it's uncertain that Apple would have released Webkit, and it would have been almost certainly impossible for Google to fork it as Blink - most improvements would have been unavailable to the public, with Apple using hidden changes as a competitive advantage.
Hmm. They may well have eventually released it — WebKit did eventually get released (years after the code dumps of WebCore an JavaScriptCore).
Yes, maybe they would have released it, just like they released modified parts of FreeBSD. But the share-alike makes it less likely that they keep the best parts hidden, and more likely that there's a single reference implementation where improvements from competitors are kept close to one another.
Violating it? When did they ever do that, or get attacked for it?
They got complaints for just having code-dumps (or WebCore/JavaScriptCore) alongside releases, which made it hard to have any sort of individual patches. They were still in no way obliged to move to developing it in public, nor were they obliged to release WebKit.
I used to believe in the BSD license. The GPL is better for the users, even if it restricts developers more than a BSD license would. There are far more users in the world than developers.
For that matter, concerns about compatibility are the only reason to use GPL over AGPL. If you want to protect user freedom, just close all the loopholes and go AGPL with everything.
This must be understood in the light of the philosophy of Peter Hinjens which is the community comes always first, before technical assets. Smoothing community process and interactions is (very) necessary for a project success.
Growing zeromq ideas mainstream will provide more value to the project of improving distributed software than changing drastically zeromq (to (re-)build nanomsg community).
> testing coverage completely matters.
testing matters not testing coverage.
Testing matters as way to give insight about the project, api and protocols as such integration tests more useful that unit tests. This help people jump in, it's a way to document the API/Protocol.
Achieving the API and protocols is more important than having a good code coverage. If there is no code, there is nothing to cover, and nothing to show.
He develop his ideas of good community processus in the chapter Sphere of Lights of Culture and Empire essay [1]
It hurts a lot when your assumptions are challenged. The process we use in ZeroMQ is successful beyond all expectations. See http://hintjens.com/blog:93.
What I'm doing with these "Top 10" articles is documenting our experience over the last years.
I guess people said "OUCH!" a lot when Wikipedia said you could edit any page. It is really similar here.
I think wether such an approach works heavily depends on the kind of project (and as such shouldn't be posted as a general rule). For something relatively new and/or small it may work very well, but as soon as you reach a certain complexity it's unsustainable; at least if core components are involved.
This is his writing style, he does shortcuts to keep thing readable and you have sort out the real world constraints yourself. That said the book is readable but some arguments that are difficult to understand.
The title is very misleading. Yes, those ten rules may work well for one project. But they are not at all applicable in general. The Open Source world is way more heterogenous than that.
For example, my current favourite Open Source project uses a permissive license, always finds consensus on the mailing list before pushing to master, and is huge. Which is in blatant violation of rules 2,3 and 9 from the article. And it's been growing in popularity for decades.
There is no such thing as general rules for Open Source projects.
Glad to see this one in here. It seems like too many open-source project communities are incredibly hostile to newcomers or people with differing opinions. Linus Torvalds comes to mind.
Torvalds is mostly hostile to people responsible for important parts of the kernel who do Bad Things, eg. breaking userspace. Oh, and that one guy who called stupid his decision to use C instead of C++ for git.
I don't think that kind of hostility and deprecation is ever justified. The worst part is that he publicly defends his way of dealing with people online and sets a terrible example.
Agreed, but if you are the only user, serve yourself first on the project. If you determine that you can't serve yourself and others at the same time, it might be a bad road you are going down.
"2. Use a Share-Alike License"
First, RMS hates the term "open-source", so it's funny that the idea is to promote GPL here. On top of that, you call for a share-alike license, which is a term used mostly for creative commons licenses, which are usually for creative works.
The license matters, but most people suggest Apache. (L)GPL v3 (not v2) is also great if you don't want it to be integrated into business products. I'm not sure why you'd want to use MPL v2 unless you are writing something for a Mozilla product? If you don't give a crap about your rights, choose MIT. Then, use a Creative Commons license for creative works that aren't free.
"3. Use an Zero-Consensus Process"
"Merge first, fix later"
No, don't do that. I understand you are trying to keep other forks from taking over, but you shouldn't allow everything. I've rejected some bad PRs before because the developer didn't understand what they were doing. There's no reason to merge that and then undo it. Explain to them what they are doing wrong and refuse the merge- then they will either fix it or you save yourself the trouble of having to undo it.
"4. Problem, then Solution"
"Every patch must be a minimal solution to a solid problem" is wrong. New features may not relate to a problem you or others are trying to solve.
"5. Contracts Before Internals"
Not every project needs its API documented to be successful.
"7. Write Down the Rules"
Those rules for ZeroMQ are really aggressive sounding. You don't have to use those. I think it's fine to just point people to docs about the PR process and information on how to build, test, release, etc.