For Approval: GPLv3
chris at metatrontech.com
Thu Aug 16 02:05:25 UTC 2007
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 171 bytes
Desc: not available
More information about the License-discuss