35 replies to this topic

[kitche]

... I just like BSD sicne I can close it at any time and such

As far as I've always known, if you own the *copyright* (say, if you wrote it, basically) to a GPL program, you can change the license to anything at any time. I guess the legality of it is, as copyright holder, one of the rights granted to you by that status is the ability to change licensing. I'm pretty sure you can, at least, apply this to any future revisions.

One of the stickier points of this is patches. If I have a bunch of people who contribute patches to my software as GPL (yes, you can license patches), then I can't change the license of the software with patches, unless I have consent from the copyright holders of said patches.

With past revisions: say you make v1.1 of your software and put a proprietary license on it, but I've previously downloaded v1.0, which was GPL'd. I have ownership of a piece of software that was licensed to me as GPL (the v1.0 of your code). So basically I can do anything to it within terms of the GPL (including redistribute, or fork it to another project). Now, if I somehow happened to get a copy of full source to your v1.1, and it were closed source, I can't do either of those because it's not licensed as such. Also, in the case of v1.0, I can't change the license in any future revisions/forks I make of the software, because the code I "own" wasn't licensed to me with the right to do that - nor am I the copyright holder, obviously.

EDIT: And also note, under this logic... you could replace GPL with BSD in the above paragraph and it's still true. If I download a version of your code that is BSD, I gain ownership of a copy of software under that license, and can do anything with it I see fit - so long as it adheres to the BSD license, of course. My point being, with the code you distribute (whether it be via GPL or BSD license), you can't retroactively "close source" previous versions of your code... at least, not the copies someone else already obtained.

This is where my legalese gets muddy. You *might* be able to change licensing on past versions, though I'm not sure. I am sure, though, of the fact that any copies of said software already obtained were obtained via the original license, and can't have their licensing altered after the fact.

With GPL software the code must always be open if I want to add a feature to a program that is already GPL'd, since the new code must be under GPL.

With BSD all I need to do really is keep the copyright in tact in the source files.

If you want to know more about the GPL vs BSD thing just look up the issue with the ath5k in the linux kernel. explains it a lot really

[WhatChout]

With GPL software the code must always be open if I want to add a feature to a program that is already GPL'd, since the new code must be under GPL.

Not if you're the creator of the original software. You can release a new version under a completely different licence, no previous licence can restrict that.

[eldiablo]

I contribute bug reports and just spread the word about FOSS. I actually got my mom using Ubuntu now and she loves it. I like to help people new to FOSS learn. I'd like to actually to contribute more in the realm of documentation and artwork, but time restraints won't let that happen right now. I do occasionally donate money to various projects. I'd like to get good at programming so I could contribute in that way as well.

[Andre van dem Helge]

In the past few months I've started to contribute to the openSUSE project. It's my favorite Linux distribution and I've just been reporting any bug I find and providing any needed details about it. I've also contributed here and there when the documentation shows out of date and adding is easy (I really wanted to edit some pfSense documentation but their wiki is locked down)

Edited by Andre van dem Helge, 02 September 2008 - 10:20 PM.

[kitche]

pfsense documentation is pretty up to date since it's uses FreeBSD as a base which uses pf from openBSD 3.5 or something like that

[army_of_one]

All my hobbyist projects are open-source whenever I finish them. However, I almost never use the GPL for anything I want to get out there. I prefer an Apache or BSD-like license. This way, if I right say an awesome crypto library, companies like Microsoft are more likely to include it in their own software. Then, I don't have to worry about what crappy homebrew solution isn't protecting my sensitive data. OpenBSD follows this philosophy partly for the same reason, and it's since been used in quite a few security appliances. This is good for everyone. Additionally, you can make both free and enhanced commercial versions of your software with the same codebase. That's a nice bonus.

So, if you want the software free, auditable, and actually used by the largest number of companies possible, a BSD-type or public domain license is usually your only shot.

[dinscurge]

i wish i could contribute to gentoo/*bsd then you would all have nothing to argue about beacuse itt would have both of the licenses or whatever, and the icon is sweet

[|cfh|]

Does this count?

( They've probably gotten $100 out of me over the years, not much. But still it's something. )

I love OpenBSD. I wish I had money to purchase the latest release. I like having a nice physical copy/etc.

I'll have to hold off for now.

[army_of_one]

Does this count?

( They've probably gotten $100 out of me over the years, not much. But still it's something. )

I love OpenBSD. I wish I had money to purchase the latest release. I like having a nice physical copy/etc.

I'll have to hold off for now.

OpenBSD is excellent, but unfortunately unusable in many applications. If someone wants something approaching the security of OpenBSD, but with apps and modern features like Linux, then FreeBSD is probably best answer. Both FreeBSD and NetBSD incorporate segments of OpenBSD's audited code into their codebase, so users get a security bonus. FreeBSD has Jails and some B1-style security features if needed. In my case, a fast networking stack and full multiprocessor support forced me to use FreeBSD or Linux. I'm still using OpenBSD in certain software appliances.

[Aghaster]

I've just posted my first significant contribution to an existing open source project, rdesktop. I've completely re-written the way rdesktop handles keyboard input, in an effort to bring much better support for different keyboard types and layouts, using the XKB configuration database.

Here is my email announcement in the rdesktop-devel mailing list.

I'm a bit excited and worried at the same time, I just want it to be accepted, I've put a lot of time so far in this. I want it to be perfect.

Here is a copy of the mail:

Hi,

It has been a while since the discussion about rdesktop using XKB. I've
worked on it from time to time, and I finally got something which is usable
Download it here:

http://www.awakecodi...desktop_mod.zip

Unzip the contents of the archive over the latest sources, and then add
xkbkeymap.o to the following line in the Makefile:

X11OBJ = rdesktop.o xwin.o xkbkeymap.o xkeymap.o ewmhints.o xclip.o
cliprdr.o

And it should compile. For the moment, I expect it to work fine at least
under any system with XKB, but the magic of the thing is that it doesn't
depend on any pre-existing XKB installation.

The reason for this patch is that rdesktop currently has its down separate
keymap database that it keeps updating and fixing. The way the keymaps
currently works is that it maps keysyms (almost the resulting characters
you'd see on your screen corresponding to a keystroke) to scan codes used by
the remote desktop protocol. As there are tons of different keyboard
layouts, it means tons of possible keymaps we'd have to make so that we
correctly map everything for each keyboard layout. It also means that if on
the client side we change the keyboard layout while rdesktop is running, the
keymap will now be wrong (still mapping for the previous keyboard layout),
unless you restart rdesktop. I've been thinking about the problem and about
a "cleaner" way to solve it. I thought of the XKB configuration database,
which is separate from XKB itself and intends to be an up to date and
accurate keymap database usable for everyone. Could we ask for a better
thing? They're already supporting way much more keyboards than we do, so I
thought it would only be for the better.

Now, what part of XKB is the best to use. Considering that we're sending
scan codes through the remote desktop protocol, it makes sense to simply map
keycodes -> virtual key codes -> scan codes. Why not keycodes to scan codes
directly? Because they're not always the same for the same key, and that is
pretty much why Microsoft made virtual key codes for. So, keycodes ->
virtual key codes -> scan codes is the most efficient and accurate. It
doesn't even depend on the current keyboard layout, all we have to know is
the keyboard type (the default type just works fine with pretty much every
"common" keyboard, a significantly different one would be a japanese
keyboard). For systems with XKB, what I'm doing in the patch at the moment
is that I call setxkbmap -print and get the current XKB keyboard type out of
that. This requires no linkage with XKBlib, which is nice.

I said at the beginning that it doesn't require any pre-existing XKB
installation. The reason is that I've made a perl script which exports only
the part of the XKB configuration database that is needed, making a new one
out of it that maps only keycodes to virtual key codes. Maintaining
rdesktop's XKB configuration database is as simple as running the perl
script on newer versions of the XKB configuration database that contain
fixes. The mapping from virtual key codes to scan codes is made using an
array of structures containing the mapping, so that for instance:

virtualKeyboard[VK_SPACE].scancode

gives you the scan code for VK_SPACE.

The new XKB configuration database that is exported by the perl script can
be located anywhere where the current keymap folder is. I've made rdesktop
search for the folder in the same places.

There is more. I've made a lot of work on finding the current possible
keyboard layout from the current locale. What I found is that in the current
rdesktop code, the locale of the system would be used to find a keymap of
the same name as the locale. The keymap would then contain the keyboard
layout code that is sent to the remote desktop server. I used the locale IDs
and default keyboard layouts from Microsoft, and made a table out of it. I
also make complete tables of all the keyboard layouts and the ID that should
be sent to announce to the remote desktop server what keyboard layout to
use. this is all in keyboard.h

Now, an overview of the files contained in the patch:

Keyboard.h:
Macro definitions for all virtual key codes
Default built-in keymap
Virtual key code to scan code conversion map
Keyboard layout IDs + Name in an array of structures. Same for keyboard
layout variants and IMEs.

Locales.h:
Macro definitions for all locales (with locale ID)
Locale country code + language code to locale ID map
Default keyboard layouts for each locale, in an array of structures

xkbkeymap.c:
Functions to detect, initialize and load the keyboard layout
Functions equivalent to what you have in xkeymap.c, but for XKB

XKB
Folder containing all the keycode -> virtual key code maps.

XKB/xkb.pl
Perl script to export the XKB configuration database to an easier to use
format for rdesktop.

What I plan to work on, next:

Keyboard layout detection on non-XKB systems. I own a SPARC system
running Solaris 10, and it doesn't have XKB. That would be my first target.
OpenSolaris comes with X.org and XKB, so it should be fine for that one. I
also have an old PowerPC mac that runs Mac OS X Tiger, I would eventually
take the time to write keyboard layout detection function that reads it from
the current Mac OS X configuration.

I would like to know your comments and advice for the work that would still
need to be done on this. If anybody is using a japanese keyboard I would
require his assistance in order to ensure that it works fine with those
keyboards. Weird sun keyboards should be working fine if XKB is correctly
set for that keyboard. In other words, whatever is supported by XKB should
be supported by rdesktop with that.

I encourage you to try my patch and give comments! I also need people to test it so that I can more easily find problems in it.

[livinded]

I've just posted my first significant contribution to an existing open source project, rdesktop. I've completely re-written the way rdesktop handles keyboard input, in an effort to bring much better support for different keyboard types and layouts, using the XKB configuration database.

Here is my email announcement in the rdesktop-devel mailing list.

I'm a bit excited and worried at the same time, I just want it to be accepted, I've put a lot of time so far in this. I want it to be perfect.

Here is a copy of the mail:

Hi,

It has been a while since the discussion about rdesktop using XKB. I've
worked on it from time to time, and I finally got something which is usable
Download it here:

http://www.awakecodi...desktop_mod.zip

Unzip the contents of the archive over the latest sources, and then add
xkbkeymap.o to the following line in the Makefile:

X11OBJ = rdesktop.o xwin.o xkbkeymap.o xkeymap.o ewmhints.o xclip.o
cliprdr.o

And it should compile. For the moment, I expect it to work fine at least
under any system with XKB, but the magic of the thing is that it doesn't
depend on any pre-existing XKB installation.

The reason for this patch is that rdesktop currently has its down separate
keymap database that it keeps updating and fixing. The way the keymaps
currently works is that it maps keysyms (almost the resulting characters
you'd see on your screen corresponding to a keystroke) to scan codes used by
the remote desktop protocol. As there are tons of different keyboard
layouts, it means tons of possible keymaps we'd have to make so that we
correctly map everything for each keyboard layout. It also means that if on
the client side we change the keyboard layout while rdesktop is running, the
keymap will now be wrong (still mapping for the previous keyboard layout),
unless you restart rdesktop. I've been thinking about the problem and about
a "cleaner" way to solve it. I thought of the XKB configuration database,
which is separate from XKB itself and intends to be an up to date and
accurate keymap database usable for everyone. Could we ask for a better
thing? They're already supporting way much more keyboards than we do, so I
thought it would only be for the better.

Now, what part of XKB is the best to use. Considering that we're sending
scan codes through the remote desktop protocol, it makes sense to simply map
keycodes -> virtual key codes -> scan codes. Why not keycodes to scan codes
directly? Because they're not always the same for the same key, and that is
pretty much why Microsoft made virtual key codes for. So, keycodes ->
virtual key codes -> scan codes is the most efficient and accurate. It
doesn't even depend on the current keyboard layout, all we have to know is
the keyboard type (the default type just works fine with pretty much every
"common" keyboard, a significantly different one would be a japanese
keyboard). For systems with XKB, what I'm doing in the patch at the moment
is that I call setxkbmap -print and get the current XKB keyboard type out of
that. This requires no linkage with XKBlib, which is nice.

I said at the beginning that it doesn't require any pre-existing XKB
installation. The reason is that I've made a perl script which exports only
the part of the XKB configuration database that is needed, making a new one
out of it that maps only keycodes to virtual key codes. Maintaining
rdesktop's XKB configuration database is as simple as running the perl
script on newer versions of the XKB configuration database that contain
fixes. The mapping from virtual key codes to scan codes is made using an
array of structures containing the mapping, so that for instance:

virtualKeyboard[VK_SPACE].scancode

gives you the scan code for VK_SPACE.

The new XKB configuration database that is exported by the perl script can
be located anywhere where the current keymap folder is. I've made rdesktop
search for the folder in the same places.

There is more. I've made a lot of work on finding the current possible
keyboard layout from the current locale. What I found is that in the current
rdesktop code, the locale of the system would be used to find a keymap of
the same name as the locale. The keymap would then contain the keyboard
layout code that is sent to the remote desktop server. I used the locale IDs
and default keyboard layouts from Microsoft, and made a table out of it. I
also make complete tables of all the keyboard layouts and the ID that should
be sent to announce to the remote desktop server what keyboard layout to
use. this is all in keyboard.h

Now, an overview of the files contained in the patch:

Keyboard.h:
Macro definitions for all virtual key codes
Default built-in keymap
Virtual key code to scan code conversion map
Keyboard layout IDs + Name in an array of structures. Same for keyboard
layout variants and IMEs.

Locales.h:
Macro definitions for all locales (with locale ID)
Locale country code + language code to locale ID map
Default keyboard layouts for each locale, in an array of structures

xkbkeymap.c:
Functions to detect, initialize and load the keyboard layout
Functions equivalent to what you have in xkeymap.c, but for XKB

XKB
Folder containing all the keycode -> virtual key code maps.

XKB/xkb.pl
Perl script to export the XKB configuration database to an easier to use
format for rdesktop.

What I plan to work on, next:

Keyboard layout detection on non-XKB systems. I own a SPARC system
running Solaris 10, and it doesn't have XKB. That would be my first target.
OpenSolaris comes with X.org and XKB, so it should be fine for that one. I
also have an old PowerPC mac that runs Mac OS X Tiger, I would eventually
take the time to write keyboard layout detection function that reads it from
the current Mac OS X configuration.

I would like to know your comments and advice for the work that would still
need to be done on this. If anybody is using a japanese keyboard I would
require his assistance in order to ensure that it works fine with those
keyboards. Weird sun keyboards should be working fine if XKB is correctly
set for that keyboard. In other words, whatever is supported by XKB should
be supported by rdesktop with that.

I encourage you to try my patch and give comments! I also need people to test it so that I can more easily find problems in it.

You should look into using diff and patch rather than just overwriting the files with a zip. It allows people to quickly go through and look at what was changed and merge changes to a code base that maybe have changed since the last time you updated and started working on it.

[Aghaster]

@livinded: Yeah, I thought about it. I thought just overwriting the files on a clean rdesktop source would be fine for the beginning, and that for the submission that gets accepted it would be with a real patch using diff.

[Bizurke]

My contribution is more community based. I try to do my best to help people fix their problems, learn new things, and stuff like that. Debian has a rather new, since before Lenny launch, Marketing Team which spends it's time on press releases, getting the word out, and anything else that can be done to get the word out both online and in real life for Debian. I am not an official member of the Marketing Team but I do my best to lend them a hand whenever I can.

I also run a blog dedicated to Debian which gives tips, tricks, news, updates, etc. I hope that websites like this help increase Debian's online community and makes it easier for anyone to get started with and continue to grow with Debian. Being a distro that is the base of so many other distros much of the information I have works downstream as well so that's nice. I do hope, eventually to get officially involved with the Debian Project but don't see myself doing that for a while now.

[Swerve]

Question for people who do contribute to open source projects.

In one my classes we have been tasked with developing a new feature for a current open source project. I'm not going to state which project it is (privacy/doc dropping) but in this case, all there is, is the SVN repo, and hardly any documentation at all, infact pretty much none except for the end user instructions.

Is this often the case? I currently find my self with a massive project in Visual Studio, and thats about it. It's kinda overwhelming to be honest.

WallOfCode.jpg.

[lattera]

Question for people who do contribute to open source projects.

In one my classes we have been tasked with developing a new feature for a current open source project. I'm not going to state which project it is (privacy/doc dropping) but in this case, all there is, is the SVN repo, and hardly any documentation at all, infact pretty much none except for the end user instructions.

Is this often the case? I currently find my self with a massive project in Visual Studio, and thats about it. It's kinda overwhelming to be honest.

WallOfCode.jpg.

It really depends. For me, if the project is just some hobbyist tool meant to solve a little problem, I likely won't write documentation. I'll let the code document itself. However, if the project is meant to be more serious, I'd document it both inside the source through comments and through API documentation. If the code is obscure, but meant to be reused within a few years, I'll likely just comment the code.

[SAGA]

I contribute to Fedora Project by maintaining packages in my free time. 2 cents for my favourite operating system (using it more than 4 years). https://admin.fedora...ackages/sagarun