Related
I recently contributed some code to an open source library/tool just before I realized that I'd like to re-write this project myself (different programming language and design choices). However, some aspects of the project are just like I would have done them myself or are simply worth "copying". Even if I tried really hard to forget about the original code -- most class names, constants and other stuff just are naturally named the same. The original project's license is AGPL.
Can I use a different license (e.g. MIT)? Which ones?
Will I have to mention the original project somewhere?
If so, where? And will I ever be allowed to remove the notice (maybe after the two projects have truly diverged after a few years of development)?
I am not a lawyer and this is probably not the correct venue for soliciting legal advice.
However, this is my take, as one FOSS contributor to another.
Generally speaking when you contribute to open source projects, you retain the copyright over the code that you wrote, and you release it under a license that permits everyone to use modify and distribute it.
Thus, you retain the right to relicense code that you so contributed under MIT or another license. That doesn't count as "stealing" the code and erasing the GPL license -- you were the original source and you retain the right to release what was originally yours again under a different license.
In some projects, the leaders may request that people DO transfer copyright, although its pretty rare I think. You should check the licensing statement to be sure. Unless there is something in writing somewhere saying that you explicitly agree to transfer copyright to them, then most likely you retained it.
You do not have the right to relicense other peoples work though. In cases where you modified someone elses code, contributing some changes to their class or something, you probably become joint owners, and at least I would not feel comfortable copying the part that they made and relicensing it without permission.
That's just the text of the code though. If you want to rewrite another program from scratch, using a similar high level plan but different execution, I don't think copyright will encumber you. Intellectual property law can still encumber you if some technique or method in the code is covered by a software patent. But it doesn't sound like that's the case here.
To avoid legal issues, sometimes companies / groups of people will use "clean room design" (https://en.wikipedia.org/wiki/Clean_room_design). But iiuc this is just done as a precaution to unambiguously head off any possible lawsuit -- the law does not require that you use such techniques just because you once looked at GPL code, iiuc.
For an example of this playing out, you can look at the history of the MinGW cross compiler project, and the mingw-w64 spin-off of it, which originally began because a private company wanted a version of mingw which supported 64-bit processors and other things, and so used clean room design to reverse engineer the project. The result of this was eventually made fully open source, but was not accepted back into the original mingw project and so there are now two projects. (Hope that this is a fair and impartial summary of the history.)
https://en.wikipedia.org/wiki/MinGW#History
Very soon we are going to start on open-source (py+qt) project which is supposed to be multi-platform (we're using FreeBSD as native platform) and we're not sure which DVCS/hosting to use.
In the past we were using darcs for very long time, but moved away from it due to not having adequate public hosting available. Played for some time with Monotone - nicely designed, but mostly niche today. Fossil is nice, but it uses non-standard wiki and its tracker is functional, but we expect more.
Considering that we won't work on kernel-like sized project we do not nee Git which we consider too complex to deal with it, especially for potential contributors which might use Windows OS and prefer GUI tools.
So, the story comes to Bazaar/Launchpad and Mercurial/Bitbucket...
Here are some pro/cons which we gathered together, but would like to hear if we missed something which might help us to decide...
Bazaar pro/cons:
2.4 is probably quick enough for our needs ,
simple to use,
has nice GUI tool (explorer),
handles empty directories,
(probably) less popular than Mercurial,
does not have equivalent of hg's named branches
The last point is probably not to important 'cause there are nicks and there is colo-branches plugin, so one can get same/similar functionality.
The most problematic quirk we find in Bazaar it its revision numbers scheme and problem which can arise if one pushes from feature branch into upstream which would change revids.
Maybe it's a lesser problem when using Launchpad...
As far s Launchpad is concerned:
- it has very nice bug tracker with email interface
- it's (maybe) more project-oriented than Bitbucket
- no private repos as with Bitbucket
- no wiki for projects - bug (https://bugs.launchpad.net/launchpad/+bug/240067) is more than 3 years old and still with 'Low priority'. LP is the only one amongst {LP,Sourceforge,Bitbucket, Google, Github} which lacks this feature and it really sucks and degrades, otherwise, nice hosting solution.
What we've found in The other camp...
Mercurial is:
(probably) more popular than Bazaar,
quick,
simple to use,
there is nice TortoiseHG for non cli-savvy users,
we like named branches,
some quirks like handling empty directories (or https://www.mercurial-scm.org/bts/issue29)
However, what we like the most over Bazaar is, as we believe, great merging capabilities without the hassle of changed revids due to revno:hash schema.
As far as Bitbucket:
we like to have unlimited/private repos
we like having wikis available for the project(s)
we miss email interface for the tracker and the tracker is (maybe) not on par with the one at LP (reviews etc.)
At the end, let's say that there are some projects which we are interested in which are under Git #github, so we would like to use single DVCS which can helps us inter-operate with git#github projects.
We find that bzr-git plugin is very capable and do not have experience with hg-git.
Although there is bzr-hg plugin (not as mature as bzr-git), but we do not know about something like hg-bzr except hg's convert extension which does the job of hg-bzr conversion.
Is there any important feature which we did miss having important consequence in deciding about the two?
Finally, we use DVCS for all our needs (simple project, writings...) and we'd prefer to settle on one DVCS/hosting which can serve all our purposes and be useful in contributing to git(hub) projects as well.
What do you recommend?
In Bazaar:
You can avoid the problem of revision numbers being renumbered by setting append_revisions_only in branch.conf, which will make sure people only merge into trunk, rather than switching the trunk around.
I like bzr-colo a lot for dealing with named colocated branches.
I would certainly like to see Launchpad get wikis. It's assigned and in progress at the moment so perhaps it will get done soon.
Update: Seing this comment makes it easier for us to abandon bzr/LP and embrace hg/bitbucket.
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
My question consists of multiple points that are inherently related, I apologize for that. I tried splitting it up a little more, but I would keep repeating myself.
What exactly is required to apply an open source license to a code base that is my Intellectual Property?
A lot of Open Source projects include a full copy of the license somewhere in a root directory but do also have some sort of file header including a license description, disclaimer and a copyright notice. Is that really necessary or does it depend on the license type?
If someone else contributes changes to this file, does he need to be named in the copyright notice too?
Disclaimer
I am not a lawyer, so you should really consult with one to get absolutely correct answers here.
To the best of my knowledge...
Whenever you author something, whether it be code or anything else, you automatically become the copyright owner of that work (unless you've signed an agreement whereby it is "work for hire").
As the copyright owner, you can apply whatever license you like. The fact is that, if you don't give out a license, then no one has any right to use, copy, modify, distribute, etc. your coyrighted work. So, users need your license to have permission to use the project (if you don't give a license, it cannot, contrary to popular belief, be presumed public domain). So, you don't need to worry about people ignoring the license... if they can't point to a license where you grant them rights to use your software, as the copyright owner, you can sue them for using your copyrighted work without your express permission to do so.
It is typical in open source projects to place the license in a file named "LICENSE" or "COPYING" in the top-level directory of the project. I suggest that you stick to this convention, since that is where people will look for the license. It is also good to indicate what the license is on the project's website, so that people don't have to download your whole project before they know what the license agreement is.
It is not necessary to include a full copy of the license in each source code file, although this is fairly common practice. Keep in mind, though, that putting a full copy of the license (or at least some indication of copyright ownership and the name of the license, if it is a well-known license) in any header files that you install will avoid any confusion as to where the header files originated, so it is reasonable to do that.
If you own the project and others contribute in a fashion similar to "work for hire", then it is not necessary to name the contributors. However, you should make it explicit (and get a permanent record of an agreement from contributors) that you will remain the sole copyright owner of the project, despite contributions made. Otherwise, the contributors do have copyright ownership over the files/code that they contributed.
One last thing, not related to the question... I highly recommend that you avoid GPL and LGPL, and go for a more permissive license (e.g. MIT, New BSD, Simplified BSD), as the former will limit the adoptability of your code, and projects with more liberal licenses, if they do become adopted in the industry, have the potential to be backed by the industry (e.g. the Apache Foundation has strong industry support, because, unlike GNU/FSF which mistakenly views open source and closed source as enemies, sees them as collaborators, and so uses licenses that allow their projects to be widely adopted by the industry world).
Disclaimer: IANAL. That said, here are some random thoughts on the topic:
The term "Intellectual Property" bundles together many kinds of law: patent, copyright, trademark, and trade secrets, among others. Applying a license to a work you create will affect how your work can be used. Because each license allows for different uses of your code, how you apply the license is usually specific to which license you choose. For example, information about how to license your code under the Apache 2.0 license can be found at http://www.apache.org/licenses/. Note that projects managed by the Apache Software Foundation also require each contributor to grant the ASF copyright for the work. Granting of copyright is separate from the license.
I'd recommend reading Van Lindberg's "Intellectual Property and Open Source" to learn some terminology, and if you have significant commercial interests related to the code, spend a few hours with a lawyer.
Disclaimer: I am not a lawyer, the below is simply my understanding of OSS licensing. If I'm wrong, I'd appreciate any corrections.
Clearly state (on your project website, in source code, documentation, splash screen, about dialog, etc.) that the project is licensed under whichever license you select.
Considering the nature of open source, if a portion of your project is used in a different project owned by someone else (e.g. some useful utility class), having the "basics" of the license as part of your source code's header text makes it clear which license governs the use of that specific source file, and who owns the copyright on that portion of code in the project as a whole.
Yes, unless they have supplied you with documentation stating that they have transferred copyright to you (I believe some larger projects require contributors to do this?).
For an example of applying an OSS license to a project, see http://www.gnu.org/licenses/gpl-howto.html
A license is simply the rules you expect others to abide by if they do anything (use it, modify it, post it, make fun of it, whatever) with your code.
a) You can put what you want, but to be taken seriously, you may use a license that is already nicely written and accepted ... check opensource dot org /licenses/category for a (loong) list
b) To decide which type of license, check out this recent aricle: http://www.itbusinessedge.com/cm/community/features/guestopinions/blog/ringing-in-the-new-year-with-clean-intellectual-property/?cs=38892&page=1 . Common ones are GPL V2, LGPL, Apache, New BSD- check out the summary matrix on Page 2 of the article
c) make sure your software doesn't include code from other open source or 3rd party, otherwise you'll be claiming theirs as yours- not a good idea! There are tools you can use on trial basis to scan your code.
d) put the text of the license in a License.txt or Copyright.txt file in the folder. Also add a simple (or complex, if you wish) header to the source files as Kimvais mentions in the previous post.
Good luck.
Short non-lawyer answer;
Nothing except making it clear to anyone that you, the sole author of the code, license the code under whatever terms.
It is advisable to have the license file in the root directory. I would personally add in the "top comments" of all files the line Copyright 2010 <Your Name>. Released under <license name> in <Your country>. The last part is so that you can claim that the license was never meant to be interpreted under any other law than your local (so you can get a competent lawyer in your home country in the event that everything goes wrong)
I would say that this depends on the license you choose
For further info, read this book - or consult a lawyer with experience of software licenses.
I've got lots of source code files written in various languages, but none of them have a standard comment at the top (sometimes even across the same project). Some of them don't have any header comment at all :-)
I've been thinking about creating a standard template that I can use at the top of my source files, and was wondering what fields I should include.
I know I want to include my name and a short description of what the file contains/does. Should I also include the date created? The date last modified? The programmer who last modified the file? What other fields have you found to be useful?
Any tips and comments welcome.
Thanks,
Cameron
This seems to be a dying practice.
Some people here on StackOverflow are against code comments altogether (reasoning that code should be written to be self explanatory) While I wouldn't go that far, some of the points of the anti-comment crowd make sense, such as the fact that comments tend to be out of date.
Header blocks of comments suffer from these symptoms even more so. Every organization I've been with that has had these header blocks, they are out of date. They have a author name of some guy who doesnt even work there any more, a description that does not match the code at all (assuming it ever did) and a last modified date, that once compared with version control history, seems to have missed its last dozen updates.
In my personal opinion, keep comments close to the code. If you want to know purpose of, and/or history of, a code file, use your version control system.
Date created, date modified and author who last changed the file should be stored in your source control software.
I usually put:
The main purpose of the file and things within the file.
The project/module the file belongs to.
The license associated with the file (and a LICENSE file in the project root).
Who is responsible for the file (either the team, person, or both)
Back in 2002, when I was straight out of college and jobs were few and far between after the dot-com bust, I joined a service company which used to create software customized for their clients in Java. I had to sit in the office of a client (which was a ramshackle room in an electric sub-station rigged with an AC to keep the servers running), sharing chairs/PCs with other guys in the team. The other engineers (if I can call them engineers ;) in the group used to make changes ad-hoc to the source code, compile the files and put them into production.
No way to figure out who made what change.
No way to figure out why any change was made.
No way to go to previous version of code, unless the engineer "remembered" what he modified.
Backup: Copy over files from the production server, which were replaced with new files.
Location of backup: Home directory of engineer copying over files to production server.
Reports of production servers going down due to botched attempts of copying over files to the server (missed a file to be copied over, backups getting lost or wrong files being copied over or not all files being copied over) were met with shrugs (oh no, is it down? let's see what happened; hey who changed what recently...? ummm...).
During those days, after spending several frustrating days trying to figure out the whos and whys behind the code, I had devised a system for comments in a list in the header of the source file which detailed the following:
Date of change made
Who made the change
Why was the change made
Two months later when the list threatened to challenge the size of the source code in the file, the manager had the bright idea of getting a source version control system.
I have never needed to put any comments in headers of source files (except for copyright notices) in any company I worked since. In my current company, everything else is mostly self-evident by looking at the code, or going to the bug reporting system which is integrated with the source version control system.
What fields do you need? If you have to ask whether to put some info there, you don't really need that info. Unless you are forced, by some bureaucratic incompetence of your employer, I don't see why you should go looking for more info than you already feel should be there.\
In most organizations, all source files have to begin with a legal blurb. If you're really lucky, it's just a one-liner, but in most cases it's a really long block of legalese. As a result, few people ever read these. Our eye just travels to the first program element and then goes up to its documentation.
So if you want to write anything, write it in association with the topmost program element, not the file.
Any other bookkeeping information should generally be part of your version control, not maintained (poorly) in the file itself.
In addition to the comment above stating license, the project that it belongs to, etc I also tend to put the "weird" requirements at the top as well (such as "built with version X of library Y") so you, or the person who picks it up after you won't change something that the program relies on without realizing it (or, if they do, they will at least know what to change back)
A lot depends on whether you're using an auto-documentation generation tool or not.
While I agree with many of the comments, if you're using JavaDoc or some other documentation generating tool that depends on comments, you'll obviously need to include the things it wants to see.
You did not mention that you are using a version control system and your comment in Neil N's answer confirms this for your older code. While using version control is the best way to go I also have experienced many situations where the cost of doing so for older code would not be paid for by the project's sponsor. If you do not have a centralized change history for the project then the change history can be put in the modules. It is good that you are using a version control system for your new code.
Your company name
All rights reserved (c) year - or reference to appropriate license
Project or library this file is for
Module it belongs to
Description of what it contains
History
-------
01/08/2010 - Programmer - version
Initial creation.
01/09/2010 - Programmer - version
Change description.
01/10/2010 - Programmer - version
Change description.
Those useful fields that you mentioned are good ones. Who modified the file and when.
Your version control software should allow for the embedding of keywords within comments. For example, in CVS, the $Id$ will resolve to the file, date/time modified, and user that modified the file. It will automatically be kept up to date with each check-in.
Include the following information:
What this file is for. That's a very useful piece of knowledge and it's more important than anything else. You should tell the reader, why there is such a file, why did you group functions in a separate file/package/module and why they are used. Maybe briefly, one or two lines, but that should be there.
Legal stuff, if appplicant.
Leave the place for special commands of console editors, such as of Emacs.
Add special commands that your auto-documenting system requires.
Things things you shouldn not include are
Who created the file
When it was created
Who modified it the last time
When it was last modified
What was added by the latest modification
You can--and should--retrieve it via the version control system, where it's constantly and automatically kept up-to-date. Let alone that most of these points are just useless.
Who created the file
When it was created
Who modified it the last time
When it was last modified
What was added by the latest modification
I'm currently trying to evaluate Mercurial, to get a feel for the philosophy the system tries to promote - but one thing that's got me confused is the presence of the bundled 'extensions' and how they fit into the mix.
In the core package, Mercurial ships with a bunch of functionality that is implemented as extensions but is disabled by default. (See: https://www.mercurial-scm.org/wiki/UsingExtensions#Extensions_Bundled_with_Mercurial)
Here's the thing I'm confused about:
Are these extensions considered first class citizens by the Mercurial dev team and therefore part of the overall Mercurial approach to DVCS?
Why are they implemented outside of the default features and disabled by default?
I don't need info on how activate extensions, that's pretty straight forward - it's the logic behind the separation that I'm curious about.
The reason I'm trying to get my head around this is because I don't really want to try and crowbar an opposing approach into Mercurial via extensions if it differs from the overall philosophy of the project.
Are these extensions considered first class citizens by the Mercurial dev team and therefore part of the overall Mercurial approach to DVCS?
Yes, although we won't generally advocate their use to new users, they are very useful for advanced usage. I guess everybody in the dev team has extension enabled (at least mq, patchbomb, and sometimes record).
Extension accepted in hgext/ are reviewed priori to inclusion, and we generally require them to provides tests. But they are often owned by outside contributors and aren't updated by the dev team except for API changes within core hg.
Why are they implemented outside of the default features and disabled by default?
We generally think that hg should stay simple and adding more commands might confuse users (e.g. if you have a simple workflow you don't need to learn about mq). But if a command is deemed useful for most users, it can migrate from an extension into core (that was the case for bisect, and it is the case of the subrepo functionality).
Almost immediately after posting, I learnt about the following hg command:
hg help extensions
This contained some information that I don't think is available in the Mercurial help docs:
Extensions are not loaded by default for a variety of reasons: they can increase startup overhead; they may be meant for advanced usage only; they may provide potentially dangerous abilities (such as letting you destroy or modify history); they might not be ready for prime time; or they may alter some usual behaviors of stock Mercurial. It is thus up to the user to activate extensions as needed.
This helps answer part of my question.