It's unfortunate that FSF director Ian Kelling doesn't see it the same way, and thinks this project has little merit other than to work around the GPL license of coreutils...
Isn't that a little rich, considering a lot of GNU software itself started as a reimplementation of proprietary UNIX applications under a different license.
If you have a proprietary program, reimplementing it under a FOSS license is a good thing. If you have a copyleft program, reimplementing it under a license that allows proprietary modifications is a bad thing.
"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..."
Linux is something of a special case, as the vast majority of the users can "use it" without thinking about the implications of the GPL. Because, for example, there's a specific exception for software that uses Linux syscalls, and that glibc is licensed LGPL.
That's not true for most uses of other GPL licensed libraries and software, where the license makes your code a "derivative work".
If you're just using Linux on your own servers, or writing userland software for it, then sure, the GPL is easy to comply with. But if you distribute hardware with Linux preinstalled on it, then you do have to provide all the source code. How is this meaningfully different from basic userland tools?
Not that I'm agreeing with them, but many companies are wary of sharing their code because it opens up a path to replicate their services without paying for them. Vendors that distribute devices with Linux, though, are able to avoid that because the hardware is often still proprietary. Binary blobs still exist despite the Linux GPL license too. Even in projects that seem lauded by the "open source" community, like the Rpi.
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.
? Android is, AFAIK, completely permissively licensed except for the kernel, and KHTML/WebKit/Blink are BSD/LGPL; what would be special about them in this context?
There are some that are Linux based. F5 load balancers is a good example. I don't know what strategy they use to avoid it, but as far as I know, you can't replicate your own F5 with whatever GPL compliance code releases they do.
But, for some manufacturers, you can. Synology is a good example...see Xpenology.
Because the GPL, specifically v3 is viral. The point being made in this statement is that the requirement to give back is potentially onerous for many commercial entities, and that this hinders open sharing rather than promoting it. It's a differing point of view. Notice that, unlike the majority of pro GPL comments, it doesn't use pejoratives or appeals to emotion to make it's point.
The original statement doesn’t use pejoratives. Viral is the best way that I can describe it, I suppose insidious is better, but that too could be considered a pejorative. I’m struggling to find a word because I view it negatively.
Self-preserving is the best. Thank you. I personally don't like self-propagating, when the truth is that it's free, but with a catch. Forcing people to do the right thing, even if the intent is good, is still forcing someone to do something the don't want to, or even can't.
I like the viral word personally, I see it positively as popular. Free software is pretty popular its so popular that even non free software is turned into "free beer" free software! ;) If its free and open source, free to use (legal or not) people will use it virally, like Windows was virally pirated because it was free, and linux is virally used in servers since they don't have to pay per core to Microsoft.
Not really. It has to be possible in practise to make proprietary modifications, get them accepted into common use, somehow prevent other people just cloning them, and steal the momentum of the open source project.
If someone makes proprietary extensions to "ls", they are just going to be stuck maintaining a fork. There is no realistic threat here.
Yeah, but POSIX was just codifying the proprietary UNIX standards. UNIX got bootlegged in a era where license enforcement wasn't strict because people didn't even know what licenses where. These days UNIX would have been a strictly proprietary AT&T product, from day 1.
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.
The GNU project chose a much better license, which lended itself towards free use and further public development continuing. The Rust re-implementation uses what many - including the FSF and myself - consider to be an inferior license with respect to public interest. So it's going back a step from the direction of the GNU project.
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.
I really don't get why you're being downvote. Your explanation is perfectly rational and demonstrates a political stance. People can disagree with it but its expression is most definitely correct.
GNU coreutils are protected against a hypothetical proprietary ownership and I value that protection a lot.
The issue isn't the FSF's opinion on this matter, it's that it is incredibly childish of them to go voice that opinion on other projects' issue trackers. You don't go to someone else's house to tell them their beliefs are wrong.
Yeah stop with that, MIT/BSD/ISC is definitely more free then GNU...you know in the normal world "less restrictions = more freedom" just someone from the FSF would think otherwise.
More free for developers, not users. MIT code can be used in a closed source system a lot easier than a GPL one can. 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 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.
Being a user of BSD if feel more free too. Know why? Because i can do nearly everything with it, and i don't even need a Lawyer to read and understand the license.
That makes no sense. You can still, as a user, do whatever you want with GPL software. The GPL is long because it has to be in order to protect the user's rights; It's an actual contract between the source provider and anyone who uses it. It also doesn't require a lawyer to read. Just sit down for 10 minutes and read it yourself; It's pretty straightforward.
Even as a user, you cannot do "whatever you want" with GPL software. Specifically, you can't distribute the GPL unless you also adhere to the GPL's requirements for distribution. (It's even worse for the LGPL variant, because that imposes requirements on how the software is built in the first place.)
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.
:) it is less free in a sense that unlike MIT GNU ensures continuation of free software. for me if someone really cares about free software then choosing MIT is like being a hippy handing out flowers hoping that the world is nice
>for me if someone really cares about free software then choosing MIT is like being a hippy handing out flowers hoping that the world is nice.
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
what the FSF hopes for is that if there is enough GPL-type licensed critical software which self-perpetuates free software then free software will become by far the most dominant paradigm. in this sense it is really not hard to see why the license change in the rust rewrite of GNU coreutils is going to become the most dominant issue for FSF. screaming about technical merrits makes no sense
>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 the license change in the rust rewrite of GNU coreutils is going to become the most dominant issue for FSF
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
sure. i know hedgefunds and banks that critically relly on a lot of permissive-licensed software and develop heavily on that code base. conversely, they wouldn't touch copyleft software with a 10 ft pole
one of the other posters also mentioned CUDA's reliance on LLVM. i think that is a very good example also
take the example of nvidia and their use of llvm in nvcc[0]. if llvm used a copyleft license, nvidia would either need to invest into an effort to replace llvm (a huge undertaking), or have cuda released under a free license. given the importance of cuda in parallel data computation, as well as nvidia's monopoly in the machine learning community, i think a copyleft license would have made a world of difference
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
yeah i wasn't being very serious by saying it is "less free". but it is funny that so many people are so touchy about this
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
How can you be so certain they're not interested in knowing what the consequences of their chosen license are? By your logic, It would be childish to ring your bell and point out you have a water leak. I'm glad my neighbors don't think like that.
I think the insinuation is more that the GNU project probably was also breaking license terms in order to do the rewrites. (Not commenting on the veracity of that claim though)
I don't think anyone is accusing either project of breaking license terms. In fact, I find the GP's argument tenuous, since the Kelling says "you're making less free coreutils than their predecessors" and the GP says "that's rich, considering that the original coreutils were more free than their predecessors".
While I don't for a moment believe that they were ripping off code or otherwise violating copyright, unix source code wasn't that hard to get if you wanted it; sure, it wasn't freely available on the net, but plenty of companies, research groups, and even schools were working with it.
The FSF director, per the post you linked to, made no comments on the merit of the project. Instead, commented on the project choice of license.
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.
The issue title alludes to the project having little merit other than its non-copyleft license.
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.
To quote a famous event with the group ABBA. When they started singing they realized too late there was already a canned tuna fish company with the same name.
The story says the owner told them: "I wont make you any problems as long as you do not to plan to sell fish."
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'
I am fairly certain I saw Benny Andersson telling the story like this in a documentary many eons ago, but my ABBA fu fails me now and cant find anything to back me up.
> 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.
> ... 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.
All this stuff happened before Google come to existence. I recall a somewhat humorous conversation with a friend about an exotic Portuguese rock band. He insistent could not have existed, because he could not find anything about them via a Google search!
What become of the ABBA Seafood brand has a take on the history:
"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."
I don't understand your point about this being "before Google come to existence."
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?
it is the FSF's role to comment on software licences first, and the technical merrits second (even that is a maybe). FSF is about software ethics and in that case ian's comment is appropriate since all he asks is that at the very least license differences be acknowledged
It's not just the FSF's role to "comment" on software licenses, but also to advocate for the use of free software licenses. That involves convincing developers to use them. To go into a project and dictate to them that you don't find their work notable, while still demanding respect for your own project, isn't likely to spark good-will towards the FSF amongst developers. If I were a director at FSF, I would cringe at this kind of interaction, and lean much more towards the "honey" approach for catching flies.
> this is a rewrite of GNU coreutils, and as such FSF has every right to comment in the project
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.
>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
Looking at source code does not make everything you subsequently write a derivative work of that code.
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.
Because by rejecting work from people who've seen the leaked code, you can be sure that your project doesn't become a derived work. That doesn't imply the reverse; that if you accept code from people who've looked, your project must be derived a work.
All cows are animals, but not all animals are cows.
You would have to prove that the Rust version is substantially similar to the C version, to an extent that wouldn't happen if someone who hadn't looked at the C code had written the Rust version purely from the spec/behavior.
For example, significantly identical code flow, variable naming, or function structure would be red flags, especially if it's not the "obvious" implementation.
I'm reasonably sure that idiomatic Rust code can't really infringe C copyright. I'm not saying that it's impossible, especially as you say, regarding overall code flow or variable naming, but the languages are quite different in how they approach things.
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.
Copyright doesn't just protect the single implementation, but also any derivative works. If I take some C code and copy it (with a rewrite) into C# (or whatever), the C version's copyright still applies because mine is a derivative work. That's where the "clean room reverse engineering" idea comes from: Implementing a spec isn't infringing, so just have the person reversing and the person implementing communicate using a spec.
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.
> If I take some C code and copy it (with a rewrite) into C# (or whatever), the C version's copyright still applies because mine is a derivative work.
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 :-)
The issue title literally says the most notable thing about the project is the license. That reads to me like a clear dismissal of any technical merits; if the most important thing about your project is its license, it's not a very interesting project.
I see your point. I also think the license is the most important thing, and probably even more for someone working on a GNU project at the FSF, but the project is still very interesting in many ways.
The stance is probably not surprising, given the point of FSF. Whether you agree with them or not, the FSF has always been very clear that the most important thing about software is its license. From their point of view, a free program is always superior than a non-free one, regardless of the technical merits.
I'm just using FSF terminology when describing a FSF point of view. I myself don't agree with the FSF stance on that issue, but the point still stands - the FSF is an advocacy organization (not a tech organization) that is at its very core about promoting any free (per their definition) software as superior.
I release all my code under MIT license. Do I still have the right to enslave other people? If yes, could you please describe the details, I'd be rather interested to learn how I can force whoever uses my code to use MIT license as well? Thank you.
The point is that the people who use your software have that awkward right, which you have carefully granted them (as that is the only right removed by the GPL). This is frankly sufficiently obvious that I can only imagine you are arguing in bad faith :/. Like, I definitely have seen good-faith arguments against the GPL, but this is not one of them.
So I can't force other people myself, but I still am a (potential) accomplice in a completely different kind of "forcing other people" stuff because I didn't explicitly prohibited others from doing it. I... understand this argument, thank you.
P.S. "Carefully granted"? The words "to deal in the Software without restriction, including without limitation the rights to [rather long list of verbs]" is anything but "carefully granted", it's a blanket permission.
By taking away one freedom (the right to relicense software under other licenses or exploit the software, analogical to slavery), you grant more people more freedom (the freedom to modify and use *their* software as they please, analogical to abolishing slavery).
And yet including the additional restriction "this software may not be used to enslave people" makes the software no longer "free". It's odd how often slavery is mentioned in examples about how free copyleft software is, while the first of the so called four freedoms insists that using software to literally enslave people is a freedom that must be protected.
Maybe this should be read as "I consider the license a no-go, so any technical merits the project has are not relevant (for me)"? If you already dismiss the project because of its license, you probably wouldn't let technical merits redeem that.
since FSF is about software licence ethics they will probably find technical merrits irrelevant if the project uses a licence that is less appealing to their standards than the already existing solution. i dont see why that should raise your eyebrows
I raise my eyebrows at them deciding to voice these concerns on a project's issue tracker. Regardless of how strong their political stance is, it is ultimately none of their business what a given project they are not affiliated with chooses as its license.
https://github.com/uutils/coreutils/issues/1781
I'm curious as to what extent GNU coreutils governance is tied to the FSF these days.