For Approval: GPLv3

[Chris Travers]

Ok. so to summarize what I see you saying:

Statutory and administrative regulations are not really relevant to the 
question of whether a license meets the OSD.  Thus we don't concern 
ourselves with whether software licenses intentionally or otherwise 
prohibit their own use in fields of endeavor where there are specific 
and legitimate regulatory requirements.

If that is the position of the OSI, fair enough and that is clear.  I 
just think that it is good to have a clear position.

Just a few corrections to your points below....

Michael Tiemann wrote:
>
>
>
> I think you have this backward: if  the software is distributed in 
> ROM, some requirements do not apply.  I am not a lawyer, but if 
> something does not apply, it's not a provision, but the opposite.
I think we are talking past eachother and share the same interpretation 
of the GPL v3.

<snip>[re distribution of, say, nVidia drivers on same media as Linux 
kernel posing GPL problem]
>
> IANAL, but I don't believe such distribution transforms somebody's 
> proprietary blob into a derived work.  The reason that Fedora (a 
> free/open source Linux distribution) doesn't distribute proprietary 
> drivers is not because of the derivative work problem (which I don't 
> think you have proved is a real problem), but because their commitment 
> to 100% pure free/open source is not met by shipping proprietary 
> codes.  There are vendors out there who *do* ship proprietary drivers 
> with their Linux distribution, and I don't believe they are violating 
> the GPL.  They *are* violating what it means to be 100% pure, but 
> that's a marketing decision, not a legal one.
I think you misunderstand me.  It is not that the proprietary blob 
becomes derived, but rather that the combination of the non-derived 
proprietary blob and the GPL software in combination with the bridge may 
(particularly under the GPL v2) might be considered to be a "new" work 
as a whole (beyond mere aggregation) derived from both and thus 
*preclude* the distribution of closed source drivers on the same 
installation media, particularly, if the product as sold requires both.

This is not entirely a moot point.  I know that Debian has refused to 
distribute at least one plugin for FreeRadius because of the concern 
that this plugin linked to a library (libpq) which often linked (and of 
which the Debian package linked to) OpenSSL (a non-compatible license).  
The concern was that this put Debian in a problem that did not exist for 
the original developers.

However, one can build a case in the GPL v3 that only libraries which 
are *required* by one's software are covered by the work relating to the 
"source code" requirements.  This is weaker in copyleft terms than the 
GPL v2 which left it up to the courts to draw the line but is more 
definite.  Hence optional libraries in downstream dependencies shouldn't 
pose a problem for distributors.  As I said, this is a step in the right 
direction.

Best Wishes,
Chris Travers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chris.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20070815/17c3cc82/attachment.vcf>