[License-discuss] Developing a new open source license

[VanL]

Hi Bruce,

I welcome feedback and criticism. No need to apologize. Heaven knows, I
have given criticism and feedback in the past, and I hope it was taken as
constructive. I think that approaching this whole process with some
humility is definitely warranted.

Let me address a couple of your points. With regard to OSD #9, I am trying
to be particularly careful about this point, as I was one of the ones
pointing out that this was a particular problem with the SSPL. Given the
law as it is/as I expect it may turn out in the next several months, the
SSO of the interface is an integral, copyrightable part of the work, and a
reimplementation of that SSO is thus a derivative work. If something is a
derivative work, then, by my reading of both the OSD and copyright law, I
believe that a license can ensure that the licensing of the derivative
follow certain rules.

Thus, it is not restricting "other" works, it is restricting derivative
works only.

With regard to the policy aspects, this is (as I mentioned in the message
to McCoy) not where I think the ideal policy is, but a reflection of the
probabilities right now. If there is a problem with standards, it would not
be because of *this* license.

Thanks,
Van






On Thu, Jan 31, 2019 at 11:52 AM Bruce Perens <bruce at perens.com> wrote:

> Van,
>
> With all respect and understanding of the motivations of the group behind
> this, I have a really big problem with this part:
>
> Unlike other current open source licenses, the Autonomous Agent License
> will require software that implements a compatible API or publicly performs
> the API to also be open source.
>
> I am the standards chair of the Open Source Initiative. *If the provision
> you propose in this license was used by standards associations, they could
> trivially prohibit Open Source implementations of their standard APIs.*
> This is obviously something that OSI would have to fight in court.
>
> Thus, it's a really, really bad idea for OSI to stand for such a provision
> by approving a license containing it.
>
> Also, almost trivially compared to the above issue, this obviously
> violates OSD #9.
>
> So, unfortunately I really have to recommend in the strongest way that a
> license incorporating that term not be approved.
>
>      Sorry
>
>      Bruce
>
> On Thu, Jan 31, 2019 at 9:17 AM VanL <van.lindberg at gmail.com> wrote:
>
>> Hello all,
>>
>> I have been retained to help develop a new, strong copyleft open source
>> license for a client, Holo Ltd. We have been going back and forth
>> internally for a little while and we will shortly be putting out a draft
>> for public comment. After the public comment period, we will be submitting
>> the license to the OSI for certification.
>>
>> I will also be discussing this license in my presentation at CopyleftConf
>> on Monday.
>>
>> In the meantime, some of the underlying reasoning for why we need a
>> different open source license is being presented on Holo's blog. The first
>> post is up now, and the second will be up in a couple days:
>>
>>
>> https://medium.com/h-o-l-o/why-we-need-a-new-open-source-license-c8faf8a8dadd
>>
>> Comments are welcome.
>>
>> Thanks,
>> Van
>> _______________________________________________
>> License-discuss mailing list
>> License-discuss at lists.opensource.org
>>
>> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>>
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190131/1d244aab/attachment.html>