Can the owner of an open source Github repository later decide to close it? What about other people's contribution to that project?
Edit - several people focused only on the legal aspects. Besides them there exists the technical question: Is it technically possible to take a public repository I own on Github, and turn it private at a later date? Assuming nobody created a public forked from it, will this in effect hide the source code for this project?
(Note that I am not a lawyer.) From the GitHub Terms of Service, paragraph F.1:
We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.
In other words, GitHub itself has nothing to do with how you license your code. So you can decide to stop publishing your source via GitHub, but everything that has been forked and cloned from it up to that point is of course still "out there" under the open source license you originally used.
The same holds for other people's contribution to the project: whatever was permitted by the original license remains, so it is between you and the other contributors. GitHub has little to do with it.
As to the updated question:
It is safest to assume that anything you put on the web is out there forever. GitHub allows you to browse the source code through the web. It seems that GitHub's robots.txt asks crawlers to stay away from the source code, but there's no guarantee that they will do this. I can easily imagine Google Code Search starting to index GitHub, for example (if they're not doing that already.)
Bottom line: once the source is public, you can never make it private anymore.
Is it technically possible to take a public repository I own on github, and turn it private at a later date?
You cannot have private repositories unless you pay for them. Github's Plans and Pricing state that you can sign up for the free public repositories, and upgrade/downgrade your account at any time, so they almost certainly have a way to make your free public repositories private by upgrading to a paid account, or they would have a tremendously broken business model.
After reading their help files, you can indeed mark a public repository as private if you have a paid account.
You could also just delete the repository from your free account, and start hosting the repository yourself if you want to stop sharing it.
It depends on the license. If it's BSD or similar, then yes, it can be close-sourced from a future point in time, incorporating third-party contributions (because the license allows it). (Any code released before the source is closed remains open under whatever license was chosen.)
If it's GPL, then any third-party GPL'd code can no longer remain in the closed-source repository, unless a separate license to use it in a commercial, closed-source application is granted by each and every third-party author.
The copyright owner can choose whatever license he wants for code. However, changing a license is not a retroactive decision, it won't revoke the license of stuff that has already been released. Unhappy users can thus still fork the code and continue the work under the terms of the previous license.
But you should really ask this question to a lawyer (which I'm not). For example I'd tempted to say that released = publicly available but this is just my interpretation. Really, ask a lawyer.
There isn't really an opensource license out there that is retroactive. So even though you close source it later, the people before still have the old code with the old open source license...
Also, if a lot of people contributed, or one person contributed a large amount of code, then certain pieces of code may be more theirs than yours, which means you'd have to get permission from them to change the license of it(if the license is restrictive that is, such as the GPL. With BSD-style, there is no such restriction)
If in doubt, consult a lawyer and not a forum of people
Related
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
So I found an open source project that uses the reciprocal public license 1.5 (RPL). It seems that the RPL means that you must post all of your code back out to the community.
RPL 1.5 - Paragraph 5
Further, under the RPL all components you author including schemas, scripts,
source code, etc. -- regardless of whether they're compiled into a single
binary or used as two halves of client/server application -- must be shared.
You have to share the whole pie, not an isolated slice of it.
I work for a health care company that is not going to be ok with me posting our proprietary code out on the internet.
So I am wondering, is that really what the RPL does? Is there limitations on what needs to be published? Or is it really just any thing that touches the RPLed project must also go open source under the RPL?
For a commercial software RPL is even worse than GPL.
It is true that you have to publish your source code on any derivative work.
Also in GNU web site it says:
The Reciprocal Public License is a
non-free license because of three
problems. 1. It puts limits on prices
charged for an initial copy. 2. It
requires notification of the original
developer for publication of a
modified version. 3. It requires
publication of any modified version
that an organization uses, even
privately.
source
Edit
Quatation from RPL 1.5:
6.0 Your Obligations And Grants. In consideration of, and as an express
condition to, the licenses granted to
You under this License You hereby
agree that any Modifications,
Derivative Works, or Required
Components (collectively Extensions)
that You create or to which You
contribute are governed by the terms
of this License including, without
limitation, Section 4. Any Extensions
that You create or to which You
contribute must be Deployed under the
terms of this License or a future
version of this License released under
Section 7. You hereby grant to
Licensor and all third parties a
world-wide, non-exclusive,
royalty-free license under those
intellectual property rights You own
or control to use, reproduce, display,
perform, modify, create derivatives,
sublicense, and distribute Licensed
Software, in any form. Any Extensions
You make and Deploy must have a
distinct title so as to readily tell
any subsequent user or Contributor
that the Extensions are by You. You
must include a copy of this License or
directions on how to obtain a copy
with every copy of the Extensions You
distribute. You agree not to offer or
impose any terms on any Source Code or
executable version of the Licensed
Software, or its Extensions that alter
or restrict the applicable version of
this License or the recipients' rights
hereunder.
Reciprocal Public License is more stricter than of GPLv2. It requires the distribution of all the source code (Whether the proprietary or Open Source), which linked, based out of RPL. Be careful in terms of protecting own IP.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been reading through the backlog of answered questions on SO regarding "How to promote an open source project". Not surprisingly, many of the answers pointed people to SoureForge/FreshMeat and other sites etc as well as blogging and whatnot. This started me thinking where is the best place to host a project and why?
As my first project is currently hosted on CodePlex, I started to wade through the Google search results to collect information on the pros/cons of each; however the comparisons that I found are rather dated (2+ years old).
http://www.stum.de/2008/12/13/sourceforge-vs-codeplex/
http://www.developmentnow.com/blog/2006/11/codeplex-vs-sourceforge/
http://www.spacesocket.com/forum/thread-6654.html
etc...
So the next question becomes "Should I host my project on multiple sites" to which the following post provides the expected answer (thankfully! as that would be a pain to maintain).
Hosting an open source project at several sites
Based on the current state of various Open Source hosting sites such as CodePlex, GitHub, Google Code, SourceForge, etc, etc is there any notable pros/cons of one site over the other? i.e., should I stick with CodePlex or am I missing out by not using one of the alternatives? Will one bring about more traffic to a new and unknown project?
I plan on exploring each site in more detail to see what they all offer, but given the vast knowledge of the good folks on SO, figured I would start with this question first.
UPDATED
As per erjiang answer below... I am currently using Mercurial for version control, and I am open to anything other than TFS. Also, my current project is only me developing, but future projects may be collaborative so worth considering...
Edit 2015-08-01: This answer is still getting views and votes. It's more than ancient and I'd like to delete it, but since it's the accepted answer, I can't do that. Then again, it's community wiki and the community has kept it up-to-date - thank you for that!
SourceForge has crossed over to the dark side, taking over project and bundling them with Adware (Google GIMP Sourceforge Adware). Avoid at all costs. GitHub is as of now still the most popular one, although there are alternatives (e.g., BitBucket offers unlimited private repos for free for up to 5 users.)
It's crazy how much the landscape changed in the past few years, and if you're reading this in the future, maybe GitHub is no longer the cool product. Bottom line is: There are a plethora of awesome options for whatever source control system you want to use.
Old 2010 information below for the sake of history
Edit: This answer is now ancient. In the past 2 years, GitHub has emerged as the prime Code Hosting place, and whenever I have to create a new OSS project, I don't have the trace of a shadow of a doubt where to go to. Leaving this below for reference.
Indeed, my posting is almost 2 years old (2008) now and not entirely accurate anymore.
Why?
Because I think that SourceForge is insignificant now for open source projects. Okay, this will get me into a lot of trouble, so let me clarify:
I am absolutely convinced that Open Source projects should be run on a DVCS, preferably git or mercurial as they are the most widespread - nothing against Bazaar, but I think it's a bit too obscure. (Edit: SourceForge now offers Mercurial and Bazaar, so that argument doesn't stand anymore. However, following two redesigns I think that SF's image isn't too great. To compare them to the images of companies: While GitHub is Apple, SF is IBM. Rock solid, but a bit dusty)
So if I were to write this posting again, it would be CodePlex vs. GitHub vs. BitBucket, with GitHub being the Winner. But that is a blanket statement, so let me add details. +/- isn't strictly Pro/Con, it's more to highlight different philosophies.
CodePlex
+ Real Mercurial/Git Hosting - no buggy bridge on top of TFS, you have real Mercurial/Git
+ Integrated Wiki that allows to add rich documentation and nice looking pages
+ Bug Tracker and Discussion Forums included
- Source Code browser isn't that great - Diffs appear in a popup and just 'feel' complicated
- Forks and Pull Requests 'not as easy' - the UI could use some work
Overall, CodePlex is still great but I feel it's more suited for single developers or very small teams because the focus of the website is on the Wiki rather than on the source code. It's more a publishing than a collaboration platform. Theoretically you don't need a project homepage, your CodePlex project can be your one stop shop.
GitHub
+ Git Hosting, supports SSL/SSH
+ Network graph allows to see forks and what merged into what when
+ Ability to 'watch' projects - your account page is like a Facebook wall with new checkins
+ Super good diff viewer with the ability to comment on single line changes - see here
+ Forking is a 2-click process, and so is sending pull requests
+ GitHub now has the the GUI tool GitHub for Windows
- Main page is not very 'pretty' for Non-Developers. If you have a Readme in your project (supports some markup languages like Markdown or HTML) it is displayed, but the initial page is the source code
- Wiki isn't that great - it's Markdown, but sometimes formatting feels a bit too complex.
GitHub has a different philosophy than CodePlex: it's all about the source code and about collaboration among devs. The main project page is the most up to date source code. There is a separate Wiki, but that's more intended for Documentation rather than presentation of your project. The network graph is fantastic, although it can get confusing once there are more than about 20 forks (frequently when a high profile project is announced everyone and their dog is forking it, but most forks die quickly). GitHub scales very well to any size.
In fact, GitHub makes it super easy for me to fork a project, apply a fix/patch, commit it to my fork and send a pull request to the author. Together with the Network graph it's really easy to see the commit.
But you most likely need a separate home page to present your project to end users and to provide downloads, as GitHubs download facilities aren't that great.
BitBucket
+ Git/Mercurial
+ Allows private repositories for free, up to 5 users
I haven't used BitBucket enough to make a real comment. The one feature that sets it apart is that private hosting is free, while GitHub charges and Codeplex does not offer it at all.
Google Code
Google Code is not an option anymore.
- Project creation is disabled since March 2015, and the Google service will be permanently closing down in January 25, 2016, as the competing services are simply better.
- It's ugly and it's too complicated to browse the source code (the link is somewhat buried)
I haven't used it so I don't want to say it's bad - it's not. A lot of projects use it and it's very stable and robust, haven't heard much bad from any developer. However, as a matter of personal, subjective opinion the 'design' puts me off.
SVN vs. Git/Mercurial
To reiterate my comment above about SourceForge being obsolete: That is of course a bit harsh. I do however believe that SVN is detrimental for open source projects. First of all, weird metadata requirements to ignore files. On Git or mercurial, you have a file called .gitignore or .hgignore in the root of your source tree which includes a list of files/directories/patterns to ignore. No magic svn:ignore metadata in the .svn folder. This alone blows SVN out of the water for me. If I start a new Visual Studio project I need to then apply that magic metadata, while with Git/mercurial I just copy over one file and be done with it.
Then, the ability to fork, patch and send a pull request is fantastic, especially for small/one-off patches.
Last but not least, SourceForge is still WAY too complex for my taste. It's not a bad host, but it really shows it's age IMHO. That being said, it's still robust and has many mirrors world wide. Also the Bug Tracker is much more sophisticated than the others.
Also, if your project for some reason requires strict contribution rules (which may make sense, e.g. legal protection to make sure the committed code is indeed legally contributed) then a traditional system like SVN hosted on SourceForge may work.
Edit: Wasn't aware that SF finally has distributed hosting. As said above, it's robust but just not the 'cool kid' anymore, and I find it much too complex.
TL;DR
For any small to medium project I whole hearty recommend GitHub, for small projects where you want a nice Web Site as well I'd go with CodePlex and for private projects I'd go with BitBucket. For big projects that require a very sophisticated bug tracker, tons of extra features and a 'real' website, consider Source Forge.
Well, you haven't said what source control system you use, which greatly influences your choices.
(not comprehensive)
Git -> GitHub or Gitorious are the obvious choices
Mercurial -> BitBucket
SVN -> Savannah, SF.net
Bazaar -> Launchpad
CVS -> upgrade to a newer source control system
I'm a Git fan, but Mercurial is pretty awesome as well. I personally use GitHub for it's awesome collaborative features, like easy forking and pull requests.
I want to add that CodePlex isn't very popular in the open-source ecosystem outside of the Microsoft camp, and that's easy to see from their most-downloaded list. It's probably a combination of how naturally Microsoft-centric it is, and also from past stigmas. If you're developing exclusively for .NET or something similar, then that'll change the perspective.
Edit: Also, I would argue that developers don't usually go browsing randomly for interesting projects. You're equally likely to go unnoticed on GitHub as you are on Codeplex, but if someone does discover your project, they'll be more likely to send messages/file bugs/contribute if they already have an account on that website.
Since Github is growing quite fast and seems to be the most prominent among the projects I see these days. It would get my vote.
But I think one doesn't have to mean you can't use the other. I see many projects that use Github for the source and Google Code for the docs. And besides that a Sourceforge link to it aswell.
It doesn't really matter what you use as a primary host, but I would recommend you add your projects on the other sites aswell so it's easy to find it.
This question seems like a duplicate of this one: https://stackoverflow.com/questions/10490/best-open-source-project-hosting-site
Here was my answer on that question: https://stackoverflow.com/questions/10490/best-open-source-project-hosting-site/3433969#3433969
In general I think the important pros/cons most significantly relate to the development features offered and the primary audience of each site, which in my above answer I walk through for the four most popular sites.
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
This question has always been around my head.
Can someone create a new product based on an existing open source project?
Say you want to create an "Apaxe webserver" that is basically Apache with your some extra plugins ( say support for ASP or something similar )
Is this possible?
Would you be able to create a closed source product ( either free or licensed )
As for GPL seems clear it is not possible because the source should be open. But what about Apache license, BSD and others "corporate friendly"
Are the price ( free for most of the project ) , bug fixes and counting with the core development team the only thing that prevent from others to commercialize those OS products?
What about: Khrome a commercial product based on Chrome with ActiveX support ( who would dare to do such a thing :P )
EDIT
Thank you all you all for your answers.
So, again
What prevents from similar ( clone ) products from appearing in the market?
:)
NOTE: I know we are not lawyers, and we could read every OSS license here http://www.opensource.org/licenses.
Nothing prevents clone products appearing on the market. Look at all the various linux distributions, for example. The X.org project was forked from XFree86. And so on.
It happens relatively infrequently, though, for a couple of reasons:
The original project has the first-to-market advantage
The original is usually being given away free
So unless your version is significantly better than the original, you're not going to get much uptake or make much money out of it. If your version is significantly better, then go ahead!
From the original developer's point of view, the power of the GPL is that it forces such clones to share any improvements with the rest of the world, so they can be incorporated back into the original.
Generally, my read of the licenses is:
You can make a derivative work of any project based on one of the popular licenses (i.e. GPL, LGPL, Apache, MIT, BSD).
You may charge money for at least the distribution & packaging of your derivative work.
Depending on the license, you may also have to distribute your modifications in source form and/or include notices in your distribution.
So to your question about Apaxe: yes, you can do this as far as I know. I believe that the Oracle HTTPD server is actually derived from Apache, and it's definitely not free!
Here's my 10,000 foot view of open source licenses:
"Real" open source licenses (eg: MIT, BSD, Apache I think, etc.):
You can do whatever you want with licensing derived works. It can be closed, open, etc. The license places no restrictions on your licensing of derived works.
"Restricted" open source licenses (eg: GPL, LGPL):
Derived works must include specific license restrictions; for example, the GPL requires derived works to be GPL-ed. Essentially your rights are restricted for derived works.
Charging for products is separate from either of these; neither type restricts charging for products, although some licenses place restrictions on the rights you can retain and/or must convey to receivers of your software (ie: the "Restricted" licenses).
Hope this helps.
Edit: Changed by original "DRM" term for GPL type licenses to "Restricted", cause some people attach negative connotations to DRM, and/or cannot grasp how the GPL restricts your rights for derived works in an almost identical way to any other type of DRM (ie: controlling what you can do with it). Seriously, you can be a FSF supporter and still grok the concept that the GPL is more restrictive than "real" open source licenses. The question is not about which type is right or wrong, it's about what the difference is.
Red Hat (and most of the other Linux vendors) charge for support, not for their software - which is primarily how companies can make money off of code that is GPL licensed.
It really depends on the license the open source project uses.
Disclaimer: I am not a lawyer; you should always read the license for full details.
If a project is under the GPL, then anything you derive from it must also be released under the GPL (or a compatible license, and if it is released at all). You're still allowed to charge money for it, but anyone who buys it has to be provided with the full source, and you can't prevent them also selling it, or giving it away for free.
If a project is under the BSD license, you can do pretty much anything with it including incorporate it into a proprietary closed source product. There is BSD code inside Windows!
Other licenses fall somewhere in between.
look at MyEclipse, its really just eclipse+free plugins+myeclipse's plugins and it cost some money.
What prevents from similar ( clone ) products from appearing in the market?
Nothing. The real question is: How can a similar cloned product get more popular than the original product?
Some cases where somebody might clone/fork a project:
Picking up a dead open source project and continuing its development. If the new derived product is maintained regularly and it gets more updates than the original version, then people will start using the new version. This is one of the big benefits of open source - good software does not need to die, just because the original developers stop developing it, but someone else can continue from where they were left. One example of such a project (which I've used) is that the development of Turck MMCache had died out in 2003, so eAccelerator forked it and continued its development in 2004. I'm sure there are lots of other examples.
There is a disagreement in the developer community of an open source project, and the project splits into two. That's why it's best to strive for a common understanding in open source projects, so that the community would not be split needlessly. If a project is split, the projects may continue living if they managed to attract enough developers and users, but otherwise they may slowly die. In general, splitting should be avoided, because it makes the community more fragmented and weaker. IIRC, in the video presentations of Producing Open Source Software (good stuff!) they mentioned a case where the original developer of some project wanted to take a completely new direction in the development, but the community of other developers wanted to keep the old direction. The result was that the original developer was kicked out of the project, so he created a fork of the project, while the rest of the community continued the development of the original project.
A commercial closed source derivative of an open source project which was released under a permissive license (for example BSD). The derived product would need to be considerably better in features or in support than the original product. Otherwise people will prefer using the original open and free product.
Isn't that essentially what red hat does? Even though they have fedora, they are charging money for their linux distribution. Granted, they've written a lot of code for it, it's still based on open source-stuff.
After delving into the world of opensource I have found implementation is emphasised over design. Version control allows for a project to branch off in many directions, which projects may do; this suggests lack of consensus or direction amongst the participants.
What software or websites are useful for collaborative design?
There are literally hundreds more collaboration apps out there and more keep appearing by the day, but these should get you started:
Source Control (Online):
Assembla - Public source is
free, private repositories are paid
Source Forge - Open source only
Google Code - Open source only
Git Hub - Public source is free,
private repositories are paid
Bug Tracking/Project Management
LightHouse - Unlimited open source, paid private projects
FogBugz - Full version is free for up to two developers
BaseCamp - Paid only
Trac - Not hosted (although Assembla hosts it), open source - Python
Bugzilla - Not hosted, open source - Python
Mantis - Not hosted, open source - PHP
Mind Mapping
MindMeister - Free for small
plans, with options to upgrade
Documents
Google Docs - Free
Buzzword - By Adobe - free
Scribd - Free
Graphics
Aviary - I'm not quite sure how
collaborative they are, but I think
you can use their tools that way
Photoshop Express - Another
Adobe product
Picnik - Free
Whiteboards
Scriblink - Free with paid
options
skrbl - Free for public, paid
for private
Dabbleboard - Free and paid
plans
Hosted Wikis
pbwiki - Paid plans
Wikidot - Free with paid plans
Miscellaneous
Acrobat - Part of Adobe's
online suite
Zoho - Fits into a lot of
categories
I've been studying collaborative design early in my Ph.D. (contact me if you want a literature survey draft that I wrote about it a back in 2003).
Anyway, collaborative design applications (as in UML modelers) fall into three categories in terms of timing:
Synchronous - Two people or more editing at same time
Asynchronous - Check-in check-out model, a mess if multiple people edit at the same time.
Hybrid (can share certain things in real time).
In addition, they fall into three categories in terms of metaphores:
- Desktop based - Essentially something like rationale rose with multiple user support
- Whiteboard based - Free canvas, not necessarily structured, sometimes has support for UML recognition. Usually a mess to manage multiple models.
- Hybrids
So this gives you a 3x3 "design space" of tools, and there are research tools inside every one of them.
The problem is that in switching to collaborative work there are many usability issues that are difficult to address. For example, access control, synchronization, awareness, shared viewports, etc. There are some academic advances on these, but they're not necessarily in tools yet.
If this is the topic you're interested in, comment, and I'll post some of the tools I'm familiar with.
I would suggest using a Wiki to document/explore the design.
A mailing list. And opensource projects argue on enough of them. I doubt lack of collaborative tools is where the lack of design emphasis comes from.
In no particular order:
A good email client (I use gmail)
Good wiki software (I use media wiki)
Github or an evolved source repository that allows for easy branching and comments on check ins
A chat room, plain old irc or that built in messenger one
A news group or mailing list (I use the free google one)
Skype
I am somewhat skeptical about collaborative design. From Scobleizer: Why Facebook has never listened and why it definitely won’t start now:
My former boss, Jim Fawcette, used to
say that if you asked a group of
Porsche owners what they wanted they’d
tell you things like “smoother ride,
more trunk space, more leg room, etc.”
He’d then say “well, they just
designed a Volvo.”
also from the comment:
Apple never listens to its customers.
In fact, it prides itself on not
listening. If you listen to your
customers, you will never innovate and
you will never be ahead of the curve.
You will always tweak and fix minor
things on what is top of customer mind
that day, week or month.
I agree with the wiki answer. I'd suggest looking at MindTouch. Our company uses them for our Intranet and for other internal and external project collaboration/management.
A wiki (such as ScrewTurn, or MediaWiki) is a good tool to document a project.
BaseCamp by 37 Signals
Microsoft Office Live Meeting
For us, all we use is Adobe Version Cue, Google Docs, Google Calendar and Gmail.
Design wise, Version Cue does the trick in terms of file management really well.
As for Google, well, it helps organizing all of my activities more than very well. I find most collaboration tools, like Basecamp, a tad too restrictive or just not exactly right. Google lets me organize my stuff just the way I want it to be.
For collaborative design ... without a doubt, it's
http://conceptshare.com
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Say I had an open-source project which I wanted to try and generate some exposure for. Would it be considered unethical to set up a project entry for it on several sites such at github, sourceforge and google code, for example?
This would be purely for giving it greater exposure. I realise there might be some practical reasons for doing this, such as wanting to use github for source control, and sourceforge for issue tracking, forums and such. For the sake if this question I'm wanting to focus more on the case where you use one of the sites as the main site for the project, and make "stub" projects on the other sites that point back to the main site.
My gut feeling is that while it may not be outrightly unethical, it might be bordering on the sleezy side...
Stick with one provider. "If you build it, they will come" :)
Besides, once people do start coming, they'll just google the project name anyway. Finding the same project on Sourceforge, Github and Google Code is just going to annoy the hell out of people.
I don't know about the ethics, but consider the practicalities:
you will have to do multiple repeated
uploads to several different sites,
doing it to a single site can be a
pain
users won't know which site to report
bugs at
if you use the SVN/CVS/git
repositories, you will have multiple
copies of your code in different
repositories - a very bad idea
I'm sure there are other problems. So stick to one site - I've been using Google Code for a small project I've just started (CSVfix, if anyone is interesed) and I can recommend Google as being very easy to set up.
I think this is fine, for the reason that each provider may have something you want. You should pick the services that are best for your project. For example:
Google code has file hosting, but the issue management is terrible, so
Launchpad has great bug tracking, but no wiki, and we use Mercurial, so
Bitbucket.org has mercurial hosting etc..
So it might be reasonable to use Launchpad for bug tracking, and Google code for hosting files and wiki, and Bitbucket.org for hosting source.
I would suggest choose your preferred host for your project. You can publish about your project on many forums. Exposure will come via search engines.
I don't know why you think it would be unethical or sleezy. Maybe you can say more about that so people could address your concerns directly. To measure that, consider if you are intentionally breaking the rules of the service, lying to anyone about how you are using the service, and being deceptive in some other way. If you are using multiple services, I don't think you have anything to hide.
Consider the Perl community, which is the one I deal with. Several projects are hosted on one of the source control services, such as SourceForge, Google Code, or Github. The main distribution for most Perl stuff is CPAN, though. Other people may distribute through Freshmeat or some other service. The main issue tracker comes from Best Practical, which hosts a free RT for every Perl module on CPAN. Most of the people I know use the best from more than one service. Indeed, the Web 2.0 way is to create applications by cobbling together services from multiple vendors. :)
You should also think about the social construction of these free sites. Places like SourceForge and Github give out free accounts, but they also sell services. They get the buzz through the free stuff that allows them to sell the premium services. I don't see anything wrong with that. If you're using the free services, just realize that in return for your free use, they get to use you as free tester, advertiser, and so on. Again, I don't see anything wrong with that. It's just part of the deal. You aren't just taking from them, you are also giving to them. There's an exchange between consenting parties.
What would be unethical, I think, is any service that forbids you to use another service or intentionally sets up a situation which would make it hard for you to use another service by not being compatible with common tools or not giving you access to your data (e.g. somehow disallowing git-svn, and so on).
Services spanning these various hosts will be inconvenient and difficult to maintain. For the above mentioned reliance on search engines to generate traffic take care to chose a name that differentiates your project from the web noise. A clear indication that traffic will not arrive is if your project first gets a re-recommendation on spelling. Take for example the people who brought you the chattr project from GNU. Immediately chatr is suggested as the proper search and your traffic will suffer accordingly.
as i has already been said having to maintain the code on several hosts will make it more trouble then it is worth. What you have to think is you would need to make sure that it uploads properly over several hosts, it would more then likely cause confusion to some over if one copy is legit and the others aren't which in turn could cause a bad name for the project before you even start.
End of the day there are much more, better ways to spread the word of your project, social networking sites, specific related forums are two main ones for you to consider, either way you would be better off spending your time posting to several sites then you would uploading and maintaining code on several sites.
I consider having several (independent) mirrors to be a benefit for the community, because such distributedness assures more reliable accessibility of your public work, now and in future (it will survive the failure of any single hosting site).
That's why I want to keep track of the available diffeent options to publicly host open-source projects:
Which public hosting sites for darcs projects are there?
Which public Git hosting sites are there that are free software?
I believe it's rather ethical (or moral) to put some effort into ensuring that your public work is published in the most accessible way (well documented, and with some guarantees about it being accessible at any moment when someone is interested).
The effort for you to push your work to several places independently (I mean, they won't depend on each other) and manage all this is probably not really a nightmare (as suggested in some other answers here), especially with a DVCS. For example, one can even set up Git so that one pushes to several places with just one command.
I feel that unless you are forcing someone to read something done by you, but you are rather just putting your stuff somewhere for it to be findable and accessible if someone is interested, you are not egoistic or ego-whatever.