Hacker News Reader

Comment by rqs | Hacker News Reader

> the title and the tone implies that you as a contributor should be a FOSS maximalist.

But what if somebody was changed the license from BSD to proprietary after you've contributed to the project? Would you still be happy about it then?

I think the idea was: I have my code contributed under BSD, so you cannot re-license my code without clearance from me.

View on HN

To have contributed under BSD means that you have contributed under a license that permits relicensing. To contribute under the "BSD license but secretly I'm not going to let you relicense" means that you have not in fact contributed under the BSD license in the first place, but your secret license.

If you want to contribute under your secret license, what it means is that you don't want to spend any time in the first place contributed to the BSD-licensed project. Make your changes and use them, but don't contribute them back. The BSD license permits this fully, including your ability to distribute and sell the resulting software, subject to the advertising clause as appropriate. So it's not like there's anything onerous about this idea.

"BSD license but secretly I'm not going to let you relicense" means that you have not in fact contributed under the BSD license in the first place, but your secret license.

I understand what you're saying, but even if you do release BSD software along with code under a different license, you are still bound by the (very minimal) requirements of the BSD license.

That’s a bizarre idea. If you don’t want people doing things the license allows, don’t contribute under that license. If you don’t want people relicensing your code without your specific permission, then the BSD license is not the one you want, and you shouldn’t contribute to projects that use it.

Actually, it is you that have the bizarre idea. BSD licences do not permit people relicensing code without permission of the copyright holder. Copyright licences cannot do so. No copyright licence could do this.

To do this, the actual copyright ownership has to be transferred. A copyright licence is a grant of permission by a copyright owner who retains that ownership. It is not a transfer of ownership.

* http://uscode.house.gov/view.xhtml?path=/prelim@title17/chap...

You don't need ownership to relicense. You just need a license which permits relicensing, which BSD does (as long as the new license is compatible, and they usually are).

It does not permit relicensing. You may use it in an aggregate work with other pieces that have a different license, including proprietary or GPL, but that does not mean your code is relicensed.

Is there an actual difference there, or is this just semantics?

You can't take the code as-is and turn it into proprietary code. You need to build a derivative work that contains the permissive code plus some other proprietary stuff.

1. Its a good idea, if you are going to use licensed code that you have an understanding of the law and what it actually means when you use other people's code.

2. As the code is not relicensed you have to follow the terms. Generally for example even BSD licensed code (other than BSD0) requires that you include attribution both in source code and binaries or documentation, so you need to keep a full list of licenses and authors and list them out in the docs.

Incorrect, as I just explained.

No, but I would be just as upset if I wouldn't have done that contribution.

There is no way they can change the past - my contribution is still open source and so is the project up until the version where they introduced the license change. The version I made my contribution to is still BSD but the current upstream master might not be.

Yes, but now that version is quickly becoming stale, growing CVEs and perhaps becoming incompatible with the new upstream, with a community left in disarray that more often than not fails to support a fork.

Software goes stale all the time for many reasons. If you're not prepared to fix it or replace it yourself, you really shouldn't be using it.

In my experience, a lot of the projects with large numbers of CVEs also have a rather sprawling project with lots of things that can (and should) be disabled if they don't apply to your environment; most of the CVEs will happen in parts you don't use. (That's clearly not the case for all projects, openssl is a joy to have as a critical dependency, but there are some options now)

I don't see how a CLA materially affects this possibility, though. If my company sponsors a BSD-licensed open source project without enforcing a CLA and then decides that starting with the next major version, we're taking it closed source, the exact same thing you describe is just as likely to happen as with a CLA -- the deciding factor seems to me to be whether most of the development activity happening on the codebase is community-driven or driven by paid developers at the company. Conversely, if the community is active and doing a lot of major work already, and there are enough non-company developers with the time, interest, and skill to start and sustain a fork, they're going to do that with or without a CLA.

Changing from BSD to proprietary does not invalidate any prior BSD license on work that has been published.

In such event, you can still distribute the existing source code, or fork the project in order for it to remain BSD-only.

>But what if somebody was changed the license from BSD to proprietary after you've contributed to the project? Would you still be happy about it then?

If you signed a CLA then presumably you're either happy about it or you've just signed a contract you had literally zero understanding of.

If you're more concerned about getting your fix in upstream or the kudos that comes with being a committer to "x project" then yeah, you probably wouldn't mind.

I personally view Microsoft's use of CLAs as a trap that highlights just how disingenuous their "turning over a new open source leaf" was but I don't really have a problem with open source projects using them in general. The maximalist approach to open source would mean a lot of really great open source would never get written. Authors have gotta eat.

Reply on news.ycombinator.com