Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
The FSF doesn't endorse Gentoo?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
The_Document
Apprentice
Apprentice


Joined: 03 Feb 2018
Posts: 244

PostPosted: Thu Feb 22, 2018 4:49 am    Post subject: Reply with quote

If Im not mistaken the kernel has TONS of code which isn't GPL or free licensed, not to mention closed sourced driver files which virtually EVERY distribution using a DE with X/Wayland is using. Therefore most if not all distros actually do not abide by their rules because of the closed source drivers and other things not GPL licensed.

Last edited by The_Document on Fri Feb 23, 2018 8:13 pm; edited 1 time in total
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2474

PostPosted: Thu Feb 22, 2018 5:23 am    Post subject: Reply with quote

The_Document wrote:
If Im not mistaken the kernel has TONS of code which isn't GPL or free licensed, not to mention closed sourced driver files which virtually EVERY distribution using a DE with X/Wayland is using. Therefore most if not all distros actually do not abide by their rules because of the closed source drivers and other things not GPL licensed.
Thus why most distros are not FSF approved. FSF are fanatics.

EDIT: The kernel can be "de-blobed" to remove this code. You loose a lot of functionality by doing so and FSF will not endorse anyone who allows users to choose the more functional kernel.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
The_Document
Apprentice
Apprentice


Joined: 03 Feb 2018
Posts: 244

PostPosted: Thu Feb 22, 2018 7:17 am    Post subject: Reply with quote

The Doctor wrote:
The_Document wrote:
If Im not mistaken the kernel has TONS of code which isn't GPL or free licensed, not to mention closed sourced driver files which virtually EVERY distribution using a DE with X/Wayland is using. Therefore most if not all distros actually do not abide by their rules because of the closed source drivers and other things not GPL licensed.
Thus why most distros are not FSF approved. FSF are fanatics.

EDIT: The kernel can be "de-blobed" to remove this code. You loose a lot of functionality by doing so and FSF will not endorse anyone who allows users to choose the more functional kernel.


Im surprised they went as far as to discourage blob use. Althought I still don't understand why coorperatate poeple don't just disclose the code. The only thing that I can understand is it might expose IP to people who didn't pay for it.


Last edited by The_Document on Fri Feb 23, 2018 8:13 pm; edited 1 time in total
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 5222

PostPosted: Thu Feb 22, 2018 7:24 am    Post subject: Reply with quote

Some hardware is built fully capable and artificially crippled in the microcode because it's more profitable to sell a broken high end part as a low end one than throw it out, or just do it to fill orders for low-end parts - see e.g. most Intel and nVidia chips.
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2474

PostPosted: Thu Feb 22, 2018 7:34 am    Post subject: Reply with quote

They are extremists. That means they do not accept any middle ground. This means the FSF does not only discourage blob use but require that it is not supported in any capacity by a "compliant" distro. They are basically the Microsoft or Apple of open source. They want to be the only game in town and you have to play by their rules. They are not about freedom; they are about control.

You really hit the nail on the head about why companies don't disclose code. Nvidia makes money by selling new video cards. Any card installed or reused is worth nothing to them. Being able to EOL a card is worth a lot of money. Then there is Blu-ray which is literally based on proprietary keys. Releasing it would defeat the entire purpose of the DRM and "allow" movies to be stolen.

Then there is security. If you show everyone how the UEFI is implemented then any Dennis Nedry can use that to shut down Jurrasic Park. You also have to deal with the white hats pointing out flaws in your product. If you keep it a secret then no one cares and Rexy doesn't escape.

Furthermore it is a pain in the neck to make your code available and it helps out your competitors. Two reasons not to do it.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2393

PostPosted: Thu Feb 22, 2018 3:18 pm    Post subject: Reply with quote

The_Document wrote:
If Im not mistaken the kernel has TONS of code which isn't GPL or free licensed, not to mention closed sourced driver files which virtually EVERY distribution using a DE with X/Wayland is using. Therefore most if not all distros actually do not abide by their rules because of the closed source drivers and other things not GPL licensed.


No.

Blobs on the kernel, AFAIK, are usually built as modules on a binary distro. If those modules ship on the ISO then there is a violation. It's my understanding that most binary distro installers will download the blob if directed to do so by the user, or possibly they may be required to wait until after the install to switch to closed-source drivers. That means the blob is downloaded separately and no violation happens.

The kernel is its own beast. Software relying on the kernel only needs a feature to be available, it doesn't know whether that feature is closed source or open source, and there's really no way to check from a running system AFAIK.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 41405
Location: 56N 3W

PostPosted: Thu Feb 22, 2018 5:01 pm    Post subject: Reply with quote

The_Document,

Blobs come in two sorts.

Those which run on the host system, like nvida-drivers and those that do something inside a particular device, like firmware/microcode.

The first sort link against the kernel. If they are not GPL-2 they cannot be distributed with the kernel.
If they are GPL-2, then they are not blobs by definition. You are entitled to the sources.

The second sort are often provided to save a few pennies on providing permanent storage on the device itself.
e.g. Wifi firmware. Lots of these blobs are not computer programs. Is a state machine a program?
They do not link against the kernel.
They might not have sources that most people word recognise so they could not be usefully released.
Think about CPU microcode for example. That's distributed as a blob ... but does it have any sources?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
The_Document
Apprentice
Apprentice


Joined: 03 Feb 2018
Posts: 244

PostPosted: Thu Feb 22, 2018 11:49 pm    Post subject: Reply with quote

Ant P. wrote:
Some hardware is built fully capable and artificially crippled in the microcode because it's more profitable to sell a broken high end part as a low end one than throw it out, or just do it to fill orders for low-end parts - see e.g. most Intel and nVidia chips.


I blame economies of obsolescence for this nonsense.

From the above posts I understand distributing non GPL things within the kernel is prohibited by law and also firmware blobs actually reside on userland perhaps in /lib/firmware/ I suspect those are non free blobs downloaded by operator for use with hardware.


Last edited by The_Document on Fri Feb 23, 2018 8:12 pm; edited 1 time in total
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2393

PostPosted: Fri Feb 23, 2018 1:31 am    Post subject: Reply with quote

It occurs to me that a blob which is a device driver need not be compiled against the Linux kernel or any other FOSS software. If anything, the kernel is compiled against the driver.

The kernel is, by definition, a layer between the hardware and the software running on the system, it exists in order to provide a consistent API for other packages to get at hardware without necessarily knowing what that hardware is.

The driver (blob) developer is implementing an API such that their hardware works when software uses that API.

Considering that the blob is developed FOR the Linux kernel, there is an implicit and probably explicit permission if you look at the license for the blob for it to be used in the kernel.

Firmware blobs I would think would be similar. They reside between the hardware and the kernel, or maybe rather the kernel interacts with the firmware blob.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5140
Location: The Peanut Gallery

PostPosted: Thu Mar 01, 2018 9:29 pm    Post subject: Reply with quote

1clue wrote:
The company I work for has approached Open Source projects and paid them to make additions or modifications to their libraries which benefited them and us.

In at least two of those situations, the project leaders had direct knowledge of how our apps are built. In all cases everyone involved knew we were working on closed-source apps. Nobody raised any questions.

That's not a rare occurrence in the FOSS world. In the real world, FOSS and closed-source software can cooperate pretty closely.
Sure.

Thing is you're talking about dealing with the copyright holder directly, which is essentially the same as negotiating a closed-source exception to the GPL with the copyright holder.

IOW: you're just talking about the rights of the copyright holder; not the wider implications of "unknowingly" linking to GPL code (which simply doesn't happen in reality, since linkage derives from API usage.)

Sure, we can restrict our discussion to diverging forks, or implementations of a standard interface; but that's not what you started out with.

Moving the goalposts isn't the same as winning the game.
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2393

PostPosted: Thu Mar 01, 2018 10:24 pm    Post subject: Reply with quote

steveL wrote:
1clue wrote:
The company I work for has approached Open Source projects and paid them to make additions or modifications to their libraries which benefited them and us.

In at least two of those situations, the project leaders had direct knowledge of how our apps are built. In all cases everyone involved knew we were working on closed-source apps. Nobody raised any questions.

That's not a rare occurrence in the FOSS world. In the real world, FOSS and closed-source software can cooperate pretty closely.
Sure.

Thing is you're talking about dealing with the copyright holder directly, which is essentially the same as negotiating a closed-source exception to the GPL with the copyright holder.

IOW: you're just talking about the rights of the copyright holder; not the wider implications of "unknowingly" linking to GPL code (which simply doesn't happen in reality, since linkage derives from API usage.)

Sure, we can restrict our discussion to diverging forks, or implementations of a standard interface; but that's not what you started out with.

Moving the goalposts isn't the same as winning the game.



Edits made in italics

SteveL are you seriously resurrecting this shit?

I'm not moving goal posts or particularly trying to "win the game." I'm explaining that:

  1. In the real world, FOSS and commercial software often work closely together.
  2. In the real world, commercial software companies frequently sponsor changes in FOSS software so that it not only improves the FOSS software but also solves a problem for the closed-source software.
  3. In the real world, splitting off problematic code into a separate interface and externally loadable module actually happens, and is a valid technique for improving software post-installation without having to do a full reinstall or upgrade.
  4. In some hypothetical world, someone (the original developer, or somebody else in the company, or possibly somebody outside of the company) can re-implement that interface by linking to GPL code.


I have worked for multiple for-profit companies which use FOSS software internally.
I have worked for multiple companies which link commercial non-free software to appropriately licensed FOSS code.
I have worked for companies which then re-licensed my work as FOSS.
I have worked for companies which have collaborated with owners/managers of widely used FOSS projects with the clear understanding that their work would be linked to our non-free software and that the sponsored work would stay in the FOSS project under the existing license.
I have worked for companies who paid me to work on FOSS projects and contribute directly.
I have worked for companies who sponsored FOSS projects.

You, SteveL, have implied that every real-world linkage of FOSS libraries to closed-source applications has been engineered from the start in order to circumvent the FOSS license. I know that's not true.

One company I've worked for which has done at least some of the above things listed is now past my NDA. The company name is IBM.

The GPL is in no way an 'average' license. The FSF is in no way an average free software organization. It is simply the most extreme example, and because of that it's often used as an example to explain FOSS software to laymen. Because of that fact, many laymen misunderstand the nature of FOSS, and fail to understand that many licenses are not hostile to closed-source at all.
Back to top
View user's profile Send private message
Dominique_71
Veteran
Veteran


Joined: 17 Aug 2005
Posts: 1613
Location: Switzerland (Romandie)

PostPosted: Sat Mar 03, 2018 12:04 pm    Post subject: Reply with quote

1clue wrote:
It occurs to me that a blob which is a device driver need not be compiled against the Linux kernel or any other FOSS software. If anything, the kernel is compiled against the driver.

The kernel is, by definition, a layer between the hardware and the software running on the system, it exists in order to provide a consistent API for other packages to get at hardware without necessarily knowing what that hardware is.

A firmware blob is not compiled against the kernel, it is loaded as-it into the hardware by the driver. Exactly the same occur when you make a bios update. The only difference is that a bios update is done 1 time and its effect is permanent, when a blob is gone when you power off the machine and must be reloaded during the next boot.

And what are the source of the blob? Most of the time, they (the blobs) are the source because they are machine code, code that the hardware will understand. And most of us know almost nothing about assembler languages. Also, different pieces of hardware will use different assembler languages. [Edit]And even for someone that know these assembler languages and can read the content of the blobs, a minimum of documentation about the hardware and its schematic will be needed, that because these blobs are all about what the hardware is doing and how it is doing it. We can consider these blobs are parts of the hardware.[EndEdit]

For the cpu, it is no difference between its own bios and any compiled software the OS will run on that cpu: both are software that the cpu can run because both are into the same assembler language. It also doesn't matter if these software are on a file in memory or into the silicium.

For any other hardware, it will be its own assembler language. Typically, graphic or sound cards have dsp (digital signal processor) which use a completely different set of instructions than the main cpu, and a very different hardware architecture as well. The software that set-up the motherboard at run time, and that make the motherboard to be able to load the kernel is the bios. Without the bios, the computer will just do nothing. For the other pieces of hardware, it is the blobs that make it to work. It can be into the silicium of the chip, but it also can be into a blob file and be loaded at boot time. The main advantage of using a blob file is that the manufacturer can update the firmware if needed.
_________________
[[[ To any NSA and FBI agents reading that text: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 12805

PostPosted: Sat Mar 03, 2018 4:08 pm    Post subject: Reply with quote

Dominique_71 wrote:
And what are the source of the blob? Most of the time, they (the blobs) are the source
While not impossible, good practice would suggest that this statement is wrong. The firmware blob may be the only published piece, but I seriously hope that the people paid to write the firmware are not handcoding the blob in a hex editor. Rather, they should have some tooling that handles the details of layout, symbol linkage, etc. and lets them write in something more like a hardware-specific assembly or, if they are very lucky, a C-like language.
Back to top
View user's profile Send private message
Dominique_71
Veteran
Veteran


Joined: 17 Aug 2005
Posts: 1613
Location: Switzerland (Romandie)

PostPosted: Sat Mar 03, 2018 6:51 pm    Post subject: Reply with quote

Hu wrote:
Dominique_71 wrote:
And what are the source of the blob? Most of the time, they (the blobs) are the source
While not impossible, good practice would suggest that this statement is wrong. The firmware blob may be the only published piece, but I seriously hope that the people paid to write the firmware are not handcoding the blob in a hex editor. Rather, they should have some tooling that handles the details of layout, symbol linkage, etc. and lets them write in something more like a hardware-specific assembly or, if they are very lucky, a C-like language.

It depend of the hardware and its available tools. Processors, also DSP processors, do have such assembly languages and associated compilers. Typically, 1 line of assembly will generate 1 machine code instruction, when in C 1 line of C will generate dozens of machine code instructions, if not more. That imply the main difference between the source and the machine code is that the source is human readable when the machine code is machine ready, but they are mainly the same.

For high-end devices like digital oscilloscopes, such devices can include several processors, including general use processors or DSPs, and they are driven by a real and dedicated OS. The manufacturer of these devices will generally develop a C/C++ compiler. It will be used mainly to compile the OS of the device, when the low level routines will be written in assembly. I guess it will be something similar with high-end chips for devices like cisco routers.

For low-end devices like wiifi or USB gadgets, I doubt the chip manufacturer will write a C/C++ compiler for them.
_________________
[[[ To any NSA and FBI agents reading that text: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 12805

PostPosted: Sat Mar 03, 2018 8:44 pm    Post subject: Reply with quote

Right, and even a working assembler is one step (or a few steps, depending on its support for macros, expressions, etc.) up from manual maintenance of the firmware blob. A working assembler and linker are the tooling that I referenced above.
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2393

PostPosted: Sun Mar 04, 2018 2:15 am    Post subject: Reply with quote

Yeah, there's pretty much zero chance that hardware 'in the wild' would be released without at least a working assembler and disassembler, more likely a full compiler and linker too. And yes, I mean for blobs on whatever hardware requires blobs. Edit: That doesn't mean that the assembler/disassembler/compiler/linker is open source or even available to use for a price without signing an NDA with the manufacturer.

I know exactly what blobs are, but thanks for the explanation for people who don't. Not exactly a bios, but correct in that they are at least usually gone when the power goes out.

The point of my statement above is that the GPL most likely does not apply to the blob, no matter what the license of the blob. The blob is not compiled against the kernel, it is simply something the kernel can load. If anything, the kernel is compiled against the blob.
Back to top
View user's profile Send private message
Dominique_71
Veteran
Veteran


Joined: 17 Aug 2005
Posts: 1613
Location: Switzerland (Romandie)

PostPosted: Mon Mar 05, 2018 1:57 am    Post subject: Reply with quote

1clue wrote:
The blob is not compiled against the kernel, it is simply something the kernel can load. If anything, the kernel is compiled against the blob.


The kernel can load the blob, but it is not compiled against the blob because the blob is not a compile time dependency, it is not even a linking dependency. The driver know how to send the blob to the hardware, and the hardware know what to do with the blob. That's all. Which doesn't make blobs a specific problem, that because any software can be included directly into the silicium of the hardware, and as hardwares are usually no more open source than blobs, we have the same issue with all digital hardwares: we don't know the source code, and we just have bloc schematics in the best case, so we cannot be sure of what the hardware can or cannot do.

In the beginning of the internet, a back door was found into all firewire chips. Its was 2 brands at that time, both from the US. At the same time, the CIA was using their own firewalls for critical operations like network sniffers, own firewalls made entirely by them of discrete components. Some was saying it was the CIA which asked the manufacturers to implement these back doors. So, we can have similar issues with any digital hardware.
_________________
[[[ To any NSA and FBI agents reading that text: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2474

PostPosted: Mon Mar 05, 2018 2:29 am    Post subject: Reply with quote

I think the point relevant to the discussion here is that anything that is proprietary and interacts with the kernel to make the system work is banned by FSF and an "approved" distro must not support their use.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2393

PostPosted: Mon Mar 05, 2018 2:06 pm    Post subject: Reply with quote

The Doctor wrote:
I think the point relevant to the discussion here is that anything that is proprietary and interacts with the kernel to make the system work is banned by FSF and an "approved" distro must not support their use.


Yes, and no. This thread is about the FSF and approved distros, but if you google linux kernel blobs there are a lot of posts about the legality of blobs with respect to the GPLv2. The point I've been trying to make is that those blobs are not compiled against the kernel, and therefore have no legal problem because of some linkage to GPL code.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5140
Location: The Peanut Gallery

PostPosted: Tue Mar 06, 2018 12:08 am    Post subject: Reply with quote

1clue wrote:
SteveL are you seriously resurrecting this shit?
Eh? I'm not "resurrecting" anything.
I'm wondering when you're going to provide some reasoning to back up your anti-GPL diatribe.

So far you haven't, beyond hypothetical scenarios, none of which provide any support to your stance.

From where I'm sitting, the "shit" is the crap you keep spewing about the GPL being "anti-something", along with the long hand-waving arguments about "confidential" crap no-one gives a damn about.

If you had actually provided "real-world" examples when you said you would, I might have a bit more respect for the argument you're putting.

As it is, I haven't actually heard an argument; just loads of shit, as you so succinctly put it.

Hope that makes it clear enough for you.
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2393

PostPosted: Tue Mar 06, 2018 12:50 am    Post subject: Reply with quote

steveL wrote:
1clue wrote:
SteveL are you seriously resurrecting this shit?
Eh? I'm not "resurrecting" anything.
I'm wondering when you're going to provide some reasoning to back up your anti-GPL diatribe.


Not sure I've posted any anti-GPL diatribe. I don't particularly like Richard Stallman, so I guess that means my attitude toward the GPL itself might be a little negative, but it's an existing license and I abide its terms the same way I abide the licenses of Microsoft or Apple or Oracle, or Apache, or FreeBSD. I hold the licenses on the extremes (GPL, Microsoft for example) to be a little unreasonable in that they insist the entire world play by their specific rules, but it takes all kinds to make the world go around. I consider these licenses to be unreasonable because there will never be a 100% free software world, nor will there ever be a 100% commercial software world. There is plenty of space for everyone and every licensing model. I think both RMS and whoever really runs Microsoft and their like now should get it figured out.

Scratch that, it appears that Microsoft is starting to get it figured out.

Quote:

So far you haven't, beyond hypothetical scenarios, none of which provide any support to your stance.


I've never linked commercial code to GPL code which didn't have a specific clause allowing linkage. For example, the Java license. I don't have a non-hypothetical scenario. The software I have had contact with I can't talk about.

Most of what I've talked about I learned at IBM.

Quote:

From where I'm sitting, the "shit" is the crap you keep spewing about the GPL being "anti-something", along with the long hand-waving arguments about "confidential" crap no-one gives a damn about.


You clearly don't give a damn about anything except your opinion, but most of us who have been around for awhile do actually care about licenses, contracts and abiding by them.

Quote:

If you had actually provided "real-world" examples when you said you would, I might have a bit more respect for the argument you're putting.

As it is, I haven't actually heard an argument; just loads of shit, as you so succinctly put it.

Hope that makes it clear enough for you.


As I said above and in prior posts, I don't have a real world example because I never did what we were talking about. I DID however give a realistic example of what could actually happen. I HAVE pushed problematic code into an externally loadable module, and I HAVE improved on it later. Just not using code not owned by the organization I was working for.

As has happened in many other discussions with you, I have ceased to care about your respect for anything at all, as you have lost all of my respect.

I've made my point succinctly enough several times on this thread. You can keep bashing or ignore it as you will, I'm done here.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5140
Location: The Peanut Gallery

PostPosted: Thu Mar 08, 2018 9:32 am    Post subject: Reply with quote

Yadda yadda. You keep putting words in my mouth, then you take that nonsense you've attributed to me, and "disprove" it.

You're doing it now and you did it in your previous post, that gained agreement on the idea that this argument is a load of shit:
1clue wrote:
You, SteveL, have implied that every real-world linkage of FOSS libraries to closed-source applications has been engineered from the start in order to circumvent the FOSS license. I know that's not true.
Quite how you expect anyone to take you seriously after all the hand-waving, and this type of crap dressed up as reasoning, is beyond me.

So please, by all means be "done here".
It would be a blessed relief.
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2393

PostPosted: Thu Mar 08, 2018 7:38 pm    Post subject: Reply with quote

What do you expect? I'm telling you that it's possible to do something, giving an example of a real-world scenario, and you're telling me it's bullshit.

If someone tells you about a possible choking hazard for a toy you bought for your kid do you ask for proof of it being a risk, or do you take the toy away? Or, since YOUR kid hasn't choked do you keep the toy and let him play with it?

If someone says it's possible to cause a buffer overflow and execute code as root, do you argue with them or do you install the fix? Or since nobody has attacked YOUR system do you assume it can't happen to you, and keep using the old code?

I'm not waving my hands. I'm just saying it's possible to have a previously externally loaded module, and for someone (not necessarily the original author) to have implemented that interface using FOSS code.

In what way exactly is that bullshit? Where is the hand-waving? This type of module loading happens all the time for all sorts of reasons. With examples such as ODBC and JDBC drivers it happens with various modules of various licenses. How is it so difficult to understand that it could be done on a commercial app using FOSS code linked to from inside of the module?

I'm telling you and the rest of the thread about a hypothetical scenario, and you say it's bullshit.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5140
Location: The Peanut Gallery

PostPosted: Sun Mar 11, 2018 10:58 am    Post subject: Reply with quote

It's the way you keep conflating "real-world" with "hypothetical" that is hard to accept.

So far, what I've got from your argument is that there are practical difficulties to releasing commercial software.

No offence, but this is hardly news.

And I don't see what the GPL, or any other FLOSS license, has to do with it, since they are in fact an awful lot easier to work with than proprietary licenses, each of which must be analysed in detail by Legal (or whoever gets stuck with the job. IME they come down to "you have no rights" apart from usage at one installation/for one development project, which sucks an awful lot more than FLOSS. Especially when you've just shelled out several hundred dollars for a component, and you haven't got paid yet.)

As for "accidental linkage", there's no distribution involved, and if there is then you're being a twat. ("you" meaning whoever's doing the distribution, which you've stipulated is commercial.) Learn how real build-systems work, and make reproducible builds that only link to what you allow. (After all, you're going to distribute it, and your corporate reputation is on the line, as well as its legal standing.)

With respect, I feel like I've been pulled into a misunderstanding; I only asked you to "go on then, show us some real-world examples", because I thought you knew of FLOSS projects that have been affected by this (so we'd have actual "real-world" examples to talk about.)

I don't much care that commercial software-houses need to deal with copyright, as that has always been the case since the beginning of the industry. It's par for the course, part of doing business etc.

Still not seeing why the GPL is a bad thing, or bad in any way: it is clear, not hard to work with, and allows you to make money on both sides: distribution and publishing, via selling exceptions (admittedly not as lucrative as support-contracts, which is why there's all the politicking going on.)

And ofc, it's the reason we can even have this conversation.

Honestly, patents are far more of a problem to the whole of society, not just the software industry.
Here's hoping our new Chinese overlords stick with their current IP arrangements.. as well as their tax laws. ;p
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2393

PostPosted: Mon Mar 12, 2018 4:11 pm    Post subject: Reply with quote

SteveL,

While there's much to agree with on what you're saying, and I keep trying to expand on the points, you still keep missing what I say.

So we're back to not making much progress here.

IMO we chewed all the flavor out of this discussion 3 or 4 pages back. Let's just drop it.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next
Page 7 of 9

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum