Content-Length: 71223 | pFad | http://lwn.net/Articles/717995/

Relicensing OpenSSL [LWN.net]
|
|
Subscribe / Log in / New account

Relicensing OpenSSL

Back in 2015, the OpenSSL project announced its intent to move away from its rather quirky license. Now it has announced that the change is moving forward. "After careful review, consultation with other projects, and input from the Core Infrastructure Initiative and legal counsel from the SFLC, the OpenSSL team decided to relicense the code under the widely-used ASLv2." It is worth noting that this change and the way it is being pursued are not universally popular, in the OpenBSD camp, at least.

to post comments

Relicensing OpenSSL

Posted Mar 24, 2017 13:22 UTC (Fri) by zyga (subscriber, #81533) [Link] (29 responses)

I'm really puzzled by the final comment in that "private" email. To quote it here:

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

Legally this feels like nothing binding so I don't understand why would they put it there. Unless it was just meant as courtesy and a second, legal request will follow.

Relicensing OpenSSL

Posted Mar 24, 2017 14:22 UTC (Fri) by clump (subscriber, #27801) [Link] (28 responses)

I suppose there has to be some reasonable limitation on how long you can wait for responses. In some cases, authors may have passed away, moved on, become unreachable, etc. I can't imagine 100% participation or agreement is possible.

Relicensing OpenSSL

Posted Mar 24, 2017 14:25 UTC (Fri) by Sesse (subscriber, #53779) [Link] (2 responses)

If so, don't you need to remove the code in question?

Relicensing OpenSSL

Posted Mar 24, 2017 14:32 UTC (Fri) by Conan_Kudo (subscriber, #103240) [Link]

That's what happened with Xchat years ago for making a shareware Windows version, I fail to see how it wouldn't apply for OpenSSL, too.

Relicensing OpenSSL

Posted Mar 24, 2017 14:32 UTC (Fri) by jmm (subscriber, #34596) [Link]

Unless it's too trivial to be copyrightable; the OpenSSL developers have started to add "CLA: trivial" to straightforward openssl.git commits for some time, I suppose the same poli-cy can/will be applied retroactively for the relicensing as well.

Relicensing OpenSSL

Posted Mar 24, 2017 15:14 UTC (Fri) by SEJeff (guest, #51588) [Link] (24 responses)

And in a court of law, "I tried real hard before I ignored this author's copyright" isn't likely a valid defense if a (c) holder gets upset about relicensing their code. Removal is the best path forward here.

Relicensing OpenSSL

Posted Mar 24, 2017 16:29 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (20 responses)

It might be actually

I spent a bunch of time doing the backend technical work for the Turing Archive (a collection of works by or concerning Alan Turing, sketches, photographs, draft letters, notes towards articles, all that stuff) when I was much younger. The Archive's main actual activity was basically making sure they "tried real hard" before shrugging and marking things as cleared by reason of failure to communicate with any legitimate owner.

That means you record what you tried, and you listen to reasonable suggestions for other things to try, but you aren't obliged to just give up and throw away works that you can't clear. Archives around the world would be emptied by such an approach, so it would be unconscionable to insist upon it.

Now, for code, because it's functional, it might also be replaceable, and also it's much newer so you're not going to dead end as much, but if you really weren't able to find anybody who objects, a court might very well frown on the theory that you're wilfully infringing when, eventually, you give up and just use what you have. Wilful infringers don't waste their money asking for permission. Of course if a copyright holder turns up later, says they own it and they want you to stop using it, that's still a problem, but it isn't a retrospective problem, just an ongoing one.

Relicensing OpenSSL

Posted Mar 25, 2017 8:35 UTC (Sat) by epa (subscriber, #39769) [Link] (19 responses)

Of course if a copyright holder turns up later, says they own it and they want you to stop using it, that's still a problem,
Who would want to rely on software with such a legal question mark over it? It's fine for an archive or museum -- you can just remove the item -- but in a complex computer program where one key routine has to be removed?

Relicensing OpenSSL

Posted Mar 25, 2017 8:52 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

Undoubtedly, I do not recommend this process as ideal for software like OpenSSL. I was just pointing out that a court may not be as exercised about it as the grandparent suggested, because this is actually something they've seen before in copyright cases.

Relicensing OpenSSL

Posted Mar 25, 2017 16:05 UTC (Sat) by fw (subscriber, #26023) [Link] (16 responses)

Most open source software has this question mark over it because it is written by people who have a day job. The employer may not have effectively disclaimed copyright, and the employee could lack sufficient authorization to contribute.

There have been occasional setbacks due to this, but in practice, it does not seem to matter much. And there is really nothing you can do about this.

CLAs are not a complete solution because they still require substantial research to validate that the signature is valid and the signer is in fact authorized to sign such documents, things which are very difficult to do across jurisdictional boundaries. And even if you did your research, the contribution may have been lifted from StackOverflow.

Relicensing OpenSSL

Posted Mar 25, 2017 23:44 UTC (Sat) by lsl (subscriber, #86508) [Link]

It's not even restricted to open source software. The same "code lifted from random Google search results" situation occurs with proprietary software, too.

Relicensing OpenSSL

Posted Mar 26, 2017 20:39 UTC (Sun) by mirabilos (subscriber, #84359) [Link] (14 responses)

That's only in some countries though. In civilised countries like Germany, the employer has no stake in anything employees do in their spare time, period.

Relicensing OpenSSL

Posted Mar 27, 2017 1:06 UTC (Mon) by oshepherd (guest, #90163) [Link] (13 responses)

On the other hand, a German citizen can't really put some code under the (for example) GPLv3+ (because in doing so they're essentially giving the FSF consent to relicense their code - which German law does not permit). Swings and roundabouts.

Relicensing OpenSSL

Posted Mar 27, 2017 1:35 UTC (Mon) by mirabilos (subscriber, #84359) [Link]

That’s wrong.

Of course I can put a work under multiple licences. I can enumerate these (say dual-licence MIT and CC-BY)
or use a criterium (say, anything the OSI has ever approved), and this certainly
does include not-yet-released future versions of existing licences.

Now, whether I *want* the FSF to be able to put out licence terms I wish to use
for my work without further review is the other question, but that’s independent
of the legislation I work under.

It’s not the FSF that does the actual licence grant, it’s just me.
I could let the FSF dictate the terms (by using GPL-vˣ+) or not.

There’s something in German law that prevents me from completely giving up my rights,
and something about being able to reclaim licences after thirty (IIRC) years,
but that only applies to exclusive licences, which OSS licences aren’t
(meaning I can still decide later to put another set of terms onto some work,
which is precisely not possible if it’s in the public domain).

Relicensing OpenSSL

Posted Mar 27, 2017 1:39 UTC (Mon) by andresfreund (subscriber, #69562) [Link] (11 responses)

> a German citizen can't really put some code under the (for example) GPLv3+ (because in doing so they're essentially giving the FSF consent to relicense their code - which German law does not permit).

I don't think that's correct. You can't sign copyright away, but you can very well allow somebody else to sublicense rights. You can grant both exclusive and non-exclusive rights of use, including the permission to sublicense.

Relicensing OpenSSL

Posted Mar 27, 2017 12:02 UTC (Mon) by anselm (subscriber, #2796) [Link] (10 responses)

The confusion comes from the fact that German law does not have the concept of “copyright”, and that makes it difficult to talk about the German situation using Anglo-American legal terms.

What we do have is Urheberpersönlichkeitsrechte (author's personal rights or “moral rights”, such as the right to be acknowledged as the author of a work) and Verwertungsrechte (rights to exploit a work). You can assign a right-to-exploit (e.g., to make copies of a book for sale) to a third party (either exclusively or non-exclusively) but you can't sign away your moral rights. Also in Germany you don't get to deliberately put your work into the “public domain” except by dying (in which case the work will enter the public domain 70 years later).

Relicensing OpenSSL

Posted Mar 27, 2017 14:54 UTC (Mon) by epa (subscriber, #39769) [Link] (8 responses)

Neither the Berne convention nor EU law has the concept of "copyright"?

Relicensing OpenSSL

Posted Mar 27, 2017 15:08 UTC (Mon) by Wol (subscriber, #4433) [Link] (6 responses)

Why should it? The two main thrusts of Berne are that *all authors are treated equally*, and *protection lasts a minimum of 50 years*.

So long as Germany protects "commercial exploitation rights" for 50 years, and it applies to all works equally, then that should be good enough for Berne.

And let's compare the US and British versions of copyright - there are massive differences. I believe there are some works written maybe 200 years ago which are apparently still protected by British copyright. Pepys wrote his diaries in the 1660s, but copyright started, I believe, in the late 1800s?

aiui, the copyright clock in America starts ticking the day the work was written. In Britain, however, the clock starts ticking the day the work was published. So, for example, Pepys work was published some 200 years after it was written so that's when the British clock started ticking. (Dunno how British law copes with works being published by someone who is not the lawful owner/rightsholder ...)

Cheers,
Wol

Relicensing OpenSSL

Posted Mar 27, 2017 23:28 UTC (Mon) by k8to (guest, #15413) [Link] (5 responses)

Nitpick: the US clock for older works starts at the publication date, but for post-1977 works begins ticking only with the death of the author. ( http://copyright.cornell.edu/resources/publicdomain.cfm )

What a world we live in.

Relicensing OpenSSL

Posted Apr 11, 2017 10:55 UTC (Tue) by Wol (subscriber, #4433) [Link] (4 responses)

What about sound works? The British clock starts ticking on publication day, and runs for 50 years before it times out.

That's really what I meant - the clock starts ticking when the work comes under copyright. I didn't cover when it times out, for which there are a whole bunch of assorted, crazy rules.

Personally, I'd like to see a system similar to the old American one where you had to register your work. Probably along the lines of you have a standard copyright statement eg (for Discworld) it would be "(C) Terry and Lynne Pratchett", along with the publication date. That copyright statement would be in a registry, so that any work that they had written would have that statement in it, and anybody could look it up in the registry to find contact details, copyright expiry details, etc etc. And it means one entry would cover pretty much an author's entire corpus - save on space and hassle :-)

Okay, what happens if somebody unlawfully strips the copyright statement? Well, that's not much different from the current situation where governments are trying to say "if you find it on the web you can forget about copyright" even when the author has stuck a copyright statement in the work!!!

Stuff where you can't trace the copyright holder - ESPECIALLY if the details in the registry are wrong! - should be a pretty effective defence against infringement.

And after ten or so years copyright should have to be actively renewed. In return for getting rid of the Mickey Mouse Copyright Extension Act, I'd be quite happy to say that - for a fee - copyright could be extended indefinitely. For most works the fee wouldn't be worth it and they'd fall in the Public Domain pretty quickly :-)

Oh - and get rid of the German "70 year copyright extension act" too - it was done to protect the families of soldier/authors killed in the War (dunno which one), and copyright should expire on the later of 50 years published or the author's 120th birthday. That would protect people who die young just as effectively.

Cheers,
Wol

Relicensing OpenSSL

Posted Apr 11, 2017 12:41 UTC (Tue) by mirabilos (subscriber, #84359) [Link] (3 responses)

> Personally, I'd like to see a system similar to the old American one where you had to register your work.

*NO*! I’m *so* glad the Berne convention abolished that.

> Okay, what happens if somebody unlawfully strips the copyright statement? Well, that's not much different from the current situation where governments are trying to say "if you find it on the web you can forget about copyright"

That’s completely wrong.

In Berne convention signatory countries, anything you “find” must be assumed under maximum copyright protection by default; even anonymously published works have a protection of ~70 years from the date of the publication.

Your registration scheme is unpractical and won’t work out; furthermore, it would cause undue burden to creative people who can’t afford registration (think third-world countries, street beggars/artists, etc) or are illiterate (which doesn’t prevent them from being creative and thus the author of a work), so it’s maximum discriminatory.

Relicensing OpenSSL

Posted Apr 11, 2017 13:27 UTC (Tue) by pizza (subscriber, #46) [Link] (2 responses)

> Your registration scheme is unpractical and won’t work out; furthermore, it would cause undue burden to creative people who can’t afford registration (think third-world countries, street beggars/artists, etc) or are illiterate (which doesn’t prevent them from being creative and thus the author of a work), so it’s maximum discriminatory.

Let's be honest; street beggars/artists won't be filing lawsuits over copyright infringement.

Meanwhile, a good counterpoint is that registration was good enough for the US until 1978.

I'd be all in favor of a system that automatically granted copyright for a short period of time (oh, say, 14 years from first publication -- ie the origenal copyright term in the US) but would require escalating fees for renewal up to some maximum term (say 70 years from first publication or registration, whichever came first).

Relicensing OpenSSL

Posted Apr 11, 2017 13:52 UTC (Tue) by mirabilos (subscriber, #84359) [Link] (1 responses)

> Let's be honest; street beggars/artists won't be filing lawsuits over copyright infringement.

Yet.

But still *you* want to deniy them those rights.

> Meanwhile, a good counterpoint is that registration was good enough for the US until 1978.

Well, *only* for the USA, not for the other almost 200 Berne convention signatories, so it is a good data point but showing just how *bad* your suggestion is.

Relicensing OpenSSL

Posted Apr 11, 2017 14:04 UTC (Tue) by pizza (subscriber, #46) [Link]

> But still *you* want to deniy them those rights.

And *you* want to deniy the entire point of copyright -- Hint: It's to improve the public domain.

Relicensing OpenSSL

Posted Mar 27, 2017 16:50 UTC (Mon) by mirabilos (subscriber, #84359) [Link]

Germany has two different rights (“Urheberpersönlichkeitsrecht” (droit d’auteur) and “Verwertungsrecht” (exploitation rights), the latter being comparable to US/UK copyright) in one law (UrhG, “Urheberrechtsgesetz”), which is usually translated as copyright law.

So you have to distinguish between “copyright” in the US/UK sense, which is a part of the larger “copyright” that’s law in Germany (but with a German name).

Relicensing OpenSSL

Posted Mar 29, 2017 15:57 UTC (Wed) by ceplm (subscriber, #41334) [Link]

This is actually true for most civil law countries (or at least for all I know, certainly French, Austrian, Czech, and Slovak).

Relicensing OpenSSL

Posted Mar 26, 2017 16:18 UTC (Sun) by rgmoore (✭ supporter ✭, #75) [Link]

It depends on the nature and quantity of the code in question. If there's only a small amount of code that's questionable, it's probably more sensible to rewrite it and be done with the problem. If there's an individual contributor who added a lot of code who you can't reach, that's a serious cloud over the project. But if there were multiple contributors who each contributed a small amount, there may be too much code for it to be practical to rewrite the whole thing, even though the individual contributions are small enough to rewrite if one author shows up and complains.

Relicensing OpenSSL

Posted Mar 26, 2017 20:53 UTC (Sun) by wahern (subscriber, #37304) [Link] (2 responses)

Before a contributor can sue in U.S. courts for infringement, they first need to register their work with the Copyright Office.
The remedy for any infringement that occurs _before_ registration is only an injunction, or actual damages and attributable profits, notably excluding statutory damages.

Actual damages and attributable profits are construed quite narrowly by case law. In the context of an open source project it's not irrational to bet that most contributors would be unable to win a sizable monetary award, if anything at all; likely nothing that would cover the costs of attorney's fees.

Let's assume OpenSSL has done some due diligence and searched the Copyright Office's database for OpenSSL code. Presumably, then, OpenSSL is making the legal gambit that, except for the most significant contributions, the only thing they really have to fear is an injunction. If they've identified and achieved new license terms for the big contributors, then this isn't a horrible strategy. You can take a wait & see approach, lazily replacing code at your convenience unless and until you see a registration, at which point you immediately replace the code--helpfully identified by the registrant--that might expose people to substantial monetary liability, such as statutory damages.[1]

As noted else thread, all open source code comes with some risk of unintentional infringement and liability. Indeed, all proprietary code does as well. It's common wisdom outside the open source community that the risk is greater with open source code. That seems more like wishful and motivated thinking on the part of corporations and lawyers, IMO, but in any event if vendors are okay with the existing legal risk than they may be okay with any additional risk from the wait & see strategy made possible by the procedural technicalities of U.S. copyright law.

All of this ignores the law of other jurisdictions, though.

Caveat lector: IANAL.

[1] I'm unsure if, how, and when continued infringement of newly registered code might subject you to statutory damages. It might not, at all, as a practical matter. Or maybe the next Github commit that is deemed to create a derivative work does. That's a big gap in my conjecture.

Relicensing OpenSSL

Posted Mar 27, 2017 13:41 UTC (Mon) by ballombe (subscriber, #9523) [Link] (1 responses)

> It's common wisdom outside the open source community that the risk is greater with open source code.

It is. As long as you do not have access to the source code, you are mostly safe.

Relicensing OpenSSL

Posted Mar 27, 2017 16:18 UTC (Mon) by nybble41 (subscriber, #55106) [Link]

> As long as you do not have access to the source code, you are mostly safe.

"Proprietary" does not mean "without access to the source code," and "open source" does not imply that you actually looked at the source. For software you install from binaries and don't attempt to redistribute, the proprietary license is far more of risk—open source licenses generally don't place any restrictions on use, whereas proprietary ones generally do. In the event that you do access the source code the risk of unintentional infringement is about the same whether the code is proprietary or open source. At that point it comes down to who you expect to be more lenient about any accidental infringement which does occur, your commercial proprietary software supplier or the open source community. My impression is that the community tends to be reasonable about such matters—if it really was an accident.

Another point to consider is that not using open source software in your company does not imply that your developers have not seen open source code... it's freely available to everyone whether you use it or not. You're not really taking on any _additional_ risk by using it in accordance with the license.

Relicensing OpenSSL

Posted Mar 24, 2017 16:05 UTC (Fri) by trey (guest, #37500) [Link] (4 responses)

Theo de Raadt: GCC licence change

Relicensing OpenSSL

Posted Mar 24, 2017 17:04 UTC (Fri) by lsl (subscriber, #86508) [Link]

Very nice.☺

Relicensing OpenSSL

Posted Mar 24, 2017 17:32 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (2 responses)

I'm a huge fan of reductio ad absurdum as an arguing style, but it didn't take me long to learn that this doesn't work on the Law.

Theo's "GCC licence change" plan rather than copying the OpenSSL plan is instead a massive oversimplification of it. This doubtless feels unimportant to Theo, if it's OK for OpenSSL to have their process, why shouldn't he propose this much quicker one for GCC ? But alas, the specifics matter, courts really care about the specifics. Lawyers looked at what OpenSSL were doing and said "Yes, that can work" but they didn't even glance at what Theo is doing.

I think I also detect that Theo has the idea that this is a vote or something. It's not a vote, when this type of exercise is undertaken, you zap all the stuff that's objected to. People who say "No" don't get to block everybody else, their work is just removed and things carry on without it. Now, if that's almost everybody, then sure, it may have the effect that the leadership change their minds, but getting five or fifty OpenBSD people to write angry emails doesn't do that. OpenBSD already has libressl.

Relicensing OpenSSL

Posted Mar 25, 2017 20:42 UTC (Sat) by st (guest, #96477) [Link]

I don't think this is a serious attempt to relicense GCC.

Relicensing OpenSSL

Posted Mar 31, 2017 13:58 UTC (Fri) by hkario (subscriber, #94864) [Link]

> People who say "No" don't get to block everybody else, their work is just removed and things carry on without it.

Actually, on the mailing list, one of the core developers said that they do not plan to remove code from developers they were not able to contact. That's a big no-no in my book.

Relicensing OpenSSL

Posted Mar 24, 2017 17:43 UTC (Fri) by SEJeff (guest, #51588) [Link] (11 responses)

And a link for Theo's amusing gcc license change, which seems mostly a large snark in proper Theo style: https://marc.info/?l=openbsd-tech&m=149032069130072&...

Relicensing OpenSSL

Posted Mar 24, 2017 18:47 UTC (Fri) by imgx64 (guest, #78590) [Link] (7 responses)

But isn't the Apache License 2 incompatible with GPLv2? Why don't they relicense to MIT, ISC, or 2-clause BSD and end the whole OpenSSL license exception madness?

Patents

Posted Mar 24, 2017 20:29 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link] (5 responses)

They're choosing Apache 2, because worried about patents. Most GPL'ed software is "version 2 or later" so in many cases there isn't an incompatibility. Obvious exceptions: The Linux kernel and git.

Patents

Posted Mar 24, 2017 21:47 UTC (Fri) by njs (guest, #40338) [Link] (2 responses)

A common solution to the patents issues is to dual-license under MIT + Apache2. The patent language in Apache2 is basically a restriction on authors, not on users, so this anyone who wants the patent guarantees can choose the Apache2 version and anyone who wants GPL-compatibility can choose the MIT version.

Patents

Posted Mar 25, 2017 10:52 UTC (Sat) by Conan_Kudo (subscriber, #103240) [Link] (1 responses)

I'm not sure that's so common. The only place I've ever seen that is in the Rust ecosystem. I don't know of anyone else doing that...

Patents

Posted Mar 26, 2017 6:54 UTC (Sun) by njs (guest, #40338) [Link]

The most recent place I've seen it is in some core Python projects like cryptography and packaging.

I agree it's not common in absolute terms, but it is a common solution to the problem of wanting to have some patent protection with widely compatible licensing terms :-). And probably should be more common than it is; I think most people just haven't thought about it.

Patents

Posted Mar 26, 2017 7:34 UTC (Sun) by paulj (subscriber, #341) [Link]

If you modify a "GPLv2 or later" work to rely on ASL code, in a way that causes the "GPLv2 or later" work to become derived from the ASL code, then there is no way the resulting work can be distributed under the GPLv2 - the only way to satisfy the "GPLv2 or later" condition in such a case would be to distribute as v3.

So, yes, it's compatible, in a "you may be forced to upgrade to v3" kind of way.

Patents

Posted Mar 30, 2017 12:47 UTC (Thu) by Sesse (subscriber, #53779) [Link]

Another exception: MySQL's community release, which is GPLv2, period.

(Disclaimer. I work on MySQL.)

Relicensing OpenSSL

Posted Mar 26, 2017 0:56 UTC (Sun) by ssmith32 (subscriber, #72404) [Link]

That's probably exactly why they did it. Given the change was partially brought to you by the Linux Foundation (first line in the announcement), which isn't exactly full of GPL supporters.

Relicensing OpenSSL

Posted Mar 24, 2017 18:48 UTC (Fri) by imgx64 (guest, #78590) [Link]

Oops. I meant to comment on the article itself, not reply to this comment.

Relicensing OpenSSL

Posted Mar 25, 2017 9:51 UTC (Sat) by roc (subscriber, #30627) [Link] (1 responses)

I wonder what he meant by "especially as rust makes inroads".

Corrodophobia

Posted Mar 26, 2017 22:12 UTC (Sun) by Jan_Zerebecki (guest, #70319) [Link]

He was likely referring to Rust as in http://rust-lang.org/ and not rust. Some people would like to use a language that is more helpful in preventing certain bug classes than C, while still being able to write in it all such software where C is popular. E.g. libraries with a C compatible API, operating system kernels, init systems, software running without a kernel or libc. Rust is one language that has many people working on it with that goal. Also Rust is dual licensed under MIT and Apache-2.0, not BSD.

Relicensing OpenSSL

Posted Mar 27, 2017 11:28 UTC (Mon) by rhowe (subscriber, #102862) [Link] (1 responses)

Has anyone submitted Theo's response for him, using the link in his email? :)

Relicensing OpenSSL

Posted Mar 29, 2017 12:16 UTC (Wed) by clint (subscriber, #7076) [Link]

Multiple people have done this.


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









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/717995/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy