Copyrights, Licenses and Patents
on
Freedom or Power?
·
· Score: 2, Insightful
Rather than debate over the types of licences developers are allowed to choose for the software they write, we should instead look at whether it is OK to prevent developers from writing software.
As currently set up I can apply for a license [read Patent] that prevents others from using an idea. This is a much more fundamental issue that the debate over what rights a developer is willing to grant users in a software license. After all, there is nothing to prevent other software developers from producing a competing product providing we solve the patent issue.
At that point, if you do not like the fact that Eric releases some software with a proprietary license, anyone is free to create a competitive product and GPL it. Then the users can decide. Right now, with patents, creating a compatible clone can be impossible.
ACM's position is that our state of knowledge and practice in software engineering is too immature to warrant licensing. Moreover, Council felt licensing would be ineffective in providing assurances about software quality and reliability.
There was a reason that I wrote a book about Software Craftsmanship The whole idea of applying a mechanical metaphor to software development is inappropriate.
I realize that comparing software development to Engineering is common, but is it really useful? Accreditation is somewhat useful in constrained engineering domains, but for software developemnt accreditation is not really a useful goal. After all, what does an embedded systems developer need to know about PL/1?
Yes, we could make the coding stage little more than data entry (or more likely generate the code from CASE tools and models), but that would just shift the problem. Getting the requisite level of detail into the development language of choice be in C or UML requires skilled, talented practitioners. To get these, we need to consider the metaphors we use.
Software Engineering doesn't really work as a metaphor for software development because few developers really understand what an engineer does. What we need to do is find an alternate metaphor that allows us to think differently about software development.
I prefer a Software Craftsmanship metaphor. Imagine trying to get a craftsman to produce a detailed estimate for a 10+person-year project without giving them sufficient time to investigate the project. They would laugh. What do software engineers do? They plug numbers into COCOMO models and come up with an incorrect number because the requirements are not even understood. For some reason we have forgotten that creating good estimates takes time and costs money, and even then you have to validate the estimate against the performance of the project team.
Please find something better to replace the worn out Software Engineering metaphor.
Slashdot Mirror
Rather than debate over the types of licences developers are allowed to choose for the software they write, we should instead look at whether it is OK to prevent developers from writing software.
As currently set up I can apply for a license [read Patent] that prevents others from using an idea. This is a much more fundamental issue that the debate over what rights a developer is willing to grant users in a software license. After all, there is nothing to prevent other software developers from producing a competing product providing we solve the patent issue.
At that point, if you do not like the fact that Eric releases some software with a proprietary license, anyone is free to create a competitive product and GPL it. Then the users can decide. Right now, with patents, creating a compatible clone can be impossible.
ACM's position is that our state of knowledge and practice in software engineering is too immature to warrant licensing. Moreover, Council felt licensing would be ineffective in providing assurances about software quality and reliability.
There was a reason that I wrote a book about Software Craftsmanship The whole idea of applying a mechanical metaphor to software development is inappropriate.
I realize that comparing software development to Engineering is common, but is it really useful? Accreditation is somewhat useful in constrained engineering domains, but for software developemnt accreditation is not really a useful goal. After all, what does an embedded systems developer need to know about PL/1?
Yes, we could make the coding stage little more than data entry (or more likely generate the code from CASE tools and models), but that would just shift the problem. Getting the requisite level of detail into the development language of choice be in C or UML requires skilled, talented practitioners. To get these, we need to consider the metaphors we use.
Software Engineering doesn't really work as a metaphor for software development because few developers really understand what an engineer does. What we need to do is find an alternate metaphor that allows us to think differently about software development.
I prefer a Software Craftsmanship metaphor. Imagine trying to get a craftsman to produce a detailed estimate for a 10+person-year project without giving them sufficient time to investigate the project. They would laugh. What do software engineers do? They plug numbers into COCOMO models and come up with an incorrect number because the requirements are not even understood. For some reason we have forgotten that creating good estimates takes time and costs money, and even then you have to validate the estimate against the performance of the project team.
Please find something better to replace the worn out Software Engineering metaphor.