Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I thinking of a good opensource licence to choose for my project. I got a few requirements but I have a hard time choosing a license because a read some different things about some of them.
The project is a Java project that can calculate decompression schemes for scuba diving. I want this project to be opensource because a wrong decompression scheme can be lethal. Therefore feedback on the algorithms and source code is important for me. I don't make my own algorithms but I use various opensource algorithms that I implement in 1 Java library.
My requirements are:
I and other contributers to the project don't want to be responsible for wrong calculated decompression schemes due to bugs in the code, miss use of the code or any other way that resulted in wrong decompression schemes.
The library should be able to use on a website I plan to build without the need to publish the server side code of the website.
It's not allowed to make any profit of the library itself. Even not even the library is changed and republished. However I don't mind if people sell programs the make use of the library.
If people change the code than they should be forced to re publish the library with an opensource licence (Optional requirement).
I hope someone with a bit more knowledge of licenses can help me out.
Well, there are a couple of things I notice right off the bat here.
First off, you talk about needing to be able to do things with your own code. If you are the copyright holder, you can do pretty much anything you damn well please with your own code. The license is for other people, not for you.
Also, disclaiming any responsibility for what the code may do to other folks is pretty much boilerplate with any license.
That being said, I've found in my work I can get by with the use of only 3 different kinds of licenses, depending on my needs.
Full on GPL
Benifits:
Nobody can ever take any of the code propreitary (without coming to me for a relicense). They can still use it and charge people, but since they'd have to license the result GPL, that wouldn't be particularly practical. The reason is that any of their users could give away all the free copies they like.
The sources are avilable for anybody to contribute to, so I might not have to find and fix every damn bug and write every new feature myself.
Drawbacks:
None of the code is usable in a properitary app
I use this typically for stand-alone apps.
GPL with linking exceptions
This is basically what it says; GPL with an exception that meerly linking against (or #including) the code does not render the entire result GPL. Here's an example from the Classpath library.
Benifits:
Nobody can ever take the code itself proprietary.
The code can be used in a proprietary product without making the whole closed-source product open-source. Only the GPL-licensed stuff has to stay GPL.
Drawbacks:
The facility itself can never be expanded into a proprietary facility. Generally a plus in my book, but it does deter some people from using it.
I use this typically for helper facilities and API's .
Public Domain
This means anyone can do anything they like with this code, including making a tiny tweak, slapping their own copyright on it and calling it theirs.
Benifits:
Anybody can feel free to use it however they like.
Drawbacks:
No protection from the code getting "stolen" by a proprietary software seller.
Impossible to do in may jurisdictions (a permissive BSD I understand can be a good alternative there).
I use this when I'm publishing something incomplete that I really want someone else to take over, or when publishing something that is supposed to be a reference implementation for a standard library.
Now in a case like yours what I would do is either:
Use GPL with the linking exceptions for the library. That will allow everyone (including you) to use the library in a proprietary application, but the library itself will always stay Free.
Use GPL, and insist that contributions from others have their copyrights assigned back to you. This allows you full rights to make your own proprietary app using other people's contributions, and doesn't allow anyone else (including those contributors) that same right. Kinda cheesy in my book, and will probably discourage outside contributors. However, only the most successful Free Software projects get any outside contributors anyway. So it may not be that much of a loss.
It came to my attention recently that Bruce Perens (one of the founders of OSI) actually made a blog post a year earlier that made the exact same point. He picked two different licenses than I did for the latter two though. He picked LGPL for the intermediate license, which I think is a mistake on his part. However, he picked the Apache License 2.0 for the latter license, and I think he may have a point on that one. The benefit you get from using Apache over straight Public Domain is that you are better protected from patent lawsuits. That isn't something poor little me really has to worry about, but your company is a different matter entirely.
This impossible. You say you want an open source license that prohibits making money. However, one of the key requirements for being an open source license is not making any restrictions with respect to commercialization.
Ergo, a license like you describe it cannot possibly exist.
And here the standard answer: StackOverflow is a site for programming questions. We are programmers. Your question is a legal question. This means that all answers (including mine) will be, by definition, crap, since we don't know WTF we're talking about.
For legal questions, ask a lawyer.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have recently started working on some open source project which I found relevant to my interests.
During this initiation period I came across some terminologies/stuff that I am not acquainted with, like configure, tool chain, binutils, etc. which I agree depends upon the type of project you are working on.
Now my question is, are there some bare requirements a developer should know before starting to work on the project?
Any help/reference will be greatly appreciated.
EDIT:
I have seen the GNU configure and build system in most of the projects I have seen.
If someone bothers about it "The GNU configure and build system" is a good place to start.
If it's a pre-existing one, you'll need to read their development docs (if any), learn how to use their version control system, and have the requisite tools for building the code and running it.
If you have all that, and the knowledge of the code/language, then you just need enthusiasm and some spare time :)
I wouldn't define them as bare requirements in the sense that it appears you are looking for. If you're a programmer you already have (hopefully!) the self-learning and problem solving characteristics that probably led you to be a programmer at first.
You'll never really know 'everything', and will likely learn something new everywhere you go. Heck, I got my current job never even hearing the words "Model-View-Controller", but picked up the concept in no time.
Your examples, toolchain and binutils, are not complex concepts and a simple wiki article should suffice.
I'd suggest downloading all the source code and making sure you can build it yourself as a first step.
Try and make sure you are familiar with the overall design and documentation before attempting to make any changes to ensure you don't inadvertently break anything on your first change!
The terminologies being used will probably depend on the technologies being used, for example an open source project written in C++ and running on Linux, will likely be very different to a C#/.NET application build to run on Windows.
It depends on how much involvement you will get into. If you just want to contribute with a feature, just get the tools to build the project, an editor to change the file and enough doc reading to find injection point for your feature. If you can find someone to help you getting started it will be fairly easy.
If you are to be committed to the project I recommend learning build tools, project history and aims. Also how the current authors try to solve the problems, their perspective on the project will help.
I would say being able to understand all of the architecture, tools and technology for whatever project you're working on is a must.
However, you then tried to make this a generic question that applied to any open source project. You kind of answered that for yourself didn't you?
which I agree depends upon the type of
project you are working on
I would think that depends entirely upon the project. Most well set up software projects will specify:
What language(s) they're written in
What developer environments (if any) they're set up for
What tools you need to build/compile/run the project
Test data with which to test the software
What are you working on? Are you sure they don't provide any of this information?
It depends on what you qualify as "work" on the project.
Most of the answers here suggest that you're coding (and your question hinted in that direction), but there are things that you can do to contribute to projects -- like testing and documentation -- that can be done without knowledge of how the program's written.
Now, for the coding aspect of it -- if it's a smaller project, I'd try to figure out what the other contributor's motivation and grand plans/goals for the project are. As with any team, coming in and trying to take things in a completely different direction than the others are planning, even if you have good intentions, can cause all sorts of problems.
(and then there's the technical advice that everyone else said ... source control, build system, project architecture, toolkits used, etc.)
It depends, as you say, on the project.
You'll have to know how to work in the language, you'll have to be familiar with the source code control system they use (usually subversion). You'll have to be able to build (usually Ant, often Maven).
I'm looking for both an explanation of why and when you would use each system and what features differentiate a bug vs. issue tracking application.
Issue tracking systems usually integrate more with customers and customer issues. An issue could be "help me install this" or "How do I get the fubar into the flim flam." They could even be something like "I need an evalutation key for your software".
Bug tracking systems help you keep track of wrong or missing things from the program.
When looking at web systems, there is usually a big difference in focus, either helping customers or tracking problems with your software.
The difference could be clearer from the following example.
Suppose you had a production issue today that affected 5 customers, but was caused by a single software defect.
In your issue-tracking system, you opened 5 tickets and started tracking what each customer reported, what was communicated to them, when the software patch was applied, etc. You can track that kind of stuff separately for each customer.
In your bug-tracking system, you made 1 entry for the software defect started tracking things like steps to reproduce, code changes, etc.
Customer issues can be closed whenever they're remedied to the customer's satisfaction and that may or may not involve fixing the software. The bug can be closed when it's fixed and retested.
Two systems, outward- and inward-facing, tracking two different kinds of things, each with its own life cycle.
Bug tracking systems like Trac are designed to have one ticket for each problem intrinsic to the program, so a ticket is closed by modifying the program.
Customer support ticket systems like IssueTrackerProduct are designed to have one ticket for each customer experiencing a situation, so a ticket is closed by working out the situation for that customer (possibly by modifying the program).
For examples of each, see Wikipedia's Comparison of issue tracking systems
A bug is a subclass of issue. All bugs are issues, but not all issues are bugs.
Typically a bug is a defect in the codebase. This is different from an incomplete/yet-to-be implemented feature, or something more hard to pin down like a developer putting in a ticket to deal with a piece technical debt, or a concern with the UI. All of these are 'issues' semantically speaking.
A generic issue, when not falling under those other categories, is more often than not a representation of something reported by the end-user. In most systems, this reported issue is handled as a bug-report in itself. I'd venture to say this is a mistake.
The tricky part is that sometimes multiple issues may be related to other issues. It could be concerning the same bug, multiple bugs, or actually be a feature request. That is to say, there can be a many-to-many relationship between issues.
Why does the distinction matter? Well, there is a natural tree internally - Resolving one issue can indirectly complete (or contribute to completing) a million other issues. It also makes a difference in how an issue is resolved. Defects themselves may be resolved with a code change that fixes it, or makes it irrelevant. If it's a user complaint, it may be resolved by sending them a work around, and then left to be followed up on when the original defect is solved.
Features that work better at representing and working with these nuances in a useful way is really what to look for in a ticket tracking system.
At some point, you are talking about processes and methodologies more than actual ticketing systems, and the actual names of things should start to become irrelevant. Mainstream and enterprise oriented solutions tend to run on a popular systems like ITIL, but you can get away with adhoc stuff provided everyone on the team has a good understanding of customer service needs. I personally see it as a waterfall (ITIL) vs agile (DevOps) situation.
it's just semantics. A bug is a problem, an issue is something to do. They are otherwise much the same.
Its' a fuzzy line at best. Issue tracking system would probably be considered the more general of the two. In that all bug tracking systems are issue tracking systems, but not necessarily the opposite.
From our Friend Wikipedia
A bug tracking system is a software
application that is designed to help
quality assurance and programmers keep
track of reported software bugs in
their work. It may be regarded as a
sort of issue tracking system.
A bug is found in code
An issue can be found anywhere, in the processes, in hardware, in people.
It depends which development process you're adopting as to what the definitions mean.
I believe that a bug is something that can be fixed in code, while an issue is more of a problem with usability.
For example, a login form. A bug in the login form would be the form redirecting incorrectly after the login completes. While an issue would be that the overall login process is too slow, or there is no option to email a forgotten password.
This isn't really a complete answer to your question, but I've had similar questions come up with dealing with customers. I think at the highest level, a bug tracking system seems usually to be more developer focused. That is, developers are trying to track problems in the code. A function isn't returning the right value, more validation should be done, etc.
A good example of a system that integrates nicely with code is Trac.
Issue tracking systems seem to be more customer-centric. For example, being able to have a customer say "When I click on 'OK" I get an error". It may be user training, it may be a feature, or it may in fact be a bug.
So in many of the projects that I've worked on we keep these distinct. We have a high-level issue tracking system that may or may not result in an actual bug being created in the bug tracking system. However, many many bugs are tracked internally without any "issues" being created in the issue tracking system.
The problem that I see between these two is that it's really not very easy for inexperienced users to enter tickets into something like Trac because they get confused by the technical lingo. However, a high-level issue tracking system does not integrate tightly with code so it's useless to the developers.
Anyway... my $0.02.
Bugs: flaws anywhere within the process (application, database, reporting, etc.) that will prevent 100% of desired functionality from occurring. Also known and referred to as defects.
Issues: potentially caused by a bug or bugs, an issue is a report of some form of loss of functionality in the system that would be tied to a user. These are also referred to as help desk tickets in some organizations.
WIKIPEDIA LINKS
- Software Bug
- Issue Tracking
To answer this question it requires context and from the looks of it Alan's answer was to your context.
In the world of software testing, one of the distinctions we make between an issue and a bug are: bugs are anything that threatens the value of the product while issues are anything that threatens of the value of testing (or the value of the project and in particular the value of testing). Rapid Software testing teaches us that.
In my experience the tracking systems allow you to make whatever distinction you want between the two. How you use a particular tracking system is up to you.
I don't think there is a definitive answer, but I usually just think of Issue Tracking as merely a more generic term that corresponds to more than just "bugs". To only use the term "Bug Tracking" is kind of a pigeon-hole, which is associated with defects in software.
An issue tracker doesn't have to be tied to software though, and even BugZilla doesn't track only bugs, but also new enhancement / feature requests, votes, etc. In that way, I think of an "issue" as just a single item of interest that someone wants to get "done."
Lately there has also been a rise in Work Item Tracking (in e.g. Visual Studio and IBM/Rational Jazz), which is more lower level than "issues"--wherein an issue could be seen as requiring some N number of smaller work items to complete. At a higher level, you might also see something akin to a Milestone in BugZilla.
Bugs are specific to software developers. Issues are more general and can include all team member's progress on a project, including the graphic designers, system administrators, company executives, etc.
An issue tracker speaks in terms of things to do and can categorize an item as a bug if needed.
It is mostly just silly words, but I use an "issue tracker" as I work with many people who are not programmers, and we need to speak a common language by having a common productivity tool that makes us aware of what each other is doing.
You can use a bug tracker but it will just confuse non developers, especially if they have to think of their tasks as being a bug.
I would say it is also nice to draw a difference between a bug and an issue for programmers, as bugs are usually problems with existing code, and issues can be new feature requests.
Well... there is not difference besides the fact, that an issue is more than just a bug. It can be a task, a new feature, or simply an improvement. A bug is mostly seen as incorrect system behavior, while an issue has a broader definition. beyond just "it does not work"...
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
When trying to link some well established tools to my company's active directory, I hit a roadblock. I was told that:
"Sorry, I cannot trust our domain admin password to [F/OSS] software...".
This question deals specifically with how to convince IT that F/OSS software isn't (automatically) less trustworthy than any other software just because it's free/oss.
I'm doing fine with adopting OSS software (I'm a linux ninja at heart) so to put it another way: How can I promote the acceptance of OSS at my company?
The technical issue of tying into AD without an admin account is for another post.
EDIT:
I got some clarification on these issues. This really has little to do with the active directory and all to do with trust of F/OSS in general. So I think my original bolded questions are still valid, just ignore the part about the "admin password".
Any IT person worth their salt will be well aware of the benefits of open source software.
The answer that has been given sounds to me like a palm off answer, some possibilities of why they don't want to implement it could be:
Possible lack of enterprise level support for that specific software open source software
Not wanting non-IT department employees to be modifying the active directory (you)
The software you have found doesn't have the industry recognition that other similar products have
There is no perceived benefit for the IT department for the work it would require them to do (both in the initial setup and ongoing maintenance)
I work as a sysadmin. From my perspective this question isn't about trusting Open Source software specifically. Your IT person mentioned a specific case saying he didn't trust it with the domain admin username and password. I think he may be concerned with the software storing that username and password. If that is in fact how it works I would deny the request for open source or commercial software. No properly setup system should need to store the domain admin username and password, possibly an account with lower credentials, or depending on the tool if it is interactive have it setup to ask for credentials at runtime and authentcate against the domain.
Bottom line you need to work with IT to come to a better understanding of your and their needs. Things need not always be only a yes or no issue.
I would try it this way:
Why would open-source software be less trustworthy than it's close-sourced equivalent? If anything, the transparency of its code would require that it be even more trustworthy, in terms of private data storage such as passwords, since any attempt to subvert it would be discoverable by examining the source code.
This, of course, is only valid if the company compiles the source themselves, and does not trust a binary distribution.
Ask them if they have read the license since that is what they object too. Ask them specifically what in the license is an issue for them. If what they are really resisting is Open Source Software, then that is a separate issue from resisting the GPL.
Why not run as a non domain admin? I can understand why they don't want to give a domain admin password to any software. Especially if there is only one "Domain Admin" account.
How about you determine exactly the permissions needed to run the software and request a new account with only those permissions. You could convice them to put this in a different OU, with additional auditing. If the software provides value, you are creating a process for them to "audit" and decide to trust OSS.
Identify exactly what he cannot trust about F/OSS software and then you can tailor your explanation to address his concerns.
Is it concern about backdoors being coded in?
Is it concern about code quality that leads to security risks?
Is it concern about how soon security risks will be fixed?
"how to convince IT that F/OSS software isn't (automatically) less trustworthy than any other software just because it's free/oss."
"How can I promote the acceptance of OSS at my company?"
You can't.
All you can do is the following.
Find the F/OSS they currently use. This can be hard. In some cases, it's trivial because many folks use Apache and Java without thinking about it.
Ask how is what you're going to use different than what they're already using?
That will make the case for exactly one new piece of F/OSS. Or, they'll go crazy and banish stuff they've been using.
You can't make a general understanding happen. You can only make the case one specific detailed case at a time until someone else starts to piece the big picture together on their own.
Sometimes they are not, sometimes they are. You need evidence to backup your thoughts.
CVE numbers don't lie. Go to http://cve.mitre.org/ , http://www.securityfocus.com/bid/, http://www.secunia.com and compare commercial and OSS version of the same line of products that you'd choose.
See which one is better sometimes it's the fact that the OSS product is really rubbish such as PHPNuke but sometimes it's darn good when it comes to security such as qmail.
Also don't forget you need to choose a OSS solution which got a good community otherwise you might see the project is dead after a year. this is possible in the commercial world, but let's face it less likely
I would put the onus on IT to prove their case. Simply ask "why not?", or possibly "what evidence do you have that this is any less secure than non-GPL software?". If they attempt to give some explanation, you can take some of the other suggestions to explain their misconceptions to them. If they just stubbornly stand their ground, they are standing in the way of you doing your job - and for no good reason. Gently explain to them how you have found incredible value (ie free) software that adds value to the company, and that you're sure the higher levels of management would want you to take advantage of it. Hopefully this will remind them they have no evidence. If even this fails and it's important, you could then take it to higher levels of management, but proceed with caution as it's a sure fire way to make enemies.
What tools do you want to use? Make the business case about how much time/$$ will be saved by using these tools. Give examples of other, highly-successful companies (Google comes to mind) that use these tools.
First and most importantly, make sure these decisions by IT are being recorded somewhere. Email or whatever. If you can't do your job effectively because of them, make sure you have enough documentation to redirect the blame where it belongs.
Look beyond IT. Your sysadmin may be following rules set down somewhere else in the company, typically a legal department. If that's the case, you may have a company lawyer who doesn't know about software or FOSS reacting with a corporate lawyer's typical reaction to the unknown - forbid it. After you've demonstrated cost and security benefits, you may need to ask the company to reach out to a legal expert in the area of FOSS.
You're talking about Windows admins. Just point out how MSFT has handled recent security issues (like the recent IE holes that have mainstream media telling people to use alternate browsers) and ask how OSS can be any worse.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm a software engineer, not a lawyer, and my university doesn't offer any courses geared toward licensing software. In fact, their law-related courses are lacking (but slowly growing in number). Where can I go to learn about open-source licenses and how to choose them?
There are lots described here:
http://www.gnu.org/licenses/license-list.html#SoftwareLicenses
The decision of which one to use can be political, but should ultimately be determined by your plans/desires for the software. If you want to ensure it is always free then choose GPL or another "Copyleft" license. If you don't mind some commercial use, choose another one that's compatible with that.
I almost always end up usign MIT or BSD (they're equivalent), since it
Is the most liberal license out there. It just says you're not responsible for any kind of trouble, and optionally forces people to include a copyright notice of your original work in derivatives.
It allows closed source derivatives, which is something I see as a good thing: companies sometimes don't have the possibility to do their work under the GPL (they may themselves use products or components from a third party with restricted licenses).
That, and the GNU/GPL bunch are generally extremists when you encounter them in the wild.
This can create endless discussion, but there is one tenet I would hold to whenever deciding what license to use: DON'T CREATE A NEW ONE!!
No matter how persuasive your legal guy's arguments that, because no current license exactly meets your project's unique needs, you should write your own, or even just "slightly modify" an existing one, treat him like a programmer coming to you arguing that he just HAS to use a GOTO statement because nothing else in the language will work.
Other advice:
Choose one which has major usage (see http://freshmeat.net/stats/#license)
See David A. Wheeler's discussion of why to choose a license compatible with the GPL - http://www.dwheeler.com/essays/gpl-compatible.html.
If you are looking for information regarding free and open source licenses a useful comparison chart: http://en.wikipedia.org/wiki/Comparison_of_free_software_licences
You could always just use the best one of all, the WTFPL. I use this on most of my school projects since they aren't that great anyways.
Wikipedia, of course, has basically all the information you would ever need to know. But the hard part is to know where to start. I'd recommend starting off by reading about the Apache License and the GNU GPL, which are two popular sides to the same story, each offering different freedoms to the people associated with the code.
But here it is in a nutshell: Apache License lets anyone do anything with your code, including taking it and using it in a closed source product. It gives whoever is taking the code the freedom to do what they want with it.
The GNU GPL, on the other hand, allows your code only to be used in a project that is also distributed under the GPL. In this case you might write some code and prevent a proprietary company from using your work. Here, you're giving freedom to the code itself that it will always be used for "free" purposes.
I'm slightly surprised to see no mention of the Open Source Initiative as a source of information about which open source licences exist. It probably doesn't do the comparisons, so the other sites are also worth checking.
More pragmatic reasons can also influence your choice of license - if you want to use a GPL library, you must use GPL yourself, or if you intend your software to be part of a larger project then you need to look at their requirements.
I've recently begun investigating the type of licensing to apply to a rather substantial piece of work. The number of choices and the content, restrictions (or not) and limitations of all the open-source licenses is bewildering. I've found a couple good links in the answers posted, but I didn't see anything pointing to the Open Source Initiative's alphabetical list of licenses, so I've included it here.
We had a similar dilemma. At our company we decided invest lots of time on a framework, with the eventual hope of releasing it to the open source community. The business is built using open source tools (apache, php, etc.), it was time to give back. We decided on an LGPL/MPL dual license. That way, we could incorporate fixes/improvements from the community, while still protecting applications (particularly ours) running on top of it from being forced to go open source as well.