On January 2 I got an email from Github that was stating that CIKit has received the takedown notice due to the Digital Millennium Copyright Act and repository will be disabled within 24 hours if the content, infringing the copyright of CIBox, will not be removed.
CIKit and CIBox - are close by spirit, but vary in underlying approaches. Let’s take a look closer.
Andrii Podanenko, the man who had published my first project on Drupal.org because I had no rights and enough experience, the man who had advised me a nice book and with whom I had an interesting talk while we were walking Barcelona’s streets, the man who had inspired many people to contribute to the open source and who had created an uncountable number of projects of different complexity decided that CIKit infringe the copyright of CIBox.
Takedown request review
Right after receiving the takedown notice I immediately sent my counter-notice. Let’s stop at some points of it.
“most of them” - is not even close to the legal statement. The content by the link shows how “cibox” was renamed to “cikit” and the amusing moment is that CIBox never had the renamed codebase.
Surprisingly that 7 other forks of CIKit for today are not the problem even despite they have “infringing” content. Perhaps, because their author is not Sergii Bondarenko.
This is not a query to “fix license issues”. Apart from that impulsive comment, no one even tried to reach me out.
Curious fact, that when I wanted to check the post on Facebook, I didn’t manage to find it. I was a bit saddened that someone of admins has removed the post even despite I made the screenshots of the entire conflict. Later on, I found it, visiting the group in incognito mode - it turned out that Andrii blocked my account on his end. It became interesting to me where else apart from Facebook, and I found that he blocked me everywhere where the “block” button exists: LinkedIn, Twitter, unsubscribed me on Github…
As I already stated on Facebook, I’m ready to remove all CIBox stuff from CIKit to not infringe the copyright. Just find that content and point me out onto it.
Let’s answer some questions first to start modeling the situation.
When was CIBox born?
Officially, on September 3, 2014.
When was CIKit born?
Officially, on November 9, 2015. But until December 24, 2016, it was named BR0kEN-/cibox under the original license, belonging to Andrii Podanenko.
When I made the first contribution to CIBox?
On March 16, 2016.
When CIKit changed copyright owner?
On December 24, 2016 CIKit got the copyright owner in a face of Sergii Bondarenko instead of Andrii Podanenko.
On a timeline it might look like:
The BR0kEN-/cibox will be used instead of CIKit below because this article mostly touches the earlier period of the project when it had the license, inherited from CIBox and the “CIKit” name wasn’t coined.
Why was CIKit born instead of focusing on contributing to CIBox?
Well, it is the question I was asked by numerous people and the answer consists of several reasons:
- I had the completely different view of the main approaches in CIBox, such as Ansible playbooks runner, provisioning style of Vagrant, DRY principles, location of unrelated codebase within the project root and so on.
- The main CIBox team, focused on building the core, locates in a different city and, without a close contact, I cannot imagine a development of complex solutions. It is not a lie to say that I was lazy to build a relationship but, on the other hand, have been getting the same. “Let’s do with us” is all I heard approximately 3-4 times for 2 years. Anyway, I do believe the team that seldom meets each other or constantly works remotely - is nothing more than a group of people.
- An absence of pull requests review. They getting merged right after creation, eliminating the chance to write a review for approximately 20 contributors.
What is wrong with running Ansible playbooks in CIBox?
The CIBox style - is to have a shell script per Ansible playbook. Two playbooks - two scripts, twenty playbooks - twenty scripts,
N playbooks -
N scripts. I counted 9 pieces just as of today.
In the very first commit to forked CIBox I’ve created the ansible.sh to eliminate production of shell scripts per playbook. Single runner - that’s what I needed.
What is wrong with Vagrant provisioning in CIBox?
In short: it is too complex and brings an undesired difference to the provision of VM and CI server. Let’s have a look at provisioning configuration in CIBox’s Vagrantfile.
config.vm.provision "shell" do |s| s.path = "provisioning/shell/initial-setup.sh" s.args = "/vagrant/provisioning" end # Install ansible inside the box. config.vm.provision :shell, :path => "provisioning/shell/ansible.sh" # Install ansible playbooks inside the box. config.vm.provision :shell, :path => "provisioning/ansible/run-ansible-playbook.sh" # Install drupal within vm for testing. if !ENV['VAGRANT_CI'].nil? config.vm.provision :shell, :path => "provisioning/ansible/run-drupal-playbook.sh" end
3 shell scripts used as provisioners: initial-setup.sh, ansible.sh, run-ansible-playbook.sh Moreover, you can find a bunch of others in there… BR0kEN-/cibox got rid of all of them on November 16, 2015, in favor of an unified way of provisioning virtual machines and continuous integration servers using a single Ansible playbook.
config.vm.provision :host_shell, :inline => "./ansible.sh provisioning/provision --limit=vagrant"
So, to provision CIBox VM we have a plenty shell scripts and for BR0kEN-/cibox VM we have single provision.yml playbook. Now, how to provision CI server?
I recommend taking a look at last two shell scripts now (and playbooks as well) because the takedown request says that
ansible.sh, the script I’m an author of and the script that has never been a part of CIBox, just had been renamed.
The state of BR0kEN-/cibox for November 16, 2015 is compared with CIBox for November 22, 2015.
What is wrong with a mess of project codebase, mixed with CIBox scripts?
The question stores the answer. CIBox-related stuff locates within
docroot of your project, where no extra codebase is preferred. Will it be a surprise to know that BR0kEN-/cibox overcame this on November 11, 2015? CIBox still continue following this way…
Does CIBox have Ansible 2.x compatibility?
What is wrong with CIBox nowadays?
This is a personal review of the competing product so it does not pretend to be objective and not aimed to insult anyone from CIBox team.
Will you say I pervert if I say I commit
node_modules to repositories? CIBox team does not hesitate to not just do this but makes an exact copy of an entire folder in a different location and commit
node_modules multiplied by two. Check these two folders by yourself: one, two.
- Numerous shell scripts are nowhere gone.
- The CIBox-related stuff is still within your
- Ansible scripts still do not compatible with 2.x, while CIKit has dropped off support of versions lower than 2.4.
- CIBox still on Jenkins 1.6 when BR0kEN-/cibox got migrated to 2.x on December 24, 2016, and now uses latest available version.
- Provisioning of VM and CI still quite different and this reduces the interoperability of environments replication. CIKit does not have this problem an enduring portion of the time.
- CIBox never had a tool for creating a matrix of CI servers when BR0kEN-/cibox got it on March 4, 2016.
- CIBox supports a Drupal only, while CIKit has predefined CI scripts for WordPress, presented on November 17, 2015, and an API for integrating any framework or CMS.
- CIBox never had the Vagrant provisioner for controlling VM preparation process and providing operability on Windows hosts. It was introduced in BR0kEN-/cibox on November 23, 2015.
- CIBox has never used Nginx on CI servers while BR0kEN-/cibox got it on March 1, 2016.
What are the distinguishing features of CIKit nowadays?
- Single-line installation as a system package, that is focused to not ship core files with a project and to make the upgrade process easier.
- Update manager with an ability to run necessary tasks on version transition.
- The controlling utility -
cikit- is written in Python, the same language as Ansible. It allows you to pass/override variables of playbooks as options to a command.
- Scripts for provisioning a server that will play a role of a hosting for CI servers in Docker-based containers.
- A manager of hosts allowing you to keep the credentials of your servers in a single place.
- Ubuntu 16.04 everywhere: VM, CI, matrix (still 14.04 in CIBox and it’s almost reached its end of life).
- Interaction with users for choosing the versions of software they prefer to install.
- Environment configuration that stores in YAML and distributes among all the users.
- Full local-to-CI environment replication.
- Completion scripts (Bash) for the
- Full support of operation on Windows Subsystem for Linux.
- Ansible SSH pipelining for accelerating the process.
- Newer versions of the software: Java, Solr, Selenium, MySQL.
- Microsoft SQL Server, Nginx, Ruby - never been a part of CIBox.
- Ansible inventory that is forming automatically for droplets and manually via hosts manager.
- Automatic IP allocation for virtual machines to create their VPN networks. You don’t need to invent and manually input the IP for every single project while CIBox requires you to do so.
Third-party open source inside of CIBox
puphpet/puphpet is a part of CIBox since the beginning.
Here is the state of CIBox on October 2017:
And the PuPHPet on June 2016 (and later). You can walk around the repositories and ensure by yourself.
The codebase for building CIBox-structured repositories came in sight on February 1, 2016. In BR0kEN-/cibox it was introduced on November 9, 2015. Nobody knows how this idea came to CIBox team. Perhaps they themselves came up with this or borrowed from BR0kEN-/cibox - I don’t know and I don’t care.
The world of open source is wonderful and exists, assuming I’ll be made a dough and you’ll come and bake a bread.
Summarizing the facts
As you read above CIKit has undergone significant changes, as in design as in implementations until the moment of getting the new license.
The idea of the software of this kind is not patented and could not be - you can do your own continuous integration programs as well as image editors, browsers etc.
Anybody, who still have doubts about the difference between CIKit and CIBox, may take the repositories and use
diff command line utility for comparing the codebase at various stages of history.
Why is it happening?
Unfortunately, somewhere in the beginning-middle of December 2017, I made a mistake on Facebook that touches a politically-unstable topic in Ukraine. A bit later I was blocked in Drupal Ukraine community on Facebook by Andrii Podanenko; I have never read and even seen such a lot of rudeness about myself. A single man has started and, it seems, many others were just waiting until the dam breaks: they immediately picked up a wave of personalized insults.
To make a complete picture of the situation you can check the entire post and its comments on Facebook.
I have silently swallowed all personal affronts on Facebook but now it is a time to step in and stop tolerating the attempts to discredit me.
On January 9, 2018, I had a legal consultation (the first time in a life) with Axon Partners (these guys leave a damn good impression) and we agreed to wait until January 18 (10 business days since the takedown notice), when Github should unblock the CIKit. My personal desire is to forget all these disagreements and move on, but if Andrii Podanenko will not stop pursuing me, independently on a sphere of life, I will be forced to collect all the facts and go to court.
It was not easy to stay calm, passing through the streams of mud, but thank you - this made me stronger.
I never actively advertised the CIKit because had a verbal agreement with Andrii Podanenko but now I can no longer consider its validity.
I do appreciate everyone who took part in CIBox until the day I made the fork. Without your hard work I would not be able to create the CIKit. Precisely for this reason I did not initiate a new repository, perpetuating everyone involved in a history.
As a final chord of this article, I want to say thank you to everyone who was supporting me these no-easy days. Without you, guys, I would be feeling BR0kEN.
January 12, 2018, 8 PM
- All commits before December 24, 2016, have been wiped out from the https://github.com/BR0kEN-/cikit. I decided to eliminate any future requests from possible copyright owners by just removing CIBox from the history of CIKit entirely.
- https://github.com/BR0kEN-/cibox is again a fork of the https://github.com/cibox/cibox and contains all the modifications until December 24, 2016, with original license and copyright.
Hope everyone will feel better since now.