Hacker News Reader

Comment by wcoenen | Hacker News Reader

To me this illustrates that if you want to ensure that improvements to your code are shared back, you'd better use the AGPL license (http://www.gnu.org/licenses/agpl.html) instead of GPL.

Quote from the AGPL preamble:

It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.

edit: according to a comment below, Google is already sharing their improvements without being obliged to do so. Nice! You can't always count on goodwill though, so my point stands.

View on HN

Chris Dibona has already co-ordinated the release of Google's patches to the FFmpeg community.

On the other hand, many companies avoid using AGPL code altogether. Code that isn't used can't be improved.

If they avoid it, it's because they are not ready to share the code. Thus their using the code is pretty much useless in the first place...

There are two kinds of enhancements to consider: Enhancements that are specific to your product and enhancements that are general to the library you're incorporating.

If Rails had been AGPL, every single webapp based on Rails would have to have its source code released. Now, Rails is not AGPL, does that mean that anybody using Rails (and not making their entire project open source) are "useless"? The vibrancy of the Rails community seems to disagree with that assessment.

> If Rails had been AGPL, every single webapp based on Rails would have to have its source code released.

Platforms are a special case, where it is usually desirable to distinguish between the platform itself and stuff on top of it. That's why we have the classpath exception for Java: http://en.wikipedia.org/wiki/Classpath_exception#The_classpa...

I'd argue that ffmpeg belongs to the platform in a YouTube like usage scenario. Compare with ActiveRecord in Rails: Everything single thing your apps does depends heavily on it, yet, it's still just a piece of infrastructure.

It boils down to interpretation of what constitutes a "derivative product". I think it would be better if whoever used Rails and made changes to Active Record _had_ to share these changes (a-la AGPL), without having to share the app they built on top.

Similarly, it's better if ffmpeg users who offer a service based on ffmpeg were required by the license to share their ffmpeg modifications (the way Google already does without being required to) without a need to share the rest of the webapp.

> I think it would be better if whoever used Rails and made changes to Active Record[...]

But doesn't it at this point boil down to an academic argument? Surely Rails benefits massively from being popular, and draconian (which I consider AGPL) licenses might hamper its popularity. I doubt that Rails misses out on significant contributions just because they are not required. Contributing to open source looks good on a CV/employer branding page.

> If they avoid it, it's because they are not ready to share the code.

Maybe they only can or want to share some of the code, not all of it. The AGPL prevents this.

That's the same argument people make against the GPL for normal desktop apps. And yet, GPLed software has been quite successful.

Google won't touch or integrate anything that is GPL licensed into their own products - especially AGPL. the linux kernel in android is the only GPL code you will find from Google, and even then they got a lot of criticism from FSF folks for deciding to license modules under a more liberal license

So if you are a developer and want to see your own library and code used by corporates such as Google and many others, a more liberal license is the only way to go.

If it is a javascript library or a web application, again, a more liberal license is the way to go since the FSF insist that a script include means your entire app must be GPL.

Using copyright law to force corporations and developers to become contributors and active participants in your software project is, to me, a ridiculous notion.

It seems like a personal choice to me. If you want companies to use your code internally, and are okay with the fact that they might make improvements that they don't release back (or think that voluntary releases will be sufficient), then GPL or BSD/MIT is fine. If you don't want to allow for proprietary forks of stuff used in webapp backends, then AGPL is a better choice. If you have a different set of preferences about how people use your code than either of those, you can keep it proprietary and just negotiate custom licenses with potential users.

AGPL seems like a particularly reasonable choice if you're running a SaaS and want to release your code, but also want to make sure no competitor can use your code as a starting point from which to leapfrog you without releasing the improvements back for your own use. That's the approach gitorious takes, for example. Of course, the other way to keep competitors from leapfrogging you with your own code is not to release it at all, or release it with a proprietary license--- the approach github and Dropbox and many other SaaS take. From that perspective, AGPL is at least more liberal a license than the "no code release" license.

> Google won't touch or integrate anything that is GPL licensed into their own products

ffmpeg is GPL, and it is being used in youtube. Isn't that the story here?

> Using copyright law to force corporations and developers to become contributors and active participants in your software project is, to me, a ridiculous notion.

So the fact that so many companies contribute to the Linux kernel has nothing to do with its GPL license?

Without the GPL there would be a "tragedy of the commons" situation: it would be best for the common good to share and avoid duplicated efforts, but it would be advantageous for individual companies to use the code but not share their improvements. The GPL fixes that by enforcing cooperation.

FFmpeg can also be compiled with an LGPL license so it can be linked in commercial products.

Also executing an external GPL library/binary from a commercial product (no direct linking) is not in direct contradiction with GPL terms (although it's a gray area where most companies would probably not want to go).

Can you elaborate on the gray area bit?

See the GPL FAQ http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

The last paragraph describe the gray area; i.e. if a proprietary program depends on- and combine a GPL program to perform its functionality it can be argued that the two parts are a combined work and hence the whole work must be licensed under the GPL.

> Using copyright law to force corporations and developers to become contributors and active participants in your software project is, to me, a ridiculous notion.

I don't really understand this sentence. No one is forcing anyone to do anything. There is code, and it has a license, and if you don't like the terms of the license, you don't use the code. Is it also ridiculous that that most software/movie/music/book creators use copyright law to "force" consumers to pay for their output?

This is absurd. We use Mercurial and Dulwich code in the project hosting site, and those are both GPL. We're very careful about where we allow GPL'd code, but we do use it quite a bit. Obviously, we're more paranoid about AGPL, but that's really a different license because of the extra restrictions.

Reply on news.ycombinator.com