Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Open Source Linux

The Covenant - a New Open Source Strategy 108

Bruce Perens writes "Lexis Nexis has Open Sourced HPCC, the parallel software that they use for handling extremely large data. Databases that, for example, hold records for every consumer in the U.S. can be processed with this software and its task-specific language. As Strategic Consultant for the company while they decided to participate in Open Source, Open Source co-founder Bruce Perens designed a new Covenant between Lexis Nexis and the Open Source community that makes dual-licensing more fair to the Open Source developer."
This discussion has been archived. No new comments can be posted.

The Covenant - a New Open Source Strategy

Comments Filter:
  • It's the White Witch offering Turkish Delight.

    The goals of this plan are to capitalize on the innovation and new ideas that come with an Open Source community [...] and collect direct revenue from the product – not just revenue from ancillary products like support and training.

    • I agree. I fail to understand the need to assign copyright. Surely the developer can just give HPCC a license to the code which includes the right to relicense the code under any commercial license they wish so long as they continue to support and release an open source version. Call this the HPCC Turkish Delight license and then just say that you are releasing your code under this license instead of GPL/.... By assigning copyright HPCC could use the code in a different, closed source product without compen
      • Surely the developer can just give HPCC a license to the code which includes the right to relicense the code under any commercial license they wish so long as they continue to support and release an open source version.

        In building a balance that will motivate multiple parties to participate, you have to consider all of their needs. In the case of HPCC's needs, this allows them to continue to own their entire product, and to list their entire product as an asset.

        I don't really expect them to act like some

        • Re: (Score:2, Informative)

          by tomhudson ( 43916 )

          In the case of HPCC's needs, this allows them to continue to own their entire product, and to list their entire product as an asset.

          Whoa, cowboy. I smell a rat. A BIG FAT JUICY RAT!

          The breed of rat that thinks "Let's get a portfolio of copyright assignments so we can list these as assets" rat that wants to be able to own other people's code so they can do an IPO or a spin-off to attract investors or inflate their balance sheet.

          Looks more and more like this is not (just) about them selling their comme

        • by Urkki ( 668283 )

          In building a balance that will motivate multiple parties to participate, you have to consider all of their needs. In the case of HPCC's needs, this allows them to continue to own their entire product, and to list their entire product as an asset.

          And you seriously thing that is going to motivate multiple parties to participate? They're free to suggest what ever licensing or copyright deals, and everybody else is free accept it, but also free to laugh at their face.

        • In the case of HPCC's needs, this allows them to continue to own their entire product, and to list their entire product as an asset.

          If it is very important that they completely own their product then I think that Open Source is the wrong strategy for them. I very much appreciate what you are trying to do but Open Source is a community effort and the community needs to be the one which owns the project (at least the open source verison of it). I simply would not trust a commercial company with my code. Sorry - HPCC may be very trustworthy but as your original article mentions many others are not (or get taken over, get a new CEO etc.) a

  • Complicated (Score:1, Interesting)

    by Anonymous Coward

    the product is to be dual-licensed under the Affero GPL 3.06 and a commercial license. In exchange for each copyright assignment from an Open Source developer, the company will covenant to continue to support and maintain the Open Source version of their product for a period of three years – they won't take it private during that time. The three-year clock will start anew every time there's another copyright contribution. If the company cannot continue to support and maintain the product as Open Source, HPCC systems promises either to contribute the product to a non-profit under permissive licensing like BSD, or to remove the developer's contribution, and all others for which the three-year clock is still running, from the product.

    Unnecessarily complicated. If it's already under Affero GPL then people can already build on it-"contributing the product to a non-profit" doesn't add anything to that and there's no reason to assume that people who choose to contribute to a GPL project want to have their code licensed under BSD anyway (and vice versa) - some will be happy with this but others won't. On balance, what's the point?

    • Re:Complicated (Score:5, Insightful)

      by Bruce Perens ( 3872 ) * <bruce@perens.com> on Monday September 12, 2011 @12:22PM (#37377618) Homepage Journal

      Unnecessarily complicated. If it's already under Affero GPL then people can already build on it-"contributing the product to a non-profit" doesn't add anything to that and there's no reason to assume that people who choose to contribute to a GPL project want to have their code licensed under BSD anyway (and vice versa) - some will be happy with this but others won't. On balance, what's the point?

      Consider why people want to have their work accepted by the project, rather than just maintain their modification independently. Consider the hoops that companies jump through just to get Linus to accept their patches. Now, consider that LN will maintain your modification for you with paid employees, if they accept it. Yes, there is value in that.

      • In exchange for each copyright assignment from an Open Source developer, the company will covenant to continue to support and maintain the Open Source version of their product for a period of three years – they won't take it private during that time. The three-year clock will start anew every time there's another copyright contribution.

        Now, consider that LN will maintain your modification for you with paid employees, if they accept it. Yes, there is value in that.

        Indeed there is, for both parties. But there is a legal asymmetry, since one party actually owns the code, and it's not the coder.

        One consequence is how bankruptcy affects ownership, control, and related duties. Exactly how that covenant could be gutted during bankruptcy proceedings is likely to be of considerable interest to any coder who submits to this license. At present, the covenant [hpccsystems.com] is silent on the issue of bankruptcy, but includes the text:
        "You assign to HPCC Systems all copyright rights, title,

        • Well, I'll discuss with their attorney whether there is a need for a change in terms specific to bankruptcy. But if the company goes bankrupt, they didn't benefit from the Open Source cooperation sufficiently anyway. So, I'm not sure how much we need to flog that horse. It seems unlikely that Oracle is going to pick up such a product in an asset sale and suddenly make a smash hit out of it.
          • Well, I'll discuss with their attorney whether there is a need for a change in terms specific to bankruptcy. But if the company goes bankrupt, they didn't benefit from the Open Source cooperation sufficiently anyway. So, I'm not sure how much we need to flog that horse. It seems unlikely that Oracle is going to pick up such a product in an asset sale and suddenly make a smash hit out of it.

            A company can have a smash hit and still go bankrupt and be picked up by Oracle. Or is Java not a "smash hit" any mo

            • Sun didn't go into a "chapter" proceeding, they were sold.
              • Sun was bleeding money hand over fist and wasn't long for this world - we all know that. They were picked up at bankruptcy prices, not some insane dot-com-multiple of their value.
                • Well, sure. But they were picked up in a way that left Sun stockholders with $9.50/share, which was a lot better than $0, and too bad for the folks who bought it at $250. Bankruptcy is what happens if you can't have the fire sale because your indebtedness is too large for anyone to be interested.
                • And, if your imagination is sufficiently paranoid, you'd argue that the "let them burn and mine the ashes" approach would fit Oracle's approach to intellectual property just fine.

                  Allowing bankruptcy to launder the obligations without disgorging the property would have been a fine way for Oracle to get out of the Java community burden. Just imagine the rich per-CPU license fees they could have been sucking down if it weren't for those pesky Open Source kids.

                  Yes, you're right. That's wildly paranoid. Still, t

    • On balance, what's the point?

      If nothing else, vesting the copyright (bearing in mind that it is assigned, and so ownership is transferred, rather than merely being licensed) in an entity other than the company which has decided not to support and maintain the product, and which exists to hold and potentially make ongoing decisions about its codebase, might increase the chances of both (a) active management of the project, rather than just code floating around, and (b) an increased likelihood of complia

    • Re:Complicated (Score:4, Interesting)

      by Ixokai ( 443555 ) on Monday September 12, 2011 @12:34PM (#37377718)

      People can already "build on it", yes -- but they would have to fork it to do so, and there's a LOT of reasons why you may want to contribute upstream and not fork your own.

      For one thing, if you care about whatever your project is that is using the software, you want to stay as close to the main line of development is as possible -- since its being actively developed and maintained by a paid group of people, in addition to whatever the community contributes.

      For another, if you /don't/ get your change to the upstream, then that is a burden on you forever -- you will have to maintain that change as the main line evolves. Your patches won't apply cleanly forever. Now, you may just dump out a patch and move on and never upgrade, and if that's what you wanna do.. okay, fine.

      There's lots and lots more. If you can't see why wanting to get your changes integrated instead of just forking your own isn't desirable, well... okay whatever :)

      The "covenant" here means that the company is promising something to you in exchange for requiring you assign copyright. Its up to you to decide if the value proposition there is worth it to you -- most other contributor agreements I've seen in the past I thought were kinda greedy (unless it was to a neutral/Open-Source organization such as Python or Apache which I could rely on to not go private), since it was always one-way. This is at least something, and I'm not sure what want more of if I were negotiating -- they couldn't realistically promise my lines be open forever, as code evolves a lot more organically then that.

      A promise to either release it all permissively, so /anyone/ who contributed -- be they commercial interests (remember, some of these "contributors" aren't Open Source people per se, who care about GPL or BSD or whatever, but are companies who may use that software and are contributing to the platform) or open source users can use it how they like.... or to support and maintain it for three years after their last accepted contribution (during which you're free to fork), seems a pretty decent compromise to me.

  • by jopsen ( 885607 ) <jopsen@gmail.com> on Monday September 12, 2011 @12:21PM (#37377608) Homepage
    If I were contributor to a dual licensed project, I wouldn't mind having a promise that the product is kept alive and open sourced for 3 years after my latest contribution. I don't know if it's enough to justify copyright assignment, but at least it's an acknowledgement and not a bad one...
  • by vlm ( 69642 ) on Monday September 12, 2011 @12:35PM (#37377732)

    The three-year clock will start anew every time there's another copyright contribution.

    Per product, or per version? How about forks?

    What happens to the covenant in a bankruptcy hearing? Bankruptcy judges have relatively free reign... Could it be bad?

    If starting anew, isn't it simpler / cleaner to have a non-profit that owns the open source code, and a private for-profit that applies the code? If not starting anew then you've got some pretty confusing balance sheet issues with transferring ownership, in which case the covenant makes sense.

    Thus, the Open Source developer is assured that the work won't be taken private for a significant amount of time

    Should I care? If version 7.4 is GPL, and they close 7.5 and above, can't I just fork off 7.4 and run it myself aside from any trademark problems?

    If a company is planning on taking ye olde version 1.3 and going private with it in just 6 more months, perhaps because they're insane, regardless, wouldn't that encourage them to not accept security patches from the community? Not saying this "enforcement aspect" is good or bad, just saying it "is".

    and the continued participation of Open Source developers provides a strong incentive for the company to never take the product private.

    What if the management team intends to burn it to the ground to extract maximal profit for one quarter at the cost of permanent long term damage, in other words traditional American management style? Your design assumptions are both sides are perfectly informed, rational, and free actors, but they are not, which likely impacts the outcome.

    Through the covenant, their use of dual-licensing, and their innovative software, HPCC Systems will gain broad acceptance of their product and will profit from its software and services.

    Agreed, that is the most likely outcome. My criticisms are about using the new covenant in other "unlikely" situations. If everything's balloons and unicorns you don't need to worry about the downside, but if you're going to bother with the paperwork, you should be focusing intensely on the downside because that's when you most need the paperwork... Best case scenario you have a PR win. Worst case scenario is ... better but not entirely perfect either.

    • Good comment. We should remember that the cumulative probability of the long tail of "unlikely" outcomes often outweighs the probability of the few most "likely" outcomes. In other words, the outcome will most likely be bad.
    • Re: (Score:2, Informative)

      by Bruce Perens ( 3872 ) *

      The three-year clock will start anew every time there's another copyright contribution.

      Per product, or per version? How about forks?

      I can't think of anything that could be used to exclude a version from the agreement, so it's every version of the work that has been contributed to (that could be more than one product) during the 3 year period. If someone other than LN forks the work they are restricted to AGPL 3.0 terms. LN, as the copyright holder, is the party with a right to issue a commercial licen

      • I haven't read the covenant yet, but plan to. As for the editorial and summary, thanks. This is a real help to the community. I only hope it's enough to take some of the edge off of the dual licensing issue. I spend a fair amount of sleepless nights debating with myself whether or not to dual license my software. It's the kind of thing would be good for the community to have and make lives better, as well pay some of my debit back to the OSS community. At the same time, I need to eat. It truly is a deep mo

      • If someone other than LN forks the work they are restricted to AGPL 3.0 terms. LN, as the copyright holder, is the party with a right to issue a commercial license. We don't need a covenant with folks who can only use AGPL 3.0.

        In other words, they've done the equivalent of Tivo-ising the code wrt commercial use. Sweet!

        Hey everyone - assign ME your copyrights and I'll give you a grant-back to use all the copyrights in the pool under the AGPLv3. I'll go one further than Loopy-Noopy - I'll even give you a

        • In other words, they've done the equivalent of Tivo-ising the code wrt commercial use.

          Not sure you're really clear on this. When I release my own code under AGPL 3.0, you don't get to commercial license it. The only code you have a chance to commercial license in that case is your own. Now, maybe you're complaining because this doesn't license-back to you your own code in a way that you could commercially license. But it would still be a fragment of an overall AGPL 3.0 program, and you would not be able t

          • My reference to "tivo-ization" was not that the code was no longer compilable - but that it would no longer be accessible for commercial use or use in many projects with different licenses even by the original author, who gets absolutely nothing in return for giving up his or her rights. The code has certain aspects that are now "fenced off" from the world.

            THEY can issue a commercial license, while the original author no longer can. The reason they want to do this is because they see value in it. If y

    • The notable phrase in what they can do to get out of the 3 year period is "...either to contribute the product to a non-profit under permissive licensing like BSD, or to remove the developer's contribution, and all others for which the three-year clock is still running, from the product."

      So BSD it (Which can be folded into a closed source system but you have a snapshot at that point, or they roll back the changes

      So your contribution can go closed source, in less than 3 years, and after 3 years they can do a

  • What about a "contributor license agreement" that lets the main company release your stuff under a commercial license?
  • Affero GPL does not meet the conditions of the FSF's Free Software definition. In particular, it fails on Freedom 0. A few years ago, they never would have approved this, but they took an uncharacteristically pragmatic turn and decided to ignore their ethics in favor of achieving a result they desired that could not be achieved with Free Software licenses alone.

    The basis of the FSF's definitions are their view that it is unethical for one to have a program but not have the ability to use it, study it, and m

  • This is unintelligible.
  • Bruce claims that MySQL never too outside contributions and this was discussed in the EU.
    This was not true.

    There was some claims to the EU that MySQL AB did not take outside contributions but this was dismissed by me and others.

    MySQL Ab did during it's whole lifetime taken outside contributions; There is a lot of bug fixes, ports, security enhancements and features developed by people outside of MySQL Ab. Most of the infrastructure (like connectors) where developed by outside contributors. It's true that w

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Working...