![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
At 10:02 AM -0700 10/24/07, Lawrence Rosen wrote:Ted Hardie wrote:The point being, of course, that there is a world of difference between "many" and "all" here. If there is no development community using the GPL in an area, forcing the IPR restrictions to meet a GPL test may hinder development rather than enhance it, especially in cases where the only requirement in a license is to request it. For many development communities, that is not an issue since it requires no monetary outlay.Will you please stop talking about GPL as if it is the only open source license relevant here!
Sorry, but the context in this part of the thread was specific to the GPL. To refresh your memory on the bits the Brian, Norbert, and Scott put forward that set that context:
Norbert wrote: How about: 'Should be possible to implement without having to ask for permission or pay a fee'?Brian replied: That will never fly. For good reason, many patent holders insist on reciprocity conditions, and that seems to require an explicit request and acknowledgement.Scott add: And that will never fly (IANAL) with the GPL and so here we sit at an impasse again. So either a GPL implementation is important to interoperability in a given space or it is not. If it is important to interoperabilty, then this is a showstopper. If not, maybe not.
Hope that helps restore context for you.
My concern is that *all* free and open source licensors be able to implement IETF specifications without patent encumbrances. And *all* proprietary licensors too, for that matter. There ought to be no "GPL test" for IETF specifications, other than that our specifications be implementable and distributable under the GPL *and any other* license.
The world as it is now simply does include licenses that aren't compatible. As Brian pointed out, reciprocity conditions are common, as are requests to acknowledge. If Scott is right and these won't work with the GPL, working groups will have choices to make about the implementation and deployment communities' needs. This is why we keep pushing the decision into the working groups, rather than making a priori IPR choices: it's the place most likely to know whether a reciprocal license/royalty-bearing license/piece of GPL'ed code in the standards document is actually likely to cause a problem. regards, Ted
I think this completes the thread of argument. As long as some open source licenses contain language that asserts that the code is not encumbered by additional patent licensing requirements, *and* there is no change in the legal and economic reasons for companies to insist on reciprocity and acknowledgement even for RF licenses, we (the IETF) simply cannot find a better compromise than deciding case by case.
I do like Sam's suggestion of giving the availability of free software weight in the Proposed Standard decision, but that is not a discontinuity in IETF practice.
Brian
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.