Along the license lines;
There are, of course, a variety of licenses available to choose from, if you so desire.
I've been toying with the concept of some type of
"retrograde" license, where the code would be release as open source after a certain date. E.g.: prior to the date of MM/DD/YYYY, the code of this project is licensed under XYZ license.
If this date has been reached and or passed, this section of the retrograde licence may be omitted.
Upon the date of MM/DD/YYYY and afterwards, the code for this project is provided under the GNU/... etc license.
This, essentially would provide me with some time, (as specified by the date of conversion ot OpenSourcing), for me to do with the code things
I wish to do. For instance, if I thought the code/project was good enough, I could make a go of selling it, though people could opt to wait to get it for free after the date that it became open-sourced...
Just one idea I've been kicking around, feedback is welcome, please keep flames on "Low":-)
Another (better, in my opinion) idea I've had recently: A platform specific license, specifying that the software is free and open-sourced for use on Linux systems, but reasonably priced and closed source for Windows(tm) systems.
-Note I've not really considered which way to go with 'Mac'-systems.
-Also note, as for Win/Linux dual or multi booting
systems, the licence applies to whichever OS the code is being run within.
Hope some of this may be useful. Thanks to all offering constructive feedback/criticisms.
by the by, I've not really researched the various
licensing schemes available, so if these ideas aren't really that novel, then please forgive my ignorance.
-S-
aside from Debating the exact definition of "Expire" for a few hours, I present this/these facts:
1] We're talking Security Issues here. 2] Security is reasonably known to be a *Process, not an Destination. *=(continuous).
i.e. continually needed. Where there is connectivity, there is risk. 3] Eventually, has not each incarnation (build) of [the Linux Kernel] been found to have
potential security vulnerabilities/issues? Which thereby required Upgrading or patch-
ing to 'fix' those vulnerabilities/issues. Upon such circumstances, should not the
older version(s) be considered 'Expired' --for strict security purposes. 4] If we were'nt talking security issues here, then much OSS would not necesarily be considered 'Expired because facts 1 through 3 would not be applicable.
# 4 could apply in cases such as where, as danheskett suggested above, someone runs a "freeBSD [or Linux] box in [their] closet that serves MP3s" - (or OGGs/OVFs [?] -for you purists, & yes I did remove a " ' ").
Let's expand my answer: No OpenSource software should not be [forcibly] expired.
Here I'll agree with a few key points: a) One cannot know the best time to expire software. b) One cannot ensure that newer software will be available. c) even if (b) were false, one cannot ensure that newer s.w. will be
better/more effective/secure/stable / not cause other problems etc.
Ideas for more appropriate actions/Method:
relevant to (a) above:
One can suggest a reasonable time frame for software to be checked for updates relevant to (b) above:
see (b) above - There are no "Absolute" guarentees in life. relevant to (c) above:
At some point, [after Much testing] newer software can reasonably be deemed *better*
1) Allow for -Nag- options to be enabled (OR NOT) for software at compile time -- Especially any s.w. which would be involved in issues of security concerns on the system. 1-b) Frequency of the -Nags- could also be selected as compile time option(s)...
I propose that in these -Nag- options, that it be well Explained to the [person] compiling that the(se) software 'Nags' are Highly Recommended (~*~) for Security purposes, and will not `negatively affect their system in any way`...[ensuing debate on that quote aside]; (~*~)-perhaps also add here -'and in your best interest(s)'.
The(se) 'Nags' should be of the nature that -yes, they may be annoying, but they Remind those who may need it or they Inform those who need informing that for [whatever] software is of a certain age that better/ more secure...etc... software may very well be available, and should be checked for - if they are concerned. The options then become... -allow for repetition of the nag(s) --every [so]-[frequently] hours/days/months. -defer the nag until next s.w. age period occurrs- i.e. let the user checked for new s.w.(/ not). -also could 'bundle' in with the Nag(s): options to automatically check for *Upgrades/Updates/Newer s.w.* - here's where the story gets tricky (if it hadn't already) - - if (auto check for *U/U/N s.w.*, and None found); - then {howbout}: Say "None Found...":reset nagtime:Done. - else -(if *U/U/N s.w.* Is found)- . .. here we're (I'm) at 'Dillemaville': Ultimately (and Obviously, I hope) the decision/choice to get&upgrade/patch to(/with) the newer s.w. is/should be with the user/[administrator] of the system/boxxen...
The Big Question is how is it to be determined When the newer s.w. is 'a good thing'. Some suggestions have been made in the discussion here of this topic...
Perhaps the Better Question to pose as the next 'Ask Slashdot': "Determining the most appropriate time to instantiate Software Patches/Upgrades ?"
-- *better* - relating to -Security, and effectiveness, + Stability & not causing other problems etc. Preferably with minimum bloat. The measure of "Much testing" would be the hardest to quantify, methinks, don't you? -- (see end of info: 'relevant to (c) above...")
-my 20 cents-- -Shimmer.
P.S. you can substite "Show:" or "Tell the user/[admnistrtor]:" for "Say"above.
Slashdot Mirror
Along the license lines; There are, of course, a variety of licenses available to choose from, if you so desire. I've been toying with the concept of some type of "retrograde" license, where the code would be release as open source after a certain date. E.g.: prior to the date of MM/DD/YYYY, the code of this project is licensed under XYZ license. If this date has been reached and or passed, this section of the retrograde licence may be omitted. Upon the date of MM/DD/YYYY and afterwards, the code for this project is provided under the GNU/... etc license. This, essentially would provide me with some time, (as specified by the date of conversion ot OpenSourcing), for me to do with the code things I wish to do. For instance, if I thought the code/project was good enough, I could make a go of selling it, though people could opt to wait to get it for free after the date that it became open-sourced... Just one idea I've been kicking around, feedback is welcome, please keep flames on "Low" :-)
Another (better, in my opinion) idea I've had recently: A platform specific license, specifying that the software is free and open-sourced for use on Linux systems, but reasonably priced and closed source for Windows(tm) systems.
-Note I've not really considered which way to go with 'Mac'-systems.
-Also note, as for Win/Linux dual or multi booting
systems, the licence applies to whichever OS the code is being run within.
Hope some of this may be useful. Thanks to all offering constructive feedback/criticisms.
by the by, I've not really researched the various
licensing schemes available, so if these ideas aren't really that novel, then please forgive my ignorance.
-S-
The answer is No.
...":reset nagtime:Done. .
Next question: Does Open Source Software Expire?
Yes.
aside from Debating the exact definition of "Expire" for a few hours, I present this/these facts:
1] We're talking Security Issues here.
2] Security is reasonably known to be a *Process, not an Destination. *=(continuous).
i.e. continually needed. Where there is connectivity, there is risk.
3] Eventually, has not each incarnation (build) of [the Linux Kernel] been found to have
potential security vulnerabilities/issues? Which thereby required Upgrading or patch-
ing to 'fix' those vulnerabilities/issues. Upon such circumstances, should not the
older version(s) be considered 'Expired' --for strict security purposes.
4] If we were'nt talking security issues here, then much OSS would not necesarily be considered 'Expired because facts 1 through 3 would not be applicable.
# 4 could apply in cases such as where, as danheskett suggested above,
someone runs a "freeBSD [or Linux] box in [their] closet that serves MP3s" -
(or OGGs/OVFs [?] -for you purists, & yes I did remove a " ' ").
Let's expand my answer: No OpenSource software should not be [forcibly] expired.
Here I'll agree with a few key points:
a) One cannot know the best time to expire software.
b) One cannot ensure that newer software will be available.
c) even if (b) were false, one cannot ensure that newer s.w. will be
better/more effective/secure/stable / not cause other problems etc.
Ideas for more appropriate actions/Method:
relevant to (a) above:
One can suggest a reasonable time frame for software to be checked for updates
relevant to (b) above:
see (b) above - There are no "Absolute" guarentees in life.
relevant to (c) above:
At some point, [after Much testing] newer software can reasonably be deemed *better*
1) Allow for -Nag- options to be enabled (OR NOT) for software at compile time --
Especially any s.w. which would be involved in issues of security concerns on the system.
1-b) Frequency of the -Nags- could also be selected as compile time option(s)...
I propose that in these -Nag- options, that it be well Explained to the [person] compiling
that the(se) software 'Nags' are Highly Recommended (~*~) for Security purposes, and will not `negatively affect their system in any way`...[ensuing debate on that quote aside];
(~*~)-perhaps also add here -'and in your best interest(s)'.
The(se) 'Nags' should be of the nature that -yes, they may be annoying, but they Remind those who may need it or they Inform those who need informing that for [whatever] software is of a certain age that better/ more secure...etc... software may very well be available, and should be checked for - if they are concerned.
The options then become...
-allow for repetition of the nag(s) --every [so]-[frequently] hours/days/months.
-defer the nag until next s.w. age period occurrs- i.e. let the user checked for new s.w.(/ not).
-also could 'bundle' in with the Nag(s): options to automatically check for *Upgrades/Updates/Newer s.w.*
- here's where the story gets tricky (if it hadn't already) -
- if (auto check for *U/U/N s.w.*, and None found);
- then {howbout}: Say "None Found
- else -(if *U/U/N s.w.* Is found)- . .
here we're (I'm) at 'Dillemaville':
Ultimately (and Obviously, I hope) the decision/choice to get&upgrade/patch to(/with) the newer s.w. is/should be with the user/[administrator] of the system/boxxen...
The Big Question is how is it to be determined When the newer s.w. is 'a good thing'.
Some suggestions have been made in the discussion here of this topic...
Perhaps the Better Question to pose as the next 'Ask Slashdot':
"Determining the most appropriate time to instantiate Software Patches/Upgrades ?"
--
*better* - relating to -Security, and effectiveness, + Stability & not causing
other problems etc. Preferably with minimum bloat. The measure of "Much testing"
would be the hardest to quantify, methinks, don't you?
-- (see end of info: 'relevant to (c) above...")
-my 20 cents-- -Shimmer.
P.S. you can substite "Show:" or "Tell the user/[admnistrtor]:" for "Say"above.