[tsimionescu]

If you want to distribute binaries or code based on the (A)GPLv3, or use them to serve content over the wire, you have to distribute the source code of the entire software project under the (A)GPLv3. If part of that software is proprietary and licensed in such a way that you can't or won't distribute its code under the (A)GPLv3 or a compatible license, then you can't use any of the (A)GPLv3 code at all.

Now, there is some unclear legality around the distribution of plug-ins to a standalone software package. Are you allowed to distribute a GPLv3 plug-in to a proprietary program, like a GPLv3 plugin for Visual Studio? Maybe. Are you allowed to sell a proprietary plug-in for a GPLv3 software, like a paid plug-in to Emacs? Again, maybe.

However, the chances for both go down significantly if the "plug-in" is distributed by the same company as the software itself, and if the plugin is critical to major functionality of that software.

[liamgm]

From i read that not "plugin"/module problem but library problem , difference is a lot. It's okay to depend on propietary library but not ok for propietary "plugin"/module.

Apple also doing this for their fork of CrossOver's Wine GPL called Game Porting Toolkit, composed by Wine + propietary D3DMetal DirectX library

[em-bee]

are you referring to the exception for proprietary libraries that are part of the operating system? an exception that is needed because otherwise it would be impossible to build GPL software for non-free operating systems.

wine is under the LGPL which allows linking to any non-free libraries as long as those libraries are available in a form that allows relinking to a changed version of the application.