Subject: Re: Mixing GPL and BSD licenses

From: [email-masked]
Date: Wed, 16 Nov 2005 18:29:26 +0000

David 
isnt the real issue that the materials may not be relicensed in any form that violates the original licensing? That simply meas that the material once licensed may not have the licensing terms re-negotiated or changed after the release occurs. No matter what use models it is licensed for. Any other set of constriants abandons the protection if an individual can republish the IP under a new set of controls which may or may not take into account the previous set.

Todd 
 -------------- Original message ----------------------
From: [email-masked]
> 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

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

---

From: [email-masked]
Date: Wed, 16 Nov 2005 13:49:34 -0500

Todd,

> isnt the real issue that the materials may not be relicensed 
> in any form that violates the original licensing? That simply 
> meas that the material once licensed may not have the 
> licensing terms re-negotiated or changed after the release 
> occurs. No matter what use models it is licensed for. Any 
> other set of constriants abandons the protection if an 
> individual can republish the IP under a new set of controls 
> which may or may not take into account the previous set.

Not exactly.  The problem is not relicensing of the original
materials, but rather license terms for modifications.

An example of a problem scenario is:
- IETF publishes an RFC under IETF-license.  Anyone can use
	the RFC under IETF-license no matter what.
- Programmer <A> makes an RFC extract from the RFC and places
	that extract under GPL-license in addition to IETF-license.
	At this point, the IETF can still get the RFC extract
	back under IETF-license because it's unchanged from
	the original RFC (and hence GPL-license's additional
	restrictions have no impact).
- Programmers <B>, <C>, and <D> make interesting modifications
	to the RFC extract.
- IETF wants the modified RFC extract because the modifications
	are interesting ... But in contrast to the original RFC
	extract, the modifications require the GPL-license that
	IETF can't accept.
The IETF-license will need to prevent this.

Thanks,
--David

---

From: [email-masked]
Date: Wed, 16 Nov 2005 21:19:42 +0000

D-Man 

 -------------- Original message ----------------------
> Todd,
> 
> > isn't the real issue that the materials may not be relicensed 
> > means that the material once licensed may not have the 
> > other set of constraints abandons the protection if an 

You mean under what terms derivatives of any variety can be produced then right?

> 	the RFC under IETF-license no matter what.

OK - seems reasonable as long as the IETF protects its IP otherwise it loses the rights to that IP...

> 	restrictions have no impact).

Actually unless there is language in the license so that the derivative can have its own licensing terms separate from those of the precursory IP they do - because there is nothing in the licensing agreement's language today to accept a second licensing model. 

In fact there is nothing in any of the use models that allows for a second set of legal controls to invalidate or change the original controls placed on the IP as source material, no matter what it is used for including advertisement on toilet paper. Seriously ...

> 	extract, the modifications require the GPL-license that

So then this is just a statement "that the revisions or derivatives would also belong to the IETF" which effectively prevents any commercial products that would have IP protection of their own from being developed with these core precursory components.

> The IETF-license will need to prevent this.

Agreed, but what about the private use model as well, where the derivative is not something that the creator wanted to secede back into the IETF???

---

From: [email-masked]
Date: Wed, 16 Nov 2005 19:47:43 -0500

Sam,

> >>>>> "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 prose text in RFCs I could live with GPL incompatible as you
> describe below.

We're in violent agreement on goals and priorities:
- GPL compatibility of "source code" is more important than IETF's
	ability to use modifications if we have to choose
- RFC prose should be GPL-compatible if it's possible to do so and
	grant IETF rights to use modifications to that prose.

I need to talk to some legal experts off-line about what's possible
and how to do it, as I've already run into one piece of the GPL
that does not mean what I thought it appeared to say <example
omitted to avoid a tangential discussion>.

Thanks,
--David

---

From: [email-masked]
Date: Thu, 17 Nov 2005 00:40:58 -0500

> Would it be
> reasonable to allow GPL on Internet-Drafts submitted with the "may
> only publish as a Internet-Draft" boilerplate? (i.e., if any of
> the I-D text is GPL-licensed, then the I-D MUST carry the "may
> only publish as an Internet-Draft" boilerplate).  

Never mind, this doesn't work, as the "may only publish as an
Internet-Draft"
boilerplate restricts what can be done with the GPL-licensed text
in a fashion not allowed by the GPL.  Sorry for the intrusion, --David

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Black, David
> Sent: Wednesday, November 16, 2005 11:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Mixing GPL and BSD licenses
> 
> Sam,
> 
> > 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 
> up the 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.
> 
> And it's even better if the modified RFC is submitted to the IETF
> as a "may only publish as an Internet-Draft" Internet-Draft as that
> brings the changes to the attention of the IETF experts on the
> protocol that the vendor modified.
> 
> Flipping this back over to open source, it raises an interesting
> question.  I hope it's clear to everyone that GPL on RFCs (at least
> for standards-track RFCs) is not a good idea because it can have
> the effect of preventing use of RFC extracts by exactly the sort
> of large vendors Sam envisions in his example.  Would it be
> reasonable to allow GPL on Internet-Drafts submitted with the "may
> only publish as a Internet-Draft" boilerplate? (i.e., if any of
> the I-D text is GPL-licensed, then the I-D MUST carry the "may
> only publish as an Internet-Draft" boilerplate).  This entails
> some procedural changes that would have to be worked out.
> 
> That initially looks like a bizarre combination (expansive GPL
> combined with restrictive I-D boilerplate), but it appears to
> have the potential to allow the IETF to receive Internet-Drafts
> documenting protocol changes made in open source projects that
> use GPL without having to obtain any additional copyright
> grants from the open source contributors, and in a fashion that
> can erect a strong procedural barrier to keep GPL-licensed text
> out of (at least standards-track) RFCs.  Today,  I believe GPL-
> licensed text cannot be put in an Internet-Draft, because the
> IETF cannot accept GPL conditions on an I-D as IETF processes
> currently stand.
> 
> Thanks,
> --David

---

From: [email-masked]
Date: Thu, 17 Nov 2005 14:29:59 +0000

Joel

 -------------- Original message ----------------------
From: "Joel M. Halpern" <[email-masked]>
> 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?

Then let me ask this - why would there be any need to specifically note or deal with IP rights? The idea of 'incompatible' changes is wrong I think. It isnt relevent - the IETF by its very charter MUST allow players to build derivatives of IETF protocols, and for those that build proprietary ones or that use IPR such that they need to be disclosed, those have as much 'right' to be inside the IETF system as those that dont... 

> 
> Yours,
> Joel M. Halpern
> 
> At 05:53 PM 11/16/2005, Sam Hartman wrote: