Development of Creative Commons licenses

["David Christie" <dc AT sover.net>]

> Greg London said:
>
> Sleepycat doesn't sell a "commercial" license,
> they sell a "non-copyleft" license.
> GPL allows anyone to sell Sleepycat.
> What Sleepycat sells is a license that allows
> someone else to combine that work with
> non-GPL code.

Yes. Although technically Sleepycat's license isn't the GPL. It has 
copyleft, and you are exactly right about what it does.

Sleepycat does refer to what they sell as their "commercial" license. 
Perhaps your terminology is better. Clearly they shouldn't call their gratis 
license "non-commercial" (though their marketing people have been known to 
do so). Since "copyleft" is an opaque term to most non-developers, I like 
Lessig's "Share-alike". He's doing us a service by foisting those terms and 
pretty symbols on the world. I hope they stick.

> But to do that, sleepycat cannot accept
> ANY code contributions from any outside individuals.
> If Sleepycat consisted of Alice, Bob, and Charlie,
> then they cannot accept code contributions from
> Dave unless they get Dave to reassign copyright
> ownership to sleepycat.

I agree again.

> Which means that Sleepycat does not benefit from
> the usual outside contributions that occur in a
> copyleft project. Sleepycat can be USED by copyleft
> projects, and Linux and other projects can modify
> it and include it with their distributions, but
> the version sold by Sleepycat does not include
> any of these outside contributions.

Sleepycat can include non-copyleft open source code from outside sources. 
They could include the Apache Portable Runtime (APR) if they wanted to, 
because Apache does not use copyleft.

And they can contract with the contributors to assign their copyrights back 
to Sleepycat. But Sleepycat cannot just expropriate those contributions, 
made under a copyleft license, for inclusion in their SOLD product.

I believe they do engage in such contracts, e.g. their Java binding was done 
by an external contributor (I think). But yes, they have to get permission 
from such outside developers (who may even demand to be paid). Is that bad? 
It seems a good thing to me.

> Which means that the version SOLD by Sleepycat
> is ZERO generations removed FROM Sleepycat.

Yes, agreed. It has to go back to them. They remain the authority for it. 
Again, what you sell ought to be something for which you are the 
authority -- we agree on that, don't we?

> You can do this now with CC-SA.

Yes. Sleepycat's license (for their gratis product) is like CC-SA.

> This is vastly different than Share-Revenue
> in which Alice releases a work to the world CC-SR,
> and Bob, Charlie, and Dave contribute work to it,
> and then when Eve comes along and wants to use the
> work commercially, she pays Alice money and gets
> a license.

Yes, it's different.

Eve gets the license without paying anything -- everyone does.

For the sake of example, let's say the license is CC-BY-SA-SR. The license 
gives everyone the right to use the work non-commercially and distribute it 
under the same terms.

The only right that is compromised is the right to collect revenues for 
doing so. The license says you must share revenues (iff you collect any 
revenues) with the copyright owner.

Eve can use Alice's original work and collect revenues using it if she 
shares them with Alice -- on the "default terms" of 10% of her gross, or 
other terms negotiated with Alice. In practice, if Alice expects anyone like 
Eve to do this, she had better make such negotiations simple and painless --  
e.g. by posting prices and contracts on her web site, and taking credit 
cards.

So far there is a single copyright owner for the entire original work 
(Alice), so things are simple.

> And if you want a license that allows Bob, Charlie,
> and Dave to get some of the money, then you're
> back to the finite resources of the royalties
> (a commons) and you've got to figure out how much
> goes to whom, and you've got to decide who you
> are going to accept contributions from and
> include them on the "royalty list".
>
> At that point, you're no longer dealing with a
> simple copyright license. You're talking about
> a contract between many parties.

It does get more complicated if Eve wants to collect revenues for using 
Bob/Charlie/Dave's derivative work. But not as impossible as you make it 
seem. The most common cases are fairly workable. Which is NOT to say they 
resemble how Linux development works; when money is involved, everything 
changes!

Let us count the ways it could play out:

1.  Bob/Charlie/Dave are open source developers who don't demand 
remuneration. They are happy if no one pays them for their contribution, 
which was motivated by needing a new feature, not by needing to feed their 
families. They can assign copyright to Alice, and leave it to her to roll it 
into her next release.

Of course, in this scenario Bob/Charlie/Dave must live with the notion that 
Alice may get paid (partly for their work) from future revenue-collecting 
customers. If this offends them, that would remove their incentive to make 
the contribution in the first place.

So having imposed Share-revenues, Alice must try to be a good steward of 
those revenues, and perhaps share them with contributors who helped to 
improve her work, or she won't long have a reputation as someone worth 
helping.

If Alice is smart, she'll be careful to return all such favors somehow --  
perhaps she'll send business their way, or even (at some point) a thank-you 
check. Perhaps she'll pay annual dividends to all developers who made 
unsolicited contributions during the last year, setting aside a per centage 
of her net revenue for that purpose. Perhaps she'll donate publically to 
worthy causes dear to the hearts of open source developers. But it's up to 
her -- it's voluntary.

One possibility is that Alice is a non-profit of some kind. She doesn't keep 
any of the money for her personal profit (OK, maybe she gets paid a salary), 
and the non-profit does socially useful work. The revenues from commercial 
customers pay for this work. Maybe the work is just software development, or 
maybe it's something else the software revenue just helps pay for.

2. Bob/Charlie/Dave implement a major new subsystem to Alice's work, or 
embed Alice's original work in an entirely new application of their 
devising. They are not happy just giving this work to Alice. They may need 
to contract with Alice. Maybe even before they do the work, to be safe.

They already have a license to use Alice's work if they don't collect 
revenue. And because it is SA as well as SR, their users get this license, 
too. So the first thing to note is that if no one makes any money by using 
the work, no contracts are needed.

But if they want to get paid, Bob/Charlie/Dave need to get together. They 
need a partnership, a company, joint membership in a cooperative, or some 
kind of business relationship defining how their product revenues will be 
divided, who will make decisions, etc. Need I say more about how they might 
do that? Let's say they form BCD Partners Inc.

If someone downstream does collect revenue using the derivative product 
without a contract, both Alice and BCD have the right (separately) to demand 
10% of their gross. This happens because the BCD contribution is copyrighted 
in their name, not Alice's. The derived work has two copyright owners, 
because at least some modules originated with BCD and carry their copyright 
instead of Alice's.

Does this mean the user is potentially liable for 20% of his gross? I 
suppose so, and that's peculiar. But remember, 10% or 20% doesn't really 
matter -- these are really just punitive damages we're talking about here. 
Absent a contract, there is really no practical way for users to legally use 
the derivative work commercially. Effectively SR is NC unless you contract 
with the copyright holder. You're subject to damages, in effect (if you get 
sued). That's deliberate.

Now, BCD won't get many commercial customers if the poor customers have to 
contract with multiple copyright holders to get rights to use the product 
commercially. (That is what makes clearing intellectual property rights for 
scenes in a film so hard, and it's a bitch.) So sombody has to be a 
single-point distribution authority. BCD and Alice have three choices:

(a) BCD contracts with Alice to pay her a portion of the revenues they 
collect from their customers, or a flat fee, or whatever they negotiate; 
such a contract gives them the right to redistribute their derived work, 
including Alice's copyrighted source code; the derived work has multiple 
copyright owners but customers don't care because they can purchase 
commercial use rights from BCD without knowing anything about Alice; BCD 
pays Alice per their agreement.

(b) BCD contracts with Alice to act as the distribution authority for their 
product; maybe Alice is not just a person, maybe she's an organization, with 
a big web presence and a suite of products; maybe Alice would love to have 
the BCD application to sell, along with her original work; after all, it 
includes her original work and she makes money when that sells; in this case 
Alice publishes the work for BCD, collects from the commercial customers, 
and pays BCD per their agreement.

(c) BCD and Alice can bring in a third party to be the distribution 
authority (publisher); maybe none of them want to bother collecting money, 
or have the visibility to advertise the product; maybe the derived work is 
best sold by some third party already established in its market sector.

So the authority to distribute the commercial product can be given to 
anyone, but in practice it has to be given to someone, so the commercial 
customer can buy from a single point. Buying can't be a three-way or n-way 
transaction; who would put up with that? There can be multiple authorized 
distributors. A contract is required to authorize each one. The simplest 
models are (a) and (b) where the contracts are two-party; (c) requires a 
three-party contract to set it up.

These contracts harness a completely different motivation than what makes 
developers contribute to Linux or Apache. I'm not recommending it for 
projects like that. But contracts like these have been used for many open 
source projects. When InnoDB was written (a complex new transactional engine 
for MySQL) the contracts that made it profitable must have happened somehow, 
and (apparently) everyone is profitable now. InnoDB is useful only as part 
of MySQL, and therefore two companies are sharing the revenue stream from 
each sale. And it's all open source. InnoDB.com is essentially like BCD and 
MySQL.com is Alice, in case (2) above.

MySQL.com has similar arrangements with Sleepycat, which provides an 
alternate transactional engine used in MySQL. Unlike InnoDB's engine it has 
an open API and is also sold for use in many other products and 
applications. And it's all open source.

Now, none of these examples use my Shared-revenues provision, of course. 
They all rely on copyleft and selling exemptions to users who need to 
distribute with proprietary code in the package. So why have SR at all? To 
enable new business models. Web sites and other installations that use MySQL 
to power the site, but don't distribute the code, don't have to pay a cent 
for MySQL, InnoDB, or Sleepycat's BerkeleyDB, even when they use them 
commercially. Now, MySQL is a great public good and I'm glad it's as free as 
it is; but you might not want to license your next product that way if it's 
designed to power web sites and you want to get paid when it does so. Does 
that mean you can't use open source development? I don't think it should.

The biggest drawback to SR is that it isn't OSI-compliant. It restricts 
commercial use. This means there isn't any copylefted software out there 
that it can derive from.

The next biggest drawback is that SR isn't real "open source" according to 
the de facto OSD recognized by most developers, even though the source _is_ 
available. So, as you point out, developers won't be likely to volunteer to 
contribute code gratis.

On the other hand, copyleft is fully OSI-compliant, even when it's imposed 
specifically to allow developers to collect revenues by selling exemptions 
to it. Though that practice also discourages volunteers, as you note.