Slashdot Mirror
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?"
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.
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.
What I'm listening to now on Pandora...
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
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...
My other car is first.
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)
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
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.
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
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.
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.
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.
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.
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.
docs.linux.org.ua
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.
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.
Never Submit.
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!