On GitHub a fork is a lightweight thing. People fork the repo in order to contribute because they can't push to the original repo. It's not like you are philosophically against Emacs and decide to fork it to produce XEmacs.
Just as I don't understand the original comment, I also don't understand yours. You don't need to push to the original repo because open source allows you to make your fork available to others. The developer of the original has a right to decide to accept your changes or not, so I fail to see why it matters that your PR isn't accepted.
Just as I don't understand the original comment, I also don't understand yours
The way Github e.a. use forks dilutes the larger meaning of the word, that's what this thread is about. When people used to talk about forks, they always mean a community fracture over differences of opinion: gcc vs egcs, xfree86 vs xorg, ffmpeg vs libav, openwrt vs lede, glibc vs eglibc, kde4 vs trinity, gnome3 vs cinnamon vs mate.
The common-use term of "fork" on github has nothing to do with divergence of development, it's just a band-aid for lack of contributor access control. I can understand why people don't like github's use of forks, and that has nothing to do with what the license "allows" or not: if it's not a divergent development line, it's not a fork, it's a clone at best. In most cases, I'd say it's just a feature branch hosted in a different repository.
Calling something a fork implies long-term viability (or at least the intention) as an alternative to the original repo. That doesn't sound like a realistic description of most cloned repo's on Github to me.
> The common-use term of "fork" on github [i]s just a band-aid for lack of contributor access control
More accurately: it's a consequence of GitHub's early decision to reject the traditional currency of open source (patches) in favor of imposing dark pattern-infested workflows on hosted projects and their contributors.
When you accept patches, anyone can easily create an account, submit their patch, and then be on their way. GitHub's opting for an unnecessarily heavyweight pull request workflow instead, though, meant that contributors were required to set up a personal on-GitHub copy of the desired repo, point their copy on their local machine at that as a remote, and push to it. At that point, they're already paying the cost of project hosting overheads just for contributing to a project that isn't theirs. When it comes time to start their own project, or evaluate whether it's worth it to continue hosting their existing projects elsewhere, pressure to choose GitHub cones into play that wouldn't otherwise if there were a level playing field. Fast forward nearly 15 years of network effects, and you have it as a nearly unavoidable multi-billion dollar behemoth.
It's such a transparent growth hack inspired by the underhanded tactics used by social networks that folks' unwillingness to even acknowledge its negative impact on productivity and privacy is really infuriating—not to mention the negative impact itself.
> I fail to see why it matters that your PR isn't accepted.
Making their code useful to other people is a strong motivator for many altruistic open source developers.
The purpose of getting PRs accepted upstream is so that your changes are useful in concert with other people's changes, especially their later changes.
Your private change is of little use to others when it's only in your private fork, which hardly anyone knows about, and if they do know, your change is incompatible with later work and maintenance by other people anyway.
If you don't care whether anyone else uses your work, especially in future, that's fine. But if you want it to be more useful to others, getting it merged upstream makes a huge difference to that.
(Merging upstream or just submitting PRs that don't get merged also helps personal visibility and reputation, which is undoubtedly a motivator for many. That's a burden on upstream maintainers when someone is pushing low quality work and doesn't care to ensure it's useful to the project.)
Maintaining a fork and maintaining a single feature of a project are two different levels of commitment and you can want to do one without doing the other although all too often people want to contribute a feature and then not provide support for it and expect the project maintainer to now maintain the contributed code. But that's a different issue (and why many maintainers sometimes don't accept random PR's even if the code itself is fine).
> You don't need to push to the original repo because open source allows you to make your fork available to others.
This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source.
> This is simply not true - not all open source software is copyleft. You can have restrictive licensing regarding use and/or distribution and still be open source.
Well, of course you can adopt any definition of "open source" you want, but I'm using the OSI definition, which states:
"The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software."
You are referring to "source available", for which they offer the clarification:
"Open source doesn't just mean access to the source code."
There is a reason FLOSS exists as a term to differentiate itself from OSS and I think the ideological differences between the two are important. So does Bruce Perens, the co-founder of OSI and the author of the Debian Social Contract of which the OSI definition was based off: https://web.archive.org/web/20140716055445/https://lists.deb...
This was back in 1999 - it's been over 20 years and "OSS" has only been muddied further and further to mean "source available" since.
Pedantry aside tremon's response sums it up well: "Feature branch hosted in a separate repository."
Where is this muddying happening? The only place I've noticed it is on HN, where others always correct the poster by pointing at the Open Source Definition.
Maybe it is time to ditch both "open source" and "free software" and go with something that has a clear meaning that isn't possible to muddy, like "libre software", prefixed with "always" for copyleft licenses and "currently" for permissive ones.
Those who sit on the Open Source side of things constantly muddy the waters and claim they are one in the same. Those who sit on the Free Software side of things are adamant that they are related but different.
> “Free” and “open” are rivals for mindshare. Free software and open source are different ideas but, in most people's way of looking at software, they compete for the same conceptual slot. When people become habituated to saying and thinking “open source,” that is an obstacle to their grasping the free software movement's philosophy and thinking about it.
I meant to ask who is muddying the waters by claiming that "open source" == "source available" rather than the Open Source Definition published by OSI?
Ask anyone who is not already heavily involved in open source software development. They can still be technical users - hell they can even still be programmers - just not already entrenched ones. You're going to have to correct them and go "No I mean this" in the same way that the Free Software movement has to correct people with "Free as in freedom, not as in beer."
See the "Common Misunderstandings of “Free Software” and “Open Source”" section of the article I previously provided. This is a known issue by both OSI and FSF.
Does similar confusion exist when asking people what the Childhood Cancer Data Initiative or Sustainable Energy Initiatives are about? Do you think there is a similar level of misperception among laypersons about the meaning of those initiatives? The common misperception regarding "Free Software" is that people think it means "gratis" rather than "libre". The common misperception with "Open Source" is that people think it means "source-code publicly available". But if the argument about common misperceptions being muddied water is not entirely convincing for you we can take another look at how the terms are defined.
The Free Software Foundation disagrees that "Open Source" and "Free Software" are the same thing. The discussion about whether they are the same thing should end there if we are to accept that the authority defining "Open Source" are correct in their definition of "Open Source". The same credence should be given to the authority defining "Free Software" providing the correct definition of "Free Software". If we are to accept both of these definitions as given by the authorities defining the terms - then they are necessarily different because the authority defining one of the terms says so despite any attempts of another authority who did not define the term at claiming otherwise.
In other words: X defines X and says X = X and X != Y. Y defines Y and says Y = Y and Y = X. Since X defines X and Y does not define X we must accept that X != Y per X's definition of X despite Y's attempt at redefining X such that Y = X.
It's uncharitable to point to OSI's definition of "Open Source" and OSI's claims that they are one and the same while completely ignoring FSF's definition of "Free Software" and FSF's claims that they are different.
> Does similar confusion exist when asking people what the Childhood Cancer Data Initiative or Sustainable Energy Initiatives are about?
No idea about cancer, but even just on HN there is confusion about which meaning of "sustainable" is being used and what environmental and other impacts each energy technology embodies.
> Does similar confusion exist when asking people what the Childhood Cancer Data Initiative or Sustainable Energy Initiatives are about? Do you think there is a similar level of misperception among laypersons about the meaning of those initiatives?
I think most lay persons, upon being informed of the existence of a "Sustainable Energy Initiative", would readily admit when pressed to a lack of sufficient familiarity with the subject that would allow them to answer with confidence about what does or does not meet the standards of being deemed "sustainable energy". Likewise with anything involving "cancer"—most people cannot define it.
But this is beside the point, because we're not talking about the work activity of the OSI. We're taking about the definition of "open source". This is not the first instance of your moving the goalposts in this discussion.
> The common misperception regarding "Free Software" is that people think it means "gratis" rather than "libre". The common misperception with "Open Source" is that people think it means "source-code publicly available".
Right. The key thing being that those are misperceptions.
Misperceptions about the distinction between "cancer" versus "viral infection" versus "bacterial infection" would not lead us to say that because the public does not have a good understanding then the definition of "cancer" changes to something that it isn't.
> if the argument about common misperceptions being muddied water is not entirely convincing
That's not what's at issue.
> The Free Software Foundation disagrees that "Open Source" and "Free Software" are the same thing.
The FSF agrees that the definition of "open source" is the one that was formulated at the end of the last millennium; the FSF doesn't disagree with the OSI about the definition of "open source".
We started with your claim from the ahistorical definition of "open source" that a given project may not actually permit people to make their fork available to others. Any argument you make here needs to support that.
So far, you're making a lot of facile "water _is_ wet*"-style observations and, I dunno, hoping that no one will notice that that was never the point of contention.
* Try substituting "FSF was founded in 1985" (or any other factual statement) here that while true nonetheless has no bearing on the actual substance of the current dispute, despite whatever surface-level relevance it may appear to have to someone who is only halfway paying attention.
I made my point incredibly poorly as I was a bit pressed for time. My bringing up other initiatives misled you as to the point I was poorly trying to make. My point was that laypersons know what the words mean - there is no "aha, it actually means <an entirely unrelated definition of the words used>!" in the words "childhood cancer data". If one knows the words "childhood", "cancer", and "data" they can accurately guess what "childhood cancer data" means and that is not the case for "open source" which has an obvious meaning in plain English which is also not what it means at all.
How people use words matters almost as much as what those words mean - and meaning can change because of how people use words over the course of years, decades, or centuries. Pointing at a dictionary is only useful when clarifying which meaning is being used.
> That's not what's at issue.
Then what is the issue, if you don't mind me asking? The issue as I understand it was what was meant by "open source" and my not already prescribing to the OSI's definition of it. Pointing to the OSI's definition cleared the air about which definition was being used but did not resolve the issue that the phrasing is easily misunderstood outside of the OSS community and is the reason the term "FLOSS" exists to circumvent the issue. The fact they had to specify the definition as defined by OSI and not "source available" is part of the issue. That this misperception exists at all is part of the issue. That the OSI has had to plea with people to please use the branding how they want it to be used [0] is part of the issue. That it is not totally uncommon to see "open source" to only mean "source available" is part of the issue. That "open source" has an obvious plain-English meaning separate from it's "intended meaning" is part of the issue. This is an issue that has existed in the community for the entirety of its 23 years of existence, been spoken about at length by both the OSI and FSF as being an issue, and some people are acting like it's the first time they've ever heard about this being an issue or even denying that it is an existing issue at all.
I'm not sure how many articles from community leaders and the very people who defined the words in the first place speaking about the issue being an issue I need to cite before people go "OK maybe it is an existing issue and not just Nadya saying it's an existing issue when it isn't."
To actually and intentionally move the goalposts this time: It still isn't even logically sound that because you're able to fork and send a PR on Github that the project is "open source" to begin with and it especially doesn't follow that the project is compliant with OSI's definition of "open source". Per my understanding of the Github Terms of Service Section D Parts 4-7 the license given to other users only extends so far as to their using Github's functionality (including "forking") - which I'm reading as not providing any license to compile or redistribute modified source code compiled into an executable. Making sending a PR possibly the only reasonable method of ensuring that a fix or feature makes it to end users.
Even worse is that "free software" has a vastly different meaning to a layperson, who probably think mostly gratis before they think libre when they hear "free".
It might be time to start using more descriptive sentences like "source code available under a proprietary license" or "libre software that can be made proprietary" or "software that is perpetually libre" instead of the "Free Software" and "Open Source" terms.
The problem with "free software" definitely exists as well but the intended meaning is still a plain English meaning of the word "free" but not the first one that comes to mind. Making it easier to correct "Free as in freedom, not as in beer." than "Please read the OSI definition of what 'open source' means." or still a bit confusingly "It's actually about the licensing of the source code and not the source code itself."
I agree it is still a problem - which is why "gratis" and "libre" see use to prevent the confusion and why I prefer the term "FLOSS".
> It's actually about the licensing of the source code and not the source code itself.
This is a big misconception. The Open Source Definition requires source code, you can't have an "open source" project that just releases binaries under the BSD license for example. The OSD (and the Debian Free Software Guidelines that the OSD is based on) is about the software and its attributes, including both the source code and the license.
The big misconception you speak of is being that the requirement is met if a <compiled binary> is released under a FOSS license but that isn't at all what I said. I said the licensing of the <source code> - not of any compiled binaries - is what matters. Swapping <source code> for <compiled binary> of course entirely changes the claim being made. The freedoms afforded by FLOSS licenses necessitate the availability of the source code as a pre-requisite to being met. So one does not meet the terms of the license of the source code if users cannot study/modify it and cannot distribute modified versions of it on account of not being able to modify it due to not being able to access it. Access to the source code in FLOSS licenses is intentional but also a side effect of the freedoms already afforded. There is no 5th freedom requiring the source code to be available because it already must be available in order to meet the requirements of freedoms 2 and 4.
But I'm still entirely wrong.
I'm completely and unequivocally wrong due to two other requirements - both of which actually pertain to the source code and not its licensing. There are in fact two requirements placed upon the source code itself to be considered open source under the OSD or even as free software as the FSF defines it. (1) It may not be deliberately obfuscated. Which makes me wonder if programs written to be deliberately obfuscated are technically not allowed to be considered free-libre or open source software? Such as programs written to compete in IOCCC or if the intent here matters and it's more about releasing obfuscated versions of source code that was not already written to be obfuscated and was made obfuscated with the intent being to prevent others from studying/modifying it. That one I think is a bit of a technicality. (2) The other being that the source code, if not released with the program, must be available in a well-publicized manner at no more than a reasonable cost of distribution/reproduction (ie no charging $1,000 for access to the source code to claim it's "technically available").
You are getting close to the complexity of FLOSS, but there is slightly more to it, some further thoughts below.
> freedoms afforded by FLOSS licenses necessitate the availability of the source code
This isn't really true, security researchers, reverse engineers and piracy experts often do the equivalent of the FSF four freedoms without having the source code. Of course not having the source code makes it harder for people without those skills and without the often costly proprietary tools that enable this work.
It is possible as a technically skilled person to write a binary in machine code, without any assembly or "source code" or other primary format. When an FLOSS license is applied to that binary, it should be considered Free Software. An example of this is the hex0 binary of the stage0 project, which is the first piece of code run by the Bootstrappable Builds project, which aims to build an entire Linux distro starting with only the ~512bytes of machine code in hex0 plus all the necessary source code.
> Which makes me wonder if programs written to be deliberately obfuscated are technically not allowed to be considered free-libre or open source software?
Debian definitely rejects such software, I assume the FSF/OSI would too, although they mostly concern themselves with licenses rather than actual software projects. In the past at least 3 times in different FSF/GNU projects, the FSF/GNU project has caused downstream GPL violations due to releases that were missing source code. Even minified JS without the original JS is not considered DFSG-free by Debian, even though it is extremely common these days. Debian applies this rule to all digital files, no matter whether they are programs or fonts or images or videos or other things. Some articles related to this topic:
The main thing about source code is that downstream users be afforded equality of access to a work as the original author of a work. So if you can write an obfuscated program and realistically modify it yourself without hiding the real source code from users, then that is considered fine from the source code point of view. Of course it is a terrible way to write a program and should get modified to de-obfuscate everything, so more people can understand the code.
The post you cite by Perens doesn't seem to mention the term "FLOSS" (or spelled out), right?
I have seen "FLOSS" used as an umbrella term for ALL of it, that is anything that is open source is also "FLOSS". But you are saying it exists to differentiate from "open source"? Huh. Just to muddy the waters yet further.
It doesn't use the term directly, no. Because to hackers, especially back in 1999, Free and Open Source were one in the same. It was just a difference of branding. However Bruce differentiates between "Open Source" and "Free Software" in writing and he only does so because public perception of what "Open Source" actually means had already been muddied in the year since OSI's founding and the freedoms afforded by FLOSS were already being de-emphasized and put on the back burner.
To quote Bruce:
> Most hackers know that Free Software and Open Source are just two words for the same thing. Unfortunately, though, Open Source has de-emphasized the importance of the freedoms involved in Free Software.....
> ......Sadly, as I've tended toward promotion of Free Software rather than Open Source, Eric Raymond seems to be losing his free software focus. The Open Source certification mark has already been abused in ways I find unconscionable and that I will not abide. I fear that the Open Source Initiative is drifting away from the Free Sofware values with which we originally created it.
There would be no need to make any kind of distinction between Free Software and Open Source if Open Source was being perceived as Free Software.
OSI was and always will be a marketing gimmick [0] created to sell the idea of open source to commercially interested parties.
> We realized that the Netscape announcement had created a precious window of time within which we might finally be able to get the corporate world to listen to what we have to teach about the superiority of an open development process. We realized it was time to dump the confrontational attitude that has been associated with `free software' in the past and sell the idea strictly on the same pragmatic, business-case grounds that motivated Netscape. We brainstormed about tactics and a new label. Open source, contributed by Chris Peterson, was the best thing we came up with.
Not to downplay OSI at all. It was extremely important and widely influential in Netscape's journey to becoming Firefox and I'd even argue is still important today. But the issue centered around what "Free" means ("Free" as in freedom - not beer - which is why the term "libre" is often used as well) and that "Free Software" already had a poor reputation in the business world and so it needed to be rebranded. Eric Raymond made it very clear that he places importance on phrasing and branding and attributes the tactics used by OSI to its success and why the Free Software movement failed. [1]
Honestly a comment by Havoc Pennington on that very post, dated Jun 28, 1999, sums up the issue perfectly.
>I think Eric's analysis of the facts is basically right. i.e. the "open source as business" stuff has gotten us a lot of popularity. The danger is that we fall for our own marketing program. That is, new community members join, and we have to say "we didn't really mean that. Really we meant freedom. The business stuff is for the suits." An increasing number of new members just don't understand freedom, or copyright, or anything like that; they joined "Linux," not "GNU."
Y'all are talking about possibly three different things.
"Source available" does not mean anything about a license at all. It literally just means the source is available... to someone.
Open source generally means it must have a license that allows modifications and derived works. It is more than "source available" it means that a public license to use and redistribute the software is available. "source available" does not necessarily mean you have a free license to use or distribute the software, or modify it and distribute the modifications. "open source" does. The Open Source Institute has tried to standardize a definition. https://opensource.org/osd
"copyleft" is sometimes used to mean something more than some "open source". Richard Stallman has promoted these sense of "copyleft". Like GNU license as opposed to apache. Both are open source -- nobody says apache license isn't open source right? Open source licenses that aren't "copyleft" are sometimes called "permissive". Here's one description of it that will suffice:
> 3. Is the Apache considered copyleft?
> Copyleft licenses require the derivative works or modified versions of existing software to be released under the same license. The Apache License doesn’t have any such requirements. It’s a permissive license. It permits you to release the modified parts of the code under any license of your choice. However, you are required to release all the unmodified parts of the software under the same license (the Apache License).
So, no, "source available" is definitely not the same thing as "open source" -- all open source may be "source available", but things described as just "source available" usually are not open source. The source might be available to you, but you might not be allowed to use it (at all, or in certain ways) without paying, and you might not be allowed to redistribute derived works.
And "copyleft" is usually used as a subset of "open source", for restrictive/"viral" licenses.
I have no idea what any of this has to do with where this discussion began -- but yes, anything that's open source, copyleft or not, gives you the right to make a variaton of the software, use that variation, and distribute it. I think that is part of the accepted definition of open source. "Source available" software may not give you this right.
