[License-review] Some notes for license submitters

Wed Jun 20 04:18:26 UTC 2018

I agree with the point that OSI, and OSI-approved licenses, shouldn't stay
trapped in amber, but I have to take issue with the idea that the problem
is specific to open source and that outside of open source, software
licenses have changed radically to adapt to changing technological and
economic circumstances. At least, I don't think I've seen this in
proprietary commercial software licenses at all, beyond the fact that
negotiated agreements can address specific issues and circumstances in ways
that form agreements are less likely to. I'm generally struck by how
conservative, technically and perhaps legally clueless and hidebound
contemporary proprietary software license agreements tend to be - though
not in the same way as open source licenses, which are vulnerable to
similar criticisms.

Richard

On Tue, Jun 19, 2018 at 11:57 PM, Luis Villa <luis at lu.is> wrote:

> [Changing the subject line back for those who'd like to ignore tools
> discussion or vice-versa]
>
> The software industry has a completely different economic and
> technological infrastructure than it did when OSI was founded and when most
> of these licenses were written. Every other software licensing agreement in
> the industry has changed radically since the mid-2000s as a result. It is
> not healthy that the OSI's license selection (and possibly the OSD) have
> not followed suit. Frankly, I think a lot of the "post open source
> <http://lu.is/blog/2013/01/27/taking-post-open-source-seriously-as-a-statement-about-copyright-law/>"
> thing is really "open source licenses are nearly completely unresponsive to
> the software industry as it actually exists in the year 2018".
>
> I'm pretty sure that, contra Bruce, it isn't OSI's position that open
> source needs to stay forever trapped in amber, but a reasonable outside
> observer (like Kyle!) could certainly conclude otherwise.
>
> Luis
>
> P.S. To respond to the claim that licensing improvements are no longer
> possible, significant input that MPL 2.0 responded to in various subtle but
> important ways:
>
>    - various cases around the covenant / condition difference (thanks in
>    part to members of this list)
>    - then-state-of-the-art changes in Javascript compilation (shouldn't
>    be any unexpected surprises there, unlike the case for some licenses)
>    - vast improvements in readability to reflect the broadening base of
>    open source developers who lack legal expertise
>    - GPL v3-style termination
>    - explicit permission for additional disclaimers (has proven very
>    useful in the medical space)
>    - patent termination that reflected the actual mechanisms by which
>    patents were being granted to open source communities (which, IMHO, we'd
>    all be better off if Apache and FSF adopted)
>
> And that's just off the top of my head, in a license that had as a
> deliberate design goal not rocking the boat.
>
> Changes since then that even a fairly conservative new license might
> consider responding to:
>
>    - What does a network services license look like in a microservices
>    world? what about serverless? what about a Javascript-dominated world?
>    - How should notice requirements respond to state-of-the-art in app
>    stores, package managers, GitHub, SPDX, and general trend towards
>    "WTFPL"-attitude in next-generation open source development? (What current
>    licenses *say*, and what all these *do*, are often at odds in ways that
>    would be very profitable for a determined troll.)
>    - How should drafting respond to license wizards, CC-style
>    human-readable licenses, and other attempts to make licensing "easy"?
>
> A bolder new license might consider:
>
>    - What does an economically viable open source look like?
>    - How do you get Facebook, Amazon, Google, Twitter, etc., on board
>    with a network services copyleft? When you talk to people at these places,
>    many of them would like to prevent free-riding by their competitors, and
>    would look very seriously at a network copyleft that was perceived to be
>    pragmatic. The vast, gaping hole in this area is a damning condemnation of
>    our work as an open legal community.
>    - How should we think about our role as an extra-institutional legal
>    system? Eben and Richard took some good steps there by documenting
>    everything (in recognition of the quasi-constitutional nature of the
>    license) but I think there's a lot of potential to explore here.
>
>
> On Tue, Jun 19, 2018 at 7:28 PM Bruce Perens <bruce at perens.com> wrote:
>
>> OK, so not just whether it passes the OSD but whether it provides any
>> unique value, too.
>>
>> Sure we need new licenses for new case law. But how many of the licenses
>> submitted actually *were *an attempt to catch up with new case law?
>> There hasn't been much other than GPL3.
>>
>>     Thanks
>>
>>     Bruce
>>
>> On Tue, Jun 19, 2018 at 7:18 PM, Allison Randal <allison at opensource.org>
>> wrote:
>>
>>> Hi Bruce,
>>>
>>> I'm a firm supporter of the license proliferation position that the OSI
>>> adopted over a decade ago, and we do continue to consider whether a new
>>> license is offering unique value.
>>>
>>> But, I consider it highly unlikely that we have such a perfect set of
>>> open source license versions today that we'll never need to change them.
>>> Especially since the law that open source licenses are built on keeps
>>> changing, so over time open source licenses will need to evolve to cope
>>> with a legal environment that the current licenses couldn't anticipate.
>>>
>>> Allison
>>>
>>> On 06/19/2018 06:02 PM, Bruce Perens wrote:
>>> > Allison,
>>> >
>>> > The biggest problem here is not that OSI is slow to approve licenses,
>>> > that they provide insufficient feedback, or that they are using the
>>> > wrong software.
>>> >
>>> > It's a greater problem that OSI continues to approve licenses on a
>>> > regular basis, twenty years after the process started.
>>> >
>>> > There aren't that many actually useful variations on the licenses that
>>> > actually pass the OSD. There are actually only three useful licenses, a
>>> > gift-style, a sharing-with-rules-style, and something in between. Given
>>> > Affero and GPL3 terms on those three, essentially all purposes for Open
>>> > Source can be carried out. All else is embellishment.
>>> >
>>> > What we are seeing now are licenses that satisfy a particular attorney.
>>> > These are often introduced as being necessary for the specific needs of
>>> > the venue (Europe, for example) or a particular organization (NASA,
>>> > focusing on restrictions on the public domain). It's arguable that
>>> these
>>> > licenses are more useful than existing well-tested ones, even for those
>>> > organizations. For example, I don't see how NASA can /really /benefit
>>> > from imposing terms upon public-domain works or making itself a
>>> > secondary beneficiary of licenses executed by others.
>>> >
>>> > The license reviewers aren't waiting to be surprised by some worthy
>>> > innovation in Open Source licensing. No such thing is coming by. They
>>> > are mainly working to make sure that OSI understands when a license
>>> > should be rejected, and why.
>>> >
>>> > If OSI were to conclude that licenses, at this point, should be
>>> approved
>>> > only when there are /compelling /reasons to do so, the community would
>>> > benefit.
>>> >
>>> >     Thanks
>>> >
>>> >     Bruce
>>> >
>>> >
>>> > _______________________________________________
>>> > License-review mailing list
>>> > License-review at lists.opensource.org
>>> > http://lists.opensource.org/mailman/listinfo/license-
>>> review_lists.opensource.org
>>> >
>>>
>>> _______________________________________________
>>> License-review mailing list
>>> License-review at lists.opensource.org
>>> http://lists.opensource.org/mailman/listinfo/license-
>>> review_lists.opensource.org
>>>
>>
>>
>>
>> --
>> Bruce Perens K6BP - CEO, Legal Engineering
>> Standards committee chair, license review committee member, co-founder,
>> Open Source Initiative
>> President, Open Research Institute; Board Member, Fashion Freedom
>> Initiative.
>> _______________________________________________
>> License-review mailing list
>> License-review at lists.opensource.org
>> http://lists.opensource.org/mailman/listinfo/license-
>> review_lists.opensource.org
>>
>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-
> review_lists.opensource.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20180620/bb7910f6/attachment-0001.html>