[dragonwriter]

> To be clear, your saying that my worry was inaccurate and one person including GPL code into a new, released version of a proprietary app doesn't require the whole, linked source of that app be released under GPL?

If the inclusion suffices to make the app as a whole a derivative work under copyright law (the FSF has a particular opinion on linking, but that opinion is not included in the license), then it would require you to offer the app under the GPL, failure to do so would be a violation of the GPL.

There is nothing "virus-like" here. The license doesn't attach without your knowledge. You may face consequences for the breach if you don't comply with the GPL terms, and releasing the whole work under the GPL may be the most convenient way of dealing with that -- then again, it may not.

[nickpsecurity]

"The license doesn't attach without your knowledge."

It does if one person on a large team did it without others' knowledge. This doesn't occur for most, non-copyleft code. At that point, if it's a derivative work, then your codebase looses its value as it gets GPL'd just because GPL'd code touched it. Preventing that outcome would require both preventative methods and constant vigilance.

Kind of like avoiding getting sick from a virus and spreading it everywhere.

Note: A former Microsoft employee told me in a prior discussion they identified this exact risk and took steps to prevent it. I never knew if it was paranoia or what could legally happen. Interesting to find last year that my hypothetical scenario actually played out to a degree in FOSS's arch-rival of that period.

[dragonwriter]

> > The license doesn't attach without your knowledge.

> It does if one person on a large team did it without others' knowledge.

No, the license never attaches to your code without a positive decision on your part to offer your code under the license.

Now, if someone does something that makes the code legally a derivative work of GPL code without knowledge of the person releasing the code, the obligation to release the code under the GPL or not at all may be created and breached without knowledge of the person doing the release, but the license still has not attached to your code.

When the breach is detected, you may decide that the best way to deal with the breach is to offer the code under the GPL.

> This doesn't occur for most, non-copyleft code.

Any code, under any license with any obligations attached to redistribution of derivative works -- or which simply prohibits redistributing such works -- can create unexpected breaches when someone includes them in a work without knowledge of the person responsible for the release; copyleft licenses are not at all special in this regard.

> At that point, if it's a derivative work, then your codebase looses its value as it gets GPL'd just because GPL'd code touched it.

No, again, your code base only becomes GPL because you choose to offer it under the GPL. IIRC, the few GPL violation cases (in the US, at least) that have gone to court and not been settled have resulted in fines and injunctions on distributing the GPL-dependent software.

> Note: A former Microsoft employee told me in a prior discussion they identified this exact risk and took steps to prevent it. I never knew if it was paranoia or what could legally happen. Interesting to find last year that my hypothetical scenario actually played out to a degree in FOSS's arch-rival of that period.

The description of the GPL as "viral" was central to Microsoft's PR effort against Free Software in general and Linux in particular.

So, its not really surprising to hear that from that source.

[nickpsecurity]

"the obligation to release the code under the GPL or not at all may be created and breached without knowledge of the person doing the release, but the license still has not attached to your code."

This is the specific concern. The name of the license isn't what people call a virus: it's the obligation it attaches to things.

"copyleft licenses are not at all special in this regard."

Damage to most copyright violations is usually a fine/settlement, publishing source of the component (not app), removal, and so on. Not an obligation to loose one's own I.P. entirely. How many common licenses that cut/pasted code or included libraries might be affected by require redistribution of the application's source in full once it gets in a release? I thought it was a non-zero amount that was pretty low for most sources. Whereas, bumbling around on a site with GPL stuff drives it up singificantly specifically due to copyleft.

" the few GPL violation cases (in the US, at least) that have gone to court and not been settled have resulted in fines and injunctions on distributing the GPL-dependent software."

Now we're talking the actual results. The virus metaphor could be dropped if it was clear that this was the worst thing that could happen and that component would just have to be dropped/replaced with non-GPL stuff. Them doing it that way is certainly reassuring. Trick is, could they instead force app using it to go GPL? Guess it hinges on enforceability of that obligation.

"The description of the GPL as "viral" was central to Microsoft's PR effort against Free Software in general and Linux in particular. So, its not really surprising to hear that from that source."

From an ex-employee mocking that source's stance on GPL as paranoid, to be clear. Not surprising, though.

[dragonwriter]

> Damage to most copyright violations is usually a fine/settlement, publishing source of the component (not app), removal, and so on.

Legal damage from GPL violations is generally fine and injunction against further release of the software with the GPL-bound components; release of application code under the GPL is typically something that happens, if at all, in a settlement, because the copyright owner would rather do that than pay damages and restructure the software not to depend on the GPL-bound component.

[nickpsecurity]

Good distinction. So, potentially a virus in theory in certain situations but rarely in practice. Might drop the label in the future.