Subject: Last Call for Comments on " Legal Provisions Related to IETF Documents"

From: "Ed Juskevicius" <[email-masked]>
Date: Sun, 10 Aug 2008 23:58:00 -0400

This is to announce that the IETF Trustees have just
posted a revised version of a draft policy on 
"Legal Provisions Related to IETF Documents" dated
08-05-08 at:
http://trustee.ietf.org/policyandprocedures.html

This draft includes all of the changes agreed during
the July 31st meeting of the IPR working group held
in Dublin.

On behalf of the IETF Trustees, we invite your
review and final comments and suggestions on this
policy.  

The IETF Trustees will meet via telechat on Aug 21st
with the goal of finalizing this policy.  If you
have any final comments, please post them on the
IPR WG mailing list.  

Best Regards, and Thanks in advance, 

Ed Juskevicius      Ray Pelletier
Chair               Trustee
IETF Trust          IETF Administrative Director
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 11 Aug 2008 09:38:02 +0200

Thanks for publishing a new version of the document.  There has been
some regressions in this version compared to earlier versions.

#1:

The latest version of the IETF Legal Provisions adds a new section 4.d.:

      d.  Attribution. In addition to the language required under the
      BSD License, each Code Component must be clearly attributed to
      IETF and identify the RFC or other IETF Document or IETF
      Contribution from which it is taken.

That license condition is beyond what the BSD license requires.  That
means the above license clause needs to be included in the license text
of every code copied from a RFC, since the requirement applies to all
material derived from code extracted from an RFC.

It also means that code copied from an IETF document cannot be used as
"BSD code", because the above restriction needs to be preserved in every
modified copy of the code.

This variation of the BSD license is original, and MAY be incompatible
with some free software licenses; at least it does not appear to have
been reviewed for compatibility by anyone familiar with free software
licensing.

It is important to use an already widely reviewed free software license
instead of inventing new licenses!  There are plenty of examples of bad
things that happen if this advice isn't followed, see [1] [2] for two
histories.

Explained in a different way, the above new addition is against what the
IETF has expressed in draft-ietf-ipr-outbound-rights-07.txt:

   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.

The new clause 4.d. is incompatible with the expressed wish of the IETF,
in my reading.  The outbound-rights-07 document doesn't say anything
about preserving attribution for code components.

The concern regarding code attribution was discussed in the IPR WG a
long time ago, when people brought up similar ideas about requiring
attributions.  As far as I could tell, no consensus developed, and
consequently the document didn't say anything related to attribution for
code components.

Please remove section 4.d completely.

#2:

There is another addition to section 4.c of the new document version:

       c.  License. Code Components are hereby licensed to each person
       who wishes to receive such a license on the terms of the “BSD
       License”, as follows (in addition to any licenses granted with
       respect to the text of such Code Components as they appear in
       IETF Contributions or IETF Documents pursuant to Section 3
       above):

The text inside the parenthesis is new.

The use of the word "in addition to" implies that the code components
will NOT be strictly licensed only under the BSD license, but under a
dual-license of the BSD license and the restrictive license (for text in
RFCs) in section 3 of the document.  That is likely what is intended
too: code components should be possible to use just like text from RFCs
under the normal (section 3) IETF rules.

In a dual-license situation, to be able to use the code component under
only the BSD license, the license needs to grant you the right to drop
one of the license texts for it.

This is the same problem as explained in my initial comment on this
document, see #1 in:

http://permalink.gmane.org/gmane.ietf.ipr/5360

What is missing is text such as the following:

  The licensee can chose whether to use the BSD License or the Section 3
  rules when extracting this component.

Once a licensee has extracted a component under the BSD license, that
version cannot later be used under the IETF section 3 rules.

Alternatively, you could adopt the suggestion I made in my initial
comment: clearly say that licensee can use the BSD license as the ONLY
license for extracted code components.  This would avoid much confusion
about which license applies to code components extracted from RFCs.

The text to add would be:

       To clarify, the entire license for Code Components is the above
       BSD license, and if you use this license for a Code Component,
       the license terms in section 3 does not apply to that material.

#3:

The URL given for "common code components" doesn't work:
www.ietf.org/trust/code.

Thanks,
/Simon

[1] http://www.dwheeler.com/essays/gpl-compatible.html
[2] http://www.gnu.org/philosophy/bsd.html

---

From: Ray Pelletier <[email-masked]>
Date: Tue, 12 Aug 2008 14:00:03 -0400

NEW DOCUMENT Dated 8-12-08

This is to announce that the IETF Trustees have just posted a revised 
version of a draft policy on "Legal Provisions Related to IETF 
Documents" dated 08-12-08 at: 
http://trustee.ietf.org/policyandprocedures.html

There is also a Comparison document and a separate Code Components List.

Below is a summary of the changes and an explanation of them.

On behalf of the IETF Trustees, we invite your review and final comments 
and suggestions on this
policy.

Given these changes, the Trustees will meet via telechat on September 
4th with the goal of
finalizing this policy. If you have any final comments, please post them 
on the
IPR WG mailing list.

Thanks

Ray Pelletier
IAD
Trustee

Summary of Changes

1. Intro -- changed "this document" to "these Legal Provisions" 
throughout the document.

2. Applicability -- moved Section 4 up to Section 2 for better flow.

2.a Effective Date -- Inserted a specific date for the effectiveness of 
the document, as discussed in Dublin.
2.b Effectiveness -- the Legal Provisions apply to IETF Contributions 
that are submitted after effectiveness, and to IETF Documents that are 
published after effectiveness.

3.a and 3.c Licenses -- the licenses now apply to IETF Contributions and 
IETF Documents in most places

3.c and 4.c Code -- clarified that Code included in IETF Documents can 
be reproduced and modified per the document licenses, while Code 
intended for execution is covered by the BSD License under Section 4.

3.c.iii.y Substantial Portion -- I was not sure whether there was 
consensus regarding the amount of text that could be extracted without 
applying the full RFC text/legends.

3.d Licenses Not Granted -- removed reference to disallowance of 
publishing I-Ds outside the IETF Standards Process.

3.f Termination -- deleted, per Dublin discussion

4.a Code Definition -- moved list of common code components to a URL

4.c Copyright notice -- changed notice in BSD license to reflect that 
this license now covers code from all IETF Contributions and Documents, 
not only RFCs.

4.d Attribution -- added a clause requiring identification of the 
relevant IETF Document/Contribution, per Dublin discussion.

6 Required Text -- added "on the first page" per Dublin discussion.

6.b Copyright Notice -- moved up from 6.c for improved flow. Also 
tweaked the text of the copyright notice to be more flexible, "IETF 
Trust and the persons identified as its authors"

7.e Definitive Version -- added a sentence to address the point about 
translations of these Legal Provisions.

---

From: "Contreras, Jorge" <[email-masked]>
Date: Tue, 12 Aug 2008 17:10:51 -0400

Simon -- thanks for the speedy feedback!  Below are some responses: 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Simon Josefsson
> Sent: Monday, August 11, 2008 3:38 AM
> To: Ed Juskevicius
> Cc: [email-masked]; IETF Discussion
> Subject: Re: Last Call for Comments on " Legal Provisions 
> Related to IETFDocuments"
> 

I understand the point.  Several participants at the IPR-WG meeting
requested this addition, but I would ask the list to reconsider in light
of your feedback.

>        who wishes to receive such a license on the terms of the "BSD
>        License", as follows (in addition to any licenses granted with

I agree that we should clarify:  the license under Section 3 is the ONLY
license applicable to extracted Code Components.  The other licenses
relate to the code-as-text in RFC and other documents.

> The URL given for "common code components" doesn't work:

That's just a placeholder.  The code components list has not changed
from the 7/18 version.  It will simply be moved to a URL that is
operable once this document is final.
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Aug 2008 09:33:38 +1200

How about adding some weasel words, or even simply making the
attribution requirement a "should"? I think it's perfectly reasonable
to ask for attribution when possible, so any form of words that
doesn't "break" the BSD license in a narrow legalistic sense
would do fine for me.

It's not like we're asking for much:

# This code was derived from IETF RFC XXXX. Please retain this comment if possible.

    Brian

On 2008-08-13 03:07, Paul Hoffman wrote:
> As someone who always prefers the BSD license, I agree with Simon on #1
> and #2. Saying "BSD except..." means it is a new type of license, one
> that typical implementers will not expect.
> 
> One way to look at this is to consider what happens if someone treats
> this as a real BSD license and doesn't give attribution. Is the IETF
> Trust really going to sue them over the lack of attribution? If not, why
> even have that addition to the BSD license? Like in our technical
> protocols, simplicity is good here.
> 
> 
> --Paul Hoffman, Director
> --VPN Consortium
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 13 Aug 2008 02:13:52 +0200

Brian E Carpenter wrote:

> attribution requirement a "should"?

I tend to forget the details, but IIRC we have a SHOULD for an
attribution elsewhere (not in the part about code).  If that is
very clear folks might arrive at the conclusion that it's also
*desired* for code snippets.  But not *required*.

> # This code was derived from IETF RFC XXXX. Please retain this

Not fair.  We can't put code with similar statements in an RFC
in some cases, where somebody also didn't "ask for much", just
a beerware licence or copyright note or similar.  Therefore we
should also not "ask for much" from others if there's a chance
that this is too much.

 Frank

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 Aug 2008 02:35:55 +0200

> requested this addition, but I would ask the list to reconsider in light

Thanks.

For what it's worth, I can't seem to find anything in the IPR WG minutes
that touches on this topic.

> relate to the code-as-text in RFC and other documents.

Exactly.

> operable once this document is final.

The table found at
http://trustee.ietf.org/docs/Code_Components_List_8-12-08.txt has been
modified compared to the 7/18 version though: the entry for 'algorithms
described in pseudocode' has been removed, which means it would no
longer be considered as a code component.

/Simon

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 13 Aug 2008 08:21:31 +0200

> that touches on this topic.
I don't mind removing 4.d again

I am somewhat confused, though - removing section 4.d means that one can 
reuse the code components without identifying the source from which they 
were taken at all, which seems to run counter to the general idea that 
all reuse of IETF contributions should properly acknowledge their source.

It may be that the best way to achieve this is to ask for an 
acknowledgement, rather than demanding one - with all the ways code is 
used, making very hard rules may reduce people's ability to do what they 
have to do unneccessarily.
>> relate to the code-as-text in RFC and other documents.
I think this is a good clarification, and certainly was the intent.
(one earlier version of the text would have seemed to accidentally 
remove the permission to quote a piece of an RFC that included both text 
and code - I'm certain this wasn't the intent).
> longer be considered as a code component.
After discussion on this list, it was made clear that the WG had not 
agreed to include pseudocode, so the list was adjusted back to what the 
WG had agreed on.

                     Harald

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Aug 2008 08:07:49 -0700

As someone who always prefers the BSD license, I agree with Simon on 
#1 and #2. Saying "BSD except..." means it is a new type of license, 
one that typical implementers will not expect.

One way to look at this is to consider what happens if someone treats 
this as a real BSD license and doesn't give attribution. Is the IETF 
Trust really going to sue them over the lack of attribution? If not, 
why even have that addition to the BSD license? Like in our technical 
protocols, simplicity is good here.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Aug 2008 16:04:28 -0700

># This code was derived from IETF RFC XXXX. Please retain this 

I would prefer a request to weasel words because it would be clearer.

   Please give attribution of the source of the code in the code itself,
   such as "This code was derived from IETF RFC XXXX".

--Paul Hoffman, Director
--VPN Consortium

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 Aug 2008 11:22:54 +0200

Harald Tveit Alvestrand <[email-masked]> writes:

> I am somewhat confused, though - removing section 4.d means that one
> can reuse the code components without identifying the source from
> which they were taken at all, which seems to run counter to the
> general idea that all reuse of IETF contributions should properly
> acknowledge their source.

That general idea isn't encoded in outbound-rights-07.

The idea of attributions and limited field-of-use was discussed before,
but as far as I understand, compatibility with free software licenses
was deemed more important than the need to require attribution.

Further, the BSD license requires that the license text is maintained
both when redistributing source and binary forms of the code.  The
modified license that is part of the legal provisions references the
IETF.  So there are references to the IETF even without the 4.d clause.

> used, making very hard rules may reduce people's ability to do what
> they have to do unneccessarily.

That could work, as long as the request is not part of the license.

> I think this is a good clarification, and certainly was the intent.

Agreed.

/Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Aug 2008 09:21:43 -0400

Comment following the excerpt from Harald...

Harald Tveit Alvestrand wrote:
...
> have to do unneccessarily.

As I understand the WG agreement, it was "may use the code in any way 
desired."  Not "in almost any way desired."
So I do not think it is consistent with our agreements to require the 
acknowledgment.  I have no problem with (and rather like) requesting an 
acknowledgment.

Yours,
Joel

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 Aug 2008 15:58:51 +0200

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

>> acknowledgement, rather than demanding one - with all the ways code
>> is used, making very hard rules may reduce people's ability to do
>> what they have to do unneccessarily.
>
> acknowledgment.  I have no problem with (and rather like) requesting
> an acknowledgment.

The following is a side note.

Strictly speaking, the BSD license makes it impossible to use code in
some ways.  The BSD license places some artificial restriction on how
the code can be used:

 * Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.

 * Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

It would be interesting to learn how the Trustees decided that the BSD
license is the appropriate license to meet the "may use the code in any
way desired" goal, and whether they had any legal advice on that choice.

There are certainly alternatives to the BSD license.  The Expat license
[1] places no requirement to reproduce a notice on binary forms.  The
GNU project uses an all-permissive license for some work:

  Copying and distribution of this file, with or without modification,
  are permitted in any medium without royalty provided the copyright
  notice and this notice are preserved.

Public domain would also meet the goal, but the concept is US-centric,
and also incompatible with the inbound document's choice to let
copyright remain with the author.

On a practical side, I'm not aware of any widely used license that is
incompatible with the BSD License, so one could dismiss my argument as
theoretical.

However, it would be easy to create an incompatible license.  For
example:

  Copying and distribution of this file, with or without modification,
  are permitted in any medium without royalty provided the copyright
  notice and this notice are preserved.  You may not impose any further
  restrictions on the recipients' exercise of the rights granted herein.

This license appears to me be incompatible with the BSD license.

If you believe the sentence I added is artificial and doesn't occur in
practice, think again: it is a direct quote from the GPLv2.

Given how the inbound/outbound documents are written, I don't see a
simple way to fix this problem.

Hopefully it will be possible to revise the Legal Provisions in the
future, if the IETF-variant of the BSD license fails to meet the goal
expressed in outbound-rights-07 and there are practical problems because
of it.  I'm worried that there is no easy process defined to do this.

/Simon

[1] http://www.jclark.com/xml/copying.txt
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 13 Aug 2008 17:11:01 +0200

Simon Josefsson wrote:

> Hopefully it will be possible to revise the Legal Provisions
> in the future, if the IETF-variant of the BSD license fails
> to meet the goal expressed in outbound-rights-07 and there
> are practical problems because of it.  I'm worried that
> there is no easy process defined to do this.

Worried, but likely not surprised, right ?  This just is not
easy, and this might require a new IPR WG and IETF consensus.

 Frank

---

From: Ted Hardie <[email-masked]>
Date: Wed, 13 Aug 2008 10:59:10 -0700

>have to do unneccessarily.

There was a suggestion from Scott Kitterman on the IETF list that a reference
to origin RFC be included as a comment in code snippets, along with
encouragement to include such comments.   That doesn't prevent someone from
modifying the code to leave it out, but encourages folks to leave
in useful data about where to feed back issues, optimizations, and
the like into the standards process. I believe it is a good, practical
idea and that it could be easily generalized.  In an I-D, for example,
the code snippet could reference the draft name, rather than RFC number,
with a request to the RFC Editor to adjust the reference on assignment
of the RFC number.

I think having a well-known way of including attribution
(Comments in the code) is better than a simple request for
acknowledgement, as those external to the code tend to
get lost in cut-and-pastes.  The bigger issue than attribution
for me, though, is that it helps folks know where to feed
their comments when things don't work or could work better.

Since this is not a limitation on code reuse (in that it doesn't
prevent someone from cutting it out if they really want to),
I do not personally see any issues with that way forward.
If there are issues, I'd like to understand them.
			regards,
				Ted

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 13 Aug 2008 20:10:04 +0200

> I do not personally see any issues with that way forward.
Neither do I. And the Trust doesn't have to do it - the IESG can add it 
to id-nits.
Let's do that.

                  Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Aug 2008 10:22:58 +1200

...
> Neither do I. And the Trust doesn't have to do it - the IESG can add it

+1. It can even go in id-nits immediately, since Bert is
revising it yet again.

    Brian

---

From: Ray Pelletier <[email-masked]>
Date: Thu, 14 Aug 2008 08:32:46 -0400

Ooops, wrong version.  But it has been corrected.

Ray

Ray Pelletier wrote:

> On behalf of the IETF Trustees, we invite your review and final 
> comments and suggestions on this
> policy.
>
> finalizing this policy. If you have any final comments, please post 
> them on the
> IPR WG mailing list.
>
> Thanks
>
> Ray Pelletier
> IAD
> Trustee
>
> Summary of Changes
>
> 2.a Effective Date -- Inserted a specific date for the effectiveness 
> of the document, as discussed in Dublin.
> 3.a and 3.c Licenses -- the licenses now apply to IETF Contributions 
> and IETF Documents in most places
>
> this license now covers code from all IETF Contributions and 
> Documents, not only RFCs.
>
>------------------------------------------------------------------------
>

---

From: "George Willingmyre" <[email-masked]>
Date: Thu, 14 Aug 2008 09:06:51 -0400

relevant recent legal decision  http://www.patentlyo.com/patent/2008/08/open-source-lic.html

8/13 Open Source License Conditions Enforceable Through Copyright Law
Jacobson v. Katzer (Fed. Cir. 2008) 

In an interesting decision, the CAFC held that open source license conditions are enforceable under the copyright laws. Jacobson's open source license at issue here allowed anyone to use his software so long as his conditions are met (such as making any modified code freely available). 

Copyright vs Contract: The district court held that violation of the open source conditions are remedied through a contract claim rather than copyright. The CAFC sided with the copyright holder - holding that "Copyright holders who engage in open source licensing have the right to control the modification and distribution of copyrighted material.

George T. Willingmyre, P.E.
GTW Associates
1.301.421.4138
www.gtwassociates.com
  ----- Original Message ----- 
  From: Ray Pelletier 
  To: Ray Pelletier ; Ed Juskevicius ; [email-masked] ; IETF Discussion 
  Sent: Thursday, August 14, 2008 8:32 AM
  Subject: Re: Last Call for Comments on " Legal Provisions Related to IETFDocuments"

  Ray

  Ray Pelletier wrote:

    This is to announce that the IETF Trustees have just posted a revised version of a draft policy on "Legal Provisions Related to IETF Documents" dated 08-12-08 at: http://trustee.ietf.org/policyandprocedures.html

    On behalf of the IETF Trustees, we invite your review and final comments and suggestions on this
    policy.

    Given these changes, the Trustees will meet via telechat on September 4th with the goal of 
    finalizing this policy. If you have any final comments, please post them on the
    IPR WG mailing list. 

    Thanks

    Ray Pelletier
    IAD
    Trustee

    Summary of Changes

    1. Intro -- changed "this document" to "these Legal Provisions" throughout the document.

    2.a Effective Date -- Inserted a specific date for the effectiveness of the document, as discussed in Dublin.
    2.b Effectiveness -- the Legal Provisions apply to IETF Contributions that are submitted after effectiveness, and to IETF Documents that are published after effectiveness.

    3.a and 3.c Licenses -- the licenses now apply to IETF Contributions and IETF Documents in most places

    3.c and 4.c Code -- clarified that Code included in IETF Documents can be reproduced and modified per the document licenses, while Code intended for execution is covered by the BSD License under Section 4.

    3.c.iii.y Substantial Portion -- I was not sure whether there was consensus regarding the amount of text that could be extracted without applying the full RFC text/legends.

    3.d Licenses Not Granted -- removed reference to disallowance of publishing I-Ds outside the IETF Standards Process.

    4.c Copyright notice -- changed notice in BSD license to reflect that this license now covers code from all IETF Contributions and Documents, not only RFCs.

    4.d Attribution -- added a clause requiring identification of the relevant IETF Document/Contribution, per Dublin discussion.

    6.b Copyright Notice -- moved up from 6.c for improved flow. Also tweaked the text of the copyright notice to be more flexible, "IETF Trust and the persons identified as its authors"

    7.e Definitive Version -- added a sentence to address the point about translations of these Legal Provisions. 

    Ed Juskevicius wrote:

  ----------------------------------------------------------------------------
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

------------------------------------------------------------------------------

---

From: Bill Fenner <[email-masked]>
Date: Thu, 14 Aug 2008 09:14:14 -0400

> that touches on this topic.

I think it was my comments at the mic that started this.  I'm  
perfectly fine with requesting, not requiring, attribution of the  
code.  I realize that adding the requirement basically turns the  
license into the dreaded 4-clause BSD license, which we definitely  
don't want to do - the advertising clause was removed for a reason.

   Bill

---

From: Bill Fenner <[email-masked]>
Date: Thu, 14 Aug 2008 13:49:01 -0400

> review and final comments and suggestions on this

Here's part of an email that I posted last week on the ipr wg list,  
which hasn't received much comment but I would like the trustees to  
consider:

When I was updating section 4 [of 1id-guidelines]
(which talks about the optional
restrictions in 6b.) I ran across a minor hiccough -- 3978 allows the
6.b.ii. statement, "This document may not be modified, and derivative
works of it may not be created, and it may not be published except as
an Internet-Draft.", to be split into two: "This document may not be
modified, and derivative works of it may not be created." and "This
document may only be posted in an Internet-Draft." are in different
sections of 3978.  The section of 3978 that mentions this also
mentions optionally giving extra permissions for MIBs/PIBs published
with this restriction: "other than to extract section XX as-is for
separate use."

-incoming only mentions that there are instructions in the Legend
Instructions, which I assume are the same as the IETF Trust's Legal
Provisions Relating to IETF Documents, so I can't really tell from
that whether the wg intentionally removed these options; the trust
intentionally removed these options; the trust unintentionally removed
these options; or other.

Thanks,
  Bill

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 15 Aug 2008 10:39:36 +0200

> intentionally removed these options; the trust unintentionally removed
As far as I understand it, the WG desired the ability for these code 
pieces to be "code licensed", just as for all other code, but the "extra 
permissions" stuff was never discussed, AFAIK.

So seen from the WG's perspective, I think having an optional ", other 
than to extract code components under the Code License" would be a Good 
Thing; it seems to me that people who post restricted I-Ds (for whatever 
reason) would be surprised if we started licensing their code pieces, so 
it's better to get them to be explicit and allow us to do so.

My opinion.

                 Harald