conducting a sane and efficient GPLv3, LGPLv3 Review

Wilson, Andrew andrew.wilson at intel.com
Wed Aug 1 07:38:18 UTC 2007


 
Staying strictly on-topic here, I believe that the final GPL/LGPLv3
both meet the OSD.  Earlier drafts did not because of the prohibition
against applying GPLv3 to implementations of DRM or to any SW which
could
be used to violate a user's privacy.  Whatever FSF intended to
accomplish with these provisions, they did discriminate against entire
classes 
of applications; however, they are now gone.

You could argue that the requirement to provide "installation
information"
and to make covered code user-replaceable in a consumer product
discriminates against the class of applications which, by government
regulation,
cannot be modified on a device by end users.  Poster child: modifying SW
to exceed
the maximum allowed transmit power in a radio.  However, FSF could then
point to the "ROM exception," which artfully allows GPL/LGPLv3 to
be applied to such applications if they are embodied in ROM and
neither the end user nor the manufacturer or service provider has
technical means to modify code in the device.  So, the "installation
information" provision tests the boundaries of OSD but (IMO) does
not cross them.  I personally believe these licenses should be approved
by OSI.

[now veering slightly off topic]
There is the written OSD, and the so far uncodified, anti-license
proliferation agenda which OSI has nonetheless pursued for the last
several
years.  OSI has pursued this agenda because subdividing the world of
free/open source software along the lines of incompatible variant
licenses
amounts to fencing off the commons.  Compatibility matters, because
incompatibility dilutes the basic power of the free/open source concept
and its ability to create a software commons.

If we learn nothing else from the recent exchange between John
and myself, we learn that compatibility between GPL/LGPLv3 and previous
versions contains several areas which are unclear at best, and where
long-time active contributors to this list can draw sharply differing
conclusions.  As noted above, I think it's proper for the OSI board
to approve the licenses, but it would also be proper for OSI to request
that FSF, as GPL license stewards (a) provide more clarity on
compatibility
guidelines, and (b) where there is room for interpretation or
clarification,
to err on the side of interpretation or clarification
which increases rather than decreases compatibility with existing GPL
code.

Andy Wilson
Intel open source technology center



More information about the License-discuss mailing list