Hyper-V ICS 1.0 (w/Synthethic Network Driver) for pfSense 2.1 & 2.1.1
-
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.
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.
-
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,
MarcoWhen 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.
-
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.
-
@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.)
-
@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. -
-
@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.)
-
Copyright
<year>, <owner>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.
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>
-
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.
-
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 -
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.)
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.
-
@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). -
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>
-
CLA agreement isn't an issue (we sign tons of stuff like that) aslong as ofcourse the ownership of contributed codes don't change hands.
We only been fools once to sign such agreement and still see our art work flow around for free because of it (while the artwork had a specific purpose for a specific project yet without ownership rights you can not make any form of claims of misuse neither).
The pull request , i have to ask our R&D for this, as far as i understaind they did change quite a few basic's AND our build is NOT recommended to mix with another build (lets say hyper-v) duo to the specific changes AND extra tools being installed for Xen.
meaning: this build should not or should it ever be in the "generic pfsense" iso, but a specific pfsenxe - Xen iso.
our R&D mentions this exact same thing for hyper-v aswel.they shouldn't be mixed, but just seperated releases to keep optimum security and performance. (ours was tested and optimized up to 10 Gbit)
So… does this comply with a pull request? as to me it sounds like you need to make a new fork for hyper-v and Xen, for the kernel optimization AND security optimization.