I am working on several projects monitoring recent uploads PyPI, RubyGems, and CPAN and analyzing them.
One of the most basic items I am looking for is a link to their public VCS on GitHub, GitLab, or elsewhere.
It turns out that a large percentage of them do NOT link to their public VCS.
When I have time I try to track down the repository and either open an issue or send a Pull-Request to change the meta-data of the project to include the link.
Sometimes I even send an e-mail to the authors asking if they have public VCS.
Some tell me they either don't have a public VCS (or no VCS at all). For some I find out that the repository is not up-to-date. eg. in this project I was told the project is internal to some organization.
Are they Open Source?
I wonder, are such project still open source? They might have an OSI approved license, but can someone really access the source code and make changes to the project in a reasonable way?
See point 2. in the Open Source definition
Strictly speaking there is no requirement to have a public VCS, but there is a requirement to have easy access to the source code and to make it possible to change the source code. Do these distribute packages satisfy this requirement?
Top comments (10)
I recall the projects we interviewed (for FLOSS Weekly) over the years. Some claimed open source, when they merely published the source code of each stable release. Others had a public VCS, but a private issue tracking system. Some (like Dart and Flutter) were extremely public, with design docs, issue trackers, and accepted pull requests. I'd say there's a sliding scale there.
Just to riff a little on Randal's "sliding scale" - here's a set of four type ideas that start from the original Free Software conception and progress through to the more contemporary norm.
Really not sure what would make good pithy terms for ThingA and ThingB. Prior language has beaten us to some of the options - e.g. "Source Available" which has often been used for non FOSS software.
Maybe we can make them more unique by putting "code" in there:
I am course, leaving out other possible subtleties - things like issue tracking - in part because that then begs questions about whether that is also on an Open Source basis. For example, does hosting on a proprietary platform like GitHub invalidate its custom aspects as being "open"?
For me, private issue tracking, where commit messages reference a JIRA number on github really means the project is not open source in the truer sense of the term.
Certainly the spirit of FOSS licensing is that for any "distribution" of the software then the source code must be made available to that recipient. But no FOSS license that I'm aware of has ever required that the source code be public.
Quite how explicit licenses are about that requirement varies, although regardless of the mechanisms, access to the source code is implicit in the four freedoms (which covers both the Free Software and Open Source definitions) .
In theory that means there is a path of legality (enforced by copyright law) for a recipient to demand access to (i.e. a copy of) the source code. But like all such things, legality and practicality are not identical.
In this context, to my mind, this begs the question of when "distribution" is happening and exactly who is being obligated.
The original conception seems to have been applying between producer and customer in direct exchanges. Clearly the four freedoms empower a recipient, who has received the source code, to then re-distribute the software to someone else, who can then make the same demand for the source code. But what if the middle party didn't ever get the source code? While their ability to pass on the software sans source code is clearly granted, is it not clear who then carries a requirement to supply the source code. Is the original producer in a position to refuse to supply source code to this extra recipient - on the basis that this was not someone they had distributed it to? We're in IANAL territory there.
So here is the crux of the matter. Is a producer, who puts the software on a publicly accessible web site, inherently making a distribution to any party that then downloads it? Does it matter if the web site is their own, versus uploading to somewhere more generic (such that this then become the middle party)?
Oddly enough, a good example of this comes from the behaviour of proprietary software, where it is quite common for vendors to make a copy of the software available on request, thereby establishing a direct exchange between vendor and client. Of course, there's usually no FOSS licensing in that scenario but if it was there, then it would be meaningful for the distribution to be direct even if it was so automated that it worked for any applying client. And thus the producer would seem to only be liable to provide source code to those clients to whom it had "distributed" the software. I feel sure I have seen some cases like this over the years - but can't recall any specifically just now.
Of course, in practical terms Gabor is probably right. A producer who is making it too onerous to get the source code is probably avoiding the spirit of Open Source, so their behaviour is likely a better guide than their strict legal obligation.
In a way it's interesting to cast back to the early days of "shareware", which was nearly all about proprietary software but unrestricted/public distribution.
The merging of FOSS licenses and public distribution created a world that muddies the meaning of "distribution". Of course, a later still arrangement is where the source code itself becomes publicly available - to the extent that by now that is considered normal by most (and that some people mistake as being what "open" really means).
Personally, I tend to view this from the other angle, that Open Source provides ways for producers to show how much and how well they can be trusted. That some don't choose to go very far that way is itself an exposure of their intentions.
Open Source is Open Source. If the source distribution is on PyPI and has an OS license, technically it's Open Source by the Open Source Definition opensource.org/osd/
Similarly, companies have started spearheading "Source Available" licenses - namely: the code is online, the development is open, but there are some restrictions on what you can do with it that fall outside the OSD. This is not Open Source, and it's fine! OS is a licensing term, it's not necessarily the gold standard of how software should be developed and distributed in our modern world.
Now, I also love when projects link back to their VCS, have discussions in the open, and have a public governance. But we have to start using new terms for these concepts - otherwise, the term "Open Source" gets diluted and folks will want to slap it on everything.
Some terminology that has been proposed over the years:
More ideas?
I think you can upload to PyPI packages that only contain the pyc files from
__pycache__. As far as I understand, at best, that would count as an obfuscated version of the source that does not fulfill the requirement of providing the source code.Yep, completely agree. Uploading an sdist with only .pyc would not qualify, I'd say.
The question is, do the packages distributed via the various 3rd-party registries properly satisfy the view and modify part of the definition?
Interesting point, certainly find truth in the post.
I'm happy when Gabor posts. Thanks for the read.
This is not low quality, unlike the AI generated response from Flo the factchecker...
Original open source project sometime has an address(a physical address) for you to send 5 floppy disk 💾 and get back the source code on them. So clearly a vcs is not required, but the source has to be made available in some way upon request.
There is also, I believe, a small exception when you are the original author, you can provide and change your licensing however you want. If you're not using a library that require you to provide your source (gpl) that's still allowed (again imo).
But for your original question, is that open source? clearly if the source aren't available, it is not.