RMS Feels There's "A Systematic Effort To Attack GNU Packages"

[bridgman]

I think you have misunderstood me. You can, as you state, use BSD licensed code in a GPL licensed project, however, the changes that are made in the GPL licensed project to the BSD licensed code are also GPL licensed and there is no way to use GPL licensed code in anything but GPL licensed projects. You can't use GPL licensed code in a BSD licensed project without switching the whole project to the GPL.
This has to the BSD licensed code the same effect as not releasing the changes at all.

I disagree. AFAIK the generally accepted convention in a project with mixed licensing is that changes to differently licensed subtrees are submitted under the license of the subtree as long as that different license is clear.

Using the Linux kernel as an example, if I submit changes to an X11-licensed file (or add files to a folder where all the existing files are X11-licensed) then I expect those changes to be subject to the terms of the X11 license as well. Otherwise I would effectively be submitting a GPL-licensed change in the middle of an X11-licensed file/folder, which would normally be rejected by the subsystem maintainer.

That said, I agree this is a bit fuzzy and generally accepted practice is always a bit dangerous, but the big ugly license header at the top of each differently-licensed file helps to keep intent clear. The subject does come up from time to time at conferences and on IM, but so far the conclusions have been along the lines of "hey, look at the time, isn't the beer event starting now ?".

[erendorn]

This doesn't sound right. Most of the BSD license variants (maybe "many" not "most", I haven't counted them ) are compatible with GPL so the BSD-licensed code can be returned to the GPL project assuming there isn't a project-specific rule prohibiting it. As an example, most of the graphics driver code in the Linux kernel is X11 licensed.

He means the other way around. If someone writes a GPL patch downstream for a BSD project (used by a larger GPL project), you cannot upstream the patch anymore to the BSD one.

[blackiwid]

I don't see it as a black-and-white solution. If your livelihood relies on you earning an income from writing code, then it's going to be quite difficult to justify open-sourcing it. Some people may also be forbidden from open-sourcing code or using the GPL in certain corporate environments.

One thing to note with the GPL is that it doesn't prevent "leeching" either. If you take source code licensed under the GPL and don't distribute the modified versions, then you don't have to give anything back.

http://www.gnu.org/licenses/gpl-faq....alDistribution

If this is applying to a large firm and they feel their software gives them a competitive advantage, then they won't give away anything anyway.

That is in theory right, in practise I dont think many company spend so much money to fork projects what you say. Because the upstream project will most likely make many changes and they will be very often incompatible to the changes so they have high maintaining and backporting costs. And on top of that even if they make more changes than upstream, most of the time they fork it, if the original author cant keep up with the patches he get sended. you have free workers maybe so you have at least guaranteed also disadvantages if you dont share it, and you cant sell it to somebody else. so at least the disadvantages are higher than with a forked bsd programm.

And even if that happens where is the problem, most likely its not about the competitor advantage in most cases its about the effort and that its very special customisations that without more work nobody else could make much use of it.

But 1. you cant just steal the work of people like with wine and cedega put some small % of effort on top of that and give nothing back, and you cant force antifeatures on the people, vendor lockins or other even more nasty antifeatures that are most of the time also secret. So at least you enpower not people to damage 3. people.

Its a bit like if producing weapons is moralicly ok, most people that work in that sector with big paychecks will say of course, and yes of course you can use a war weapon for policework or for shooting animals for eating. But if you only want to do moralicly good stuff, gpl dont hinder you to do that, and if not I am happy that it hinders you to do evil stuff.

[bridgman]

He means the other way around. If someone writes a GPL patch downstream for a BSD project (used by a larger GPL project), you cannot upstream the patch anymore to the BSD one.

Ahh, OK. Yes, if an explicitly GPL-licensed patch is added to a downstream copy of BSD-licensed code then that patch would not be able to go back upstream.

In that case my disagreement with MoonMoon's original post is only that it implied GPL-licensed patches to downstream copies of BSD-licensed code were the common (or only) practice, whereas I'm saying that while examples exist AFAIK those cases are the exception not the norm.

[MoonMoon]

Ahh, OK. Yes, if an explicitly GPL-licensed patch is added to a downstream copy of BSD-licensed code then that patch would not be able to go back upstream.

In that case my disagreement with MoonMoon's original post is only that it implied GPL-licensed patches to downstream copies of BSD-licensed code were the common (or only) practice, whereas I'm saying that while examples exist AFAIK those cases are the exception not the norm.

Even if it is not the norm, I would think that it is quite a contradiction that you intentionally have to not use the license that so many people think (or at least are claiming in this and similar threads) is all about contributing code back and not being a leech, so that in reality you actually can contribute code back and aren't a leech. This makes it pretty clear that the GPL is far from being as ideal as its proponents often claim. In fact, it shows that the GPL really only works as intended in a world where no other licenses exist. From this one could conclude that at least one goal of the GPL (and with it the FSF) is to eliminate the freedom of developers to choose a license for their work as they see fit.
It is hard to imagine a higher form of leeching.

[KernelPanic]

Using the Linux kernel as an example, if I submit changes to an X11-licensed file (or add files to a folder where all the existing files are X11-licensed) then I expect those changes to be subject to the terms of the X11 license as well. Otherwise I would effectively be submitting a GPL-licensed change in the middle of an X11-licensed file/folder, which would normally be rejected by the subsystem maintainer.

Ideally, that's how it would work. But what can happen is this:

• Programmer A releases code under a permissive license. We'll use X11 as the example.
• Programmer B takes the code and incorporates it into his project.
• Programmer B makes changes to the code, but releases the changes to the GPL. There are ways to do this.
• Programmer A can't incorporate changes unless he also uses the GPL.

As far as I know, the only way for both sides to be happy is for Programmer B to dual-license the changes. Otherwise, nothing can be contributed back.

[Luke_Wolf]

Ahh, OK. Yes, if an explicitly GPL-licensed patch is added to a downstream copy of BSD-licensed code then that patch would not be able to go back upstream.

In that case my disagreement with MoonMoon's original post is only that it implied GPL-licensed patches to downstream copies of BSD-licensed code were the common (or only) practice, whereas I'm saying that while examples exist AFAIK those cases are the exception not the norm.

Unfortunately hostile forks are things even with large high profile projects.
ex.:

http://www.libreoffice.org/about-us/licenses/

The saddest part though is the copyleft fanboys who will then go and rationalize this away as okay, under the premise that "if proprietary software can do it why shouldn't we?", while not realizing that they're being hypocritical about their "share alike" ideal by sharing in an asymmetric fashion where the author cannot take the changes back. Of course this angers the permissive people because if you're going to share code, then share it... don't be an ass.

[ssokolow]

Unfortunately hostile forks are things even with large high profile projects.
ex.:

http://www.libreoffice.org/about-us/licenses/

The saddest part though is the copyleft fanboys who will then go and rationalize this away as okay, under the premise that "if proprietary software can do it why shouldn't we?", while not realizing that they're being hypocritical about their "share alike" ideal by sharing in an asymmetric fashion where the author cannot take the changes back. Of course this angers the permissive people because if you're going to share code, then share it... don't be an ass.

It's a bit more complicated than that:

1. Sun bought StarOffice and open-sourced it while still selling a StarOffice-branded version as a value-add (similar to Mozilla Suite and Netscape 6.0+).

2. The project had a lot of bureaucratic hoops for outside contributors and patches backlogged so much that a project named Go-OO started up as a downstream similar to wine-staging. (And that's what Linux distros generally packaged)

3. IBM decided to base their closed-source Lotus Symphony office suite on OpenOffice.org, starting with version 3.0.

4. Oracle bought Sun and tried to throw their weight around. It was the straw that broke the camel's back. (this is no surprise at all, given Oracle's nature. To quote the talk I linked, "don't fall into the trap of anthropomorphizing Larry Ellison")

5. All the outside contributors moved to the Go-OO project and renamed it LibreOffice.

6. Because the experience with Oracle left them with a bad taste in their mouth, they decided that they didn't want Oracle to just be able to merge their changes back in for free.

7. As a result of the exodus, LibreOffice didn't have to decide whether to keep following OpenOffice.org as their upstream because Oracle decided to fire the handful of remaining developers.

8. Two months later, IBM convinced Oracle to give the OpenOffice name to the Apache foundation in the hopes that they could bring the development back to the now-stagnating Apache-licensed codebase upon which their closed source Lotus Symphony product had been free-riding.

9. The Apache foundation accepted and kept developing it, but the LibreOffice people saw no reason to go to a huge effort to get sign-offs from all of the contributors in order to change the license to something that would only help IBM's closed-source product.

10. Roughly half a year later (January 2012), IBM admitted defeat and donated the Lotus Symphony code to the Apache OpenOffice project.

Here's a chart which visualizes that heredity.