Google Reverses "Absurd" Mozilla Code Ban 201
Barence writes "Google has reversed its decision to ban projects created under the Mozilla Public License from being hosted on its Google Code site. Google banned the license in August, claiming it wanted to 'make a statement against open-source license proliferation' which it blamed for hindering the cross-pollination of code from one project to another. Chris DiBona, of Google's open source team, described its decision to ban the MPL as 'absurd,' citing the community's huge popularity." Jamie mentions that the issue was raised from the floor at OSCON at the Google Open Source Update panel, with DiBona on stage.
Proliferation of O/S software hosting services (Score:3, Interesting)
Frankly, given Google's record, I refuse to host any of my projects on Google Code, or to participate in the development of any projects hosted there. I use Sourceforge [sourceforge.net] (has svn and ssh access) and Berlios [berlios.de].
Multi-license ! (Score:5, Interesting)
Maybe we should come up with a good acronym for a package of the most popular licenses...
Re:Multi-license ! (Score:4, Interesting)
I am not sure about a good acronym but Public Domain comes to mind.
If there is going to be a unified Open Source License that is completely compatible it would have to be public domain where the developer looses all the right to there code and users of the code have no exclusive rights.
Issues such as credit, openness, goodness, who will use it, who cant, stopping Microsoft from ripping it off, freedom of speach, spreading the code, patents, making money from it, not making money from it..... All these political ideals need to be stripped out.
Part of the problem with each new version of the GPL more and more political ideals have been added to the license making it more incompatible as time increases. So if you want to make open source code that can be used wherever it needs to be public domain.
Proposed solution (Score:3, Interesting)
Here's a possible solution to the license proliferation / cross pollination problem of F/OSS software projects: Each open source compliant license could include within its terms specific permission to use portions of its project's code in software licensed under another open source compliant license. It could be called an Open Source Cross-Pollination Clause or something like that, and the wording would be identical across licenses. It would be a sort of "UCC of software licenses." As an example of what might happen if this clause were included in, say, the Apache license, the Mozilla license, and the Eclipse license: Suppose there are a group of functions in Apache that produce some result that might be useful in a web browser. The Mozilla project could copy that code verbatim, insert it into Mozilla, and perhaps make modifications to it later on. The copy of that portion of code would essentially become licensed under the Mozilla license. The Eclipse project could then find that code useful and copy it into Eclipse, perhaps modifying it further. Now there are three copies of that code, each licensed under the same license as the broader code that contains it. If, say, all OSI approved licenses decided to insert this Cross-Pollination Clause, it would completely solve the problems of license compatibility.
Re:Boycott Vibrant in-frame popups (Score:2, Interesting)
I object to ads. If you want access to my eyes to sell your product, pay me.
Re:Meh (Score:2, Interesting)
Re:Multi-license ! (Score:3, Interesting)
Re:Could someone tell me... (Score:2, Interesting)
it's like LGPL with a file-based granularity rather than library-based granularity. Also, MPL code can be linked into your binary. LGPL effectively requires dynamic linking/shared library. [Specifically, the user must be able to replace the LGPL part with their own version]
So it's sort of in the middle between BSD and LGPL.
Re:Proposed solution (Score:1, Interesting)
Except this fails to take into account the licenses that are created explicitly because developers don't want to see their code under a different license. Some view the BSD license as too lax, while at the same time viewing the GPL and LGPL as too restrictive. Therefore, they feel the need to create their own license, so that the code can be dealt with on their terms.
An immediate example that comes to mind is Sun Microsystems's CDDL. According to Wikipedia [wikipedia.org], the CDDL was based on the MPL explicitly because Solaris developers did not want their code to appear in GPL-licensed projects.
And before the GPL-advocates come in here and rally against this kind of behavior, remember that the GPL itself was created because the FSF developers did not feel secure in releasing their code into the public domain or under a permissive license, for fear that it would be incorporated into proprietary products. Likewise, the LGPL was created because certain libraries needed to be able to link to non-GPL code for strategic reasons.
Re:Multi-license ! (Score:3, Interesting)
Personally, I want the code I write to remain free, but the code other people write around it, they can do whatever they want with. I tend to release code under a mozilla/cddl style license with a GPL exception ( though I make sure to leave a strongly worded comment that any code contained MAY NOT be relicensed under the GPL, since GPL people tend to forget that importing doesn't imply relicensing )
Re:Proliferation of O/S software hosting services (Score:4, Interesting)
For the love of god do not use tortureforge.
There are plenty of alternatives, use one that doesn't make your devs and users scream in agony every time they have to use it.
Sourceforge is so bad, it's not remotely funny. Not only are the "Forums" and "Bugtrackers" utterly unusable and useless. Even supposedly trivial (read: baseline!) stuff like downloading a release tarball is a sea of pain, requiring 2-3 clicks through useless spoiler-pages (more ad impressions, eh?). God forbid someone just wants to quickly wget a release to give it a shot, OSDN might not profit!
Generally avoid any provider that carries "forge" in its name. Most of them took the abysmal tortureforge interface and somehow managed to make it worse.
Also beware of tortureforge in disguise! Some, like berlios, copied everything except the name. Same poison, different bottle.
So, here are some sane choices (randomly picked, there are more):
And if you are serious and have a bare minimum of linux-skills then you can always set up your own instance of RedMine [redmine.org] (not trac, mind you) along with a SVN, Git, bzr or whatever server. It's not rocket science. I'm sure there are even hosters that sell it prebundled for a few bucks a month.
It puzzles me that some people still pick TortureForge for their projects in this day and age. But normally that's at least a surefire sign that the project is not worth the diskspace it occupies... (for *new* projects that is, not counting legacy projects here that started on sourceforge years ago and are just too lazy to move).