Open Sourcing with (Imperfect) Revision History?

AArnott asks: "My company is open-sourcing a private project that has been in development for 4 years. It's history is all in our internal Subversion server. The history of the project includes dependencies on source code that we are not open-sourcing. Should we just publish the latest version (now that we've removed the dependencies) and leave out the old history? Or should we publish the history, even though no previous revision will build, due to the dependencies that we are not including?"

Publish the current version

[str8edge]

Why bother deaing with old or historical releases? Unless there is functionality or features lost in the current release that someone could resurrect by going through the historical code, there really wouldn't be any advantage.

Learning utility

[hackwrench]

When learning about certain code bases, I find it extremely valuable to start with whatever beginning code there is because it illustrates the core concepts while not being a thicket of code. It also helps to see what design decisions were made and then rescinded.

Re:Learning utility

[dubl-u]

When learning about certain code bases, I find it extremely valuable to start with whatever beginning code there is because it illustrates the core concepts while not being a thicket of code. It also helps to see what design decisions were made and then rescinded.

Agreed! Being able to get an annotated view [cenqua.com] helps me a lot when I'm coming to grips with a code base. It doesn't matter if the old versions build; the history is very valuable in its own right.

Re:WTF?

[Imperialist]

>>This has to be one of the dumbest Ask Slashdots ever posted.

When someone ask the community a question in earnest, especially one which has its interests in mind, is it necessary to belittle the question? This is a longstanding and, ipso facto, disturbing trend amongst Slashdotters. So, why can't we all just get along?

btw, due to the nature of this post, and the prevaling culture here at Slashdot, I can forsee myself as the target of much flaming/dissin'/general discourtesy/etc as a result. Just

No good deed...

[Otter]

The only thing releasing the full Subversion history is going to get you is complaints from idiots that you're violating the GPL by not open-sourcing the dependencies. I applaud your concern for thorughness but just go with the current version.

Re:No good deed...

[penguinboy]

There should be no GPL issue. What the GPL requires is distribution of source (or at least making it available) when you distribute binaries. If they aren't distributing GPL'ed binaries of the old versions, I can't see why there would be any GPL issue.

Re:No good deed...

[Otter]

Of course there's no genuine GPL violation there. But most of the "___ Is Violating Teh GPL!!!" stories we get around here don't involve genuine violations, just failure to comply to the widespread misunderstandings of what the license requires. That's why I specified idiots as the complainants.

Start fresh from the latest version.

[rossifer]

Just start a new public repository with the latest good version. Keep the history, but don't worry too much about making sure that everyone has access. Long term storage is fine.

CM systems improve communication between developers by allowing them to synchronize their work as well as preventing simple developer mistakes from turning into massive code rewrites (but you don't need more than two weeks of history to accomplish these goals). The reasons you usually carry around all of the extra baggage of the old versions is for (1) establishment of legal ownership (copyright information) (2) simultaneous maintenance of multiple versions in the field and (3) to show some history of how you got to where you are.

Legal ownership is important, but you get that by keeping a few backups in your long-term storage. You don't have versions in the field (not of the open-sourced version anyway) so that's a moot point. The "how we got here" argument is also of minimal value as long as someone who knows the code is still around. The knowledge of how things were developed in a decent developer's head will be much easier to use than attempting software archeology on a stale file repository.

Regards,
Ross

Re:Start fresh from the latest version.

[Miffe]

I agree, keep the history.

It will show the world that you have changed your project for the better.

Re:Start fresh from the latest version.

[Grab]

Did you even *read* the parent post? If you did, you might have found they said *not* to keep the history...

Shame I don't have modpoints for "-1, can't be arsed to read other people's posts so we shouldn't have to read yours".

Re:Start fresh from the latest version.

[jilles]

A fourth important reason is being able to figure out who chnnged what when and why, sometimes years after the fact. This is something subversion allows you to do easily and it can be really valuable information when debugging some stuff written years ago. Subversion makes this very easy.

Re:Start fresh from the latest version.

[barzok]

Or for auditing Sarbanes-Oxley. I have to be able to reconcile every change made to my system. Yes, we keep a paper trail, but being able to go back to the code and point at the exact change, exact date & time and who committed it for the auditors is a big deal. And a lot easier than sifting through binder upon binder of paper.

Publish the history

[jrockway]

I say publish the history. The worst case scenario is that it's not useful to anyone. If that's true, there's no loss on your part. The advantage of providing the history is that if there was, say, a bug in your dependency removal, someone can go look at the history and fix the bug. When you're fixing bugs, extra information never hurts...

Re:Publish the history

[Thalagyrt]

But then, as a previous poster mentions, if he releases it under GPL there will be issues with his open sourcing the project but not all of the dependencies as required by the GPL. While it would be good for bug fixing, the only way I see possible to open source the history would be under a custom license, or a BSD/MIT license, which wouldn't be good for him and his company. Just my two cents.

GPL requirements?

[hackwrench]

It was my understanding that code could be open sourced under the GPL without the dependencies being open sourced, but if one or more dependencies are open sourced under the GPL then the project has to be open sourced

Dependencies are irrelevant.

[dhasenan]

No, if the package has dependencies that *are* GPL, you still don't have to release your package under the GPL.

Take Crossover Office, for example. It depends on the Linux kernel, X, libstdc/libstdc++, and almost certainly glibc. Each of those are GPL. But Crossover Office is released under a commercial license.

Dependencies are irrelevant to the GPL; it's a matter of being a derivative work. If a GPL library offers certain functions, my code doesn't incorporate the body of those functions if I use that libra

Re:Dependencies are irrelevant.

[vanye]

What the hell are you smoking ?

If the package depends on (links against) things that are GPL, the package must be released under a GPL compatable license.

To fix your example.

Crossover Office is commercial, it depends on

The linux kernel - this is GPL, but the GPL requiremnt doesn't apply to things that interact with the kernel using normal system calls.

X - is not GPL, its licensed under the X license , a modified BSD license.

libstdc - is LGPL, you can link commerc

Re:Publish the history

[Ithika]

if he releases it under GPL there will be issues with his open sourcing the project but not all of the dependencies as required by the GPL.

But he's not omitting to release all of the dependencies --- the OP explicitly says that there are no (external) dependencies. There were, in the past, but not any longer. It's the current version that is being released under GPL, not something that it grew out of four years ago.

The previous version was under a different licence (or maybe none at all, if it never

If no ones seen it before

[JoeCommodore]

If no ones seen it before what use is the history? It might be interesting to review the pre release development cycle but to the intial user it's not going to matter.

The only use it might be is to illustrate the evolution of the code from using one method to another and the reasons for such changes (to lay to rest anyone proposing a former method).

Your audience isn't starting at vers. 5.5 but at the intial version (in thier perspective)

value of information is always positive

[drDugan]

it took me a long time to come around to this view -- but the value of information is always positive. storing and managing it might be costly or take time, but all information, by itself, always has positive value. I argued with my decision analysis prof in grad school a whole semester on this point and after losing miserably I finally came around.

so... realease as much as you can.

Dont split the history

[mrderm]

Ignoring whether the old history will be useful to anyone outside your organisation, it is more useful to you if it is all stored in one place. 'svn blame' works, and it is one less thing to explain to new engineers who join your organisation.

I went through this with my current company a few years ago, and we decided to publish only the current revision. I wish we hadnt.

More information can't hurt...

[vistic]

Well more information can't hurt... I don't know how necessary it will be... but as a reference at least it would be there when/if needed.

Bugs may bite sometimes

[jafd]

Think about another thing. Geniuses are extremely rare these days, and I have doubts that there is absolutely nothing in the code left "for historical reasons", or as a drop-in replacement for code you do not wish to go open source. The history would at least explain the things if one runs into a bug because of this replacement; moreover, there are chances that such kluges will be improved, if one knows what they are for.