Skribent: Simon Hobson Dato: Til: dng Emne: Re: [DNG] vdev - udev is a dead end
Nate Bargmann <n0nb@???> wrote:
> Second, clone that repository locally (dead easy with Git).
Which is what I was thinking ...
In an almost exact parallel, at a previous employer they used a business system which was effectively bespoke and written in Cobol. The history was that it had been written in-house at some large company for their own use, and the devs recognised that it had wider application and got permission to sell it to others. So they spun off a company selling and supporting this system - each installation customised.
It was before my time there (or at least, before I was involved in that side of things), but there was some politics and one of the devs tipped off the customer (my employer) to make a backup of a load of source files on the system - and sure enough, over the next few days/weeks the sources all disappeared off our in-house server ... I think the outfit doing support had got into trouble and were planning to hike support fees, eventually they folded and the dev that tipped us off came and worked for us for a while - we were the only ones left using it. After she left, we then had a handful of freelance contractors look after it - finding all sorts of "hidden gems"* buried in the code.
A couple of years later we'd switched to an off the shelf system which was much more capable !
* As the system didn't have support for various stuff, there were all sorts of hacks. One I recall hearing about was a bit of code that basically said "if customer code = some_constant then apply 10% discount".
Rick Moen <rick@???> wrote:
> As has been noted by others, to preserve the ability to fork from other
> versions, wide distribution and mirroring of a codebase's past releases
> (and/or changesets) is necessary.
>
> I'd like to tell a story about how the world got Portable OpenSSH and
> other completely open source implementations of the secsh protocols.
Thanks, that makes sense and is quite interesting.
> To sum, there are things to beware of and watch for. Any important
> open source codebase needs to have a significant number of years of its
> version history widely mirrored, and at least _some_ of the mirrors need
> to be entirely untouchable by the maintainers.
>
> Any sudden mysterious code disappearances / unavailability, any
> mysteriously requested assignments of copyright ownership (_especially_
> if they're deceptively called 'Contributor License Agreements' -- and
> I'm looking at you, Canonical, Ltd.), or anything even remotely like
> that should raise immediate red flags and get people independently
> mirroring everything and preparing to fork if necessary.
Indeed. If you have the source then they can't stop you forking the (GPL) project.
There was one other thing that came to mind earlier ...
If ${company} decided to do that, and they had previously distributed binaries ... doesn't the GPL mean they are required to provide the sources to anyone they've distributed the binaries to ? So removing the sources from public repositories would actually be a breach of the GPL (given some limitations regarding timing).
And that raises an interesting problem for other people distributing binaries. If (say) I were distributing binaries for ${foo} and relying on (say) a git repository for providing the source - where would that leave me if those git sources suddenly disappear ?
Certainly something for anyone building systems to bear in mind. I know lots of people who take the attitude - don't keep it, you can download it again.