Incoming - software licenses

I just sent a Last Call issue on software licenses and the
-outgoing
document, which I think is a clarification issue.  The
interaction
of software licenses and the incoming document is more
"interesting".
I should apologize in advance to Simon, as I think he's been
over this
ground in much more detail, and I have not had the time to
review
what he's done.

There should be a general goal that if incoming code has a
software
license, then that license should be consistent with the
following
provision of the outbound document:

   As such, the rough consensus is that the IETF trust is to
grant
   rights such that code components of IETF contributions
can be
   extracted, modified, and used by anyone in any way
desired.

and so use of licenses that are not consistent (e.g.,
copyleft,
patent provisions) ought to be discouraged when there's an
alternative.
When there's no alternative, things appear to get
"interesting".
Some of these licenses could prevent contribution of code to
IETF
because they restrict the copyright grant to the IETF Trust
(Section 5.3 of -incoming) in a fashion that cannot be
dealt
with by prohibiting derivative works.

Let me stop here to allow the WG chair to determine whether
discussion of the "interesting" consequences is in
scope.  At a
minimum, we probably ought to agree on goals (e.g., do we
want to
be able to accept GPL-licensed code in contributions?,
should this
be a normal or exceptional procedure?) before discussing
mechanisms
to achieve the goals.

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




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


_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

Black_Davidemc.com writes:

> There should be a general goal that if incoming code
has a software
> license, then that license should be consistent with
the following
> provision of the outbound document:
>
>    As such, the rough consensus is that the IETF trust
is to grant
>    rights such that code components of IETF
contributions can be
>    extracted, modified, and used by anyone in any way
desired.
>
> and so use of licenses that are not consistent (e.g.,
copyleft,
> patent provisions) ought to be discouraged when there's
an alternative.
> When there's no alternative, things appear to get
"interesting".
> Some of these licenses could prevent contribution of
code to IETF
> because they restrict the copyright grant to the IETF
Trust
> (Section 5.3 of -incoming) in a fashion that cannot be
dealt
> with by prohibiting derivative works.

I agree that when there isn't an alternative available, it
gets
"interesting".  I believe most practical
situations will be in that
interesting area too.  The LGPL code in the Base64 document
is an
example, and the many third-party code in various RFCs are
others.

However, I challenge that it is simple to solve this when
there is an
alternative.  The problem is: Who will decide that something
is an
alternative or not?  For anything that is non-trivial, each
alternative
solution will have various advantages and disadvantages.  It
is rare
that you will find two solutions to the same problem with
the exact same
properties.

Going back to the Base64 example.  There are Base64 code
available under
more permissive licenses than the LGPL.  However, all of the
about 10
such examples that I found and reviwed (before writing my
own) turned
out not to follow the recommendations in the RFC, or have
other
disadvantages.  Some believed they were
"alternatives", but I did not
(and I could point to some section of the RFC).  Deciding
who is right
in that situation is difficult.

My point is that any rule written for the situation when an
"alternative" exists will be difficult to apply in
the real world,
because the problem is in deciding what an
"alternative" is.

/Simon

_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

Simon,

And thanks for weighing in on this topic also.

> > There should be a general goal that if incoming
code has a software
> > license, then that license should be consistent
with the following
> > provision of the outbound document:
> >
> >    As such, the rough consensus is that the IETF
trust is to grant
> >    rights such that code components of IETF
contributions can be
> >    extracted, modified, and used by anyone in any
way desired.
> >
> > and so use of licenses that are not consistent
(e.g., copyleft,
> > patent provisions) ought to be discouraged when
there's an
alternative.
> > When there's no alternative, things appear to get
"interesting".
> > Some of these licenses could prevent contribution
of code to IETF
> > because they restrict the copyright grant to the
IETF Trust
> > (Section 5.3 of -incoming) in a fashion that
cannot be dealt
> > with by prohibiting derivative works.
> 
> I agree that when there isn't an alternative available,
it gets
> "interesting".  I believe most practical
situations will be in that
> interesting area too.  The LGPL code in the Base64
document is an
> example, and the many third-party code in various RFCs
are others.
> 
> However, I challenge that it is simple to solve this
when there is an
> alternative.  The problem is: Who will decide that
something is an
> alternative or not?  For anything that is non-trivial,
each
alternative
> solution will have various advantages and
disadvantages.  It is rare
> that you will find two solutions to the same problem
with the exact
same
> properties.

The topic of "Who will decide" is definitely a
discussion that I think
the IPR WG ought to have, as it's related to whether this is
a normal
or exceptional process, and under what circumstances it's
normal vs.
exceptional.

> Going back to the Base64 example.  There are Base64
code available
under
> more permissive licenses than the LGPL.  However, all
of the about 10
> such examples that I found and reviewed (before writing
my own) turned
> out not to follow the recommendations in the RFC, or
have other
> disadvantages.  Some believed they were
"alternatives", but I did not
> (and I could point to some section of the RFC). 
Deciding who is right
> in that situation is difficult.

Ok, and if a similar circumstance came up today, an outcome
to
include LGPL code in an RFC would be (IMHO) a plausible
conclusion,
but I'd want this issue looked at more closely than if the
code
were BSD.  (For those not familiar with the licenses, LGPL
is a
copyleft license that allows linking with non-copyleft code,
BSD
does not contain copyleft provisions).
 
> My point is that any rule written for the situation
when an
> "alternative" exists will be difficult to
apply in the real world,
> because the problem is in deciding what an
"alternative" is.

I agree, that it's not possible to write the rules for all
cases in
advance, but it should be possible to write the rules to
cover common
cases and define the process (plus associated goals and
guidelines)
for dealing with the exceptional cases.  We have lots of
examples
of MIB modules, ASN.1, ABNF, etc. that just don't run into
any
problems here (e.g., no separate software license) and
should be
clearly allowed without having to "ask
permission".  Writing the
conditions under which it is necessary to "ask
permission" and
then figuring out who gets asked is the work that I think
needs
to be done here, as opposed to trying to sort out every case
in
advance.

A starting point may be that some sort of exception and
official
approval could be required for code with a license that does
not
permit the copyright grant to the IETF Trust required by
the
-incoming document.  Most copyleft licenses do not permit
that
grant because it does not require redistribution to be
under
the copyleft license, and hence that grant requires rights
beyond
the scope of copyright carried by the copyleft license.  We
may
achieve some of this via the processes already available
for
exceptions (e.g., I believe the IESG is empowered to grant
some
exceptions to the standards process), but we should work
through
what we want for an exceptions process as opposed to just
taking what we get by default with the existing process
documents.

All of the above is about copyright.  If patent rights ever
land
in the IETF Trust, then patent license provisions of
software
licenses become a consideration.

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

_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

I tend to agree with Brian.

At 04:12 AM 7/18/2007, Brian E Carpenter wrote:
>On 2007-07-17 18:24, Black_Davidemc.com wrote:
>...
>>A starting point may be that some sort of exception
and official
>>approval could be required for code with a license
that does not
>>permit the copyright grant to the IETF Trust
required by the
>>-incoming document.
>
>My starting point would be to tell the person attempting
to
>contribute the code to go find its original author and
have
>them grant the necessary license to the IETF,
independently of
>whatever other license they have put it under, and
repeat until
>done. I think making exceptions possible will produce a
world
>of hurt.
>
>     Brian

I get to this conclusion from another angle as well.  If we
introduce 
exceptions, conditions, and variations then we produce two
bad results:
Firstly, we require everyone using code from RFCs to be
careful to 
figure out what terms the code is under.  And the RFC
implementor may 
even (as has been discussed on the list before) have to take

interesting steps to avoid license contamination.
Secondly, we cause various working groups to have to have
debates 
about this non-technical aspect of their work.  Debates
which have 
been demonstrated to consume VAST quantities of time.

Yours,
Joel


_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

Seems to me (speaking as contributor) that if the
contributor is not in a 
position to grant the licenses that are asked for in
-incoming, he cannot 
make the contribution. I think we should make that a
"no exceptions" rule.

In the case of *GPL code, I think we have a couple of outs
that allow us to 
get most of the benefit to the community already:

- *GPL code contributed under the "no derivative
works" rule would not 
impose any additional onus on the recipient - he can't use
the IETF license 
to make modified versions anyway, but can discover (possibly
from the 
document) that a *GPL license is available for the code, and
act 
accordingly. This bars the example code from being
standards-track, 
naturally.

- *GPL code can be pointed to by contributions - possibly
even published by 
the IETF in some repository that is *not* the I-D/RFC
document series.

Like Brian, I see an exception process as a rather expensive
component of 
the process.

                Harald

--On 18. juli 2007 10:21 -0400 Black_Davidemc.com
wrote:

> Brian
>
> I think I agree with this line of thought - here are
some more
> detailed ideas to move this along:
>
> - Whatever IETF exception process exists for
restrictive software
> 	licenses needs to be a process of last resort.
> - As input to the process, we should require the
requester of the
> 	exception to demonstrate that the code cannot be
obtained
> 	under conditions that allow the copyright grant
required
> 	by the -incoming draft. (i.e., the default hypothesis
is
> 	that the code can be obtained under suitable
conditions,
> 	and it is the requester's responsibility to disprove
this
> 	hypothesis).
> - The requester should not expect IETF to act on
his/her behalf
> 	in attempting to obtain the code or assisting with
obtaining
> 	the code.
> - Absent a convincing demonstration that the code is
not available
> 	under conditions that permit the copyright grant, the
> 	exception should be denied.
>
> Thanks,
> --David
>
>
>> -----Original Message-----
>> From: Brian E Carpenter
[mailto:brian.e.carpentergmail.com]
>> Sent: Wednesday, July 18, 2007 9:42 AM
>> To: Black, David
>> Cc: simonjosefsson.org; ipr-wgietf.org
>> Subject: Re: Incoming - software licenses
>>
>> On 2007-07-18 15:18, Black_Davidemc.com
wrote:
>> > Brian,
>> >
>> >> On 2007-07-17 18:24, Black_Davidemc.com
wrote:
>> >> ...
>> >>> A starting point may be that some sort
of exception and official
>> >>> approval could be required for code
with a license that does not
>> >>> permit the copyright grant to the IETF
Trust required by the
>> >>> -incoming document.
>> >> My starting point would be to tell the
person attempting to
>> >> contribute the code to go find its
original author and have
>> >> them grant the necessary license to the
IETF, independently of
>> >> whatever other license they have put it
under, and repeat until
>> >> done. I think making exceptions possible
will produce a world
>> >> of hurt.
>> >
>> > That's a fine starting point, but (IMHO) it's
already insufficient,
>> > because:
>> >
>> > Exceptions are already happening - cf. Simon's
example of LGPL
>> > Base64 code, and I believe Simon has already
brought a number of
>> > other examples to our attention.  Ignoring
this issue is a decision
>> > that the existing exception process(es) are
what we want.  I'd
>> > prefer that to be a conscious decision rather
than something that
>> > happens by default.
>> >
>> > Also, there needs to be a warning somewhere
for those without
>> > sensitive legal antennae that the copyright
provisions in -incoming
>> > conflict with copyleft software licenses.  The
warning could be in
>> > an FAQ or some sort of notice in the
submission process and/or tool;
>> > it doesn't have to be in the -incoming
document itself.  My concern
>> > here is that I suspect that the members of
this mailing list are
>> > among the minority that understand the
conflict between copyleft
>> > and the -incoming copyright grant.
>>
>> But I think if we include that warning we have to
offer a work-around
>> which doesn't lead to exception handling in *our*
process - put the
>> onus for the work-around on the person who wrote
the code and decided
>> to encumber it with copyleft in the first place.
>>
>>      Brian
>>
>>
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wgietf.org
> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>
>





_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

Harald - its really good to see you echoing my words
finally. I should have 
sent this out a month ago but just found it in my DRAFTS
folder and since it 
pertains to the IP rights of an Entity who is sponsoring
people in the IETF 
its relevant.

The problem is that there is an issue with submitting
anything to the IETF 
for vetting by SPONSORED ENGINEERING STAFF that is 'assigned
to the IETF to 
work on the Entity's Effort's therein'.

Simply said, the SPONSORS own the WORK PRODUCT their
Sponsoree's work on, 
and also get the privilege of determining what their
SPONSOREE's work on. 
That is a key flaw in the current work-flow model. It
assumes and insists 
that the SPONSOREE themselves control their actions within
the IETF and that 
simply is not true.

That said, because the SPONSORING ENTITY does retain
ownership of the IP 
until there is something between them and the IETF itself
acknowledging that 
the SPONSOREE holds those abilities themselves. Otherwise
their are owned 
lock, stock, and barrel, and the SPONSOREE doesnt have the
legal authority 
to assing any of the SPONSORING ENTITY's IP Rights to the
IETF or the IETF 
Trust no matter what the IPR WG says they do.

As such,  the IETF has a responsibility to force any and all
submssions to 
disclose any and all IP Rights so that relying party's are
informed as to 
what they are investing assets (the time of their
Sponsoree's) w... but 
there is a problem with the IETF's disclosure model and that
is that the 
model may make the IETF a formal part of a fraud by Wire
which could be a 
criminal matter in my estimation.

I suggest you review the inline comments below.

----- Original Message ----- 
From: "Harald Tveit Alvestrand" <haraldalvestrand.no>
To: <Black_Davidemc.com>; <brian.e.carpentergmail.com>
Cc: <ipr-wgietf.org>
Sent: Friday, July 20, 2007 6:28 AM
Subject: RE: Incoming - software licenses


> Seems to me (speaking as contributor) that if the
contributor is not in a
> position to grant the licenses that are asked for in
-incoming, he cannot
> make the contribution. I think we should make that a
"no exceptions" rule.
>
> In the case of *GPL code, I think we have a couple of
outs that allow us
> to get most of the benefit to the community already:
>
> - *GPL code contributed under the "no derivative
works" rule would not
> impose any additional onus on the recipient - he can't
use the IETF
> license to make modified versions anyway, but can
discover (possibly from
> the document) that a *GPL license is available for the
code, and act
> accordingly. This bars the example code from being
standards-track,
> naturally.

OK now that we are at "that we cannot grant rights to
our relying parties
which we as the relying party were not granted", the
only impact this has is
that for proprietary standards runs, the IETF MUST require
full and final
IPR disclosure in the original filing, so that SPONSORS are
enabled to 
review whether
their ENGINEERING RESOURCES which they CONTRIBUTE TO THE
IETF, should work
on thise initiatives or not. The IETF does not get to make
its mind up what 
to of
its Member's Time to focus on any given initiative, that is
up to those 
spending time there on those efforts.

Otherwise the IETF itself becomes a part to any mechanical
frauds which 
occur when a relying party invests their engineer's time in
a project which 
has undisclosed IP rights issues with it, and as such the
IETF and the 
IPR-WG member's may ultimately be responsible for any
commercial damages 
which occur.

The argument is simple, the engineer's in the IETF cannot
also say "no we 
are not liable" and make that liability go away. That
is to say, the IETF, 
and those inside it may in fact liable and so are those
inside it I am 
betting.

>
> - *GPL code can be pointed to by contributions -
possibly even published
> by the IETF in some repository that is *not* the
I-D/RFC document series.
>
> Like Brian, I see an exception process as a rather
expensive component of
> the process.
>
>                Harald
>
> --On 18. juli 2007 10:21 -0400 Black_Davidemc.com
wrote:
>
>> Brian
>>
>> I think I agree with this line of thought - here
are some more
>> detailed ideas to move this along:
>>
>> - Whatever IETF exception process exists for
restrictive software
>> licenses needs to be a process of last resort.
>> - As input to the process, we should require the
requester of the
>> exception to demonstrate that the code cannot be
obtained
>> under conditions that allow the copyright grant
required
>> by the -incoming draft. (i.e., the default
hypothesis is
>> that the code can be obtained under suitable
conditions,
>> and it is the requester's responsibility to
disprove this
>> hypothesis).
>> - The requester should not expect IETF to act on
his/her behalf
>> in attempting to obtain the code or assisting with
obtaining
>> the code.
>> - Absent a convincing demonstration that the code
is not available
>> under conditions that permit the copyright grant,
the
>> exception should be denied.
>>
>> Thanks,
>> --David
>>
>>
>>> -----Original Message-----
>>> From: Brian E Carpenter
[mailto:brian.e.carpentergmail.com]
>>> Sent: Wednesday, July 18, 2007 9:42 AM
>>> To: Black, David
>>> Cc: simonjosefsson.org; ipr-wgietf.org
>>> Subject: Re: Incoming - software licenses
>>>
>>> On 2007-07-18 15:18, Black_Davidemc.com
wrote:
>>> > Brian,
>>> >
>>> >> On 2007-07-17 18:24, Black_Davidemc.com
wrote:
>>> >> ...
>>> >>> A starting point may be that some
sort of exception and official
>>> >>> approval could be required for
code with a license that does not
>>> >>> permit the copyright grant to the
IETF Trust required by the
>>> >>> -incoming document.
>>> >> My starting point would be to tell the
person attempting to
>>> >> contribute the code to go find its
original author and have
>>> >> them grant the necessary license to
the IETF, independently of
>>> >> whatever other license they have put
it under, and repeat until
>>> >> done. I think making exceptions
possible will produce a world
>>> >> of hurt.
>>> >
>>> > That's a fine starting point, but (IMHO)
it's already insufficient,
>>> > because:
>>> >
>>> > Exceptions are already happening - cf.
Simon's example of LGPL
>>> > Base64 code, and I believe Simon has
already brought a number of
>>> > other examples to our attention.  Ignoring
this issue is a decision
>>> > that the existing exception process(es)
are what we want.  I'd
>>> > prefer that to be a conscious decision
rather than something that
>>> > happens by default.
>>> >
>>> > Also, there needs to be a warning
somewhere for those without
>>> > sensitive legal antennae that the
copyright provisions in -incoming
>>> > conflict with copyleft software licenses. 
The warning could be in
>>> > an FAQ or some sort of notice in the
submission process and/or tool;
>>> > it doesn't have to be in the -incoming
document itself.  My concern
>>> > here is that I suspect that the members of
this mailing list are
>>> > among the minority that understand the
conflict between copyleft
>>> > and the -incoming copyright grant.
>>>
>>> But I think if we include that warning we have
to offer a work-around
>>> which doesn't lead to exception handling in
*our* process - put the
>>> onus for the work-around on the person who
wrote the code and decided
>>> to encumber it with copyleft in the first
place.
>>>
>>>      Brian
>>>
>>>
>>
>> _______________________________________________
>> Ipr-wg mailing list
>> Ipr-wgietf.org
>> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>>
>>
>
>
>
>
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wgietf.org
> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg


_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

Damn spell checker... "assign"... sorry.

T
----- Original Message ----- 
From: "TS Glassey" <tglasseyearthlink.net>
To: "Harald Tveit Alvestrand" <haraldalvestrand.no>; <Black_Davidemc.com>; 
"Brian E Carpenter" <brian.e.carpentergmail.com>
Cc: <ipr-wgietf.org>
Sent: Sunday, October 07, 2007 8:22 AM
Subject: Re: Incoming - software licenses


> Harald - its really good to see you echoing my words
finally. I should 
> have sent this out a month ago but just found it in my
DRAFTS folder and 
> since it pertains to the IP rights of an Entity who is
sponsoring people 
> in the IETF its relevant.
>
> The problem is that there is an issue with submitting
anything to the IETF 
> for vetting by SPONSORED ENGINEERING STAFF that is
'assigned to the IETF 
> to work on the Entity's Effort's therein'.
>
> Simply said, the SPONSORS own the WORK PRODUCT their
Sponsoree's work on, 
> and also get the privilege of determining what their
SPONSOREE's work on. 
> That is a key flaw in the current work-flow model. It
assumes and insists 
> that the SPONSOREE themselves control their actions
within the IETF and 
> that simply is not true.
>
> That said, because the SPONSORING ENTITY does retain
ownership of the IP 
> until there is something between them and the IETF
itself acknowledging 
> that the SPONSOREE holds those abilities themselves.
Otherwise their are 
> owned lock, stock, and barrel, and the SPONSOREE doesnt
have the legal 
> authority to assing any of the SPONSORING ENTITY's IP
Rights to the IETF 
> or the IETF Trust no matter what the IPR WG says they
do.
>
> As such,  the IETF has a responsibility to force any
and all submssions to 
> disclose any and all IP Rights so that relying party's
are informed as to 
> what they are investing assets (the time of their
Sponsoree's) w... but 
> there is a problem with the IETF's disclosure model and
that is that the 
> model may make the IETF a formal part of a fraud by
Wire which could be a 
> criminal matter in my estimation.
>
> I suggest you review the inline comments below.
>
> ----- Original Message ----- 
> From: "Harald Tveit Alvestrand"
<haraldalvestrand.no>
> To: <Black_Davidemc.com>;
<brian.e.carpentergmail.com>
> Cc: <ipr-wgietf.org>
> Sent: Friday, July 20, 2007 6:28 AM
> Subject: RE: Incoming - software licenses
>
>
>> Seems to me (speaking as contributor) that if the
contributor is not in a
>> position to grant the licenses that are asked for
in -incoming, he cannot
>> make the contribution. I think we should make that
a "no exceptions" 
>> rule.
>>
>> In the case of *GPL code, I think we have a couple
of outs that allow us
>> to get most of the benefit to the community
already:
>>
>> - *GPL code contributed under the "no
derivative works" rule would not
>> impose any additional onus on the recipient - he
can't use the IETF
>> license to make modified versions anyway, but can
discover (possibly from
>> the document) that a *GPL license is available for
the code, and act
>> accordingly. This bars the example code from being
standards-track,
>> naturally.
>
> OK now that we are at "that we cannot grant rights
to our relying parties
> which we as the relying party were not granted",
the only impact this has 
> is
> that for proprietary standards runs, the IETF MUST
require full and final
> IPR disclosure in the original filing, so that SPONSORS
are enabled to 
> review whether
> their ENGINEERING RESOURCES which they CONTRIBUTE TO
THE IETF, should work
> on thise initiatives or not. The IETF does not get to
make its mind up 
> what to of
> its Member's Time to focus on any given initiative,
that is up to those 
> spending time there on those efforts.
>
> Otherwise the IETF itself becomes a part to any
mechanical frauds which 
> occur when a relying party invests their engineer's
time in a project 
> which has undisclosed IP rights issues with it, and as
such the IETF and 
> the IPR-WG member's may ultimately be responsible for
any commercial 
> damages which occur.
>
> The argument is simple, the engineer's in the IETF
cannot also say "no we 
> are not liable" and make that liability go away.
That is to say, the IETF, 
> and those inside it may in fact liable and so are those
inside it I am 
> betting.
>
>>
>> - *GPL code can be pointed to by contributions -
possibly even published
>> by the IETF in some repository that is *not* the
I-D/RFC document series.
>>
>> Like Brian, I see an exception process as a rather
expensive component of
>> the process.
>>
>>                Harald
>>
>> --On 18. juli 2007 10:21 -0400 Black_Davidemc.com
wrote:
>>
>>> Brian
>>>
>>> I think I agree with this line of thought -
here are some more
>>> detailed ideas to move this along:
>>>
>>> - Whatever IETF exception process exists for
restrictive software
>>> licenses needs to be a process of last resort.
>>> - As input to the process, we should require
the requester of the
>>> exception to demonstrate that the code cannot
be obtained
>>> under conditions that allow the copyright grant
required
>>> by the -incoming draft. (i.e., the default
hypothesis is
>>> that the code can be obtained under suitable
conditions,
>>> and it is the requester's responsibility to
disprove this
>>> hypothesis).
>>> - The requester should not expect IETF to act
on his/her behalf
>>> in attempting to obtain the code or assisting
with obtaining
>>> the code.
>>> - Absent a convincing demonstration that the
code is not available
>>> under conditions that permit the copyright
grant, the
>>> exception should be denied.
>>>
>>> Thanks,
>>> --David
>>>
>>>
>>>> -----Original Message-----
>>>> From: Brian E Carpenter
[mailto:brian.e.carpentergmail.com]
>>>> Sent: Wednesday, July 18, 2007 9:42 AM
>>>> To: Black, David
>>>> Cc: simonjosefsson.org; ipr-wgietf.org
>>>> Subject: Re: Incoming - software licenses
>>>>
>>>> On 2007-07-18 15:18, Black_Davidemc.com
wrote:
>>>> > Brian,
>>>> >
>>>> >> On 2007-07-17 18:24,
Black_Davidemc.com wrote:
>>>> >> ...
>>>> >>> A starting point may be that
some sort of exception and official
>>>> >>> approval could be required for
code with a license that does not
>>>> >>> permit the copyright grant to
the IETF Trust required by the
>>>> >>> -incoming document.
>>>> >> My starting point would be to tell
the person attempting to
>>>> >> contribute the code to go find its
original author and have
>>>> >> them grant the necessary license
to the IETF, independently of
>>>> >> whatever other license they have
put it under, and repeat until
>>>> >> done. I think making exceptions
possible will produce a world
>>>> >> of hurt.
>>>> >
>>>> > That's a fine starting point, but
(IMHO) it's already insufficient,
>>>> > because:
>>>> >
>>>> > Exceptions are already happening - cf.
Simon's example of LGPL
>>>> > Base64 code, and I believe Simon has
already brought a number of
>>>> > other examples to our attention. 
Ignoring this issue is a decision
>>>> > that the existing exception
process(es) are what we want.  I'd
>>>> > prefer that to be a conscious decision
rather than something that
>>>> > happens by default.
>>>> >
>>>> > Also, there needs to be a warning
somewhere for those without
>>>> > sensitive legal antennae that the
copyright provisions in -incoming
>>>> > conflict with copyleft software
licenses.  The warning could be in
>>>> > an FAQ or some sort of notice in the
submission process and/or tool;
>>>> > it doesn't have to be in the -incoming
document itself.  My concern
>>>> > here is that I suspect that the
members of this mailing list are
>>>> > among the minority that understand the
conflict between copyleft
>>>> > and the -incoming copyright grant.
>>>>
>>>> But I think if we include that warning we
have to offer a work-around
>>>> which doesn't lead to exception handling in
*our* process - put the
>>>> onus for the work-around on the person who
wrote the code and decided
>>>> to encumber it with copyleft in the first
place.
>>>>
>>>>      Brian
>>>>
>>>>
>>>
>>>
_______________________________________________
>>> Ipr-wg mailing list
>>> Ipr-wgietf.org
>>> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>>>
>>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Ipr-wg mailing list
>> Ipr-wgietf.org
>> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wgietf.org
> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg 


_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg