Git policy violation

I'll take a look at this, but I don't really know why you're jumping all over me when the same CSS file is included in tons of themes ON drupal.org, and also even has a module: https://www.drupal.org/project/normalize, but yes, I don't see it on the packaging whitelist, and it appears through the myriad of confusing, incomplete, and incoherent information regarding "licensing" policies that it is probably not allowed.

And as it is mentioned here: https://www.drupal.org/node/422996#comment-7475828 Removing it now will not actually "fix" the licensing issue since the file can't/won't be purged from git completely and is now there for all time. So I guess it'll be okay to have an archived version of a license policy violation in the repository, but not one that's actively being used.

Guess I'll just have to write some "original code" that has the same effect. Cheers!

Let me clarify so my position doesn't sound hostile even though it wasn't meant to be in the first place.

I WILL take care of this issue. I however, hope that this issue was not directed to only me, but this issue was just one of hundreds upon hundreds already created, or in the process of being created to deal with ALL of the files amongst ALL the projects on D.O. that potentially violate the licensing policy by including some php/js/css libraries that break policy.

Initially, I hate to have to figure out a way around this because as Omega (is once again) intended to be for users with little to no knowledge of the theme layer, any libraries that I deemed appropriate to include to make the end users life easier that need to be downloaded to a certain location, and enable a libraries module, is out of the question for many users.

Omega is intended to be a "set it and forget it" base theme, allowing the most newbie Drupal users to turn on a theme and click a few options and "make it their own".

Most themes (probably every theme) come with some form of Reset CSS. From the old Eric Meyer reset.css, normalize.css, or one of the many variations upon both. Users shouldn't be required to run some compass/ruby build script in order to build out all the elements that are needed to build the files needed for the starting point of a contributed theme.

So this leaves me with the option to create my OWN reset.css with "original" code. No matter what code I write for this solution, any number of elements will be copied and adapted from some other library that already exists. Even if I had the knowledge of everything to be reset/normalized in my head and wrote the code letter by letter, line by line, it could be argued it was "copied" from a existing library on the internet.

My only point is that the entire licensing issues with 3rd party libraries is quite vague, and the process to deal with these issues seems to need a lot of work and a LOT of clarification.

Old issue but - better to wake it up here than to start a new one.

No @himerus - you are not being picked on personally, and I'm only touching this project now as an issue of fairness. I often remind newbies in the project application queue about how respecting the work of others, and respecting Open Source Licenses is ethically and legally important. And when their response is also "but xxx does it as well" - then we have a consistency problem.

In trying to support everyone to do the right thing, and solve some of the potential challenges in legal re-use of copyrighted libraries, I remembered that due to its richness, this project had probably encountered this issue before, so came looking to to see how it had been done, hoping for a good example to point at. :)

However - As well as the package.json and grunt stuff and build instructions (which is what I was hoping to see)
.. What I also found was a full copy of PHPSASS.
PHPSASS is a stand-alone PHP library, available from github or Packagist for Composer, Licensed as BSD.

I do not believe there is any vagueness in the Drupal.org policy that states that this sort of redistribution is not permitted.
I do understand and sympathize with your (and every other copy-paste developer) desire to just provide something that works out of the box! Encouraging respect for licensing and authorship is not something we do to deliberately make life hard. So we are looking for solutions here, not inventing problems.

Modern theme toolsets with gulp, grunt, sass, node, ruby, and all those things do tend to introduce such challenges, but equally, asking a theme developer to explicitly initialize or require some libraries if they are to take advantage of the tools seems to be the new normal.

While I agree it may have been difficult to provide the functionality in the past without just pasting this library in like that - happily, some solutions now exist. :)
In precisely the same way as this project already uses npm etc to allow users to include third-party libraries as needed - I expect you are able to use you composer.json to pull in this other PHP library!
From my own experiences, this is possible, but certainly can be a bit complicated to get sorted out the first time.

Suggestions:

• Remove the third-party library from the codebase (It's not constructive to be distracted by 'purging' git history or anything, it's - what is much more important is doing the right thing going forward!)
• Provide attribution information and instructions for how to download the phpsass from the licensed source.
• Add richthegeek/phpsass as a dependency in your composer.json, with some additional composer settings that may be needed to make things work in your custom context

When done correctly, you should end up with a seamless download again. With the bonus that the *additional* composer dependencies that *that* library has will have been made appropriately available also.

I'm not enough of a Composer expert to describe the extra tweaks in detail, but I think that if you are able to meet the d.o community half-way on this, we'll be able to find someone out there who can advise us specifically on how best to achieve this, and then we can all end up with some clearer instructions in the d.o documentation pages for everyone!

(Which ultimately, was the real reason for me coming and examining the Omega code in the first place!!)