What do we mean when we say "Open Source"?
Closed this issue · 8 comments
There always seems to be a bit of confusion when people say "Open Source".
The general public seems to have a different understanding of what that means and even developers often disagree and misunderstand each other.
So I figured it would be good to ask the question and get everyone on the same page.
In general, I've found people mean one of three things when they say "Open Source".
- Jane Q. Public
- "Source Visible": The source is available to view, but takes no thought to how the code is licensed for use.
- Open Source Initiative
- "Open Source" as defined in The Open Source Definition
- Free Software Foundation
- "Free Software": as described in What is Free Software?
I'm assuming that we're not talking about "Source Available" software here, but we may need to explicitly call out and explain the differences between these concepts/definitions. The question in my mind is
Should Smart Columbus' code base be "Open Source" or "Free" software?
I have my opinions, but I would like to refrain from sharing them until other folks have had a chance to chime in.
As an Emacs user and general fan of Richard Stallman's philosophy, I would prefer our software be "Free Software."
I like the idea of considering this free software and yes I do agree.
To me this question may simply come down to which license we choose to use for our published works. I created #3 to track this.
One thing which had me thinking / wondering. What was meant by the wording of the session kickoff about "release to open source". I fully recognize this could simply have been quick decision wording however I would like to get this clarified in the issue here or elsewhere.
What parts of the platform will be open source? When do those components become visible to the public? How do we go about taking community feedback? What about issue tracking. Questions along these lines I think are part of this issue as well as the bigger picture.
My concern with the previous comment about "release to open source" is that it could indicate that a piece of software would not be developed in the open from the start. It implies that the software code would be released in the future which, among other reasons, is not what I would consider to be true to what I consider to be developing open source.
My concern with the previous comment about "release to open source" is that it could indicate that a piece of software would not be developed in the open from the start.
That is indeed where we are today @bilsch.
There is an entire team working on this as closed source software right now.
We're here to help make it open.
You bring up an interesting point though. There are many projects out there that would not be "open source" by your yard stick.
Take, for example, SQLite
Open-Source, not Open-Contribution
SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from unknown persons.
https://www.sqlite.org/copyright.html
The Android Open Source Project is another interesting example.
You can contribute to AOSP, but only to the last released version of it.
Google works on the next version behind closed doors.
There is not just the question of Open Source vs. Free, but also Cathedral vs. Bazaar.
As an Emacs user and general fan of Richard Stallman's philosophy, I would prefer our software be "Free Software."
@jdenen I generally don't agree with Stallman on much, but I think in the case of publicly funded code, it makes a ton of sense to ensure the rights of the public to use it.
I'm definitely in the "free software" camp. Freedom Zero is an old essay, but succinctly identifies the real value of GPL licensed free software:
Many people misunderstand Free Software and the GNU General Public License. Many people equate the GPL to the boogeyman, because it’s "viral", and that sounds like a bad thing. Here’s what viral licensing means: GPL software has the restrictions that it has, and that’s it. The GPL is quite restrictive on developers, not at all on end users. ... Regardless, GPL software has the restrictions that it has, but it can never become more restrictive. An upgrade can’t take away freedoms that I enjoyed with an older version.
(And here's a decent follow-on post from a different author.)
The freedoms assigned by the GPL do indeed present challenges to developers and would-be contributors. Many projects have attempted many different ways to facilitate contributions while also ensuring license compliance and code purity (that is, not permitting any non-GPL code from getting included). Contributor agreements, assignment of copyright, and all sorts of other things. It does end up creating friction to the process, and absolutely creates barriers to entry for new participants. I've explicitly walked away from adding trivial improvements to some projects because it was just too much work to jump through all the hoops.
The BSD and MIT licenses are the "most" free, generally speaking; but they don't actively prevent a wholesale change of license to something non-free. This is mostly a theoretical concern, but it's off-putting for some people to know that their freedom to use a project might be rejected. The burden of forking the last free version is too much for most people, especially if the project is of any real size or complexity.
The Apache license has been the one I've been favoring the most for the last several years. This is mostly because I have several friends in the Apache Software Foundation, and I think they're all much smarter and more informed than me. Their affiliation with the ASF implies agreement with the ASL, and that's a strong argument in its favor, to me.
Any license selection on our part will facilitate some future decisions, and constrain others. We can't really predict all of the ways in which our license will help or hinder us. I'm okay with any of ASL, BSD, or GPL; so long as we all understand why we select one over the other.
Any license selection on our part will facilitate some future decisions, and constrain others. We can't really predict all of the ways in which our license will help or hinder us. I'm okay with any of ASL, BSD, or GPL; so long as we all understand why we select one over the other.
To me the why is the single most important thing we need to think about in context of the different licenses.
I very much agree with what @skpy has described above and think we should consider switching direction a bit to think about what factors / considerations are important and how to weight them. Then compare that list with the licenses we have been discussing to see which license is the best fit and why.
Have we reached any consensus of what open source means here? I agree on the idea that we should consider the "free software" direction and consider this resolved - taking the decision into #3
posting a few links from a side conversation with @skpy
https://www.computerworld.com/article/2478585/open-source-tools/open-source-still-the-best-way-to-de...
https://www.linuxinsider.com/story/85646.html?rss=1
I think we're all on the same page now, so I'm going to close this.