Hyper-V ICS 1.0 (w/Synthethic Network Driver) for pfSense 2.1 & 2.1.1

Yes, I'd be happy to help. In Option C, the drivers were compiled from lightly modified hyperv for FreeBSD 8.3 port source (the only modifications were to Makefiles to get the patch to apply, but we can probably forgo these changes by creating a patch that only applies to sys/modules/hyperv - something I didn't know when I started, hence the more inclusive patch). The source compiles using pfSense-tools and get the ko modules included on the ISO (they're included with the other kernel modules). However, I just need some help to get the drivers installed/used by the installation process.

I can try to keep digging, figuring out pfsense-tools by trial an error (since I haven't found any documentation on the tools other than inline comments). However, I'd only be struggling to figure out info that someone more familiar with the build process already knows (saving me hours of running in circles). Maybe someone that worked to integrate the virtio drivers? Or someone that would know how to instruct the installer/builder to modify /boot/loader.conf (if that is the best way to do this, maybe there is a way to have the installer only make the modification only when Hyper-V is detected).

gonzopancho, can you put me in touch with someone more knowledgeable on the tools? I'll probably need access to the tools repo (as instructed in the development list, I emailed a week ago with an SSH key to gain access, didn't hear back).

Thank you

I'm certain that I have access to pfsense-tools. Several people I work with do, too. (This is because CMB and I own ESF.)
The larger issue is 'testing', and setup of a Hyper-V environment to do so.

@doktornotor:

@bryan.paradis:

The perversion of the project brought on by one person building and distributing, which was taken down after a request I think is far worse.

Knee-jerk reaction, borderline paranoia.

@bryan.paradis:

Now we have an opensource project that isn't buildable?

Which - for me - is a complete and utter fail of the BSD license…

You apparently are unfamiliar with trademark law. I tried to explain, but you seem to not be listening.

@key4ce:

Outch.

Even threatning with legal action to something what i see as a major contribution (helping pfsense work on a hypervisor).
We where about to release a fully working pfsense with Citrix Xenserver 6.2 for the community.

but i guess we will keep that build to our selfs after reading this.

For the admins in question: i would really wonder if thats a right way of handling things if you say you depend on the community yet shoot it down when they do actually contribute :-)

Regards,
Marco

When the -tools repo comes back, you'll be able to build something called "pfsense" with your changes, but you won't be able to distribute it without prior permission (a license) from ESF.

@bryan.paradis:

The perversion of the project brought on by one person building and distributing, which was taken down after a request I think is far worse. Now we have an opensource project that isn't buildable?

Is the solution going to be to have an internal branded buildtoolset and a unbranded copy of that on public git?

No, I'd considered this, but I'm not going to unbrand pfSense for the 57 companies that all want that from us now.'

Someone else could do this, of course. The BSD license allows it. Some have even been successful.

doktornotor

@gonzopancho:

You apparently are unfamiliar with trademark law. I tried to explain, but you seem to not be listening.

And I tried multiple times to suggest that if you are so paranoid about your trademarks, you should provide people with way to build unbranded code instead of removing access to build tools. I tried to explain, but you seem to not be listening. :o

(As for what I'm familiard with, I'd suggest reading the other thread.)

@gonzopancho:

When the -tools repo comes back, you'll be able to build something called "pfsense" with your changes, but you won't be able to distribute it without prior permission (a license) from ESF.

So the code is no longer BSD-licensed? Good that it's clear now that it's not just Jim T. going wild. Pretty much finished this as open-source project. >:(

@gonzopancho:

No, I'd considered this, but I'm not going to unbrand pfSense for the 57 companies that all want that from us now.'
Someone else could do this, of course. The BSD license allows it. Some have even been successful.

Yah. Pissing people off with legal threats is surely a way to accomplish volunteer effort and motivation. You must be kidding. (Actually, they could not do it now, not without using the forked outdated repos at least.)

@doktornotor:

@gonzopancho:

You apparently are unfamiliar with trademark law. I tried to explain, but you seem to not be listening.

And I tried multiple times to suggest that if you are so paranoid about your trademarks, you should provide people with way to build unbranded code instead of removing access to build tools. I tried to explain, but you seem to not be listening. :o

(As for what I'm familiard with, I'd suggest reading the other thread.)

@gonzopancho:

When the -tools repo comes back, you'll be able to build something called "pfsense" with your changes, but you won't be able to distribute it without prior permission (a license) from ESF.

So the code is no longer BSD-licensed? Good that it's clear now that it's not just Jim T. going wild. Pretty much finished this as open-source project. >:(

@gonzopancho:

No, I'd considered this, but I'm not going to unbrand pfSense for the 57 companies that all want that from us now.'
Someone else could do this, of course. The BSD license allows it. Some have even been successful.

Yah. Pissing people off with legal threats is surely a way to accomplish volunteer effort and motivation. You must be kidding. (Actually, they could not do it now, not without using the forked outdated repos at least.)

Doing as you suggest, building a -tools repo with no branding, helps you, but it also helps many companies who want to rip-off pfSense and build their own 'firewall'. Right now, several companies actually pay for that.

Your thoughts seem to mostly consist of rants that ignore the legal realities. Even here you speak of "tons of legal BS", but
it is not BS.

What do we do, doktornotor, when someone eventually builds a version of 'pfSense' that contains a hostile payload? Remember that this is a security project/product.

I'm offering to open a dialogue, you're refusing. We both lose.

Yes, the project is still BSD-licensed. The BSD license covers copyright, not trademark (nor patents, which is why we have the MPL.)

doktornotor

Which part is it that concerns you most:

not currently having access to -tools
not being able to distribute your personal build and still call it pfsense

The situation with #1 will change.
The situation with #2 can not.

doktornotor

@gonzopancho:

Doing as you suggest, building a -tools repo with no branding, helps you, but it also helps many companies who want to rip-off pfSense and build their own 'firewall'.

Rip off? LOL. Yeah, and people rip off Ubuntu daily. And Debian. And… (Read the other thread, really.)

@gonzopancho:

Right now, several companies actually pay for that.

They do? Looks like the rebranding service no longer exists, plus you clearly refuse to do it - "I'm not going to unbrand pfSense for the 57 companies that all want that from us now."

@gonzopancho:

Yes, the project is still BSD-licensed. The BSD license covers copyright, not trademark (nor patents, which is why we have the MPL.)

Well, sorry, no. It is NOT BSD-licensed any more. Since "you won't be able to distribute it without prior permission (a license) from ESF." is directly incompatible with the BSD license.

@gonzopancho:

Which part is it that concerns you most:

not currently having access to -tools

not being able to distribute your personal build and still call it pfsense

The situation with #1 will change.
The situation with #2 can not.

Ad 1/ It won't for change anything for me. Clearly I'm NOT going to sign any licensing agreements to get access to build tools.
Ad 2/ Yes, because there's no –without-branding switch to build the code. Right, you feel ripped off, so there won't be one.

Perhaps you need to read the BSD license again.

It does not, and never did, allow you to use the associated trademarks.

I do not feel "ripped off", I am simply preserving the trademark rights of ESF.

The reason for the delay is I'm trying to restore access to -tools without requiring a written agreement.

(contributions, however, require an associated contributor agreement.)

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.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "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 THE COPYRIGHT HOLDER OR CONTRIBUTORS 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.

The three clause adds:

3. 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.</owner></year>

doktornotor

We are going in circles. See, I'd have no problem if you simply and honestly stated "We want/need more $$$$, so screw you, guys, this no longer is an open-source project, the ideas won't pay our mortgage!" Instead of trying to make a mountain out of a molehill (oh noes, someone did build something and called it pfSense, the end of the world is near! and hide this simple fact behind tons of legal blurb as a "justification". (Ever looked at XDA? People do it daily there, and I have yet to hear about how the companies like HTC, Samsung etc. are losing trademarks en masse, so yeah, let me state again - this is legal BS, plain and simple.)

P.S. Need to ask Manuel Kasper whether he feels "ripped off" as well. ::)

P.P.S. No idea how's the "3-clause BSD" license relevant here. That's not how the code is licensed.

key4ce

Ehmm..

Just a silly question but if we take out every pfsense out of the build (so pfsense is no longer mentioned) and name it something else BUT leave everything you made in tact.. then we did not publish anything under the pfsense name.

Would this mean you prefer a total rebrand so people can publish for example a stable Xen / hyper-v iso "with pfsense" but then just call it "Based up on PFSense" (with their own name) ?

As removing the pfsense name from our build isn't a issue, just seems kind of a dick move which is why we don't/didn't.
but considering i can see how much requests of PFSense with Xen had (as Xen currently lacks good supported firewall distributions) it would be something i would consider doing to "give back" to the community

doktornotor

To conclude this - since "Your intent, however noble, doesn't matter" - see, this is the exact problem people have with this nonsense. What you've done is preventing honest development efforts by the community (not rip-offs), this thread being the prime example. Heck, it even prevents people from using pfSense, since they, as it is, cannot even build the code now, to make is usable on their virtualization platform.

And then Jim T. comes and asks at the mailing list how do forks help the project. WTH? What's you have done is what causes forks. Plain and simple, again. (BTW, your ML archive is still down.)

@key4ce:

As removing the pfsense name from our build isn't a issue, just seems kind of a dick move which is why we don't/didn't.

Yeah, this. People are leaving the pfSense brand there as a credit to the project. Unfortunately, when paranoia kicks in, common sense no longer matters. Actually, thinking about it, must be some kind of schizo paranoia - leave the branding there, you're a trademark offender. Remove it, and you are the bad "rip-off" guy. That, or the motivation is completely elsewhere and has nothing to do with trademarks, as I've suggested above. ::)

It's not paranoia, it's what the law requires in order to maintain the marks.

We're not taking the project "closed source".

I've already stepped up to provide an official build.

You're spreading FUD.

You mentioned Ubuntu. Here is ubuntu's IPR policy:

http://www.canonical.com/intellectual-property-rights-policy

Debian and Mozilla got into it. Mozilla Foundation owns the trademark "Firefox" and claims the right to deny the use of the name and other trademarks to unofficial builds.

http://www.mozilla.org/en-US/foundation/trademarks/policy/

And informed Debian here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354622

The resolution was debian's "iceweasel" browser, which was a rebranded Firefox.

Even Debian itself has a trademark policy.

https://www.debian.org/trademark

Not as well that it prohibits marking (branding) something as debian that is not, in fact, debian.

key4ce

@gonzopancho

i don't wanna get in the middle of the fuzz of this topic but lets stick to facts:
I got a 100% working PFSense with Xen, everything works and even the i to install has been changed to install due to Xen's poor refresh rate on console.

with everything works i mean everything works, including carp, managed switches with LACP etc (all been tested).

Tho for xen tcp checksum offloading have to be disabled on vm level (else connections get hard on the same server, strangely opposite server works fine out of the box, and wan in lacp setup requires is).

all with all we pretty much got automated scripts and hooks for that too on xen.

We do plan on releasing this back to the community, as said there's almost no firewalls working with Xen, so it's a shame not to.
even within just our customers we received countless of requests when we publish it.
–------------------------------------------

That all being said: where do we proceed from here?, to comply with PFSense etc, yet contribute to your community?
(with minimum extra time spent on it, as in the end we are still paid workers, yet tend to give back to community whenever our contractors allow us to).

doktornotor

Extremely difficult to have a conversation when someone posts 5 random things in a row in 5 different posts (your Edit button got broken, or what?)

1/ I am well aware of the Mozilla BS, that was about the last straw for me. Seems like they are at it again, now they don't like that Dell UK is charging for installation service (maybe someone should mention to them that their trademark rights are exhausted by the first distribution in the EU, after that, they have no way to stop anyone from redistributing it, selling it or whatever else… Meanwhile, the browser development got completely off-track to put it mildly, same happened to their release cycle (wheeeew, we need to catch up with Chrome), and they are losing their userbase pretty fast. Is this the way you'd like to follow?

2/ Debian/Ubuntu - again, already discussed this on the other thread, not going to go thru this again in detail. And as said on the other thread as well, I have yet to see Debian sending "the most polite letters from lawyers" to the Mint guys, e.g. I also have yet to hear about complaints from Ubuntu or Debian about "abusing" they package mirrors.

So oh yeah, you say you are just protecting your trademark. The easiest way to protect it would be providing the unbranded build tools. Instead of pissing off large part of the active community and trying to make them jump through hoops to get access to something that's been always available. So honestly, all I can see behind this are the $$$$. All of this being even more absurd, given the origins of the pfSense project as a m0n0wall fork. And to be perfectly honest, the mails by Jim T. on the ML (archive still down, on purpose?) made me pretty much sick. If you guys feel so much exploited by people using your code, you should have chosen a different license from the very beginning. Oh wait, it wasn't about money at that time, right?

I got a 100% working PFSense with Xen, everything works and even the i to install has been changed to install due to Xen's poor refresh rate on console.

That's great!

That all being said: where do we proceed from here?, to comply with PFSense etc, yet contribute to your community?
(with minimum extra time spent on it, as in the end we are still paid workers, yet tend to give back to community whenever our contractors allow us to).

Contributions are welcome (and we are grateful for them), but we don't want anyone confused about what 'pfSense' is, and is not.
And we have to act in a manner that preserves our trademarks.

The 'rules' for pfSense are the same as for nearly any Open Source project of our side or lager.

You can build and run a version inside your organization, (or individually), which you have done.
This is fine, as the BSD license(*) allows exactly this, and we want to encourage experimentation and development of the pfSense base. But you can't distribute the results outside your organization with the pfSense indicia intact.

If you want to provide us with pull requests, we're happy to review them. If they meet with our evaluation, and a CLA(**) is received from the individual(s) or company(ies) who have accomplished the work, then we will accept them into the pfSense source repository. If we have the resources, we will build and release these for the community. (We may choose to not support them for various reasons, including lack of resources.)

If you like, you can use me as 'point' on this. <jim-at-pfsense.org>or <jim-at-netgate.com>work.

All the above also applies to the original subject of this thread, 'Hyper-V' support.

(*) Most of pfSense is licensed under the BSD license, but pieces of it come with different licenses attached. These are not our work, but the work of individuals and companies outside BSD Perimeter or Electric Sheep Fencing. Typically they are in the original FreeBSD tree.

(**) CLA = "contributor license agreement". This basically a low-key agreement were you assert that it's your original work, and that we have the rights from you sufficient to build and redistribute it, and that you won't sue us for doing so (or infringing on your IP in the work, etc.</jim-at-netgate.com></jim-at-pfsense.org>