Pro vs Open source and declaration of crates/libraries used

Hi,

My organization mainly works in C++ and go, but we are moving slowly towards Rust.

One main area of concern is keeping technology used confidential. C++ has commercial libraries that gives the right to hide if we used them. And in go, standard library pretty much has everything so we don't have to declare anything what was used (clarification: it is distributed with Go's license).

With Rust, on the other hand, it appears most of the useful libraries have independent crates which requires declaration I believe. And there are no pro paid crates yet.

How do companies that keep these things confidential use Rust in their distributed software code?

Best regards

2 Likes

Kruzer

As a producer of commercial, proprietary software it is of course your responsibility under copyright and other intellectual property law to ensure that you are not redistributing the work of others without appropriate licensing.

You should not expect to use the work of others for free. Although that is often possible if it is licensed in that way.

To that end Rust crates mostly specify the license under which they are published. And you should check the terms of all such licenses of all crates you use.

The tool cargo-license can help with that: GitHub - onur/cargo-license: Cargo subcommand to see license of dependencies

2 Likes

We are not using Rust code in software that is distributed at the moment, hence, I'm asking for organizations that keep libraries or technology used confidential what options are available for them?

I don't think I understand your question exactly.

Whatever organizations they are have the same opportunities as you or I do. If they want to copy and/or use any published work they should check the license it is published under. Or perhaps try to negotiate with the author for special licencing terms.

This is true of all software since decades ago when copyright law was extended to cover it. Nothing special about Rust or the Rust crates.

What might be special about the situation you are describing?

2 Likes

I understand that, and that is not the issue in OP :slight_smile:

Kruzer

Now I'm more confused. In your opening post you stated:

As far as I know I have addressed these issues. In short, one deals with it the same way as dealing with any other published works. Software of otherwise. Check the licenses.

And suggested something that could help with that task.

If neither of the above is what you actually meant to say perhaps you could spell out exactly what it is you want to do?

It appears that is the only available option until paid licenses come into scene.

I am not a lawyer. But I believe this is correct.

As I understand, the Rust standard library is also dual MIT and Apache2 licensed. As such, even just using the standard library, you might need to include a license.

See this post from a year ago: Reddit - Dive into anything. No one is offering legal advice, but as I understand it, people are saying that even without third-party libraries, you statically link to stdlib, and thus need to include stdlib's copyright notice.

I don't believe there's been any work towards having stdlib or crates licensed such that you can keep the use of Rust confidential.

It's an interesting use case, one which I don't think many people have looked into for Rust... There's an assumption within the community that anyone using Rust libraries will be OK with using MIT or Apache2 licenses.

For many cases, this can still be kept confidental, for instance if using rust in server-side software which is never distributed. But for distributing rust software, I have no idea.

2 Likes

@daboross thanks for the reply, you understood the issue faced in the OP precisely.

And I believe there are many software development organizations that are facing this issue with Rust to replace C++ in their projects.

1 Like

Kruzer

OK. So am I correct in thinking that what you want is a supply of crates that can be bought and used in commercial closed source software without any need to disclose ones own source, as the GPL would dictate, and without any need for attribution, as BSD or whatever licenses sometimes require?

I cannot know of course but my feeling is that may never happen. The era of closed source proprietary software products is drawing to an end.

For use in house of course MIT, BSD etc licenses are not a problem anyway.

1 Like

There is probably confirmation bias with mostly working in open source projects communities. There is case for open source software and it is beneficial in many use cases but it may not be suitable for every segment of software industry. There is a huge industry of small software development shops around the world who use closed source software and depend on proprietary libraries for their clients and they will probably keeping using them for foreseeable future because it fits better for their business model.

2 Likes

I'm selling commercial software that includes some BSD-licensed components, and in my experience this isn't a problem for business buyers at all. Any large software project these days is likely to use at least some open-source software that requires attribution, so adding one more copyright line in documentation isn't a big deal for them.

5 Likes

How many companies are there out there who are making a living creating closed source commercial libraries now a days? As opposed to applications.

How many of those are not in turn using some open source code in their products? BSD or whatever.

How many of them might be considering rewriting or interfacing their products to some new language, Rust in particular in this case?

I have no idea of course. Just speculating that it may not be as many as it once was. And that it might be early days yet for such companies to start supporting Rust. If ever they do.

Of course if MS were to embrace Rust, it seems they are looking at it, the situation might change significantly.

2 Likes

This is a guess, but probably more than a million only in India.

It becomes a stumbling block when there is a client who wants to keep the technologies used confidential. And there are many commercial clients who demand this.

The companies I'm familiar with, they are content with use of C++. And when asked about security and code quality concerns they believe C++ is adding those.

However, in my experimentation Rust is better at preventing bugs and C++ trying to improve code quality and security ergonomics but I doubt they can do it at the level of Rust since they have to support legacy code.

So I'm trying in my organization where possible to move to Rust and discovered this issue where there are clients who wants to keep technologies used confidential even if they have to pay more but it is not possible because this use case was not considered.

MS is familiar with this segment of software industry, so yea when they fully support Rust in Visual Studio they will probably cover this use case.

3 Likes

Now I'm curious: why would anyone need the ability to use open source libraries to make software which they want to offer/sell/expose to a third party and at the same time keep secret from that third party any information about how they made it?

I've simply never heard of a reason to do this in any context (the most top-secret commercial stuff is simply only used in-house AFAIK), which IME usually means either I or they are deeply misunderstanding something.

2 Likes

It doesn't have to be top secret stuff. Probably they don't want the competitors offices in their proximity to know what they have used. Probably their employees using the software doesn't know either.

It may depend on region to region, but in my experience, lot of clients ask to keep it confidential. Hence, we cannot use libraries that have to be declared in the 'about box' in these cases.

1 Like

I would ask the clients/business folks what they hope to achieve by keeping the fact Rust or some particular library was used secret. I’m sure they have a good intent and goal, but I’m also just as sure they would be wrong that secrecy achieves that goal. From there, it’s a discussion about trade offs. “Yes, we can avoid [well known, battle tested by thousands of users, library], but you’ll need to spend $x to recreate the functionality and it won’t be as good as [well known library] by any metric. OR we can spend $200 of dev time adding a disclaimer in the about box and get back to working on the core product. It’s your money, your call.”

Put things in terms business people understand, dollars & cents.

7 Likes

Probably worth noting that if you're handing over binaries, it's almost impossible to hide the technology used if someone's really determined to find out. It's not something I follow, but there's at least active research and probably existing tooling to detect non-compliant use of OSS libraries, and there's no reason to think this couldn't extend to closed-source too.

3 Likes

This isn't related to obscuring your dependencies, but if using libraries with a licence that requires disclosure is your problem there is the cargo-deny plugin to allow you to easily prevent crates with the "wrong" licence being included in your source.

8 Likes

The discussion is heading towards what clients/business folks should do. Sure they are advised on costs, ease, and other issues but in the end it is their choice.

It is pretty much standard process of any commercial software development to give clients advantages and disadvantages of languages, tooling, and libraries related to their requirements. In the end it is their choice.

I put it here because I see demand about confidentially a lot from business clients and it may help Rust's adoption into this market segment.

And this market segment is huge but hidden, these small software development companies develop lot of projects for small and medium size businesses, but their activity is not much visible online.