https://github.com/uutils/coreutils/issues/1781
I'm curious as to what extent GNU coreutils governance is tied to the FSF these days.
Personally, most of the software I write is under a 3-BSD or MIT license - unfortunately. I wish I were in a position to write more GPL code.
GNU coreutils are protected against a hypothetical proprietary ownership and I value that protection a lot.
What counts as a "distribution"? Well, that's a contract interpretation question, and if you are not asking that question of a lawyer, then you have a fool for a client. I suspect that there's actually a lot of technical GPL violations going on, but since the open source community is not litigious in general, there's little realization of those violations and even less care that those are going on.
Personally, I am not a fan of the GPL licenses for this reason. If you are trying to use legal contracts to enforce norms, it is disingenuous to argue that you don't need lawyers to be involved. Using social contracts and pressure instead would truly allow everybody to avoid lawyers and achieve much the same goals.
Really?
https://www.gnu.org/licenses/gpl-3.0.en.html
>It's an actual contract between the source provider and anyone who uses it.
I don't want a contract, especially NOT with the FSF and their shady GPLv3 introduction...not thanks. If i want a contract i go to Oracle.
I protest this dichotomy. But even beyond the dichotomy, you're atomizing in the way you discuss people. A community or large group of users have among them both developers and resources to recruit developers to further their collective needs. When MIT/BSD-licensed software ends up being developed beyond the original freely-accessible base within commercial entities, as in:
> MIT code can be used in a closed source system a lot easier than a GPL one can.
then those communities and groups are stuck with a thorn in their side they can't remove, which warps technical fields to accommodate it and is utterly frustrating.
This has been my personal experience in more than one field. As an example it's like that with the CUDA ecosystem for GPU use, much of it is closed and hidden while employing technologies like LLVM, and likely a lot of other FOSS and free academic publications regarding effective computing. I really wish their choice was either much crappier closed-source commercial stuff, or, say, a GPL'ed LLVM, and having their drivers and user-mode toolchains open. If they were to choose the latter, than great; if they were to choose the former, than they would be at a competitive disadvantage and hopefully others (e.g. AMD) would use that to gain more traction with GPL'ed software. I'm not saying that this would _necessarily_ happen, but it might very well.
> Developers love to talk about the freedoms they have with licenses, while ignoring that the whole point of the GPL family is disregarding that in favor of the user's rights.
I think you meant MIT and BSD? Anyway, the point of the GPL and Free Software (using FSF/RMS terms) is to get enough software to have GPL-style license that it becomes unreasonable to license software any other way, with the end result being that essentially all released software will be free for use, dissemination and modification and we will be able to forget about software licenses altogether since people will stop trying to limit that and what is now the GPL would essentially be the legal default.
I like that, and i like free flovers. What i don't like are lawyers and stuff like the GPLv3, AGPL and all the licenses who try to put some political view on me.
Look it's like that. If you fork and close down a BSD/MIT code base, you loose all those devs (no free flowers from hippies anymore), instead you have to pay your own dev's, juniper can sing a song about that problem. So without any pressure, just with the logic of economy you try to stay as near as possible to the free codes base with your product (and integrate your changes), netflix can sing a song about that too.
Continuation has nothing todo with the license but with interest of developers see -> Hurd
>Continuation has nothing todo with the license but with interest of developers see -> Hurd
i think developer interest has far more to do with technical viablity of a project than license choice. besides, as in all software some projects fail, some succeed, and some are just beginning
Why is that a problem? There was already toybox (BSD), muslc (MIT), llvm (UIUC (BSD-style)). The dominant issue the FSF has is that they are no technically interested anymore but politically, and so no one need's them, no one wants them.
And listening to Stallman is really boring, the last time he was kind of self-aware was with the Religion of Emacs, since then just repetition and being rude to interviewers and trying to trick devs (Linus and the GPLv3)
BTW: I am NOT talking about the GNU project, just the FSF
simple. imagine: you value free software; you invest a lot of effort to make a really important critical piece of software; you license it under MIT; some company uses your software as a critical component, develops a lot of software on top of it, keeps the source closed, makes massive profit for itself, dominates the market and becomes a monopoly, all thanks to your critical component.
now the question is: are you pissed off? if you are not, choose MIT. if you are pissed off choose a self-perpetuating copyleft license
Like to give a real world example for that? Or is it just theory?
one of the other posters also mentioned CUDA's reliance on LLVM. i think that is a very good example also
No they would buy a license for one of the hundreds proprietary compilers, and you will eat their dogfood like you do today with cuda itself.
>or have cuda released under a free license.
Dreamer...it's nvidia....you know the ones with the "driver" that runs with the GPLv2 kernel.
i thought you said you are a hippy
anyway at this point everything becomes hypothetical. however what is certain is that copyleft licenses could make life much more difficult for monopoly companies than permissive licenses, and i am ok with that, just as i am ok with FSF being agressive about matters pertaining to software freedom. could they have a better and more effective approach, i dont know. maybe. i am not involved in any shape or form with them, but i guess that right now they have my support
FSF can be as aggressive as they want, they will not change anything...quite the opposite actually.
they exist for over 35 years now. are you sure they haven't achieved anything? :)
MIT license basically allows you to do whatever you want. however it should be well noted that if you really belive in software freedom and write your code for sake of furthering free software, choosing MIT is a naive choice since you let any derivates of your work to be closed source
"Were all Unix commands re-written in Linux?"' https://unix.stackexchange.com/questions/85189/were-all-unix...
"Is the GNU Coreutils copied from Unix?" https://unix.stackexchange.com/questions/81302/is-the-gnu-co...
Heck, POSIX stands for Portable Operating System (POS) + IX because X is a cool letter and IX because POSIX is cooler than POSIX plus, you know, UNIX.
If I implement it in Rust now, dont think I will be accused of copying IBM?
* GNU Coreutils: GPL licensed
* uutils: MIT licensed
right?
The MIT license is not only an Open Source license, but it's even a Free Software license according to the FSF itself.
So this is nitpicking of the 100th degree at this point.
If someone makes proprietary extensions to "ls", they are just going to be stuck maintaining a fork. There is no realistic threat here.
"While this may superficially look like a noble strategy, it is a condition that is typically unacceptable for commercial use of software. So in practice, it usually ends up hindering free sharing and reuse of code and ideas rather than encouraging it..."
> it is a condition that is typically unacceptable for commercial use of software
https://en.m.wikipedia.org/wiki/Viral_license#Criticism_of_t...
That's not true for most uses of other GPL licensed libraries and software, where the license makes your code a "derivative work".
I just don't think Linux is a great example to explain to a company why they should be fine with licensing their software under the GPL. It's not a good direct comparison in most cases.
Many people assume all of Linux is GPL. I say "special case" because not everyone knows the most-linked-to stuff isn't.
Depends by what metric and the definition of "commercially". I'm not sure this is the case for (physical) devices sold with software pre-installed.
I mainly see BSD licensed binaries on network appliances (routers, firewalls and other security appliances), apple hardware, automotive headunits, ...
But, for some manufacturers, you can. Synology is a good example...see Xpenology.
As anybody can also see, from the reference you provided, the way the discussion was closed, with not a hint of an effort to reply, already raises a small red light. Had the project replied along the lines of: "Its the one we choose for the project" even without a rationale attached, would turn it less into the interesting event I think it is.
I think closing the discussion like that was entirely the right choice; this project already had to deal with a prior issue from FSF-affiliated individuals complaining about the license choice. It isn't the FSF's job to go around telling people their license choice is wrong on their issue trackers. This is just a waste of everyone's time.
As the project is called Coreutils...Its not to the FSF to tell others what license to use but its reasonable to ask for a clarification the project uses a different license.
As we seem to try to save time for everybody...Do you know if the project has a public reference, with the rationale for the current choice of license? ( Note: No criticism implied concerning their current choice)
> Fred Bronson reported for Billboard that Fältskog told him in a 1988 interview that "[ABBA] had to ask permission and the factory said, 'O.K., as long as you don't make us feel ashamed for what you're doing'
This is an interesting take on the story but now have to get back to work... https://youtu.be/gC09BnFmQ30?t=118
https://books.google.com/books?id=CILUDgAAQBAJ&pg=PT297&dq=%... has:
> Stig phone up the managing director who enthusiastically approved, the only condition being that the group wouldn't discredit his company.
https://books.google.com/books?id=6lu_BgAAQBAJ&pg=PT57&dq=%2... says:
> There was just one tiny problem with formalising the anagram; ABBA was also the name of Sweden's premier brand of canned fish. Fortunately, after some brief negotiations, Stig was able to placate the fish firm and they gave ABBA, the pop group, their blessing.
https://books.google.com/books?id=-hkbqflhfKoC&pg=PT7&dq=%22...
> ... the name was also that of a Swedish company which sold canned fish; whose directors were worried lest ABBA the quartet should bring the name into disrepute, but after Stig Anderson had assured them that ABBA were aiming to publicise the name in a very positive way, the convern abated.
What become of the ABBA Seafood brand has a take on the history:
https://www.orkla.se/brands/abba/
"The Abba brand and the pop group ABBA have been the subject of some confusion over the years. During the 1970s, Abbas' switchboard usually received calls from Swedish and foreign fans who, if they were not allowed to talk to any of the group's members, could settle for a signed idol card.
Before the group Abba broke through in 1974, they actually called from the record company Polar and asked for the green light to use the name. Per Brolund, then HR manager at Abba, gave his consent to a reservation. "That the young people behaved and did not damage Abbas' good reputation."
If your memory predates Google's ~1998 search services offering, it's surely possible that you've misremembered what Benny said?
And the first reference I gave was to a copy of "Bright Lights, Dark Shadows: The Real Story of ABBA" from 2001, only a few years after Google. I don't see how Google search per se is relevant.
The Orkla link you gave is in Swedish(!). Good thing there's Google Translate. It essentially supports the point that Abba was concerned about behavior, not jocular opposition to becoming fishmongers as you suggested.
I do find it interesting that the first source I gave says "managing director" while the one you gave says "HR director". I expected "managing director" to mean CEO.
Ha! There's an ABBA fandom entry about it (because of course there is), at https://abba.fandom.com/wiki/Abba_seafood , which references the same page and translates the term to "staff manager".
Perhaps there are organizational differences between Sweden and US/UK which make direct translation difficult?
a key person from FSF commented on the project. he didnt say it is not notable
on the other hand this is a rewrite of GNU coreutils, and as such FSF has every right to comment in the project
He did say that the most notable thing about the work was the license, which effectively dismisses the technical work as not notable.
that being your interpretation and deduction. i am a bit more empirical and judge only what he actually said. moreover i am also not that much of a rust-lang fanboy, at least not to the extent that i see every rust rewrite of a c-lang code base as a technological marvel
Sure, and FSF also has every right to tell anyone who writes proprietary software that they hate their guts, if that was how they felt. My point is that this is not a particularly effective strategy for advertising the GPL to developers.
maybe the strategy sucks, maybe not. but maybe speak for yourself. i actually like their quirkiness and lack of shyness
disclaimer: I did actually make the first commit on one of these tools, but I didn't look at the source of the original C code.
For example, significantly identical code flow, variable naming, or function structure would be red flags, especially if it's not the "obvious" implementation.
Unlike for example, Java 1.5 and C# 2. I think at the time you could almost copy paste Java code into a C# and have it compile after tinkering with it for 2 minutes.
In this case, the "spec" of the coreutils would probably the man pages.
Changes to the C code to be idiomatic Rust does throw a wrench into the whole thing, and it would have to be sorted out by a court, but it's not as simple as people like to think.
As usual: IANAL
Copyright protects creative output. That means if you copy creative aspects of the code - things like the structure, naming, algorithms down to small details of the implementation - then you are creating a derivative work (this is what happens if you translate code from one language to another verbatim - not trying to be idiomatic - most of the time). If you merely read the original code to understand what it does and create an implementation that produces the same behavior, but is otherwise not substantially related to the original, then you have not copied any creative aspects and you have not created a derivative work.
"Clean room reverse engineering" (which, done properly, is extremely rare and the vast majority of open source projects related to reverse engineering do not do it to a proper standard) is a strong legal defense to show that creative aspects could not have possibly been copied. However, it is neither water-tight (the spec could've conveyed unnecessary creative aspects accidentally), nor is it required to show non-infringement. It's merely a defense; not doing clean-room RE doesn't mean you are doing anything infringing.
> Changes to the C code to be idiomatic Rust does throw a wrench into the whole thing, and it would have to be sorted out by a court, but it's not as simple as people like to think.
Practically speaking, given the significant differences between what is idiomatic in both languages, and the relative simplicity of what most coreutils actually do, there's a good chance that even a careless "translation" into idiomatic Rust would erase most creative aspects and put you well on the way to being able to claim it's not a derivative work. Effectively, the translation would involve a round-trip through an abstraction to the level of a spec, simply because what's idiomatic is so different. This is, of course, not a hard guarantee, nor would I bet the legality of my project on this aspect alone, but rather just an observation of what is likely to happen in many cases. In other words, you'd have to be really careless to end up creating a derivative work of coreutils here; the language difference works significantly in your favor.
IANAL, but I've been doing reverse engineering projects for over 15 years and my main job these days is leading an open source project to support an undocumented platform via reverse engineering. So I have a bit of experience with this matter :-)
All cows are animals, but not all animals are cows.
Not looking is a strong legal defense for whatever you wrote not being a derivative work. Looking just means you can't use that defense, it doesn't mean you actually copied code.
Given the significantly different paradigms of Rust and C, and that most coreutils don't really do that much algorithmically, it would be pretty easy to avoid accidental copying with this kind of project.