Sergii Bondarenko

Sergii Bondarenko

DMCA notice for taking down the CIKit

11 minute read

DMCA notice for taking down the CIKit

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.

Brief preamble

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.

If you have read the complaint, the claim is pellucid: CIKit - is a renamed CIBox that violates BSD license, where the copyright owner is changed from Andrii Podanenko to Sergii Bondarenko.

Takedown request review

Right after receiving the takedown notice I immediately sent my counter-notice. Let’s stop at some points of it.

Files to take down

“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.

Forks

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.

  1. https://github.com/Mitsuroseba/cibox-1
  2. https://github.com/kapoldi/cikit
  3. https://github.com/sb3838438/cikit
  4. https://github.com/Selitbovskaya/cikit
  5. https://github.com/spheresh/cikit
  6. https://github.com/stalliobn/cibox
  7. https://github.com/gajdamaka/cibox

Focusing at https://github.com/gajdamaka/cibox we may see the fork had been created 2 years ago - on November 18, 2015. Does it, even a bit, looks close to CIBox at those days?

Licence violation

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.

Facts sheet

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.

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:

CIBox/CIKit timeline

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.

  1. provision.sh
  2. repository.sh
  3. requirements.sh
  4. check_updates.sh
  5. reinstall.sh
  6. runcodestyleautofix.sh
  7. rundevops.sh
  8. runsniffers.sh
  9. runtests.sh

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?

CIBox: run the run.sh that will run the jenkinsbox.yml playbook.

BR0kEN-/cibox: run the ansible.sh that will run the provision.yml playbook.

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?

It still requires you to use 1.9.6 despite 2.x has been released on January 12, 2016. Meanwhile, BR0kEN-/cibox became Ansible 2.x compatible on January 17, 2016.

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.

node_modules weight in the Universe

Other moments:

  • Numerous shell scripts are nowhere gone.
  • The CIBox-related stuff is still within your docroot.
  • 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.

The change of license and the copyright owner of BR0kEN-/cibox, alongside with renaming project to CIKit and detaching it from CIBox on Github has happened on December 24, 2016.

What are the distinguishing features of CIKit nowadays?

X-Men as CIBox and CIKit

Third-party open source inside of CIBox

Case one

puphpet/puphpet is a part of CIBox since the beginning.

Here is the state of CIBox on October 2017:

CIBox at f21dffb49fdf52711b02ff13d962a20db8fdc7f4

And the PuPHPet on June 2016 (and later). You can walk around the repositories and ensure by yourself.

PuPHPet at 50dcab55392bbbe6d30a5a86b4969cf45f38ceab

Case two

The Ansible role for Jenkins installation stores the links to modified, MIT-licensed, https://github.com/afonsof/jenkins-material-theme.

Case three

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.

I do understand that my post was an absolute mistake and I want to apologize here once again, apart from couple times I already did this on Facebook.

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.

Thank you

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.

Respect everyone!

Updates

January 12, 2018, 8 PM

Hope everyone will feel better since now.

Comments

You May Also Enjoy