Tag Info

Hot answers tagged

59

Because it's extra effort to create and maintain such a document, and too many people don't understand the associated benefits. Many programmers aren't good technical writers (although many are); they rarely write documents strictly for human consumption, therefore they don't have practice and don't like doing it. Writing a code overview takes time that you ...


14

The dry, harsh truth? Documentation is not made because projects can do without it. Even open source projects often face stiff competition. Most of such projects don't start with large shoulders, they start off a bright idea, often a one man bright idea. As such, they can't afford the time and costs of hiring human documentors, even if they offered to ...


7

Overview documents such as you describe are rare even on commercial projects. They require extra effort with little value for the developers. Also developers tend not to write documentation unless they really need to. Some projects are lucky to have members who are good at technical writing, and as a result have good user documentation. Developer ...


7

Yes, undistributed improvements don't need to have source code released. This was an intentional decision when designing the GPL; you're allowed to modify the code for your own purposes without needing to tell anyone what you're doing, or to distribute anything related to it. The GPL was never intended to say "if you improve the code, you must release the ...


6

The GPL requires all derivative works to be licensed under the GPL as well. If you fork a GPLed software and distribute your fork, then you are required to offer your software under the GPL. This implies that you have to make the source code available. From the GPL v3: 5. Conveying Modified Source Versions. You may convey a work based on the ...


5

In principle, there is nothing wrong with accepting payment for software you provide, not even if that software is freely available through other channels. Some gotchas to look out for are: Bank account details are loved by criminals. If possible, prefer to use services like PayPal. Be careful with what you promise and what contracts you sign. What level ...


5

1) Can someone sell a fork of an open-source software under GPL without distributing the source? Example: Can I modify a little bit GIMP, repackage it under another name, and sell it as a commercial product without giving source code (like Adobe Photoshop) ? Holy cow NO! That's exactly the sort of behavior that the FSF made the GPL to fight ...


5

Are there things like these and I'm missing them? Things that do the same job as I am describing? There is an excellent book called The Architecture of Open Source Applications that provides detailed descriptions of a variety of high-profile open source software projects. However, I'm not sure if it exactly fills the role you're imagining, because I ...


4

Because there are far more open-source programmers than open-source technical writers. Documentation takes maintenance and time to keep up to date. The more bulky the documentation, the more it takes. And documentation that isn't in sync with the code is worse than useless: it misleads and conceals instead of revealing. A well documented code base is ...


3

Your biggest problem is the other contributors. Unless you have a written agreement with them, they own the copyright to the bits they contributed. This means you need to get all of them to agree to release the software under a different license. Established projects require all contributors to sign a contributor's license agreement. If you have done this, ...


3

(I am not a lawyer, this is not legal advice, etc.) My understanding says that this is perfectly fine. A copyright license is a license from the copyright holder granting specific permissions under specific conditions. It is up to the copyright holder what to license, to whom, under what conditions. It is even common for the copyright holder to offer ...


3

The first thing you want to do is check how projects accept submissions and in what format (e.g. where to branch from, do you need to rebase, style guide etc.). Make that step 0. For step 3, it depends on your workflow. Mine is to clone the repo to a folder I have specially for such projects, create a virtualenv (usually using virtualenvwrapper, as it makes ...


3

So let's take a look at first clause in the BSD 2-clause license template. Copyright (c) , All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of ...


3

To quote from MIT license text: The MIT License (MIT) Copyright (c) Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, ...


2

Git repos are incredibly easy to set up. Move your file into a directory of its own, run git init, and start enjoying version control. There's no downside to doing this, except that you end up with a lot of repos. If you want to share that repo on GitHub or Bitbucket, just do so – after all, public repos are free. The idea to have one big repo that contains ...


2

You're having trouble with this question because you're not thinking about the right things. Source control is a tool, it's not a means to an end. What are your plans down the road? Do you want to have a toolkit of many scripts where people can use any or all of your package for, say, audio processing? Then group them together in the AudioMiscellanea ...



Only top voted, non community-wiki answers of a minimum length are eligible