[License-review] For Legacy Approval: TOPPERS License

Tue Aug 4 04:20:30 UTC 2015

Hello all,

Are there any concerns in this topic?
I hope that voting to approve the TOPPERS License would be carried out 
sometime soon.

Thanks,
Yutaka

On 7/25/15 20:42, Yutaka MATSUBARA wrote:
> Dear Carlo,
>
> Thanks for the reply.
>
> On 7/24/15 10:38, Carlo wrote:
>> Dear Yutaka,
>>
>> some replies inline.
>>
>> Something went wrong with the mailer, the thread is not really readable
>> as per the standard way of nested discussion.
>>
>> On 22/07/2015 08:07, Yutaka MATSUBARA wrote:
>>> Hello Carlo and other members,
>>>
>>> Sorry for my late response.
>>>
>>> On 7/9/15 20:53, Simon Phipps wrote:
>>>> Hi there Yutaka,
>>>>
>>>> On Tue, Jul 7, 2015 at 8:37 PM, Yutaka MATSUBARA <yutaka at ertl.jp
>>>> <mailto:yutaka at ertl.jp>> wrote:
>>>>
>>>>      Hello Carlo,
>>>>
>>>>                   (a) The above copyright notice, this use
>>>> conditions,
>>>>              and the
>>>>                       disclaimer shown below must be shown without
>>>>              modification in
>>>>                       the document provided with the redistributed
>>>>              software, such as
>>>>                       the user manual.
>>>>
>>>>
>>>>          The example is clear, but why is it not sufficient to
>>>>          accompany any
>>>>          distribution in such a form with a copy of the license
>>>> itself?
>>>>
>>>>
>>>>      The form with a copy of the license itself meets (a) clearly.
>>>>      Do you have a concern?
>>
>> So why you simply don't use one standard language (like the one in the
>> GPL v.3 for instance) saying that any distribution must be accompanied
>> with a copy of the license, and be done? I understand sometimes you
>> have
>> to deviate from standard practice, but here I don't see a rationale,
>> and
>> any unnecessary complication can lead to unnecessary confusion.
>
> I understood your intention. But, I think that this is not critical.
> Thank you for the advice.
>
>>>>
>>>>                   (b) How the software is to be redistributed must be
>>>>              reported to the
>>>>                       TOPPERS Project according to the procedure
>>>> described
>>>>                       separately.
>>>>
>>>>
>>>>          If this was the only option available, this would make the
>>>> entire
>>>>          license strikingly non-compliant, IMHO. In addition,
>>>> reference
>>>>          to a
>>>>          specific project ought to be omitted, otherwise the license
>>>> would
>>>>          practically be limited to a single use -- a one-way free
>>>> ticket to
>>>>          proliferation.
>>>>
>>>>      > I would advocate that, because the condition under b) is
>>>> non-compliant,
>>>>      > it should be removed for the license to be approved.
>>>>
>>>>      I think that if a user can do (b), then the user can do (a)
>>>> as well.
>>>>      What kinds of situations do you imagine?
>>
>> This is what I mean. In any case, b) is useless, and why give an
>> exemption to a), which is the standard way to ensure certain notices
>> are
>> preserved, to those who comply with b), which does nothing to foster
>> openness and freedom, and is uncompliant with OSD as well?
>>
>> Therefore, I advocate that it must be removed.
>
> I don't agree with you. I think OSD does not require users of
> OSD-compliant software to guarantee and foster openness and freedom of
> their derived software. TOPPERS license is permissive compared to GPL.
>
> I think 3) is compliant with OSD because it *ALLOW* users of software
> with the TOPPERS license to modify and redistribute their software
> based on it by a) if users want to do so. If users prefer not to
> foster their modified software, they can choose b).
>
> What do you think?
>
>>>> I am still concerned that the license could result in situations
>>>> where
>>>> a developer is unable to ensure a document is included with the
>>>> software they are distributing (imagine a portion of the code is
>>>> excerpted and used in an embedded function in a hardware component
>>>> used for constructing other products). In this event, (b) would be
>>>> the
>>>> only option and it is clearly not OSD compliant. As such I don't
>>>> believe the license as a whole can be OSD compliant.
>>>
>>> I understood that the event (a portion of the code is excerpted and
>>> used in an embedded system) can be occurred. But, other OSD-compliant
>>> licenses such as BSD Licenses could result in the same situation
>>> (where a developer ...).
> e>>
>>
>> BSD is not the best example IMHO, and in this case it is ambiguous
>> as to
>> what happens if no documentation is distributed with the software. But
>> one can argue that in this case only the copyright notice should be
>> preserved somewhere.
>>
>> Just to show how BSD was bizarrely written, the advertising clause was
>> conceived to apply even separately from the actual distribution (and
>> for
>> how long?). Wisely it has been recalled.
>>
>> Anyhow, this is a sort of ad hominem argument, I don't like to follow
>> this way of discussing.
>>
>>> If your concern is common, I guess that a developer is also unable to
>>> ensure a document is included with the software in case of BSD
>>> Licenses. What do you think about it?
>>
>> Ditto. I can read that license in a way that in this case it is
>> exempted.
>>
>> To be clearer, I do not think that requiring that the text of the
>> license is distributed along with the software is non compliant with
>> OSD. I speculate about the fact that in some environment it encourages
>> following a different rule, which is non compliant.
>>
>>>
>>>> Remember, open source code is frequently excerpted outside the scope
>>>> of the original project, even if you are not aiming for that. In
>>>> addition, OSI approves licenses for general use not just for your
>>>> use.
>>>
>>> I understood the above intention.
>>
>> Fine
>>>
>>>>      Several licences including names of specific projects/companies
>>>>      have been already approved. I think that these licences seem
>>>> to be
>>>>      limited to use cases. What differences between these licenses
>>>> and s
>>>>      TOPPERS license do you see?
>>>>
>>>>
>>>> Indeed, licenses were historically approved with specific names in
>>>> them. Since the anti-proliferation discussions OSI hosted nearly a
>>>> decade ago, we have been avoiding new licenses that refer to specific
>>>> projects. The license should be genericised for anyone to use before
>>>> being approved.
>>>
>>> Is it an official and unified comment from the OSI committee that OSI
>>> does not approve new licenses that refer to specific projects? Please
>>> let me know where it is noticed in the OSI website.
>>
>> I think this is clearly stated many times in this discussion list.
>> But I
>> think this is a matter best left to the Board to discuss with you.
>
> I would like to discuss with the Board about this matter.
> Are there any ways for that?
>
> Thanks,
> Yutaka
> _______________________________________________
> License-review mailing list
> License-review at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review