6 ms·
> 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 af
by rqs 8y ago
> 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.
- Legogris 8y agoNo, 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.
- Sir_Cmpwn 8y agoYes, 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.
- toast0 8y agoSoftware 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)
- chipotle_coyote 8y agoI 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.
- sparkie 8y agoChanging 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.
- jerf 8y agoTo 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.
- dec0dedab0de 8y ago"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.
- mikeash 8y agoThat’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.
- JdeBP 8y agoActually, 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/chapter2&edition=prelim http://uscode.house.gov/view.xhtml?path=/prelim@title17/chap...
- mikeash 8y agoYou 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).
- justincormack 8y agoIt 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.
- mikeash 8y agoIs there an actual difference there, or is this just semantics?
- newacctjhro 8y agoYou 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.
- crdoconnor 8y ago>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.