Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Open Sourcing with (Imperfect) Revision History?

Cliff posted more than 8 years ago | from the missing-dependencies-frustrate-compilers dept.

Programming 27

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?"

cancel ×


Sorry! There are no comments related to the filter you selected.

Publish the current version (2, Interesting)

str8edge (34283) | more than 8 years ago | (#14473934)

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 (4, Insightful)

hackwrench (573697) | more than 8 years ago | (#14474316)

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 (1)

dubl-u (51156) | more than 8 years ago | (#14477598)

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 [] 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.

WTF? (-1, Troll)

XBL (305578) | more than 8 years ago | (#14473954)

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

Why release a version of your software's code that is useless to everyone outside of your organization? Just to confuse people who end up downloading your code? Just post the newest code without the dependencies. Duh!

BTW, thanks for making your code open source. I hope the code is a lot better than this question.

Re:WTF? (1)

Imperialist (814663) | more than 8 years ago | (#14479987)

>>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 remember, karma comes back. Tenfold.

Re:WTF? (0)

Anonymous Coward | more than 8 years ago | (#14485497)

Hello TROLL!!! How about piping down and thank the poster that he/her/they are making their software open. STOP harassing people for asking questions - There are no stupid questions... only stupid answers!

No good deed... (4, Insightful)

Otter (3800) | more than 8 years ago | (#14473988)

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... (1)

penguinboy (35085) | more than 8 years ago | (#14479308)

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... (1)

Otter (3800) | more than 8 years ago | (#14481624)

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. (4, Insightful)

rossifer (581396) | more than 8 years ago | (#14474041)

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.


Re:Start fresh from the latest version. (1)

Miffe (592354) | more than 8 years ago | (#14474176)

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. (1)

Grab (126025) | more than 8 years ago | (#14477064)

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. (1)

jilles (20976) | more than 8 years ago | (#14474849)

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. (1)

barzok (26681) | more than 8 years ago | (#14475303)

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 (2, Insightful)

jrockway (229604) | more than 8 years ago | (#14474096)

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 (2, Insightful)

Thalagyrt (851883) | more than 8 years ago | (#14474112)

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? (1)

hackwrench (573697) | more than 8 years ago | (#14474390)

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

Re:GPL requirements? (0)

Anonymous Coward | more than 8 years ago | (#14474633)

It's generally percieved that you an add an "additional freedom" to handle non-GPL dependancies, but then you are actually using a different licence and can't pull in regular GPL code.

Dependencies are irrelevant. (1)

dhasenan (758719) | more than 8 years ago | (#14475960)

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 library; so I can distribute that library under the GPL and distribute my code under whatever license I choose. However, if I copy a portion of that library into my code, I have to GPL my code, provided I distribute it.

Now, if I have a non-GPL dependency for my code, I can still GPL my code. For instance, there are GPL applications for Windows, which is of course closed-source and proprietary.

The logic is this:
My code doesn't include any part of the library, only an interface. If the library's released under the GPL, it doesn't matter unless I distribute it, in which case I need to distribute it under the GPL. If I have an application that uses it, it doesn't include it; the OS does the linking, but the user has to get it under the GPL's terms. All I have is an interface to that library.

On the other hand, if it's a commercial library or dependency, then it's still the user's responsibility to get it and follow the license. If the license forbids using it as a dependency, then it will violate the license to install and use my program. But that's not my responsibility.

It's much easier to segregate particular packages to use the GPL than most people think. And most software corporations try to propagate that myth. This isn't the place to do that.

Still, people would complain about the dependencies not being open sourced if the complete version history was released. I say keep it to yourself.

Re:Dependencies are irrelevant. (1)

vanye (7120) | more than 8 years ago | (#14476779)

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 commercial applications against LGPL libraries.

    glibc - is LGPL.

Now had Crossover Office linked against a GPL library (ie readline) it would have been different,

As in all things on slashdot - the advice here is worth what you pay for it.

Back on topic.

Is the original poster intending to maintain two separate repositories or will all future work be done in the open source version ? This isn't that stupid a question - it all depends on product release mangagement - having two repositories with manual merging allows your product to "lock" its repo during key release phases while still allowing the community to continue working. While extra work - you'll be gald you did it the first time you have to release a product.

So if you only have one repo - include all the history, if you have two repos (open source and product) then I'd only export ther current HEAD revision to the open soruce repo.

Re:Publish the history (2, Informative)

Ithika (703697) | more than 8 years ago | (#14475203)

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 left the company), but licence changes don't act retrospectively.

Releasing the entire history (including the bits that cannot be compiled any longer) is the only right thing to do. Repositories maintain all sorts of useful metadata which should not be discarded just because the revisions they refer to no longer compile.

If no ones seen it before (1)

JoeCommodore (567479) | more than 8 years ago | (#14474172)

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)

leave it out! (0)

Anonymous Coward | more than 8 years ago | (#14474528)

Just start with the first revision that works without the dependencies, copy into a fresh repository, and leave the rest out. In fact, renumber it to version 1.0 while you're at it.

Nobody's going to care what you did before they got their hands on it. It's nice to have the version history and logs for the changes between, e.g., the version I have on my hard drive and the latest release, but I wouldn't really care about what happened in the distant past before I even knew the program existed. Maybe just include the commit logs as a changelog file.

value of information is always positive (2, Insightful)

drDugan (219551) | more than 8 years ago | (#14474818)

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 (3, Interesting)

mrderm (685352) | more than 8 years ago | (#14474948)

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... (1)

vistic (556838) | more than 8 years ago | (#14475135)

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 (2, Insightful)

jafd (944017) | more than 8 years ago | (#14475864)

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.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>