Re: IETF Last Call for two IPR WG Dcouments

[Simon Josefsson <[e-mail]>]

I'm cc'ing [e-mail] since others may have the same question.

"Joel M. Halpern" <[e-mail]> writes:

> I'll leave it up to others to comment on list, but you did not
> actually answer the question.
> How is it possible to write a license that lets anyone use the code
> any way they want, and modify it any way they want, but not have that
> license permit use in the open source projects you list.

The problem is that the wishes as expressed right now are too sketchy to
provide sufficient information for the trust to produce a good license.

There are examples of projects with good intentions that want to give
everyone the right to use code they publish in any way to end up with
copying conditions that prevent some subset of the community from using
the software.

Look at the mailing list archive of debian-legal.  Most of the software
licenses that are reviewed there have been written by organizations that
wants open source-friendly distribution of their code, but happens to
make one mistake or the other.

If people involved in free software licensing have trouble getting this
right, I have little confidence that people not involved in the free
software licensing will get the right.  Providing them with some
mechanism to test their proposed license against (i.e., the
OSD/FSD/DFSG) will help to avoid at least the most basic mistakes.

Ray asked if there were some reason to not use the NPOSL for this.  I
read that to imply that he thought the license would be a candidate.  If
my proposed text has been part of the documents, we could easily explain
how and why that license doesn't meet a needed criteria.

Thanks,
Simon

> Yours,
> Joel
>
> Simon Josefsson wrote:
>> "Joel M. Halpern" <[e-mail]> writes:
>>
>>> I do not understand the problem you want addressed.  The way this
>>> is worded, it doesn't matter what "open source" or "free software"
>>> is or becomes.  The intention is to grant anyone to do anything
>>> with the code segments.  That's what we ask the trust to
>>> do. Further in line.
>>
>> The problem is that without proper guidelines on how to make a software
>> license compatible with free software licenses, it is possible to end up
>> with something that won't be compatible, and thus wouldn't meet the
>> intended goals.
>>
>> Given that the IETF Trust doesn't publish drafts or have a history of
>> asking for community review on the legal license they chose, I believe
>> it is important that the IETF articulate its wishes in ways that reduce
>> chances of misunderstandings or are open for interpretation.
>>
>>> Simon Josefsson wrote:
>>>> Regarding -outbound section 4.3:
>>>>
>>> ...
>>>>    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.  To
>>>>    enable the broadest possible extraction, modification and usage, the
>>>>    IETF Trust should avoid adding software license obligations beyond
>>>>    those already present in a contribution.  The granted rights to
>>>>    extract, modify and use code should allow creation of derived works
>>>>    outside the IETF that may carry additional license obligations.
>>> This says that the trust is to grant rights so that code can be
>>> extracted, modified, and used by ANYONE.  I.e. our grant will not
>>> place restrictions on people.
>>
>> Agreed.
>>
>>>> I believe the intention here is good, but it leaves the IETF Trust with
>>>> no guidelines on how to write the license declaration that is likely to
>>>> work well in practice with actual products.  There are no reference to
>>>> what "open source" means in this context, and references to "free
>>>> software" is missing.
>>>>
>>>> I believe it would be a complete failure if code-like portions of RFCs
>>>> cannot be included into open source and free software products such as
>>>> the Debian project.
>>> If we grant anyone the right to use the code any way they want,
>>> which means that we specifically can not require preservation of
>>> notices or anything else, how could it fail to meet the
>>> requirements of the specific cases you list?
>>
>> If you show me the software license that is going to be used, the
>> community will be able to tell you.
>>
>> Writing software licenses that are compatible with free software
>> licenses is a complicated area, and there are many ways to fail.  If you
>> haven't evaluated licenses for compatibility before, I suggest to look
>> at what the debian-legal list has been doing.  There are subtle issues
>> that can prevent a license from giving the necessary rights.  As far as
>> I know the IETF Trust does not have extensive knowledge of free software
>> licensing and license compatibility considerations.  Helping them to get
>> this right by providing some sanity tests (the OSD, FSD and DFSG) to run
>> their drafts against will help them.
>>
>>>> To give the Trust something concrete to work with I propose to add the
>>>> following:
>>>>
>>>>   To make sure the granted rights are usable in practice, they need to
>>>>   at least meet the requirements of the Open Source Definition [OSD],
>>>>   the Free Software Definition [FSD], and the Debian Free Software
>>>>   Guidelines [DFSG].
>>>>
>>>> For those who fear that this will lead to complexity: releasing
>>>> something that is compatible with those requirements is simple.  The
>>>> modified BSD license meets those requirements, as does a number of other
>>>> methods, including releasing the work into the public domain.
>>> My concern is not complexity.  Referencing the specific documents
>>> is more restrictive than what the working group recommended.  I
>>> don't see why that would help anything.
>>
>> Please read again what I proposed, in particular "at least meet the
>> requirements".  If the Trust's software license do not meet those
>> requirements, then it clearly will not meet the intended IETF goals that
>> we agree on.
>>
>> /Simon
>>
_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf