For Approval: GPLv3

[Rick Moen]

Quoting Chris Travers (chris@...):

> I see a number of possible issues with the GPL v3. [...]

[you cite OSD#6]

> I think that the anti-Tivoization provision in the GPL v3 effectively
> prevent its use (or at best are not technology-neutral regarding its
> use) in areas such as, say, WIFI card firmware, or the like where the
> hardware/software package is subject to sufficient regulation as to
> prevent the user from being able to make arbitrary modifications ot the
> code and still run it on that specific piece of hardware.

My understanding is that this is not what OSD#6 concerns.  OSD#6
essentially says you cannot have OSI cerify a licence that selectively
withholds necessary rights for left-handed Esperanto teachers, or
members of the military, or professional clowns, etc.

I thus don't think "the profession of locking people out of the ability
to run modified software on particular pieces of hardware" is among the
sorts of fields of endeavour OSI has in mind.

[you cite OSD#9]

> I suspect there are *cases* where the GPL (both versions 2 and 3) fail
> in this regard, particularly where works which might be considered
> separate when distributed separately might be considered the same work
> when distributed together. I don't see this as an obstacle, but want to
> mention it anyway. See below.

My understanding is that this is not what OSD#9 concerns.  OSD#9
essentially says that a qualifying licence must not ban the presence of
other software in its vicinity _merely_ because it's in the vicinity.
If one piece of software is legally derivitive of the other, then it's
simple reality that you may have licence-compatibility issues.  OSD#9
cannot change that reality, and does not purport to do so.

[you cite OSD#10]

> There are GPL v3 provisions which are predicated on the distribution of
> software in restricted environments being limited to ROMs.

My understanding is that this is not what OSD#10 concerns.  OSD#10
essentially says that a qualifying licence must not be tied
irretrievably from, or be barred from, particular technological
developments or interface styles, e.g., it cannot require that all
derivatives of a Web application also be a Web application.

[Chris Travers]

Rick Moen wrote:
> My understanding is that this is not what OSD#6 concerns.  OSD#6
> essentially says you cannot have OSI cerify a licence that selectively
> withholds necessary rights for left-handed Esperanto teachers, or
> members of the military, or professional clowns, etc.
>  
Ok, the legitimate question is-- does de facto discrimination count?  If
it does, then this is a violation of the definition.  If not, you are right.

If de facto descrimination does not count, then it may be possible to
include restriction in a license which are designed to preclude fields
of endeavor without naming them, as I believe the GPL v3 does (with
regard to DRM-centric applications).

In short "you may not implement DRM" might not be acceptable, but if you
effectively forbid the implementation of DRM using other clauses, does
this make it OK on a technicality?

I mention DRM because I believe that it is the FSF's intended target and
WIFI firmware/voting machines are just collateral damage.

So, in the above case, where do you draw the line?  I think the only
sensible line that can be drawn is to forbid de facto discrimination
against fields of endeavor whatever they are and however they are
defined.  And yes, this should include WIFI card firmware and voting
machines even if this was not the intended target of the provision.

> I thus don't think "the profession of locking people out of the ability
> to run modified software on particular pieces of hardware" is among the
> sorts of fields of endeavour OSI has in mind.
>  
Ok, but does it apply to hardware/software packages which must be
licensed as a whole from the government, such as WIFI cards and their
firmware?

My largest concern is simply OSD part 6, that it creates a system which
is discriminatory against any package which must be certified on both
the hardware and software level.  This includes WIFI cards and voting
machines and effectively prevents any GPL v3 code from being used in any
field where the government has a compelling interest in regulating this
component.  These include products which interface with the public
airwaves and products, such as voting machines, where there is a
compelling interest on the part of one government to regulate other
governments within its jurisdiction, such as with regard to voting machines.

If the FSF had included a clause stating that "Code from covered works
can only be included in user devices interfacing with public airwaves if
that is on a ROM" then that might be a definite violation of this
definition, would it not?  Yet, I do not believe there is any case where
such a clause would have made *any practical change to the license at
all.*  That is why I am saying this is entirely implied.

[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Chris Travers]

Just to be clear---

my concern is that we have to decide where exactly to draw the line wrt
discrimination against fields of endeavor.  Either we take the line that
"if the license does not explicitly name any such fields, then it is not
discriminatory" or we take the line that "discrimination may be
explicitly state or implied, or simply collateral damage of the license."

If we take the former case here and approve the GPL v3 without
specifying exactly what this means *now* then we will have a harder time
when someone wants to take it further and we will be stuck with a "don't
ask, don't tell" policy on this portion of the OSD.

In short if the GPL v3 is approved, I think it is *absolutely mandatory*
that this section be clarified not only in rationale but as to where the
line is actually drawn, and whether exceptions are going to be made
allowing discrimination of certain fields of endeavor such as DRM.

If we are going to do this, let us at least *try* to contain the erosion
:-).

Best Wishes,
Chris Travers

[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Michael Tiemann-2]

On 8/15/07, Chris Travers <chris@...> wrote:

I guess I sent my concerns some time before I was actually subscribed.
If they come through separately, I appologize for the re-post.

I see a number of possible issues with the GPL v3. I will list them with
the sections of the OSD here:

It is good to use the OSD  in your analysis, because that is the one relevant reference.

6: No discrimination against fields of endeavor:
The license must not restrict anyone from making use of the program in a
specific field of endeavor. For example, it may not restrict the program
from being used in a business, or from being used for genetic research.

I think that the anti-Tivoization provision in the GPL v3 effectively
prevent its use (or at best are not technology-neutral regarding its
use) in areas such as, say, WIFI card firmware, or the like where the
hardware/software package is subject to sufficient regulation as to
prevent the user from being able to make arbitrary modifications ot the
code and still run it on that specific piece of hardware.

I don't accept this logic.  In my view it's not the GPLv3 that's restricting the field of endeavor.  There's a wholly separate regulatory regime that does or does not permit the operation of certain devices in certain environments.  The OSD focuses on what the license does or does not allow, not what unrelated governing law does or does not allow.  Last time I checked, it's not legal to construct an operable nuclear warhead in the US, but that prohibition does not invalidate any OSI-approved license that might cover software capable of triggering such a device.

9: License must not restrict other software
The license must not place restrictions on other software that is
distributed along with the licensed software. For example, the license
must not insist that all other programs distributed on the same medium
must be open-source software.

I suspect there are *cases* where the GPL (both versions 2 and 3) fail
in this regard, particularly where works which might be considered
separate when distributed separately might be considered the same work
when distributed together. I don't see this as an obstacle, but want to
mention it anyway. See below.

I did see below, and my analsys is that modifyable software shipped with hardware does not make hardware a derived work of the software, and so I think your concern is moot.  I elaborate below...

10: License must be technology-neutral
No provision of the license may be predicated on any individual
technology or style of interface.

There are GPL v3 provisions which are predicated on the distribution of
software in restricted environments being limited to ROMs.

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.

Further Discussion and Recommendations:

OSD Sections 6 and 10 vs the anti-Tivoization provisions in the GPL v3.
The GPL v3 added provisions which require one who conveys GPL v3
software with a user product (such as a Tivo) to provide installation
instructions sufficient to get user-modified software running on the
system. The direct target of this change was Tivo, but the larger
concern appears to be the interplay between software and hardware. In
essence the GPL v3 requires that these are treated as entirely separate
goods unless the software is distributed via a method whereby nobody has
the ability to change it (for example, a ROM). The intent was to prevent
GPL v3 software from being used in unTrustworthy Computing platforms in
a way which were not fully usable when the source was changed by the end
user.

From above: I would construe this differently.  I would say that the requirement to supply sufficient instructions ensures that users are not denied the freedoms that a vendor might enjoy.  To the extent the vendor has the ability to modify the software, the user should have the same rights, and those rights should not be obscured by technical obscurity/interference.  To the extent that the vendor has no ability to change software on a device they supply, the are not liable to provide the user with any such ability, either.  Thus, this is a question of symmetry of rights.

The relevant section of the license is: [...]


As a side effect, this effectively bans the use of GPL v3 code in any
device which requires government certification of the hardware/software
package (such as a WIFI card and related firmware). It could also
prohibit use of GPL v3 software in voting machines in that it would be
illegal for the counties that use the machines (and hence distribute the
software) to prohibit modifications of the software through technical or
legal means. In fact the only option open in these cases is to remove
the ability to do any vendor updates (including security updates) from
the products in question and hence take on a substantial competitive
handicap.

If your interpretation were correct, which I do not think it is, then one positive effect of the GPLv3 (but also the GPLv2) that it would provide standing to people to sue the government to allow people to modify such software.  This would benefit society because often bugs are found via stress-testing and whitebox testing.  A law prohibiting any modification of software on voting machines would make it impossible for independent audit of the machines, which can lead to abuse.  But the more relevant question is: how does this violate the OSD...I do not see how.

I would recommend that the FSF drop the questionable provision before
this is adopted. It violates either portion 6 or 10 of the OSD by my
reading, depending on how I read the OSD and the GPL v3.

I do not agree.

As for OSD section 9: There are cases where the GPL, versions 2 and 3
may affect other software on the same media even when it might not were
they separate.

Please provide an example.  I know of none such.

IANAL, but I see a few cases where this could happen. I will draw
parallels between existing cases in the GPL v2 in this section, however.

For code to fall under the GPL licensing requirements when linking to a
GPL application, it would need to be either a) derivative of that GPL
application or b) part of the same "covered work." If neither of these
apply, then the GPL licensing requirements don't apply either.

So far I'm with you (meaning I agree that it's possible for code to be linked but not have the GPL provisions apply--your third case).

For example, ndiswrapper provides, under a GPL-compatible license, a way
of linking NDIS Windows drivers (closed source) to the GPL v2-licensed
Linux kernel. I do not believe that this is a GPL violation when the
Windows drivers are distributed separately because they are not
derivative of the Linux kernel nor are they by any reasonable measure
part of the same work just (being independantly written and distributed).

Therefore, they are not a derived work.

A similar case I believe exists with regard to the nVidia closed source
drivers for Linux. Again, the proprietary code is non-derivative, a
compatibly-licensed bridge exists, and the software is distributed
seprately. (This same argument might *not* apply to the Apple ObjC
plugins for the GCC because it is not clear to me that these were
written for another environment and that a compatibly licensed bridge
existed.)

However, what happens now when I pre-install those same nVidia or wifi
drivers on a Linux-based laptop that I sell? Can it then be argued that
I am, in distributing both the closed source and open source packages
together essentially creating a new "covered work" based on the "Linux
kernel" but that license incompatibilities forbid me from distributing
it? In short, there are cases where mere aggregation *may* under the GNU
GPL (versions 2 or 3) create new covered works which hold a distributor
liable for copyright infringement even when the original developers are not.

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.

However, the fact is, the GNU GPL v2 has been accepted as an
OSI-compatible license for some time and the GNU GPL defines source code
and covered work a little more tightly than does the GPL v2. Therefore
the GPL v3 is an improvement in this case and I believe it would be
inconsistant of this organization to let this specific problem (of OSD
part 9) get in the way of approval. I would therefore hope the OSI would:

1) State specifically that definition 9 does not apply to cases where
these problems only exist in corner cases.

It's not our position to render legal advice like this.  Only a lawyer can do that. We can say what we believe the OSD requires or does not require, but we cannot speak to the legal behavior of a license in an as-yet unknown corner case.

2) Thank the FSF for helping to reduce the impact of this problem in
version 3 of this license.

I certainly would like to see the Board do this.

I would therefore suggest that we consider either clarifying why the GPL
does not erode or volate OSD sections 6 and 10, or ask that they drop
the anti-Tivoization clauses prior to approval.

Hopefully I have clarified why I think the GPLv3 fits within OSD 6 and 10.

Best WIshes,
Chris Travers

Thanks for submitting a detailed opinion.  Though I did not agree with some of your points, I applaud your effort to write it out and engage with us.

M

[Michael Tiemann-2]

On 8/15/07, Chris Travers <chris@...> wrote:

Rick Moen wrote:
> My understanding is that this is not what OSD#6 concerns.  OSD#6
> essentially says you cannot have OSI cerify a licence that selectively
> withholds necessary rights for left-handed Esperanto teachers, or
> members of the military, or professional clowns, etc.
>
Ok, the legitimate question is-- does de facto discrimination count?  If
it does, then this is a violation of the definition.  If not, you are right.

If de facto descrimination does not count, then it may be possible to
include restriction in a license which are designed to preclude fields
of endeavor without naming them, as I believe the GPL v3 does (with
regard to DRM-centric applications).

In short "you may not implement DRM" might not be acceptable, but if you
effectively forbid the implementation of DRM using other clauses, does
this make it OK on a technicality?

Some OSI licenses effectively forbid the assertion of patents against users of the software.  That's fine and dandy. I believe that effectively forbidding the prohibition of user modification is similarly fine and dandy, and consistent with the larger movement (certainly of free software, to some extent, open source as well).

I mention DRM because I believe that it is the FSF's intended target and
WIFI firmware/voting machines are just collateral damage.

So, in the above case, where do you draw the line?  I think the only
sensible line that can be drawn is to forbid de facto discrimination
against fields of endeavor whatever they are and however they are
defined.  And yes, this should include WIFI card firmware and voting
machines even if this was not the intended target of the provision.

As I argued in my previous email, I do not believe that GPLv3 forbids your other two examples, so I cannot agree that it de facto prohibits them.  This shows why it's wrong to draw the line at a presumed de facto position, and instead stick to what is expressly prohibited and to judge whether that's against a field of endeavor or not.

M

[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

[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Lasse Reichstein Nielsen-2]

On Thu, 16 Aug 2007 03:19:14 +0200, Chris Travers <chris@...>  
wrote:

> Ok, but does it apply to hardware/software packages which must be
> licensed as a whole from the government, such as WIFI cards and their
> firmware?

Law can change.

The license itself does not preclude the use of the software in WIFI cards
or firmware. There might currently be law, in some contries, that makes it
impossible to both comply with the license and with the law at the same  
time.

Whether a license complies with the OSD should be decided only from what
the license says, not what restrictions are introdued by arbitrary  
countries'
current laws. Laws can change, in both directions. If having a law,  
somewhere,
that makes some software uses incompatible with the license also makes the  
license
non-OSD, then it would be necessary to revoke the OSI certification when  
law
changes for the worse.

OSD compliance cannot be prevented by incompatible law.
If the Liberated State of Antarctica one day proclaims a law that requires
all software must be distributed under the, very restrictive, LSA License,
then no license would be OSD compliant any more.

> My largest concern is simply OSD part 6, that it creates a system which
> is discriminatory against any package which must be certified on both
> the hardware and software level.

That's not af field of endeavor. It's a use of the software that is  
restricted
by law, and it's not the license that restricts it, it's the law.
The license is fine.

/L
--
Lasse R. Nielsen - atwork@...
  'Faith without judgement merely degrades the spirit divine'
  Reproduction of this message, or parts thereof, is allowed if proper  
attribution is given.

[Rick Moen]

Quoting Chris Travers (chris@...):

> my concern is that we have to decide where exactly to draw the line wrt
> discrimination against fields of endeavor.  Either we take the line that
> "if the license does not explicitly name any such fields, then it is not
> discriminatory" or we take the line that "discrimination may be
> explicitly state or implied, or simply collateral damage of the license."

Once again, I, for one, don't accept your fundamental assumption that
"the profession of locking people out of the ability to run modified
software on particular pieces of hardware" qualifies as "a field of
endeavour" within the meaning of OSD#6.

Which means that the question of where to draw lines _among_ fields of
endeavour, if at all, does not arise.

[Chris Travers]

There is one more possibility I have found as I have re-evaluated
whether or not my objections were valid.  I have concluded that despite
Rick's mischaracterization of my argument, they are not but that there
is one other possible issue with use of GPL v3 software (and this
concern was raised to some extent on debian-legal a while back as well).

At the moment, despite this concern, I would suggest that we approve.

7b of the GPL v3 states that one may require the preservation of
reasonable legal notices.  Debian has raised the concern that
"reasonable" is not defined anywhere.  A legal notice might be required
as part of the code of the software (perhaps as compiler warnings
stating that running the modified code on the supplied hardware would be
a violation of federal law unless appropriate licenses were issued by
the FCC,   Such notices could become quite long and if required outside
of comments (i.e. as compiler warnings or textual notices in the code)
could render portions of the code effectivly invariant.

Due to concerns such as these,. Debian treats the GPL v3 as a
"case-by-case" license which may meet conditions similar to the OSD or
not depending on the specific work.  I don't know whether the OSI sees
the line as "all works under this license meet the definition," or "some
works under this license meet the definition."  If the latter, then we
should approve.  If the former, we need to think about whether an
invarient section of code disseminating a (potentially long) legal
notice violates the OSD.

Ok, I am willing to accept Michael's position that legislative
regulations are outside the bounds of these discussions, and hence the
GPL v3 is OK.  However, I think that you are misrepresenting what I have
said.

I would also point out that I did a little more digging and discovered
that Debian considers the GPL v3 to be a license which may or may not
(depending on use of optional terms) violate the Debian Free Software
Guidelines.  Since the DFSG are the basis for the OSD, this may lead
people to conclude that the use of the GPL v3 does not guarantee meeting
the OSD either but neither does it preclude it.

On 8/16/07, *Rick Moen* <rick@...> wrote:


    Once again, I, for one, don't accept your fundamental assumption that
    "the profession of locking people out of the ability to run modified
    software on particular pieces of hardware" qualifies as "a field of
    endeavour" within the meaning of OSD#6.

    Which means that the question of where to draw lines _among_ fields of
    endeavour, if at all, does not arise.



The "fields of endeavor" that I was talking about were firmware for
FCC-regulated equipment, voting machines, and the like.  The basic
argument is that if you cannot abide by both the laws and the terms of
the license, you cannot use the code.  This therefore discriminates
against *any field of endeavor* where the government has a compelling
interest in regulating the software/hardware package as a whole
including areas which:

1)  interface with public airwaves
2)  must maintain integrity relating to public service functions (such
as voting machines) etc.

Once again, I am willing to accept Michael's view that the combination
of government regulation *and* license terms do not constitute a problem
for part 6 of the OSD where the license *alone* does not enforce such
discrimination, but I reject your view that the field of endeavor that I
was concerned about was as you categorize.

BTW, I have come to agree with Michael on this and would further suggest
that the voting machine issue is not valid because agreements which
provide for, say, processing and acceptance of data from software
operated by a third party are outside the scope of the GPL v3.  I.e. a
State is perfectly within their rights to tell Counties that the GPL
permissions *may not be used* for any model of voting machine where the
county wants the votes to count.

Furthermore, with the FCC's permission, long, invarient legal notices
could be included in GPL code warning the individual compiling them of
dire consequences of actually installing the software without a
license.  These could perhaps include code which output the legal notice
as compiler warnings, in help files, or elsewhere.  Thus although a
large percentage of the source might not be freely editable under the
GPL, the practical components would be, so "code relating to 7b legal
notices" should also fall outside the OSD.

[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Rick Moen]

Quoting Chris Travers (chris@...):

> 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) [...]

I think there may be some confusion, here.

Derivative work is a term of art in copyright law.  GPLv[23] cannot
regulate the scope of copyright coverage (that being defined by law),
and can only embody the licensor's conditions for third parties'
creation and distribution of whatever the _law_ judges to be derivative
works.

Thus, if a proprietary blob is implemented with a driver in a fashion
that's alleged to violate the copyright of the driver's (or OS's)
copyright owners, then that is a judicable question of fact that in the
USA would be settled using the conceptual test the 2nd Circuit developed
in CAI v.  Altai.

The above is true regardless of the licensing, and without regard to
whether the code in question is stored in a software blob or inside a
firmware ROM -- and it has nothing whatsoever to do with whether
particular license are OSD-compliant or not.

OSI doesn't exist to fix people's licence-compatibility problems
(though OSI and participating commentators may give tips on that
matter), nor to fix their software-packaging problems.  It just
certifies software licences as OSD-compliant or not.

[Rick Moen]

Quoting Chris Travers (chris@...):

> 7b of the GPL v3 states that one may require the preservation of
> reasonable legal notices.  Debian has raised the concern that
> "reasonable" is not defined anywhere.

By "Debian", I assume you mean "unnamed parties who have opined on the
matter to the open, unmoderated mailing list debian-legal".  As a
Debian-using sysadmin, I always appreciate people not confusing the
distribution as a whole with (in particular) some of the wilder
commentators on that list.

The cited objection by "Debian" is pretty ridiculous.  If they don't
like the fact that a Turing machine cannot be set up to decide what is a
"reasonable" notice requirement, then they're going to really hate the
rest of the world's legal systems, where the reasonable man standard is
widely used.

Fortunately, the perspective-challenged opinion of some unnamed party on
debian-legal need not detain us, here.

> Due to concerns such as these,. Debian treats the GPL v3 as a
> "case-by-case" license which may meet conditions similar to the OSD or
> not depending on the specific work.

Actually, individual Debian _developers_, with theoretical intervention
by the ftp-masters and any NMUs, treat GPLv3-covered packages on a
case-by-case basis -- absent a passed General Resolution, decision of
the DPL, unchallenged decision of the Project Secretary, unchallenged
decision of various Deputies, or unchallenged decision of the Technical
Committee.  Neither the debian-legal mailing list as a whole nor any
individal poster to that rather motley public mailing list has more than
an advisory role.

> However, I think that you are misrepresenting what I have said.

To err is human.  Please feel welcome to clarify, if that seems
warranted.

> I would also point out that I did a little more digging and discovered
> that Debian considers the GPL v3 to be a license which may or may not
> (depending on use of optional terms) violate the Debian Free Software
> Guidelines.

I believe you mean "unnamed posters to the open and unmoderated
debian-legal mailing list feel this way".

> The "fields of endeavor" that I was talking about were firmware for
> FCC-regulated equipment, voting machines, and the like.

To reiterate:  those are not fields of endeavour.

> The basic argument is that if you cannot abide by both the laws and
> the terms of the license, you cannot use the code.  

To reiterate:  that is always and everywhere the case, and always has
been.  OSI's mission does not include fixing people's
licence-compatibility, legal compliance, or software-packaging problems.

 
> Once again, I am willing to accept Michael's view that the combination
> of government regulation *and* license terms do not constitute a problem
> for part 6 of the OSD where the license *alone* does not enforce such
> discrimination, but I reject your view that the field of endeavor that I
> was concerned about was as you categorize.

I agree with Michael's statement, and reiterate my simple observation
that you did not cite a field of endeavour within the meaning of OSD#6.

[Chris Travers]

Just a quick summary here first:

I have withdrawn my objection to approval.  I think we should approve
the GPL v3.

THere are corner cases that I think GPL-users (any version) should be
aware of but this is not OSI's job.  Most of the rest of this email is
aimed at discussion of these topics already underway on this thread.

Furthermore, in cases of using GPL v3 code with voting machines there
are other mechanisms otuside the GPL whcih could be used by governments
to effectively prevent alteration of software from government certified
configurations (including source code changes) which would be outside
the scope of the GPL.  Thus this is not even a de facto discrimination
against this field of endeavor.

Also, section 7b may provide a way out for those who have legal
requirements not to let modified software run on the hardware depending
on answers to the following questions:

1)  Are legal notices restricted to the comments in the code?
2)  Are legal notices restricted to communication to other people?  Can
required legal notices be used to convey legal status information to
other components (for example, fcc license information for modifications)?

A few other disagreements are mentioned below.


Rick Moen wrote:
>
> I think there may be some confusion, here.
>
> Derivative work is a term of art in copyright law.  GPLv[23] cannot
> regulate the scope of copyright coverage (that being defined by law),
> and can only embody the licensor's conditions for third parties'
> creation and distribution of whatever the _law_ judges to be derivative
> works.
>  
Agreed as far as you take it.  "The law" is sort of difficult to define
(in fact borders on being entirely meaningless) though when there is no
consideration to where a given case may be tried.  Can one even speak of
"the law" as singular in this case? IANAL though.

There is nothing that prevents the license from granting permissions
outside a narrower definition of the work as a whole or derived works
according to copyright law (and arguably the GPL v3's definition of what
parts are required to be source-accessible is narrower than it is in the
GPL v2).

The key phrase under section 1 is:
" For example, Corresponding Source includes interface definition files
associated with source files for the work, and the source code for
shared libraries and dynamically linked subprograms that the work is
specifically designed to require, such as by intimate data communication
or control flow between those subprograms and other parts of the work."

One would well conclude by the above definition that optional
dependencies need not be a part of the corresponding source.  As I say,
this is a step forward because it avoids questions like:

Can a plugin to a GPL application be distibuted if it links to a
new-BSD-licensed library which likely (but not necessarily) links to a
library with an incompatible license like OpenSSL.  In short, the GPL v3
is far weaker in terms of copyleft than the GPL v2 but this does not
impact whether OSI should approve.  In fact I would argue that the GPL
v3 poses *fewer* potential concerns than v2.

However, the GPL v3 is also incredibly vague and hard to understand in
terms of other exceptions (for example, which libraries exactly in a
Linux distribution are really parts of "major components?"  This is not
really an issue before us though.  Just something I would note for
people looking at using the GPL v3.

Since I have no doubt that a license which required that system
components directly or indirectly linked with the code be under
compatible licenses would probably meet the OSD, this really is not an
issue.
> Thus, if a proprietary blob is implemented with a driver in a fashion
> that's alleged to violate the copyright of the driver's (or OS's)
> copyright owners, then that is a judicable question of fact that in the
> USA would be settled using the conceptual test the 2nd Circuit developed
> in CAI v.  Altai.
>  
But that specific test only affects people in the second circuit.  I
believe the 9th Circuit has a different one from the Gates Rubber
case).  Potentially these tests could result in different opinions, in
which case the meaning of the GPL depends on who is making allegations
against whom, whether declaratory judgement is sought, etc. and it
becomes one big game.  One issue I have with the GPL in general (again
not in the scope of whether or not to approve) is that there is no
possibility to control jurisdiction, so it is impossible for anyone to
know whether a specified activity will be a problem in terms of
copyright law or not (this is true even within the US, and is far worse
internationally).  I think however that although the GPL v3 is weaker in
terms of copyleft, it does help to define some of the
jurisdiction-dependant cases so that this is not as much of an issue.

I would even argue that the proprietary blob issue you mention would be
almost certainly allowed by the GPL v3 (definition of corresponding
source does *not* include the proprietary blob provided it is
redistributable as a proprietary blob because it is an optional
dependency, and is not itself derivative), but almost certainly
justiceable under GPL v2 (IANAL though).

In short what I am saying about the GPL v3 is that some potential issues
with the GPL v2 have been solved (or replaced with other problems, such
as long, invariant sections of code that spit out legal notices as
compiler warnings under section 7b).

[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Rick Moen]

Quoting Chris Travers (chris@...):
> Rick Moen wrote:

> >Derivative work is a term of art in copyright law.  GPLv[23] cannot
> >regulate the scope of copyright coverage (that being defined by law),
> >and can only embody the licensor's conditions for third parties'
> >creation and distribution of whatever the _law_ judges to be derivative
> >works.
> >  
> Agreed as far as you take it.  "The law" is sort of difficult to define
> (in fact borders on being entirely meaningless) though when there is no
> consideration to where a given case may be tried.

As Douglas Adams attributed to God as his final message to his
creations:  "We apologise for the inconvenience."  ;->  

I,e. it's lamentable that "the law" is difficult to define, but it is
simply a fact that law, not licensing, defines the concept of derivative
work and thus of the reach available to licences under copyright law.
Thus my point.

> Can one even speak of "the law" as singular in this case?
 
Actually, despite the admitted handicap of being a Yank, I'm aware of
the existence of diverse legal jurisdictions and endeavour to reflect
that awareness in my posts.


> There is nothing that prevents the license from granting permissions
> outside a narrower definition of the work as a whole or derived works
> according to copyright law (and arguably the GPL v3's definition of what
> parts are required to be source-accessible is narrower than it is in the
> GPL v2).

Nor did I so state.

None of the rest of your post appears to concern OSD compliance, but
rather meanders around licence compatibility and other similar concerns.
Exceptions:

> >Thus, if a proprietary blob is implemented with a driver in a fashion
> >that's alleged to violate the copyright of the driver's (or OS's)
> >copyright owners, then that is a judicable question of fact that in the
> >USA would be settled using the conceptual test the 2nd Circuit developed
> >in CAI v.  Altai.
>
> But that specific test only affects people in the second circuit.

I'm sorry, but you need to get out more.  The CAI case's abstraction,
filtration, comparison test is now applied, in copyright-infringement
cases involving software works, nationwide.

> I believe the 9th Circuit has a different one from the Gates Rubber
> case).

Gates Rubber (10th Circuit) merely further elaborated the CAI test.  I'm
not clear if there are now subtle differences among the districts
(IANAL, TINLA, YADA), but if extant they don't negate my overall point
that law, not licensing, defines the scope of derivative works, and that
the CAI test is what the courts would use in the USA.

> One issue I have with the GPL in general (again not in the scope of
> whether or not to approve) is that there is no possibility to control
> jurisdiction, so it is impossible for anyone to know whether a
> specified activity will be a problem in terms of copyright law or not
> (this is true even within the US, and is far worse internationally).

Again, this is not so much a problem with GPLv[23] as it is an inherent
one in the diversity of this planet's legal jurisdictions.  Neither FSF
nor OSD can do a great deal to address that, and it has no visible
conneciton to OSI's certification process, in any event.

[Chris Travers]

Just for the record, I withdraw any of my objections to approving the
GPL v3.

I think that the GPL v3 provides a number of potential loopholes under
section 7b which could be used to address all the issues I have riased.  
Sorry for the misunderstandings.

Best Wishes,
Chris Travers

[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Matthew Flaschen]

Chris Travers wrote:
> Just for the record, I withdraw any of my objections to approving the
> GPL v3.
>
> I think that the GPL v3 provides a number of potential loopholes under
> section 7b which could be used to address all the issues I have riased.
> Sorry for the misunderstandings.

I think 7b is best interpreted as allowing requirements to maintain
unobtrusive text (and possibly graphical) notices.  I don't see how it
could be used to bypass the language allowing user modification of GPLv3
code in User Products (when the manufacturer can), or how it affects the
scope of GPLv3's copyleft.

Matt Flaschen

[Donovan Hawkins]

On Thu, 16 Aug 2007, Chris Travers wrote:

> The "fields of endeavor" that I was talking about were firmware for
> FCC-regulated equipment, voting machines, and the like.  The basic argument
> is that if you cannot abide by both the laws and the terms of the license,
> you cannot use the code.  This therefore discriminates against *any field of
> endeavor* where the government has a compelling interest in regulating the
> software/hardware package as a whole including areas which:
>
> 1)  interface with public airwaves
> 2)  must maintain integrity relating to public service functions (such as
> voting machines) etc.

Coming from a purely technical perspective, I'm not certain you are
correct that those two fields are prevented from using GPL code.

1) I have at least two devices with open source firmware that are capable
of broadcasting over the airwaves: a Linksys WRT54GL (wifi) and a Neuros
MP3 player (FM transmitter). Both of them have 3rd-party replacement
firmware, derived from the open firmware released by the manufacturers,
which enable the user to increase the broadcast strength significantly. As
I see it, there are a few possible explanations for why this would be:

a) The manufacturer is not legally responsible for what the users do when
they modify their device, as long as the version as sold was FCC
compliant. This may require a legal notice informing the user that
certain modifications may be illegal in their country.

b) The hardware has been physically designed not to exceed FCC
regulations regardless of firmware.

c) Closed-source drivers prevent the open-source portion from exceeding
FCC regulations.

d) The manufacturers have technically violated the law and are willing to
risk any consequences.

Whatever the case, there seem to be several ways you can have open-source
firmware on an FCC-regulated device.


2) There's nothing inherently insecure about open-sourcing the software
for a voting machine...IIRC there is at least one county/state that plans
to require open-source software for all electronic voting machines
(creating quite a problem for the companies that designed their voting
solutions to run on MS Windows).

GPL v3 requires that the manufacturer of the voting machine inform the
buyer (ie the government who is holding the election) how to unlock the
voting machine and replace the software. If there is a password needed to
access it, they have to tell them what the factory default password is set
to. But there is nothing that prevents the government from changing that
password and keeping the new password a secret from the voters who use the
machine. I don't think that allowing you to vote using the government's
machine qualifies as conveying the software to the voter, so the voter has
no rights under the GPL. At best the voter might managed to get himself a
copy of the software and be entitled to learn the factory default
password.

I don't even think that Affero-style licences would be affected by this,
as long as they are well constructed. I don't think the intent of Affero
is to require site admins to give out their admin passwords.

IOW, freedom to obtain and modify your own copy of software doesn't imply
freedom to mess around with my copy running on my machine.

(note, of course, that "password" can be replaced with "any method used to
prevent access to the software")

---------------------------------------------------------------------------
Donovan Hawkins, PhD                 "The study of physics will always be
Software Engineer                     safer than biology, for while the
hawkins@...                   hazards of physics drop off as 1/r^2,
http://www.cephira.com                biological ones grow exponentially."
---------------------------------------------------------------------------

[Matthew Flaschen]

Donovan Hawkins wrote:
> d) The manufacturers have technically violated the law and are willing
> to risk any consequences.

Or, the manufacturer has technically violated the law and does not know it.

Matt Flaschen

[Richard Fontana]

Donovan Hawkins wrote:
> GPL v3 requires that the manufacturer of the voting machine inform the
> buyer (ie the government who is holding the election) how to unlock the
> voting machine and replace the software. If there is a password needed
> to access it, they have to tell them what the factory default password
> is set to. But there is nothing that prevents the government from
> changing that password and keeping the new password a secret from the
> voters who use the machine. I don't think that allowing you to vote
> using the government's machine qualifies as conveying the software to
> the voter, so the voter has no rights under the GPL.

As to voting machines, one need not even reach this issue under GPLv3.
The anti-lockdown requirements of section 6 apply to "User Products"
only, which are largely limited to "consumer products" (which uses the
Magnuson-Moss Act definition: any tangible personal property normally
used for personal, family or household purposes).  Voting machines, as
they exist today, are certainly not consumer products. Moreover, the
anti-lockdown requirements do not apply to such ephemeral forms of
propagation as granting someone brief access to use a voting machine to
vote (even if this *would* be "conveying"; under U.S. law, at least, we
are confident that it isn't).

--
Richard E. Fontana
Counsel
Software Freedom Law Center
tel. [phone]
fax  [phone]

[Smith, McCoy]

On item a) below, of interest is 47 CFR 15.15(a) & (b) (the Federal
Regulations promulgated by the FCC), which can be read here:

http://a257.g.akamaitech.net/7/257/2422/09nov20051500/edocket.access.gpo
.gov/cfr_2005/octqtr/pdf/47cfr15.15.pdf

-----Original Message-----
From: Donovan Hawkins [mailto:hawkins@...]
Sent: Thursday, August 16, 2007 6:01 PM
To: license-discuss@...
Subject: Re: For Approval: GPLv3

On Thu, 16 Aug 2007, Chris Travers wrote:

> The "fields of endeavor" that I was talking about were firmware for
> FCC-regulated equipment, voting machines, and the like.  The basic
argument
> is that if you cannot abide by both the laws and the terms of the
license,
> you cannot use the code.  This therefore discriminates against *any
field of
> endeavor* where the government has a compelling interest in regulating
the
> software/hardware package as a whole including areas which:
>
> 1)  interface with public airwaves
> 2)  must maintain integrity relating to public service functions (such
as
> voting machines) etc.

Coming from a purely technical perspective, I'm not certain you are
correct that those two fields are prevented from using GPL code.

1) I have at least two devices with open source firmware that are
capable
of broadcasting over the airwaves: a Linksys WRT54GL (wifi) and a Neuros

MP3 player (FM transmitter). Both of them have 3rd-party replacement
firmware, derived from the open firmware released by the manufacturers,
which enable the user to increase the broadcast strength significantly.
As
I see it, there are a few possible explanations for why this would be:

a) The manufacturer is not legally responsible for what the users do
when
they modify their device, as long as the version as sold was FCC
compliant. This may require a legal notice informing the user that
certain modifications may be illegal in their country.

b) The hardware has been physically designed not to exceed FCC
regulations regardless of firmware.

c) Closed-source drivers prevent the open-source portion from exceeding
FCC regulations.

d) The manufacturers have technically violated the law and are willing
to
risk any consequences.

Whatever the case, there seem to be several ways you can have
open-source
firmware on an FCC-regulated device.


2) There's nothing inherently insecure about open-sourcing the software
for a voting machine...IIRC there is at least one county/state that
plans
to require open-source software for all electronic voting machines
(creating quite a problem for the companies that designed their voting
solutions to run on MS Windows).

GPL v3 requires that the manufacturer of the voting machine inform the
buyer (ie the government who is holding the election) how to unlock the
voting machine and replace the software. If there is a password needed
to
access it, they have to tell them what the factory default password is
set
to. But there is nothing that prevents the government from changing that

password and keeping the new password a secret from the voters who use
the
machine. I don't think that allowing you to vote using the government's
machine qualifies as conveying the software to the voter, so the voter
has
no rights under the GPL. At best the voter might managed to get himself
a
copy of the software and be entitled to learn the factory default
password.

I don't even think that Affero-style licences would be affected by this,

as long as they are well constructed. I don't think the intent of Affero

is to require site admins to give out their admin passwords.

IOW, freedom to obtain and modify your own copy of software doesn't
imply
freedom to mess around with my copy running on my machine.

(note, of course, that "password" can be replaced with "any method used
to
prevent access to the software")

------------------------------------------------------------------------
---
Donovan Hawkins, PhD                 "The study of physics will always
be
Software Engineer                     safer than biology, for while the
hawkins@...                   hazards of physics drop off as
1/r^2,
http://www.cephira.com                biological ones grow
exponentially."
------------------------------------------------------------------------
---

[Chris Travers]

How many ways to say "I was wrong and I appologize?"

Richard Fontana wrote:

> Donovan Hawkins wrote:
>  
>> GPL v3 requires that the manufacturer of the voting machine inform the
>> buyer (ie the government who is holding the election) how to unlock the
>> voting machine and replace the software. If there is a password needed
>> to access it, they have to tell them what the factory default password
>> is set to. But there is nothing that prevents the government from
>> changing that password and keeping the new password a secret from the
>> voters who use the machine. I don't think that allowing you to vote
>> using the government's machine qualifies as conveying the software to
>> the voter, so the voter has no rights under the GPL.
>>    
>
> As to voting machines, one need not even reach this issue under GPLv3.
>  

Furthermore, even if one does, nothing prevents a state from conveying

such software to counties and then issuing further restrictions as a
condition for accepting the votes as valid.  Agreements relating to the
data are separate from agreements relating to the software.

I think we can all agree (including myself) that the voting machine
issue is moot.  It had been raised to me by another developer and I
posted it before I thought it through entirely.

I would hope that people don't read this license quite in the way
requiring additional rights be granted consumers as opposed to corporate
users.  That would seem to be discriminating against a class of persons
(though not a class of natural persons) and would be possible an OSD
conflict depending on how one reads the OSD (but it is still unfair to
corporate entities in that they are granted fewer rights than natural
persons).

> The anti-lockdown requirements of section 6 apply to "User Products"
> only, which are largely limited to "consumer products" (which uses the
> Magnuson-Moss Act definition: any tangible personal property normally
> used for personal, family or household purposes).  Voting machines, as
> they exist today, are certainly not consumer products. Moreover, the
> anti-lockdown requirements do not apply to such ephemeral forms of
> propagation as granting someone brief access to use a voting machine to
> vote (even if this *would* be "conveying"; under U.S. law, at least, we
> are confident that it isn't).
>  

As I say, no reading of the GPL no matter how extensive forbids further

restrictions from someone as part of an ongoing agreement relating to
services.  Since voting is a service performed by the county, using the
machines in voting could be subject to agreements outside the scope of
mere copyright.

In short, if I offer to accept ODF documents from you on condition that
you do not alter my GPL v3 word processor, that is accepted under the
GPL v3.  I just can't push that into the terms of a copyright license.  
In short other restrictions may apply provided that they are not part of
the general permission to use the software outside of other service
agreements.  I didn't think of this and I was wrong.  Clear enough? :-)


Best Wishes,
Chris Travers

[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---