Subject: Mixing GPL and BSD licenses

From: [email-masked]
Date: Wed, 16 Nov 2005 13:19:33 -0500

Simon Josefsson writes:

> Ok.  Mixing GPL licensed code and BSD licensed code is perfectly
> legal, and is done in many large GPL projects (e.g., the Linux
> kernel).
> 
> Derivative works of the combined BSD+GPL work will have to follow the
> terms in both licenses, of course.  You can't combine something and
> only follow the license for one piece of the work.

The important case for IETF is derivative works of the IETF work alone
(BSD-licensed in the above discussion).  This was Bill Sommerfeld's
original second point:

> 2) any or all of a derivative spec must be fair game for inclusion
> in a future IETF spec.

I agree with Bill that this is important.

If an RFC extract is placed under GPL, and then modified under the GPL,
the result is not "fair game for inclusion in a future IETF spec" because
the IETF is not going to be able to place GPL (or similar) conditions
on RFCs, and tracking down the original authors of the modifications
to obtain permission outside the GPL is not a sure thing.  That's still
a potential problem even if the authors can be located and are willing
- see the example I posted earlier where the lawyers got in the way.

To achieve the "fair game" goal, something like the following should
work;
- All RFC extracts are licensed under an IETF license (perhaps a
	modified version of BSD) that grants the IETF permission to use
	any modifications in the IETF's standards processes without
	further conditions/permissions/restrictions/etc.
- The IETF license would prohibit use of licenses on RFC extracts that
	would impair that grant of permission to use modifications.  GPL
	is an example of a license that would impair that grant, it
	appears to be necessary to prohibit placing RFC extracts under
	GPL - this avoids the modifications being only GPL-licensed, and
	hence not "fair game" for the IETF to use.

Note that the latter prohibition is only a prohibition on placing text
that invokes GPL or similar license terms in a file containing an RFC
extract - it does not (and had better not) prohibit combination of that
file with GPL-licensed files and distributing the result under GPL.

This approach may require isolation of RFC extracts into separate source
files (e.g., put the ASN.1 in a separate file that is IETF-licensed) in
order to avoid mixing RFC extracts with GPL-licensed code (#include and
the like are your friends ...).  The combination of the RFC extracts and
GPL-licensed code would only be distributable under the GPL, but the
modified RFC extract file could be put into an Internet-Draft without
having to deal with the GPL's terms and conditions.

While not what might be wanted in a perfect world, this doesn't look
like a particularly burdensome inconvenience.  It also has the benefit
of clearly separating modifications to RFC extracts that the IETF may
want back from related source code and the like that the IETF is
probably not interested in.

Does this sort of approach appear to be workable?

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2005 17:53:16 -0500

>>>>> "Black" == Black David <[email-masked]> writes:

    >> 2) any or all of a derivative spec must be fair game for
    >> inclusion in a future IETF spec.

    Black> I agree with Bill that this is important.

And it is also GPL incompatible.
At least for source code in RFCs, I think GPL compatible is far more important.

For proes text in RFCs I could live with GPL incompatible as you
describe below.

    Black> If an RFC extract is placed under GPL, and then modified
    Black> under the GPL, the result is not "fair game for inclusion
    Black> in a future IETF spec" because the IETF is not going to be
    Black> able to place GPL (or similar) conditions on RFCs, and
    Black> tracking down the original authors of the modifications to
    Black> obtain permission outside the GPL is not a sure thing.
    Black> That's still a potential problem even if the authors can be
    Black> located and are willing - see the example I posted earlier
    Black> where the lawyers got in the way.

Agreed.

    Black> To achieve the "fair game" goal, something like the
    Black> following should work; - All RFC extracts are licensed
    Black> under an IETF license (perhaps a modified version of BSD)
    Black> that grants the IETF permission to use any modifications in
    Black> the IETF's standards processes without further
    Black> conditions/permissions/restrictions/etc.  - The IETF
    Black> license would prohibit use of licenses on RFC extracts that
    Black> would impair that grant of permission to use modifications.
    Black> GPL is an example of a license that would impair that
    Black> grant, it appears to be necessary to prohibit placing RFC
    Black> extracts under GPL - this avoids the modifications being
    Black> only GPL-licensed, and hence not "fair game" for the IETF
    Black> to use.

It's important to note that when a combined work including both GPL
and BSD content is distributed under the GPL, the entire work is
considered a GPL licensed work.

If you pull out the BSD bits, those may be distributed under the BSD
license.  However if someone goes and modifies the BSD bits, the
modifications may happen to be only GPL licensed.

Quoting the GPL version 2:

    2. You may modify your copy or copies of the Program or any portion
    of it, thus forming a work based on the Program, and copy and
    distribute such modifications or work under the terms of Section 1
    above, provided that you also meet all of these conditions:

        a) You must cause the modified files to carry prominent notices
            stating that you changed the files and the date of any change.

                b) You must cause any work that you distribute or publish, that in
                    whole or in part contains or is derived from the Program or any
                        part thereof, to be licensed as a whole at no charge to all third
                            parties under the terms of this License.

Where this license is the GPL, not some combined license.

[. . .]

     7. If, as a consequence of a court judgment or allegation of patent
     infringement or for any other reason (not limited to patent issues),
     conditions are imposed on you (whether by court order, agreement or
     otherwise) that contradict the conditions of this License, they do not
     excuse you from the conditions of this License.  If you cannot
     distribute so as to satisfy simultaneously your obligations under this
     License and any other pertinent obligations, then as a consequence you
     may not distribute the Program at all.  For example, if a patent
     license would not permit royalty-free redistribution of the Program by
     all those who receive copies directly or indirectly through you, then
     the only way you could satisfy both it and this License would be to
     refrain entirely from distribution of the Program.

So, if the IETF license prevents you from distributing the work as a
whole under the GPL, then you may not distribute at all.  All the
obvious loopholes such as definition of the work/program are covered
reasonably.

I strongly believe that at least for source code, MIBs, ASN.1 modules,
header files, tables and other code-like things in RFCs, GPL
compatibility is a must.

Imagine situations we can get into if we don't meet that goal.  We
might have a complex algorithm for some important transport behavior
and yet be unable to use that code in the Linux kernel.  Sorry, but I
don't see how any need expressed so far in this discussion trumps the
need of real vendors to be able to use our specifications to produce
running code.

We can go tell the world not to use the GPL.  They cannot and will not
listen to us: important sections of the vendor community we must at
least consider are forced to use the GPL.  

--Sam

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 17 Nov 2005 01:03:05 +0100

> I agree with Bill that this is important.

I'm not sure I think it is that important.

What problem do you see if we don't make sure the IETF will have this
right?

Remember, the IETF is not googling around for useful improvements to
their work, rather they publish what we as a community bring to the
IETF.  If someone doesn't bring their derived work back to the IETF,
then that's their problem and they can't leverage the expertise and
influence that the IETF community has.  If the modification is useful,
other vendors will eventually adopt it, and sooner or later it will be
standardized through the IETF because someone believe it would
contribute to a better Internet.  If the modified work cannot be used
in that process, it will be rewritten.  There are no losses here, as
far as I can see.

> if an RFC extract is placed under GPL, and then modified under the GPL,

Here's a thought experiment: why can't the IETF use GPL for the
license?  That would solve Bill and my problems.  The IETF would be
able to fold back changes made by others, since everyone who
distribute a modification must make it available through the original
license, which would permit the IETF to use it.

One answer is that the BSD community couldn't use the RFCs, but if
Bill insists that the IETF must have the right to modified IETF works,
I don't see how that would be compatible with the BSD license.  The
BSD license permit closed-source modified works derived from BSD
licensed works.

> Does this sort of approach appear to be workable?

I'll have to think about this more.  I think we are moving into a
completely new phase of the discussions here.  I'm not yet convinced
that Bill's desired wish to make the IETF able to use any IETF-derived
work is useful.  As far as I can see, it would generate problems for
the BSD community.

Thanks,
Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Nov 2005 21:56:04 -0500

I must be missing something.

The point of IETF RFCs is to promote internet interoperability.
If changes are made to RFCs that are
a) incompatible
b) can not be folded into future RFCs
it does not appear to me that this is to the benefit of internet 
interoperability.
So why should the IETF want that?

Yours,
Joel M. Halpern

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2005 21:58:35 -0500

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:

    Joel> I have to disagree.  The primary purpose of IETF RFCs is to
    Joel> drive interoperable implementations of useful protocols.

I agree that's the primary purpose of IETf specifications.

When we include source code, MIBs, header files, tables etc in our
specs it is typically because we believe that by using these parts of
our specs people are more likely to produce interoperable
implementations.

So our interests are best served by making the tables, code etc
available to implementers in a form they can use.

For example let's say that we only made our specifications available
as postscript.  There's a time when that probably would have been
acceptable for the proes content of our specs.  However it is not easy
to cut and paste from postscript.  We would clearly be advancing the
IETF's primary mission by making the code available as text as well as
postscript even if that made it easier for people to modify.

Similarly GPL implementations are enough of a reality that our primary
mission is served more by making the code and text available in a way
that is useful for GPL implementations than it is by restricting
modifications.

If you don't believe GPL implementations are a reality our give you
 information on that.  If you don't believe that the sort of
 restrictions you are talking about would make code in RFCS useless to
 GPL implementers, please talk to your favorite lawyer.  I've
 explained why this is true and if you don't agree with my explanation
 it would come down to a matter of license interpretation.

Now, as it happens, I do believe that our primary and secondary goals
are better served by allowing people to create derivatives of our
specifications than by preventing them from documenting the protocols
they deploy.  Briefly preventing someone from specifying protocol
modifications does not prevent them from modifying the protocol, it
just prevents interoperability.  Even if we don't see the document and
cannot use the changes, the goal of interoperable protocols on the
Internet is better served by allowing people to document what they do.
I've discussed various ways we can prevent people from distributing
modified specifications as our specifications.

--Sam

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Nov 2005 22:14:51 -0500

[Sorry, two slightly different versions of my email went out due to 
problems with my client.]

I agree that open source implementations (including GPL implementations) of 
our protocols are an important and beneficial set of implementations.

However, there is nothing legal that stops someone from writing something 
for which different conditions apply to different parts of the content.

I am not asking that implementors who make changes be forced to send us 
their changes.
However, having changes that we CAN NOT include seems a drawback.  It 
reduces interoperability rather than improves it.
In fact, if changes are that important, and if GPL implementations are that 
important, then the conclusion would be that standards that can be 
implemented by commercial implementors are ineffective.  That is not a view 
I share.

One thing to remember about standards is that their benefit is not in their 
perfection.  They are not perfect.  They need to be good.  But more 
importantly, they need to be agreed and widely implemented.

I have no problem encouraging lab experimentation.  That does not require 
GPL on the RFC extract.
I have no problem with folks who use the extracts needing to make changes 
for compilers, or even to fix bugs.  That does not require GPL on the RFC 
extract.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2005 22:46:12 -0500

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:

    Joel> [Sorry, two slightly different versions of my email went out
    Joel> due to problems with my client.]

    Joel> I agree that open source implementations (including GPL
    Joel> implementations) of our protocols are an important and
    Joel> beneficial set of implementations.

    Joel> However, there is nothing legal that stops someone from
    Joel> writing something for which different conditions apply to
    Joel> different parts of the content.

This statement is false if part of the content is GPLed.  That is
exactly why the RFC extracts need to be GPL compatible: if they cannot
be distributed under the terms of the GPL then a work containing RFC
extracts and GPL content cannot be distributed at all.

    Joel> I am not asking that implementors who make changes be forced
    Joel> to send us their changes.  However, having changes that we
    Joel> CAN NOT include seems a drawback.  It reduces
    Joel> interoperability rather than improves it.  In fact, if
    Joel> changes are that important, and if GPL implementations are
    Joel> that important, then the conclusion would be that standards
    Joel> that can be implemented by commercial implementors are
    Joel> ineffective.  That is not a view I share.

I don't follow this paragraph at all.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2005 23:02:17 -0500

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:

    Joel> I must be missing something.  The point of IETF RFCs is to
    Joel> promote internet interoperability.  If changes are made to
    Joel> RFCs that are a) incompatible b) can not be folded into
    Joel> future RFCs it does not appear to me that this is to the
    Joel> benefit of internet interoperability.  So why should the
    Joel> IETF want that?

A large vendor makes incompatible changes to an important ietf
protocol.  They have a lot of market share.

Which world serves the Internet better?

A) The vendor cannot easily document their changes so they do not.

B) The vendor can publish a clearly labeled and modified RFC that
documents their change.  They don't want the IETF to pick uptthe text
they wrote--after all they paid expensive tech writers to write that
text--but they'd be happy to let the world know what the change is.

In the second world the Internet is a better place.

It's important to distinguish the IETF from the Internet.  Our primary
goal is not to improve the interoperability of IETF protocols: it is
to improve interoperability of Internet protocolls.  There are many
cases where that primary goal implies improving IETF protocols and
encouraging people to work within the IETF.  However if we can choose
between documentation outside the IETF and no documentation we should
choose documentation outside the IETF.

--Sam

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Nov 2005 23:32:19 -0500

Actually, I would be perfectly happy to insist that to the degree they 
publish the changes we have the right to incorporate them into future 
RFCs.  (Note, I am talking here about changes to the underlying protocol, 
not extensions.  Extensions don't have this problem.)

I am not asking that we treat corporations better than we treat open source 
developers.  Both are important.

In your other reply, you state that anything published with a GPL is fully 
covered in its entirety by the GPL.
That is clearly true if all that is included is the GPL.
However, if the author chooses, they can write things so that there are 
differences.

Yes, the IETF is obliged to try to work with open source developers.  But 
that is a two way street.

Yours,
Joel M. Halpern

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2005 23:52:55 -0500

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:

    Joel> In your other reply, you state that anything published with
    Joel> a GPL is fully covered in its entirety by the GPL.  That is
    Joel> clearly true if all that is included is the GPL.  However,
    Joel> if the author chooses, they can write things so that there
    Joel> are differences.

No, it's simply true.  If there is any code there at all in the entire
  project that is under the GPL, then I must be able to make a
  GPL-only modification to any part of the project at all.  That's how
  the GPL works; if you don't believe me go read the GPL FAQ or talk
  to a lawyer.  (I'd be happy to try and work through in detail why
  this is the case, but it would probably not help you if you won't
  accept the assertion).

So, you're asking open-source developers to give up the entire body of
GPL-only work.

consider for example if you wanted to add one small excerpt that was
under a license that required the IETF to be able to take
modifications to the Linux kernel .  That would require contacting
every copyright holder in Linux--everyone listed in the credits
file--and getting their permission.

Putting it mildly,  asking for that is asking for a lot more than "working with us."

Also, remember that the IETF has no control over what protocols we
implement.  Anyone who wants to can modify our protocols.  All we can
do is stop them from using our words in their attempt to document
their modifications.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Nov 2005 21:23:12 -0500

I have to disagree.
The primary purpose of IETF RFCs is to drive interoperable implementations 
of useful protocols.
Random incompatible changes to RFC based implementations do not in and of 
themselves help that goal.
Incompatible changes which improve the protocol and get published as 
revisions to the standard can be argued to help the goal.

Why is it in the interest of internet interoperability for the IETF to 
support incompatible changes taht can not be made available to commercial 
and non-commercial implementors by way of the RFC series?

Yours,
Joel M. Halpern