2 ms·
Licenses should be evaluated in context. 1. For anything internal, they already had free work from GPL. They can even modify it - the for them unfortunate side
by arghwhat 3y ago
Licenses should be evaluated in context.
1. For anything internal, they already had free work from GPL. They can even modify it - the for them unfortunate side-effects only apply if they need to distribute it to outsiders, as only those receiving a copy need access to the source.
2. For anything external in this particular example, they can either use GPL projects unmodified (no effort required on their part in that case), or they could get all these bits from BSD with a BSD license already and do whatever they want.
GPL - and more importantly, AGPL - is definitely important for full-fledged products that can be monetized and abused, with improvements never made available. Note that no common license require any degree of upstream collaboration.
coreutils on the other hand isn't such a full product. This project hardly enables anything new - they could just use a BSD userspace or other portable coreutils clone - but if I end up exposed to some included coreutils in a proprietary product, I'd much rather have that they could easily include a proper one. The same logic applies to many other things too.
- toyg 3y ago> GPL - and more importantly, AGPL - is definitely important for full-fledged products that can be monetized and abused With GPL3, that covers pretty much everything from laptops to online databases. Which is why Apple, for example, has worked very hard to rip any GPL code out of their systems. > This project hardly enables anything new - they could just use a BSD userspace or other portable coreutils clone Yes, but it is a competitive disadvantage to ship something less familiar. Again, the Apple example shows most developers would run to replace the shipped utilities with GNU versions instead, which was good for the ecosystem as a whole - less so for Apple, of course, which lost some control on target toolchains and suffered a competitive disadvantage towards Linux machines (minor, sure, but every little helps). It's sad that this particular project is headed by Mozilla people, who are supposed to care about the health of the opensource community as a whole, and still does the wrong thing - probably out of a (vaguely desperate) hunt for widespread adoption of Rust, at the expense of the overall free-software community.
- sylvestre 3y agoThis project isn't related to Mozilla at all.