Live data from Hacker News

If it's not practical to redistribute, it's not free software in practice

lwn.net

111–120 of 139 posts

Re: If it's not practical to redistribute, it's not free software in practice

#111
post #104
post #60

Earlier quoted context omitted.

I really couldn't be happier with a Distro. It is super stable and easy to upgrade. This computer at work has been over 5 years of just sudo zypper dup after a one line command to rename the repos. The ability to install packages with https://build.opensuse.org is such a better system than ppa. For the last three years I use i3 (Tiled Window Manager) and works great on in VM at my Windows machines. Still sad to see s…

How does "build" and ppa compare to Fedora's "copr", if you know?

OpenSUSE build's best feature is you can build for other Distros. So build it for SUSE, Fedora, CentOS, or Ubuntu even Arch and it works.

Fedora(Redhat) has picked out two of OpenSUSE's best features, zypper and obs (https://opensuse.org). OBS (Open Build Service) was considered instead of re-inventing the wheel that is copr https://lists.fedoraproject.org/pipermail/devel/2013-Septemb...

Re: If it's not practical to redistribute, it's not free software in practice

#112
post #94
post #83

Earlier quoted context omitted.

The problem is that Canonical is (intentionally?) vague about what you need to do with their software to redistribute it. They have not answered requests for clarification. What do they consider trademarks, what do you need to remove? This kind of (intentional?) legal ambiguity ends up having a chilling effect.

There is no legal ambiguity. The license is a legal document. You comply with the terms of the license and trademark law. > What do they consider trademarks, what do you need to remove? They don't define trademarks, because it's a legal term that depends on the laws in your country, and not up to them to define. Canonical's Q&A is merely clarification. At the end of the day, you're subject to whatever licenses you im…

> They don't define trademarks, because it's a legal term that depends on the laws in your country, and not up to them to define.

It is up to the trademark holder to decide what they consider their trademark to be. That's why when defending a trademark you have to say "so-and-so is a registered trademark of so-and-so", and that's why when people defend trademarks they use a trademark symbol. People defending their trademark also have to decide what is or is not an acceptable use of their trademark. Furthermore, trademarks that are not defended are lost.

Copyright licenses also are completely irrelevant as regards to trademarks. These are different sets of laws. What is in effect here is what Canonical confusingly calls its "intellectual property policy", which is in effect only about trademarks, not any other law that people confusingly call "intellectual property".

Re: If it's not practical to redistribute, it's not free software in practice

#113

Earlier quoted context omitted.

Assuming binary-only distribution, you already have this problem for a multitude of distros. If you're employing such a proprietary model, you'll obviously have problems you'll need to overcome. Assuming source distribution, I do not see any special effort required. This is a protectionist, anti-choice argument.

> Assuming source distribution, I do not see any special effort required. No special effort to support Mir/Unity/upstart? Other Ubuntu-only APIs, standards, UX, Kernel/Library versions not employed by other distributions, …? (Upstart was killed when even Canonical realized it was impossible to demand of everyone else to support their special snowflake init system.)

For the record, most projects do not supply configurations for every possible userspace plumbing, but either none or only select ones. Upstart jobs would be written by the distribution maintainer or user. Mir hasn't even rolled out yet, and IIRC it has X11 compatibility anyway. Why would you need special effort to support Unity other than a .desktop file, which is interchangeable with GNOME (Unity reuses GNOME under the hood)? Kernel and libraries do not require special effort at all to support when distributing source.

It's also funny how people routinely bitch about Upstart when it predated systemd.

Re: If it's not practical to redistribute, it's not free software in practice

#114
post #59
post #32

Earlier quoted context omitted.

Sounds like Redhat's systemd: "if you want to run it, you have to replace most everything."

Init systems are, by nature, highly invasive. Systemd's requirements don't fundamentally differ from modern sysvinit derivatives or upstart or whatnot in that regard. Unity, on the other hand, is a bloody desktop environment. You can install dozens of those (or could, if there were that many) in parallel without any modifications… with the sole exception of Unity.

Systemd replaces a lot more of the system than other init systems - for example, it has it's own journal format, and also has it's own time tools. Other init systems don't. You can't just drop systemd in and get by just with learning it's config language - you have to change the way you do a number of other things, too.

But then again, you don't think that there are dozens of desktop environments. Arch supports nearly two dozen by itself (https://wiki.archlinux.org/index.php/Desktop_environment), and that list doesn't include things like fvwm, or tiling desktops like xmonad or i3.

Edit: To clarify, the point being made is "if you have to modify a bunch of stuff, then the software is not free". Systemd requires a lot of modifications - it's not a 'drop in' replacement. Using the same argument, systemd is 'not free'. It doesn't matter how 'invasive' the component is, the argument is about modification effort.

I think the argument is wrong - Canonical patches a lot of things for Unity, but those patches are publicly available and are not done to obfuscate the code. Basically the argument here is that no-one should be allowed to publish free software if it can't be simply dropped into $RANDOM_YAHOO's system.

Re: If it's not practical to redistribute, it's not free software in practice

#115
post #97

Earlier quoted context omitted.

> This doesn't change the fact that you can use their code as you wish. But I can't use the code as I wish. If I want to make a modification to it and then redistribute it, I then have to go through the entire codebase and remove trademarks. I wish to do the first step without doing the second step, and I can't.

This is the process used to generate new version of CentOS from RHEL.

The amount of work necessary to generate new versions of CentOS is not feasible for individuals.

Re: If it's not practical to redistribute, it's not free software in practice

#116
I see a value in this approach.

I don't known your experience, but as soon you have a well known OpenSource project with binary distribution, you are going to see it available in a lot of scam download sites.

In fact, the OpenSource licenses allow it, and the author is going to have a hard time taking them down. In this regard, OpenSource licenses are too permissive, and are doing a disservice in being too easily abused.

Imposing additional restrictions to binaries, seems a good approach to have legal arguments to prevent that in the first place.

Re: If it's not practical to redistribute, it's not free software in practice

#117

I see a value in this approach. I don't known your experience, but as soon you have a well known OpenSource project with binary distribution, you are going to see it available in a lot of scam download sites. In fact, the OpenSource licenses allow it, and the author is going to have a hard time taking them down. In this regard, OpenSource licenses are too permissive, and are doing a disservice in being too easily abu…

All you need to handle that is a trademark. You don't need to impose restrictions on binaries other than those that trademark law already imposes.

Re: If it's not practical to redistribute, it's not free software in practice

#118
post #92

Earlier quoted context omitted.

You can distribute unmodified versions of Ubuntu or the binaries, you just can't call Ubuntu + your binaries "Ubuntu", or call your distribution + Ubuntu binaries "Ubuntu". It's basically just clarification concerning the GPL and trademark law. Software licenses are legal documents, they're binding as far as the interpretation of the laws of the jurisdiction.

> You can distribute unmodified versions of Ubuntu or the binaries, you just can't call Ubuntu + your binaries "Ubuntu", or call your distribution + Ubuntu binaries "Ubuntu". That's not what Canonical's policy says. What you described sounds like a perfectly sensible policy. However, Canonical's policy instead says you must remove all of Canonical's trademarks. Canonical's policy also does not limit itself to functio…

> However, Canonical's policy instead says you must remove all of Canonical's trademarks.

Which is perfectly acceptable. Red Hat and SUSE apply similar restrictions, hence why CentOS is a thing...

Re: If it's not practical to redistribute, it's not free software in practice

#119
post #91

Earlier quoted context omitted.

> LP's testimony starkly contrasts with Kay and SJR. No it doesn't. There is no reason that "conceptually, it was the wrong design" has to contradict with "they had different ideas to me, and couldn't contribute them because of the CLA" and "it could have quite easily evolved into what systemd looks like today, with an active community working on it." It is quite easy to read those statements as being in agreement --…

Except for the whole part about Lennart's project already having a prior non-public existence. Discussing historical counterfactuals like this based on limited public testimony is a difficult matter, but my input here is that the ultimate breadth of changes envisioned by the systemd developers would have triggered a split anyway. SJR's comments concern systemd-the-PID1.

> Except for the whole part about Lennart's project already having a prior non-public existence.

Is there any reason, any at all, that you've provided to think that Lennart wouldn't have abandoned that project to contribute to Upstart, if the CLA issue had been able to be overcome? Because the testimony of people who would actually know this indicates that he would have. I mean, I'm happy to drop this argument if you find it a "difficult matter," but it seemed to matter to you enough to bring it up in the first place, and you seem to be focusing on trivialities that you think support your point rather than some pretty unambiguous statements from people who would know (and it seems hard to accuse SJR of some sort of pro-Red Hat bias ehre).

Post reply on HN