OSDev.org

In that document software is defined as digitial content. I don't know just how reliable this all is but it does look like there is a warranty of sorts for gratis software in the UK.

That is not current legislation, and it is not referring to what I would think of as a warranty. A warranty relates to whether a product works or not rather than whether it causes damage to other items. You would not claim under warranty if your car crashed into another one.

iansjack wrote:

In that document software is defined as digitial content. I don't know just how reliable this all is but it does look like there is a warranty of sorts for gratis software in the UK.

That is not current legislation, and it is not referring to what I would think of as a warranty. A warranty relates to whether a product works or not rather than whether it causes damage to other items. You would not claim under warranty if your car crashed into another one.

Quality and fitness for purpose is covered by paragraphs 32, 36 and 37.
https://www.gov.uk/government/uploads/s ... s-bill.pdf

Edit: https://www.gov.uk/government/uploads/s ... alysis.pdf Has the following:

Question 100 Should our proposals apply to Open Source software that is offered from a business to a consumer? (Box 35)

and the following strange answer

There was a mixed response to this question with some commenting that open source software by its very nature would contain bugs and other
faults while others thought the proposals appeared sensible.

open source software by its very nature would contain bugs and other faults ??? What software doesn't contain bugs and other faults???

If the goods are not fit for purpose the contract would be non-valid and the consumer would have the right to reject the goods and have a refund of their payment. As a supplier of free software that would seem fair to me.

bwat wrote:Once you start language development you quickly realise that as soon as you get functions(*) and variable scope working, you've got something good enough for pretty much anything. Everything above and beyond this is to make your life easier. Also, you simply don't need the worlds most optimising compiler to write responsive systems

I am really looking forward to reach the point of having something useful implemented. It is starting to feel doable. Thank you for your encouragement post.

releasing source code for the purpose to give user more flexibility would also need special care to make the design of program very simple, and with as much 'low coupling' as possible, for very complex system such as linux, it's really not very practical to give the whole plain source of beast like apache or mysql, as it's very unlikely an average user would really be able to modify source code in a reliable and safe manner, same for any component that is used by many other applications

it can maybe be useful for advanced developer who really know what they want to get at from the source code to tailor it to specific purpose, and is ready to spend good amount of time to understand the whole software stack involved to produce something still reliable and distributable under good condition

it can make sense with short scripted language like python or php script, or tcl, language that have rather simple synthax and short script to make a thing or another

not sure if the thread also apply to different code path that could be optimized better regarding the cpu architecture, cacheline size, instruction set, and how particular algorithm can be made more efficient on particular target, if binaries would have to contain all possible precompiled codepath for each configuration and enable certain code path at run time based on detection, it can be also useful for advanced 3D rendering, it can be made with even little impact on performance at run time if everything is preconfigured in setup or at launch time in a way that the program doesn't have to do any test based on the configuration at runtime, and in anycase it would need to have many code path distributed in the binary that would never be used on a particular configuration

it can be specially daunting for advanced 3D rendering because there can be many different way to program advanced effect that can make drastic performance/quality increase if using the feature present on the architecture, but would need to use very different approach to program them if the feature is not present, and most likely the binary would have to contain all the different version of how to make the effect and use the one that is the most efficient for the particular configuration, and it can get very complex if there a rich interactive world with tons of effects and complex scene hierarchy, and sometime it can be best to let user choose what effect they want enabled or not manually, even if the implementation can be very slow, but it can be done without having to recompile everything either, but even the kind of scripting that can be used to build video games scene can be rather complex and hard to modify anyway without in depth knowledge of the game engine and of 3D rendering in general, now lot of game allow for 'moding' , and give scene/level editor with it that can already allow to change pretty much anything that one would want to change without having to release the source code

the ideal for me would have to make most of the base block of software released in binary, and having a comprehensive script language to then load up and configure all the component for the particular use, and having most things done with simple script that are easy to understand and modify without too much problem, but not release the whole thing as raw source code, unless the code source is really very well organized for that key feature that could be useful to modify or tailor would be easy to spot and modify without involving too much dependence chain, or having a very well made graphic interface to manage plugins/packages and configuration that are being installed and used

the security aspect i think it's a bit moot, because it is also possible to hide some unwanted feature in source code, and binaries can also be monitored for suspicious activity, unless you really want to review in depth thousand and thousand of lines of code, overall design, potential flaw or security issue in any software you run, source code is not that useful, it can be useful for learning, or education purpose, but i doubt it's really that useful in most case either for security or tailoring purpose, and anyway it's still in the developer responsability to distribute software that serve a useful purpose and is adapted best to user/customers needs, and document all function that can be relevant , rather than give the full source code to have user tailor it themselves to their need instead of having 'ready to go' software that meet what the user need the best without they have to tweak the source code themselves to meet their need

On the contrary, it is very practical to provide source code for Apache and MySQL (and not just because of licensing considerations). Many times, over the years, I have used source of both of these programs to build versions for my requirements (the last time was yesterday when I built a FreeBSD version of Apache 2.4 for my Raspberry Pi). Many people use source code to build binaries for less ordinary systems or to fork new versions of a project. Long may it be so.

h0bby1 wrote:releasing source code for the purpose to give user more flexibility would also need special care to make the design of program very simple, and with as much 'low coupling' as possible, for very complex system such as linux, it's really not very practical to give the whole plain source of beast like apache or mysql, as it's very unlikely an average user would really be able to modify source code in a reliable and safe manner, same for any component that is used by many other applications

Reality proves you wrong.

Just check out the number of patch authors in a big project like Linux or qemu who have only contributed a handful or even just a single patch (series). There are many of them, and they probably don't know the whole kernel inside out. But they are smart enough to understand the one module they are touching to a sufficient degree so that they can provide a valid fix or new feature in that module.

I think the Raspberry Pi is a very good example of the validity of releasing source code. If we had to rely on the authors of the software to provide binaries for every niche platform these non-mainstream ones would never get off the ground. As it is, anyone can produce a version of Apache to run on whatever OS they are using on their Pi (with maybe a little hard work). If I had to wait for the Apache Foundation to release a binary of Apache to run on FreeBSD 10 on a Pi then I would still be waiting. Without source code I'd still be waiting for FreeBSD to run on such a platform let alone the userland.

Kevin wrote:

h0bby1 wrote:releasing source code for the purpose to give user more flexibility would also need special care to make the design of program very simple, and with as much 'low coupling' as possible, for very complex system such as linux, it's really not very practical to give the whole plain source of beast like apache or mysql, as it's very unlikely an average user would really be able to modify source code in a reliable and safe manner, same for any component that is used by many other applications

Reality proves you wrong.

Just check out the number of patch authors in a big project like Linux or qemu who have only contributed a handful or even just a single patch (series). There are many of them, and they probably don't know the whole kernel inside out. But they are smart enough to understand the one module they are touching to a sufficient degree so that they can provide a valid fix or new feature in that module.

yeah it can work if there is sufficiently low coupling, and that the interface is documented enough , and the program well organized, but thing that need to be seen is 'modification' is not always equal to 'improvement' , and if you follow a bit all the dev mailing list of those project, it's easy to see how sometime patch or fixes are not accepted because they fix something, but break something else, or improve a function in a particular context, but slow it in another context, it's never easy and trivial to have really productive well tested improvement on a large project without seeing the big picture

php can be interesting for this, because all php software are released in open source, and most of the time it's done in sort that you actually rarely have to read or modify the distribution source code, either most of the feature are configurable with a web interface, and feature are added using modules, and generally better to read the doc about the API and get code example of working module, rather than reading the source code of the engine or modifying it, unless you want to use some undocumented feature, or do some sort of hack, but modification to existing source code should be kept minimal, specially if they are mandatory to do some common task that the software is supposed to be doing, and that there can be large amount of testing to make sure it works well in all configuration and condition of use

iansjack wrote:I think the Raspberry Pi is a very good example of the validity of releasing source code. If we had to rely on the authors of the software to provide binaries for every niche platform these non-mainstream ones would never get off the ground. As it is, anyone can produce a version of Apache to run on whatever OS they are using on their Pi (with maybe a little hard work). If I had to wait for the Apache Foundation to release a binary of Apache to run on FreeBSD 10 on a Pi then I would still be waiting. Without source code I'd still be waiting for FreeBSD to run on such a platform let alone the userland.

it can be useful to make source available for porting , but it doesn't necessarily mean that the main form of distribution has be the source code form, specially when it's porting it to a widely distributed system, it can just be compiled once by developers , even if they are not the main project developer, and then distributed in binary form, or giving the source as it for porting purpose but still considering the binaries form as the main form of distribution, and still having the policy to give a ready to use binary to use whenever possible, rather than entirely relying on it to be compiled by end user by default, and only distributing it in source code form

it doesn't necessarily mean that the main form of distribution has be the source code form

I'm not sure that anyone would suggest that option. But you did say that:

it's really not very practical to give the whole plain source of beast like apache or mysql

which is just plain wrong. Your later arguments in that post show a lack of understanding of the purpose of providing source code.

h0bby1 wrote:yeah it can work if there is sufficiently low coupling, and that the interface is documented enough , and the program well organized, but thing that need to be seen is 'modification' is not always equal to 'improvement' , and if you follow a bit all the dev mailing list of those project, it's easy to see how sometime patch or fixes are not accepted because they fix something, but break something else, or improve a function in a particular context, but slow it in another context, it's never easy and trivial to have really productive well tested improvement on a large project without seeing the big picture

In general maintainers don't just say "this is wrong", but explain what needs to be done differently (exceptions exist). If you address the problems, you'll usually get a improved version of the patch committed. In the end, if you really try to understand and address the points the maintainer is making, it's still a productive way of getting changes in, with a high quality that is ensured by the patch review.

If you, on the other hand, try to make the changes all by yourself and not contribute them back, then you won't get the review and get to live with your broken attempt. It's your own fault then.

Operating systems is a special case here I think regardless of open source or commercial software. Many companies including Microsoft provide the full or parts of their source code so that customers can quickly adapt the OS for their particular hardware. With kernels there are many parts that needs to be customized and compiled into the kernel and boot stages for system support and only providing binaries would be really difficult and the risk would be that they would chose another vendor that offers the source code.

Development time is really important in the business and porting an OS for a new HW often leads to that in some stage the booting locks up because they have done some error or forgotten something. By having the source code they can more quickly point out where the location of the error and if they didn't have the source code they would have been almost blind and wouldn't understand what's going on.

Kevin wrote:

h0bby1 wrote:yeah it can work if there is sufficiently low coupling, and that the interface is documented enough , and the program well organized, but thing that need to be seen is 'modification' is not always equal to 'improvement' , and if you follow a bit all the dev mailing list of those project, it's easy to see how sometime patch or fixes are not accepted because they fix something, but break something else, or improve a function in a particular context, but slow it in another context, it's never easy and trivial to have really productive well tested improvement on a large project without seeing the big picture

In general maintainers don't just say "this is wrong", but explain what needs to be done differently (exceptions exist). If you address the problems, you'll usually get a improved version of the patch committed. In the end, if you really try to understand and address the points the maintainer is making, it's still a productive way of getting changes in, with a high quality that is ensured by the patch review.

If you, on the other hand, try to make the changes all by yourself and not contribute them back, then you won't get the review and get to live with your broken attempt. It's your own fault then.

from what i read from linux dev mailing list, the policy of linus torvald is to favor the making sure that already working code keep working, rather than adding support for new things that could break already working feature, or impact them negatively , or could be detrimental in configuration that already considered to works , so it still need to have an idea of the big picture, and to follow a bit development history, and policies, to be able to really make meaningful contribution , and need to be a bit involved in the global development community, and project history etc which still require more minimum time involvement that is not necessarily wanted by most people who will use the software

and in the ideal, it would still be better if fixes where not needed to be done at all by users, and if features or particular configuration can be enabled without having to download any source code at all, or then it's more a developer perspective than user perspective, users are not supposed to be able to use the software without having anything to do with source code at all, and can just download working binaries compiled directly from the developer that fix a particular things, or have a particular feature or support for a particular platform , rather than relying on either user or third party to compile it or tweak it to meet their particular need

OSwhatever wrote:Development time is really important in the business and porting an OS for a new HW often leads to that in some stage the booting locks up because they have done some error or forgotten something. By having the source code they can more quickly point out where the location of the error and if they didn't have the source code they would have been almost blind and wouldn't understand what's going on.

it can be done with a good system of logging, or cutting functions in little piece to avoid to have large/complex portion of system code executed at once from api, often i think good documentation, and good error tracking/logging/reporting can be more useful than giving source code, because reading and understanding source code also take time, and having a good meaningful error detecting/tracking is more productive than having to dig in source code to see what is going wrong