3 ms·
Yes, but such a policy should be in place before you start using open source code, by the time you wonder about giving back to the community these should be pas
by antonovka 17y ago
Yes, but such a policy should be in place before you start using open source code, by the time you wonder about giving back to the community these should be passed stations. After all, using open source code also comes with strings attached, not in the least what you will be able to do with the code that you produce. If you find out - as a manager - that one of your employees has tainted a bunch of code by importing open source software in to the company repository and modifying it extensively then you have a problem just the same.
Yes -- the policy we have is roughly:
MIT/BSD/Apache: OK for any purpose -- Note the license requirements in the project's top-level LICENSE file.
LGPL - Only as a library, and only for non-statically-linked projects.
GPL/MPL/Copyleft - Only for system utilities, not to be integrated into any existing code base under any circumstances. We'll still contribute GPL licensed code back to projects.
On the flip side, the side-effect of this policy is that we rarely contribute anything back to GPL projects, but quite often contribute changes back BSD/MIT/etc licensed projects.
- jacquesm 17y ago> On the flip side, the side-effect of this policy is that we rarely contribute anything back to GPL projects, but quite often contribute changes back BSD/MIT/etc licensed projects. There's an interesting datapoint. I wonder if that's a common thing or not. It definitely might be. Your policy makes perfect sense by the way. I don't know how large a group that policy applies to but I can imagine that if the group is large enough that you will have to have periodical refreshers on it and that people are required to sign off (or check a box) on having followed that policy before their code is accepted into 'trunk', just to reinforce it. Same with new hires.