management
#define management: \
I------------------------------------------------------------------\
I ___ ___ _ \
I | \/ | | | \
I | . . | __ _ _ __ __ _ __ _ ___ _ __ ___ ___ _ __ | |_ \
I | |\/| |/ _` | '_ \ / _` |/ _` |/ _ \ '_ ` _ \ / _ \ '_ \| __| \
I | | | | (_| | | | | (_| | (_| | __/ | | | | | __/ | | | |_ \
I \_| |_/\__,_|_| |_|\__,_|\__, |\___|_| |_| |_|\___|_| |_|\__| \
I __/ | \
I |___/ \
I------------------------------------------------------------------I
• this chapter regards everything relating to project and programmer management
https://ludic.mataroa.blog/blog/i-will-fucking-dropkick-you-if-you-use-that-spreadsheet/
# some culture
http://www.catb.org/jargon/html/
# to gain a deeper understanding of web development and such (this is not a joke)
Bullshit Jobs: A Theory by David Graeber
"\
There's no such thing as the FOSS community, only open standards pushed by \
corporations used by millions of freeloaders. The so called community \
rarely achieve a sustainable development, most successful community driven projects \
are made by a corpo backed group or a single talented individual that makes \
daily commits. \
" - Anon
"\
Because the technician has no opinions or convictions of his own \
outside of his specialty, he needs the crutches of some vulgarized faith \
as peddled by the demagogue. \
" - Friedrich Georg Jünger, The Failure of Technology, 102.
Chatedral_effect:
"\
Studies have shown that the environment we find ourselves in powerfully shapes \
our thinking. When we are in a space with high ceilings, for example—think of \
the lofty architecture of classic churches invoking the grandeur of heaven—we \
tend to think in more abstract ways. When we’re in a room with low ceilings, \
such as a small workshop, we’re more likely to think concretely. \
\
No one questions the importance of having physical spaces that make us feel calm \
and centered, but when it comes to your digital workspace, it’s likely you've \
spent little time, if any, arranging that space to enhance your productivity \
or creativity. \
\
Well now, spending hours customizing your UI in Linux doesn't sound so stupid \
anymore, does it? \
" - Anon
Iron_triangle:
• "project management triangle"
• famous visually intuitive tool describe the trade-off between aspects of a product
• the idea is that aspects are layout out at the vertices;
and a dot -marking the philosophy of the software- is placed inside;
one may prioritize 2, but get further away from the 3th,
or focus heavily on 1, but loose out on the other two
— it has multiple variants:
• scope - time - cost (original)
• quality - time - cost
• resilience - speed - maintainability (most useful outside of a corporate setting)
• security - speed - usability
• having more than 3 vertices for specialized domains
• extending it onto the 3th dimension, ruining the ability
to represent it on paper, a board or a text document
{
resilience
/`\
/ \
/ \
/ \
/ . \
/ \
/ \
/_______________\
speed maintainability
where:
resilience - is security and a subset of robustness,
which includes accounting for edge-cases and
the graceful handling of errors
speed - is performance
maintainability - is a combination of readability, flexibility
and extensibility;
it also implicitly represents cost,
because harder to maintain software requires
more man hours
examples:
• aggressive dependency injection to facilitate testability,
hinders maintainability by introducing extensive context
• telemetry helps debugging, but introduces overhead
• extra checks help preventing errors
at the cost of run-time and more code to oversee
• making assumptions helps with optimizations,
yet hurts security unless hard to maintain code is also introduced
• low-level code is fast and hard to maintain
}
Roles:
• efficient dev teams are comprised of specialists with specific duties
— analyst:
• a mediator between developers and normies
• his duty is defining the outlines of the project;
making sure the list of required features,
especially with cost-effectiveness in mind
• writes highest-level documentation
• a business analyst is specialized in mediating
• a system analyst is specialized in project outlining
• a process analyst is specialized in the domain that is to be aided by software;
usually someone on the client side of the order
— project manager:
• a parrot that asks "how is the project going"
• professional accountability buddy, required due to human psychology
• ideally not just some retard, but someone with other duties too,
otherwise she is a leech on the budget
— front-end developer:
• someone with a sense of beauty
• trained in UX/UI foremost
• ideally you are not paying him for html/css monkey-ing,
but creating something visually appealing and comfortable to use
— back-end developer:
• theoretically any non-front-end developer
• in practice refers to CRUD monkeys
— architect:
• creates high-level code documentation
• responsible for ordering and flashing out the project
• specifies modules, patterns and interfaces
— junior:
• a code monkey
• implements specifications
Weekly_build:
• developers work on their own branches for 4 days of the week
• the progress of others is not considered during development
• the 5-th day of the week is dedicated to integrating all changes back to master
• works poorly for large teams and or large projects
• as the integration (time) cost grows, it should be abandoned
Implementation: Implementation:
• if a software complies with a documentation its called an implementation
• might as well be interpreted as an instance of a software class defined by a specification
• many large software projects {languages} have more than 1, concurrently developed implementations
• multiple implementations are beneficial due to the same logic a free market is beneficial to consumers
Firmware:
• code embedded into devices
• becomes obsolete as hardware evolves,
this is an important distinction compared to software,
which is (or atleast supposed to be) hardware independent
Framework: Framework:
• a stand alone program that is centered around user override-n behaviour
• highly reusable blank stale
• dictates the control flow
• collection of developer tools
• predefined project structure
• not to be confused with a library
Big_data:
• "bigdata"
• "An alternate definition of Big Data is “when the cost of keeping data around is less \
than the cost of figuring out what to throw away.” I like this definition because \
it encapsulates why people end up with Big Data. It isn’t because they need it; \
they just haven’t bothered to delete it."
Most_common_code_quality_errors: Most_common_code_quality_errors:
• "software crisis"
• orphaned/redundant/poorly written comment
• commented out code
• project wide operations {building, testing} require more than 1 command
• too many function arguments
• dead functions
• obvious behaviour is unimplemented
• duplication
• inconsistency
• clutter
• obscured intent
Imaginary_software: Imaginary_software:
• "vaporware"
○ software that is described by one of the following
• has no user potential
• has no users
• is never finished
• exists only on paper {spec}
Owned_code: Owned_code:
• the phenomenon when one develops an emotional ownership to code
— the syndrome is characterized by:
• unwillingness to accept help
• denial of contribution merging
• unreasonable attachment to arbitrary conventions
• it easily halts meaningful development of a piece of software
• highly relevant in the field of coding due to the disproportional percentage
of autistic workers
• for examples, read GNU discussions
Fountain_dilemma: Fountain_dilemma:
• metaphor: fountains are pretty and everyone wants one,
but are painful and expensive to maintain
• feature requests are often fountain like;
their complexity is high, but the return is low
• its important to recognize such features and eval them responsibly
• always document their nature
Project: Project:
https://miro.com/
— to almost all software projects at least on of the following applies:
• goes over budget
• goes over time
• does not comply with expectations
• bad quality
• causes damage {monetary; health}
• never finishes
+---------------------------------------------++---------------------------------------------+
| Unique Software || Boxed Software |
+---------------------------------------------++---------------------------------------------+
| The customer is personally known and || There is no preconceived customer, |
| can be communicated with. || only potential customers. |
| More expensive for the customer. || Cheaper for the customer. |
| For the customer it takes longer to || The customer gets a working system fast. |
| acquire a working system. || |
| Stable pay for the developers. || Get-rich-quick wetdream of start ups. |
| Updates must be contracted. No unexpected || (Usually) updates come frequency and free. |
| updates can cause trouble. || Some updates might cause obstruction. |
| Not bloated. Fits exactly with the || Might already contains functionalities |
| requirements. || which are not yet, but will be desired |
| || (by individual customers). |
+---------------------------------------------++---------------------------------------------+
○ components of commercial software
• source code
• installer
• documentation
○ aspects of software quality
• reliability
• maintainability
• serviceability
• security
• testability
SaaS:
• "Software As A Service"
• for access to the software connection to a server is required
• a continuous subscription fee must be payed for access
• all your rights are stripped away, you are our toy-slave, goy
• usually the server will host the entire backend
• usually the software is browser based
Free_trials:
• common advertising spyop
• helps to draw in new users
• during the trial period {7, 30 days} the user gains access to all or most features
of the software
• a common scam is to ask for credit card information up front and
start withdrawing after the trial has ended,
playing on the chance that the user might have forgotten about
cancelling
Tasks: Tasks:
• "story"
Goal_gradient_effect:
• people work harder as the perceived goal draws closer
• exploited by splitting the work to many small part,
and stressing their proximity with mirrors and smoke
to get the maximum possible worker performance
Story_points:
• semi-arbitrary metric to measure performance
• could correspond to work hours or work days, the team may choose
• every task must be supplied with a story point cost estimate
— the number of story points available in a sprint is:
let <worker-availability> : int - be story points an individual worker
is worth with his ideal performance
let <focus> : const float - be a fraction to express the probable work
{ estimated from previous sprint; 70% as a sensible default}
( ∑ <worker-availability> ) * <focus>
Planning_poker:
• used for democratically estimating task durations or story point values
○ the process
1. each participant is handed an identical deck of cards with various
values which may represent any unit to be estimated
2. a task is proposed and described
3. each participant chooses a card privately
4. participants flip over their cards
5. if total agreement then
goto 2
if disagreement then
discussion
goto 3
except deadlock then
postpone current task
goto 2
RUP:
• "Rational Unified Process"
— the idea that every task can be split into 4 so called phases:
• inception
• elaboration
• construction
• transition
Task_controll_system:
• maintains a list of all tasks and tracks progress
Gantt_graph:
• displays development tasks, their planned completion order
and implementation dependencies
Burndown_chart:
Story points remaining
X ▲
│'--
│ '. .
│ ' `,
│ \
0 ┼──────────┼▶ Time
Deadline
• descending into the goal tends to be a more motivating representation
• with very short sprints it tends to be useless overhead
Kanban_tables:
https://trello.com/
https://docs.gitea.com/
○ has the following columns
• todo
• in progress
• under review (*optional)
• done
• its common to set a limit on how many tasks can be presented in column simultaneously
• cells are also called cards each expressing a task or "story"
• physical boards have been found to be the best in practice
│ TODO │ IN PROGRESS │ UNDER REVIEW │ DONE │
├────────────────────────┼────────────────────────┼────────────────────────┼────────────────────────┤
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
Ideal_planning_space: Ideal_planning_space:
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ ########################## ┃
┃ Design whiteboard __ ┃
┃┌──┐ ::| \ ┃
┃│ │ ::| |┃
┃└──┘ ::|__/ ┃
┃┌──┐ Public PC ┃
┃│ │ ┃
┃└──┘ @┃
┃┌──┐ K B @┃
┃│ │ Open Space a o @┃
┃└──┘ n a @┃
┃Chairs b r @┃
┃ a d @┃
┃ n @┃
┃ @┃
┃ @┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
GOF:
• "Gang Of Four"; the 4 retards who came up with the initial set of OOP patterns
— principles:
1. Program to an interface, not an implementation
2. Favor composition over inheritance
3. Encapsulate what varies
4. Strive for loose coupling between objects
SOLID: SOLID:
|S|ingle Responsibility Principle
|O|pen-Closed Principle
|L|iskov Substitution Principle
|I|nterface Segregation Principle
|D|ependency Inversion Principle
SRP: SRP:
• "A module should be responsible to one, and only one, actor."
• every * should have 1 responsibility with extra mental gymnastics,
bastardizing it from art to brain cancer
• stolen from the Unix Philosophy
• applied to class-es, it leads to new new new new new
• can produce ravioli code
OCP: OCP:
• open for extension, closed for modification
• the primary mechanism behind it is polymorphism;
possibly with decorators and such
• factories have an inherent problem of abiding OCP,
we simple dont talk about that
• the performance impacts can be severe
• introduces complexity to the code
LSP: LSP:
• subtypes must be substitutable for their base types
• "for the love of God, stop checking the types at runtime"
• assumptions about basetypes should apply to derived types
ISP: ISP:
• "Clients should not be forced to depend on interfaces they do not use"
• dont bloat your interfaces
• technically SRP already expresses this
DIP: DIP:
• high-level modules should not depend on low-level modules,
both should depend on abstractions
• abstractions should not depend on details;
details should depend on abstractions
• introduces a bunch of abstract layers to prepare for errors,
that the compiler would catch anyways
• the performance impact is severe
• all interfaces depend on details;
pretending otherwise is futile;
its deluding ourselves with interfaces that correspond to no reality
• its really just polymorphism done right with facades;
this should be really bloody obvious when to use,
while being autistic about its application is retarded;
making it basically redundant as a principle
{
┏━━━━━━━━━━━━━━━━┓
┃ class compiler ┃ high level
┗━━━━━━━━━━━━━━━━┛
|
— - - - | - - - - - - -
V
┏━━━━━━━━━━━━━━━━━┓
┃ class assembler ┃ low level
┗━━━━━━━━━━━━━━━━━┛
┏━━━━━━━━━━━━━━━━┓ ┏━━━━━━━━━━━━━━━━━━━━┓
┃ class compiler ┃--->┃ interface assembler┃ high level
┗━━━━━━━━━━━━━━━━┛ ┗━━━━━━━━━━━━━━━━━━━━┛
|
— - - - - - - - - - - - - - - - | - - - - - - -
V
┏━━━━━━━━━━━┓
┃ class x86 ┃ low level
┗━━━━━━━━━━━┛
}
Component_cohesion_principles:
• REP; "Reuse/Release Equivalence Principle"
• CCP; "Common Closure Principle"
• CRP; "Common Reuse Principle"
Software_Development_Life_Cycle: Software_Development_Life_Cycle:
• "SDLC"
• if a model has a clear start and end, its called linear
• if a model has steps which will have to be repeated const to keep the software viable (alive),
its called iterational or incremental
Waterfall: Waterfall:
• linear
• struct-ured
• well documented
• no backtracking or partial transitions between stages
1. Requirement Analysis
2. System design
3. Implementation
4. Testing
5. Delivery
(6. Maintenance)
• the main problem is that if the analyst made a mistake,
it gets into the end product, likely costing a fortune
SSADM: SSADM:
• "Structured System Analysis and Design Method"
• government standard; literally from 1984, Britain
• data flow diagram oriented
• hyperfixated on the concept of products
• products are crafted from products, creating new products
V: V:
• named after the shape of its graph
— splits the development into 2 virtual phases:
• implementation
• testing
• both phases consist of steps
• the implementation phase closely resembles the waterfall model
• if an error is encountered in a step of the testing phase,
backtracking must be done to the mirroring step of the
implementation phase
• linear
• struct-ured
• well documented
┃ "Testing phase"
(Start) ┃ (End)
+-----------------+ +-----------------+
\ PRD \ │ / Deployment /
\ \ / test /
+-----------------+ │ +-----------------+
\ Functional \ / System test /
\ specification \ │ / /
+-----------------+ +-----------------+
\ System \ │ / Integration /
\ specification \ / test /
+-----------------+-+-----------------+
\ Implementation │ Component /
\ │ test /
+--------------+-+--------------+
RAD: RAD:
• "Rapid Application Development"
• many prototypes
• continuous deployment tests
• non-formal team communication
• fast
• pretty name for anarchy (which is the default state of software development)
PROTOTYPE CYCLES
..------..
.' '.
+---+ .' Demonstration'. +---+
| \ .:.--. :. | \ .------------------.
+------------+ \ |/ B \ /````\ | +------------+ \ | |
| Requirement \ | u : : | | Testing \ | <Deployment> |
| analisys / | i : :\ /| | / | |
+------------+ / | l \,,,,/ \__/ | +------------+ / | |
| / ': d +'` :' | / '------------------'
+---+ '. / Refineing .' +---+
'. .'
''------''
Development: Development:
Agile_development: Agile_development:
https://agilemanifesto.org/
• when the stress is on getting the software to work
• documentation is second class at best
• with time, will result in monolithic stacks of blackboxes creating a hell hole to work with(/around)
• practically an ideology to justify shitting out software as fast as possible for incomemaxxing
• communication with the customer is done parallel with programming
• new practices, experiments and optimization attempts are encouraged
Extreme_programming: Extreme_programming:
• "XP"
• clusterfuck of techniques
• agile
• fuck the documentation; just talk it out; what is a bus factor?
• TDD
• pair programming
• code review
• continuous integration
• refactoring
○ pillars
• planning
• coding
• testing
• attention
○ values
• communication
• simplicity
• feedback
• bravery
• respect
SCRUM: SCRUM:
https://www.scrum.org/assessments/professional-scrum-master-i-certification
• not an actual acronym, comes from a rugby formation
• agile
• "behavioural framework"
• everyone involved has a curious last name and they sell certifications, go figure
• uses RAD
• sprints are used
• each sprint results in a prototype
• commonly used together with extreme development
• big teams are divided into small ones
— kanban tables:
• each sprint resets the table
• the backlog is sorted by priority
Sprint:
• a period of development lasting a predefined spawn of time,
under which a set of tasks must be completed
• when sprints are used, the entire development process is split into them
• outlined during a planning meeting, where the goal is set and tasks are distributed
Teams:
• employees are sorted into smaller SCRUM teams
• each team has their own sprints and meetings
• teams dont communicate with each other directly
• teams dont specialize, so they dont have to wait for each other during sprints
• some recommend mixing up the team members between sprints, either to find the
most optimal compositions or to resolve internal conflicts
Roles:
Pigs:
• SCRUM master
• developers (optimally 3-8 people)
Chickens:
• managers (product owners) (may mix between SCRUM teams)
Meetings:
Daily:
• 15 minutes max
• only pigs are present
• only standing is allowed ("stand-up meeting")
— each person must answer the following questions:
• what have you done since the last meeting?
• what will you do until the next meeting?
• what impediments have you encountered?
• this is when the kanban board gets updated (if physical)
Sprint_planning:
• held before sprints
• manages the backlog
• chickens are invited
• few hours max
Sprint_review:
• held when a sprint is finished
• chickens are invited
+---+ +---+ +---+ +---+ +---+
| \ | \ | \ | \ | \
+------------+ \ +------------+ \ +------------+ \ +------------+ \ +------------+ \ +----------+
| Product \ | Sprint planning \ | Sprint \ | Sprint \ | Sprint \ | |
| backlog / | meeting / | {2-4 weeks} / | review / | retrospective / | |
+------------+ / +------------+ / +------------+ / +------------+ / +------------+ / +----+ |
| / .--. | / | / | / | / | |
+---+ .' '. +---+ +---+ +---+ +---+ | |
.' '. | |
| | | |
+--+ +--+ | |
| | | |
| | | |
| +----------------------------------------------------------------------------------------------+ |
| |
| |
+---------------------------------------------------------------------------------------------------------+
Pair_programming: Pair_programming:
• when 2 people program together in such manner that only one codes
• the man coding is referred to as the navigator
• the man observing and assisting {with information} is referred to as the driver
• dont lie to ourselves, it reduces the productivity of 2 people to that of less than 1
>the one situation where code ouput could go up is in documentation browsing heavy contexts
• if both participants are known to write atrocious code,
their combined output is expected to go up in quality
• it is known that the knowledge base of any developer is not
going to be a clean super-set of any other developer's,
pair programming is the most efficient way to transfer knowledge between developers,
making them more replaceable (which is ideal for any employer)
• some are simply not fit for it
• frequent pair shifting is encouraged
• used to manage developer stress levels with (forced) socialization
PERT: PERT:
• "Program Evaluation & Review Technique"
• US army™
• statistical strategy used for approximating project durations
— a chain of tasks where every task has the following qualities
• Optimistic estimate & weight (recommended: 1)
• Most probable estimate & weight (recommended: 4)
• Pessimistic estimate & weight (recommended: 1)
• by averaging together the 3 weighted estimates of a task,
we get a more optimal estimate
• calculating a standard deviation and treating the tasks estimate in such context
is highly recommended
Refactoring: Refactoring:
• "the process of changing a software system in such a way that\
it does not alter the external behavior of the code yet improves its internal structure"
Backlog_grooming: Backlog_grooming:
• "backlog refinement"
• fancy way of saying "cleaning tickets"
• remove old, irrelevant stuff
• reevaluate whats left
• split and create new tickets based on old ones if appropriate
Licenses: Licenses:
— trademarks:
® - registered trademark
™ - unregistered trademark
℠ - unregistered service mark
• freeware is software that can be freely copied and shared
• shareware is freeware on a license period
• proprietary software is software with a proprietary license
• postcard-ware is software where the copyright owner asks for optional positive feedback,
under the condition that the user liked the software
• adware may refer to freeware where the profit model is based on ads or
computer viruses with the intent of showing ads
• abandonware is software where the identity of the copyright holder is unclear
to the point that its reasonable to assume that no one can present a realistic
legal case for it {company that no longer exists}, abandonware is usually
threated as freeware
Licensing: Licensing:
• each source file must include the copyright notice or a clear indication of
what license is being used
• at least one legal name must be used in the license { "Emil & Anon" wont work }
• you should attach both electronic and analog contacts
• "You should also get your employer (if you work as a programmer)\
or your school, if any, to sign a \"copyright disclaimer\" for\
the program, if necessary."
—
• anyone who includes a gigantic, full license notice at the top of each source file,
nicely formatted to 80 chars so it takes up atleast 20 lines,
is mentally handicapped
Copyright: Copyright:
• anglo abomonation spiced by the US
• owned by a person, multiple people in share or a company
• until death + 70 years
• the owner can decide who may copy, modify and or copy it
• "infringement" is a perceeved violation of copyright,
the owner is entitled to seek legal action
• turns out i could be jail for up to 2 years for torrenting, oh well
— auto applies to:
• creative works
• logos
• trademarks
— except:
• "unappropriate creations" {porn; which is happily exploited by certain webservices}
• inventions and innovations ( these can still be explicitly patented)
○ examples in software
• binaries
• source files
• APIs (yes, seriously)
Proprietary: Proprietary:
• the right for usage is sold by the copyright holder
• specifies the number of computers it can be used on (implicit 1)
EULA:
• "End User License Agreement"
• records the conditions of usage
• companies keep getting away changing it on the fly with updates
and without providing access to prier versions
• obviously too long and technical to except anyone to read them
BSA:
• "Business Software Alliance"/"\"software police\""
• coperation between big corpo to enforce copyright laws
• not a proper enforcement firm, but work very closely with
various legitimate law enforcement entities
• known to organize raids against suspected infringers
• their tactic is to convince employees to become rats
• often sends out letters ordering to prove software ownership
Public_domain: Public_domain:
• no copyright applied to begin with
• no owner at all
• do whatever
Anon_license:
Permissive: Permissive:
• : it cucks the developer, but gives absolute freedom to the user
• throws away copyright with very few conditions protecting the owner,
without restricting the user
• proprietary licenses can be added on top
BSD: BSD:
○ text
Copyright {c} <year>, <copyright holder> 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 conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the <copyright holder>.
4. Neither the name of the <copyright holder> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY <COPYRIGHT HOLDER> AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES {INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION} HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT {INCLUDING NEGLIGENCE OR OTHERWISE} ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
— 4-clause
• original
— 3-clause
• "Revised BSD License"
— 2-clause
• "Simplified BSD License"
• used by FreeBDS
— 0-clause
• only mitigates responsibility
+--------------------------------+
BSD LICENSE COMPARISON
+----------+----------+----------+----------+
| 4-clause | 3-clause | 2-clause | 0-clause |
----------+----------+----------+----------+----------+
Clause-1 | o | o | o | |
clause-2 | o | o | o | |
clause-3 | o | | | |
clause-4 | o | o | | |
----------+----------+----------+----------+----------+
MIT: MIT:
○ text
Copyright <YEAR> <COPYRIGHT HOLDER>
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, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Apache2: Apache2:
• relatively long
• preserve the copyright notice
• state changes in modified distributions
• the current copyright holders give up any future claims
• do whatever otherwise
Copyleft: Copyleft:
• works inside the constructs of copyright
• the copyright owner grants freedoms to everyone
GPL: GPL:
• : it ensures free software stays free software, but in the process cucks the users freedom
• "gnu General Public License"
• requires source aviablility meaning distributors
have to provide a way to obtain the source code;
this can be as minimal as providing instructions,
meaning this clause is open-ended, up for legal interpretation bullshitery
• theoretically prevents GPL software to become proprietary or to be used as a component of proprietary software
• "Linux is a cancer that attaches itself in an intellectual property sense to everything it touches," - Steve Ballmer
• way too long to copy paste here
GPLv2: GPLv2:
• the copyright owner does not sign away his future rights
○
1. keep and redistribute the notice;
you may sell copies or offer warranties
2. follow the following rules:
• add a notice about your changes and their date
• you may not sell licenses
• if the program in question prints the copyright on
interactive use, that must be retained in modified versions
programs using GPL code that can be considered independent work,
can apply their own license to said portions and GPL does not apply
3. do at least one of the following when distributing binaries:
• distribute machine readable source code
• attach a written offer that you will distribute
the source code uppon request to any 3th party
• pass down source code distribution offers
4. violating the license strips you from all rights
5. by modifying, copying or distributing the program you accept the license
6. ownership persists
7. no condition cancels the terms of this license
8. one may exclude countries from distribution if he explicitly
copyrights them there
9. we may create newer licenses "similar in spirit", trust us goy,
we wont pull a communist bait-and-switch,
specify "GPLv2 or later" in your license
10. if you wish to use partial source code in other programs
which are not licensed under GPL you must request permission
11. no warranty
12. we are not liable
— key points:
• "You may charge a fee for the physical act of transferring a copy,\
and you may at your option offer warranty protection\
in exchange for a fee."
• "The act of running the Program is not restricted,\
and the output from the Program is covered only if\
its contents constitute a work based on the Program\
(independent of having been made by running the Program)"
• "You may not impose any further restrictions on the recipients'\
exercise of the rights granted herein."
• "It is safest to attach them to the start of each source file to\
most effectively convey the exclusion of warranty;\
and each file should have at least the \"copyright\"\
line and a pointer to where the full notice is found."
• recommendations on the act of licensing
GPLv3: GPLv3:
• communist bait-and-switch
• the copyright owner signs away his future rights
• the language is noticablely much more lawyer-talk like
○
1. definitions
2. no takesies-backsies
3. seriously, no takesies-backsies
4. you may distribute the source code intact for any fee
5. follow the following rules:
• add a notice about your changes and their date
• "keep intact all notices"
• derived works inherit this license
6. convey the source with binaries
7. added terms to this license may be removed when redistributing
8. violating the license strips you from all rights
9. by distributing you accept the license, but not by receiving or
making a copy or running one
10. ownership persists
11. every contributor gives up any future claims for copyright
12. no condition cancels the terms of this license
13. you may combine this license with the GNU Affero General Public License
14. we may create newer licenses "similar in spirit", trust us goy,
we wont pull a communist bait-and-switch,
specify "GPLv3 or later" in your license
15. no warranty
16. we are not liable
— key points:
• "All rights granted under this License are granted for the term of\
copyright on the Program, and are irrevocable provided\
the stated conditions are met."
• "You may convey covered works to others for the sole purpose of having\
them make modifications exclusively for you, or provide you\
with facilities for running those works"
• "A compilation of a covered work with other separate and independent\
works, which are not by their nature extensions of the covered work,\
and which are not combined with it such as to form a larger program,\
in or on a volume of a storage or distribution medium, is called an\
\"aggregate\" if the compilation and its resulting copyright are not\
used to limit the access or legal rights of the compilation's users\
beyond what the individual works permit. Inclusion of a covered work\
in an aggregate does not cause this License to apply to the other\
parts of the aggregate."
AGPLv3: AGPLv3:
• GPLv3 then some
• modified versions of AGPL software must also be source available
Modifiers: Modifiers:
• must be combined with other licenses
GCC_Runtime_Library_Exception:
• GPLv3 would make all your compiled binaries GPLv3;
yeah, no, forget about that, do whatever with your binaries
+NIGGER:
• created by CrunkLord of Kiwifarms
• unironically used by chinese companies to keep western companies
from using otherwise open-source code (keeping the technical lead at home turf)
— "By including the word \"NIGGER\" in a LICENSE file that must be distributed with the software you will ensure:"
• "The software will not be used or hosted by western corporations that promote censorship"
• "The software will not be used or hosted by compromised individuals that promote censorship"
• "Users of the software will be immune to attacks that would result in censorship of others"
Version_controll: Version_controll:
git
svl
• literally everything currently on the market but Git, is garbage;
whatever google uses is much praised, but its internal use only
• tracks changes in source
• allows for inspecting previous iterations
• a common, but wrong assertion is that you should delete code,
instead of commenting it out for the long term;
the reasoning being,
that the version control system will hold on to the code for you
and commented out code is a code-smell;
the second part is correct, however
the problem is that if you shift code into history,
its discoverability becomes near zero,
defeating the purpose of commenting out
○ important concepts
Repository : a project with a version control system initialized inside it
Fork : a version controll created copy of source code
Commit : the unit of versioning;
some changes made and added (commited) by someone;
each commit except the initial has a parent
Branch : a "path" of commits;
one commit might be the parent of multiple commits,
these divergent paths are refered to as different branches
Trunk/Master : the main branch of a project
Head : a marker of the current commit;
which is usually used for determining what version of
the project to show and operate on
Checkout : the act of viewing a specific version (marked by a commit);
usually "refreshes" the project directory
Merge : the act of uniting 2 branches;
may result in a merge commit
Conflict : could happen during merging; when 2 branches have edits
to the same file / file region; these must be resolved by hand,
to not break the project
Tag/label : arbitrary text assigned to a commit; usually marks a version
(not as defined by the version control system { v1.4.6 })
Update/Pull : the process of patching a local fork with extern-al commits,
usually from the Trunk