Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Assume I own some open source project with no license information. Furthermore, assume nobody has contributed publicly yet and so I own the project's source code and copyright.
Say the source code is already hosted online. If I decide to give it an open source license by uploading the associated COPYING document to the repository and adjusting the source files accordingly, will the previous versions of the project become licensed as well? Or will the current and future versions be protected while previous versions fall under public domain?
Alternatively, say I start a new project using a DVCS (e.g. Mercurial) on my local machine. I commit all my changes (locally) and then add license information in a later changeset. If I were to host the project/repository, will the entire history be licensed or only the versions following that changeset?
In (2), the project is initially not hosted so this does not seem like a problem. But once it's uploaded, some of the project's history will not include the license information, making the result look almost exactly like (1).
I ask because Google Code allows you to select a license on a new project, even if you intend to import the repository afterward, making licensing seem somewhat external to the actual source code, whereas bitbucket.org does not.
If you want the license to apply to the whole history, just say so in the license file, something like 'This file was added at revision x, but you may consider that the license applies to all revisions prior to x as well'.
You can view it as the license declaring what it covers... legalbol is code, scoping can be made explicit if you want.
As long as you're not using any GPL libraries then what you do with your code is up to you. You can say that you code is retroactively GPL or you can say what version is GPL and what version is BSD and what version is Apache license. You can even offer dual license: use GPL or pay me $100 to use BSD (kind of like what the Qt guys did before they decided to offer LGPL).
Now, if you are using a GPL licensed library then your code is already GPL.
I'm not a lawyer but as far as I know code or any form of content being plainly on the web doesn't really make it public domain.
Regarding the timing of your license: If you attach a license to your code in revision 100, this should only affect revision 100 and future changesets until you change that license again. Otherwise you could, for example, revert code from being opensource afterwards.
From my understanding the license that you get when checking out some code (with a given revision) is the license applicable to that revision of the project. IMO this is also what makes forks from projects possible that went from some OSI-license to a closed one using the opensource code.
Consequently, you should probably create a new repo with the license information in place before putting it online.
Why do you want to expose the source history? The easiest solution to your scenario is to simply copy your code and create a brand new repository, then post this new repository somewhere, along with an open source license. Pull the source that is currently hanging out online without a license, and you're golden. The old source and the new source are completely separate and there shouldn't be any problems. If someone has a copy of the old source, you probably can't do anything to stop them from doing whatever they want with it, but you've got a clean slate for everything going forward. Anything pulled from your new repo (the one with the license) will be covered by that license.
I'm assuming that you are the author of the source that is currently hosted online. If you're not, then you've got other issues to contend with, namely, whether or not you have the right to specify a license for someone else's source code - probably not.
If you use LGPL (or Apache or Berkeley-Licensed) code you're better off then using GPL code which requires that all code which is written based on this code has to be published as open source.
See http://www.google.com/help/faq_codesearch.html#license, but you may get better information regarding Google code from this source.
Related
I built a library for manage library Arduino and it is now published.
https://github.com/ArsaLearn/Arsa-Main
And now I want to add the next version of my library, but when I add the new tag, it brings me the files of the previous version again...
Just summing things up.
You updated library.properties just fine, but there haven't been any other commits (apart from two test files) to your software since release 1.0.0.
You need to commit the changes you made in your software at home, especially the new files in the src directory, to Github before making a new release. You can't do that by just sending a new RAR-file; it will be ignored by the Arduino Library Manager.
How to commit changes, or sending updated source files, to Github is basic Git functionality and easily googled, and a useful skill to have. Maybe somebody feels like explaining how to do it in another answer; then again, maybe not.
If you somehow can't figure it out for yourself, the question you should be asking is "How to commit changes in my software to Github before making a new release".
I am researching development in VisualFiles.
How can I use version control on the files(scripts) I have changed?
My solution so far:
Setup:
Create a folder structure within the repository according to my applications.
Update process
I will modify a file in visual files
I will then manually have to update file in a repository
Commit the changes against a work item
Is there a better way of introducing version control for VisualFiles. Because to me this feels like not an ideal solution
Thats pretty much the only solution at the moment. The team I am in does something similar but only really for major versions, in minor changes we will feature-switch within the code and leave the old edits inline with dates and initials
The platform provider (LexisNexis) have determined changess to code editor functionality as "likely to implement". This may or may not include version control, that is not yet known, if it does it will be in released v4.1+. There are no other tools available to achieve your aim within the platform. Ask your account manager for access to the ideas portal and you can see when their dev team commit to enhancements such as this.
As source/version control is a long standing issue, any devs using the platform have always had to find workarounds as per your suggestion. The providers are highly unlikely to push any version control functionality with backwards compatability pre v4.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Before you start admonishing me with "DON'T DO IT," "BAD PRACTICE!" and "Learn to use proper source code control", please hear me out first. I am fully aware that the practice of commenting out old code and leaving it there forever is very bad and I hate such practice myself.
But here's the situation I'm in. A few months ago I joined a company as software developer. I had worked in the company for few months as an intern, about a year before joining recently. Our company uses source code version control (CVS) but not properly.
Here's what happened both in my internship and my current permanent position. Each time I was assigned to work on a project (legacy, about 8-10 years old). Instead of creating a CVS account and letting me check out code and check in changes, a senior colleague exported the code from CVS, zipped it up and passed it to me.
While this colleague checks in all changes in bulk every few weeks, our usual practice is to do fine-grained versioning in the actual source code itself (each file increments in versions independent from the rest). Whenever a change is made to a file, old code is commented out, new code entered below it, and this whole section is marked with a version number. A note about the changes is placed at the top of the file in a section called Modification History. Finally the changed files are placed in a shared folder, ready and waiting for the bulk check-in.
/*
* Copyright notice blah blah
* Some details about file (project name, file name etc)
* Modification History:
* Date Version Modified By Description
* 2012-10-15 1.0 Joey Initial creation
* 2012-10-22 1.1 Chandler Replaced old code with new code
*/
code ....
//v1.1 start
//old code
new code
//v1.1 end
code ....
Now the problem is this. In the project I'm working on, I needed to copy some new source code files from another project (new in the sense that they didn't exist in destination project before). These files have a lot of historical commented out code and comment-based versioning including usually long or very long Modification History section.
Since the files are new to this project I decided to clean them up and remove unnecessary code including historical code, and start fresh at version 1.0. (I still have to continue the practice of comment-based versioning despite hating it. And don't ask why not start at version 0.1...) I have done similar something during my internship and no one said anything. My supervisor has seen the work a few times and didn't say I shouldn't do such clean-up (if at all it was noticed).
But a same-level colleague saw this and said it's not recommended as it may cause downtime in the future and increase maintenance costs. An example is when changes are made in another project on the original files and these changes need to be propagated to this project. With code files drastically different, it could cause confusion to another developer doing the propagation. It makes sense to me, and is a valid point. I couldn't find any reason to do my clean-up other than the inconvenience of a ridiculously messy code.
So, long story short: Given the practice in our company, should I not do such clean-up when copying new files from project to project? Is it better to make changes on the (copy of) original code with full history in comments? Or what justification can I give for doing the clean-up?
PS to mods: Hope you allow this question some time even if for any reason you determine it to be unfit in SO. I apologize in advance if anything is inappropriate including tags.
If copy of some file from another project really means (for this sources) "The point of divergence" and parallel independent evolution of source and fork, than legacy history and commented code are effectively "white noise" and can be easy eliminated on your side. For future possible propagation from parent mentioning of "bifurcation point" only will be sufficient in first line of Modification History, smth. like
...
* Date Version Modified By Description
* 2012-10-25 1.0 ADTC Created from 12.34 of <filename>
...
Addendum by asker (ADTC):
I wish to quote a comment in addition to the answer above.
[...] take the source code, remove the comments related to who did what (history comments), but retain the comment regarding what the source code/class/method does (informational comments). That is what the comment section is supposed to be. It should clearly define what the method is doing, how it is implemented and under what condition an exception will be thrown. – Wins, 2012-10-25 00:57:57Z
If I am I going your position, I'd prefer to modify the other source code and make it as library to be used within my project.
I suggest using some version control yourself - I recommend git. Have one branch for "upstream" code that is synchronized with whatever you senior colleague currently has. Then you can have one or more branches for your work. You will have good overview what changes you made using git diff against "upstream" branch, you can search history of everything you ever did on that project etc. And this all is automatic, without manual code versioning, the files are always "clean", with all their history available in git.
I've seen it everywhere. In documentation, web sites, help screens, you name it.
Why?
Should I use it too?
How?
The tag is probably from CVS and represents the version of that file in CVS. The developer inserts $Revision$ in his code. When it's committed, CVS expands this to $Revision: 1.2.3$. In my opinion, you definitely shouldn't use it or its friends (such as $Id$), at least in normal source code.
If you have a more modern source control system (SVN, Mercurial, git, monotone) which has a single version number for the whole tree, then keeping a file somewhere in your build that contains that number isn't a bad thing - it lets you do things such as in the bottom right of this page, where right now it says "svn revision: 3772".
But if you have something like CVS, where each file has its own separate version numbers, you end up with $Revision$ (or $Id$ or whatever) in each file. Over time, this causes confusion (people quoting version numbers that only refer to one file, for example) and leads to merge errors where there might otherwise have been a clean merge (remote version has a different version of that line than your local version, merger trips up).
Plus, anything programmatically and automatically changing your source code should be viewed with suspicion.
That is probably an expanded version of '$Id$', which I think has its origins with the RCS version control system, and has been inherited or implemented in many others, not least CVS and SVN.
Basically, you stick '$Id$' into your source code somewhere, and the version control system expands it to an identity string containing the current revision on every checkout.
Then, when looking at source code you can remind yourself which revision or branch the source code has come from.
Personally I do not find it that useful.
Here is the CVS documentation for keyword substitution: http://ximbiot.com/cvs/manual/cvs-1.11.6/cvs_12.html
Note that $Id$ is one of many such strings that can be used.
Why?
It's an attempt to answer the question "Which version of the source code matches the binaries shipped to a customer?" How it works others have commented on.
Should I use it too?
How?
Do you need it? How often have you or your developers asked that question? How often have you had difficulty answering it? If you already have tags/branches like release-1.0, release-1.1 etc., then you most likely don't need it.
I've never really worked with a lot of people where we had to check out code and have repositories of old code, etc. I'm not sure I even know what these terms mean. If I want to to start a new project that involves more than myself that tracks all the code changes, does "check out" (again, don't know what that means), how do I get started? Is that what SVN is for? Something else? Do I download a program that keeps up with the code?
What do I do?
It will all be in house. No Internet for storing code.
I don't even know if what I am asking for is called source control. I see things about checking out, SVN, source control, and so on. I don't know if it is all talking about the same thing or not. I was hoping to use something open source.
So, a long time ago, in the bad old days of yore, source control used a library metaphor. If you wanted to edit a file, the only way to avoid conflicts was to make sure that you were the ONLY one editing the file. What you'd do is ask the source control system to "check out" that file, indicating that you were editing it and nobody else was allowed to edit it until you made your changes and the file was "checked in". If you needed to make a change to a checked out file, you had to go find that freakin' developer who'd had everythingImportant.conf checked out since last Tuesday..freakin' Bill...
Anyway, source control doesn't really work like that anymore, but the language stuck with us. Nowadays, "checking out" code means downloading a copy of the code from the code repository. The files will appear in a local directory, allowing you to use them, compile the code, and even make changes to the source that you could perhaps upload back to the repository later, should you need to. Even better, with just a single command, you can get all the changes that have been made by other developers since the last time you downloaded the code. Good stuff.
There are several major source control libraries, of which SVN (also called Subversion) is one (CVS, Git, HG, Perforce, ClearCase, etc are others). I recommend starting with SVN, Git, or HG, since they're all free and all have excellent documentation.
You might want to start using source control even if you're the only developer. There's nothing worse than realizing that last night the thousand lines of code you deleted as useless were actually critically important and are now lost forever. Source control allows you to zoom forwards and backwards in the history of your files, letting you easily recover stuff that you should not have removed, and giving you a lot more confidence about deleting useless stuff. Plus, fiddling around with it on your own is good practice.
Being comfortable with source/revision control software is a critical job skill of any serious software engineer. Mastering it will effectively level you up as a professional developer. Coming onto a project and finding that the team keeps all their source in a folder somewhere is an awful experience. Good luck! You're already on the right path just by being interested!
Check out Eric Sink's excellent series of articles:
Source Control HOWTO
I recommend Git and Subversion (SVN) both as free, open-source version control systems that work very well. Git has some nice features given that it can be easier to work decentralized.
Checkout means retrieving a file from a source control system. A source control system is a database (some, like CVS, use just specially marked up text files, but a file system is also a database) that holds all versions of your code (that are checked in after you make modifications).
Microsoft Visual SourceSafe uses a very proprietary database which is prone to corruption if it is not regularly maintained and uses reserved checkouts exclusively. Don't use it, for all those reasons.
The difference between a reserved checkout and an unreserved checkout is in an unreserved checkout; two people can be modifying the same file at once. The first one to check in gets in no problem, and the second one has to update their code to the latest version and merge the changes into theirs (which usually happens automatically, but if the same area of the file was changed, then there is a conflict, which has to be resolved before it can be checked in).
For some arguments for unreserved checkouts, see here.
Following this, you will be looking at a build process that independently checks out the code and builds the source code, so that everyone's changes are built and distributed together.
Are you creating the project that requires source control? If so, choose a source control system that meets your needs, and read the documentation for how to get it set up. If you are simply using a previously set up source control system for an existing project, ask a coworker who has been using it, or ask the person who set up the source control system.
For choosing a source control system that meets your needs, most source control systems have extensive descriptions of their features online, many provide evaluation or even completely free products, and there are many many many anecdotal descriptions of what working with each individual source control system is like, which can help.
Just don't use Microsoft Visual SourceSafe if you value your sanity and your code.