> I don't see an issue with this (am I supposed to? Do we demand everyone use git or similar now?).

That depends on your job. If you are a software developer, -engineer or similar, I would argue that you should. There are good arguments for version control.

- divide & conquer for bugfinding - reconstruction of history - being able to revert back to an older version if/while operations require it - it allows tracking of changes over time - it is the best way of understanding what changed since the last version (for people actually using the library) - finding complex faults - branching and merging (but the author is opposed to this)

So, well, what concerns live555, IMHO it's a huge red flag for people considering to actually use the library. When it comes to "not seeing an issue with not using source control", I believe that one can state without a doubt that it is a good and proven practice.

It's usual to just put stuff like this in your own version control. Each time you get an update, delete old version, copy new version on top, then sort it out. Perforce has a "Reconcile Offline Work" for exactly this sort of situation; with git or svn, a simple commit will probably do exactly the right thing. This doesn't give you full history, but you get enough to revisit and bisect old versions.

(With a touch more work, you can also maintain your own changes, and have them 3-way merged in automatically.)

As for not using source control - if they don't use it internally, that's a bit weird, but maybe there's just one person working on the code, and they take a backup every hour, and they're happy. (It's their time, not mine.) But not exposing their source control to the outside world is absolutely standard. I worked as a programmer for software companies for ten years and never once saw 3rd-party code distributed any way other than zipped up source drops. (And this includes times where we were working with the 3rd party on the same project! - we just did the thing I mentioned at the start when they sent us updates, and they did the same thing at their end. It's much less of a bother than you'd think, though the first couple of merges can be a bit painful.)

If you want to claim they're being unhelpful, the insistence that you upgrade at a moment's notice is much worse. Upgrading 3rd party libraries is one thing you never, ever want to do, unless your hands are absolutely tied!

I don't get where the downvotes came from. All the downvotes in the world can't fix the past, sadly.

Some of the arguments may seem plausible in theory, but as soon as I contemplate doing my 9-to-5 dev work without source control (specifically git)-- yeah, no, not happening.

Obviously source control has its benefits, but ironically often tarball-only developers produce very high quality software (the most prominent example is djb at cr.yp.to).

Conversely, GitHub is full of low quality software.

djb's software is pretty low-quality for very many metrics of "quality". Lots of it is not elegantly interoperable with existing UNIX systems, because he has his own idea of how UNIX systems should work. There's the entire qmail backscatter thing. There are pieces of crypto code written in a custom assembler. Curve25519 has its own reimplementation from Chrome's Adam Langley, and all of NaCl its own repackaging in the form of the libsodium project, because the official distributions are difficult to use. NaCl has been promising certain features in the "next release" for years (notably Ed25519 signatures), but no release has been seen. All the downloads are over plaintext HTTP with no cryptographic signatures: I've always interpreted this as implying that if you're not qualified to audit the entire tarball you downloaded, the software isn't for you.

None of this is to claim that he's a bad cryptographer, or even a bad software engineer. But pure code output is far from the only important metric for software. GitHub makes it easy to do release engineering well, or to let other people help you with that if it's not your forte. (libsodium, for instance, is on GitHub.)

You're cherry picking a few example of tarball only developers and then comparing it to the entirety of github? How is that a fair comparison at all?

Wow, -3 for this horrible comment. HN is full of idiots.

Now go on, make it another -10; it will be the only thing in your day that makes you feel that you have any influence.

The issue isn't that they don't want to have a repository. The issue is that the rationale for not having one is pants on head idiotic.

The LGPL says no such thing about forcing you to distribute updates but the FAQ implies it does. I wonder how this squares with the part of the GPL that says:

>If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.

It seems to me that they don't actually WANT anyone to use it, and definitely not modifying the code... Really makes you wonder why they bothered to make it open source and LGPL licensed

I'd like to think the first part is talking about making extensions to the code, that you should be writing subclasses to add new functionality for your own use, not maintaining a series of patches.

That is, dependency injection for your extensions, not alterations to the core.

The whole project reeks of anachronistic development practices, though.

That's a pretty strained interpretation of "open source" on their part.

The LGPL requires that end users are able to replace LGPL libraries with new builds. The App Store creates a bit of an issue, but it's possible to update app libraries if your phone is jailbroken. You might also be able to modify and re-sign, but I'm not sure.

The LGPL doesn't require the developer to use a new version or provide updates at anyone's request.

Well, what they say:

> If you distribute a product (whether software or hardware; whether free or for pay) that uses the LIVE555 library code, then you must - when requested by either a customer, or Live Networks, Inc. - upgrade it as soon as possible to use the latest version of the LIVE555 library code (or else provide a way for your customers to perform this upgrade themselves).

That's a very strained reading of the LGPL, but the way the LGPL is written, they must provide a way for customers to updgrade the LIVE555 code used to whatever version they want to, including the latest version. It doesn't have to WORK, necessarily, but the ability to replace LGPL code in a work with one's own code is part of the license.

TL;DR: I think they're wrong but not so far wrong as to be crazy, and what they insist on happening is a consequence of following the terms of the LGPL (customers being able to upgrade to the latest version).

Theoretically, could you just say "the newest version of this software is licensed under the LGPL; for any other version, I retain copyright and grant no rights to it, and revoke any rights previously granted."? So it becomes an infringement of their copyright to not be running the newest version, whatever the LGPL says.

The iOS App Store disallows dynamic libraries. Libraries are statically linked into the final executable, so they're not easy to replace.

In that case, the LGPL requires you distribute source or relinkable object files.

I know a lot of folks don't (because i do M&A due diligence), but that's a very clear license violation if you don't.

(also note that IOS 8+ allows dynamic linking, but replacement may still be an issue).

As of iOS 8 you can use dynamic libraries, but the user can't replace them without invalidating the code signature for the app.

Ross may have tacked this on after this exchange with Foscam regarding an IP camera line streaming RTSP with an ancient (and buggy) live555 release:

http://foscam.us/forum/a-reported-problem-with-your-fi9821w-...

The user-replaceable part is standard fare, but I've never heard about the forced upgrading part. That sounds pretty crazy. I guess if you follow the LGPL and allow a user to swap out the library you're covered, since they say "or". Maybe it's "LPGL or release updates until you die"?

> when requested by either a customer, or Live Networks, Inc. - upgrade it as soon as possible to use the latest version of the LIVE555 library code

This is not a requirement of the LGPL, the rest is. A user must be able to replace a LGPL portion of a program. Dynamic linking is the way this is usually accomplished.

the "upgrade it as soon as possible" part is an extra requirement