Hacker News Reader

> Furthermore, dumped-over-the-wall projects like Android would be better referred to as "Shared Source" (with its association) - the Free branches are seemingly unable to actually keep up with the master!

I think I'd called this "spectator source". You can watch for free, but don't expect you'll really get much time on the field.

I think 'source available' is already an established term, i.e. the source is there to view, but that's about it.

> Furthermore, dumped-over-the-wall projects like Android would be better referred to as "Shared Source" (with its association) - the Free branches are seemingly unable to actually keep up with the master!

That's because AOSP by itself is Android without all the integration work that's necessary to make a useful image for a specific device, and traditionally it's been a lot of work for each new version. Things are better in that respect since Android 8.0, which I think shows in frequency of both manufacturer updates and community builds.

Yes, that's the mechanism. The point is that if Android were really Free/OpenSource, that integration work should have gotten pushed back to the main branch and carried into the new version alongside everything. Then that work would be done across the board when making breaking changes to the driver API.

I recognize that the embedded culture of zip+email version control has much to do with this - manufacturers don't care if the starting source was retrieving using git pull or wget. But that's merely an explanation, not a justification.

I don't worry about not being able to install the latest Debian on an older machine, because the drivers for the hardware have been carried forward.

Sure, it’s a way for proprietary software authors to deduplicate efforts and share IP, one they tend to prefer over paying vendors who are trying to extract their own rents, and one they can pull off because they are already competent to write and operate their own software. In an alternative history, the tech community would all be paying small fees to license each other’s patents. What open source is is closer to what the patent system was supposed to be, than some kind of end-user empowerment revolution.

Richard Stallman has considered this issue, alas, with no clear solutions yet - https://www.gnu.org/philosophy/who-does-that-server-really-s...

It sounds similiar to the classic "anarchy trap/paradox". What is there to prevent the establishment of rules without any rules in place? In this case it is "What stops someone from using software freedom to reduce software freedom?"

I doubt there is one aside from social norms that nobody would use such things.

I don't think even AGPL software is safe from the SaaS menace; the tooling around AGPL software can simply refrain from actually linking to it, ie, generate configs and manage the software service doesn't trigger the AGPL, so you never see the code.

I think MongoDB has had trouble with that despite AGPL license, which is why they did the entire SSPL thing.

If all that developers see happening to their free software project is that SaaS corps take it and squeeze it for money without giving back a single cent, people won't license as free software anymore.

Atleast with open source licenses the expectation of that abuse is always somewhat present but people will similarly stop using it if the abuse is too great.

> If all that developers see happening to their free software project is that SaaS corps take it and squeeze it for money without giving back a single cent, people won't license as free software anymore.

> At least with open source licenses the expectation of that abuse is always somewhat present but people will similarly stop using it if the abuse is too great.

You talk about “free software” licenses and “open source licenses” as if they are different things. While the FSF and OSI are different organizations with somewhat different philosophy and strategy, the set of “Free Software” licenses recognized by the former is virtually identical to the set of “Open Source” licenses recognized by the latter.

A good bit of the original article is about the difference.

The article is about the difference in philosophy and strategy between the communities. Which I noted in my comment.

But the set of licenses is essentially identical, the differences being in licenses where only one of the two groups has rendered an opinion, which arguably isn't even a difference other than in degree of certainty.

While both recognize most of the same licenses, "open source" licenses are licenses like APL, MPL, MIT, BSD and friends, licenses which give maximum freedoms, while "free software" licenses like GPL, EUPL and AGPL attempt to maximize user freedoms.

There is a difference between those two and there are definitely communities that prefer one over the other.

I find it silly to yell "but they recognize the same licenses" when that isn't what it's about at all...

There are existing, established terms—used consistently by both the Open Source and Free Software communities—for those different kinds of licenses, and the terms are “permissive” for what you call “open source” and “copyleft” for what you call “free software”.

Under your terminology, the GNU All Permissive License, despite clearly originating in the Free Software community, would be an ”open source” rather than “free software” license.

> There is a difference between those two and there are definitely communities that prefer one over the other.

The FSF, by the actual recommendations it states on its list of licenses, explicitly prefers copyleft licenses for large programs, but considers permissive licenses fine for smaller programs and supporting files (and has specific recommendations as to which permissive licenses should be used.)

The OSI is less prone to state preferences, and it'd be a misnomer to conflate the open source community with people who unconditionally prefer permissive licenses.

Your claim that OSS is effectively proprietary software immediately loses half your audience, because most people in the OSS camp have the opposite experience (that FSF leads to monopolistic SaaS companies spying on you).

I'm not saying either tribe is right, so let's skip past the tribalism.

What we need is not new OSS/FSF, what we need is new economic models that are capable of measuring the value of OSS/FSF.

Here is an extensive treatise to fix all of this: https://hackernoon.com/wealth-a-new-era-of-economics-ce8acd7...

I wasn't saying that OSS is itself equal to proprietary software, but that it often ends up affiliated with non-free products. Products which then shamelessly continue using the OSS image to foster goodwill, even though their end users are far from having Freedom.

> that FSF leads to monopolistic SaaS companies spying on you

Erm, what? Both BSD and GPL software are similarly vulnerable to being transmuted into SaaS.

This isn't an argument about specific licenses per se. What I'm calling out is "openwashing" in general.

The FSF at least has an intellectual framework to analyze this. You don't need to license your work as GPL, but you do need to think ahead about the users of your software. Imagine using a derivative of your own work, suffering an annoying bug that you know precisely what it is, and yet being unable to fix it because a middleman has prevented you from doing so.

Ah, that makes more sense. Good point, thanks!

I think that is a fair concern, but personally I'd much rather give my users unrestricted abilities to use my code, because I believe that any proprietary-tech built on my code will not be able to compete in the end game with any also OSS-tech built on my code. I also see the same that any OSS-version would outcompete (a)GPL-version, though I'm sure you disagree?

Yes, I believe perfectly efficient markets are analogous to P == NP.

> I believe that any proprietary-tech built on my code will not be able to compete in the end game with any also OSS-tech built on my code

I'm worried that you face a forever-uphill climb. Whenever a proprietary group pulls ahead by developing some killer feature or improvement, your OSS group has to duplicate all of their work. Whereas if your OSS group pulls ahead, they can just fork you and put all their energy into pulling ahead again.

I think this analysis is a good argument for why you might want to put restrictions on those who would take advantage of your community's work. (Of course, it's important that the restrictions actually work and aren't burdensome to those who don't want to take advantage of you. Whether the GPL or any other license succeeds at that is debatable.)

When you own the entire vertical, all the way to end user, it makes sense.

In practice, the final steps that are necessary to deliver something useful to the user are often considered the most boring and tedious (UI, documentation etc), so many F/OSS projects either don't bother at all, or provide something half-baked. But if the underlying libraries allow for a proprietary derivative, then that might motivate some businesses to come and do all that tedious stuff for $$$. Such businesses might not contribute back much, but they are also unlikely to fork - less code to maintain that way.

When that happens, I don't think it's a loss for anybody, really. The open code stays open and can be improved further, and it also gets used by more people in better ways. Some would argue that library developers aren't properly compensated, but the act of voluntarily releasing something under a non-copyleft license is explicit consent to that.

In the hypothetical "suffering an annoying bug" scenario, I would, of course, prefer to have the source so that I can fix it. But if the real choice is between having a product with an annoying unfixable bug (but plenty of other added value), and not having one at all, because nobody wants to build my extremely useful GPL'd library into a polished product, the obvious pragmatic choice is the bug.

If you're going to the trouble of building a proprietary derivative, you are going to want to make sure no one but your paying customers can benefit.

Yes, and that is achieved by keeping the part that makes it all sellable to consumers proprietary. But there's not much point in doing that with the backing open source libraries, especially if they're popular and in active development - maintaining a constantly diverging in-house fork is very time-consuming and expensive, so it must have some really big value-add to justify them.

How many closed-source projects use, say, SQLite? How many of them fork it?

How many contribute back to it?

Would we know if they forked it?

This also assumes that the software must constantly evolve and `pull ahead'. In reality, a lot of the software in use usually evolves to a point of being useful and does not need anything but routine incremental adjustments (I did not say improvements because one man's improvement is another man's useless feature), like compilers being retargeted, or typesetting software using new image formats, or a new language.

Software becoming free (as in everything, beer and speech) is a natural progression because our patterns of using software are not that flexible so when a new use case appears, in a few years the free software catches up and it is no longer possible to abuse the customers as before (like Autodesk is doing now), just as it should be. Not that this model is bullet proof, unfortunately.