Skip to Content.
Sympa Menu

cc-licenses - Re: Share-revenues as an alternative to Non-commercial

cc-licenses AT lists.ibiblio.org

Subject: Development of Creative Commons licenses

List archive

Chronological Thread  
  • From: "David Christie" <dc AT sover.net>
  • To: "Discussion on the Creative Commons license drafts" <cc-licenses AT lists.ibiblio.org>
  • Subject: Re: Share-revenues as an alternative to Non-commercial
  • Date: Wed, 4 May 2005 19:00:44 -0700

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.





Archive powered by MHonArc 2.6.24.

Top of Page