Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think they mean is that the GPL can restrict the ways developers can combine various components. Ultimately software is developed for users, and if developers can't build software for their users, then the license can become a problem.


Sony, Nintendo (and others) solved this by running the said applications externally.

For example a Sony or Nintendo SDK would have the gcc compilers, linkers, bintools, etc, and they would distribute the source... Yet nothing stops them from writing pre-linker, post-linker, pre-compiler, post-compiler steps that would be required by the developer to get called (or get called automatically by a tool).

In such case you mix well GNU (GPL) with closed commercial software, and distribute the end product just fine.


You have to be extremely careful in a mixed license setup. Lots of folks make the mistake of linking to GPL'd libraries, thinking it's like the LGPL.

But yeah, external calls seem to be the safest bet right now, even if it isn't always the most optimal solution.

(e.g. you can often use GPL'd components by writing a server wrapper around them and communicating from your non-GPL code via network communications for example, an arbitrary, and silly distinction from just linking in the components and using message passing, but hey...apparently that's what freedom (as in free, not as in beer) is all about).


Also the different version of the GPL are incompatible with each other. For example, you cannot distribute combinations of GPLv2 and GPLv3 works. The recommended way to deal with this is to add the optional (but not default) "or any later version". Then the user can promote the license to be compatible. e.g. GPLv2+ is compatible with GPLv3.


Does that apply to executables? For example package with GPL2 and GPL3 executables?

(But even if it does, nothing stops you from splitting the package in two, and providing two packages, rather than one).


I think you're describing aggregation which the GPL does not consider a derived work. Mere use of a GPL-licensed executable does not extend the GPLs terms to what you are doing (e.g. shell scripts, system() calls, etc). For each binary, the license terms of each statically or dynamically linked component must be simultaneously satisfied. The GPL includes a "system library" exception that excludes libraries shipped with the OS from that calculus.

The situation with combining interpreter code that doesn't access compiled libraries (e.g. pure octave M-files, or python code) isn't really clear to me. The FSF's opinion has been that a script that uses GPL'd interpreter code is subject to the terms of the GPL. I personally accept that interpretation out of deference to the FSF, but I've never understood specifically how that conclusion arises from the text of the GPL.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: