|
|
Log in / Subscribe / Register

Perens: The Covenant - A New Approach to Open Source Cooperation

[Posted September 12, 2011 by corbet]

Bruce Perens has posted a description of a scheme he came up with to make copyright assignment policies more acceptable to developers. The article is long, but the idea is straightforward: "A company can covenant, to each contributor of a copyright, to continue to support and maintain a project as Open Source, for a fixed period after a particular contribution - or to remove the contribution from their product if they cannot continue to Open Source their work. In this way, the Open Source developer would be assured of the continuing labor of paid developers on the project in exchange for his contribution, and thus the continued improvement of the program that he uses gratis as a community participant. By making the promise in exchange for the participation of the entire Open Source community, the company will have a better idea of the value it is expending and the value it receives than if it attempted to pay piecemeal for modifications. This covenant is renewed each time there is a new copyright assignment, in that the three-year counter starts anew every time the company receives a contribution from a developer. Thus, developers continue to be encouraged to contribute their copyrights to the company."
to post comments

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 13:52 UTC (Mon) by BrucePerens (guest, #2510) [Link]

Also, note that this is applied to the HPCC software from Lexis Nexis. This is the first large participation of Lexis Nexis in Open Source. The software is the parallel system that they use to produce their own data products. It can handle extremely large scale databases, for example consumer data on everyone in the U.S. I was strategic consultant as Lexis Nexis decided to participate in Open Source, and continue in that role.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 14:08 UTC (Mon) by kragilkragil2 (guest, #76172) [Link] (8 responses)

Master Chief will fight this all the way ;-) and he always wins.

Seriously, is this a jab at harmony? Harmony done right(tm)?

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 14:15 UTC (Mon) by BrucePerens (guest, #2510) [Link] (7 responses)

Not Harmony Done Right, more like Harmony Was Missing the Point.

Why hasn't anyone else tried this? It seems so obvious that the problem with Dual Licensing was that it was all take, with no promise back from the company. Easy to fix.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 14:42 UTC (Mon) by ber (subscriber, #2142) [Link] (4 responses)

Why hasn't anyone else tried this?

The FLA of the FSFE from before 2007 already had a provision that the software will only published as Free Software.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 14:55 UTC (Mon) by BrucePerens (guest, #2510) [Link] (3 responses)

FSE's a non-profit. It seems to be unique that LN, a commercial company, is using this covenant to make dual-licensing fair.

Sure, we all expected that it would only be Free Software if we donated to FSE, FSF, Apache, Software in the Public Interest, Software Freedom Conservancy, etc. But that's not the same thing.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 16:56 UTC (Mon) by pboddie (guest, #50784) [Link] (2 responses)

Wasn't the Free Qt Foundation agreement initiated by Trolltech similar to this?

http://www.kde.org/community/whatiskde/kdefreeqtfoundatio...

Initially, I imagine that there weren't so many community contributions to Qt, so the agreement may not have emphasised the notion of people handing over their work for some kind of corporate commitment, but I imagine that the effect of it has mutated over the years towards what we're talking about here.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 20:10 UTC (Mon) by BrucePerens (guest, #2510) [Link] (1 responses)

If I remember correctly, the Foundation was created as a way of dealing with objection over the product not being under a Free Software / Open Source license for some time in its early history. There was some restriction intended to protect TrollTech's developer seat revenue. They later morphed to GPL, and then later BSD.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 9:10 UTC (Tue) by pboddie (guest, #50784) [Link]

Sure, the history of the project involved the weird conditions of the "Qt Free Edition license" in the original agreement, but the licence was changed in 2000, and the agreement was updated subsequently. The Free Software licensing is currently LGPLv2.1 or GPLv3.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 27, 2011 7:48 UTC (Tue) by bignose (subscriber, #40) [Link] (1 responses)

It seems to me that “missing the point” also describes organisations that insist on copyright assignment in the first place.

What do they think it will provide them that a copyleft won't? Why should contributors grant that organisation something more than what they're willing to give to all the other recipients of the code?

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 27, 2011 8:45 UTC (Tue) by jrn (subscriber, #64214) [Link]

* With copyright assignment, it is easy to change license terms when flaws are discovered in the existing license.
* It becomes possible to negotiate and settle to resolve cases of copyright infringement.
* It becomes possible to grant exceptions at a moment’s notice, for a good cause or in exchange for bribes (or both!).
* When someone has a question of what the copyright holder will permit, it is clear who to ask.

Copyleft doesn’t provide any of those things, does it? It might be a good thing or a bad thing, but it’s hard to say that organizations that insist on papers granting complete control over a project’s copyrights are asking for something of no importance.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 14:25 UTC (Mon) by lutchann (subscriber, #8872) [Link] (17 responses)

I appreciate the thought behind this, but by my reading the legal promises made by HPCC are basically meaningless. What does it mean when HPCC promises to "support and maintain" the OSS edition? Certainly that implies less of an obligation than, say, continuing to maintain feature parity with the commercial edition.

Even if HPCC or its successors manage to violate this weak promise, what is my remedy? Pay my own attorney's fees and travel costs to adjudicate in Fulton County, Georgia, with maximum possible damages limited by the agreement to basically zero?

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 14:48 UTC (Mon) by BrucePerens (guest, #2510) [Link] (16 responses)

Currently the Open Source version and the proprietary version are the same, they don't expect to change that. They differentiate their commercial version with a package of scripts written in the ECL language.

The disclaimer of warranty is similar to the one in the GPL and is bi-lateral, meaning that it protects you as well as LN. It does not absolve LN of the responsibility to, if they can't fulfill the agreement, remove your contribution or contribute the entire thing to a non-profit under permissive licensing. That, rather than financial damages, is the important thing for the community.

Atlanta is in Fulton county. The LN office is in Alpharetta. I would not expect you to go there, but perhaps someone from the Software Freedom Law Center would go there on behalf of the developer community if there was a problem to litigate.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 15:13 UTC (Mon) by lutchann (subscriber, #8872) [Link] (15 responses)

> Currently the Open Source version and the proprietary version are the same, they don't expect to change that.

So why isn't that specific promise in the agreement? Why use the much weaker language of "support and maintain"? Sounds like LN isn't actually willing to commit to keeping up the same level of development.

> The disclaimer of warranty is similar to the one in the GPL

I was referring to the limitation of liability language, not the disclaimer of warranty. And it's not at all like the GPL language. The GPL provides a liability limitation protecting the author from the recipient, whereas the LN agreement protects the recipient from the author as well.

You are correct that the limitation of liability does not absolve LN from fulfilling its obligations under section 4, and an author could take LN to court to force them to do that. But section 5 specifically prohibits an author from collecting indirect damages (or attorney's fees, or other expenses) due to LN's failure to comply up to that point. That's a much, much weaker range of potential remedies than an author would have without this agreement in place.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 15:44 UTC (Mon) by BrucePerens (guest, #2510) [Link] (14 responses)

So why isn't that specific promise in the agreement?

When you are working with a company as large as that (LN is a big division of huge Elsevier) with as many separate stake-holders in legal, management, etc., it's always a negotiation. That's what I could get.

It strikes me that the disclaimer of liability is mainly concerned with product liability. However, to the extent that it protects them from your lawyer fees, it protects you from theirs as well. Let's not get so arrogant that we don't consider that we could lose a case and have to pay the other side for their (much more expensive) lawyers work.

Given the value of the copyrighted property, which has an appreciable fraction of a Billion investment in it, lawyers fees are chicken feed. LN won't want to endanger their rights to keep it proprietary. I'm sorry that we had to accept the limit to remedies, but we got what was most important.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 16:22 UTC (Mon) by lutchann (subscriber, #8872) [Link] (4 responses)

> we got what was most important.

Which is what, exactly? Justification to say, "We're not like Oracle, it's totally safe to assign copyright to us"? No--what's most important is that the "OSS edition" is distributed under a license that allows anybody to fork it when the copyright owner abandons it, a la MariaDB and LibreOffice. And that has nothing to do with the covenant.

Sad to say, the good intentions you started with have been "negotiated" down so far as to become meaningless in practice. Not your fault, but please don't go around telling people that this is some huge breakthrough in community software development. It isn't.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 16:28 UTC (Mon) by BrucePerens (guest, #2510) [Link] (3 responses)

Monty Widenius would kill to have a current copy of MySQL under permissive licensing like BSD so that MariaDB could go back to the old MySQL way of doing business, with a commercial and Open Source version rather than only a GPL version. This agreement would have given him that, if MySQL had accepted contributions and used it.

Obviously, it's more rights than you'd just get with AGPL 3.0

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 16:44 UTC (Mon) by lutchann (subscriber, #8872) [Link] (2 responses)

Not by my reading of the agreement. The permissive licensing requirement is only triggered if LN fails to "support and maintain" the OSS edition for three years after accepting their most recent community contribution. My complaint is that "support and maintain" could mean something as minimal as assigning a single $40k/yr junior programmer to leisurely backport security patches and nothing else from the newly-closed mainline development tree. This is much less of a commitment than you seem to be promising in your announcement, and it is small consolation to a community suddenly frozen out of new feature releases.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 17:06 UTC (Mon) by BrucePerens (guest, #2510) [Link] (1 responses)

only triggered if LN fails to "support and maintain" the OSS edition for three years
Within 3 years. If they gave it up, you could initiate action the next day, not 3 years later.

If they don't make an investement in the Open Source side, the community will probably go away. Their competitors in Open Source would prosper, then. So, they have an economic motivation to maintain their presence, just as they had a motivation to Open Source a 10-year-old product in the first place.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 17:35 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

While I think this is a _very_ interesting way to balance corporate and unpaid volunteer interest, I am concerned that the conditions under which the permissive licensing latches is too vague to provide a clearly delineated set of conditions that can be relied on by externals.

Who has the clear legal authority to make the determination? The company? The external contributors? Sounds like a guaranteed lawsuit if the company decides to take its ball and go home.

I don't know what "support and maintain" means in reality. If the company stops making commits to the open development trunk for a week? for a month? Is that indicative of a lack of maintenance? If the company slips a target release data by a week or a month for the next release, does that cause the BSD doomsday clause to latch?

What if the company deliberately refuses to apply existing critical bug fixes to the open development tree but fixes them in the commercially licensed tree? Does that latch the permissive re-licensing?

There's a lot of room here for corporate bad faith action to game the covenant.

I'd be very interested in seeing someone very familiar with the KDE Free Qt Foundation licensing to give feedback on the new implementation of the "permissive licensing doomsday" covenant.

http://www.kde.org/community/whatiskde/kdefreeqtfoundatio...

Especially the role of a 3rd party foundation to hold the code in trust, instead of relying on the corporate entity to be the arbitrator if the bad faith latching action is taken.

But thanks for the little bit in the article about MySQL being _inadvertently_ fair to developers via a strict work for hire approach. This little fact seems to be missed a lot when certain people hold up MySQL as a poster-company for certain business models.

-jef

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 20:54 UTC (Mon) by jspaleta (subscriber, #50639) [Link] (8 responses)

<i>
When you are working with a company as large as that (LN is a big division of huge Elsevier) with as many separate stake-holders in legal, management, etc., it's always a negotiation. That's what I could get.
</i>

Without disparaging your heroic efforts, let me suggest that by not having a team of externals representing the multi-faceted aspects of external contributor interests in the negotiation that you put yourself and the interests of all external contributors who will be potentially asked to sign this covenant at a material disadvantage in the negotiations.

This is why labor contract disputes usually involve a team of people on both sides of the dispute. A one-man representative for labor against a team of corporate stakeholders will always be at a severe disadvantage and the result runs the risks of being inequitable in the level of specificity with regard to the rights and obligations of the parties involved.

This particular covenant gives a lot of wiggle room to corporate interests and very little wiggle room to external interests. The premise may be good, but the lack of specificity as to conditions under which the corporate entity understands itself to be in breach makes this a guaranteed court fight when corporate/community relations break down.

Hypothetica scenario of concern:
1)It appears as if the corporate entity isn't maintaining things for a period of 3 months. I'll leave it up to you to interpret what that would have to mean in terms of corporate inactivity.

2) External contributor spins up a BSD license based business under the good faith assumption that the corporate entity has shuttered the open development branch.

3) Some time later (6 months, a year, two years), the corporate entity pops back up with new commits on the open development branch and fires a cease and desist order at the external who spun up a new business around the BSD license version he in good faith thought was available under the terms of corporate breach in the covenant.

4) Legal fight ensues to determine who is in breach of covenant, external gets pounded by legal fees(by admittedly very large company) and an injunction to cripple his business. External settles. What happens to the customers who got the BSD code is anyone's guess really.

-jef

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 21:10 UTC (Mon) by BrucePerens (guest, #2510) [Link] (7 responses)

Without disparaging your heroic efforts, let me suggest that by not having a team of externals representing the multi-faceted aspects of external contributor interests in the negotiation that you put yourself and the interests of all external contributors who will be potentially asked to sign this covenant at a material disadvantage in the negotiations.

There are two ways of answering this. First, we just watched the Harmony Project play out. It was structured to include all of the interest holders. No new ideas were incorporated. Not even this one, when I suggested a form of it with a broader grant than that used by LN.

Second, I think there will be room for a community to have a dialogue with LN when there is a community that actually develops useful stuff that LN uses. Right now, that community is theoretical, and I have no way to differentiate the actual participants from those who merely wish to play lawyer.

Regarding how the permissive release gets activated, it would not be as you theorize. The very first move would be a suit filed on behalf of the community. At that point, the company would decide whether to fight the suit or not. If they were finished with the business, they'd just make the release.

Ultimately, it's a court who decides if they aren't supporting and maintaining - if the company doesn't decide to give up first. There is room for expert testimony if you want to write one. I have certainly explained terms in our community to judges before, and will again.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 22:06 UTC (Mon) by jspaleta (subscriber, #50639) [Link] (6 responses)

Hmmm so for externals to make use of the re-licensing rights under the covenant it is expected they'll have to file a lawsuit, on their own, ahead of invoking the BSD relicensing clause and have a court of law rule as to whether the clause in effect. And in return for this opportunity to file a lawsuit, the company gets clear legal authority to proprietary relicensing via copyright assignment. Do you see the lopsidedness problem there?

Again, I think there are some deficiencies here. compared to the previously crafted structure of the KDE Free Qt Foundation agreement. I think everyone should read the original and the 2004 update of that KDE/QT agreeement.

The 2004 update of the KDE Free Qt Foundation agreement really addresses the issue of specificity of the latching conditions on Trolltech. There are clearly delineated obligations and timelines with regard to Trolltech's obligation to provide a corresponding Free Qt release. Really, the KDE community / Trolltech agreement dealt with everything you need to deal with several years ago. I'm not saying you should take it up wholesale, but as a model for the type of latching promise-back, its pretty balanced.

And to be fair to your good faith efforts and the good faith effort of LN reps, I'll point out that yes the Free Qt agreement evolved to include the specificity I'm talking about. And I'm _hopeful_ that you might be able to point reps from LN to the pre-existing Free Qt agreement and see if you can move the LN covenant towards looking more like the amended 2004 Free Qt agreement.

And I cannot stress this enough, the formation/funding of a foundation with both community and corporate reps to act as the legal entity that initiates the formal process of BSD relicensing under predetermined conditions is something I feel really important to consider as part of the covenant you are working on. Take the burden of initiating formal legal proceedings for the doomsday clause off of the individual contributors and spin up an entity tasked with that purpose with buy in from the corporate entity leadership.

-jef

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 23:28 UTC (Mon) by BrucePerens (guest, #2510) [Link] (5 responses)

Hmmm so for externals to make use of the re-licensing rights under the covenant it is expected they'll have to file a lawsuit, on their own, ahead of invoking the BSD relicensing clause and have a court of law rule as to whether the clause in effect.

Maybe a court will be involved, maybe not. But we have organizations like SFLC to do that. They spend all of their time suing other people about my software right now, we might as well give them something useful to do.

I appreciate that the KDE Qt foundation agreement (which is moot now) is clearer. Perhaps we can use something from it.

We also have to remember that Trolltech was a business failure. Which a lot of people didn't realize. Look back to their sale price, there was no premium. I would like to help to build something better for LN.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 5:11 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

Everything has an end...even for-profit business entities.

I really don't think you can point to the specificity with regard to the latching conditions for BSD relicensing in the KDE Free Qt Foundation's charter as material to Trolltech's demise.

And I appreciate that you want to give LN some long term options with regard to business model course corrections and to hedge against uneasiness with dipping their toes into community based development. Like I said the a time window of source access as an alternative form of payment instead of cash for ongoing contributions premise you have here is very interesting. But like everything the devil is in the details.

I think it would help immensely if the corporate entity felt comfortable stating clearly at the beginning of the use of the covenant some specific bad faith actions on their part triggered the BSD doomsday clause. And just as importantly what notice they expect to be given (and from whom) in order to come back into compliance when they fall out of compliance due to an honest mistake on their part. Mistakes are going to happen. I'd really hate to see a good faith effort turn into a legal furball over some boneheaded mistake or miscommunication made inside the fenceline of the admittedly large corporate entity. The more specificity you can drive into the covenant the less likely corporate cultural shifts and personal turnover will accidentally walk everyone into a firefight.

If LN wanted to designate an existing entity such as the SLFC or the Software Freedom Conservancy as ombudsmen with specifically granted notification and arbitration powers when an agreed on latching condition is met, that would probably work out just fine for everyone. I think both of those entities would agree that more specificity would be required to be effective ombudsmen for the covenant. Obviously if LN did make use of such an existing entity, then that such an independent entity would not have as much power to deal with unforseen circumstances as granted in the 2004 Free Qt agreement( where the non profit had the power to re-license for unspecified cause via an unanimous vote.)

Thanks for the chat. I don't think I've got much left in the tank on this. I'll let my specificity arguments rattle around in your head for awhile before I harp on it again. And please shop that 2004 Free Qt agreement around with the LN people you've been negotiating with and see if some additional constructive discussion comes from it.

Though I'll leave you with the following bit of snark. For this concept to really take-off, the IRS will have to figure out how to quantify the value of the time window of source access and tax LN for equivalent amount in payroll taxes and contributors in the equivalent in income taxes. Once that happens, your idea will be simultaneously be legitimized and rejected due to the increased IRS paperwork.

-jef

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 9:16 UTC (Tue) by pboddie (guest, #50784) [Link] (3 responses)

We also have to remember that Trolltech was a business failure.

Come on, Bruce, trot out the myth that "Trolltech never made a profit" as well, while you're at it.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 15:53 UTC (Tue) by BrucePerens (guest, #2510) [Link] (2 responses)

The article you linked to says they made a profit one year, and lost in other years. It indicates that they expanded more than they could cover with revenue, and - it appears - ultimately lost control of their company in a low-price purchase when they couldn't get more investment or loans and could not continue without being bought regardless of the price.

This is not an unusual outcome for a business, sad though it is.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 16:20 UTC (Tue) by pboddie (guest, #50784) [Link] (1 responses)

Well, they made a particular kind of bet, and in the end it seemed worthwhile for the majority shareholders to go along with an acquisition. My response in that comment was to someone who suggested that the business model wasn't viable, which cannot really be claimed since the business model had changed to involve significant expansion and a bunch of people working on initially proprietary mobile solutions, perhaps anticipating that an entrenched mobile vendor would be interested in taking them over.

I think it's all fairly sad, really. I was reading about the Greenphone again the other week, with all the optimism about genuinely open devices running genuinely open software, and five or so years later all the progress on that front has had to be made by other parties, many of whom have no connection with the large corporations who could have so easily contributed small things to significant effect in such efforts.

I think Qt is a pretty important and undervalued piece of technology which should have commanded a much higher price, so I agree with you there. Why it didn't is a rather interesting question in itself.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 17:43 UTC (Tue) by BrucePerens (guest, #2510) [Link]

There are some things that companies just can't do for us. That's why I'm working on Open Hardware.

Affero fiction

Posted Sep 12, 2011 15:12 UTC (Mon) by ballombe (subscriber, #9523) [Link] (6 responses)

It is unfortunate Bruce is propagating the Affero fiction:
> 6 Affero GPL 3.0 is a modern version of the GPL with the addition of an “Affero” feature that requires that source be made available if a program is performed online.
which is maybe what people would like it to be, but not what it says. The AGPLv3 does not restrict the use of the software but how it can be modified (or more accurately expand how you can be sued if you modify it). You do not even need to accept the AGPL to run the software.

Affero fiction

Posted Sep 12, 2011 15:53 UTC (Mon) by BrucePerens (guest, #2510) [Link] (2 responses)

I'm not sure I see your point. If an unmodified program is performed online, we would already have the source. The modified version is the only thing of value to us, and because of the Affero terms, we would be able to get that and propogate it under the AGPL terms, or the upstream authors could bring suit.

I am just not seeing what makes this so odious that you call it "The Affero fiction".

Affero fiction

Posted Sep 12, 2011 18:03 UTC (Mon) by jeremiah (subscriber, #1221) [Link] (1 responses)

I think what the GP is trying to say is that people are under the impression, that if someone uses an unmodified AGPL library in a webserver. Then all of the code that uses/links to said library must be open sourced, ie the entire web application. Which is my impression of the AGPL, and I hope my impression is not wrong, but the GP is saying that it is.

Affero fiction

Posted Sep 12, 2011 20:21 UTC (Mon) by BrucePerens (guest, #2510) [Link]

It would not cause the release of your web content, but might well cause the release of the server program that incorporates the AGPL 3.0 code. Certainly there are gray areas yet to be litigated, but the overwhelming record in the case of the GPL is that violators have settled.

Affero fiction

Posted Sep 12, 2011 16:07 UTC (Mon) by imgx64 (guest, #78590) [Link] (2 responses)

Really? Here's what the FSF has to say about it[1]:

"if you run the program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the program that it's running."

Did I misunderstand what you mean?

[1] http://www.gnu.org/licenses/why-affero-gpl.html

Affero fiction

Posted Sep 13, 2011 8:47 UTC (Tue) by ballombe (subscriber, #9523) [Link] (1 responses)

Yes, that is the Affero fiction and that is the actual licence:

13. Remote Network Interaction; Use with the GNU General Public License.

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

It also says

You are not required to accept this License in order to receive or run a copy of the Program.

and

You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force.

Affero fiction

Posted Sep 13, 2011 15:41 UTC (Tue) by BrucePerens (guest, #2510) [Link]

The point of that text is that you don't need to accept the license just to run the program, but you do need to accept it to modify the program, because nothing else would give you the right to do so. And if you modify the program, you do need to make your modified program available for download.

What it doesn't say is that if you haven't modified the program, we don't really care about the download because we already have a copy.

To call this a "fiction" seems rather mercurial.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 15:13 UTC (Mon) by KGranade (guest, #56052) [Link] (3 responses)

The PROSE describing the covenant is promising, but the language of the covenant itself leaves much to be desired, particularly for a copyleft advocate. The most likely scenario for the software "going closed source" is that the company jettisons the open source portion of the project by permissively licensing it and "donating"* it to a noncommercial or non-profit foundation.

This is the same bizarre reasoning I saw during discussions of Harmony that releasing previously copyleft code under a permissive license is desirable to the developers**. This makes it safer for business competitors to develop solutions based on the code, since they know it will always be available either as current license or a permissive license***, but does it really protect the interests of the contributors?

A side issue, is it just me or does clause 2 of the CLA seem incredibly vague? I assume they want assignment of any patent and trademark rights pertaining to the product, but is this clause sufficient for that to happen? Also can they actually enforce, "You will reasonably cooperate with recording, perfecting, or otherwise protecting these rights."? e.g. can they require you to sign off on a patent application based on your contribution? Can they require you to sign off on application to register a trademark based on a feature you've contributed?

* What does "donating" mean when the work is permissively licensed? the only meaningful things that could be donated at that point would be trademark and patent rights, but the covenant does not claim this will happen.

** I understand and respect that some developers prefer permissive licenses, but in at least some cases, permissive licensing is not what is desired.

*** They could theoretically chose a permissive license incompatible with the strategy of a major competitor, hopefully this could be avoided since it is known in advance.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 15:28 UTC (Mon) by lutchann (subscriber, #8872) [Link]

> I assume they want assignment of any patent and trademark rights pertaining to the product, but is this clause sufficient for that to happen?

I believe so, yes. (IANAL, of course.) It's fairly similar to language I've seen used in many different contracts in the past. Generously, they leave out the typical clause which would require the contributor to indemnify them in case they relied on these rights and the contributor didn't actually have permission to grant them.

> Also can they actually enforce, "You will reasonably cooperate with recording, perfecting, or otherwise protecting these rights."?

Yes, but since they say "reasonably" and "at no cost to You", they'd pay any fees and would likely pay you for your time if it required any significant amount of work from you.

As far as forcing you to sign a patent application, I doubt it since their definition of "IP" seems to include only existing patents and trade secrets rather than things like "patentable ideas" and "know-how".

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 16:03 UTC (Mon) by BrucePerens (guest, #2510) [Link] (1 responses)

Permissive licensing is a poison pill to a company that wants to have a commercial version that people pay for. They would probably go far to avoid it.

The lawyer involved wrote the license to be as brief as possible and understandable by non-attorneys. Perhaps this is what bothers you about clause 2?

Donating means conveying the work to a non-profit under the permissive license, with the expectation that the non-profit would continue the work and redistribute it. Just releasing under the permissive license would be sufficient, IMO.

I don't like permissive licenses much either, But I think they work just fine if the intent of the company is to exit the business.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 17:44 UTC (Mon) by KGranade (guest, #56052) [Link]

I see, the questions about "donate" and clause 2 not mentioning Patent or Trademark rights were mostly confusion rather than objections.

In a broader sense I'm not happy with the "Intellectual Property" nomenclature, but that's not at all specific to this particular agreement.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 15:19 UTC (Mon) by rich0 (guest, #55509) [Link] (2 responses)

Wouldn't a bankruptcy discharge the responsibility to support the software? If the copyrights get sold in bankruptcy then what little inventive that exists to assign copyright disappears.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 16:06 UTC (Mon) by BrucePerens (guest, #2510) [Link] (1 responses)

The covenant will apply to any assigns - companies that are sold the copyright or acquire it through bankruptcy.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 22:51 UTC (Mon) by Wol (subscriber, #4433) [Link]

Plus, if the covenant is part of the contract transferring the copyright, then the contract is an executory contract (thanks PJ) that can only be transferred AS A WHOLE.

Think of a lease - you can't, in bankruptcy, just transfer the bit giving you the right to occupy, without also transferring the obligation to pay rent. If the contract transferring copyright obliges the recipient to maintain the software, then the recipient has to maintain the software. If a bankruptcy court sold the software without the accompanying obligation, copyright would revert to the original author (or whoever), and the buyer would discover they had no copyrights, and no licence. (That's presuming Judges Gross and Cahn haven't thrown a spanner in the works. Here's hoping, if UnXis tries to do anything with what they've "bought", Novell sues them and they find they've bought a pig in a poke.)

Cheers,
Wol

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 15:51 UTC (Mon) by iabervon (subscriber, #722) [Link] (1 responses)

It seems to me that this is missing an important motivation for developers: many developers want to implement a particular feature so they themselves can use that feature. Consider, for example, a developer who has added a redundancy feature to a database so that the web site they run has better availability; their primary goal is to run the site with a database with this feature. To the extent that these developers expect to get a benefit from contributing the code to the upstream project, it is to reduce the maintenance burden (ultimately by developers considering that to be normal functionality and simply not introducing conflicts). In this situation, the covenant would ensure the worst of all possibilities in the situation where the company took the project proprietary: not only would the developer not have access to the source of future versions, but these future versions would not work for the developer, since the feature would have to be removed. Furthermore, there is a danger in the company then owning the copyright on the implementation of this feature, if the developer decides to add the feature to a different project (particularly if the other projects that it would make sense to add the feature to require copyright assignment, so simply having a license to the original implementation is not sufficient).

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 16:11 UTC (Mon) by BrucePerens (guest, #2510) [Link]

Actually, this isn't a problem because of a key feature of copyright law: A developer is always free to grant their own work to others under his/her own terms. The covenant doesn't make you promise not to do so.

If you want to give it to LN with no covenant, you have the option to offer it to them that way. Now, or in the future if they ever decide to take the work private. They might still want some of the language granting patent rights and reducing liability.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 18:45 UTC (Mon) by fw (subscriber, #26023) [Link] (7 responses)

I'm not sure if this is a real problem. If the initial contributor manages to create a vibrant community, with a constant influx of external contributions, then it's very likely they can survive an eventual retreat. If they don't, it's often challenging to actually use the software, even if the initial contributor reliably releases a new version once or twice a year. Look at Berkeley DB or GNAT for examples.

The AGPL is an odd choice. I have yet to see any piece of software which uses this license and which does not put me immediately out of compliance once I modify it, simply because the software lacks built-in mechanisms source-code access.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 20:30 UTC (Mon) by BrucePerens (guest, #2510) [Link] (6 responses)

I'm not sure if this is a real problem. If the initial contributor manages to create a vibrant community, with a constant influx of external contributions, then it's very likely they can survive an eventual retreat.

Yes, but it doesn't seem to me that they'd have economic motivation to abandon a vibrant community.

The AGPL is an odd choice. I have yet to see any piece of software which uses this license and which does not put me immediately out of compliance once I modify it, simply because the software lacks built-in mechanisms source-code access.

I always build that in before I release my own AGPL software. But it happens that just putting it up for download through normal means is sufficient. You don't have to build a special source code delivery facility to comply. I just do so because if the folks who get the code from me or others forget to comply, the automatic download code will do it for them.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 11:07 UTC (Tue) by deepfire (guest, #26138) [Link] (5 responses)

This gets an interesting angle with highly-dynamic languages, like Lisp,
where it is a usual practice to modify the code at run-time, so that the code modifications are immediately effective.

In fact this practice is so widespread, it is actually a modus-operandi, for the vast majority of Lisp-based web developers.

Python programmers call this "monkey patching", just for reference.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 11:51 UTC (Tue) by nix (subscriber, #2304) [Link]

Yeah, but a running system accessible by multiple people is generally only monkey-patched to solve problems at runtime which have *also* been solved in the distributed codebase. You don't normally make a change at the REPL which is not also done to the codebase unless you're debugging, since you don't normally want the change to vanish next time you restart.

(This was less relevant with Lisp Machines, of course, since one hardly ever did restart them.)

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 21:44 UTC (Tue) by BrucePerens (guest, #2510) [Link] (3 responses)

Yes, but isn't lisp good enough at introspection that it could be persuaded to deliver the run-time-modified source on request?

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 14, 2011 1:34 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

Only if you don't mind losing comments and the like, which is usually unacceptable.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 14, 2011 2:12 UTC (Wed) by BrucePerens (guest, #2510) [Link] (1 responses)

Yes, you'd have to modify the interpreter to handle comments differently.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 14, 2011 13:23 UTC (Wed) by nix (subscriber, #2304) [Link]

You need comments as a first-class ignored entity, really, so that ;; foo turns into (comment "foo"), and turns back on printing.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 22:45 UTC (Mon) by aliguori (guest, #30636) [Link] (8 responses)

Is this effectively just another type of software license? Why add the complexity of copyright assignment to the mix? I think it just creates confusion and if anything is malicious in that it tricks people into believing software is Free and/or Open when it really isn't.

In this case, this is a license that carries the same properties of AGPL except for a specific party (HPCC Systems) which effectively gets a BSD license. If some clause is activated (based on whether HPCC Systems "supports and maintains" the work), then all parties receive the BSD terms.

So why not just say, "This work is licensed under the AGPL for all parties except HPCC Systems which is granted a BSD license unless HPCC Systems does not support and maintain the community for a three year period after which, all parties are granted a BSD license."

Copyright assignment seems like a way to circumvent an otherwise trustworthy license. It also makes it clearer the the work is dual licensed and therefore cannot link against GPL software without sacrificing the BSD part of the license.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 12, 2011 23:52 UTC (Mon) by BrucePerens (guest, #2510) [Link] (7 responses)

I think you're missing the economic side of the equation. Take a company with a big product, who didn't need us to make it. Get them to Open Source it. Sometimes, they are giving up on the product and are happy to unload it on us. So, we get it without any quid-pro-quo for them. This isn't one of those times. They have a valuable product in current use, and with an existing customer base, and they want something of value from us just as we are expecting something of value from them.

Regarding making it a BSD license for one company, that's not what they need. They need to be able to grant a commercial license to their customers. For money.

Sometimes people don't realize that BSD isn't so business friendly as people say it is, if your objective is to fund the development by charging the folks who make proprietary derivative works.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 0:18 UTC (Tue) by aliguori (guest, #30636) [Link] (6 responses)

Regarding making it a BSD license for one company, that's not what they need. They need to be able to grant a commercial license to their customers. For money.

Then s/BSD/Some Business Friendly License/g. I don't think there's anything you need here that cannot be handled by a copyright license. You can certainly have a licensing terms that allows for transferring the exclusive SBFL license to another party.

The problem with any type of copyright assignment is that you get to say, "hey, look this is Free Software.". But it's not. Copyright assignment is a backdoor around the GPL.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 0:46 UTC (Tue) by BrucePerens (guest, #2510) [Link] (5 responses)

Then s/BSD/Some Business Friendly License/g.

There isn't one. What they need in this case is the right to use explicitly non-Open-Source terms.

It's still free software because the AGPL 3.0 is always available to everyone. We never give less rights than AGPL 3.0 gives. We sometimes give more rights to paying customers.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 5:18 UTC (Tue) by mjthayer (guest, #39183) [Link] (4 responses)

> Then s/BSD/Some Business Friendly License/g.
>
> There isn't one. What they need in this case is the right to use explicitly non-Open-Source terms.

I have been told by a lawyer knowledgeable about software licensing that code release under the MIT licence can safely (as far as anything legal can be safe) be used in proprietary software. So couldn't a company just ask for contributions to be licensed that way? The company can include such contribution in their dual-licensed version without the contributor having to grant them special rights.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 5:38 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

yes, but many people aren't willing to contribute to a project that can take their work and make it entirely proprietary.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 6:06 UTC (Tue) by mjthayer (guest, #39183) [Link] (1 responses)

> yes, but many people aren't willing to contribute to a project that can take their work and make it entirely proprietary.

Fair enough, but presumably those people are not the target of the sort of covenant proposed by Bruce Perens anyway.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 17:08 UTC (Tue) by dlang (guest, #313) [Link]

I see it as exactly the opposite.

Bruce's proposal is an attempt to satisfy such people that even though there will be a proprietary branch of the code, there will also be a open branch with the contributers code in it. It prevents the company from taking the contribution and just putting it in a proprietary tree (which could happen with a BSD licensed contribution)

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 15:01 UTC (Tue) by BrucePerens (guest, #2510) [Link]

Yes, you can include MIT or BSD licensed code in proprietary products. That's not what is really needed here, though. What is needed is a reciprocal Open Source license (like GPL) and a license that is explicitly commercial, where, unlike BSD, you lose your rights if you don't pay. This separates the folks who want to write Free Software from those who don't, and makes sure that the folks who don't want to write Free Software pay for their license. Thus, the paid developers have a revenue stream to support them, and this is used to make more Free Software.

Thanks, Bruce!

Posted Sep 13, 2011 4:46 UTC (Tue) by jensend (guest, #1385) [Link]

I've seen lots of vitriol on LWN directed against copyright assignment, but I still think it's vital to a lot of projects for a lot of reasons.

At the same time I think people are quite right to be hesitant about simply assigning copyright on their contributions without solid assurances about how that copyright will be used.

I can only see two ways of providing such assurances: having a project's copyright be owned by a well-governed nonprofit which everyone can trust, and having agreements like Bruce's covenant. I'm glad to see the work he's done here.

He mentions having floated a variation of this when Sun started OpenOffice. What a world of difference it would have made if they'd either followed his advice or set up a proper nonprofit!

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 13, 2011 16:26 UTC (Tue) by guest (guest, #2027) [Link]

" . . . The license enforces that the software will remain Open Source. "

Nope, "open source" yes-or-no aside, the (IP) license enforces nothing, it just gives a right to the licensor to sue the alleged licensee for breach of license (breach of contract claim, a right to collect contract damages, ...) and it also give a right to terminate the license upon the breach, and then (upon successful ("automatic" is not allowed by law) termination) sue for intellectual property rights infringement for subsequent (subsequent to termination) use of previously licensed IP...

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 14, 2011 23:58 UTC (Wed) by slashdot (guest, #22014) [Link] (1 responses)

For this to work, the company must also promise that any proprietary versions will be also released simultaneously as open source, since otherwise, they could just "claim" to maintain the open source version, while in reality all significant work is done on the proprietary version.

In addition, it must promise that all versions must be released with a license that prevents further distribution of derivative works under non-open-source licenses, since otherwise they could just license the commercial version to a controlled company that then distributes a heavily modified derivative which is the "real" commercial version.

For GPL licensed works, this is however pretty much equivalent to not assigning the copyright in the first place and having the software under the GPL.

For Affero GPL licensed works, instead, this allows the company to sell the ability to not have to release the source to internally developed derivatives.

In this latter case (which appears to apply to HPCC), it could actually work quite well.

The article however seems to miss this absolutely essential distinction.

Perens: The Covenant - A New Approach to Open Source Cooperation

Posted Sep 15, 2011 0:21 UTC (Thu) by slashdot (guest, #22014) [Link]

As aliguori said above though, there is no need for copyright assignment.

Simply use a variant of the Affero GPL with a ("viral") addition that says that if you received your copy from ACME Inc. in exchange for money, then you are exempt from the requirement to make available the source to any modified version of the software you run on a server.

It is possible to either dual license with the normal Affero GPL or not do so, depending on whether or not you want to allow derived works that you can't make money off in this way.


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds