[License-review] Some notes for license submitters

[Bruce Perens]

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

> 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
>
...

> MPL 2.0 responded to in various subtle but important ways
>

Thank you for the trip back to 2012, Luis.

That's when you wrote about the "post Open Source" movement that was more
about copyright naivete than anything concerning Open Source. As soon as
people realized what "All Rights Reserved" meant, that was over.

Similarly, it was January of 2012 when MPL 2.0 was released. GPL3 is 10
years old now. This is not really an effective argument that we need to
adopt licenses faster.

   - What does a network services license look like in a microservices
   world? what about serverless? what about a Javascript-dominated world?

We don't have a public performance right in software, so we end up
synthesizing one as Affero did. I was at the meeting in New York called by
Bradley Kuhn in the early 2000's where the problem of Google was discussed
and disposed of. Given the lack of law to build upon, we don't have any
better solutions since then. Javascript in the browser is redistributed
software and has to be handled similarly to present redistribution-based
licenses. Javascript in the server requires that we synthesize a public
performance right as Affero does.

I am not suggesting that we lobby for a public performance right in
software. Expansions of intellectual property protection do us harm.

   - 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.)

App stores and package managers, vs. Github have a very different audience.
We don't particularly need to burden users, thus app stores and package
managers. There is the issue of a library package manager, but at that
point we're creating derivative works.

You need to look at the license when you are doing one of two things:
creating a derivative work and redistributing. I was tempted to add
performing to that list, but if you are only performing as SaaS without
modifying the software, it was redistributed to you (activating more
conventional license terms) and it should be distributing its source code
at its interfaces as required in an Affero license.

   - How should drafting respond to license wizards, CC-style
   human-readable licenses, and other attempts to make licensing "easy"?

Writing a CC-style license deed is actually a separate act from writing the
license, and it's not even necessary for the license owner to do it.
Similarly, wizards incorporate an act of interpretation that the license
author need not participate in. The lawyer-in-a-box quality of wizards and
deeds create risk for the user and implementor.

A bolder new license might consider:

   - What does an economically viable open source look like?


My usual answer for this is that if you have to ask how you're going to
make money, you're the wrong person to make Open Source. Nowhere in the
mission of OSI is any mandate to provide authors with a viable business
method.

Certainly lots of business methods exist and have been exhaustively
documented over the years. But a lot of the business methods are actually
at odds with the community.  The most viable Open Source business method,
historically, has been non-differentiating collaboration, which I
documented in 2005. It produces *no* money on its own, but frees the
collaborator to spend more on their business differentiators. Most of our
business collaborators are using this method.

   - How do you get Facebook, Amazon, Google, Twitter, etc., on board with
   a network services copyleft?

Reverse their current behavior. Most of them have a policy not to touch
Affero *because *it has a network services copyleft.
First, we have to stop the FUD regarding share-and-share-alike licensing
like GPL and Affero, and educate companies that copyleft actually protects
them from having competitors run away with their own projects without
sharing anything. Most companies only consider licensing from the viewpoint
of a receiver of the work rather than the producer.

   -  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.

I'm not sure that "pragmatic" has anything to do with the actual license
terms. The SaaS folks don't engage in Tivo-ization, which is the major part
of the modern GPL3 license family that some people think isn't pragmatic.
And in any case you can write an exception around it, if you don't like
that term.
It might be that they don't like the prologue, the FSF's mission, or
Richard as a person. But this isn't really about license terms.

   - The vast, gaping hole in this area is a damning condemnation of our
   work as an open legal community.

I'd agree if an effective license to do just what you're talking about did
not already exist and had not been long accepted by OSI. The reasons they
aren't being used don't seem to be primarily related to the license terms.

   - 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.

It's a bit overboard to view it as a legal system. Open Source is a
marketing program for a particular form of intellectual property practice,
and we approve licenses that match that practice. Free Software is another
similar marketing program that approves licenses that match its pre-defined
form of practice, which is effectively identical to ours.

    Thanks

    Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20180619/0f8be4e9/attachment.html>