Sign in / up

back to article Inside OpenSSL's battle to change its license: Coders' rights, tech giants, patents and more

The OpenSSL project, possibly the most widely used open-source cryptographic software, has a license to kill – specifically its own. But its effort to obtain permission to rewrite contributors' rights runs the risk of alienating the community that sustains it. The software is licensed under the OpenSSL License, which includes …

COMMENTS

Post your comment
House rules Send corrections
Add to 'My topics' unstar *
  1. Anonymous Coward
    Anonymous Coward

    The existing license is awful and should be changed, but there appears to have been little to no public discussion or consultation on the choice of new license, and so far no attempt to seriously discuss or address the issues with the choice of Apache-2.0 (lack of GPLv2 compatibility, patent clause, among other concerns). This is disappointing for an important open source project - particularly one with several active forks: everyone, both OpenSSL and the wider community, would benefit from a license which allows all parties to easily share code in the future.

    9 0 Reply
    1. Dan 55 Silver badge
      Reply Icon

      OpenSSL is a one-man band and a law unto itself, why should that change just because the Linux Foundation comes along and throws money at it? This license problem is just another symptom of that.

      1 6 Reply
      1. MJB7
        Reply Icon

        Re: One man band

        It was always more than a one man band. It never went below about three or four central figures.

        There are now even more people involved.

        8 0 Reply
        1. Dan 55 Silver badge
          Reply Icon

          Re: One man band

          Really? It was basically Stephen Henson.

          3 0 Reply
    2. Charlie Clark Silver badge
      Reply Icon

      What did you expect when the big companies got involved? As for the choice of licence – I think the patent protection is largely handwaving but the threat of patent trolls is real – but incompatibility with the GPL is good thing™ in my opinion. But really going with any of the standard licences is better than opening it to discussion. APL allows for embedding in devices without having to argue about shipping source code.

      Given the problems around getting all contributors to agree it would seem easier to adopt one of the "clean room" implementations of TLS.

      3 12 Reply
      1. Anonymous Coward
        Reply Icon
        Anonymous Coward

        incompatibility with the GPL is good thing™ in my opinion.

        Well prepare to be disappointed then, because the APLv2 is compatible with the GPLv3.

        7 0 Reply
      2. thames
        Reply Icon

        @Charlie Clark - "but incompatibility with the GPL is good thing™ in my opinion"

        As noted by the AC above, the GPL version 3 is compatible with the Apache license version 2. Compatibility with Apache V2 was a major design goal when GPLv3 was drafted.

        @Charlie Clark - "APL allows for embedding in devices without having to argue about shipping source code"

        The overwhelming majority of smart phones and a huge host of other embedded devices are based on GPL software, so there don't appear any practical problems with a GPL license in that area.

        I suspect that Theo De Raadt's objections to using the Apache License are simply that it isn't a BSD license. He is a relentless promoter of BSD licenses and slags off anything else. He is of course the founder of OpenBSD, whose defining feature is that it uses a BSD license.

        The Apache license (version 2) is similar in effect to an MIT license with the addition of a patent clause. The FSF (founded by Richard Stallman) recommend the Apache V2 license for projects which for whatever reason don't use a GPL style ("copyleft") licence, so it's a pretty non-controversial and widely accepted license in the software industry.

        There is a general push in the open source / free software side of software development to get rid of custom licenses such as OpenSSL uses and switch to a few widely accepted ones such as Apache, GPL, MPL, etc.

        11 4 Reply
        1. NickHolland
          Reply Icon

          no. The issue is not "the" license, nor the change of the license.

          The issue is the way the license is attempting be changed.

          One person can not say, "I want to change the license, and if you don't respond, I'll take it as approval".

          There are right ways and wrong ways to do this. Some years ago, the OpenBSD project wanted to clean up the licenses on the entire distribution, as there were lots of little things with sloppy (or no!) licenses. They worked to contact EACH author, and they either got clear permission to change or REMOVED THE CODE (sometimes replaced, sometimes not). While benefits of making the change were explained, the license is the choice of the original author, period. Lots of problems were found -- missing contact info, people who had died, people who didn't want to change...and all those situations were respected.

          Authors of code put their intended license on the code. If they change their mind, great. Others may attempt to persuade them to change, but the decision needs to remain with the author. If they wish to use the most gawd-awful license, THAT'S THEIR CHOICE.

          24 1 Reply
          1. dbannon
            Reply Icon

            no. The issue is not "the" license, nor the change of the license.

            The issue is the way the license is attempting be changed.

            One person can not say, "I want to change the license, and if you don't respond, I'll take it as approval".

            I am afraid I have to disagree. I have, several times needed to 'organise' various changes requiring 50% or greater approval. There are always a few in favour, a few opposed and a large number who really don't care. In this case, the last group will be people who, some time ago contributed, or made a small contribution, or are just interested in the code. Hey, not everyone loves reading software licenses !

            Getting people who don't care to respond is really hard. Given that they don't care, it makes sense to assume they will be happy with what ever is judged best for the project.

            3 4 Reply
            1. Voland's right hand Silver badge
              Reply Icon

              Re: no. The issue is not "the" license, nor the change of the license.

              One person can not say, "I want to change the license, and if you don't respond, I'll take it as approval".

              I am afraid I have to disagree. I have, several times needed to 'organise' various changes requiring 50% or greater approval.

              The minor difference here is that the change is a legal issue - you cannot alter a license without 100% uniform consensus and 100% agreement. It is against copyright law.

              4 1 Reply
          2. Anonymous Coward
            Reply Icon
            Anonymous Coward

            Re NickHolland

            Grow up. Not all open source contributors are snot nosed 20-somethings. A good fraction of the non-respondents are going to be from people who are deceased, retired, disinterested, suffering from dementia, etc who can't or won't respond.

            Setting up a proxy vote system where a only deliberate 'no' vote counts as 'no' and everything else counts as support for management's decision is standard and legal. It is the structure of shareholder voting systems for publicly traded companies.

            3 7 Reply
            1. Anonymous Coward
              Reply Icon
              Anonymous Coward

              Re: Re NickHolland

              "Not all open source contributors are snot nosed 20-somethings."

              Indeed not, but how is that relevant here?

              "a proxy vote system where only a deliberate 'no' vote counts as 'no' and everything else counts as support for management's decision is standard and legal.It is the structure of shareholder voting systems for publicly traded companies."

              That may well administratively be the case in some jurisdictions, but whether it works in the interests of anyone other than the established management is a somewhat different discussion. Just as it is here, in fact - the established management and the broader community, how closely are their interests aligned?

              6 0 Reply
              1. Anonymous Coward
                Reply Icon
                WTF?

                Re: Re NickHolland

                A good fraction of the non-respondents are going to be from people who are deceased, retired, disinterested, suffering from dementia, etc who can't or won't respond.

                None those things mean that they consent to a license change to their intellectual property.

                3 0 Reply
            2. FIA Silver badge
              Reply Icon

              Re: Re NickHolland

              Grow up. Not all open source contributors are snot nosed 20-somethings.

              Possibly not the best opener, but go on...

              A good fraction of the non-respondents are going to be from people who are deceased, retired, disinterested, suffering from dementia, etc who can't or won't respond.

              This is a good point, and one lesson that should be learnt by all open source projects, especially if you're planning a licence change. When you take code from other people, they may drop off the radar, lose interest, go mad or die; which means you may at some point have to rewrite their code.

              Setting up a proxy vote system where a only deliberate 'no' vote counts as 'no' and everything else counts as support for management's decision is standard and legal. It is the structure of shareholder voting systems for publicly traded companies..

              ..and for a company, especially a publicly traded one this is correct. However that's an entirely different situation from a piece of open source software made up from the work of disparate contributors.

              If I contribute some code under a given licence, and you wish to change that licence but are unable to get my permission then you have to replace the code. That's it. I may not be interested, I may be barking at the moon or I may even be dead, but I also may just not have seen your email or have moved address; or decided to live in a tent in the outback, which doesn't mean I don't care. You may not like it and it might prove to be an insurmountable logistical burden for a project but you can't just ignore licence terms because you feel like it. To do so is just putting yourself at risk of legal issues further down the road.

              What if I return from my 5 year voyage of personal discovery in the outback even grumpier than ever and discover you've relicensed my code without my consent.... It'll be lawyer time....

              You only have to look to the entertainment industry for many examples of this.

              8 0 Reply
              1. Adam 1
                Reply Icon

                Re: Re NickHolland

                Agreed with FIA. You can't retrospectively add some requirement to check your email within period x.

                Perhaps licenses could be written to authorise proxies in the event that you can't be contacted for an extended period or if you are known to have died. You could even stipulate the default proxy as the unanimous decision of the project foundation board to handle those who were never interested beyond the feature/fix they needed 5 years back. You just don't get to move the goal posts. Most open source licenses are written deliberately to make these sorts of changes really difficult.

                0 0 Reply
    3. Anonymous Coward
      Reply Icon
      Anonymous Coward

      It was all about GPL stealing code

      Linux often forks code from Open BSD and other projects, and then relicenses it as GPL. This means that improvements made under the GPL license cannot be returned to the originators. It is a one way take.

      The original authors wanted to keep OpenSSL free for wide distribution, including for inclusion in commercial software. That is why the no GPL clause was added. And it was important.

      Today, I do not think a GPL fork would survive, so the point is moot.

      4 1 Reply
      1. oldcoder
        Reply Icon

        Re: It was all about GPL stealing code

        That is allowed by the BSD license. Software under the BSD license can even be (and has been) taken proprietary.

        The advantage of the GPL form is that it STAYS OPEN SOURCE.

        7 6 Reply
        1. Steve the Cynic
          Reply Icon

          Re: It was all about GPL stealing code

          "That is allowed by the BSD license"

          OK, maybe, but that's not the point. The question is not whether the BSD-licensed original project is allowed (by the BSD license) to take in the modifications, but whether the GPL-licensed(1) modifications are allowed *by the GPL* to be incorporated into the BSD-licensed original project.

          (1) This is neither the place nor the time to argue about whether "GPL-bound" or "GPL-encumbered" are appropriate or interesting terms.

          0 0 Reply
  2. Will Godfrey Silver badge
    Unhappy

    Frankien-license

    A perfect example of why developers shouldn't try to create their own.

    The no-challenge clause would be no impediment to a patent troll, as they would have no intention of using the software. Also if, as implied, only one attempt was made to contact contributors (with assumed consent) I would expect them to be on shaky ground if anyone made a serious legal complaint.

    6 0 Reply
    1. Nick Kew
      Reply Icon

      Re: Frankien-license

      A perfect example of why developers shouldn't try to create their own.

      Legacy issue. From a more innocent era.

      Perhaps the world could do with some legal precedent on this. There are much lesser license issues getting in the way of sensible things people would like to do. Like, when the contributor of some trivial patch can no longer be contacted, uncertainty over the legalities can be a showstopper.

      Real-life example: when we proposed relicensing an XSLT module for Apache to include in the core webserver distribution. All three developers of the XSLT module agreed, but there was someone else who had once contributed a patch and whose contact details had gone stale.

      3 0 Reply
  3. Anonymous Coward
    Anonymous Coward

    Expert legal counsel?

    "We've gotten expert legal counsel and we're confident in the plan we have,"

    The same one that caused them to require contributors to sign CLA now? Somehow I don't think it was such an expert after all...

    0 1 Reply
  4. Anonymous Coward
    Anonymous Coward

    The planned licensing change comes with the endorsement of Intel and Oracle,

    Obviously so they can do an insignificant change and then charge the earth for its use, and don't forget the patent lawyers.

    0 2 Reply
  5. Peter Galbavy

    Theo's come back with a beauty:

    https://marc.info/?l=openbsd-tech&m=149032069130072&w=2

    Perfect.

    14 2 Reply
    1. Chavdar Ivanov
      Reply Icon

      Indeed...

      I read that letter before I was aware of the proposed OpenSSL license change... What on earth was Theo thinking? Now I see of course...

      2 0 Reply
    2. Number6
      Reply Icon

      It's a good response that highlights the approach nicely, but he'd fail if there was a legal challenge because he's only given them a week to respond. I suspect a court would consider that unreasonable, whereas a few months would probably be acceptable if there was also proof of adequate attempts to contact everyone. I don't know how long the OpenSSL team have given people to respond, or what attempts have been made, but I'm guessing longer than that. Rewriting stuff is a safer option, of course, if your code isn't in there then you can't complain about the licence.

      1 0 Reply
  6. Anonymous Coward
    Anonymous Coward

    I don't see the problem...

    Open source or not: there are only a few people who actually own or run the project. So if they want to change their license then they should be allowed to do so. And well, to be honest I think you can't go very wrong with the Apache license.

    "For years, OpenSSL went largely unappreciated, until the Heartbleed vulnerability surfaced in 2014 and shamed the large companies that depend on the software for online security to contribute funds and code."

    "Shamed companies"? Interesting choice of words, but I don't think it holds very true. Another thing: it also wasn't the first time something like this happened. In 2008 we had another OpenSSL disaster, but this time fully triggered by the Debian package maintainer who altered the code and by doing so introduced a vulnerability.

    1 0 Reply
    1. Ken Hagan Gold badge
      Reply Icon

      Re: I don't see the problem...

      "Open source or not: there are only a few people who actually own or run the project."

      Your problems start at word 13. Because of the way the original licence works, there are not "only a few" people who actually own the project, even if there are only a few running it or contributing to it. Worse, the law does not have a rule that says "there must be an easy solution to this". It doesn't even have a rule that say "there must be a hard solution to this". Copyright protection is *supposed* to be something that other people can't unilaterally take away from you just because you were looking the other way at the time. (It even applies after you are dead, FFS, and there isn't much more "looking the other way" than that!)

      10 0 Reply
  7. Roland6 Silver badge

    Key Learning Point for the OSS Community: IP Ownership Governance

    "Fundamentally, OpenSSL has never had a contributor agreement," said De Raadt. "OpenSSL does not own the rights to make this change."

    Just, like an employer, open source projects need to have contributors assign the rights to their contributions to the project/foundation. As this would give the project/foundation the freedom to decide on whatever licence they deem is appropriate for the complete body of work. Obviously, part of the project governance is having the necessary checks and balances in place to ensure 'member' contributors have the final veto on any decisions that impact the licensing and thus style of usage permitted.

    0 5 Reply
    1. oldcoder
      Reply Icon

      Re: Key Learning Point for the OSS Community: IP Ownership Governance

      That also opens up the possibility that the project gets taken over... and taken proprietary.

      NOT a good thing for the users or developers.

      4 2 Reply
      1. Anonymous Coward
        Reply Icon
        Anonymous Coward

        Re: Key Learning Point for the OSS Community: IP Ownership Governance

        "That also opens up the possibility that the project gets taken over... and taken proprietary."

        No, it doesn't. Contributor agreements assigning the copyright of the work to a neutral foundation-like body are *absolutely* essential for a truly open source project. That's the difference between something that is really open source and something that just publishes its source code.

        0 1 Reply
    2. Berny Stapleton
      Reply Icon

      Re: Key Learning Point for the OSS Community: IP Ownership Governance

      > Just, like an employer

      Actually, this couldn't be further from the truth, in that instance, you're being paid for your work. You're giving up your copyright, in exchange for a pay check. In open source projects, the copyright is still yours, it will always be your code. The purpose of the license (And in this instance, I'm referring to open source licenses) is to provide a legal framework for someone else to benefit, or not, from it, but in every instance I can think of providing someone permission to use (And potentially distribute) your copyrighted work.

      0 0 Reply
  8. pitrh

    The point is, changing the license without contributors' explicit consent is illegal

    The specific content and any perceived merits of the various licenses are all irrelevant.

    It's the "if we don't hear anything back we assume we have your consent" part that's simply not legal in any jurisdiction anywhere that has the concept of copyright.

    If they want to change the license, fine. Contributors who agree with the new license will give their consent. For those who do not explicitly give their consent, any contributed code needs to be replaced with code under the new license, in some manner consistent with fairly straightforward copyright law.

    The legalities are not at all complicated. Performing a full license audit of their tree is likely to be time consuming (just ask the people who did just that on the OpenBSD source and ports trees at least once), but unless they get everyone explicitly on board with the new license they will need to go through one.

    If the various supposedly legality-savvy organizations such as those Theo mentions in his "GCC licence change" message actually approved this, "worse than useless" is a much too mild characterization of those organizations.

    9 0 Reply
  9. Christian Berger

    Luckily...

    ... the OpenSSL team is known for their excellent and virtually bug free code, otherwise it would be silly to discuss licenses before actually doing what LibreSSL did and clean up their code.

    1 3 Reply
    1. Roland6 Silver badge
      Reply Icon

      Re: Luckily...

      Shame LibreSSL, as fork of OpenSSL seems to have the same licence - which makes me wonder just what Theo De Raadt (founder of OpenBSD, a contributor to OpenSSL, and creator of a LibreSSL), is really objecting to.

      I wonder if a comparison of the unaltered OpenSSL code remaining in LibreSSL with the list of OpenSSL contributors who have consented to the licence change results in a significantly shorter list of orphaned contributions and thus make the workaround rework more manageable.

      3 2 Reply
      1. Anonymous Coward
        Reply Icon
        Anonymous Coward

        Re: Luckily...

        "Shame LibreSSL, as fork of OpenSSL seems to have the same licence"... But LibreSSL *can't* just go and change the license. Doing so would require tracking down all the contributors and either getting their agreement or rewriting their code. Which is exactly what OpenSSL are trying to avoid doing here with the "if we don't hear from you we assume it's ok" approach.

        1 0 Reply
  10. Anonymous Coward
    FAIL

    Insert open-source licensing FUD

    "We are working to change the license for OpenSSL .. to the widely-accepted and common Apache License (version 2)."

    "We wrote some tools to look through every version of our files, and our scripts found your email address. You can see what we found:"

    "If we do not hear from you, we will assume that you have no objection."

    "You can also post to the public mailing list, openssl-dev@openssl.org; details about that list can be found at this site:"

    So, if I correctly follow your thinking, the attempt by the OpenSSL project to contact contributors is evidence of the OpenSSL project alienating the community. Is this place turning into the Breitbart of the technology press.

    1 7 Reply
    1. Ken Hagan Gold badge
      Reply Icon

      Re: Insert open-source licensing FUD

      It is not the attempt to contact contributors that is alienating the community. It is the fact that the community will be ignored if that one attempt fails. Happily, bobajob12 puts it nicely in a post which is (at time of writing) directly below this one, so...

      1 0 Reply
  11. Anonymous Coward
    FAIL

    OpenSSL losing their mind

    It is extremely sensible for the maintainers of OpenSSL to want to have the entirety of the project under a single unifying license, and APL is a perfectly reasonable choice (compared to, say inventing Yet Another License).

    It is crazy of them to do it in such a cack-handed way. Assumption of consent is at best incredibly lazy and at worst mendacious. They need to get off their behinds and audit every contribution, track down the contributor, and ask. If they can't do that, then the contribution needs to be rewritten.

    Yes, doing it right takes time. The leaders of OpenSSL of all people should remember that not doing it right causes major pain later on. My heart...bleeds for them.

    12 1 Reply
  12. Anonymous Coward
    Anonymous Coward

    Theo De Raadt - why bother asking?

    De Raadt has his own BSD/LibreSSL agenda so why bother asking him for an opinion on OpenSSL as his replies will always be negatively coloured by his own bias. It's like asking Steve Ballmer for an educated and informed opinion on Linux - once he's stopped foaming at the mouth, you simply won't get one.

    I imagine the only reason for asking De Raadt is to get some poisonous soundbites with which to spice up what is otherwise pretty much a non-event. Everyone agrees SSLeay is a mess, and that another more standard licence for OpenSSL would be beneficial for all concerned. Make it happen, move along, nothing more to see.

    2 2 Reply
  13. MNGrrrl
    Megaphone

    Its bad

    The subhead tells me everything i need to know: not responding counts as a "yes". In other words it's so bad the only ones who would vote for it don't know it's happening

    2 0 Reply
  14. Number6

    Book Publishing

    Isn't this the same sort of argument that Google are making with books? If you don't object to them doing stuff then they can do it. They might have tried to contact you in advance to ask but as you didn't respond they presume consent.

    2 0 Reply
  15. Anonymous Coward
    Anonymous Coward

    "Isn't this the same sort of argument that Google are making with books? If you don't object to them doing stuff then they can do it. "

    It's also the UK's current Brexit situation. In a way that would be unacceptable in any two-bit community organisation (where the constitution would typicaly not be radically changeable without two thirds of the voters being in favour of the change), we are about to make massive changes to the future of the UK, based on a statistically insignificant majority and (arguably) a variety of misinformation from one or both sides of the vote.

    Whether anyone agrees with the outcome or not, the process was defective by design, both in the case of Google/books and in the case of the England/Wales/NI relationship with the EU (Scotland seem to have a bit of a fallback plan).

    8 1 Reply
  16. Not That Andrew

    I don't see why people have this thing about advertising clauses. Is it REALLY that onerous to have a section in your documentation & a link from your about box listing all the software you used & their licensing?

    0 0 Reply
    1. Lennart Sorensen
      Reply Icon

      The openssl advertising clause is so obnoxious that if you even say:

      Our product has secure connections.

      You actually have to do something like:

      Our product has secure connections (using OpenSSL copyright x, y, and z, blah blah blah).

      Every single time you talk about any feature that relies on what OpenSSL provides. Does everyone do that? Well no, but the license does appear to say exactly that. It is very hard to comply correctly with that license.

      It is not just the documentation that has to list the copyrights, or the about info for the application. It's documentation, advertising, discussions of product features, etc.

      0 0 Reply
      1. Not That Andrew
        Reply Icon

        But seriously of all the software over the years that has used OpenSSL, has anyone ever actually done that? No, just a section in the documentation and a page on the website.

        0 0 Reply

POST COMMENT House rules

Not a member of The Register? Create a new account here.

Forgotten password ?

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like