[License-review] Some notes for license submitters

[Kyle Mitchell]

On 2018-06-19 22:06, Bruce Perens wrote:
> 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.

It's hardly over where I keep the watch!

The majority of open source contributors and companies I've
worked with see the identity of "open source" and license
terms as historical trivia.  They usually haven't heard of
OSI or OSD until I mention them, and OSI would seem _less_
"open source" in their eyes for hosting its own mailing list
to avoid GitHub.

These folks aren't slapping "All Rights Reserved" on
anything.  Neither are they receiving C&Ds.

I'm not here to push that party's program.  But
license-review shouldn't pretend they don't exist, or that
they're all unread fools who'll grow up, do their homework,
and start paying dues.

>    - 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.
>
> ...
>
> I am not suggesting that we lobby for a public performance right in
> software. Expansions of intellectual property protection do us harm.

And here is the root of our different points of view on
reciprocal licensing today.

With G Suite in OSI's back-office, and GitHub the leading
contender for license-review 2.0, the hosted-service problem
has hardly been disposed of.  Rather, the hosted-service
problem has largely disposed of copyleft: put it out to
pasture without its teeth, behind company lines, within
legacy systems, crying foul to stop GPL-AGPL merger at v3.

The same method by which AGPL "synthesizes" network copyleft
has been used to synthesize all manner of other use-like
restrictions, before and since.  We've written so many
internal-business-use, n-seat, in-territory, resource-usage,
and other limited, proprietary licenses in industry that
they've hit the courts.  And they've been enforced---and
settled dearly---however theorized.  Those proprietary
licenses run on the same copyright operating system open
source does. The functionality is there.

Perhaps so many years back, a hard line on use restrictions
felt like it had a shot.  FSF posts still claim use
restrictions aren't possible, and Nimmer switches off
Treatise Mode to go full amicus curiae in the relevant part.
But 117 and some patent push-back notwithstanding, IP
expansion continues in full swing.  A constant reminder that
our policy preferences aren't the legislators'.  That the
law merely _accommodates_ our preference, via licensing, at
considerable documentary inconvenience.

I agree that IP policy has gone too far.  But protozoan open
source was as much about confidentiality and trade secrecy
as permission.  Pivoting off copyright gave copyleft
leverage on source availability.  The dual nature problem
hasn't changed. Minimizing IP by opting out of its default
rules is necessary, but not sufficient, for software
freedom.  Repealing the Copyright Act wouldn't make software
free.

Long story short, we have the track record to write the kind
of license McCoy dubbed "maximaleft".  And some of us see
the motivation.  That project's ongoing.

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

And also the issue of dev-tools package managers.  Only with
that addition can we really start to talk about npm, given
the front-end-versus-server-side usage metrics.

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

Don't forget OSL!  Or GPLv3, section 2, paragraph 1, for
that matter ;-P

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

They call patent litigation the sport of kings.  Is open
source their potlatch, their feast of merit?

I think that view is internally consistent, but also
profoundly, terribly exclusionary.  Most people have to ask
how they're going to make money, pretty much all of the
time.  And insofar as open source would compete with
proprietary alternatives, it's asking a lot to forgo all
direct compensation-incentive, and play in the major leagues
with that kind of handicap.

> Nowhere in the mission of OSI is any mandate to provide
> authors with a viable business method.

Granted: OSI's mission is completely silent on business
models.  Why invoke business model in the _other_ direction,
repeatedly, to cast aspersions on L0-R?

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

A number of open source companies have gone public or sold
well in the past few years, and the past few weeks.  Some of
them produced less money than everyone would have liked. But
not because they stuck to business models that make no money
on their own.

The community is diverse.  There have always been factions
and differences of opinion.  We each represent where we come
from.  Anointing one faction or approach "the community"
doesn't resonate with others, even in plurality coalition on
a particular issue.

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

Google doesn't blacklist AGPL because they heard some FUD or
lack understanding!  They can and do teach copyleft, and
well.  Their published open source documentation is as much
about releasing as consuming open source.

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

AGPL is extensively used.  For industry examples, see
MongoDB or Neo4j.  For highly decentralized hacker efforts,
see Secure Scuttlebutt or Mastodon.  But many
permissive-license users would use a strong reciprocal
license they feel they can understand without delegation.

Part of what inspired L0-R was holes in AGPL's coverage. Dev
tool authors want a reciprocal license.

But part of the inspiration was simple confusion and
bewilderment around GPL, its history, its scope, its length,
and so on.  To my knowledge, there was no short,
academic-style, hacker-administrable reciprocal public
license form until L0-R, especially the 2.0.0 draft.

Hacker-types still favor MIT/BSD over Apache 2.0.  Facebook
followed suit after the PATENTS tragicomedy.  If you don't
trust FSF---or OSI for that matter---and you don't have a
legal department large enough for an open licensing wonk,
you want a license you can read.  You want a purpose-built
tool that directly expresses your purpose, and little more.

-- 
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933