On 04/12/17 21:54, Antony Polukhin via Boost wrote:

2017-04-11 15:32 GMT+03:00 Fabrizio Riente via Boost : <...>

...

I was wandering if under this license it is possible to distribute the application for free to other universities and interested people without sharing the source code.

This issue often confuses users. Especially non native speakers for whom all that perfectly measured legal words make absolutely no sense! Seriously, I need to spend about an hour to understand what a license is talking about. And I *know* the restrictions, it's just unbelievably hard to convert legal words to understanding.

What's worse - BSL is not a very popular license. There's probably only 1-2 pages in non-English languages about BSL on wikipedia. Other wiki pages redirect from BSL to Boost libraries. So for example I can get no information about BSL in Russian. I've tried twice to translate BSL to Russian. Both times the wiki page was removed as a minor/useless topic.

Could we somehow solve the issue in Boost by * also distributing Boost under the MIT license (super extremely very close license)

I think, multi-license distribution would only complicate things, both for developers and users, for no real gain.

* or by summarizing the differences between BSL and MIT in simple English like here http://softwareengineering.stackexchange.com/a/44116

And it's really an issue! I know at least 6 small Russian companies that do not use Boost libraries because they could not get through the license.

If you can't understand the Boost license, why would you understand the MIT license?

This issue often confuses users. Especially non native speakers for whom all that perfectly measured legal words make absolutely no sense! Seriously, I need to spend about an hour to understand what a license is talking about. And I *know* the restrictions, it's just unbelievably hard to convert legal words to understanding.

What's worse - BSL is not a very popular license. There's probably only 1-2 pages in non-English languages about BSL on wikipedia. Other wiki pages redirect from BSL to Boost libraries. So for example I can get no information about BSL in Russian. I've tried twice to translate BSL to Russian. Both times the wiki page was removed as a minor/useless topic.

Also, translations prepared by non-lawyers are problematic.

Could we somehow solve the issue in Boost by * also distributing Boost under the MIT license (super extremely very close license) * or by summarizing the differences between BSL and MIT in simple English like here http://softwareengineering.stackexchange.com/a/44116

I would *really* prefer the EUPL over the MIT licence. The EUPL comes in 22 languages and was written to work well in any of the major legal systems in the world, including Russia's. I'm currently strongly considering placing Outcome and all my Boost like libraries under the EUPL licence. It far better matches the "Licence requirements" at http://www.boost.org/development/requirements.html than the Boost licence does. And it comes in 22 translations as prepared by lawyers in those languages, and those translations have undergone multiple rounds of peer review and checking. It is a far superior licence for Boost code. https://joinup.ec.europa.eu/community/eupl/og_page/european-union-public-lic... Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

I'm currently strongly considering placing Outcome and all my Boost like libraries under the EUPL licence. It far better matches the "Licence requirements" at http://www.boost.org/development/requirements.html than the Boost licence does.

A license that is 7 A4 pages doesn't look like one that is "simple to read and understand".

A licence which understands that there is a legal world outside the United States of America and it is not the same needs to be longer. Many would find the Boost licence insufficiently specified to give clarity and lack of ambiguity.

Also, from a cursory look, it doesn't seem to require to retain copyright notices and the license in redistributed source code. There may be other significant differences, which is difficult to learn quickly because of that license volume and language.

I don't know what you're on about here. The language is very simple. Much clearer than say the GPL. And the clause you didn't find is on page 3: "Attribution right: the Licensee shall keep intact all copyright, patent or trademarks notices and all notices that refer to the Licence and to the disclaimer of warranties. The Licensee must include a copy of such notices and a copy of the Licence with every copy of the Work he/she distributes and/or communicates." Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

A licence which understands that there is a legal world outside the United States of America and it is not the same needs to be longer.

Many would find the Boost licence insufficiently specified to give clarity and lack of ambiguity.

The BSL was written with international consideration in mind. And most of the long language you see in other licenses was deemed superfluous as it was already covered by various international treaties and accords. Obviously, IANAL, but that is my recollection from the various discussions and legal team at the time of the BSL.

With respect, the aversion to Boost code by corporate legal teams is very well known here. Both in the US and outside. The superfluous wording you mention is highly important because those international treaties were not equally enacted in each country. For example, the US only recognises moral copyright to visual artistry alone. Most of Europe applied that treaty to everything. China has another application again. You need wording to indicate which enactment applies, else it is whatever formulation applies in the court in question rather than what the licensor intended. I think the BSL was up to par *at the time it was written* as compared to other software licences at that time. But the world has moved on. Most open source orgs have released a v2.0 of their licences to reflect the modern climate, and to reassure those corporate legal teams so the software is less objectionable. Apache v2.0 licence is an excellent example of a refresh to solve such worries. Meanwhile the BSL remains firmly locked in the past. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

...

The BSL was written with international consideration in mind. And most of the long language you see in other licenses was deemed superfluous as it was already covered by various international treaties and accords. Obviously, IANAL, but that is my recollection from the various discussions and legal team at the time of the BSL.

With respect, the aversion to Boost code by corporate legal teams is very well known here. Both in the US and outside.

reference please

You can search this list's archives for many tales of woe when trying to get Legal in a multinational to approve usage of Boost. I'm not saying it's all due to the Licence, there are other causes. But lawyers like detail, and the BSL lacks clarity. The biggest objection I always heard from Legal(s) was patent threat, and the BSL says absolutely zero about patents. You may notice all the v2.0 revisions of major open source licences do now say something about patents. That's why. If the steering committee might be thinking of fixing the BSL, better to adopt the Apache 2.0 licence https://www.apache.org/licenses/LICENSE-2.0.html. It has 25% of the open source market according to Wikipedia, and it's very well recognised by Legal, unlike the Boost licence. It isn't ideal for European jurisdictions, but it is widely recognised here too. They know how to deal with it upon sight, so in that sense it greatly improves on the BSL. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 13/04/2017 00:04, Rene Rivera via Boost wrote:

On Wed, Apr 12, 2017 at 5:55 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:

...

If the steering committee might be thinking of fixing the BSL, better to adopt the Apache 2.0 licence

Also not compatible with the BSL.

The BSL is compatible with the GPL, so I find it very hard to believe that Apache 2.0 is incompatible. Source: https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_li... Source: https://www.gnu.org/licenses/license-list.en.html Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

The BSL is compatible with the GPL, so I find it very hard to believe that Apache 2.0 is incompatible.

Source: https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_li...

Source: https://www.gnu.org/licenses/license-list.en.html

I believe it is more correct to say Apache 2.0 does not meet Boost requirements to the license in that it is more restrictive than the BSL. In particular, BSL has no requirements similar to those in Apache 2.0 [1] Section 4 item b.

Also, unlike BSL, Apache 2.0 is not compatible with GPLv2, only GPLv3, which is not as popular.

The boilerplate comment that is recommended to be used to apply the license, and the license itself, are significantly longer than those of BSL. I'll remind that this thread has started from someone having difficulty reading and understanding the BSL, and Apache 2.0 is not likely to improve on that.

[1]: https://www.apache.org/licenses/LICENSE-2.0

Irrespective of the merits of the various licences, I would remind everyone that it took us the better part of 2 years last time we changed licences... and Boost has grown immeasurably larger since then. I am emphatically not going to take on that task again, if someone else wants to volunteer, I can only wish them good luck - they will most certainly need it! Best, John. --- This email has been checked for viruses by AVG. http://www.avg.com

On Thu, Apr 13, 2017 at 5:29 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:

...

Irrespective of the merits of the various licences, I would remind everyone that it took us the better part of 2 years last time we changed licences... and Boost has grown immeasurably larger since then. I am emphatically not going to take on that task again, if someone else wants to volunteer, I can only wish them good luck - they will most certainly need it!

New libraries can be licensed under improved licences so long as they are compatible with the Boost licence and meet the licence requirements at http://www.boost.org/development/requirements.html.

Good point indeed.. But so far in this thread non of the licenses mentioned meet those requirements. Perhaps someone, with legal acumen, could go the OSS licenses https://opensource.org/licenses/alphabetical and indicate which ones meet the Boost requirements. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 04/13/17 17:04, Peter Dimov via Boost wrote:

Niall Douglas wrote:

...

New libraries can be licensed under improved licences so long as they are compatible with the Boost licence and meet the licence requirements at http://www.boost.org/development/requirements.html.

Hypothetically, yes. In practice, no. If it's not BSL, it's not going into Boost.

I agree with this sentiment. In fact, why not spell it explicitly on the web site?

On 4/13/17 08:49, Niall Douglas via Boost wrote:

...

...

New libraries can be licensed under improved licences so long as they are compatible with the Boost licence and meet the licence requirements at http://www.boost.org/development/requirements.html.

Hypothetically, yes. In practice, no. If it's not BSL, it's not going into Boost.

That's a pretty arrogant statement.

It's down to the review manager in question at the time of review. Unless you're the review manager, your vote is just one of many considered.

Niall

It is significantly more complicated than that. If it isn't BSL it would need to be reviewed by SFC's counsel and we would need to weigh the benefits over the confusion. -- Michael Caisse Ciere Consulting ciere.com

Niall Douglas wrote:

...

Hypothetically, yes. In practice, no. If it's not BSL, it's not going into Boost.

That's a pretty arrogant statement.

It's just putting the status quo in words. I'm not making an "ought" statement, I'm making an "is" statement. The BSL is a de-facto requirement. Do you think that all libraries in Boost use the BSL by some sort of a happy accident? How would you estimate the chances of that coincidence? The reason all Boost libraries use a single license is to ease adoption. Once the BSL is cleared by legal, ALL of Boost is cleared by legal. If libraries could pick a license, every library would need to be cleared separately. This is enforced by the Inspect tool, see https://github.com/boostorg/inspect/blob/develop/license_check.cpp For the record, the decision to use the BSL wasn't mine, I didn't write the Inspect tool, the decision to add a BSL check in it wasn't mine, and the rationale to use a single license for each and every file in the distribution isn't mine either.

I believe it is more correct to say Apache 2.0 does not meet Boost requirements to the license in that it is more restrictive than the BSL. In particular, BSL has no requirements similar to those in Apache 2.0 [1] Section 4 item b.

It is correct that Apache 2.0 licence imposes more requirements. That's its merit over the BSL.

Also, unlike BSL, Apache 2.0 is not compatible with GPLv2, only GPLv3, which is not as popular.

Correct.

The boilerplate comment that is recommended to be used to apply the license, and the license itself, are significantly longer than those of BSL. I'll remind that this thread has started from someone having difficulty reading and understanding the BSL, and Apache 2.0 is not likely to improve on that.

You are allowed to, and indeed encouraged to, provide just a URL to the licence text. Besides, Apache 2.0 is a very popular and well understood licence. You don't need a large boilerplate, unlike the relatively unknown BSL. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 04/13/17 01:55, Niall Douglas via Boost wrote:

The biggest objection I always heard from Legal(s) was patent threat, and the BSL says absolutely zero about patents.

You may notice all the v2.0 revisions of major open source licences do now say something about patents. That's why.

Having a section regarding patents in the license implies that the author is supposed to perform a research on possible patent infringement. Otherwise he might be giving a license to patents he doesn't own. I'd say most of the Boost contributors don't have the resources or will to conduct such research, so this task is upon users (more presicely, those users who act in jurisdictions that recognize software patents). Pretty much the same goes for trademarks.

Niall Douglas wrote:

Without it, it allows bait-and-sue on code because say someone like you Andrey could deliberate contribute code to Boost violating a software patent you hold. You then wait for people to use your patented code in Boost. You then sue them for patent violation.

Has this ever occurred? Because the license clearly states that the owner grants a right to use, and defending in court the proposition that this grant somehow only applies for use in a copyright sense but not for use in a patent sense (as if there's a difference) will be an interesting exercise.

On 4/13/17 08:56, Niall Douglas via Boost wrote:

On 13/04/2017 15:06, Peter Dimov via Boost wrote:

...

Because the license clearly states that the owner grants a right to use, and defending in court the proposition that this grant somehow only applies for use in a copyright sense but not for use in a patent sense (as if there's a difference) will be an interesting exercise.

I would never second guess a clever lawyer.

The point being made is not whether any licence is enforceable in court. Most have never really been tested in a court, even the GPL. It is about risk minimisation to a lawyer, and persuading Corporate Lawyers that the licence on some bit of open source is minimum risk or not.

I have seen no persuasive argument that the BSL is perceived as less legal risk to lawyers than the Apache 2.0. From all my interaction with Corporate Legal departments over the years, never mind trying to get Professional Indemnity insurance for works covered by the BSL as against a better known licence (tl;dr forget about it, they won't insure BSL licenced code, at least in Europe), I am very sure that the Apache 2.0 is a safer, more acceptable, more inclusive, more commercially friendly licence than the BSL.

New Boost libraries should as a minimum, use the Apache 2.0 licence in preference to the Boost licence. Period.

Niall

Since there is plenty of this banter going on in the thread, let me add my own experience of 11-years dealing with BSL. We have had clients in the US, Europe, and Asia. Our clients include very large multinational corporations that are household names and small start-ups that are looking for exit plans to sell. Our clients work in fields such as financial, medical, various research, consumer products, business-to-business ventures, blaa blaa blaa... Many of the organizations are already using Boost and some were introduced to Boost during the project. Those we introduced to Boost (including large international corps) have all had their teams of concerned lawyers evaluate the BSL to determine the risk of including libraries. We have some clients that require each new OSS library to be evaluated (add Boost.MSM and have it and dependencies evaluated. Now add Boost.Spirit and have it and dependencies evaluated.) We have helped several companies through the IP purchase process in which OSS inventories are scrutinized by teams of lawyers looking for a reason to not purchase or to reduce the cost. Our most recent exercise in this was last month. Not one lawyer along the way has raised a red flag. There has been more than enough opportunity for the BSL to be rejected. Not one lawyer has done so. I am sorry you have had such a horrible experience with licensing. Dealing with this stuff can be hard. Perhaps it is a reflection of the quality of lawyer you are interacting with. Ambiguity *always* works against the writer of the license. That is the legal way of it. So while you have had the experience of "aversion to Boost code by corporate legal teams" I have had the exact opposite experience. In fact, we have clients that say if it isn't BSL ... it isn't going in. michael -- Michael Caisse Ciere Consulting ciere.com

On 12/04/2017 22:18, Peter Dimov via Boost wrote:

...

Also, from a cursory look, it doesn't seem to require to retain copyright notices and the license in redistributed source code.

It does, see "Attribution right" in clause 5. It's not even limited to source code.

Earlier on "the Work" is defined to be the source code I believe.

I'm not clear on "Provision of Source Code", it's not limited to the Original Work, so it seems to apply to derived works as well. If so, this makes the EUPL unsuitable for Boost. We don't require source availability for derived works.

It's a much weaker "non viral" copyleft than the GPL because it defers to any of the compatible licences listed at the end if combined into a work consisting of multiple licenced codes. I had understood that to mean that if your EUPL code is used as a library in a bigger project, no obligations to distribute source land on the licensee, but if they distribute a modified copy of your library as a standalone thing, then they can't supply prebuilt DLLs without source code. But that requirement, now you make me think about it, does violate the Boost licence which does allow people to derive from Boost and publish binaries without source. Good catch. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Wed, Apr 12, 2017 at 3:55 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:

...

Could we somehow solve the issue in Boost by * also distributing Boost under the MIT license (super extremely very close license)

The MIT license is technically incompatible with the Boost license. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 13/04/2017 11:15, Stefan Seefeld wrote:

It might be a good idea to collect such bits of wisdom in a common place (such as the wiki). A good starting point: a list of widely known Free Software licenses, annotated to indicate whether they meet the requirements in http://www.boost.org/development/requirements.html#License (with explicit references to the clause they don't meet if applicable).

The BSL is generally more permissive than the other popular licenses (in particular placing no obligation of attribution or source-sharing on distribution in binary form); that's typically where the conflicts lie. To most users of the Boost libraries, it doesn't make any difference either way -- they either distribute the libraries in compiled form, which the BSL permits without complications, or they distribute their own library/application in source form typically without redistributing the Boost libraries themselves (instead just telling people where to find them or expecting that they'll be able to find them themselves). The latter approach might technically get them in trouble with their own licenses (eg. if they're using GPL) but most people don't worry about that either.

On 04/13/17 13:40, Josh Juran via Boost wrote:

Authors who license their own code under the GPL are not bound by the GPL with respect to that code. An author is allowed to offer anything under the terms of the GPL, including a program that links to a binary-only library...

That's not my reading of the GPL. According to Section 6 [1], everyone, including the author, must provide source code of the (derived) work as part of distribution, which is not possible if the work contains a binary-only component. [1]: https://www.gnu.org/licenses/gpl.html

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Niall Douglas via Boost Sent: 12 April 2017 21:56 To: boost@lists.boost.org Cc: Niall Douglas Subject: Re: [boost] Boost licensing information

...

This issue often confuses users. Especially non native speakers for whom all that perfectly measured legal words make absolutely no sense! Seriously, I need to spend about an hour to understand what a license is talking about. And I *know* the restrictions, it's just unbelievably hard to convert legal words to understanding.

What's worse - BSL is not a very popular license. There's probably only 1-2 pages in non-English languages about BSL on wikipedia. Other wiki pages redirect from BSL to Boost libraries. So for example I can get no information about BSL in Russian. I've tried twice to translate BSL to Russian. Both times the wiki page was removed as a minor/useless topic.

Also, translations prepared by non-lawyers are problematic.

...

Could we somehow solve the issue in Boost by * also distributing Boost under the MIT license (super extremely very close license) * or by summarizing the differences between BSL and MIT in simple English like here http://softwareengineering.stackexchange.com/a/44116

I would *really* prefer the EUPL over the MIT licence. The EUPL comes in 22 languages and was written to work well in any of the major legal systems in the world, including Russia's.

I'm currently strongly considering placing Outcome and all my Boost like libraries under the EUPL licence. It far better matches the "Licence requirements" at http://www.boost.org/development/requirements.html than the Boost licence does. And it comes in 22 translations as prepared by lawyers in those languages, and those translations have undergone multiple rounds of peer review and checking. It is a far superior licence for Boost code.

https://joinup.ec.europa.eu/community/eupl/og_page/european-union-public-lic...

I can't help myself bike shedding that clause 8 looks to have less complete no-liability. "Except in the cases of wilful misconduct or damages directly caused to natural persons, the Licensor will in no event be liable..." IANAL, but might look as though - If someone dies from a life-support software malfunction, the author is on the hook? (Damage to 'un-natural persons' are exempted I note ;-) It looks like a case of "If it ain't broke, don't fix it to me". If your lawyers can't be bothered to read or translate the Boost license, or don't like it - tough? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830